【メトリクス管理 連載目次】
- 1. メトリクスとは
- 2. 基本メトリクスセット
- 3. 進捗管理とメトリクス分析
- 4. 工数メトリクス
- 5. ソフトウェアメトリクス
- 6. プロジェクト管理ツール＆システムの成長モデル
- 7. プロジェクト管理ツール＆システム構築の戦略
- 8. Metrics for Project Management
- 9. メトリクスの実例
- 10. Products of Metrics for PM
1. コード・メトリクスの問題
ハードウェア開発の場合、設計部門は、購買や生産管理、工場技術、製造など多くの関連部門との関わりを持つ必要があるため、ある意味強制的に進捗や設計内容を整理しおく必要がありますし、回路図や基板などのモノを見ればだいたいの状況はわかります。したがって、進捗はある程度把握できるものです。一方、ソフトウェア開発の場合は、技術部門だけで一通りの開発作業ができてしまうことや、ハードウェアを組み合わせて動かしてみないと確認が難しいことなどから、進捗や設計内容はブラックボックスになりがちです。したがって、意識的に進捗を見える化して外部に伝えることが重要です。
このような要求に応えるために、すでに多くのソフトウェア開発現場では作業成果物を使った進捗の見える化を行っています。たとえば、プログラム・ステップ数（コード・メトリクス）は多くのところで収集され、進捗指標として利用されています。そういう意味では、ソフトウェア開発における作業成果物メトリクスはなじみのある考え方ですが、確認のためそのポイントを整理しておきましょう。下図をご覧ください。
この中で、「作業量との相関があること」というのは、あまり意識していない場合があります。たとえば、ほとんどのソフトウェア開発現場で収集しているプログラム・ステップ数（コード・メトリクス）は、作業量との相関が高いことがわかっているから指標として使われているのです。しかしながら、ステップ数に対して複雑なカウント方法や計算を行っているところに出会うことがあります。流用の場合には流用元の関数全体のステップ数にある係数を乗じて加算するとか、開発中に削除したプログラムについてもそのステップ数にある係数を乗じて加算するとか、これらの係数もいろいろと場合分けされているとか、いろいろと手の込んだ方法をとっているところがあります。
理由を聞くと、「削除しているプログラムも作業の結果なのだからカウントするべきだ」というような説明があり、一見すると論理的根拠のある計算方法のようにも思えるのですが、ここで問題なのは、このような計算方法にすることが妥当かどうかを検証していないことです。工数（時間）などの実際の作業量との相関が高いかどうかを検証した上で、計算方法が妥当かどうかを判断する必要があるのです。ただ多くの場合、複雑にしてもその相関が高くなることはまれです。
2. 開発工程と作業成果物メトリクス
作業成果物メトリクスで忘れがちなことがもう一つあります。作業成果物は開発工程ごとに違うということです。
ソフトウェア開発では、開発工程を定義して工程ごとのインプットやアウトプットなどの定義を明確にすることが基本ですが、この開発工程定義によれば作業成果物は工程ごとに違うとなっているはずです。これは、進捗管理のための作業成果物メトリクスは工程ごとに違うということです。したがって、工程ごとに前述の作業成果物メトリクスの条件を満たす作業成果物メトリクスを整備する必要があります。
上図はソフトウェア開発工程と作業成果物メトリクスの例です。この図では工程ごとに一般的な作業成果物メトリクスを記載しているのでわかりやすい例になっていると思いますが、実はこの中には、先の作業成果物メトリクスの条件からは適切ではないメトリクスが含まれています。どれだかわかりますか？
それは要件定義工程です。「仕様書項目数」や「仕様書ページ数」が仕様書作成までの作業量に比例した値になることは非常にまれだからです。一般的に、仕様書の書き方は明確に定義されておらず、人やプロジェクトによってかなりバラツキがあります。また、以前の仕様書を流用して作成することも多いと思いますが、一般的な仕様書ではその際のカウント方法を決めるのは非常に難しいことになります。普通の仕様書というのは表現や内容の制限が緩くて自由度が高いため量のカウントに向いておらず、また、記述の基本単位を特定することが難しいので、測定対象のバラツキが大きなものになってしまうのです。
したがって、要件定義工程で適切な作業成果物メトリクスを設定する場合には、まずは、ユースケースやシナリオなどにより要件の記述方法を標準化し、その上で、測定対象を基本ユースケースと派生ユースケースにするなどの対応をとることになります。また、流用開発がメインの場合は、仕様の変化点を抽出できる変化点管理シートのようなフォーマットを定義し、変化点という基本単位が明確になるような工夫が必要になります。
作業成果物の測定は多くのソフトウェア開発現場で行われているわけですが、このような検討が不十分なままにルールとして決まっているからという理由だけで、かなりの時間をかけて収集・管理しているようなケースも多いものです。データ収集などのオーバーヘッドが問題になっている場合は、改めて現在収集している作業成果物メトリクスが、適切な作業量との相関をもっているかどうかを確認するのが良いかもしれません。
3. 作業成果物メトリクスを使った見積もり式の開発
作業成果物メトリクスは、作業成果物を測定することにより作業量から見た進捗を把握するためのものですが、その活用方法について紹介しておきたいことがあります。もう一度、図（開発工程ごとの作業成果物メトリクス例）をご覧ください。図に開発工程の作業成果物メトリクス間の関係式を記載しています。この関係式は、基準モデルと同じように、自組織でのプロジェクトの実績値を分析して作ったもので、図に記載している関係式はある組織でのものです。
このような関係式を作ると、作業成果物メトリクスを使って進捗管理をするだけでなく、その進捗情報を使って作業見積もりをすることが可能となります。
たとえば基本設計工程では、計画していた総プロセス数に対して、実際に設計ができたプロセス数をカウントすることで作業進捗を判断するわけですが、この関係式を使えば、設計ができたプロセス数から詳細設計工程におけるファンクション数を見積もることができます。同様に、見積もったファンクション数からコーディング工程におけるプログラム・ステップ数を見積もり、さらにはテスト工程におけるテスト項目数も見積もることができます。
図（開発工程ごとの作業成果物メトリクス例）で説明すると、設計できたプロセス数が 10 であればファンクション数は 53 と見積もることができ、さらに、プログラム・ステップ数の見積もりは 1,855 となり、テスト項目数の見積もりは 222 となります。図には書いていませんが、それぞれの作業成果物メトリクスと工数（時間）との関係式も明確になっているはずですから、各工程での工数（時間）も見積もることができます。
このように、作業成果物メトリクス間の関係式を使えば、開発工程における作業が進むにつれ、そして、開発工程が進むにつれ、それ以降の作業量や必要工数（時間）の見積もり精度を上げることができます。開発初期に見積もったプログラム・ステップ数や工数（時間）を最終ゴールとし、その変わらないゴールと実績と比較することで進捗とするのではなく、継続的に見積もりを見直すことにより段階的にその精度を上げることができるのです。
この関係式を作ればそれが基準モデルになっているのですが、作業成果物メトリクスについても基準モデルを作ることを忘れないでください。プログラム・ステップ数であれば、コーディング工程の作業成果物メトリクスですから、単位時間当たりのプログラム行数というコーディングのパフォーマンスとなる基準モデルを...
つくることができるはずです。ただ、繰り返しになりますが、単位工数（時間）あたりのプログラム・ステップ数というのは他社データが手に入れやすいこともあり、そのまま自分のところの基準としてしまうことがありがちですが、あくまでも自分の組織でのベストプラクティス（成功事例）を基準とすることを忘れないようにしてください。自分たちの現状の延長上にあるゴール（基準）であることが大切なのです。
4. 流用率と開発生産性
ここで、プログラム・ステップ数に関して興味深いデータをひとつ紹介しましょう。
上図は横軸に流用率、縦軸に単位時間当たりのプログラム・ステップ数（開発生産性）をとり、10 社程度のエレクトロニクス・メーカーの約 50 プロジェクトをプロットしたものです。
縦軸の開発生産性は、そのプロジェクトで新規に作成したプログラム・ステップと修正したプログラム・ステップを加算したものを、リリースまでの開発工数（時間）で除算したものです。複数会社の複数プロジェクトをプロットしたものですから、かなりバラツキがあるのは当然ですが、高い値を示しているところに注目すると、流用率が高くなるにつれて開発生産性も高くなっていることがわかります（橙色の線）。
流用率を上げることが推奨されることは多いものですが、確かに流用率を上げることは開発効率を上げることにつながることがわかります。ただし、流用率が高くなるほど開発生産性のバラツキが大きくなっていることに注意が必要です。単純に流用率を上げるだけでは開発生産性を上げることにはつながらないことを示しています。「流用率を上げろ」というかけ声だけではダメだということです。