0: ある日の優秀なプログラマとの会話
突然ですが。ある日の、長年の友人との「○木屋」における会話から、この連載を始めてみようと思います。
「最近さぁ、帰ったら『もおー食ってやるー!!』って言いながら炊飯ジャー開けて、食事するんだよね...」
「さすがに不景気だからねぇ、開発の仕事も減ったでしょう、ストレスばっかりだよね...」
「とんでもない！！ この不景気だから、カイシャが取れる仕事を全部取って来るんだよ！ この人員でどう考えてもこなせません、っていう量なんだよ。もう最初からやる気なくすよ！！」
「じゃあ人雇えばいいじゃない」
「この人数でなんとか回してきたから、今年も来年も、回せるって思ってんだよ、ちくしょー」
不景気で、開発者が過労死寸前。そんな話があるんですね。
1: パーソナル・ソフトウェア・プロセス（PSP）
この連載の最初に、私はある「優秀な」プログラマとの会話、を載せました。
皆さんのうち、どれくらいの方が「うまく回っていないプロジェクト」「ギリなプロジェクト」を経験したことがありますか？ 経験した方に聞きます。うまく回らない原因は、必ずしも開発者の能力が足りないからではないのだということに、気づいたことがありますか？ むしろそれ以外の要因が直接的な引き金になることがほとんどだ、と私は考えています。ソフトウェア工学の重鎮ワッツ・ハンフリー(Watts Humphrey)も、
私の知っているソフトウェア開発者のほとんどがこの問題に気づいていて、その原因が非現実的なスケジュール、不適切なリソースと要件が不安定なことだ、と説明さえできるのです。[2007 Humphrey]
と、能力以外の側面に言及しています。
私は、カーネギーメロン大学のソフトウェア工学研究所（Software Engineering Institute: SEI）からソフトウェア開発者としての認定『SEI-Certified PSP Developer』をいただき、2009年現在、コンサルタントとして様々な企業様のお悩みを聞いています。
上記のような問題を回避し、ソフトウェア開発・システム開発はやりがいがあって楽しい、ということを思い出していただきたい、と思い、この連載を始めることにしました。
お客さまから飛んできたちょっと複雑な要求に答えたり、ちょっと難易度の高いプログラムを組み上げることはやりがいがあって楽しいはずです。ですから、そのプログラミング以外の部分の実質的、精神的な負荷を軽減したい、あるいは最低でも、想定可能にしたいものです。
例えばプログラミング作業以前の、計画や設計と呼ぶ段階では、現実的なスケジュールを組んで、リソースを適切に見積もって、要件がどれくらい変更されるかを見切って、その不安定分は上乗せしておけば、余裕を持ってプログラミング作業に集中できるでしょう。そして、プログラミング以後の段階では、単体・結合・ユーザテストなどの時、想定外のバグの山に気が狂いそうにならないように、最初からバグを軽減できるような方法、あるいは、最低でも、バグ修正にかかりそうな時間を確保しておくような対策方法を取りましょう。
この連載ではこれらを実現するための方法「パーソナル・ソフトウェア・プロセス（PSP）」を、エクササイズを交えながら習得していきます。
さて、そのPSPの骨子を書くと、こうなります。
- 過去の実績を基に、できるだけ正確に、自分の生産性・品質を算出しておく。
- その生産性と品質は、プロジェクトにおいて起こる様々な出来事によって、どれほど変動するかを算出する。
- それをもって、今後同じ開発言語で、同じような開発案件が来た時には、「このくらいの規模幅・これくらいの期間幅・これくらいの品質幅になる予定です」と答える。
- 3.に当てはまらない、新規部分が多いプロジェクトの場合は、予測がつく部分とつかない部分とを慎重に分けて、それぞれで見積もってから、組み合わせる。
- 実際の開発は、コーディングそのものよりもはるかに多くの時間を、実開発作業以外に費やす。それらの時間や、休日、有給などをうまく管理し、プロジェクトをオーバーランから回避させるための「計画」について考える。
ここで、勘の鋭い方はすぐにピンとくるでしょうが、この連載では、プログラムを開発する際に必要なあらゆること――初期計画・見積もり・設計・実装・品質管理など一通り――を少なくとも一度以上のエクササイズによって演習します。そして実際の開発作業の中に取り入れることを試みます。なかなか骨のある内容・量です。が、どうぞ少しずつ読んで、少しずつ演習を解きながら、理解を試みてください。
