「高品質・低コスト・短期間」が重視され、グローバル化とニーズの多様化が進む近年のソフトウェア開発。

従来の「最初に決めた計画どおりに進めていく」方法論だけでは、仕様変更や予想外の不具合にうまく対応できず、余計なコストや手間がかかってしまうケースが増えています。

こうしたリスクを最小限にとどめ、かつ、顧客の満足度を高めるにはどうすればいいか──。

そんな発想から生まれ、発展してきたのが「アジャイル開発」という手法です。

活用が広がるアジャイル開発の導入メリットや適したプロジェクトから、導入する際の注意点などまでを解説します。

アジャイル開発とは？

短期間で「設計→実装→テスト」を繰り返す

ソフトウェア開発では、成果物をリリースするまでに、大きく分けて「要件定義」「設計」「実装」「テスト」の各プロセスをたどります。

これまでの開発では、ソフトウェア全体の「設計」が終わったら「実装」を開始し、全体の「実装」を完了させたら「テスト」に進む形で、プロセスの一つ一つを頭から順に進めていくのが一般的でした。

一方「アジャイル開発」では、開発予定のソフトウェアを細かい要素に分割し、要素ごとに「設計→実装→テスト」のサイクルをくり返しながら、結果を検証。

テストの結果、明らかになった問題や顧客の要望に応じ、要素ごとに修正・改良を加えながら開発を進めていきます。

工業製品のモジュール化のように、ソフトウェアを構成する「要素ごと」につくり上げていくアプローチだと考えれば分かりやすいでしょう。

「設計→実装→テスト」の1サイクルは「イテレーション（反復）」と呼ばれ、一つのイテレーションには1?4週間くらいかけるのが一般的です。

アジャイル開発のメリット

リスクを最小化しながら柔軟な対応を可能にする

アジャイル開発の「アジャイル（agile）」は、英語で「機敏な」「頭の回転が早い」などの意味。

名前の通り、細かなイテレーションを効率的に積み重ねていくことでリスクを最小化し、従来に比べて素早く開発を行いながら、仕様の変更に臨機応変な対応ができるようになっています。

開発では、最初に細部まで決め込んだ「要件定義」を行う形ではなく、大まかな「リリース計画」を決めたら、スピーディーに設計に入ります。

アップデートが頻繁に要求されたり、手戻りの必要が生じたりすることを想定し、計画のメンテナンスを重ねながら業務を進めていくわけです。

もし不具合が発覚しても、およそ1?4週間程度の1イテレーションで完結する部分の設計、実装、テストであれば手戻りの工数を抑えることができます。

ポイントは「機能がどのように動くのか」をイテレーションごとに顧客に確認してもらうことで、問題点を早い段階で洗い出せる点。

一方、従来の手法のように長期スパンで進行する工程の場合、不具合が発覚したタイミングによっては修正の影響が全体におよび、大きなロスにつながりかねません。

アジャイル開発では、確認の際に顧客から新しい要望が出た場合にも対応しやすいのがメリット。

さらに、工程が分割されているため「何の機能から進めるか」「どのプロセスが重要なのか」を判断し、選択できる利点もあります。

ソフトウェアの軸になる要素が完成したら、残る工程や必要な機能などを考慮して、その時点で最適な作業の内容とスケジュールを組み立てることもできます。

これらをまとめると、アジャイル開発は、仕様の変更や追加など、「当初の計画が変化していくこと」が予測されるプロジェクトに特に向いているといえるでしょう。

従来の開発手法との比較

大切なのは適切に使い分けること

もちろん、どのようなプロジェクトにおいても、アジャイル開発が最も適切な手法とは限りません。

案件の特性や規模によっては、「最初に決めた計画どおりに進めていく」開発手法が適していることもあるでしょう。

例えば従来の代表的な開発の方法として、「ウォーターフォール開発」があります。

ウォーターフォール、つまり滝が上から下へと落ちていくように、工程を一つずつ、順番に完了させていくスタイル。

最初にプロダクトの最終形をはっきりと描き、ゴールを見据えて「要件定義」「設計」「開発」「テスト」を順番に終わらせていくため、プロジェクト全体のスケジュールや進捗状況を管理しやすい利点があります。

伝統的に用いられてきた方法ですから、携わった経験が豊富なソフトウェアエンジニアも少なくないでしょう。

また、各工程を担うチームの役割も明確で、最小限のコミュニケーションで作業が成立するため、細かいやり取りの必要も減ってコミュニケーションコストを抑えやすくなっています。

アジャイル開発との大きな違いは、なんらかの変更点が発生した場合の対応力。

途中で「やはりこうしたい」と顧客から新しい要望が出されたとき、それまで進んでいた計画を大幅に見直すことも起こりえます。

ウォーターフォール開発は、比較的規模が大きく、仕様の変更が生じないものに向いていると言えるでしょう。

アジャイル開発とウォーターフォール開発のいずれを採用するかは、開発期間や託された予算に加え、変化の振れ幅をどのくらいに設定するかなど、さまざまな要素を加味して判断することが大切です。

アジャイル開発実践の心得

開発宣言の4つの価値がヒントに

では、アジャイル開発を導入するとなったとき、どのようなことに注意して進めていくべきでしょうか。

2001年に17人のソフトウェアエンジニアたちがまとめた「アジャイルソフトウェア開発宣言」の中に、ヒントが隠されています。

以下に全文を掲載します。

これらの「価値」を重視しながら、イテレーション単位の開発を進めることで、素早い開発、柔軟な対応といったアジャイル開発のメリットが実現されていくわけです。

留意すべき点としては、開発の方向がブレやすいことが挙げられます。

計画が変化することを想定しているとはいっても、「幹」となる部分を決めておかなければ、完成は遠のくばかりです。

仕様をある程度固めておくことはやはり重要になります。

また、プロジェクト全体の進捗管理がしにくい点にも注意が必要です。

開発は、最初に決めた「リリース計画」でプロジェクト全体を管理しながら、各イテレーションの実施計画となる「イテレーション計画」に沿って進めていきます。

常に開発プロジェクトの全体を見据えて優先順位をしっかり踏まえながら、進行状況を把握し、計画のメンテナンスを行うよう心がけましょう。

アジャイル開発のバリエーション

最後に、アジャイル開発のさまざまな手法について触れておきます。

ラグビーから名前を取った「スクラム」は、コミュニケーションに重点を置いた、チームで開発を行うための方法です。

ポイントは、スクラムを組むようなメンバーの協力体制づくりとチーム内の活発なコミュニケーション。

毎日の情報共有、イテレーションごとの計画・振り返りなどをチームメンバーが主役となって行い、プロダクトの最終的な決定権をもつ「プロダクト・オーナー」、プロジェクトのスムーズな進行をチェックする「スクラムマスター」などのサポートのもと、リリースに向けて力を合わせます。

「XP（エクストリームプログラミング／Extreme Programming）」は、名前からも分かるように、プログラミングに主眼を置いた手法。

開発メンバーは、初期計画に強くこだわらず、柔軟性を大切にしながら

• 円滑な「コミュニケーション」
• 「シンプル」な実装
• ユーザーによる頻繁な「フィードバック」
• 計画変更にひるまない「勇気」
• 互いの「尊重」

の5つの価値を共有し、コーディングとテストを繰り返しながら品質を改善していきます。

もう一つ、「FDD（ユーザー機能駆動開発/ Featured Driven Development）」と呼ばれる手法では、「顧客サイドにとっての機能価値（Feature）」の視点から開発が進められます。

開発単位となるのは「ユーザーにとっての機能」。

まずは、顧客のビジネスの「見える化」を行い、その分析に基づき、最小限のプログラムによって一つずつの機能を短期間で実装していきます。

ほかにもアジャイル開発では、最初にテストコードを書き、プログラムの実装と修正によってバグを減らしていく「TDD（テスト駆動開発 / Test Driven Development ）」など、さまざまな品質管理の手法が活用されています。

スクラムに象徴されるように、アジャイル開発のカギを握るのはチームの力。

新たな開発手法に挑戦してみることは、多職種による相乗効果が見込まれ、プロジェクトの管理やクライアントとの協働など、新たなステップアップのための経験値を高めるチャンスともなるはずです。