Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

パーソナルソフトウェアプロセス(PSP)実践講座
~第1日 自分の生産性・品質を算出する

パーソナルソフトウェアプロセス(PSP)入門 (1)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/06/25 14:00

ダウンロード 記録用チャート (8.9 KB)

 プロジェクトのエンジニアとして担当分を「安定した品質で/安定した生産性で/期日通りに」納入する方法を、具体的なエクササイズを通して習得する「パーソナル・ソフトウェア・プロセス」(PSP)という手法について解説します。

目次

0: ある日の優秀なプログラマとの会話

 突然ですが。ある日の、長年の友人との「○木屋」における会話から、この連載を始めてみようと思います。

オムそばをつつきながら、最近少し顔色の悪い彼は言いました。
彼:

「最近さぁ、帰ったら『もおー食ってやるー!!』って言いながら炊飯ジャー開けて、食事するんだよね...」

焼き鳥の串をはずしながら、私は言いました。
私:

「さすがに不景気だからねぇ、開発の仕事も減ったでしょう、ストレスばっかりだよね...」

するとプログラマの彼は、浅漬けを取りかけた箸を止めて、なんとこう言いました。
彼:

「とんでもない!! この不景気だから、カイシャが取れる仕事を全部取って来るんだよ! この人員でどう考えてもこなせません、っていう量なんだよ。もう最初からやる気なくすよ!!」

私 with さつま揚げ:

「じゃあ人雇えばいいじゃない」

彼 with 焼酎ボトル:

「この人数でなんとか回してきたから、今年も来年も、回せるって思ってんだよ、ちくしょー」

 不景気で、開発者が過労死寸前。そんな話があるんですね。

1: パーソナル・ソフトウェア・プロセス(PSP)

 この連載の最初に、私はある「優秀な」プログラマとの会話、を載せました。

 皆さんのうち、どれくらいの方が「うまく回っていないプロジェクト」「ギリなプロジェクト」を経験したことがありますか? 経験した方に聞きます。うまく回らない原因は、必ずしも開発者の能力が足りないからではないのだということに、気づいたことがありますか? むしろそれ以外の要因が直接的な引き金になることがほとんどだ、と私は考えています。ソフトウェア工学の重鎮ワッツ・ハンフリー(Watts Humphrey)も、

私の知っているソフトウェア開発者のほとんどがこの問題に気づいていて、その原因が非現実的なスケジュール、不適切なリソースと要件が不安定なことだ、と説明さえできるのです。[2007 Humphrey]

と、能力以外の側面に言及しています。

 私は、カーネギーメロン大学のソフトウェア工学研究所(Software Engineering Institute: SEI)からソフトウェア開発者としての認定『SEI-Certified PSP Developer』をいただき、2009年現在、コンサルタントとして様々な企業様のお悩みを聞いています。

 上記のような問題を回避し、ソフトウェア開発・システム開発はやりがいがあって楽しい、ということを思い出していただきたい、と思い、この連載を始めることにしました。

お客さまから飛んできたちょっと複雑な要求に答えたり、ちょっと難易度の高いプログラムを組み上げることはやりがいがあって楽しいはずです。ですから、そのプログラミング以外の部分の実質的、精神的な負荷を軽減したい、あるいは最低でも、想定可能にしたいものです。

 例えばプログラミング作業以前の、計画や設計と呼ぶ段階では、現実的なスケジュールを組んで、リソースを適切に見積もって、要件がどれくらい変更されるかを見切って、その不安定分は上乗せしておけば、余裕を持ってプログラミング作業に集中できるでしょう。そして、プログラミング以後の段階では、単体・結合・ユーザテストなどの時、想定外のバグの山に気が狂いそうにならないように、最初からバグを軽減できるような方法、あるいは、最低でも、バグ修正にかかりそうな時間を確保しておくような対策方法を取りましょう。

 この連載ではこれらを実現するための方法「パーソナル・ソフトウェア・プロセス(PSP)」を、エクササイズを交えながら習得していきます。

 さて、そのPSPの骨子を書くと、こうなります。

  1. 過去の実績を基に、できるだけ正確に、自分の生産性・品質を算出しておく。
  2. その生産性と品質は、プロジェクトにおいて起こる様々な出来事によって、どれほど変動するかを算出する。
  3. それをもって、今後同じ開発言語で、同じような開発案件が来た時には、「このくらいの規模・これくらいの期間・これくらいの品質になる予定です」と答える。
  4. 3.に当てはまらない、新規部分が多いプロジェクトの場合は、予測がつく部分とつかない部分とを慎重に分けて、それぞれで見積もってから、組み合わせる。
  5. 実際の開発は、コーディングそのものよりもはるかに多くの時間を、実開発作業以外に費やす。それらの時間や、休日、有給などをうまく管理し、プロジェクトをオーバーランから回避させるための「計画」について考える。

 ここで、勘の鋭い方はすぐにピンとくるでしょうが、この連載では、プログラムを開発する際に必要なあらゆること――初期計画・見積もり・設計・実装・品質管理など一通り――を少なくとも一度以上のエクササイズによって演習します。そして実際の開発作業の中に取り入れることを試みます。なかなか骨のある内容・量です。が、どうぞ少しずつ読んで、少しずつ演習を解きながら、理解を試みてください。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

修正履歴

  • 2009/06/29 16:18 参考文献を加筆。

著者プロフィール

  • 南川 しのぶ(ミナミカワ シノブ)

    IT技術、IT経営のコンサルタント。主にシステム開発コンサルティング活動の他、外部セミナー、顧客先企業の内部セミナーの講師も務める。カーネギーメロン大学のソフトウェア工学研究所(Software Engineering Institute)認定PSPソフトウェア開発者(SEI-Certified P...

バックナンバー

連載:パーソナルソフトウェアプロセス(PSP)入門
All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5