進捗把握のインターバルとスカートの丈は短く

システム開発のプロジェクトに関わったことがあるエンジニアなら、おそらく誰もが一度はプロジェクトの佳境とか作業のピークだとか、トラブルだとか、はたまたデスマとかの経験があると思います。そうした作業量的なピークはプロジェクトの成功やオーバーランの意図での失敗に関わらず内部外部の要因の積み重ねでおきるものです。

計画したとおりの作業のピークでも、避けたかったトラブルでもそういった状況になれば、並行した作業がクリティカルパスに取り込まれていくので一つの作業であっても進捗の関心は高かったりします。そのような状況のときにプロジェクトマネージャは何を現場に求めるかというと計画した完了日時に求める完了の定義を満たすアウトプットされること、です。

では、その要求をただ完了予定の日時まで祈るしか他ないのかといえばそんなことはせずにアクティブに進捗を監視するものです。そのアクティブに進捗を監視するのはどうするのかといえば、関心の度合いに沿ったインターバルで情報を把握する、というものです。

「えっ、それだけなの。」と思ったらそれだけの話なんですけどね。でも、そのインターバルを関心の度合いによって変えるということの意味が分かっている人なら頷くんじゃないかな、と思うんです。

確かに単純な話なんですけど、でも、とても重要な観点だと思うのです。

「えっ、それだけなの。」と思った人は、インターバルを変えることの発想が出来ない人か、インターバルを変えなかったときの実績が期待する完了の定義を満たしていなかったときのリカバリに掛かるリソースを過小評価しているか元々評価のかけらもしていない人としか思えません。

だいたい、そんな計画的若しくは無計画的に諸々と切羽詰っているときに無い時間の中で組み立てた計画を自ら崩していくことはないんじゃないかって思うんですが。

関心の度合いで変化させるインターバルで進捗を監視するときには、実作業で一杯いっぱいの現場に対してそのために負担を掛けないしくみで情報を掌握する工夫が必要です。その工夫をしないでインターバルを変えるだけでは無能と罵られても抗弁するはどうかと。

でも、その工夫をしてリーズナブルな手間とコストで掌握できるなら、プロジェクトの最初からやればいいのに、って思っちゃうんですけど。大体人はやり方を覚えてしまうと変えたがらないです。それをやる人が生理的に受け付けないのでなければ。

そのプロジェクトで学習してそのプロジェクトのお作法として学ぶ機会は、プロジェクトにアサインされジョインしたタイミングです。だったら、一番小さなインターバルをプロジェクトのルールとしてしまえばいいのです。それをプロジェクトが終わるまで変えない。

こうしたお作法の刷り込みをプロジェクト参画時に行い、日々訓練することがとても効いてくるときこそ、作業のピーク時とかトラブルのときなのです。

人はやって身に付けた自信を持っていることしか、イザってときに出来ないのですよ。

進捗把握のインターバルは最短にしておきましょう。