アジャイル開発の広範な普及を目指してThe Rational Edge(1/2 ページ)

The Rational Edgeより: アジャイル開発手法は何年も前から一部の組織でうまく利用されてきたが、大部分のソフトウェア企業ではそのテクニックがまだ採用されていない。その理由を探り、業界にアジャイル手法をもっと浸透させる可能性を秘めたトレンドを解説する。

» 2008年05月08日 12時00分 公開
[Per Kroll(Manager of Methods, IBM Rational, IBM),@IT]

 米Standishグループの「Chaos Report」によれば、システム開発プロジェクトの72%が失敗に終わるか問題[注1]に直面するとある。さらに、実装された機能の45%が一度も使われず、ほとんど使われないものも19%ある(図1)。そして、最も気掛かりなのは、プロジェクトを明らかに成功に導くはずの手法(その多くはアジャイル開発手法、もしくは類似の手法)が採用されないケースが多いという部分だ。

ALT 図1 実装された機能の大半は、ほとんどもしくは一度も使用されない。

▼注1: プロジェクトが完了して運用が始まるが、予算オーバー、納期の遅れ、当初指定された仕様や機能の漏れが出る。


 アジャイル開発は何年もの間効果的に利用されてきており、プロジェクトの結果の見通しが非常に明るいにもかかわらず、その採用は主に企業や組織のごく一部に限られてきた。最近では、保険、通信、および金融といった業界ではその採用が増え始めてきた。

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

 しかし、アジャイル開発が主流になるには、業界の主力ベンダによる支援、散在しているアジャイル開発環境の統一、そしてアジャイル開発手法への段階的な移行シナリオが必要となる。アジャイルへの大規模な移行には、ナレッジの大規模な伝達、必要な人事ポリシーへの取り組み、そしてスケーラブルなツール環境などのサポート向上が必要だ。最後に、大規模開発プロジェクト、地域分散型開発、そしてコンプライアンスなど、大きな組織が直面する開発の問題にも対応する必要がある。これら各分野で進んでいる有望な作業を見ていこう。

安全策を探す主要企業

 マーケティング・コンサルタントのジェフリー・ムーア(Geoffrey A. Moore)は著書「Crossing the Chasm」[注2]の中で、製品がアーリーアダプター向けの先進技術から市場で幅広く普及したものへと移行を果たすには、どんどん増加する消費者の大部分にその魅力を訴える必要がある、と指摘している。大部分の主だった組織は、未知の分野に足を踏み入れるよりも、自分たちが安全策だと見なすものを好む。彼らは最新技術よりも市場リーダーを好み、斬新なパラダイムシフトよりも継続的な改良を好む。


▼注2: 『Crossing the Chasm』(Geoffrey A. Moore=著/Collins/2002年)

▼編注: 『キャズム』(ジェフリー・ムーア=著/翔泳社/2002年)


 ムーアの意見がアジャイル開発を主流にすることとどのように関連しているのか見ていこう。

■ 業界の主要ベンダーによるサポート

 アジャイル市場には、オブジェクト・メンター、マウンテンゴート・ソフトウェア、ネット・オブジェクティブス、クアドラス、そしてインダストリアル・ロジックなどのサービスベンダや、ラリー・ソフトウェア・ディベロップメントやバージョン・ワンなどの製品ベンダなど、規模の小さいベンダが参入している。これらの大半は従業員100人以下の企業だ。これまでのところ、サービスや製品の主力ベンダは参入していない。だが、こうしている間にも状況は変わりつつある。

 世界最大級のシステムインテグレータ各社が、アジャイル開発に注力し始めている。IBMグローバルビジネスサービスも、アジャイル開発とアジャイル移行に重点を置く「Accelerated Solution Delivery Practice」を投入したばかりで、キャップジェミニはアジャイル開発プラットフォームへの投資を進めており、コグニザントやITC インフォテック・インディアといったインドの複数のシステムインテグレータもアジャイル開発への進出を進めている。

 主要ベンダ各社は、アジャイルツールとプロセスへの投資を進めている。IBMは先ごろ、アジャイル・コラボレーション開発を中心に据えた次世代技術プラットフォームの「Jazz」を先行公開した。Microsoftも先日、アジャイルプロセスの「MSF for Agile」を投入し、IBM、テレロジック、コバンシス、キャップジェミニをはじめとした大小15社のベンダが、アジャイルプロセスに重点を置く「Eclipse Process Framework」(以下、EPF)[注3]の開発に携わっている。


▼注3:www.eclipse.org/epf/を参照。


■ 乱立するアジャイルプロセスの統一

 アジャイル開発の人気が高まるにつれ、アジャイルプロセスの数も増えつつある。XP、スクラム、OpenUP、AUP、DSDM、リーンソフトウェア開発、アダプティブソフトウェア開発、Rational Unified Process(RUP)、MSF、FDD、クリスタルクリア、EssUP、そしてアジャイルモデリングなどがその例だ。

 これらのプロセスの多くは、ソフトウェア開発ライフサイクルの特定の分野しかカバーしていない。その一例として、スクラムはプロジェクトと要件管理の分野しかカバーしておらず、ライフサイクル全体に対応するにはXPやアジャイルモデリングなどのほかのプロセスとの統合が必要になる。異なるプロセスの統合は難しく、時間もかかり、主流ベンダ各社は投資に否定的だ。

 だが、EPFプロジェクトはプロセスの統合問題にも対処している。EPFはオープンソースで、ソフトウェアのベストプラクティスを目指すプラットフォームのオーサリング、コンフィギュレーション、そして導入を実現する。このプロジェクトは2007年初めに立ち上がり、OpenUP、XP、スクラム、DSDM、そしてアジャイルモデリングなど、多くの主要アジャイルプロセスがEPFに対応済み、もしくはもうすぐ対応する予定だ。

 EPF内部では、これらすべてのアジャイル手法を活用し、いずれは再利用可能なアジャイルプロセスコンポーネントを開発したいと考えている。これらは、組み合わせることでOpenUP、XP、およびスクラムといった異なるアジャイルプロセスや、独自のアジャイルプロセスを作成できる。プロセスコンポーネントは、企業や組織が登録や修正を行ったり、自分たちで利用したり、無償提供もしくは販売することもできるはずだ。

■ 進化か? それとも革新か?

 アジャイル開発は、突然のパラダイムシフトだと表現されることが多い。多くの企業にとって恐ろしい話である。アジャイルへの移行は終わりのない旅のようにもなる。四半期ごとに新たなプロジェクトを移行させ、毎回移行プロセスについて学ばせ、それを向上させることもできる。一度に複数の手法を投入することもできる。例えば、まずは反復とテスト主体で開発に着手し、その後にペアプログラミングやチーム開発を導入することもできる。

 自己管理チームなど特定のアジャイル手法は、確かに真のパラダイムシフトだ。チームメンバーを全体の意思決定に従わせることと、自分の仕事や運命を本当の意味で自己コントロールさせることでは、大きな違いがある。チームが難しい判断を迫られ、メンバーが自分たちの上司に判断を仰いだ結果、「お茶を飲んでくるので、自分たちで決めて知らせなさい」などといわれたら、誰が管理職なのかまったく分からなくなってしまう。だが、それが新たなレベルのコラボレーションと熱意を生み出し、生産性を大幅に増加させることも多いのだ。

 アジャイルへの移行によって組織のどの部分が影響を受けるのか、またどのような責任が必要なのかも明確にする必要がある。テストへのアプローチ方法、動機付けや報酬の手段、IT部門と業務ラインとのコラボレーション、開発環境……。これらを修正する準備ができていないところには、アジャイルへの本格的な移行は向いていない。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.