効率

「レビューってのも、考え物だな。」
ある工程の終了が近づくと、成果物のレビューを実施するのが一般的だと思う。あれ、無駄ぢゃないかと思うのだ。なぜならば、レビューで問題が発覚しても「時、既に遅し」だからだ。レビューを実施して何ができるかと言えば、体裁を整えて、期日に間に合ったかのように誤魔化すことぐらいだろう。どうせ、本質的な問題は次の工程に先送りすることになる。レビューで誤魔化してしまったものだから、次の工程では絶対にゆとりがなくなる。それを無自覚でやっている場合と、自覚してやっている場合があるけれど、結果は同じなので気にしない。

もともとゆとりのあるスケジュールなんて書いてない (誰だ? 一人 200 時間労働で予定を書いてるのは!) のだから、レビューを実施して問題があったとしても有効な手段は何も打てない。いったい、何のためにレビューをしているのだ?

後ろの予定は詰まっているなら、問題を先送りしたら必ずシステム開発は遅れる。とすると、問題の繰越はご法度なのだ。もちろん、うまくバッファをとって進めているなら、問題修復時間は確保しているだろうから、とやかく言うことはない。そんなシステム開発に遭遇したことはないけれど…。

後ろにはずらせないから、逆から考えてみる。

レビューで問題が発覚する可能性は十分にある。無ければレビューなんて必要ないからね。期日の 1 日前にレビューをしたとする。対策に使える時間は 1 日だけだ。と云うことは、対策に 1 日を超える時間が必要な問題を発見してはいけないってことになる。二日前なら二日分、三日前なら三日分、四日前なら四日分…といくらでも言えるのだけれど、どんな問題が見つかるかなんて、レビューを実施してみないと分からない。四日分の問題だけを発見するように…なんて調整は無理だし、もしそれが可能だとしても、問題の先送りはご法度なのだから、五日分の問題を誤魔化すわけにはいかない。

結局、ずーっと遡って、開始直後から毎日レビューを行うしかないのだ。もし、それで日数が足りないなんてことなら、そもそもスケジュールがおかしいので、あり得ないってことになる。論理的に組み立てるならね。

レビューって言っても、大きな会議室で偉いさんと一緒に何時間もやるやつぢゃぁダメだ。まあ、偉いさんも毎日付き合ってられないだろうけど。あくまでもプロジェクトを実際に実行している人が担当者の成果物を実際に目で見ることが大事だってこと。特に書式よりも内容。それによって問題を早期発見するのだ。

初日で問題が見つかれば、修復時間はたっぷりとある。でも、期日数日前になって、「こんな状況ぢゃぁ、先に進めないぢゃないか…」なんて事が分かっても、時間は取り戻せない。未来は動かせるけど、過去は動かせない。過去の責任を追及するレビューなんてやめて、未来を動かすために果たさなければならない今の責任の話をしようぢゃないか。

…後の祭りになる前に…。