システム導入の失敗は「要件定義の丸投げ」から始まる—発注側の経営者が押さえるべき、要求と要件の違いと4つの要件

1｜結論—今すぐ取るべき経営判断

最も大事な経営判断は、要件定義（システムで何を実現するかを決め、文書にまとめる工程）の責任者を、ベンダーではなく自社の業務部門の責任者とし、意見が割れたときの裁定は経営者が持つことです。ベンダー（システムを開発・販売する会社）は「決める人」ではなく、「決めるのを支える人」と位置づけます。ベンダーは、要件を文書にまとめ、実現方法と費用を示すことには長けています。しかし、どの業務を変え、どの要望を見送るかは、自社の事業の優先順位を知る者にしか決められません。

そのうえで、経営者自身が決めるべきことは三つです。第一に、このシステムで何を達成するのかという目的と、それを測る指標です。第二に、要望が予算や期間を超えたときに、何を先に実現するかという優先順位です。第三に、今回はやらないこと、つまり対象外とする業務や機能です。特に三つ目は現場から言い出しにくく、経営者が明言しない限り決まりません。

2｜なぜ丸投げは失敗するのか—「要求」と「要件」は別物

任せきりの背景には、「要望を伝えれば、プロが形にしてくれる」という思い込みがあります。区別すべきなのは、要求と要件の違いです。家の新築にたとえると、「リビングを広くしたい」は要求です。それを何畳にし、どの向きに置くかまで決めて図面に書いたものが要件です。

要求をそのまま要件にすることはできません。「早くしたい」は、どの業務を、どれだけ、何のために速くするのかを決めて、初めて要件になります。この翻訳の過程で、矛盾する要求のどちらを採るか、費用に見合わない要求を見送るかといった取捨選択が必ず発生します。その取捨選択を外部に委ねた状態が「丸投げ」です。

国の報告書も、発注側がITを自ら判断できない状態を問題にしてきました。経済産業省は2018年のDXレポート（DX＝デジタル技術で業務や事業を変えること）で、既存システムの複雑化・ブラックボックス化（中身を誰も説明できなくなること）を問題視しました。放置すれば、2025年以降に最大12兆円/年（レポート公表時の約3倍）の経済損失が生じる可能性があるという指摘です（出典：経済産業省「DXレポート」、2018年9月）。その後のDXレポート2（2020年12月）、2.1（2021年8月）、2.2（2022年7月）でも、ユーザー企業とベンダー企業の関係の見直しが論じられています。2025年の総括でも、DXとレガシーシステム（古い仕組みのまま使い続けているシステム）脱却の進捗は「依然としてスピード感に欠ける」とされています。多くのユーザー企業がベンダーに依存し、ITに対する自律性が低下した「丸投げ体質」も、課題に挙げられています（出典：経済産業省「レガシーシステムモダン化委員会総括レポート」、2025年5月）。

3｜要件の全体像—業務要件から4つのシステム要件へ

要件定義は、二つの段階で進めます。まず業務の側で、現状の流れと課題を把握し、要求を整理して「何を変えるか」を決めます（業務要件）。次に、それをシステムが満たすべき条件に落とし込みます（システム要件）。システム要件は、次の四つに分けて考えると漏れが減ります。

非機能要件は、特に見落とされやすい領域です。IPA（情報処理推進機構）の「非機能要求グレード」は、非機能要求を6つの大項目に整理し、発注側とベンダーが段階的に水準を合わせられるようにしたものです。大項目は「可用性」（止まらずに動き続ける度合い）「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」です。最新版は2018年版で、同事業は終了していますが資料は公開されています（出典：IPA「非機能要求グレード」）。IPAの整理では運用と移行も非機能要求に含まれますが、発注側の判断の論点が異なるため、本稿では別立てにしました。「24時間止められないのか、夜間なら止めてよいのか」といった水準の決定は、費用に直結する経営判断です。

移行要件の具体的な決め方は、データ移行の事前準備を扱った別稿に譲ります。パッケージ製品を使う場合、要件定義は、製品の標準機能と自社業務の差を見極めるFit&Gap分析と一体で進みます。その手順と、提案依頼書（RFP）によるベンダー選定は本稿では扱いません。

4｜関係者ごとの関心—ずれを裁くのは経営者

要件定義が難しいのは、関係者がそれぞれ別の基準でシステムを見ているからです。

どの立場の関心も正当で、だから互いにぶつかります。業務部門の「今のやり方を残したい」とベンダーの「標準機能に合わせてほしい」が対立したとき、どちらを採るかを決められるのは、経営目標に照らして判断できる経営者だけです。経営者が不在のままだと、結論の出ない会議が繰り返され、要件定義の期間そのものが延びていきます。

5｜経営者が関与すべき3つの場面

経営者が関与すべき場面は、次の三つに絞れます。

STEP1　着手時—目的・指標・やらないことを文書で示す

要件定義の開始前に、導入の目的、効果を測る指標、対象外とする業務を1枚の文書にまとめ、関係者に示します。「やらないこと」を先に書いておくと、要望が増え続けるのを止めやすくなります。要件定義の期間と、自社側の担当者が割く時間も、ここで決めます。社内にまとめ役がいなければ、発注側に立つ外部の支援者を付ける手もあります。

STEP2　中間時—優先順位の衝突を裁く

業務要件がそろった段階で、要望の一覧に「必須」「あれば望ましい」「今回は見送り」の区分を付けます。区分の意見が割れたものは、経営者が決めます。あわせて、要件定義そのものの工数（作業にかかる人数と時間）と期間が、計画どおりかも確認します。

STEP3　確定時—要件定義書を承認し、変更の手続きを決める

要件定義書は、業務部門の責任者と経営者が承認して確定させます。あわせて、確定後に要件を変えたい場合の手続きを決めておきます。誰が影響と費用を評価し、誰が可否を決めるかです。確定後の追加要望を手続きなしに受け入れることが、予算超過の典型的な原因です。

6｜よくある誤解—要件定義を他人事にする判断のパターン

誤解①　「要件定義はベンダーの専門領域だから、任せたほうが良いものができる」 ベンダーが得意なのは、決まった要求を実現可能な形に整理することで、何を優先するかを決めることではありません。任せきりにすると、要件定義書は誰も責任を持たない文書になり、稼働後に「そんなつもりではなかった」という食い違いが表に出ます。

誤解②　「現場の要望をできるだけ多く取り入れれば、使われるシステムになる」 要望をすべて受け入れると、機能が増えて費用と期間が膨らみ、操作も複雑になります。使われるシステムに必要なのは要望の数ではなく、目的に照らした取捨選択です。

誤解③　「要件定義は短く済ませて、早く開発に入るほうが全体は早く終わる」 要件定義を急いで切り上げると、決めるべきことが開発やテストの段階に持ち越され、手戻りとして返ってきます。手戻りとは、前の工程に戻ってやり直すことです。要件定義の工数を見積もらず、遅れても計画を見直さないことが、全体の遅延の典型的な原因です。

7｜経営判断チェックリスト—今やるべきか否かの判断軸

要件定義への経営関与を優先すべき企業の条件

• 基幹システム（販売・会計・在庫など、事業の中心となるシステム）や業務システムの導入・刷新を、1年以内に予定している
• 過去のシステム導入で、追加費用や、稼働後の大幅な手直しが発生した
• 社内に要件をまとめた経験のある人材がおらず、ベンダーの提案をそのまま採用しがちである
• 導入の目的や効果の指標を、経営層が文書で示していない
• 要件確定後の変更の手続きや、追加要望の可否を決める人が決まっていない

今やるべきかの判断軸

判断の分かれ目は、「目的と指標」「今回やらないこと」「自社側責任者の名前」を、今この場で言えるかどうかです。言えないなら、ベンダーとの打ち合わせより先に社内で決める段階です。必要なのは主に経営者と業務部門の時間で、稼働後の作り直しや追加開発の費用より小さく済みます。

やらない場合のリスク

第一に、目的が曖昧なまま要望が積み上がり、予算と納期を超えるリスクです。第二に、稼働後に現場の業務と合わず、システムが使われないか、手作業での補完が当たり前になるリスクです。第三に、要件の判断がベンダーに偏るリスクです。自社が自分のシステムを説明できず、刷新のたびに同じ依存を繰り返します。

8｜経営者への一言

要件定義は、システムの設計図である前に、経営の意思表示です。次にベンダーと会う前に、「今回やらないこと」を自分の言葉で一行書けるか、確かめてみてください。

参考文献

• 経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月） https://www.meti.go.jp/policy/it_policy/dx/20180907_03.pdf
• 経済産業省「デジタルトランスフォーメーション（DX）」政策ページ（DXレポート2〈2020年12月〉、2.1〈2021年8月〉、2.2〈2022年7月〉を掲載） https://www.meti.go.jp/policy/it_policy/dx/dx.html
• 経済産業省「DXの現在地とレガシーシステム脱却に向けて—レガシーシステムモダン化委員会総括レポート」（2025年5月） https://www.ipa.go.jp/disc/committee/begoj90000002xuk-att/legacy-system-modernization-committee-20250528-report.pdf
• 独立行政法人情報処理推進機構（IPA）「非機能要求グレード」（2018年版、ページ情報は2023年8月時点） https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html