攻撃的な進捗管理 - 室長のひとりごち

なんとも挑戦的なタイトルではありませんか。だって、“攻撃的”な進捗管理ですよ。看板倒れの感がなきにしもあらず、ですけど。
進捗管理としていますが、ここでの進捗管理という言葉の選択の意図には、プロジェクトを、進め方のシナリオに基づいて進めるその立ち向かう姿勢に纏わる全般を込めています。計画に対する出来高を上げるための方策や管理のための管理は棚に上げています。

防衛前線異常だらけ
ワタシが見積もりレビューやプロジェクト計画レビューで重きを置くレビューポイントの一つに

“プロジェクトの進め方”が描けているか

というものがあります。成果物であるdeliverableを期限までに確実に届けるために、どういった手順や役割分担の中で顧客とプロジェクトチームが振舞うか、という云わば脚本に当たるものです。

十分プロジェクトの進め方が描けていないデスマのフラグが立っているプロジェクトにハダカ突撃する輩は、ここが描けていないから目の前に飛び込んでくる、−すでに受身です−、物事をこなすことをはじめてしまうものです。
プロジェクトの進め方が描けていないままプロジェクトをキックオフしてしまい、手探りのままに“それが今優先順位が高いかどうか判別つかないけれど”目の前にあるので手をつける。それに手をつけてしまったものだからそれから生じる課題や宿題に追われ始めてしまう。

本当なら、先々を見廻してその工程で片付けて、次の工程のインプットとして仕上げておかなければならないのに。
本来その工程で必要な振る舞いをしなければならないことをしないということは、“不作為”という言葉以外当てはまりません。それは次工程に大きな負債を付回すだけだからです。

進め方の脚本が先々までとは求めないけれど、工程単位での進め方の思想やポリシーは必ず必要なものです。これを「時間がない」だとか「忙しい」というそれこそ怠慢な言い訳でプロジェクトが自爆するリスクを高める原因をつくるようなエンジニアが居るとするならば、最前線に自ら突撃して帰ってくるな、と言いたい。
＃言っちゃいましたが。

この状態は放置できないし、してはいけません。例え、そのプロジェクトと直接関係していなくても、組織の一員であるなら、そのような状態を知ってしまったら、直接的に関与できなくても自ら誰かを動かさなければなりません。

常に攻撃せよ
攻撃せよ、と言っても顧客と対立したり、プロジェクトチームの中を殺伐とさせよう、というわけではありません。

プロジェクトの計画は、アジャイルにしろ、ウォーターフォールにしろ、辿り着くゴールの姿に向かって何らかしか、先を見通した計画を作るものです。その辿り着く先のゴールをいつも、プロジェクトマネージャ自身、そして、プロジェクトチームメンバ全員と、それこそ毎日それであることを意識して目指さなくてはなりません。
ところが、そのゴールに辿り着くために、それを達成するための計画をそれこそ真摯に進めようとしても、その計画を構成する一つひとつのヒト・モノ・カネ・時間が勝手に変わっていきます。

そう、プロジェクトを構成する要素は、刻々と変わってしまうということを意識しておかなければなりません。

プロジェクトを構成する要素は変わるものだ。だから、プロジェクトを実行ベースに移したら、計画に対する出来高の出来具合が予定とおりか差異を現場で掴むのです。で、やっぱり、少しずつずれているという事実を掴みます。

そのずれていく事実を受け止めたときに、無理やり計画に事実をあわせるようなことはせず、プロジェクトの計画自身を有機的に変化させるのです。プロジェクトの計画を変化させるといっても、プロジェクトで達成するゴールを変えようといっているのではありません。ゴールは変わらないし、顧客との合意もないのに変えてはいけない。
しかし、プロジェクトのやり方を変えることは、誰にも制限されるものではないのです。

工程という大きなフレームワークの上で、先々を見通し、足元の実績がずれているなら計画そのものを自らの意思で変えていこう、ということです。

計画を変えるのは、勇気が必要です。勇気がなければ変えることを躊躇するでしょうし、躊躇することでさらに自体を悪化させてしまうでしょう。

現場にある変えがたい事実から達成するゴールを目指すために、受身で計画を変更するのではなく、先々を読み自分の意思で先に手を打つ効果的な計画に変えていくことが攻撃的な進捗管理です。