要件定義がなかなか完了せずスケジュール遅延、そしてプロジェクトは大混乱【プロジェクトの失敗談】

2022年2月9日

要件定義に失敗するとどうなるのか？

ソフトウェア開発プロジェクトが失敗する理由はさまざまありますが、『ソフトウエア開発 55の真実と10のウソ』では、不正確な見積りと仕様を固められないことがプロジェクト失敗の二大要因だとしています[1]ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年、42頁。。
仕様は要件定義のプロセスで固めていきますが、要件定義のマネジメントに失敗するとどうなるのでしょうか？
今回はプロマペディアに寄せられた失敗談を読み、その教訓を考えていきましょう。

失敗談

このプロジェクトはとある企業の工事件名管理システムの新規構築案件でした。
件名の発生、契約、納入、完了までを幅広く管理しなければならず、大規模プロジェクトであり、複数のサブシステムに分けて管理していました。

プロジェクトの最初の工程であるシステムの要件定義は、クライアントの担当者が、実際にシステムを使う予定のユーザー部門に確認しながら実施するという話でした。

ユーザー部門が更に実際にシステムを利用するユーザーに要件を確認するという風に多段階の確認が必要であったため、思うように進まず、進捗に遅れが目立つようになってきました。
何度もクライアントの担当者にこのままではスケジュールに遅れが出てしまうことについてアラートを上げ続けましたが、一向に仕様は決まらず、クライアント側の責任者にも問題をエスカレーションしましたが、責任者から担当者に「早く要件を決めるように」と依頼があるだけで、状況はほとんど変わりませんでした。
私も説明資料作成等で面倒になることが懸念されたので、自身の上司にこの状況を報告しませんでした。

要件が一向に決まらないまま時間だけが過ぎてゆき、元々の開発開始予定日になってもほとんどの要件が決まりませんでした。
開発開始予定日から要員をアサインしていたので、仕様が決定していた一部のみの開発は開始出来たものの、アサインした要員のうちほとんどが開発に着手出来ず、無駄に時間が過ぎていきました。
　
この時点でもう隠しようがないと観念し、上司をはじめ社内のメンバーに相談しました。当然ながら周囲には叱られ、その後何とか要件定義を終わらせ、開発工程では地獄のリカバリ作業が待っていました。
マネジメントと仕様決めを私が兼任していたため、顧客との仕様決め打合せや定例会準備、要員の受け入れなどを１人でやらなければなりませんでした。進捗遅れが発生したプロジェクトの定例会が揉めないはずもなく、様々な資料を作成し、顧客に怒られたり、開発要員からの質問攻めにあったりと、心身ともに疲弊していきました。

プロジェクトの状況が非常に苦しいことを開発チームにも伝え、リカバリのため開発要員に休日出勤を依頼しましたが、「嫌ですよ」と冷たく断られた時が一番辛かったです。
　
結果として要員の追加や連日の長時間残業、休日や正月休みも返上して何とか無理やり開発フェーズを完了させたものの、プロジェクトは大赤字を計上してしまい失敗プロジェクトの戦犯として社内でも責められ、失敗の原因についての報告なども必要になるなど、散々なプロジェクトとなってしまいました。

失敗からの教訓

今回の失敗談からは様々な教訓が得られますが、ポイントは以下の２点にまとめられます。

  • 進捗が思わしくない場合の対処法
  • 問題の報告のタイミング

今回プロジェクトが座礁した原因は、クライアントが要件定義を進められなかったことにありますが、こうしたことはプロジェクトにはありがちです。ソフトウェア開発の専門家がいるベンダー側に比べ、そのクライアントである発注者側には専門家がいないことは多く、そのため「要件定義」といっても、どのように進めるかわからずに時間が過ぎてしまうことがあります。
そのため、進捗が思わしくない場合の対応をベンダー側である程度想定し、準備しておくことが大切です。
今回の失敗談でいえば、クライアント側のタスクではあるものの、要件定義の会議の場にベンダー側の人間も参加してサポートしたり、遅延の対応をベンダー側・発注側の責任者を含めて話し合ったりすると、トラブルの被害は最小限に抑えられたかもしれません。
こうしたトラブル発生時の対応を考えるステアリングコミッティをあらかじめ設立してもよいでしょう（ステアリングコミッティについては、下記の記事もご参照ください）。

今回は遅延が見られたあとのチームや上司への報告も遅れてしまっています。その理由は、「説明資料作成等で面倒になることが懸念された」というものでした。プロジェクトの進捗が悪くなると、悪い報告を上司やチームにするのも億劫になってしまいますが、誠実に対応しないとさらに大きなトラブルになるというのは、今回の失敗談で見てきたとおりです。
PMBOK第７版では、チームのパフォーマンスを高める文化の１つに「誠実さ」を挙げていますが、トラブルが起きたり、その発生が予想されたりした時に、誠実に対応することが肝心です。
こうしたチームの文化については下記の記事で解説していますので、ぜひご覧ください。

プロジェクトは一度大きなスケジュール遅延が発生すると、その後の対応は難しく、待っているのはデス・マーチになってしまいます。

ここまでの話をまとめると、教訓としては以下の３点が挙げられるでしょう。

  • あらかじめ進捗が悪い場合の対応を考えておく
  • 問題を隠そうとせず、誠実に周囲に状況を報告する
  • 一度プロジェクトに大きな遅延が発生すると、デス・マーチが待っている

繰り返しになりますが、今回の失敗談はソフトウェア開発にはありがちな話です。心当たりのあるプロジェクトのチーム・メンバーになったら、上の教訓を参考にしてみてください。

注

注
↑1ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年、42頁。

トラブルトラブル,要件定義

Posted by promapedia