8: よく出てくる質問
ここまでご説明すると、以下のような質問をよくいただきますので、それぞれ簡単に説明します。
具体的にどれくらいの計測サンプルがあれば、実用レベルなのでしょうか。
今日1つ課題を解いていただきました。このデータを1セットとします。この連載では、8種類のプログラミング課題を出します。それを順番通りに解いていただき、8セットのデータがそろった段階で、この計測結果が実用に足るものなのかを改めて判定し、それを自分の業務に生かしていきます。
計測は手作業だとかなりシンドイのですが…
計測するのは「時間・欠陥・プログラム規模」の3点のみです。そしてこの連載では、計測ツールがないことを前提にし、紙と鉛筆で演習ができるように工夫しています。しかし、実際、演習の数が多くなってくると、計測・計算を自動化すると非常に楽です。そこでSEIのサイトに行くと、計測に便利なデータベースや、SEIで実際に使われている講義資料を無料でダウンロードすることができます。
『PSP Academic Material』のWebページで「Download Form」をクリックしてください。その後出てきた登録フォームに、お名前などを記入すると、入手できます。しかし、英語ですから、ちょっと敷居が高いかもしれません（翻訳版を公開したいのはやまやまなのですが）。
PSPの骨子の第3点でいう「同じような開発案件」とは何でしょう。
第一義的には、同じプログラミング言語と同じ開発環境によって行う開発、と考えていただければいいでしょう。
PSPの骨子の第5点でいう「実開発以外に費やす」時間とは何でしょう。これもPSPに含まれますか？
毎朝のメールチェック・会議・資料のコピー・ちょっとした休憩・ちょっと呼び止められて打ち合わせ・電話・……などです。それらの時間をすべて差っ引いた時に、私たち開発者が一日にプロジェクトのための作業をしている正味の時間がはたしてどれくらいなのか、が知りたいのです。例えば一日のうち、プログラミング作業が可能な正味の時間が2時間半だったとします。ならば、もしも、5時間くらいかかりそうなプログラム作業が飛んできた場合、今まで「実営業日1日いただければできます」と答えていたものを、「実営業日に直すと2日後にできます」と言い換えることになります。
とにかく「早くできます」と返事をし、後で冷や汗をかくことと、実績をベースに「2日後」と宣言しておいて、堅実な結果を残すこと。どちらがあなたの開発者としての信頼性を高めることになりますか？ 答えは明白ですね。よって、実開発以外の時間もすべて自分のコントロール下におくことが、PSPの目指す方法なのです。
ちなみに、この例で「5時間くらいかかりそうと、どうして分かるのですか」と思った方は、第3回・4回で、このからくりを説明しますので、もう少しお待ちください。
PSPがプログラマの生産性を定量化できる、よい手法であるということは分かりました。しかし、働きすぎを判断できる半面、これをベースに給料を算出する、という怖さもあると思いますが…
PSPでは、生産性を時間当たりのコード行数で測ります。こと給料算出に関しては、開発者が無駄に長いコードを書いたり、改行を多く入れることで給料を上乗せできるリスクがあるので、最近は実開発量や生産性で給料を算出する傾向は減っているようです（あくまで筆者の実感として、ですが）。コード行数の測り方、生産性の算出の仕方については、第2回で改めて取り上げ、演習します。
9: まとめ
それでは第1回のまとめです。
- パーソナル・ソフトウェア・プロセスとは、開発者が無理ない納期・品質・生産性でモノ作りをするための、NOと言える手法である。
- 最初に現状を知るところから始める。
- 現状を知るには「測る」といい。
- PSPでは、「フェーズ」と「欠陥」を定義している。
- ミナミカワはどうやら戦うコンサルである。
- 性格はキツイらしい。顔は怖いらしい。
それではまた次回。
10.参考文献
- 『PSPガイドブック ソフトウェアエンジニア自己改善』 ワッツ・S・ハンフリー 著、秋山義博 監修、JASPIC TSP研究会 訳、2007年8月、翔泳社
