要求開発とアジャイル開発(3)

2007.04.05

　今回は，「要求開発とアジャイル開発」のまとめとして，要求開発とアジャイルについてもう一度整理したあと，一次開発，二次開発という大きな単位でのプロジェクトの繰り返しに対する要求開発のイメージと，仕様変更や機能追加のバリエーションについて説明したいと思います。

それぞれのチームの役割分担

　アジャイル開発における顧客（要求開発チーム）とシステム開発チームの役割をまとめると，図1のようになります。

図1●アジャイル開発における要求開発チーム（顧客）とシステム開発チームの役割分担。インフラ系作業や運用系の作業は省略

　初めに顧客（要求開発チーム）が要求開発を行い，「プロジェクト企画」を行います。これにより顧客の社内で，プロジェクトの承認を行ってもらいます。この時点で基本的な要求は抽出されているはずです。

　システム開発チームは，プロジェクト・マネージメント的な観点で「開発計画」を作成します。そして，顧客とシステム開発チームが双方で「リリース計画」を作成して，どのイテレーションでどの要求を実装するかの優先順位付けとスケジューリングを行います（開発計画にリリース計画を含むことも多いでしょう）。

　各イテレーションが始まる前に，顧客（要求開発チーム）は次のイテレーションで実施する要求を検討します。最初に計画されたものや，新たに発生した要求は，要求開発で作成した，IT貢献度マップや要求ツリー，要望分析シートで意味のある要求かどうかを分析して優先順位付けを行い，計画ゲームに臨んで，その要求をシステム開発側と合意します。

　アプリケーションができたら，顧客側が受入テストを実施して，一つのイテレーションが終了する，といった具合です。これは一例ですが，アジャイル開発と要求開発のチームが連携してプロジェクトを遂行する場合の大まかな作業はこのようになります。

要求開発の作業例

　前回はざっくりとしか触れられなかったので，ここでプロジェクト企画レベルで実施する要求開発の作業例を説明したいと思います。

図2●要求開発と反復の例

　一次開発，二次開発といった大きな繰り返しがあるようなプロジェクトの例を図2に示しました。

　すべての要求開発プロジェクトがこのような形をとるのではなく，プロジェクトごとに最適な作業手順を選択して実施します。ここでは，わかりやすい例として，流れがあるサンプルで説明したいと思います。

(1)ビジネス戦略，業務目的の確認

　プロジェクトの業務目的を確認し，ビジネス戦略と今回のプロジェクトの目的がどのようにつながっているかを確認します。ここで作成する成果物としては，BSC戦略マップやIT貢献度マップなどが多いようですが，単純に目的を確認するだけといった場合もあります。

(2)トップダウン/ボトムアップ分析

　トップダウン分析は，トップダウン的な視点で，プロジェクトでどんなことをする必要があるかの分析を行います。ボトムアップ分析は，課題を分析したり，現時点でわかっているIT化要望を取りまとめて分析します。ここでは，要件ツリーや要望分析シートなどが使われます。

(3)プロジェクトゴールの確認

　上記のプロセスにより，今回のプロジェクトのゴールが判明します。そこで「これが達成されたらこのプロジェクトは成功だ」と言える基準をゴール記述書に記述します。

(4)現状業務の確認

　現状の業務を確認します。AsIsのビジネス・コンテキスト図やビジネス・ユースケースで分析範囲を絞り込み，AsIsの業務フローを作成します。既存システムがある場合は，AsIsのTFP分割図を作るケースもあります。

(5)ToBe業務フローイメージの確認

　システム化プロジェクトを実施するということは，現状とあるべき姿のギャップを埋めるオペレーションを行うということです。現状を分析したあとは，ToBe業務の分析を行います。ToBeのコンテキスト図やビジネス・ユースケースを作成し，ToBe業務フロー（システム化後のもの）を作成します。この業務フローには，システムとプロセスがどのようにかかわるか，ということも記述します。

(6)ToBeビジネスモデリング

　ToBeのシステムの概観をモデル化し，鳥瞰図を得て，業務の抜けや漏れを発見します。ここではTFP分割図が使われます。

(7)第一次開発のゴール確認

　今回は，一次開発，二次開発…が存在する場合のイメージで作成していますので，上記のゴール記述書のうち，第一次開発で実施するぶんのゴールだけを選定します。

(8)ToBeシステムイメージの確認

　ToBeの業務フローからシステム化要件をシステムユースケース(もしくはストーリ）として抽出して，TFP分割図や要望分析シート，要件ツリーなどでその要求に抜け漏れがないか，意味があるかを確認し，トリアージを行って，システム化する内容やイメージを明確にします。ここでは非機能要件，システム構成，予算取りといったオペレーションが含まれることも多いでしょう。

(9)システム開発

　第一次開発のアジャイル開発を実施します。内部ではリリース計画，イテレーションを繰り返します。

(10)第一次開発の評価

　第一次開発のプロジェクトゴール記述書と見比べて，プロジェクトが成功したかどうかなどの評価を行い，次につなげます。

　以上，要求開発の一例として，作業と成果物についてまとめました。しかし，実際にこれらの作業を，仕様変更や仕様追加のたびに全部やるとなると大変なはずです。どの程度やり直しが必要なのかをパターン別に整理してみます。

要求開発と反復

　先ほど見た図2はもっとも一般的なパターンです。プロジェクト立ち上げ時に計画した一次開発，二次開発を実施します。そして第○次開発ごとのゴールを確認するところから，作業を繰り返します。一般的な業務であればこのような形態が多いのではないでしょうか。

　次に，戦略的なプロジェクトで，一次開発と二次開発の間でも最初に策定した業務フローが変わってしまうような大きな変化がある業務の場合です。このようなケースでは，発生した新規の要望に対してゴールを設定し，ToBe業務フローイメージの見直しから再度要求開発をまわすことになります。

図3●要求開発と反復の例（戦略的な業務の場合）

　とはいえ，すべての業務フローを再作成するというわけではなく，変更になった部分を見直すというオペレーションになります。

　大きな反復（第○次開発といったレベル）での要求開発のかかわりは，このようなイメージになります。

要求開発と仕様変更/仕様追加

　今度は，仕様変更や仕様追加に対して要求開発をどこまで再実行するかについて説明します。前回でも触れた内容ですが，今回のケーススタディでより具体的に説明したいと思います。

図4●一般的な仕様変更/仕様追加があった場合

　これは一番ポピュラーな仕様変更や仕様追加の場合です。その変更によって，業務フローや企業の戦略というレベルが変わるわけではなく，画面の変更や機能追加といった程度の仕様変更と仕様追加です。

　このレベルでは，要求開発を繰り返す必要はなく，せいぜい出てきた要求を要望分析シートで分析したり，要件ツリーと見比べることで，要求が意味があるかをチェックするぐらいで結構です。

図5●業務に影響がある仕様変更/仕様追加があった場合

　図5は，業務が変わる，つまり業務フローやビジネスモデルに変化が発生するレベルの仕様変更/仕様追加の場合です。業務が変わるわけですから，業務を変えて問題ないか，他に影響するところはないか，とったことを分析する必要があるので，ToBe業務フローから再度見直す必要があります。

図6●ビジネス戦略に影響がある仕様変更/仕様追加があった場合

　最後は，ビジネス戦略が変更になった場合です。こうなると，1プロジェクトどころか会社全体の戦略の変更になるので，当然，戦略レベルからの見直しが必要になるでしょう。しかし，さすがにここまでの変更は滅多におこらないでしょう。

　3回に分けて「要求開発とアジャイル開発」についてお話ししました。主に，XPを初めとするアジャイル開発で，あまりプロセス化されていない「顧客」側のプロセスに要求開発を適用するとどうなるかを説明してきました。

　「要求を出す」という行為は簡単そうですが，実は，プロジェクトを企画して予算取りできるほどの「意味のある要求」を出すのは難しいことです。変化の多い世界のなかで，すばやく開発された「要求」や「ビジョン」をいかに速くシステム化し，フィードバックを得るか，がこれからのIT化の大きなポイントだと筆者は考えています。

　今回のお話が皆様のお役に少しでも立てたならとてもうれしく思います。