システム開発・ソフトウェア開発の世界に、アジャイル開発やXP（エクストリーム・プログラミング）が登場したのは10年ほど前のことである。従来のウォーターフォール・モデルに対抗する新しい開発手法・開発方法論として注目された。しかしながら、「ウォーターフォール・モデル」対「アジャイル」という、単純な対立概念で捉えるのは必ずしも正しい見方ではない。
Webサービス・Webアプリを開発するソフトウェア・ベンダーは、アジャイル手法に積極的に取り組んでいるようだが、企業の基幹業務システムを開発するSI案件では、依然として従来からのウォーターフォール・モデルで開発するケースが多いと感じる。
SIベンダーの場合、ウォーターフォール・モデルをベースとした、ベンダー独自の方法論が確立されており、多くの実績を積んできている。さらに、品質や見積りのベースとなる基礎データを蓄積してきている。このことが、ウォーターフォール型の開発が多い一つの要因だと思われる。
先に、ウォーターフォールとアジャイルは単純な対立概念ではないと書いた通り、昨今はウォーターフォール型の開発であっても、プロトタイピングやテスト・ファーストの思想を取り入れるなど、変わりつつある部分も見られる。
ここでは書籍「XPエクストリーム・プログラミング入門 ～変化を受け入れる～ 第2版」（ケント・ベック著、ピアソン・エデュケーション）を中心に、XP手法の特徴を、時にウォーターフォール・モデルと対比しながら見ていく。
この書籍「XPエクストリーム・プログラミング入門 ～変化を受け入れる～ 第2版」の内容は、方法論や手法の解説書というよりは、むしろ哲学・思想に近い。また、「第2版」とあるとおり、「第１版」出版以降の著者の経験則を取込んで大幅な改訂が行われている。
本書を理解するためには、まず基本的な用語の定義を把握しておく必要がある。XPの枠組みを表す用語に、「価値」、「プラクティス」、「原則」があるが、これらの用語の定義が少々変わっていて分かり難い。
「価値」は、全体を捉えて判断する基準や、その能力と定義されている。
企業経営における「ビジョン」の概念に近い。すなわち、どのような戦略をとるべきか、どのような企業行動が望ましいか、それらを判断する際の基準になるものである。
「プラクティス」は、実際に行うことである。
「原則」は、価値とプラクティスの隔たりを埋めるものと定義されている。
「規約」や「ルール」、「ガイドライン」の概念に近いと思われる。
XPの特徴として、大きく2つ挙げることができる。
ひとつは、非常に優秀なSE／プログラマーを前提にしていること。
今一つは、要求仕様も設計も常に変化し、進化することを前提にしていること、である。
最初の「非常に優秀なSE／プログラマーを前提にしている」という点は、個人のみならず、開発チームについても少数精鋭部隊を前提としている、ということである。
実際、本書の中でも「XPは、ソフトウェアについての信頼性の高い見積り、実装、配置を迅速に行うことができる、強力なプログラマーが増えることに依存している」と書かれている。
優秀なSE／プログラマーとは、専門知識が有り、プログラミング能力、設計能力が高いということ“だけ”を指しているのではない。他のメンバーと協調し、常に仕事に対する改善意欲を持ち、主体的に行動できる人材を指している。
これだけの優秀な人材と、優秀な人材を集めたチームであれば、どのような開発手法であってもプロジェクトを成功に導けるのではないか、と思ってしまうが・・・。
一方、日本における大規模SI案件のプロジェクト組織は、どのようなものであっただろうか？
ピーク時の開発要員が100名、200名、あるいはそれ以上というような大規模案件では、まずそれだけの要員を集められるということがSIベンダーの力量であった。SIベンダー（1次請け企業）の要員だけでは人数が足りず、SIベンダーの関連会社や協力会社や、さらにその2次請けや3次請け企業まで動員して人を集める。
当然ながらプロジェクト体制は複数の会社の社員から構成され、さらにそれらの会社と契約を結ぶ個人事業主なども混じっている、というのが、ごく普通の姿であった。
このような寄り合い世帯であるから、メンバー間の情報共有・コミュニケーションや、プロジェクトへの貢献意欲を高めることが最初のハードルになる。
このように、今までの大規模SI開発は、とにかく必要人数を集めることに注力し過ぎていたように思われる。
今後は、XPが標榜しているような「優秀なSE／プログラマーと、少数精鋭部隊」による開発を目指すべきであろう。少なくとも国内で開発する場合は、オフショア開発に勝るコストパフォーマンスを発揮できる体制が要求されるはずである。
オフショア開発を上回る開発生産性・費用対効果をあげない限り、SE／プログラマーが国内の開発で生き残ることは不可能であろう。
XPの今一つの特徴である、「要求仕様も設計も常に変化し、進化することを前提にしている」点を考えてみる。XPのこの特徴は、ウォーターフォール・モデルと大きく異なる点である。ウォーターフォール・モデルでは、要件定義工程で要求仕様を確定することが前提になっている。要件が増えたり、あるいは変更になる前提では、基本設計以降の見積りが出来ないからである。
では、XPはこれをどのようにコントロールしているのか？
XPは、短いスパン（通常は1週間や2週間の単位）で、要求仕様の定義と実装を、インクリメンタルに繰り返すことでコントロールしている。
要求仕様は小さく切り出されて、優先度の高い順に実装され、目に見える形でユーザーに提示される。切り出された要求仕様は、ストーリーと呼ばれる。短いスパンで実装されるから、出来上がったものがユーザーの要求通りのものなのか、あるいは要求と異なる部分があるのかが、すぐに確認できる。
早い段階で実物を確認できるという点が、XPの優れたところであろう。ウォーターフォール・モデルの場合、ユーザーは下流工程（テスト工程）で初めて実際のシステムの動きを目にすることになる。
さすがに、ユーザーの要求と全く違うものが出来上がっていた、というようなことは、実際にはほとんどないが、追加要望や改善要望はある程度出てくるものである。
ウォーターフォール・モデルで注意が必要なのは、開発ベンダー側が、ユーザーの業務や業界の知識を充分に持っていないケースである。この場合、ユーザーの要求と実際に出来上がったシステムとのズレが大きくなるリスクはかなり高い。従って、このようなケースでは、設計段階でプロトタイプ手法を導入するなどの対策を打つべきである。
XPのインクリメンタルな開発手法は優れているが、危惧する点が無いわけではない。
コストとスコープのコントロールが難しそうにみえる。
ウォーターフォール・モデルでは、上流工程でスコープ（開発範囲）と要求仕様、および設計工程以降の見積りが確定する。
一方、XPは優先度の高いストーリーから実装していくが、スコープを全て実装し終わるまでの期間とコストのコントロールが難しいように思われる。
優先度の高いストーリーから実装していき、時間とコストが計画値に達したら打ち切る、ということも考えられるが、基幹業務系のシステムでは、スコープに満たない段階で開発を終了するのは難しいと考えられる。
以上見てきた以外にも、XPやアジャイル開発には、ペア・プログラミングやテスト・ファースト、継続的インテグレーション、などの特徴があるが、これらの話題はまた別の機会に考察することとしたい。
繰り返しになるが、これらの手法は必ずしもウォーターフォール・モデルと相対するものではない。メリットのある手法は取り込んでいくべきである。 |
