DX社会の落とし穴、企業の基幹システム開発やリプレースの相次ぐ“失敗”…裁判例から見える失敗の本質

　詳細設計フェーズでは、データベース設計、API仕様、入出力形式など詳細な仕様を固めることとなる。住宅の建築で例えると、「壁の厚さ」「窓のサイズ」「電源コンセントの位置」「床材の種類」など施工に必要となる詳細な図面・仕様を決定して、実施設計図を作成する段階である。

　開発フェーズは、プログラミング、コーディング、各種設定をする段階である。住宅の建築で例えると、大工や職人が基礎工事、大工工事、設備工事など図面通りに建物を建てていく段階である。

　テストフェーズは、単体テスト、結合テスト、総合テスト、ユーザー受入テストなど開発したシステムが予定通りの機能・水準になっているかをテストするフェーズである。住宅の建築で例えると、「ドアや窓は正常に開閉できるか？」「設計図通りになっているか？」を施主や監督がチェックする段階である。

写真を拡大

多くの失敗が起こる工程

　以上のウォーターフォール型の開発手法を踏まえて、文化シヤッター対IBMの事例を見ると、プラットフォームの利用というのは住宅の建築でいえば建売住宅を購入することであり、既製品をベースに内装や間取りを少しカスタマイズする想定でスタートしていたものが、なぜか早々に建売住宅の壁を一度壊して配置を全部変えるなどの大改造を行い、最終的にその大改造に失敗したというものである。

　そのほかのシステム開発に関する裁判例もいくつか分析すると、プロジェクト失敗の傾向が見て取れる。それは、上流工程において失敗の原因が発生し、それが下流工程で顕在化して失敗に至るという点である。

　失敗の原因が下流工程に発生するのであれば手戻りが少なく、まだリカバリーが容易である。例えば最後から二番目の開発フェーズでプログラミングを失敗して、それが次のテストフェーズで発覚したのであれば、一つ前の開発フェーズに戻って修正するだけなので、工期や費用が追加されるとしても限定的となり、何とか完成まで辿り着くことができる。プロジェクトが失敗に終わることは少ない。

　しかしながら、失敗の原因が上流工程に内在すると、そもそもスタートから間違った方向にプロジェクトが進行していたことになるので、それが下流工程で発覚した場合にはもはやリカバリーは容易ではなく、そのシステム開発は失敗する可能性が高まる。

責任の所在

　多くの失敗事例を引き起こす上流工程における原因は、ユーザー側とベンダー側のどちらに責任があるか。

　実際の紛争においては、ユーザー側からは「ベンダーが丁寧に説明してくれなかったから、プロジェクトの方向性や進め方を十分に理解できていない状態で誤った方向にスタートを切ってしまい、我が社のビジネスに合わない/使えないシステムになった」という旨の主張がなされ、ベンダー側からは「ユーザーがプロジェクトで実現したい要望を社内で取りまとめてくれなかったり、着手した後から次から次へと要望を出してきたりして、収拾がつかなくなった」という旨の主張がなされることが多い。

　上流工程においては、ベンダー側として、システム開発に不慣れなユーザーに対して、どのようなシステムが用意されているか、導入候補となるシステムによって何が実現でき何が実現できないか、納期や予算はどれくらいになるかといった点をユーザー側に分かりやすく説明する義務がある。これを裁判例ではプロジェクトマネジメント義務と表現されている。

　他方で、ユーザー側としても、システム開発によって実現したい要望や自らの業態（例えば製造業、コンサル業、金融業など）の特徴を期限内に取りまとめた上で、必ずしもユーザーの業務内容に明るくないベンダーに伝える必要があるし、導入するシステムによって自社の業務フローに変更が生ずる場合には事業部を説得する必要が生ずる。これを裁判例ではユーザーの協力義務と表現されている。