アジャイル開発と反復開発の落とし穴：ソフトウェア開発の匠（4）（2/3 ページ）

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

アジャイル開発は、反復開発のアンチテーゼ？

　アジャイル開発は、反復開発のアンチテーゼという見方もあるだろう。せっかくウォーターフォール開発という官僚的で、楽観的なプロセスから脱出する時代が到来すると思ったら、また反復開発という親せきがやってきたからだ。

　ITエンジニアとしてはもっとイノベーティブな開発にチャレンジしたいし、本当にユーザーが望んでいる要求を価値重視で開発したいという反発の思いから、アジャイル開発がブームになったのである。

　このようにアンチテーゼとしてとらえると、アジャイル開発コミュニティにおいては極端に特徴を強調しすぎる傾向にあり、アジャイル開発・反復開発それぞれの考えは両極端である。しかし、それらの考えは時代とともにバランスが良くなってきている（図4）。例えば、アジャイル開発はXP（Extreme Programming）の時代より、計画性や見積もりが重視されたり、設計やモデル、そしてプロセスを重視する傾向になってきている。また、FDD（Feature Driven Development）といったアジャイル開発プロセスなどが、どちらかというと反復開発に近い考えであるにもかかわらずアジャイル開発の一種とされているのも興味深い。

図4　アジャイルと反復開発の発展

　一方、反復開発は、アジャイル開発の思想を取り入れることになる。実際にRUPをアジャイルで適用するような開発手法が出てきている。

　このような状況で、われわれは両者をどうとらえるべきなのか。端的には、アジャイル開発や反復開発といった表面的なもの（名前）にとらわれず、本来あるべき開発プロセスを自ら考えていくべきだと思う。ソフトウェアを開発するプロセスはまだまだ未熟なのだ。

　さて次は、反復開発とアジャイル開発の弱点に迫る。弱点を知ることで、それらの弱点をカバーしたプロセスを確立してほしい。

反復開発の落とし穴

●1．要求が収束しない

　反復開発であるRUPでは、要求定義が下位フェイズまで続いている。図5でいうと、要求定義（Requirements）が、Inception（方向付け）から始まり、Elaboration（推敲）、Construction（作成）、Transition（移行）まで続いている。曲線で描かれた面は作業量を示している。方向付けフェイズと推敲フェイズに多くの要求が定義され、移行フェイズまで続くということである。

　これは、ビジネスの変化に対応するための対処としては自然であるが、実際に日本的なシステム開発で使う場合、要求定義が収束しないためにプロジェクトが破たんする恐れがある。そういう観点で見ると、この絵には矛盾がある。本来ならば、ビジネスの変化から要求が永遠に出続け、その要求に対して永遠に開発を進めるような並行ラインのプロセスの絵にしなければならない。

　しかし、この絵ではライフサイクルが1プロジェクトに収まっている。つまりいずれはプロジェクトが終わり、納品され、実際に使われる環境に移行しなければならない。だとすれば、推敲フェイズの第1反復辺りで要求をコミットさせる必要がある。それ以降の要求は調整・変更程度にとどめない限り、プロジェクトは破たんする。

図5　RUPの概要。出典：『The Rational Unified Process』（Philippe Kruchten著、2000、Addison Wesley）

●2．ビジネスモデリングの位置付けが問題となる

　図5の中に「Business Modeling」があるが、少なくともシステム開発プロジェクトのスコープでビジネスモデリングを行う価値はあまりない。逆に弊害の方が多いかもしれない。中途半端が一番よくないのだ。

　ビジネスモデリングを行うプロセスは、プロジェクトライフサイクルや範囲が、システム開発プロセスとは異なる。よって、本来、RUPの方向付けフェイズは、システム開発プロジェクトよりも大きなスコープであるビジネス開発プロセスで行うべきだ。つまりは、筆者の推進している要求開発の視点で行うべきなのである。

　このビジネス開発プロセスでは、そもそもシステム開発プロジェクトの単位を決めたり、必要性を判断したりするのである。それをシステム開発プロジェクトが始まってからビジネスモデリングということで行っても意味がない。

　しかしながらRUPプロセス提唱者は開発プロセスにビジネスモデリングを入れてしまった。この気持ちは分からなくもないが、非常に安易な決断だったと思われる。

　またビジネスモデリングという言葉自体、現在のビジネスをモデリングするといった誤解を招きかねないものである。実際は、システムの対象となるビジネスの姿をモデリングするのであるが、そこには通常、現状モデル（AsIs）、将来モデル（ToBe）といったモデルをどのようにプロセスとして扱うのか明確な指針が必要となるはずだ。

　取って付けた感のあるビジネスモデリングによって、多くの利用者に誤解を生み、視野の狭いビジネスモデルによって投資コストの割には成果が出せないでいるのではないかと心配になる。

●3．推敲フェイズにおけるミッションが多すぎて動きが鈍くなる

　推敲フェイズは、ユースケースドリブンと、アーキテクチャセントリック（アーキテクチャ重視）で開発を計画するという、相反する2つの観点で反復計画を立てることになる。この際、リスクの高そうなアーキテクチャとユースケースを、できるだけ早い段階で開発の対象とするだろう。このことから、推敲フェイズの最初の反復は、主要なユースケースやリスクの高いユースケースを動かすことと同時に、アーキテクチャの全体像を確立するというミッションを抱えることになり、慣れていないと結構大変なことになる。不慣れなアーキテクチャや新規アーキテクチャで開発が必要な場合は、前段階、例えば方向付けフェイズの段階で検証・試作が必要とされる。

●4．管理志向が強すぎる（モチベーションダウン）

　反復開発は管理志向が非常に強いために、開発者のモチベーションを著しく低下させてしまうことがある。この対策はアジャイル開発を大いに見習うべきである。

●5．モデリングが非効率

　これは、第1回「『ITエンジニアは職人気質を取り戻すべき』」で取り上げた、ユースケースドリブンによるユースケースからロバストネス分析、そして概念モデル、設計モデルと流れていく方法の冗長性のことをいっている。RUPを行う場合には、このようなやり方を習うのであるが、効果を考え、もう少し洗練させていく必要性がある。