前回は，機能要件を対象とした国内開発をまず先に実施し，その後オフショア拠点を利用して非機能要件を満たすフトウエアを完成させるという基本的な考え方について説明した。前半の機能要件を対象とした国内開発のための手法がRfSである。
RfSとアジャイル開発
RfSのプラットフォームであるRuby＋Rails（Ruby on Rails）は非常に生産性が高い。偶然であるが，牛尾 剛氏と私は，2008年2月13日から14日にかけて東京・目黒で開催された開発者向けイベント「Developers Summit 2008」で，「超上流おそるるに足らず」という講演を行った。
そこで，Ruby＋Railsによるセミナー販売サイトのプロトタイプのデモを実施した。そのデモは，エンティティ10数個を含み，機能的にも充実していて，またスタイルシートを利用した見栄えの良いものであったが，その開発に要した時間は61時間であった＊1。
| ＊1前回述べた通り，Ruby＋Railsというプラットフォームを使用し，仕様書作りを目的としたプロトタイピングを行う開発手法を「RfS（Ruby for Specifications）」と名付けている。 |
このような効率的プロトタイピングも，伝統的なウォータフォール型のプロセスモデルでは，プロジェクトの開始時点でただ1回だけ実施されるということになる。それでは，効率的なプロトタイピングによってもたらされるメリットがきわめて限定的だ。
ここに，アジャイル開発手法を適用すればどうだろう。アジャイル開発手法にはいくつかの種類があるが，共通しているのは反復型の開発プロセスを採用する点だ。反復型では，プロジェクト全体を複数回のミニプロジェクトに分けて実施する。ならば，ミニプロジェクトで必ずRfSを行えば，効率的なプロトタイピングを繰り返し実施できることになる。
こうした開発プロセスが持っている顧客価値は，明らかだ。顧客要求の反映や操作性へのフィードバックなどが，反復というミニプロジェクトのサイクルで，俊敏に反映されていくからだ。ミニプロジェクトの長さは，最短で数日から最長で数カ月までというところだろう。この単位で，顧客は，新しく要求した機能や，プロトタイプに対するフィードバックが反映された機能を試すことができるのだ。
これが，本稿に「目標追跡型ソフトウエア生産システム」というタイトルをつけた理由である。前々回の「オフショア時代を乗り切る明確な要求仕様作成術」で牛尾氏が述べているように，要求が時間とともに変わることを平鍋 健児氏（チェンジビジョン代表）が，ムービングターゲット（動く標的）と呼んだ。目標追跡型ソフトウエア生産システムとは，そのムービングターゲットをアジャイルに追跡できる生産システムを意味しているのである。
もちろん，ミニプロジェクトの後半で，前回述べたような非機能要件の充足を目的とした本格的なサーバー機能の開発を実施することが可能だ。
反復型開発＋α
さて，前述の通り，反復型開発プロセスには明らかな顧客価値がある。しかし，残念なことに，必ずしも顧客からは好感を持たれてはいない。反復型開発プロセスは顧客に何も約束しない，という印象を持たれているからだ。何故このような印象を持たれるかというと，それはミニプロジェクトの開始時点でアウトプットを約束しないからである。
図1で示すように，原則として同一ミニプロジェクトで複数作業分野（ディシプリンと呼ばれる）が実施されるため，そのミニプロジェクトで生み出される成果物を約束することができない。つまり，実装の範囲は，設計が終了しなければ定義されず，設計の範囲は，要件定義が終了しなければ定義されない。そして，要件定義の範囲は，当該ミニプロジェクトの開始時点で決まっていないのだから，結局，ミニプロジェクトの開始に当たってそのアウトプットを約束することができないのである。
ところが，このようなミニプロジェクトに対して，顧客は一定金額の支払いをあらかじめ約束させられる。これでは普通は納得がいくまい。
| |
|
図1●反復型開発プロセスと作業分野 [画像のクリックで拡大表示] |
しかし，図2に示すようにミニプロジェクトを構成する作業分野が，明確な仕様を作るための前工程と，そこで提示される仕様を確実に実装し，テストする後工程に分かれていたならばどうだろう。
後工程のほうは，1期前の前工程からアウトプットされる仕様を実装することとすれば，顧客に対して，少なくとも後工程の開始前には確実な成果を事前に約束できることになる。前工程は，プロトタイピングや要件定義の工程であり，顧客が目標追跡という柔軟性を享受できるのだから，一定量の作業量や作業時間を約束することはあっても，一定量の成果をあらかじめ約束する必要はない。
| |
|
図2●パイプラインを導入した反復型開発プロセス [画像のクリックで拡大表示] |
図2のように，仕様が斜めに流れていくプロセスは反復型のバリエーションであり，パイプラインと呼ばれる。図に示したようにRfSは，ビジネス分析やユースケース分析などとともに前工程の一部として組み込まれる。必要に応じて，ビジネス分析，ユースケース分析，RfSなど前工程に含まれる作業分野をさらにパイプライン化してもよい。
前工程からアウトプットされた要件を，後工程は確実に実装する。そのため，後工程の契約は，請負型での実施が可能だ。
もし前工程から与えられた仕様やその変化が過大であり，1回のミニプロジェクトでは後工程が作業を吸収できない場合はどうすればよいのか。逆に，用意された後工程のリソースに対して，必要なリソースがそれを下回った場合，リソースをすでに用意してしまった後工程担当開発会社のリスクはどのように考えたらよいだろうか。
トヨタ生産方式を手本にしたい
このあたりは生産管理の課題であり，トヨタ生産方式のような先輩製造業の管理手法が参考になると考えている。トヨタ生産方式では，日々の生産品目や生産量はカンバン方式によって機敏に制御されるが，数カ月にわたる生産量の見込みが全くないわけではなく，おおまかな品目と数量があらかじめ案内されており，その範囲から大きく変更しない生産計画が立てられる。そのような仕組みがあるために，トヨタの協力会社は安心して，生産を続けることができるのだ。
図3は，後工程の負荷をそのような一定の範囲内に納めるために，前工程の最終段階として「平準化作業」をいれてある。この作業では，定義された要件によって後工程の負荷が重すぎると判断される場合は，その一部のみを要件として切り出し，後工程に対する次回ミニプロジェクトの仕様とする。また，負荷が軽すぎる場合には，ドキュメンテーションのような作業を追加発注したりすることになろう。
| |
|
図3●平準化を導入したパイプライン [画像のクリックで拡大表示] |
では，以上に述べたような，目標追跡型ソフトウエア生産システムにおける契約とはどのようなものになるだろう。
個々のミニプロジェクトだけを考えれば，前工程は目標追跡というあらかじめ成果を特定できないサービスを提供している工程なので，準委任がふさわしく，各ミニプロジェクトの作業量や作業時間に制限をつけた契約となろう。
また，後工程は，明確に与えられた仕様に基づいて設計・実装・テストを行うのだから，請負型の契約が発注者と受注者双方の利益になる。請負であるから受注者には瑕疵（かし）担保責任が伴う。ただし，すでに述べた前工程の平準化作業によって，仕事の量はある一定の範囲に限定することができる。そのため，都度ミニプロジェクトの請負金額を見積もる必要はない。
これまで説明してきたように，目標追跡型ソフトウエア生産システムの生産管理面は，これからもトヨタ生産方式が参考になると考えている。お手本を探して海外に目が向きがちなIT産業ではあるが，生産管理に関する限り，世界一の手本が我々の身近にある。RfSという生産技術，トヨタ生産方式，そしてオフショア開発という組み合わせで，新しいソフトウエア生産の仕組みをさらに考えていきたい。
| （依田 智夫＝要求開発アライアンス理事） |
