監視・コントロールプロセス（その2）

前回、監視・コントロールプロセスの基本的なところを、医療行為とPMを対比させて書きました。

監視・コントロールプロセスの大きな課題、
・正直に報告されない
・管理工数が爆発
に対して、ではどうしたらいいのか？

メンバーの人数にもよりますが、中～大規模プロジェクトになると、メンバーは数十人～数百人、さらに千人越えなんて事もあり得ます。
こうなるとある程度管理可能な規模のサブシステムに分けて、プロジェクトリーダーを複数配置して管理することが必要になります。
それでもやっぱり数十人にもなると、上記の課題が立ち塞がり、早期発見ができなくなります。

PMBOKにはEVM（Earned Value Management）という進捗管理の方法が提案されていますが、これは工数や費用をすべて金額換算して、それらの費消計画と実績をトレースするもので、確かに有効な手法ではありますがちょっと一見分かりづらい。

そこで提案は、
「開発成果物の計画立案と実績管理」
です。イメージは下記です。
Excelを使って、横軸はカレンダー（週単位とか）、縦軸は開発成果物。

①計画立案
開発成果物とは例えば、
・要件定義書
・外部設計書
・内部設計書
・テストスクリプト
・実装
・バグ
などです。
これらを縦に並べて、上段に計画立案してもらって数字を入れておく（黒字）。単位はページ数だったりライン数だったり、成果物によって変わります。

②実績報告
このExcelを共有サーバーに配置して、毎週下段に実績を入力してもらう（赤字、青字）。

③管理
管理者は毎週決まった曜日にこのExcelを開けて、計画と実績の乖離が大きいところ（Excelで自動的に色づけする機能を使う）について、担当者やプロジェクトリーダーに状況を聞きに行く。

これだと数字での報告なので嘘つけませんし、管理側もいちいち全員に状況を聞きに行く必要もない。つまり、
・正直に報告されない
・管理工数が爆発
の両方とも解決できます。

ただし、この方法では大きな課題が別にあります。
それは、「計画の信憑性」、すなわち本当にその計画値は妥当なの？
ということです。
これに対して私の経験では、実績が少ないメンバーの場合は当然自分の実力がわかっていないので精度は低い傾向にあるので、毎週計画値を見直してもいいということにしていました。
これだと進捗管理にならないのですが、教育的指導も含めてプロジェクトリーダーの方がフォローすることが必要です。
一方経験豊富なエンジニアはかなり高い精度で計画立案ができるようになります。
逆を言うと、計画を作ってそれに対して作業を進めるという「癖」を付けることが個人個人の開発能力の向上に繋がり、組織全体としての計画の精度を上げていくことができるようになり、プロジェクトの成功確率が格段に向上します。
実はこれが究極の求める姿であるわけです。

さらに、
バグの計画って何？　バグは実績であって計画は作れない
と言われそうですし、現に何度も言われましたが、実はこれがまた非常に重要なことです。
これについては次回書きたいと思います。