はじめに
突然ですが皆さんは、自分がどれくらいのサイズのプログラムを、どれほどの生産性でコーディングできるのか、はっきりと上司の方に話せるでしょうか。例えばあなたは、10KLOC（K Lines of code）のソースコードを何時間かけて書きますか。1週間でどれくらいの規模のプログラムをコーディングできるでしょうか。
今、こう思ったかもしれません。
「新規性やプロジェクト特性によって、プロジェクトの生産性は大幅に変動します」
しかし、新規性がまったくないプロジェクトは、ほぼありません。その「新規性」「プロジェクト特性」をどこまで正確に数量化し、見積もりに反映できているでしょうか。とどのつまり、こういうことになっていませんか？
「自分の経験に理由をつけて、えいっと出す！」
…なんて勇敢な。勇敢な方は嫌いではない、むしろちょっと好き、ですが。
もとい。私は今、アメリカ合衆国にあるSEI（Software Engineering Institute）で、PSP（パーソナル・ソフトウェア・プロセス）について勉強しています。このPSPとは、ソフトウェア開発におけるプロセス標準を提供するものです。
これまで改善が叫ばれてきた上記のような問題、つまり、生産性や見積もりの正確さ、自分が作る製品の品質の検証、などといった問題に、「自分がプロジェクトのエンジニアだとしたら、担当する部分の製品をどういう方法で設計してコーディングし検証するか、またはどういう方法で品質、コスト、納期を約束し、守るか」というアプローチで、答えを出そうとする理論です。
品質や進捗について上司、プロマネ、委託元と揉めそうになったら何を武器にして闘うか、を知る。今のところは、このような認識で構いません。
これを踏まえて、次節以降を読み進めてください。
筆者の立場
ここで少し脇道にそれますが、PSPの認定プログラムと、執筆時点（2007年7月）での筆者の立場をお話ししておきます。
私は現在、PSPスキルを持った開発者としての認定（SEI-Certified PSP Developer）を取得すべく、年に数回、SEIと日本を往復しています。PSP認定資格には、「開発者」「コーチ」「インストラクター」の3段階があり、今は最初の認定である「開発者」を取得中のため、まだSEIが正式に認めたインストラクターではありません。
この連載は、PSPに興味のある方、またはPSPをまったく知らない方を対象に、PSPの概観を把握してもらうことを意図して執筆しています。
より深くPSPを学びたい方は、筆者の経験を含め、SEI認定を持ったインストラクターの講義を受けることを強く勧めます。また、2007年8月にPSP参考書籍の翻訳本（翔泳社刊）の発刊が予定されています。こちらも参考になるでしょう。
PSPを始めるにあたって
さて連載第1回では、PSPを採用し自分で展開しようと思った時に、まず何から手を付けるべきなのかを紹介します。
PSPでは、まず自分に一番馴染んでいる開発方法で開発した、プログラムのサイズと開発にかかった時間を計り、自分で作りこんだ欠陥（defect）を全件記録して、それらをデータとして蓄積します。つまり、「自分は今、何にどれくらいの時間をかけているのか」を知る作業です。
開発時間を計る
PSPでは開発の各フェーズを以下の6つと定義して、計測することを求めています。
- 計画立案（planning/PLAN）
- 設計（design/DLD）
- コーディング（code/CODE）
- コンパイル（compile/COMPILE）
- テスト（test/UT）
- 事後分析（post mortem/PM）
各フェーズにかかる時間は、できればストップウォッチで測って記録することを求めています。たとえば、「計画立案」中に電話がかかってきたら作業を中断しますね。その時はストップウォッチを止めます。もしくは作業を中断した時間を記録し、総時間から引きます。会議があるなら、もちろんストップウォッチは止めたままです。この要領で計測していきます。
では、まずは何かプログラムを書いてみましょう！
