進捗が終わったかと借金取りしても終わらないよりReadyな状態にした方が確実に進捗する

プロジェクトマネジメントで言えば、統合管理プロセスの中のと言い始めると開発現場での感覚とずれていくのは何故なんだろうか。やはり、プロジェクト管理と訳され、製造するという感覚を引きずっているからではないか。

某氏との会話でもプロジェクトが始まったら、プロジェクトの終わりまではリスクマネジメントをするものであり、『リスクのコントロールこそプロジェクトマネジメントだ』という意見に同意するのは、PMBOKの統合管理プロセスとう言葉の言い回しにフィットフィット感を覚えているからだろう。

それはそれとして、予定したタスクが予定した期日に終わらない。終わって欲しいと（勝手に）期待しつつも（メンバは）終わらせてくれない。

それで管理という名の終わったという言葉の取り立てが始まる。要は、進捗管理である。

こんな会話をしていたら、終わるものも終わらない。

一度、どうしたら終わるかをこんな風に質問してみてはどうだろうか。

『全くの制限ない前提で、何が揃ったら、予定した期日に終わるか教えて欲しい』

回答に詰まったら、全く何も考えていないのでいつまでたっても終わらない。担当を変えよう。もちろん、そのエンジニアはご退場願おう。

辿々しくても、必要だと並べてくれたらそれを用意しよう。必要だというほとんどのものは、仕様に絡むものだ。作業を始めようと思っても、必要なインプットが揃っていないから途中で作業が止まってしまうのだ。

それは本来なら作業を始めるには、Readyな状態になっていないだけなのだ。着手してもインプットが足らないから、作業中にインプットを揃え始めようとする。調べ始めるといつの間にかに調べることや調整事項が増えてしまい、スケジュールオーバーラン担っている、だけなのだ。

Readyな状態にするためには、１つだけすればいい。

作業を小さくすること。

時間は難易度と担当するエンジニアのスキルレベルに依存するので目安でしかないが、4時間程度で終わるとか、2時間とかくらいまで分解する。

もちろん、割り込みされない前提で。

大きなチャンクのままで作業を渡してタスクが終わったかと借金取りをするより、始められる条件に時間を掛けた方が100万倍いい。

なにせ、始められるReadyな状態なのだから不慮のインシデントでもない限り必ず終わる。

これは、プロジェクトマネージャなり、リーダのエンジニア自身が自分の価値観を変えないと誰も乗ってくれない。