The Rational Edge

プロジェクトに1人で果敢に取り組んだ
あるプロジェクトリーダーの日記

−ラショナル統一プロセスの実践−

Philippe Kruchten
Rationalフェロー
2002/4/13

---

　「ソフトウェアエンジニアリングプロセス」という言葉からは、専門用語ばかりでつづられた基本方針、指示、書式といった内容ばかりの書類の山が、だれの目にも留まることなくほこりをかぶっている様をイメージする人もいるだろう。だが、このような資料は、開発作業に対する管理能力が疑問視される典型的なマネージャたちから指示されたプログラマー軍団が開発するソフトウェアを、お役所やごく一部の大企業にのらりくらりと引き渡す巨大な開発ベンダーしか利用しないようなものだ。

　だが、実際にソフトウェアエンジニアリングプロセスがこのように大げさなものである必要はなく、当面の仕事や開発組織の要求に応じて簡単にまとめても、周到に用意しても構わないものだ。数百人のデベロッパーを投じる膨大な規模のプロジェクトでも、1人が短期間で片づけられるような小規模のものでも、優れたプロセスであればそれぞれの内容に合わせることができるのだ。

　ソフトウェアエンジニアリングプロセスの目的は、デベロッパーの毎日の作業をつらいものにすることでも、膨大な量の事務処理によって創造性を破壊しようとすることでもない。その真の目的は、ソフトウェア開発組織がユーザーのあらゆるニーズと要求を満たす高品質のソフトウェアを、スケジュールと予算を守って期待どおりに開発し、引き渡すことだけだ。

　そこで、ソフトウェアエンジニアリングプロセスの神髄を理解するために、たった1人で構成されるチームが作り出したシンプルなソフトウェアプロジェクトを例として考えてみたい。

単独作業によるソフトウェアプロジェクト

　12年の開発経験を持つソフトウェアエンジニアのNickは一匹狼的開発スタイルを好むが、明確に規定したプロセスに慎重かつ忠実に従って作業を進めている。以下は、彼が古くからの友人であるGaryのために1週間をかけて先日完成させたばかりのプロジェクトについてつづった日記である。

■発展する可能性を秘めたアイデア（土曜の夜）

　今日の夜、共通のお気に入りの飲み屋で友人のGaryに会った。彼は小さな会社のソフトウェア開発マネージャだ。この会社は社内でのプロセス効率と予測性改善への取り組みの一環として先日「Personal Software Process手法」のトレーニング（＊1）に参加したのだが、デベロッパーが要求事項の収集、設計、テスト、および運用といった各種作業に費やした時間をそれぞれに整理することがこのアプローチの重要な要素となっていたことが、彼にとっての問題になっていた。彼のデベロッパーはそれぞれ別のトラッキング手法を利用しており、週末が訪れるたびに全データの整理／統合作業が待っているのは悲惨な悪夢だという。彼のアシスタントは、チームメンバーが作業時間割の予想に使用してバラバラにしてある付せん、電子メール、ボイスメールをかき集めなくてはならないという思わしくない状況にある。何しろ生産性の監視、プロセス改善の可能性を秘めた分野の特定、そして何よりも今後のプロジェクトに向けた効果的プランニングのためには、各種作業に費やす労力を正確に計算することがソフトウェア関連企業にとって非常に重要なのだ。

　そこでGaryに、開発作業のトラッキングという単調で退屈な作業を自動化してはどうかと提案した。常時起動しておき、作業の目的と関連付けて、昼食や休憩時などで席を外すときは保留し、戻ったときには再開させ、作業が完了したら閉じるという、作業の内容が分かる小さなタイマをデベロッパーの画面に表示させるのだ。また、データはどこか安全なところに保存し、週末になったら取り出してスプレッドシートを使って整理できるようにする。Garyは「素晴らしいアイデアだ！ 君がこれを作ってくれないか？ これならかなり混乱が解消するし、予算も相当削減できる。限度はあるけどお金はいくらでも払うよ。いくら払えば開発してくれるかな？」と話に乗ってきた。そこで、Garyにはよく考えたいと伝えておいた。翌週には何の予定も入っていなかったので数時間もあれば何かしら見せられるものが作れるとは思ったが、すぐに考え直し、「そうだね、数日待ってくれ。月曜日の朝11時ごろにでもぼくのオフィスに来てくれないか。それまでに何か考えておくよ」と伝えた。

■提案（月曜の朝）

　残りの週末はタイマのプロジェクトについて何度も検討し、今朝起きたときには「頭の中」でコンセプトが完成していて、インプリメンテーションに関するアイデアもいくつか浮かんでいた。でも、本格的なビジネス提案には本格的なビジネスケースが必要だった。何を作成し、それにはどの程度のリソースを割り当てる必要があるだろう？ 最大のポイントは、作業開始に当たって時間の確保とソフトウェアの購入が必要になることだ。それに、Garyには最終的にどの程度の金額を請求すればよいかという問題もある。そこで、早朝からオフィスに出勤し、机を整理して4枚の紙を並べ、それぞれの一番上に次にようなタイトルを付けた。

• 開発構想（Vision）
• プラン
• リスク
• ビジネスケース

■「開発構想」

　まず開発構想から考えていった。Garyと自分のために、取り組もうとしている基本的なニーズは何か、ツールの外観はどのようにするのか、それをどのように使うのかなど、自分たちが達成したい目的を厳密に記述する必要があるのだ。私が最初にまとめたのは以下のような内容だった。

パーソナルタイマツール（開発構想）

問題点 　Garyの会社にとっては、さまざまなソフトウェア開発作業に費やされた時間に関する一貫したデータを収集できないことが、予測に照らし合わせたプロジェクトの進行監視、カスタマーに対する適切な請求、請負業者への支払い、そして最終的には今後のプロジェクトに対する正確な予測の障害ともなっている。 開発構想の提示 　消費時間を計測し、後からソートや抽出を行うべくデータを収集および保存するパーソナルタイマツール（PTT）をGaryの会社で使えば、（付せん紙やいい加減な推測とは違って）負荷のかかる部分について体系的かつ堅実な評価を容易に行うことができ、プロジェクトの予測時間に対する実際の消費時間をトラッキングできるようになり、今後の開発にかかる作業負荷を一段と正確に予測できるようになる。 主な当事者 開発作業者 管理スタッフ プロジェクトマネージャ ユースケース＊2 作業時間の計測 週次作業時間表の抽出 プロジェクトに向けたデータの整理統合 プロジェクトに向けたツールおよびデータベースのセットアップ 　＊2：ユースケース＝システムが提供する機能

　「プラン」の段階では今後数日のスケジュールを大まかに描き、大きなマイルストーン（自分1人、あるいはおそらくGaryと一緒に判断を下さなければならないポイント）を主に特定することになる。

　これ以降の作業に対する対価の支払いを約束してもらうため、今日の昼にはGaryから作業開始の承諾を得る必要がある。この開発構想、プラン、そして予算に彼の同意を得なくてはならない。自分にも、このプロジェクトにかかる金額の詳細が分かり、Garyには見えない自分だけのビジネスケースが必要だ。もしこれらすべて（全体の開発構想、プラン、そして価格に関する承諾）を得ることができ、自分が損をすることが絶対にないことが分かれば、「Lifecycle Objective（LCO）Milestone」（ライフサイクルにおける目標のマイルストーン）という最初のマイルストーンに到達したことになり、開始フェーズを終わらせることができる。

　Garyが分かりやすいよう、そして予期せぬ難題に直面したときの自分自身の保険のために、彼には火曜日の夜に見せる大まかなプロトタイプの開発分だけの支払いを約束してくれるよう提案しよう。そして、彼が自分で目にしたものを気に入った（そして私自身がプロジェクトを金曜日までに完了できる確信を得た）場合のみ、合計額の支払いを約束してもらおう。

■「プラン」

　まだ朝の9時半なのでプランまで進めることにしよう。見栄えのする日程管理表を作成してくれる高機能プランニングソフトウェアまでは必要ないが、自分に許された時間をだいたいのフェーズに分割する大まかなプランは立てたい。

　1枚の紙に大まかな計画を描き、手帳に予定表を書き写すことにした。最初のフェーズプランは次のようなものになった。

月曜日	火曜日	水曜日	木曜日	金曜日	土曜日
方向付け（Inception） 開発構想 プラン ビジネスケース リスク	プロトタイプ リスクの緩和	作成（Construction） 設計 コーディング テスト	設計 コーディング テスト
LCO：Gary承認	LCA：Gary承認		IOC：最初のベータ版を見せる
推敲（Elaboration） プロトタイプ	ユースケース テスト	設計 コーディング テスト	移行（Transition） 改善作業？
			引き渡し（Delivery）

「方向付け（Inception）」。早朝から各種作業を進めており、Garyと一緒に昼食を取った直後には作業を終わらせたいと思う。彼にデモ版のプロトタイプに対する支払いを約束してもらえれば、このフェーズも今回のプロジェクトの1日分となる。彼が支払いを約束してくれない場合でも、そこで作業を終わらせるだけで2人の関係は変わらない。

「推敲（Elaboration）」。このフェーズも火曜日の昼食時までには終わらせることができると思う。要求事項、ソリューション、そしてプランを「詳述」する大まかなプロトタイプを作成し、自分のアイデアをいくつか探ることになる。そして、昼食を取りながらGaryと一緒にすべてを再検証してもらうことになる。このプロトタイプには次のような意味がある。

• 要求事項に対してさらに多くのフィードバックを得るために、Garyに見せられる具体的な何か（“百聞は一見に如かず”である）。何といっても、これまで彼がプロジェクトとして実感できたのはビール片手の話し合いと大まかなプラン立てしかないのだ。
  
  
• 自分にとってさらに重要なのは、必要なすべてのものが手元のハードドライブ上にあるかどうか、そして作業量を自分が過小評価していないかどうか検証できるようにしてくれる。今朝には、ひげを剃りながらアーキテクチャのアイデアと、そのために利用するさまざまな部品が頭に浮かんだと思ったが、いまは不安もある。「前回のプロジェクトで使用した小さいデータベースは利用できるだろうか？」「これとJavaアプレットの連動は可能だろうか？」「APIのユーザーガイドはどこにしまっただろうか？」「これは彼らが使っているOSに対応するだろうか？」など疑問は尽きない。
  
  
• さらに優れたプランを立てるための詳細な情報とスケジュールを提供してくれる。
  
  
• 本番システムを作成するための第一歩となり、失敗してもやり直せる機会を提供してくれる。
  
  
• 自分のデータベース定義スキルやJavaのスタイルに関する記憶を思い出させてくれる機会を提供してくれる。

　この非常に重要な火曜日の昼食は「Lifecycle Architecture（LCA）Milestone」（ライフサイクルにおけるアーキテクチャのマイルストーン）だと考えられる。この時点では、Garyにも私にもいまのうちにプロジェクトを中止してしまう、大幅な手直しを加える、もしくは自信を持って先へ進めるという選択肢がある。

「作成（Construction）」。Garyが上質のボジョレー産ワインの勢いでゴーサインを出したら、水曜日には早朝から本番システムの「作成」を開始し、キッチリとまとめ、徹底的にテストすることになる。そしてGaryには出来上がったものを自分のラップトップで試してもらえるよう、部下のプログラマーを1人連れて木曜日の午後2時ごろに顔を出すよう伝える。そうすれば、彼らの気に入らなかった部分をその日の午後に修正することができるだろう。

　木曜日に行うこのセッションは実際のエンドユーザーが初めてこのソフトウェアを試す機会となるため、これは「Initial Operational Capability（IOC）Milestone」（初期動作確認のマイルストーン）だと考えられる。　

「移行（Transition）」。これが最後のフェーズだが、私はこれが1〜2時間で終わってくれることを願っている。このフェーズは、リリース（おそらくソフトウェアを彼らに電子メールすることになる）と、それに伴う私の大好きな代金請求を行うことで、木曜日の仕事が終わるまでにはこのプロジェクトのすべてが終了することになる。

■リスク一覧

　疑念や不安がいくつかあることにはすでに言及した。そこで危険を避けず、これを「リスク」というタイトルを付けた1枚の紙に書き留めることにする。この小さなプロジェクトを失敗、遅延、予算超過させる要因となり得るものすべてを書き込んでいくのだ。また、リスク一覧は再編や整理を繰り返す可能性が高いため、書き留めるときは鉛筆を使用する。

　一覧には次のような項目を書き込んだ。

パーソナルタイマツール：リスク 自分が必要とする開発ツールのライセンスが有効期限を過ぎている。 データベースがあまりにも高価。 Garyの会社でノード間のコミュニケーションメカニズムがサポートされていない。 Garyの会社のプログラマーが使うマシンの中にインターネットに接続されていないものがある。

■ビジネスケース

　いまは朝の10時半だが、最初のビジネスケースを作成するために必要な情報はすべて自分の手元にあるので、最後の紙にも書き込んでいくことにする。このプロジェクトに4日が必要なことはすでに見積もった。また、手元にあるJavaコンパイラとデータベースソフトウェアの両方をアップグレードする必要が考えられるため、これらはTBD（未定）としておく。自分の通常の作業量の要因に、後から出てくると思われるバグ修正の時間を多少水増しして加えておけばだいたいOKのはずだ。

　もしGaryが乗り気でなかったら、彼の視点から納得できるビジネスケースを用意することもできる。もし彼が1週間につきデベロッパー1人当たり30分と、彼の管理スタッフが費やす2時間のデータ入力や整理の時間とを節約できるならば、彼は6カ月以内にコストを回収できることになる（私はこの小さなプログラムをGaryと利益折半で他社に販売することまで考えているが、いまは時間が限られているため、この件については後日あらためて熟慮する）。

■アーキテクチャ

　まだGaryが現れないので、さらに一歩先に進んでおく。「アーキテクチャ」というラベルの付いた5枚目の紙には、Javaアプレット、ブラウザ、データベース、データ抽出機能など、タイマソフトウェアに必要な主要コンポーネントを示す次のような簡単な図を鉛筆で描いた。

　次に、私はUML（Unified Modeling Language）を使って新たなコンポーネントを2つほど加えた。この図はなかなかの出来栄えだったし、Gary自身もソフトウェアの知識をある程度持っているので、これも彼に見せることにする。

[注釈]

＊1　「Introduction to the Personal Software Process」、Watts Humphrey著（Addison-Wesley、1996年12月刊）

1/3

INDEX
先駆者に学ぶ「開発プロセス改善の原則」
	Page1 単独作業によるソフトウェアプロジェクト
	Page2 支払いの約束（月曜日） 格闘(月曜の午後） 続行（火曜日） さらなる進展と変更（水曜日） 近づく完成（木曜日） ベータテストと出荷（金曜日）
	Page3 Nickのプロセス