「プロジェクトの測る化」を読み終えたので、内容について気になった点を備忘メモ。
測る化とは
一言であらわすと、定量的に計測した情報を用いて状況を可視化して現場での変化や問題をすぐに把握できるようにすること。要は「見える化の進化形」。
「見える化」だけでは主観的で勘や経験に基づくマネジメントになりやすい。この「見える化の限界」を打ち破るものが「測る化」だ、と。
ドラッカーなどが言っているように、プロジェクトマネジメントにおいて測る化は不可欠となっている。
そもそもプロジェクトを管理するためには計画がすべてのベースとなるので、計画時点でS(スコープ)+QCD(品質・コスト・納期)における定量的な目標値を設定することが必要。この計画を基にして、実際にプロジェクトが着実に遂行できているかどうか確認し、必要に応じてアクションを打っていく。
例えば、設計工程で以下のような報告を受けても、判断できない。
「設計作業は順調です。設計書の作成も順調に進んでいて、レビューもきちんと実施しています」
定量的な計画を立てていれば、目標とすべき設計書の分量に対してどの程度の作成が完了しているのか、1ページあたりどの程度の時間をかけて何件の欠陥が発見されたのか、を報告してもらえる。
計画時の目標精度を高めるには
計画時に設定する目標値の制度を高めるためには、定量データをモノサシとして参照することで「相場感」を掴むことが有効。
相場感をつかむために有効なデータには大きく分けて３種類あり、「自分が経験したプロジェクトのデータ」「組織で蓄積したデータ」「世の中のベンチマークデータ(※)」。
※ソフトウェア開発データ白書、ソフトウェアメトリック調査、ソフトウェア開発データリポジトリの分析
「改善に近道はありません。しかし王道はあります。そして、改善を続けて行くには定量データを蓄積・活用する測る化が不可欠なのです」
スコープの測る化
大切なのは、何を基にした要件の一覧なのかを明確に示し、関係者間で認識を合わせておくこと。入力情報に関する共有認識が不足していると、その後で何に対する変更かが不明になり、婚とロース使用としてもできない状況に陥る。（入力情報がRFPなのか、提案書なのか、設計書なのかを明示して認識を合わせる）
品質の測る化
品質の評価には成果物そのものの品質と、成果物の品質を検証するプロセスの品質の両面で品質を捉えるようにする。（成果物の欠陥、バグが少ないからと言って品質が良いとは判断できない。レビューやテストといった検証プロセスが適切に実施されていないと、当然発見できるはずの欠陥やバグも少なくなる）
コストの測る化
「何を作るか（機能要件）」と「どのように作るか（スケジュール、体制、WBS）」からコストは算出される。コストの見積時には前提条件を明文化し、関係者間で共通認識を持つことが大切。（どの文書、どの版をベースとしているか等）
「規模」と「工数」
規模に比例する工数（主に開発）、比例しない工数（管理、環境構築、移行、マニュアル作成等）を区別する。
上流工程でおおよその工数を見積り際に、トップダウン見積り（FP数やステップ数から工数を概算）することが多い。
規模に対する見積りを実施しておかないと、スコープと見積りの関係性が希薄になり、スコープの変化に応じたマネジメントが難しくなる。
「期間」と「要員」
WBSやスケジュールから各工程の期間を見積もり、規模や工数の見積り結果と比較して適切かどうかを判断する。見積りとプロジェクト計画のバランスを取り、要員数を見積もっていく必要がある。（100人月の開発を100人でやれば1ヶ月で出来る、なんてアリエナイ）
上流工程において、機能の詳細が明確になっていない場合、どういった根拠で見積もったのかを記載しておくことで、その後のスコープの変動において何が変動したのか把握しやすくなる。
プロジェクトのスムーズな運営をするために工程間での要員の急激な増加や減少に注意する。
- 急激な増加：設計から製造に移る際に散見される（新規メンバーの教育を考慮する必要あり）
- 急激な減少：製造からテストに移す際に散見される（バグ発生時のアプリケーション改修に影響を及ぼさないよう体制を考慮する必要あり）
納期の測る化
「達成度」「乖離日数」「予定算日数」の３つの情報を用い、成果物や作業ベースの達成度と当初スケジュールからのズレの双方を定量かすることによって、スケジュールの遅れを可視化するだけでは見えてこなかった事実を数値で表せるようになり、アクションを取るべきか否かを判断しやすくなる。
「達成度」は設計書ならページ数や機能数、製造ならステップ数やファイル数、テストなら項目数や機能数を基に、全て完了したら100%といった形で数値化する。
プロジェクト実行中の品質の測る化
品質が良くて欠陥が少ないことと、レビューやテストが不十分で欠陥が少ないことを混同してしまうと適切な評価ができなくなり、品質不良を見逃してしまう。そのため、上流工程でも下流工程でもプロセス品質とプロダクト品質の両面から評価が必要となる。
特に上流工程の品質が確保できないまま下流工程に進んでしまうと、深刻な品質不良を引き起こす。（設計書の品質が悪いと、適切な試験項目が作れず、テストが意味を成さなくなる）
指標値を用いた評価はプロジェクト全体で比較すると平準化されてしまうので、機能単位などで比較して欠陥数が上限・下限を超えるものを抽出する。上限を上回っている部分は欠陥の発生原因を調査する。なお、下限を下回る場合には要注意で、品質が良くて下回っているのか、レビューやテストが不十分で摘出すべき欠陥を見逃しているのか判断が必要。
プロジェクト実行中の納期の測る化
WBS、スケジュール、要員の3要素を考慮して監視する必要がある。
また、本当の意味での進捗状況の確認においては、納期の測る化だけでは不十分で品質の測る化とあわせて監視していくことが必要。（作業は順調に進んでいるように見えても、品質が不十分なのであれば、本質的には順調に進んでいないため）
※進捗遅延要員の上位によく挙がるのが、特定の有識者に作業が集中することによる遅延のため、未然に防止策を考えておくことが必要。
まとめ
作ったコード行数や必要となる工数ベースの契約では生産性の向上に対するモチベーションも生まれないため、業界として疲弊していくばかりです。
提供した機能要件、非機能要件に相応な対価に基づく受発注が可能な世界へと転換していく必要があり、そのためには前述したベンチマークデータによる相場感の醸成が不可欠です。また、将来的には顧客の事業目標に対するシステムの貢献度で対価が決まる世界を作ることが必要です。
測る化ですべてが解決するわけではありませんが、測る化を始めないと解決しない問題は多いのです。
ここに書かれている通り、ステップ数や工数だけで判断すると生産性向上のモチベーションが発生しづらいという点については、とても納得。
コメント