なぜITアウトソーシングプロジェクトの70%が失敗するのか？
- 課題: 多くの外注ITプロジェクトは技術ではなく、関係者間で責任が分断されることで失敗する。
- 解決策: 3つの断絶——伝達の三角形、「仕様どおり」の罠、エンドツーエンドの責任の欠如——をたどる。
- 成果: 解決策は、全体を通して結果に責任を持つ「Single Point of Accountability」を置くこと。
非常に安い価格で外部の開発チーム（オフショア）にシステム構築を依頼し、キックオフミーティングでは全てが完璧だったにもかかわらず、納品された製品を見て**「これは私が求めていたものではない！」**と頭を抱えた経験はありませんか？
もしあるとすれば、あなただけではありません。業界のレポート（Standish GroupのCHAOSレポートやMcKinseyの調査など）によると、アウトソーシングされたソフトウェアプロジェクトの70％近くが、納期の遅延、予算超過、あるいは実際のビジネスで全く使い物にならないといった深刻な問題に直面しています。
私はデリバリーマネージャーおよび日越市場のBrSE（ブリッジSE）として14年間、数え切れないほどの失敗プロジェクトを見てきました。この記事では、コードの品質ではなく、オフショア開発プロジェクトのサイレントキラーである**「責任の断絶（Broken Accountability）」**についてお話しします。
読み進める前に： 失敗は、根本的な判断 — そもそも作る必要があるのか？ — から始まることがあります。迷っている方は、まずSaaSか、カスタム開発か？Build vs Buy判断フレームワークをお読みください。
TL;DR (Executive Summary)
- 課題： ITアウトソーシングプロジェクトの多くが失敗する原因は、技術力の不足ではなく、要件伝達プロセスにおける関係者間の責任の断絶にあります。
- 解決策： 伝達のトライアングル（顧客 - 営業 - BA - 開発者）、「仕様通りに作るだけ」の罠、そしてエンドツーエンドの責任（Accountability）の欠如という3つの根本的な断絶ポイントを特定することです。
- 結果： これを克服するためには、技術的なソリューションがプロジェクト全体を通してビジネス目標と一致することを保証する「Single Point of Accountability（単一の責任窓口）」を確立する必要があります。
1. 伝言ゲームの悲劇： 顧客 → 営業 → BA → 開発者
従来のシステム開発会社の典型的なワークフローは次のようになります。
- あなたは営業担当者と話します（彼らは話術に長けており、何でもできると約束します）。
- 営業担当者は、その情報を**BA（ビジネスアナリスト）**に伝えます。
- BAは設計書を作成し、それを開発チーム（コードを書くことしか知らない人々）に丸投げします。
ここで何が問題なのでしょうか？ いわゆる「伝言ゲーム」です。 コードを書く人間は、あなたのビジネスの目的を理解していません。ビジネス側（あなた）は、技術的な問題を解決する担当者と直接話す機会がありません。その結果、「設計書通り」に作られてはいるものの、実際の業務ロジックとしては完全に破綻しているシステムが出来上がります。（社内システムにおける属人化の罠からの脱却方法についても合わせてご覧ください）。日越のオフショア開発では、この伝言ゲームは文化差によってさらに増幅されます——詳しくはなぜ「日本品質」はベトナムオフショアでそのまま再現されないのかで分析しています。
2. 「課題を解決する」のではなく「言われた通りに作る」という罠
従来のアウトソーシングモデル（特にオフショア開発）では、通常「人月（Man-month）」単位で費用が計算されます。彼らの鉄則は、**「顧客の言う通りに作り、余計なことはせず、絶対に反論しないこと」**です。
これは一見従順で良いように聞こえますが、あなたのプロジェクトを確実に死に至らしめます。 なぜなら、あなたは自分の業界の専門家であって、ソフトウェアエンジニアリングの専門家ではないからです。あなたが要求したもの（例：「倉庫データを分析するAIシステムが欲しい」）が、実際に必要なもの（例：「毎朝スプレッドシートからLINEにデータを通知するシンプルなAI自動化ツールだけで十分」）であるとは限りません。
優秀なデリバリーマネージャーは、顧客の要求に対して**「No」**と言える勇気を持ち、ビジネス目標を100%達成できる、よりシンプルで安価な代替案を提案しなければなりません。残念ながら、多くの開発会社は売上を伸ばすために、複雑な要求にもただ頷く傾向があります。
3. 「End-to-End」で責任を持つ人間が誰もいない
これが最大の失敗要因です。プロジェクトが失敗したとき、何が起こるでしょうか。
- 開発者は「BAの要件定義が不明確だった」と責めます。
- BAは「営業が顧客に過剰な約束をした」と責めます。
- 営業は「顧客が仕様を頻繁に変更した」と責めます。
プロジェクトにおいて、**「誰の責任であろうと、このソフトウェアが企業の売上向上に貢献することに対して、最終的な責任（Accountability）は私が負う」**と机を叩いて断言できる人間が「たった一人」もいない場合、そのプロジェクトは極めてリスキーです。「作業の責任（Responsibility）」と「結果に対する責任（Accountability）」には天と地ほどの差があります。
解決策：「Single Point of Accountability（一人の絶対的な責任者）」を求める
バラバラの10人のチームをプロジェクトに押し込む代わりに、中小企業（SME）のプロジェクトで最も効果的なモデルは、フルスタック・デリバリーコンサルタントを見つけることです。
- あなたと一緒にビジネスモデルを徹底的に分析できる人。
- 自らシステムアーキテクチャを描ける人。
- 最も重要なコードを自ら書く（あるいは厳密にレビューする）人。
- そして、システムに障害が発生したときに、あなたが唯一、胸ぐらを掴める（全責任を負う）人。
頭数（エンジニアの人数）を買うのではなく、結果へのコミットメントを買ってください。
日越オフショアでは、この役割はBrSEに期待されがちですが、すべてのBrSEが担えるわけではありません——ブリッジSE（BrSE）とは何者か？「ITに強い通訳」と何が違うのかで4段階に分類しました。ベンダー選定の段階にいる方は、契約前にベトナムオフショア開発会社の5つの評価軸をご活用いただくか、あるいはプロジェクト複雑度を自己見積もりして正確なRFP/RFQを作成してください。
もし現在、高額なITシステムを導入したもののROI（費用対効果）が見合っていないとお悩みの場合や、現在のプロジェクトが行き詰まりローンチの目処が立っていない場合は、お気軽に課題を共有してください。専門領域と時間的余裕に合う案件であればご返信いたします。
よくある質問
なぜ外注ITプロジェクトは失敗しやすいのですか？
根本原因は技術ではなく、要件が顧客→営業→BA→開発へと渡る過程で責任が分断されることです。各受け渡しで少しずつズレ、最終的に誰もエンドツーエンドの結果に責任を持ちません。
「Single Point of Accountability」とは何ですか？
事業課題の理解から動く解決策まで、最終成果に責任を持つ単一の人または役割です。この役割が受け渡しをつなぎ、「仕様どおりだが課題は解けていない」状態を防ぎます。