はじめに
プログラマの仕事がより楽しくなる「PSP（パーソナルソフトウェアプロセス）講座」の第2回です。今回は、プログラム規模（サイズ）の正確な測り方について考えてみます。
前回はPSPとは何かについてお話ししたのち、プログラム課題を一つ解いていただきました。その際に、「開発（6つのフェーズ）にかかった時間」「発見し修正した欠陥の数」を数えて記録してみました。
なぜ計測したのでしょうか。今日はそのあたりからお話を始めてみたいと思います。それでは今回も一緒に、この方法「PSP」についてエクササイズをまじえ、習得していきましょう。
PSPの概要を知りたい場合は第1日に戻って、ざっと読んでからここに戻ることをお勧めします。PSPをスキルとして習得なさりたい方は、やはり第1日に戻り、演習を解いてから、ここに戻るとよいでしょう。
計測の意味: データを蓄積すれば見積もりに使えます
現場経験をお持ちのプログラマさんならピンと来ると思いますが、プロジェクトは恐ろしくたくさんの「いつ終わるの？」「どれくらいかかるの？」に満ちています。マスタースケジュールをはじめ、個々のチームの作業計画、おそらく要件定義時に作成する総合テスト計画から、今日の会議の終了時刻、その後作業を予定している資料の締切にいたるまで……。また、作りっぱなしでいい成果物など一つもありません。自分が作成したモノは資料であれプログラムであれ、必ず後続の作業の入力になっているはずです。だから、「いつ終わるの？」「どれくらいかかるの？」という質問が飛び交い、場合によってはそれが強迫観念のようになるわけですね（やれやれ） 。
前回プログラムを作る際に時間を測っていただいたのは、その「いつ終わるの？」に対する答えを準備するためです。つまり、少なくとも主要業務であるプログラム開発においては、
「前回使用した言語で、前回程度の規模の開発をする場合、 かかる時間は平均で○○分程度です」
という答えを用意するための、一つめの材料になるわけです。もし仮に経験が一度しかなくても、あなたはきっと
「前回○○分だったので、今回も同程度だと思います」
あるいは
「前回と比べて○○なので、時間は△倍の約○×分です」
などと言うはずですね？ 今後も、蓄積したデータが1点でもあるならばそれを使い、その上で技術者としての判断を発揮して、「いつ終わるの？」に答えましょう。これが、PSPにおける見積もりの立場です。よって、次のプログラミング課題（第4日で出題予定）からは規模も測ることにしましょう。
平均とは何かについては、ほとんどの方は既にご存じだと思います。また、前回課題を解いていただいた方は、その計算式を用意する段階で思い出して、あるいは理解していただいたかと思います。つまり、
同じ定義に基づき収集したデータについて、その値の総和÷データ数
ですね。
プロセスを測るとは
ということで、計測の意図についてお話ししました。さて、ここでこの連載のタイトルはPSPだということを思い出してください。PSPはパーソナル ソフトウェア プロセスの略でしたね。パーソナルは「個人の」、ソフトウェアは「ソフトウェア」、そしてプロセスとは「仕事の仕方」と考えてください、と前回申し上げました。では、「仕事の仕方」などという漠然とした観念をどのように計測するのでしょう。
さっそく答えを申し上げます。今回のプログラム課題を開発するフェーズは、計画立案・設計・実装・コンパイル・テスト（実行）・事後分析、の6つです（第1日参照）。この6つのフェーズにかかった時間を測り、その時に発見した欠陥を記録することで、皆さんは各プロセスにかかる工数を測り、その品質を測っていることになるのです。お分かりいただけるでしょうか。これが「プロセスを測る」ということです。
万が一ここで混同される方がいないように、念のため補足しておきます。
「フェーズ」は、時間の流れの中の1区切りです（第1日参照）。時間は後戻りできません。よって、フェーズを巻き戻すことは原理的にはしません。一方、「プロセス」は、前出の通り、仕事の仕方です。
ですから、時間という大きな流れを、仕事の視点から区切ったものがフェーズです。その中で行う仕事内容がプロセスです。よって、たまたま同じ時間軸の中に表わされていますが、同義ではありません。
