はじめに
システム開発の失敗は、単なるコストの浪費にとどまらず、企業の信頼性や事業運営に多大な影響を及ぼします。最近、日本通運がアクセンチュアに124億円の損害賠償を求めた裁判が注目されています。この記事では、この事例を含めた失敗事例を通じて、システム開発失敗の要因や回避策を探ります。また、過去の裁判事例や失敗原因についても深掘りし、プロジェクトを成功に導くポイントを解説します。
1. システム開発失敗事例の概要
日本通運とアクセンチュアの訴訟 (2023年)
https://www.nikkei.com/article/DGXZQOUC033FV0T01C24A0000000
- プロジェクト内容: 国際航空貨物の基幹システム統合プロジェクト。
- 規模: 総額123億円以上、開発期間3年4ヶ月の大型案件。
- 問題点:
- アクセンチュア側は「契約は完了した」と主張。
- 日本通運側は「品質面で問題があり、契約未達」と反論。
- 検収プロセスの曖昧さが主要な争点に。
その他の失敗事例
- 江崎グリコのシステム更改失敗: サプライチェーンが停止し、「プッチンプリン」が出荷不能に。
- 野村證券 vs IBM: 投資一任口座システムの開発が遅延し、品質リスクを巡り36億円の訴訟に発展。
開発会社はなるべく即座に検収してほしいものですが、事業会社さんのほうが得てして、業務に関する知見も広く、納品されたシステムに対する改善案・現場にどれほど落とし込めるかの鋭い感覚をお持ちの場合が多いです。総合コンサルといえでも顧客のビジネスの理解を怠ったのであれば、それは法的手段を行使されても仕方ないでしょう。
2. システム開発失敗の主な要因
1. 要件定義の曖昧さ
- プロジェクト開始時に「何を作るのか」が具体化されていないと、途中で仕様変更が頻発することがあります。
- 作業スコープ（どこまでを開発するのか）と納期を温度感ふくめてしっかりと明瞭に合意をとっておくのが重要です。
2. コミュニケーション不足
- ベンダーと顧客間の連携が不足。例えば、仕様変更や進捗報告が適切に行われないケースもあります。
- 開示すべき情報が開示されていない場合や、多重下請けによるステイクホルダーの増加によって、報告ばかり重なって実務に入れないプロジェクトも散見されるようです。
3. プロジェクト管理能力の不足
- 特に大規模案件では、適切なスケジュール管理やリスク管理が欠如すると失敗に繋がることが多いです。
- 技術的に複雑・込み入った案件の場合、研究開発・PoC開発がいつになるのか読めずにプロジェクト全体のスケジュールに響いてしまうこともまれに発生します。
4. 契約内容の認識のズレ
- 請負契約では「仕事の完成」が求められるが、検収手続きが独立している場合、認識の違いが裁判沙汰に発展することも。
- 準委任契約の場合、工期がいつまでに完了するのか、と実際の完了時期のズレによってクライアントとの言い争いに発展することも。
システム開発では、長期化すればするほど、案件が巨大化すればするほど、見積もりとは全くことなった状況になってしまうことが非常に多いです。基本的には１年を超えて納品されない案件は長期に渡るものではございますので、いくばくかのリスクを念頭にいれて発注を考えるべきです。また、準委任契約（時間単価での精算）であっても、ある程度は完成責任を問うことも可能なケースも多いですので、しっかりと外注する範囲を定義しておくのが重要かと思われます。
3. 成功への鍵: 過去の失敗から学ぶ
一口でいうと簡単に見えますが、エンタープライズレベル・中規模・小規模レベルの開発プロジェクトはもちろん全く難易度が異なりますので、注意が必要です。なるべく、カウンターパート・ステイクホルダーを減らし、不要なコミュニケーションパイプラインを削り、予算を直接開発関連費用として燃やし続ける体制構築ができるのかがプロジェクト管理者に求められていると感じます。
| 要因 | 失敗事例の教訓 | 成功するためのポイント |
|---|---|---|
| 要件定義の曖昧さ | 日本通運 vs アクセンチュア | 仕様を具体化し、仕様凍結を厳格に管理する。 |
| コミュニケーション不足 | 江崎グリコの出荷停止 | 定期的なミーティングと文書化された進捗報告を徹底する。 |
| プロジェクト管理の不足 | 野村證券 vs IBM | プロジェクトマネージャーを設置し、進捗・リスク管理を実施。 |
| 契約の曖昧さ | 多くの訴訟事例で見られる共通の問題点 | 契約書を詳細化し、検収基準を明確に設定する。 |
4. 開発会社の意見
大規模プロジェクトで海外の大手コンサルを起用することは一般的ですが、近年では国内企業への回帰の流れも見られます。背景には、「海外ベンダー特有のリスク」を避ける意図があります。また、アジャイル開発の普及により、段階的な納品やプロジェクトの柔軟性が重要視されています。
私が公共系プロジェクトやエンタープライズ系受託開発プロジェクトを見ていて、開発を実施する会社にもう少し権限およびプロジェクト管理を任せてしまってもよいのでは？とよく思います。プロジェクト管理はどこまでいっても管理ですから、ステイクホルダーへの進捗を知らせるまでしかできませんが、手を動かすエンジニアしか最終的には動くプロダクトを作ることができないのです。あくまで職人である彼らに効率よく働いてもらうための座組をつくることが肝要でしょう。
まとめ
システム開発は、多くのリスクを伴う複雑なプロジェクトです。しかし、過去の失敗事例から学び、適切な管理や明確な契約を行うことで、成功の確率を大きく高めることができます。プロジェクトの初期段階で慎重に計画を立て、ベンダーと顧客が緊密に連携することが成功の鍵です。
