プロジェクト管理の基本は計測です。プロジェクトが現在どのような状況になっているかは計測することなしに把握できません。プロジェクトでは、人が作業を行い、ドキュメントやプログラムを生産します。プロジェクトは期限内に作業を完了させる必要があります。そのため、適切な手順で作業を進める必要があります。例えば、上流工程から下流工程に向けて、要求仕様設計（外部仕様設計）→構成（構造）仕様設計→詳細仕様設計→コード化→テスト→評価の順に作業して行きます。各工程の作業に誰を割り当てるかは大変重要なことです。そのためには、生産物の種類、規模や難易度を見積もる必要があります。見積りについては別稿で説明しますが、見積りと計測は密接に関連しています。計測という行為なしに見積りはできません。新しいプロジェクトの見積りには過去のプロジェクトで得られた計測データや試験的に行って計測したデータを参考にするのです。
以下では、先ず、計測するための尺度について、次に計測の考え方、最後に計測データの蓄積と活用について説明します。
１．尺度
プロジェクト管理の合言葉は「何でも測ろう！」です。仕事をしたらどんなことでも測りましょう。そのためには尺度が必要になります。何を尺度にして測るのか。長さはメートル、重さはグラム、時間は秒で測ります。これらの尺度を基本として、面積は長さ×長さ、容積は長さ×長さ×長さ、速度は長さ÷時間という風に求められます。新たに求められた面積や容積などを尺度にすることもできます。これらの尺度は世の中で標準として決められた尺度ですが、プロジェクト管理における尺度は自分達で勝手に定めることができます。尺度を決めると、プロジェクト状況を把握することができます。
尺度が決まるといろいろなことが計算できます。１人でできる仕事の量は１日どのくらいか、プロジェクトが仕事をこなすのに何日（何時間）かかるか、この仕事をこなすのに何人必要か、このままのペースで仕事を進めていけば納期に間に合うかなどと言ったことが計算できるようになります。もちろん計算は紙の上のことですから、その通りになるわけではありませんが、現実の状況をベースにして予測できるわけです。行き当たりばったりや勘に頼るよりはるかに正確な管理が可能となります。
上に述べたことは生産性の測り方です。品質についてもある種の尺度で測ることができます。
プロジェクト管理における尺度は、長さや重さ、時間のように厳密ではありません。多くの不確定要因がありますが、尺度としての性格は同じです。しかし、多くの計測データが集まると尺度の信頼性は上がり、実際のプロジェクト管理において大いに役立ちます。
プロジェクト管理における尺度としては、一般的に、
1) 項目数
2) ページ数
3) 画面数
4) 帳票数
5) コードの行数（LOC：Line Of Code）
6) モジュール数
7) テスト項目数
8) 欠陥件数
などを使用します。
1)から6)までは生産物の出来高を測る尺度になります。上記の尺度は絶対的なものではありません。プロジェクトあるいはプロジェクトの工程の生産物により尺度は決まります。生産物の中で、尺度になるものを決めるのです。対象とするプロジェクトにおいて意味があるならばプロジェクト管理者の判断で決めれば良いのです。例えば、小さなソフトウェア部品を沢山作成することが主たる業務では部品数を尺度にすれば良いでしょう。
7)と8)は品質を測る尺度です。
これらの尺度は、長さや重さ、時間とは比較できないほどいい加減な尺度です。それでも、これらの尺度を使えばプロジェクトの実態が見えてくるのです。いい加減では困ると言って、精度を重視した理屈っぽい尺度を取り入れるのは賛成できません。現実のプロジェクトには不確定要因が沢山存在し、尺度だけ厳密にしても余計な仕事を増やすだけです。それより、プロジェクトのメンバが理解しやすい尺度の方が良いのです。上に挙げたものは現実的な尺度と言えます。
２．計測の考え方
２．１ 生産性の計測
プロジェクトは要員（頭数）が揃っているだけでは、その生産能力は分かりません。プロジェクトに参加する人の能力の種類と能力、能力を発揮する意欲、意欲を発揮する体力、そして協調性、団結力、組織的活動などが問われます。いつでもそれらのプロジェクト能力を最大に発揮できるわけではありません。プロジェクト管理者には、これらの不確定要因を見抜き、プロジェクトの成功に向けで誘導するリーダシップが要求されます。管理者はプロジェクトあるいはプロジェクト工程を計測することによりプロジェクト状況を把握し、決められた予算内で、決められた時期に目的が達成できるよう調整するのです。
プロジェクト活動が混沌としていては、結果がどうなるか全く見えなくなります。プロジェクトを管理可能とするために、言い換えればプロジェクト状況を把握、制御するために、要求仕様設計（外部仕様設計）→構成（構造）仕様設計→詳細仕様設計→コード化→テスト→評価と言う作業工程を踏む必要があります。つまり、要求からソフトウェア作成に到るまでの作業を工程に分けてブレークダウンし、作業を実行して行くのです。
１人ですべての作業を行う場合、このような過程は不要となることもありますが、複数の人が作業を進めるには、この作業工程は必要不可欠となります。
各作業工程をどう設計するかについては別稿で述べますが、作業工程には次の模式図に示すように入力情報と出力情報があります。必要な情報を入力し、当該工程の作業を経て、情報を出力します。
例えば、要求仕様設計工程の場合、入力はお客様の要求であり、出力は要求仕様設計書です。要求仕様設計書は次の作業工程：構成（構造）仕様設計の入力となります。構成（構造）仕様設計工程の出力は要求仕様をどのように実現するかを示す構成（構造）仕様設計書です。以下同様です。
ここで注意すべき点は出力が次の作業工程で必要とする情報を完全に満たしていなければならないことです。ありがちな間違いは上流作業工程が下流の作業工程の準備作業であるという認識を十分持っていないことです。各工程では次の工程で何を行うかを頭に入れておき、現在の作業工程でなければできないことを完全に済ませることです。上流工程で済ませておかずに下流工程に持ち越すとプロジェクトは混乱します。例えば、テスト工程で要求仕様設計のやり直しをするなどの状況になれば、プロジェクトは完全に失敗です。以下では、こうした状況はないという前提で話を進めます。
これまでの説明で、計測対象となる生産物が明らかになりました。各作業工程の生産物の規模（規模を測る尺度は上記１．尺度で述べたものを使用）を見積もる必要があります。規模と１人単位時間当たりの生産規模、人数が分かれば何時間（日）で作業が完了するかを計算することが可能となります。
＜総作業時間＞＝＜生産物の規模＞／＜１人単位時間当りの生産規模＞
＜作業工程の所要時間＞＝＜生産物の規模＞／（＜１人単位時間当たりの生産規模＞×＜人数＞）
これらの計算式を利用するためには＜生産物の規模＞と＜１人単位時間当たりの生産規模＞を見積もることが鍵となります。既存の計測データや経験値があれば、それを予測値として利用します。しかし、作業を始めて最初の数日で、プロジェクトの実体との差異がでるのが普通です。違いが顕著であれば、予測値を実体に合わせて修正します。このようにして、生産物の規模、人数が予定期間に見合うものなのかどうかを確認することができます。
＜１人単位時間当たりの生産規模＞の実際の値は個人の能力に依存します。熟練者は生産性が高く、初心者は低いのが普通です。計算では平均値を使う必要があります。
プロジェクト管理者は担当者から毎日、計測結果を報告させます。ここで必要となるのが報告書です。できるだけ負担が少ない報告方法を選択します。どのような報告書が良いかはプロジェクト管理者の判断で決めます。プロジェクト管理者は報告結果を集計し、予定期限に間に合うかどうかを計算します。
予定期限に間に合わないことが明らかになった場合、速やかに行動しなければなりません。調整できるポイントは、
・ ＜予定期限＞の延長
・ ＜人数＞の増員
・ ＜生産物の規模＞の縮小
・ ＜１人単位時間当たりの生産規模＞の拡大
です。プロジェクトの予算オーバーが認められない場合、＜予定期限＞の延長、＜人数＞の増員はできません。但し、生産性が悪い人を高い人に交換することはできます。また、担当配分を調整して全体として計画要員でまかなうこともある程度はできます。お客様との交渉で可能ならば、＜生産物の規模＞を縮小します。
２．２ 品質の計測
上記の２．１では、生産性の計測について述べましたが、品質についても計測することができます。
作業工程：コード化の生産物はプログラム、DB、画面、帳票などです。これらの規模から平均的な潜在欠陥件数を予測し、その値に達するまでテストを繰り返すという考え方があります。この考え方は、良くできる担当者にとっては釈然としません。一方、できの悪い担当者の場合、直ぐに目標は達成されます。できの悪い担当者のプログラムは、欠陥が検出されなくなるまでレビュー、インスペクション、テストを繰り返すことは当然ですが、テスト工程でこれを行うのは時機を逸しています。品質の良し悪しは早い段階で把握しておく必要があります。対策が遅れるほどプロジェクトにとって致命傷となるからです。
そのために、作業工程には必ずレビューを組入れ、欠陥件数を計測します。担当者、モジュール別に欠陥件数をカウントすると、担当者やモジュール別の品質が見えてきます。
テスト工程で品質を計測する方法として勧めたいのは次に述べる「投網法」です。これは極めて単純な方法ですが、担当者やモジュール別の品質を容易に把握できます。
投網法
１人の人間が書いたプログラム中に欠陥がいくつ潜在するか分かりませんが、１回目のテストを行い、
＜欠陥検出率＞＝（＜検出欠陥件数＞／＜テスト項目数＞）×１００ （％）
を計算します。この段階で検出された欠陥を修正すれば、すべての欠陥が取り除かれたと考えることはできません。修正済みのプログラムに対して、再度テスト項目を挙げ、テストを実施し、＜欠陥検出率＞を計算します。前回と同じ欠陥検出率であった場合、テスト項目の網羅度が希薄であったと考えられます。テスト項目の網羅度が信頼できるなら、２回目の検出率は確実に下がるはずです。この作業を繰り返して、品質を上げて行きます。
１回目のテストでは、＜欠陥検出率＞は通常５％程度になります。２回目以降のテストは1回目のテスト結果を分析して、同様の欠陥がないかレビューします。欠陥は人間のはまり易い瑕疵を反映しているからです。また、テスト漏れはないか等を確認します。
分析結果によって、テスト対象を絞り込みます。２回目のテストは１回目よりはるかに負担が減るはずです。
この方法でテストを実施すると、テストを行う毎に、欠陥検出率の下降傾斜が読み取れ、残欠陥件数が後どのくらいあるかも見えてきます。残欠陥件数は、残りのテスト回数毎に発見されであろう欠陥件数の総和と考えられます。レビューをしっかりと行えば、連続関数ではなく、階段関数的に＜欠陥検出率＞が下がります。
投網法には「テストを何度も行わなければならないので、工数がかかり過ぎないか」と言う疑問があります。
テストは欠陥を検出する手段ではなく、プログラムの品質を評価する手段です。品質が悪いと評価されたプログラムに対しては、欠陥の分析を行い、テストで欠陥を見つけるのでなく、設計作成工程に戻って欠陥を取り除く必要があります。欠陥の分析はそのプログラムや担当者の欠陥作りこみ傾向が明らかになるので、その傾向を反映させたレビューを行うことによって担当者の集中力が喚起でき、レビュー効率が上がります。担当者自身が投網法を意識して実行すると、漫然と品質が悪いのでテストをやり直せと指示しなくても、自ら探し出そうと努力するようになる効果もあります。
投網法では、欠陥検出率はいくらなら満足なのかが問題となります。検出率０．１％以下であれば先ず問題ないでしょう。しかし、システムによっては１％程度でも良いと思われます。この値をいくらにするかはプロジェクトにより決められます。OSのように欠陥が１つあっても困るソフトでは、０．１％程度ではだめでしょう。さらに厳しい値以下になるまで品質を上げる必要があります。
３．計測データの蓄積と活用
計測データは蓄積し、次のプロジェクトで活用することが肝要です。組織により、計測データの値は若干異なります。同じ組織であっても担当者の熟練度が増してくれば、計測データの値は年毎に異なります。しかし、プロジェクト管理おいてはその程度の違いは大した問題にはなりません。組織の生産性や品質を管理するために、プロジェクト報告として整理しまとめておくことが大切です。
上記「１．尺度」と「２．計測の考え方」でとりあげた話題は計測に関するほんの一例に過ぎません。計測すべきことはまだ多く存在します。組織で必要な計測データを蓄積し、活用することが大切です。
例えば、プロジェクト毎に計測データを記録しておくと、新しい案件の見積を正確に行うことができるようになります。要員の手配も容易になります。プロジェクト管理においても（経験の）再利用は大変重要です。再利用こそ生産性と品質向上の要です。再利用はオブジェクト指向の特権ではありません。
本稿は計測の触りを述べたに過ぎません。皆さんには是非「ソフトウェア・メトリクス」（ロバートB．グレイディ、デボラL．カスウェル、日経BP社 原書：Software Metrics: Establishing a Company-wide Program Robert B. Grady, Deborah L. Caswell）を読まれることを勧めます。この本はヒューレットパッカード社の生産性、品質の計測について詳しく紹介しています。計測の重要性とその効果を詳細に事例を挙げて述べていますので大変参考になります。 ■
