アジャイル開発とは

アジャイル開発が生まれた背景

アジャイル開発は、開発途上で何回も動くソフトウェアを開発依頼者に提示し、フィードバックや要求の変化を受けながら開発する方法です。アジャイル開発の登場は、ソフトウェア開発に関係するビジネスの変化が大きく影響しています。

ウォーターフォール型開発の長所と短所

ウォーターフォール型開発は、要求を開発初期段階に確定し、確定した要求に基づいて設計、実装、統合、テストを順次的に行う形の開発方法です。日本のソフトウェア開発プロジェクトの半分以上で採用されており、いまだ大勢を占めています。

ウォーターフォール型開発

ウォーターフォール型開発には以下のような長所があります。

  • 開発依頼者側の計画、契約の負荷(リスク)が小さい
    開発初期段階に確定した要求に基づいて計画や契約を締結すれば、要求の実現の責任をITベンダーに転嫁できる
  • 分業が可能
    開発を複数フェーズに分けて、フェーズ間で文書による引き継ぎを行うことでフェーズ毎に異なる開発者(役割)による分業が可能になる

この「分業が可能」という長所を利用して、日本ではソフトウェア開発において複数の階層にも及ぶアウトソースという形態が一般化しました。また、フェーズ間での引き継ぎのために作成される文書をレビューすることで品質を管理するというアプローチも広まりました。

つぎに、ウォーターフォール型開発の短所としては、以下のような点を挙げることができます。

  • 要求確定後の仕様変更が困難
    要求確定後に技術やビジネス状況の変化やビジネスニーズの理解が進んで要求を変更したいと望んでも、対応は次バージョン以降になる
  • 開発終盤に開発上の問題点が顕在化して遅れる
    統合段階やテスト段階でアーキテクチャー上の問題やサブシステム間のインタフェースの不整合などの問題が顕在化して納期が守れない

ウォーターフォール型開発の限界

欧米ではウォーターフォール型開発を適用するプロジェクト割合が半分以下に低下し、アジャイル開発を適用する割合が増えているということも報告されています。欧米でウォーターフォール型開発が減少している原因として以下のようなものが考えられます。

  • ビジネスや技術の変化にすばやく対応するための開発が求められている
  • ユーザー企業がある程度開発要員を抱えている

GoogleやSalesForceのようにクラウドでビジネスを展開する企業も、Appleのようにハードウェアデバイスやソフトウェアでビジネスを展開する企業も、Amazonのような販売でビジネスを展開する企業も競争に勝つために「ビジネスや技術の変化へのすばやい対応」を重視しています。「ビジネスや技術の変化への対応」というのは以下のことを意味します。

  • ビジネス形態(モデル)や市場の変化に対応する
  • 新たな技術(IT機器)を組み込んだり、移行したりする必要がある

これらの「ビジネスや技術の変化」を先読みするのは不可能に近いでしょう。また、変化に対応した製品やサービスを早く市場に投入しないと高い利益を得ることができません。そのために、ウォーターフォール型開発からアジャイル開発への移行が進んでいると考えられます。

また、同時に自社で開発要員を抱えているために日本ほど「開発委託側の計画や契約の負荷(リスク)」に対処する必要はありません。つまり、計画や契約が難しくないこともウォーターフォール型開発からアジャイル開発への移行が欧米で進んでいる理由になっていると考えられます。



アジャイル開発の特徴

90年代の後半に、顧客と開発者との密な協力に基づいて顧客に役立つソフトウェアを開発することを目指すXP(eXtreme Programming)[1]やスクラム[2]などの複数のアジャイル開発手法が登場しました。これらのアジャイル開発手法の提案者が2001年に集まってアジャイル宣言[3]を起草し、アジャイル開発の共通の価値と原則[4]を定めました。このアジャイル宣言の原則はアジャイル開発を進めるためのより具体的な心構えを述べており、技術者を含むプロジェクトの利害関係者がアジャイル開発を理解するための助けになります。この原則に述べられているアジャイル開発の特徴をまとめると、以下の4点になります。

  1. 反復的な開発
  2. 顧客との連携
  3. チームワークの重視
  4. 技術的な裏付け

A. は、1週間から1ヶ月程度の一定の周期で動くソフトウェアを作るという形で開発を進めるということです。この動くソフトウェアを作る1回の周期のことを「反復」と呼びます。A. については、反復の期間が固定であることを強調する「タイムボックス」という言葉で表現することもあります。

B. は、顧客と連携して顧客のビジネスの成功につながるソフトウェアを作るということです。そのため、反復毎にできるソフトウェアをレビューしたり、顧客を取り巻く状況の変化のためにソフトウェアに対する要求は変化しうると考えます。反復毎に、前の反復で作成したソフトウェアのレビュー結果や顧客の状況変化に基づいて顧客のビジネスの成功によりつながる方向へと開発を軌道修正することができます。

アジャイル開発

C. は、開発チームのメンバーの自律性や直接的なコミュニケーションを重視したチームの運営を行うということです。開発チームのメンバーの自律性という点では、従来のような縦割りで計画や作業の割り当てを行い、メンバーが与えられた計画や割り当てを行うというのではなく、開発チームのメンバー間の話し合いで計画や作業の割り当てを決めるということです。このように自律性を尊重することで、開発メンバーのモチベーションが高まり、より良い仕事のやり方を考える改善マインドが生まれます。

D. は、要求の変化の結果としてソースコードの変更が発生するが、そのソースコードの変更のコストをなるべく抑えるような技術的な工夫(プラクティス)を講ずるということです。アジャイル開発で広く使われている技術的なプラクティスとしては、以下のようなものがあります。

  • テスト駆動開発(TDD: Test Driven Development):プログラムコードを書くときに、そのコードを検証するためのテストコードを書くというもの
  • リファクタリング:既に書いたプログラムコードの機能を保ったまま、プログラムコードの品質を高めるための改良を行うこと
  • 継続的なインテグレーション:各開発者が開発した本体コードとテストコードが蓄積された構成管理ツール内のコードを自動的にビルドし、テストコードを自動実行し、その結果を開発メンバーに通知するというもの

これらのプラクティスにより、加えたプログラムコードの変更による回帰エラーの発生をすぐに検知したり、プログラムコードの変更が広範に波及しないようにプログラムコードの品質を高めることが可能になります。このような回帰エラーの迅速な検出やプログラムコードの品質向上によりソースコードの変更コストを削減することができます。

>> アジャイルでもっとも使われている手法スクラムの説明はこちら



参考文献

[1]ケント・ベック, XPエクストリーム・プログラミング入門―変化を受け入れる, ピアソンエデュケーション, 2005
[2]ケン・シュエイバー, マイク・ビードル, アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
[3]アジャイル開発宣言, http://agilemanifesto.org/iso/ja/manifesto.html
[4]アジャイル宣言の背後にある原則, http://www.agilemanifesto.org/iso/ja/principles.html




アジャイル・スクラムに関するトレーニングのご案内

オージス総研ではアジャイル開発をこれから学びたい方、スクラムをこれから現場に取り入れたいと考えている方向けにアジャイルやスクラムに関するトレーニングを実施しています。いずれも演習を通じて理解を深めていただける内容です。

  • 体験!アジャイル超入門(0.5日版)  
    アジャイル開発をこれから学びたいお客様に向けた入門トレーニングコースです。アジャイル開発で使用される用語や考え方(価値と原則)を学習し、アジャイル体験ゲームの演習によってアジャイルの概要を体験します。ソフトウェア開発者だけでなく、アジャイル開発に関連する管理者やユーザ部門の方にもおすすめできる内容です。
  • スクラム入門  
    スクラムを採用したプロジェクトの進め方を段階的に学習する入門トレーニングコースです。ブロック玩具を使った演習でスクラムの基本概念の理解を深めます。スクラムに関する知識を習得したい方、スクラムを現場に取り入れたいと考えている方を対象としたトレーニングです。


※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。