検収の場で「これは依頼した内容と違う」と発注側が言い、「仕様書のとおりに作りました」と受注側が答える。どちらも嘘をついていないのに話が噛み合わない——システム開発の外注で最もよく見る光景です。

そして多くの場合、この対立はプロジェクトの終盤で初めて表面化します。要件定義から数か月、費用の大半を支払った後です。ここから巻き返す手段はほとんどありません。追加予算を出して作り直すか、不満を抱えたまま検収するかの二択になります。

失敗の原因をベンダーの技術力に求めるのは、たいてい間違いです。この記事で扱う7つの理由のうち、6つは発注側の準備と契約の設計に起因します。裏を返せば、契約前の段階でほぼ潰せるということでもあります。本記事では、それぞれの理由について「なぜ起きるのか」「どんな兆候が出るのか」「契約前に何をすれば防げるのか」を整理します。

失敗の責任は発注側と受注側のどちらにあるのか？

技術力の不足が原因であることは少ない

「ベンダー選びを間違えた」という総括は、次回に活かせません。同じベンダーが他社では成功していることが珍しくないからです。実際に差を生んでいるのは、発注側がどこまで決めて渡したか、そして決まっていない部分をどう扱う契約にしたか、という点です。

もちろん受注側に起因する失敗も存在します。体制の破綻、経験のない領域への安請け合い、担当者の離脱。ただしこれらは発注前の確認である程度は見抜けます。体制図と稼働率の提示を求め、類似案件の経験を具体的に聞けば、安請け合いは判別できます。

「決まっていないこと」の扱いが分岐点になる

プロジェクト開始時点で、要件のすべてが決まっていることはまずありません。問題は、決まっていないことがあるという事実ではなく、それをどう扱うかが契約に書かれていないことです。

決まっていない部分について、誰がいつまでに決めるのか、決まらなかった場合はどうするのか、決めた結果として費用や納期が変わる場合の手続きはどうするのか。ここが空白のまま進むと、後から必ず認識の齟齬として噴出します。以下の7つの理由は、いずれもこの空白から派生しています。

理由①：要件が固まらないまま請負契約で発注する

最も多く、最も影響の大きい失敗です。要件が固まっていない状態で「成果物の完成」を約束する契約を結ぶと、要件が動くたびに契約変更の手続きが必要になります。手続きが面倒なため、発注側は「これは仕様の範囲内では」と主張し、受注側は「追加要件です」と応じる。この応酬がプロジェクト全体を通じて続きます。

IPAが公開している「情報システム・モデル取引・契約書」では、工程の性質に応じて契約形態を使い分けることが示されています。要件が動く探索的な工程と、仕様が確定した後の構築工程では、適した契約形態が異なるという考え方です。

対処：要件定義工程を準委任で切り出し、仕様が固まった段階で構築工程を請負で契約する二段構えにしてください。一括請負しか選べない場合は、要件定義の完了を明確なマイルストーンとして設定し、そこで金額の見直しを行える条項を入れておきます。

理由②：意思決定できる人が打ち合わせにいない

担当者が持ち帰って社内調整し、次回に回答する。この往復が2週間かかると、要件定義の期間は現場の想定の3倍に膨らみます。しかもその間、受注側の要員は稼働しているため、費用は発生し続けます。

さらに厄介なのは、持ち帰り先が複数部門にまたがるケースです。営業・情シス・経理がそれぞれ異なる要望を出し、調整の結果として「全部入り」の仕様になる。合議で決めた要件は、ほぼ確実に肥大化します。

対処：スコープの最終決定権を1人に明示的に置いてください。その人が打ち合わせに出席できない場合は、事前に判断基準を委譲しておきます。「関係者全員の合意」を要件確定の条件にすると、確定しません。

理由③：業務の暗黙知が要件定義書に落ちない

現場の業務には、必ず文書化されていない例外処理が存在します。「この取引先のときだけ承認ルートが違う」「月末はこの手順を飛ばす」といった知識です。担当者にとっては当たり前すぎて、聞かれない限り話題に上りません。

これが表面化するのは、たいていテスト工程です。実際の業務データを入れた瞬間に「このパターンが処理できない」と発覚します。設計をやり直せる工程はすでに終わっているため、その場しのぎの対応が積み重なります。

対処：要件定義の段階で、机上のヒアリングだけで済ませないでください。実際の業務を横で観察するか、過去数か月分の実データをベンダーに渡して確認させます。「例外はありますか」と聞くのではなく、実データの中から例外を見つけてもらうほうが確実です。

理由④：検収条件が「動くこと」しか定義されていない

契約書の検収条件が「本件システムが仕様書に定める機能を満たすこと」とだけ書かれているケースは非常に多く見られます。この書き方では、何をもって満たしたと判定するのかが決まっていません。

結果として、検収の場が交渉の場になります。発注側は使い勝手の悪さを理由に検収を渋り、受注側は仕様書に記載がないと反論する。どちらの言い分にも根拠があるため、決着は力関係で決まります。

検収条件として明記すべき項目を、実務でよく問題になる順に挙げます。いずれも契約前に決めておかないと、後から定義することが困難になるものです。

対処：検収条件は契約書ではなく、別紙の判定基準表として作成してください。契約書の条文に書き込もうとすると抽象的になります。表形式で「何を、どう測り、どの値なら合格か」を並べるほうが実効性があります。

理由⑤：変更管理の手続きが決まっていない

プロジェクト期間中に要件が変わること自体は、失敗ではありません。事業環境も法制度も変わるため、むしろ変わらないほうが不自然です。失敗になるのは、変更の手続きが決まっていない場合です。

手続きがないと、変更は口頭やメールで積み上がります。誰も総量を把握していないまま作業が増え、納期直前になって「これでは間に合わない」と判明します。このとき、増えた作業の責任がどちらにあるかを遡って確認する手段がありません。

対処：変更の申請・見積・承認の手続きを、契約時に定義してください。重要なのは手続きの厳格さではなく、変更が発生した事実と、それによる影響（費用・納期）が、その都度可視化されることです。少額の変更まで承認を求めると運用が破綻するため、一定額以下は担当者判断とするなどの閾値も決めておきます。

理由⑥：丸投げにより社内に知識が残らない

「専門ではないので任せます」という姿勢は、短期的には効率的に見えます。しかし完成後、システムの内部構造を知る人が社内に1人もいない状態になります。

この状態の何が問題かというと、次の見積もりが妥当かどうかを判断できなくなることです。小さな改修に高額の見積もりが出ても、それが正当なのか判断する材料がありません。ベンダーを変えようにも、引き継ぎのコストが見積もれないため動けません。結果として、交渉力を失った状態で長期の関係が続きます。

経済産業省の「DXレポート」が指摘した既存システムのブラックボックス化は、まさにこの積み重ねで生じます。IPA「DX白書」でも、内部人材の不在が変革の阻害要因として繰り返し挙げられています。

対処：技術を理解する必要はありませんが、データがどこに何の形で入っているかだけは社内で把握してください。テーブル定義書とデータフロー図を納品物に含め、社内の誰かが説明できる状態にします。これだけで、次の見積もりの妥当性判断と、ベンダー変更時の交渉力が変わります。

理由⑦：本番稼働後の運用体制を決めずに終わる

プロジェクトの計画は検収日で終わっていることが多く、その翌日から誰が何をするのかが決まっていません。障害が起きたとき誰に連絡するのか、軽微な修正は誰が判断するのか、利用者からの問い合わせは誰が受けるのか。

この状態で本番を迎えると、開発を担当した情シスの担当者が事実上の運用窓口になります。本来の業務に加えて問い合わせ対応が乗るため、負荷が高まり、やがて対応が滞ります。システムが使われなくなる原因の相当部分は、機能の不足ではなく運用の不在です。

対処：保守契約の範囲と、社内側の運用担当を、開発の契約と同時に決めてください。とくに「軽微な修正」の定義と、その依頼手順を明文化しておくと、稼働後の摩擦が大幅に減ります。

失敗の兆候はいつ現れるのか？

7つの理由は、それぞれ発現する時期が異なります。厄介なのは、原因が発生する時期と、問題として顕在化する時期が大きくずれることです。契約段階のミスは、半年後のテスト工程で初めて表面化します。

下の表は、原因が仕込まれる工程と、それが問題として現れる工程を対応させたものです。右の列に到達してから対処しようとすると、選択肢が著しく狭まります。

③④⑥は、とくにずれが大きい項目です。③と④は数か月後、⑥にいたっては次のプロジェクトが始まるまで問題として認識されません。だからこそ、同じ失敗が組織内で繰り返されます。

契約前に潰しておくチェックリスト

ここまでの7つの理由を、発注前に確認できる形に整理します。すべて契約書に署名する前に確認できる項目です。着手後に決めようとすると、交渉上の立場が弱くなる点に注意してください。発注してしまえば、こちらには止める以外の手段がなくなります。

12項目のうち、4番と9番はとくに省略されやすく、かつ後から取り返しがつきません。検収基準は着手後に定義しようとすると受注側が同意しませんし、ドキュメントは納品物に含めていなければ追加費用の対象になります。

それでも外注すべき領域はどこか？

ここまで失敗の構造を扱ってきましたが、外注そのものを否定するものではありません。外注が構造的に有利な領域は明確に存在します。

判断の軸は、要件の安定性と、止まったときの許容時間です。会計・給与・人事のように標準化され法改正への追随が必要な領域、可用性が事業継続に直結する処理、決済や暗号のような高度な専門性を要する領域は、外注または既製品が適切です。これらを内製すると、維持のコストが開発のコストを上回ります。

一方、要件が頻繁に変わり、自社固有性が高く、半日止まっても業務が回る領域では、外注の弱点である変更コストの高さが効いてきます。近年は、この領域の一部を内製で賄う選択肢が現実的になりました。背景には、経済産業省の「IT人材需給に関する調査」が示すような人材不足の常態化と、開発ツールの変化があります。

また、外注と内製は二択ではありません。要件の探索は内製で行い、仕様が固まった本番構築を外注する、という組み合わせは実務でよく機能します。この場合も、探索工程で作ったものをそのまま渡せるかどうかで引き継ぎコストが変わるため、使うツールの選定が効いてきます。

よくある質問（FAQ）

Q1. ベンダーの選定を間違えたことが原因ではないのですか？

そのケースもありますが、多くはありません。同じベンダーが他社では成功していることが珍しくないためです。差を生んでいるのは、発注側がどこまで決めて渡したか、決まっていない部分をどう扱う契約にしたかです。

Q2. 打ち合わせで話が進まないときは、何を疑うべきですか？

意思決定できる人が同席しているかです。持ち帰りと社内調整の往復が2週間かかると、要件定義の期間は想定の3倍に膨らみます。その間も受注側の要員は稼働しているため費用は発生します。スコープの最終決定権を1人に置いてください。

Q3. 現場の例外処理はどうすれば拾えますか？

机上のヒアリングでは拾えません。担当者にとって当たり前すぎるため、聞かれない限り話題に上らないからです。「例外はありますか」と聞くのではなく、過去数か月分の実データを渡して例外を見つけてもらうほうが確実です。

Q4. 「専門ではないので任せます」という進め方の何が問題ですか？

完成後に内部構造を知る人が社内にいなくなり、次の見積もりが妥当か判断できなくなります。ベンダー変更も引き継ぎコストが見積もれず動けません。技術の理解までは不要ですが、データがどこに何の形で入っているかは把握してください。

Q5. 納品物には何を含めるべきですか？

最低限、テーブル定義書とデータフロー図を含めてください。納品物に含めていないと、後から取得しようとしたときに追加費用の対象になります。あわせてソースコードの著作権と利用範囲も契約書で明記します。

Q6. 本番稼働後に使われなくなるのはなぜですか？

機能の不足より、運用体制の不在が原因であることが多いです。計画が検収日で終わっていると、翌日から誰が問い合わせを受け、誰が軽微な修正を判断するのかが決まっていません。開発担当者が事実上の窓口になり、負荷で対応が滞ります。

Q7. 失敗の兆候を早く見つけるには？

原因が仕込まれる時期と顕在化する時期が大きくずれる点を意識してください。契約段階のミスはテストや検収の工程で現れます。したがって兆候を探すより、契約前チェックリストで潰すほうが確実です。

Q8. 内製に切り替えれば解決しますか？

領域によります。会計・給与のような標準化された領域や、可用性が事業継続に直結する処理は外注または既製品が適切です。要件が頻繁に変わり自社固有性が高い領域では内製が有利になります。二択ではなく、探索は内製・本番構築は外注という組み合わせも有効です。