No.122: 進捗の嘘を見抜けるか

「カトウさん、やらかしてしまいましたよ」昔一緒に仕事をしたエンジニアと久し振りに会った時に、開口一番出てきた言葉です。プロジェクトマネージャ(PM)として関わった数ヶ月前の仕事で納期遅延を引き起こしそうになり、最後は睡眠を削りながらの力技でなんとか間に合わせることができたということです。
数々のトラブルを経験してきたエンジニアなので、問題が発覚してからの小出しではなく一気に大きめの手を打って終息させた手腕はさすがでしたが、やはり自分の足元で工程遅延が発生したことに気がつくのが遅れてしまったことにはショックを受けている様でした。
それは10人弱の体制によるソフトウェアの開発プロジェクトでしたが、製作フェーズをオンスケで進んでいたはずが、次の単体テストフェーズに入ってPMがテストケースのレビューをしていたところ、まだ製作できていないモジュールが見つかったというのです。
当該モジュールの担当者は、工程会議の席上で、担当部分は計画通りに進んでいるという報告をしていました。ところが実際は一部のモジュールが出来ておらず工程遅延が発生しており、出来ていない部分は単体テストフェーズの中で挽回しようと考えていたらしいのです。
私は、PMがその担当者と仕事をするのは初めてだったのか聞いてみました。もし初めて仕事をするなら担当者の力量を自分の目でチェックし評価しておくべきであるし、進捗は決して本人の主観的な報告に任せるのではなく客観的、定量的に測定できる仕組みを作り込んでおくべきだったからです。
しかし、PMが言うには、これまで何度か一緒に仕事をしており、力量もわかっていたつもりで、かつ今回の作業では参考にできる既存の成果物があったので難易度も高くはなく、安心して任せてしまった様なのです。
製作工程では、ピアレビューと言ってペアを組んだ担当者と相互にモジュールのコードレビューを行うことになっていました。そのピアレビューは実施されていましたが、出来上がったモジュールは対象になっていたものの、出来上がっていないモジュールがあることは検知できませんでした。
単体テストフェーズに入って、PMがテストケースのレビューを行った時に、この仕様ではこの様なテストケースがあるはずだという観点で確認しようとしたが見つからなかったので、本人に聞いたところそこはまだ出来上がっていないことを白状したわけです。
この段階で見つかったのも、PM自身がエンジニアであるので、自身で単体テストのテストケースまで踏み込んだからであり、たまたまだったかも知れません。
本来であれば、前工程の詳細設計フェーズ時点でソフトウェア構造を確立させ、すべてのモジュールを識別したうえで製作フェーズに進め、いわゆる白地図上でどこまで色塗りが終わっているかを見える化して進捗状況を定量的に管理したいところでした。
それを妥協して、作りながらモジュールを識別していくやり方を認めてしまったのでしょう。そこに今回のトラブルのポテンシャルが隠れていたものと考えます。
やはり、進捗を担当者の報告任せにしていてはいけないと言うことを、あらためて認識させられる事例でした。
あなたのプロジェクト、あなたの組織のプロジェクトでは、担当者が嘘の報告をしてきた時に、それを見抜くことができるでしょうか。担当者の主観によらない、客観的に把握する仕組みを作り込めているでしょうか。是非点検してみてください。
関連提言:No.49: その工程会議は効果的か?

