めまぐるしく変化し続けるIT業界では、短いスパンで開発を行い、要求の変化や追加に柔軟に対応しながら開発を行う「アジャイル型」という手法が主流になってきています。
本記事では、アジャイル開発の概要や手法の解説、他の開発手法との相違点なども交えながら、アジャイル開発で価値を生み出すためのポイントについて解説します。
目次
1.1 アジャイル開発の概要
1.2 アジャイル開発の原則
1.3 アジャイル開発はどんなシステムに向いているか
2.1 スクラム
2.2 エクストリームプログラミング(XP)
4.1 目的の明確化
4.2 組織全体で「アジャイルによって起こりうる変化」を意識する
4.3 密接なコミュニケーション
1. アジャイル開発とは
アジャイル開発とは、「アジャイル(Agile) = すばやい」の言葉の意味どおり、迅速にソフトウェア開発を行いシステムを作り上げることです。
また、システム全体の計画を立てるよりも少しずつ作っていきながら目標を設定していくことに重点が置かれ、「作りながら考える」やり方とも言えます。
アジャイル開発が生まれた背景には、競争が激しく技術の進歩が著しいIT業界において、システムもその都度変化に柔軟に対応していく必要がありました。
そのため、顧客の要望に沿ったシステムをなるべく短い期間で完成させ、要求の変化にも柔軟に対応していくアジャイル開発が主流になってきています。
1.1 アジャイル開発の概要
アジャイル開発では、システムを機能ごとに分割し、ビジネス上で優先度の高い機能から順に開発していきます。
小さな機能を1~2週間(最大4週間)の短期間で「設計・開発・テスト」の順に行う「イテレーション(反復)」を繰り返します。
イテレーションの終わりにリリース可能と判断されたプロトタイプはリリースします。次のイテレーションにはプロトタイプの検証および顧客の要求変更なども取り入れながらシステムの完成度を高めていきます。
1.2 アジャイル開発の原則
2001年、アジャイル開発の公式文書としてまとめられた「アジャイルソフトウェア開発宣言」では、アジャイル開発の定義とそれに基づく 12の原則が定義されています。
(引用元:アジャイルソフトウェア開発宣言より)「プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。」
「アジャイル宣言の背後にある原則」より、アジャイル開発の定義に基づく12の原則を下記にまとめました。
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する
2. 要求の変更には対応し、顧客の競争力を引き上げる
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く
5. 意欲に満ちた人々を集めてプロジェクトを構成し、環境と支援を与え信頼関係を築く
6. 効率的・効果的に情報を伝えるためフェイス・トゥ・フェイスで話をする
7. 動くソフトウェアこそが進捗の最も重要な尺度である
8. アジャイル・プロセスは持続可能な開発を促進し、一定のペースを継続的に維持できるようにする
9. 技術的卓越性と優れた設計を怠らず機敏さを高める
10. シンプルさ(ムダなく作れる量を最大限にすること)が本質である
11. 自己組織的なチームから最良のアーキテクチャ・要求・設計をうみ出す
12. チームの効率性を高めることができるかを定期的に振り返り、それに基づいてやり方を最適に調整する
上記の原則から、アジャイル開発には概念的なものがしっかりとしていることが読み取れます。
「Don’t just Do Agile, Be Agile」(アジャイルを行うのではなく、アジャイルになれ)、このような言葉があるように、アジャイル開発とはただの開発手法ではなく、上記の原則のような状態になることを目指すべきだと考えられています。
1.3 アジャイル開発はどんなシステムに向いているか
アジャイル開発の特徴として「少しずつ開発を進められる」「変更に柔軟に対応できる」「短期間で開発する」などが挙げられます。
この特徴を活かせるシステムとしては、仕様変更が発生しやすく、ユーザーの意見を多く取り入れる必要のあるWebサービスや、Webアプリ、スマートフォンアプリの開発には特に適していると言えるでしょう。
2. アジャイル開発の手法
アジャイル開発の手法にはいくつかありますが、使用される手法の90%以上は下記のふたつに絞られます。
2.1 スクラム
アジャイル開発における代表的なフレームワークであり、段階的にプロセスを進めながら反復する手法です。
スクラムというチームを組み、その中での動きをどう進めるかが定められています。
プロダクトオーナーがプロダクトに責任を持ち、スクラムマスターがチーム全体を支援し、開発チーム(3~9人程度)が実際に開発を行います。
そして、スクラムチーム以外のプロダクトに対する利害関係を持つステークホルダーが、プロダクトに対するフィードバックを行います。
チームメンバーで計画を立て、スプリントごとに開発の進捗度やプロダクトの機能の動きなどを精査します。
メンバー間でのコミュニケーションを十分とりながら、全員が協力して開発を進めていきます。
2.2 エクストリームプログラミング(XP)
エクストリームプログラミング(Extreme Programming)は、事前に仕様や設計を詰めてその通りにプログラミングを行う手法とは異なり、プログラミング開始後も変更・修正などが行われることを前提としています。
小単位の機能の設計・開発・テストを繰り返して、完成度を高めていく「反復型開発」であり、アジャイル開発においてはスクラムと合わせて用いられます。
2.2.1 エクストリームプログラミングのプラクティス
問題発生のリスクを回避するための具体的な「プラクティス」と呼ばれる様々な実践内容が定められています。
代表的なプラクティスを下記に挙げます。
◆ ストーリーの作成
開発する機能が顧客側から見てどう動くのか、そのコンセプトを短い文章にしたストーリーカードを作成します。
ストーリーカードをもとに顧客と話し合い、機能の詳細を決め、優先度の高い機能から開発していくことで無駄な機能の開発防止にもつながります。
◆ ペアプログラミング
2人ペアでプログラミングを行います。
設計・開発・テストなどをペアで行い、1人が開発、1人がチェックすることで問題の発生リスクを下げ、開発時間の短縮と品質の向上につながります。
◆ソースコードの共同所有
ソースコードをオープンにし、チーム内の誰もが参照し修正することができます。ソースコードの責任はチーム内全員で共有します。開発遅延の防止や個々の知識範囲の拡大が期待できます。
3. アジャイル開発以外の主な開発手法
ソフトウェア開発において、アジャイル開発とよく比較される他の開発手法について解説します。
3.1 ウォーターフォール開発
「分析 → 設計 → 開発 → テスト → 保守」と一通りの工程を上から順番どおりに実行していく手法です。
アジャイル開発が台頭してくる前は、ほとんどこのウォーターフォール開発が用いられていました。
【メリット】
◆ 最初にしっかりとシステム設計を行い仕様を固めるため、システムの全体像をつかみやすい
◆ 計画的に開発を進めるため進捗管理をしやすい
【デメリット】
◆ 順番どおりに各作業を進めるため途中での変更がしづらく柔軟性に欠ける
◆ リリース後に顧客の要求変更が重なると数年がかりで開発したシステムもニーズが合わなくなっていることがある
3.2 スパイラル開発
システムを機能ごとに分割し「設計・開発・テスト」を行います。
品質保障のない段階で顧客に確認・評価をもらい、分析を行ったうえで、次の機能の「設計・開発・テスト」を行い、また顧客に確認・評価をもらいます。
これを繰り返して機能単位で作り上げ、システムの質を高めながら全体を作り上げます。
システム全体が完成するまでこれを繰り返し、完成後にリリースします。
【メリット】
◆ 顧客の要望や意見の取りこぼしが少なく、システムにもすぐに反映させやすい
◆ 開発スケジュールや仕様変更に対応しやすい
【デメリット】
◆ 予算を超えコストがかかりがち
プロジェクトの早い段階から顧客とシステムイメージを共有するため、顧客からの要望が増えがちになり、想定外の仕様となりコストがかかってしまうことがある
◆ 期間内に機能が完成しない
顧客からの評価に問題が生じるとその度に修正が入り、対応のための開発作業も膨らみ時間がかかることが少なくない。
3.2.1 同様の「反復型」であるアジャイル開発との相違点
◆ スパイラル開発
品質保障のない段階で顧客に確認・評価をもらいシステムの質を高めながら全体を作り上げ最後にリリースを行う
◆ アジャイル開発
品質保証された機能のリリースを繰り返し、システム機能を高めながら全体の開発を行う
アジャイル開発ではシステムを機能ごとに分割しスパイラル開発よりも短い期間で「設計・開発・テスト」を繰り返します。
この機能の繰り返し中にリリース可能と判断されると都度ソフトウェアをリリースするため、顧客が確認する際には機能単位レベルでの品質は保証されています。
短い期間でリリースを繰り返し、システムの機能を高めながらシステム全体の開発を行います。
3.3 プロトタイプ開発
開発の早い段階でプロトタイプ(試作品)を作り、顧客に確認・評価をしてもらいます。
その後、細かな仕様を詰めてから本格的な開発を行い、顧客の要望を反映したプロトタイプを再度評価してもらいます。
これを繰り返すことでシステムの完成度を高めます。
【メリット】
◆ システムの完成後をイメージしてもらいやすい
プロトタイプを作り、実際に動かしてみることでシステムの具体的なイメージがつかめる
◆ 質の高いシステムができる
プロトタイプの評価後に、要望を取り入れたり修正しながら開発を進めるため、顧客と開発側の認識のずれを防げる
【デメリット】
◆ 大きなシステムには向かない
開発中に何度もプロトタイプの検証が入るため、大規模システムでは開発チームのスケジュールの管理がしづらい
◆ いつまでも完成しないリスクがある
顧客の要望が細かすぎたり多すぎたりすると、開発側が対応しきれずプロジェクトの終わりが見えないことが起こりうる
4. アジャイル開発を成功に導くためのポイント
「アジャイル」の「顧客の要求に柔軟に対応しながら短期間で開発する」というメリットは聞こえもよく、現代の変化の激しいソフトウェア業界において他社との競争に勝ち抜くためには適した開発と言えます。
しかしながら、多くの企業が「アジャイルっぽい開発」を導入するものの、思うような結果が出ていないという事実もあります。
アジャイル開発でしっかりと価値あるものを生み出すためにはどのようなことに気をつければよいのでしょうか。
4.1 目的の明確化
プロジェクトの最初に、システム設計をしっかりと行い、プロジェクトの目的やどんな課題を解決したいのか明確に把握しておきましょう。
アジャイルは短いスパンでリリースを繰り返すため、プロジェクトの全体像を見失いがちになります。
4.2 組織全体で「アジャイルによって起こりうる変化」を意識する
アジャイル開発を行うと、開発現場だけのことのように捉えがちですが、実際には経営陣や組織全体にも関わってきます。
特に、アジャイルでは常に成果物やタスクの量や質が変化するため、
開発チームとプロジェクトの決済関係者が常にプロジェクト中に起こりうる様々な変化に対応する意識を持っておくことが大切です。
4.3 密接なコミュニケーション
アジャイル開発の原則に「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く」とあるようにプロジェクトを円滑に進めるためにも双方が信頼関係を保ち、密接なコミュニケーションをとることが必要です。
また、開発チーム内でも日々のミーティング、レビュー、プロトタイプの検証、仕様変更への対応などが行われるため、チーム全員で意見を交わしコミュニケーションをしっかり取り、システムを成功につなげていく意識が重要です。
5. まとめ
アジャイル開発はスクラムやエクストリームプログラミングなどの手法を活かすことで短期間での開発を実現し、顧客の要望を取り入れやすく柔軟性が高いという特徴があります。
近年広く知られるようになり、成功事例を出す企業も増えており、今後さらにアジャイル開発が普及していくであろうと言われています。
アジャイル開発によってプロジェクトを成功させるためには、アジャイル開発の手法をただ取り入れるだけではなく、原則にあるような本質をプロジェクトに携わる全員が把握し、手法を活かすためのチーム作りやフレームワークを作ることが重要だと言えるでしょう。