[#53] なぜ「システムの発注～導入」には失敗がつきものなのか(2)
初めに
前回[#51]はパッケージ導入の事例を通じて、システム選定の際に見逃しがちなリスクや落とし穴について触れました。今回は、システム再構築における具体的な失敗事例を紹介し、その反省点とともに成功に導くための重要な教訓を共有したいと思います。ビジョン無き開発と仕様不一致が引き金となり、最終的には契約破棄に至ったプロジェクトの教訓。
再構築計画の「曖昧なビジョン」が引き起こした混乱
B社は急激に増大したデータ量と業務の効率化を理由に、システムの全面再構築を決定しました。当初は、システムが過去のテクノロジーに依存しているため、最新技術への移行が急務だと考えられていました。しかし、計画立案時に「新システムで何を実現したいのか？」というビジョンが明確でなかったため、プロジェクトは次第に方向性を失い、遅延と予算超過を、そして最終的には契約破棄を引き起こしました。
パッケージの選定
まず、対象となるパッケージを選定、前提として
・現行業務に近い操作性、運用ができる事
・パッケージで対応できない部分はカスタマイズができる事
・B社と同等クラスの規模で全国的に導入実績がある事
・開発費はもちろん保守を含めて安価に使える事
導入に向けて
約1年間の検討の結果、大手を含めて数社から提案をいただく、コンペの結果、B社の要望を含めた総額内で実績のあるX社に決定をした。
1.当初計画
・2ヶ月で要件整理
・3ヶ月で要件定義書作成(X社)
・5ヶ月で開発
・3ヶ月テスト
・本番
2.プロジェクト体制、進捗管理
・X社は業種知識の薄いPMが仕切る(後に発覚)
・B社は専任内部SEを1名
・B社業務担当者は日々の業務を回しながらの時間内での対応
問題の発端：進捗の遅延と要件漏れ
開始4ヶ月目、X社による要件定義書の作成スピードが急激に遅くなり、次第にB社の期待していた仕様と一致しない箇所が多くなってきました。最初の段階では順調だったものの、徐々に進捗が停滞しました。
要件漏れが発覚：B社からの要件が仕様書に反映されておらず、両社間での認識のズレが拡大していきました。B社が求めていた重要な機能が明確に抜け落ちていたことが、後にプロジェクト全体の大きな障害となりました。
是正処置とSEの交代による期待の裏切り
是正措置を講じるも効果なし：X社は問題を認識し、是正措置を講じましたが、改善の兆しはほとんど見られませんでした。時間だけが過ぎ、進捗は一向に回復しませんでした。
PMの交代：半年が過ぎ、状況が改善しない中で、B社はX社に対しPM-Aの交代を申し入れました。X社はこれを受け入れ、PM-Bが新たに担当することになりました。しかし、ここでも問題が解決するどころか、新たな障害が浮上しました。
担当の離脱：9ケ月が過ぎ、状況が改善しない中で、今度はB社の実務担当が離脱することになり、更なる障害が浮上しました。
新たな障害：パッケージ優先と運用要件の不一致
パッケージ優先の提案：PM-Bは、遅延を取り戻すためにB社の要望に応じるのではなく、提案したパッケージに合わせることを優先し、B社の運用上どうしても譲れない機能については「追加要望・追加費用」として扱おうとしました。これにより、B社はますます不満を抱き、プロジェクトの進行が再び停滞しました。
運用要件とパッケージのギャップ：B社が譲れない仕様要件と、X社の提案するパッケージの仕様との間に大きなギャップがあり、解決の糸口が見つからなくなりました。
延期と合意後も進展せず、最終的に契約破棄
本番稼働の延期：B社は、プロジェクトがこのまま進まないことを見越し、本番稼働の延期を決断。当初予定の半年先をリスケし、X社と合意しました。しかし、延期された半年間も問題は解決せず、双方の溝は一向に埋まることなく、プロジェクトは深刻な停滞を続けました。
最終的な契約破棄：最終的に、双方は全く進展のない状況に疲弊し、契約破棄を選択することとなりました。貴重な時間とリソースが無駄に消費され、プロジェクトは完全に頓挫しました。
今回の事例から言えることは、
1. B社の要件定義の不十分さ — 「業界のプロだから分かるだろう」という誤認識
B社は、システム開発の初期段階で要件定義書をあまりにも抽象的に記述してしまいました。「業界のプロなら詳細な説明がなくても理解できるだろう」との過信が原因です。しかし、システム開発においては、たとえ経験豊富なパートナーであっても、顧客の具体的なニーズや業務フローに関する詳細な情報は必須です。この誤認識が、仕様漏れや要件の不一致を招き、後々の進行に大きな影響を与えました。
2. B社担当SEの業務知識不足 — 実務担当に任せすぎた
B社内の担当SEは、業務プロセスに対する深い理解が不足していました。システム開発においては、技術的な知識だけでなく、業務の詳細を十分に理解することが不可欠です。再構築後の運用イメージも社内では作られておらず、実務担当者に任せきりにしてしまったため、業務の本質を理解せずにシステムの要件を設定してしまい、その結果、B社の本当のニーズが仕様に反映されない事態が発生しました。
3. X社のPMスキル不足 — マネジメントの欠如
X社のプロジェクトマネージャー（PM）のマネジメントスキルが不足していたことも、進行遅延の一因です。プロジェクトの進捗管理やリソース調整、問題発生時の対応が十分ではなく、問題が悪化するまで対策が取られませんでした。途中交代は行われましたが後を引き継いだプロジェクトマネージャーは、進捗を進める為に強引に運用を無視したパッケージへの誘導、PMは顧客とのコミュニケーションを密に取り、進行状況をリアルタイムで把握し、問題が小さなうちに解決する能力が求められます。X社のPMがこの役割を果たせなかったことが、プロジェクト全体の遅延に繋がりました。
4. 無理なスケジュール設定 — 業務の複雑さと時間的余裕の欠如
最初に設定されたスケジュールが非常にタイトで、業務の複雑さを反映した現実的なものではありませんでした。システム開発には時間がかかり、特に要件定義や調整には余裕を持つ必要があります。しかし、無理なスケジュールの中でプロジェクトを進めようとしたため、途中で調整が必要な場面が多く、全体の進行に遅れが生じました。スケジュールに対する現実的な見積もりがなされていなかったことが、最終的な破綻に繋がったと言えるでしょう。
5. B社の業務責任者不在 — 最終的な調整・決断を担う人材の欠如
B社にはプロジェクト全体を取り仕切り、最終的な決定を行う業務責任が不在でした。業務の最終責任を持つ人物がいなかったため、仕様変更や要件の優先順位に関する最終判断が遅れ、プロジェクトが混乱しました。特に複雑なシステム開発においては、最終的な意思決定を行うリーダーが必要不可欠であり、業務の進行における舵取り役がいなかったことが、プロジェクトの停滞を招いた要因です。
今回のプロジェクトの失敗から学べることは、システム開発においては「明確な要件定義」「業務知識の深堀り」「適切なプロジェクトマネジメント」「現実的なスケジュール設定」「業務責任者の存在」が不可欠であるということです。これらの要素が欠けていると、どんなに優れた技術やパートナーがあっても、プロジェクトは破綻するリスクを抱えることになります。
まとめ
システム再構築の成功に必要なのは、単なる技術的なアップデートではなく、ビジネスゴールを明確に定義した上で、現行システムが抱える具体的な課題を洗い出し、解決策を見出すことです。「ただの刷新」ではなく、企業の成長戦略を支えるために何を変えるべきかを、最初に徹底的に議論することが重要です。今回の事例に類似したケースは経験上数多く存在し、仮に稼働できたとしても追加費用の支払い、納期の大幅遅延、損害補償のケースもありました。最悪の場合は契約破棄、裁判、損害賠償などのケースも見受けられました。私の経験として「失敗の場合ユーザの力量不足」と断言できる場合が多いですが、今回は少なくてもベンダー側の対応にも問題があったケースでは無いでしょうか。
最後までお読みいただきありがとうございました、今回は再構築の難しさの事例でした。一つでも多くのプロジェクトが成功しベンダー、ユーザ共にWin Winになれる事を願っています。
次回も別の事例を紹介したいと思います。
備考
日本通運が基幹システムの開発失敗を巡り、アクセンチュアを提訴した。日本通運によると、プロジェクトの遅延に加え、検収では大量の不具合が発覚。開発の中止を余儀なくされたのは、アクセンチュアの債務不履行と主張している。アクセンチュアは真っ向から反論し、成果物の検収など至るところで対立する。