数値が真実を照らし出す
プロジェクトに参加したメンバーは、プロジェクトの良かった点、悪かった点、改善した方が良い点などを、いくつか頭に思い浮かべているはずだ。一般的なプロジェクトの反省会では、これらの点について互いに意見交換することが多い。
だが、メンバーが感じている問題点は、必ずしもプロジェクトの実体を表しているとは限らない。
例えば、あるプロジェクトでは、やたら進捗や会議ばかりやっていて、仕事が進まず、スケジュールがオーバーしてしまった、とメンバーが思っていたとしよう。この点を反省すると、なるべく会議を短くしよう、という結論になる。
だが、実際に会議を行っていた時間と、机の前で作業していた時間を、それぞれ集計してみないと、真実は見えない。集計してみると、会議に費やした時間の割合は、実はかなり小さいことが分かるかもしれない。
会議の時間が適切でも、
- 事前に連絡がなく、急に会議を始めることが多い。
- 作業に集中したい時間に会議が入ることが多い。
- 会議の雰囲気が悪い。
といったケースでは、メンバーが「会議ばかりしていた」と感じることもある。もしそうなら、なるべく会議を短くしよう、という結論は誤りである。
どんな数値を出すべきか
プロジェクトレビューでは、メンバーが集まって話し合う前に、プロジェクトの実績を数値で示した資料を作成する。
プロジェクトの実績を示す数値とは、具体的には、次のようなものである。
プロジェクトの実績を示す数値
- 工数
- 累計の作業時間（○時間）
- 実際の作業期間（○月○日〜○月○日）
- 成果物
- 仕様書や設計書の分量（ページ数）
- ソースコードの分量（行数／関数の個数／クラスの個数／ファイルサイズ）
- 項目
- 作業項目数（仕様書や設計書の見出しの個数）
- テスト項目数
- 障害の個数
これらの数値を算出するためには、日頃からきちんと記録を残しておくことが重要だ。工数を算出するためには、詳細な日々の作業記録が必要になる。また、多人数での開発であれば、自分の修正箇所が分かるようにしておく必要がある。
レビュー資料では、これらの数値を報告するだけでなく、自分なりの考察も書き加えておく。レビューに参加する前に、この数値を基に評価・解析を行っておくことが大切である。
資料に提示する数値は、プロジェクトの実体を明らかにできるデータでなければいけない。何について、どれくらい詳細に集計すれば良いかは、プロジェクトをどのように評価・解析するかに合わせて、適切に定める必要がある。
数値を操作して真実を隠してはいけないが、正確に評価・解析するためには、実情に沿った値を算出する必要がある。例えば、ソースコードの行数を算出する場合、コメントを削除した上で数えた方が良いかもしれない。
予定が無ければ、評価も無い
プロジェクトを評価するためには、実績の数値だけでなく、予定の数値も必要である。予定と実績との比較が、プロジェクト評価の基本となる。
当然のことだが、予定の数値は、プロジェクトをスタートする時点で算出しておく必要がある。前章では、プロジェクトの実績を示す数値を挙げた。これらは、初めに予想しておくべき数値でもある。特に工数の値は、評価基準として重要だ。
プロジェクトレビューは、実際に問題が発生した時だけ行えば良い、という考えもある。それも悪くはない。だが、いざ問題が発生してから、慌てて実績だけを算出しても、評価のしようがない。事前に数値化した予定を立てていなければ、問題を教訓として次に活かすことはできないのだ。
実際には、たいていのプロジェクトでは、事前に工数やスケジュールの見積もりは行っているだろう。だが、数値だけ残っていても、評価はできない。その数値を導き出した根拠となる資料も残しておくことが重要だ。
数値に基づくプロジェクトレビューの効果
数値に基づくプロジェクトレビューは、それ自身にかなりの工数がかかる。実際、数ヶ月×数人規模の作業で行ったプロジェクトレビューでは、資料を作成するのに１日、レビューにも半日かかった。ただでさえ忙しい中、そんな悠長に反省会などやっていられないかもしれない。だが、それだけの時間をかける意義は必ずある。
ソフトウェアの品質はテストで充分に評価する。設計の不備による障害のデバッグを１、２個もやる羽目になれば、たいていの技術者は、もっと上手く作りたいと思うようになるものだ。一方、開発作業については、終わり良ければすべて良し、となりやすい。だが、プロジェクトレビューを行うことで、ソフトウェアの作りだけでなく、開発の進め方そのものにも関心が向き、作業をより良く進めようという意欲も沸く。
数値に基づくプロジェクトレビューのためには、資料をまとめる必要がある。そのため、日頃からスケジュールの自己管理や、ソースコードや文書の管理についても、注意が払われるようになる。
プロジェクトレビューのためには、事前に数値化した予定を立てておく必要があると述べた。逆に言えば、プロジェクトレビューを習慣化することで、根拠のないスケジュールで開発作業を進めてしまうというリスクを防ぐことができる。
そして何より、数値に基づいて予定と実績を解析することで、作業計画や要因配置を考える上での、具体的な参考データを得ることもできる。例えば、ファンクションポイント法などで工数を見積もる際の、係数を求めることもできるだろう。「やることリスト」に基づく見積もり手法も、数値に基づいたプロジェクトレビューから得られた結果を基にしたものである。