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

2007.03.22

　現在のシステム開発プロジェクトの状況を見ると，いわゆる生産管理，経理といった従来からある業務のシステム化といったプロジェクトに加えて，Webシステムに代表される，従来無かったような新業務に対するプロジェクトが増加しています。

　そうした業務のシステム構築は要件を固めにくく，予想もしにくい状況にあります。また，ビジネスの変化に伴ってシステム自体も非常に変化が激しいという特徴を持つことが多いようです。

　そのような現状において変化に強い「アジャイル開発」は非常に魅力的です。本稿では，顧客サイドからの視点で「アジャイル開発」を総括し，「アジャイル開発」を行うときの，「要求開発」の可能性を検討してみたいと思います。

アジャイル開発とは
　XP（eXtreme Programming）に代表される繰り返し型の開発方法論をさします。特徴としては現場サイド（プログラマ）から出てきた開発方法論であり，変化に柔軟に対応する能力が高く，「シンプル」であり，「人」や「コミュニケーション」を重視した手法になっています。大規模で，人数の多いプロジェクトには向かず，比較的少人数のプロジェクト（25名以下）を対象にしたものが多いようです。

　アジャイル開発手法は，下記のアジャイル開発宣言を満たすような開発手法です。

プロセスやツールよりも，個人と相互作用
包括的なドキュメントよりも，動作するソフトウエア
契約交渉よりも，ユーザーとの協調
計画に従うよりも，変化に対応する

　アジャイル開発の詳細な説明は本稿の趣旨ではありませんので，ここでは深くは触れません。興味がある方はWebサイトや書籍を参照してみてください。

顧客から見たときのアジャイル開発の特徴

　アジャイル開発手法の中でも最も特徴的なXPを例にとって，顧客から見たときのアジャイル開発の四つの特徴を整理してみましょう。

プロセス/ツールと人間の関係
変化への柔軟な対応
開発側と顧客側の関係
ドキュメントとアプリケーション

　以降，それぞれについて説明します。

1.プロセス/ツールと人間の関係

　開発手法の中には，人間の属人性をなるだけ無くして，あたかも人間を歯車のように使うような手法が多くあります。

　プロセスやツールというものはいつも誇大広告される傾向にありますが（効果が無いという意味ではありません），実際に良いソフトウエアを効率よく，プロジェクトを失敗させることなく開発するためには，ツールや方法より「人」が一番重要です。余談ですが，筆者もこれまで，いろいろな制約の中で極力「できる人」を集めてプロジェクトを実施してきました。

※アジャイル開発手法や要求開発も「手法」ですので，地に着いた方法で，目的を常に見失わないようにして活用していくべきと考えています。

　そして，プロジェクトは感情を持った「人」がやっているという観点も忘れてはなりません。また人の頭にある情報は，ドキュメントにした程度ではなかなか他の人には移転しません。そのために暗黙知を含む「コミュニケーション」が大切です。

2.変化への柔軟な対応

　これは，顧客側から見たときの「アジャイル開発」の大きなアピール・ポイントです。普通の開発では顧客側は「早く要求をFIXしてください」と言われることが多いと思います。しかし，アジャイル開発では，「変化を抱擁する」ことが当たり前になっていますので変化を歓迎します。

　アプリケーションやプロセス自体が，変化に強くなるように考えられているのです。変化しても，バグがたくさん出たり，設計がむちゃくちゃになってしまわないような工夫も施されています。

　ここで，アジャイル開発（XPの例）の場合に，要求がどのように実現されて，変更がどのように実装されるのかというイメージを簡単に説明しましょう。

　XPでは，要求は「ストーリ」という単位で記述されます。これは顧客がわかる言葉で書かれた要求です。その要求を実行するのに2週間以上かかる場合は，分割します。UMLで言うと「ユースケース」にあたり，その簡易版のようなものと思っていただいて結構です。

　そして，顧客が出した「ストーリ」を実装するために必要な作業を「タスク」として分解します。これは開発側が行います。

図1●ストーリとタスク

　さて，XPの大まかなプロセスは下記の通りです。

図2●XPのプロセス
なお，ピュアなXPのプロセスでは，受入テストは各イテレーションの中に組み込まれているので，ここで記述した最後の「受入テスト」はありません。しかし，筆者がXPを適用したプロジェクトでは，本番のリリースは最後の1回だけで，それまでのリリースはお客様にモノを見せてアーキテクチャ検証をする意味合いが濃く，本番前にこのようなフェーズを設置することが多かったので，ここでも図示しています

(1)リリース計画

　この先3カ月ぐらいで実装して欲しいストーリを要求として出して，各ストーリを開発側が見積もり，どのイテレーションで実行するかのプランニングを行います。

(2)イテレーション

　イテレーションというのは，1～4週間のアプリケーションを作成する時間単位です。XPではこの「イテレーション」を繰り返してアプリケーションを開発していきます。

図3●イテレーションの内容

(3)計画ゲーム

　イテレーションは，「計画ゲーム」－「開発」－「受入テスト」という流れになります。顧客は「計画ゲーム」で，このイテレーションで実装するストーリをもう一度検討します。最初のリリース計画で検討したものが基本ですが，イテレーションを行っていくなかで，いろいろ変更が出ることがあるので，変更がある場合はそれも「ストーリ」として提出します。

図4●計画ゲームの内容
[画像のクリックで拡大表示]

　ここで出てきた「ストーリ」に対して開発側が作業見積を行います。顧客は，作業見積の結果を見ながらどれを今イテレーションで実装するかを決定します。ただし，開発チームが受け入れられるだけの工数ぶんしかお願いできません。そのため「ストーリ」を取捨選択し，優先順位の判断を行う必要があります。

　イテレーションで実装する「ストーリ」が決定されたら，開発チームはそれを実装し，顧客はイテレーションの最後に受入テストを実施して，OKならばそのイテレーションは完了といった流れです。

　このようなイテレーションを行うことにより，顧客には下記のようなメリットがあります。

実際に動くアプリケーションを見て仕様を決定できる
変更を受け入れてもらえる。変更のコストが少ない
変更しても変更のコストが上がらない（普通は変更すると設計が崩れて，変更も保守もだんだん大変になる）
プロジェクトの最初に仕様をFIXしなくてもよい
仕様のミスがプロジェクトの初期で発覚しやすい
ストーリの見積もりが出るので，「コスト」で取捨選択しやすくなる

　逆に，以下の点を忘れないようにしないといけません。

変更や仕様の出し入れに対しては柔軟でコストも少なくて済むが，無限に変更ばかりしていては終わらない（だからリリース計画がある）
「仕様の固定」で縛りがない代わりに，「チームの工数と時間」を縛りにしている。工数が多くかかる変更をすれば，仕様の出し入れが必要になり，期間が延びたりする。「チームの工数」を上回る作業を実施する場合は，要員計画を変更してプロジェクト・コストが増額される

　だからといって，仕様を無理矢理FIXしたりすると，後から仕様変更の追加請求が発生してしまいます。まとめると，

変化には強いが，タダでもなく，時間も必要である（ただし，通常の手法よりはかなりマシである）

3.開発側と顧客側の関係

　XPでは，開発側と顧客側の役割が明確です。単純に言うと「システムのことは開発側が決定し，要求に関することは顧客が決定する」のです。

　普通のプロジェクトでは，例えば「概要設計書」や「方式設計書」などの開発側が作ったものを顧客がレビューしてはんこを押します。つまり，アプリケーションの中身に関しても顧客が責任を持っています。後で変える場合は，当然仕様変更費用が発生します。

　これに対してXPでは，顧客は要求やビジネス上の決定だけに注力し，開発側がアプリケーションをどんな「作り」にするのかは決定権がありません（もちはもち屋です）。ただし，どんな「作り」にするのか，他にどんな実現方法があってそれぞれいくらかかるのか，といったことを聞くことができます。また，開発チームの能力が低い（何をするにも高いなど）の場合は，そのチームを解雇するといった対応をします。

　その他，通常の開発では，開発側と顧客側の関係が契約内容や作業に関して険悪になることもよくあります。XPの場合は，精神論的ではありますが，顧客と開発側が一つのプロジェクトの成功にフォーカスして，無駄な対立はやめようというポリシーもあります。

　開発チームがきちんとしたアプリケーションを作れるスキルがあると想定すると，それは顧客に下記のことを要求します。

顧客が出す要求が価値のあるものであることを顧客が保証しないといけない（これはアジャイルでなくても同じ）
顧客は要求の優先順位をつけて，開発が見積もるコストとのトレードオフによって実装すべきか否かを判断しなければいけない

　また，システムのことは開発側が把握しておくものなので

データベースの構造（などシステムの構造）もシステム側が決定する

　という特徴もあります。

4.ドキュメントとアプリケーション

　これは，“ドキュメントをコテコテに書くよりも，実際に動くアプリケーションを作って，アーキテクチャや仕様がちゃんと実装されているかを確認しよう”という考えです。

　また，いくらアプリケーションが変更に強くても，大量のドキュメント修正があれば，プロジェクトとしては変更に強くなりません。そのためアジャイルでは，ドキュメントは必要最小限にとどめて，アプリケーションを変更しやすくしています。

　なぜそれが可能なのかというと，たとえドキュメントが必要最小限でコードしかなくても，シンプルでわかりやすく，保守のしやすいアプリケーションを作るプラクティス（テスト駆動やリファクタリング，共同所有，継続インテグレーションなど）が存在するからです。

　ここでのキーワードは「フィードバック」です。顧客は，実際に動くアプリケーションを見ることで「フィードバック」を得て，仕様を考えることができます。

　通常だと，開発側は紙の要求仕様書のレビューを求められて，それにはんこを押すと，その後の変更にはコストが発生します。とはいえ，紙の仕様書を見てコレでいいのか，あっているか，などといったことは，よほどこなれた業務とシステムでないと判別は難しいでしょう。また，プロジェクトが経過すると，ビジネスが変わったり，最初はこう思っていたけど実際作ってみるとこっちのほうがいいことがわかった，といったこともよくあります（変化への柔軟な対応もフィードバックのうちの一つですが…）。

　ドキュメントは，必要ならばイテレーションがすべて終了した後に作成したりします。ドキュメントは必要なものだけ作成します。たくさん作りすぎることは，ドキュメントの陳腐化と変化への対応の遅れにつながります。

　顧客は，前述のように，アプリケーションの良しあしを「実物」で判断していきます。ここで顧客が覚悟しなければならないことは下記の通りです。