KATOエンジニヤリング開発日誌

「アウトプット無きエンジニアにインプットもチャンスも無い」の精神で書いています

プロジェクトの事例研究 - トラブル事例研究 -

前回の予告通りに実際に起きたITプロジェクトのトラブル事例から反省点を学び取ります。

www.kato-eng.info

役割分担・PJ推進体制に問題があった事例

ユーザは大手旅行代理店で、宿泊予約等を行うHR(Hotel Reservation)システムの再構築を行うプロジェクト。複数ベンダを比較した結果あるシステム開発ベンダへ発注することとなった。

経緯

基本合意書及び基本契約書、要件定義・基本設計・詳細設計に係る請負契約を締結し、プロジェクトが開始されたが、スケジュールが大幅に遅延したためプロジェクト推進体制などを見直したが、費用が当初の見積額を大きく超えたのと稼働時期が1年以上の延伸となるため、ユーザは作業中止を求め、後に契約を解除した。

その後、プロジェクトの失敗の責任や開発費用の支払いを巡って交渉を続けたが折り合いがつかず訴訟に至った。

争点と各々の主張

要件定義・基本設計等の完成が遅延した原因がどちらにあったかが争点となった。

ユーザ側の主張

ユーザ側の主張としては、基本合意書で開発費用の総額を約束しており、開発範囲が増加していないにもかかわらず、大幅な費用の増加や稼働日の延伸は納得できない。ベンダがユーザの業務やHRシステムを理解するのに時間が掛かったこと、またベンダが進捗の遅れを取り戻すべく体制を代えたために新たな担当者へ説明を行う手間が増えたために開発作業が遅延したと言っている。

ベンダ側の主張

それに対するベンダの主張としては、基本合意書は金額とスケジュールの変更が前提のもので、個別契約が優先する。ユーザ側における業務要件やHRシステムを伝える担当者の不足及び、担当者のスキルにも問題があったことによる要件提示の遅延に加え、度重なる要件変更と開発範囲の増加が作業遅延の主な原因であると主張した。

反省点とトラブルを未然に防ぐポイント

原因としては要件定義・基本設計段階におけるベンダとユーザの共同作業が不十分であった点にあると考えられる。

ユーザ側はユーザの業務やHRシステム等を説明するプロジェクト要因の不足や、プロジェクトマネージャの監視に問題があったといえる。
ベンダ側は開発作業の進捗状況について見通しが甘く、プロジェクト推進体制を急遽変更し、そのことが更なる作業遅延を招く結果になり、対応に問題があったといえる。

この件での個別契約は請負契約として締結されていたが、要件定義はあくまでユーザの業務であるから、ユーザはベンダに要件を詳細に提示する必要があるが、ベンダもシステム開発の専門家として十分な支援体制のもとで業務を行うべきであった。

要件定義作業に入るまでに、要件定義段階でのユーザとベンダの役割について明確にしておけばトラブルを未然に防ぐことができたと思われる。また、連絡協議会を開催し、進捗状況を両者が常に共有することで、開発作業の遅延の原因を早期に発見し、修正することが可能だったと思われる。

役割分担が不明確だった事例

ユーザは放送会社であり、最初にコンサルテーション会社に依頼して要件定義と基本設計を行った。この段階でベンダが本システム開発を受託した。

経緯

ベンダが受託後、ベンダとユーザは「開発要素設計書(一般でいう基本設計書に該当)」の作成作業に取り組んだ。その際にコンサル会社が作成した基本設計の内容を参照しながらベンダが開発すべき項目を決めていった。しかし開発要素設計書においては全ての要件を決めることができなかった。このことが原因でシステム開発が大幅に遅延し、ユーザが契約を解除する事態になった。

争点と各々の主張

システム開発が大幅に遅延したのはどちらのユーザとベンダのどちらの責任になるかが争点となった。

ユーザ側の主張

ユーザの主張としては、未決案件が多いとベンダが言っているが大規模なシステムなのである程度の未決案件があるのは当然であり、それを詰めていくのがベンダの責任であるとした。

ベンダ側の主張

ベンダ側は未決案件が数十件あったのが遅延の原因であるとした。ベンダとしては契約に関する成果物は納めており債務不履行は無いと主張した。

反省点とトラブルを未然に防ぐポイント

この件では「開発要素設計書」の作成が行われているが、名称からではその位置付けが明確でない。例えば要件定義レベルであればその旨を記載するべきである。そもそも用語については「共通フレーム2013」を参照して明確な定義があるものを用いるべきであった。

また、「開発要素設計書」作成の完成基準や、ユーザとベンダの役割分担が明確になっていなかったために大量の未決案件項目が残り、システム開発の実行を大きく遅延させたものと思われる。

先行契約の成果物の問題点に対処するための条項を明確にしておくことも必要であった。モデル契約書では多段階契約を基本としており、各作業段階における業務内容や完成基準を明確にして各当事者の義務を示す。
要件定義に関わる各作業項目についてユーザとベンダとの間の役割分担や作業内容を明確にしておくべきだった。また、業務終了の確認内容についても事前に双方が確認しておくことにより、作業完了についての共通認識を高めることができる。

次回予告

次回はプロジェクトマネージャに求められるスキルと教訓の残し方について書きます。