①紛争防止と紛争解決の間

紛争化しつつある開発プロジェクトの立直しのために開発工程管理支援を行った事例です。

 事案   中堅商社であるA社は、3年後の上場をにらんで、基幹系システムの再構築をシステムベンダのB社に委託しました。しかし、外部設計の途中で、機能の漏れや齟齬が多数見つかりました。A社はクレームを出したところ、逆にB社から、漏れや齟齬が出たのはA社が要件定義を無視した要望を多数出したからで、このままでは8500万円の開発費用を2億円にしないと作業を継続できない、という通知を受けました。両社は何度か互いの意見をぶつけ合いましたが、結局、交渉は平行線のまま、開発は事実上中断となりました。A社は、B社の対応に不満を持ったものの、要件定義までは満足のいく形で終わっており、また、この段階でベンダを代えて一から開発をやり直していては、上場準備に間に合わないため、開発再開を前提とする工程管理をITSに依頼しました。

 解決  ITSは、A社のメンバーと共にB社との交渉に臨み、共同検証による開発内容・規模の検証を提案しました。これに応じたB社から要件定義との差異の明細を提示してもらい、実務ベースの検証作業を経て、機能の追加・変更、工数評価の差異、当初の見積漏れに分類し、双方合意しました。そして、最終的に、一部機能の将来フェーズへの先送りを前提に、見直し後の総開発費を9000万円として開発を再開しました。また、検証作業の中で、A社側には体制の薄さ、B社側にも今回初めて用いる開発手法のリスクなど、なお解消されないトラブルの種があることが判明したため、再開後も、リリースまでITSが継続的にプロジェクトに加わり、プロジェクト管理を支援しました。

 ポイント  ユーザから見ればベンダ側の要求仕様の誤解・無理解、ベンダから見ればユーザ側の要求仕様の混乱・変節、というのは典型的なトラブル状態の構図です。そして、これは品質の低下と共に、開発費用の上ブレという形で現れ、調整の限度を超えると、本件のような開発中断にまで至ります。上ブレの原因は、ベンダ側では見積の甘さ、ユーザ側では過度な機能の要求、といったことも挙げられますが、その根本には、要件定義レベルで合意したはずのシステムの範囲・内容についての、ユーザの理解とベンダの理解との大きなギャップがあります。本来は、プロジェクト内のコミュニケーションによりそのギャップの発生を抑え、あるいは埋めるべきですが、本件では、共同検証によってようやくそれが実現されたわけです。

※ この事例は説明用のもので、実際の事件とは一切関係がありません。