目次

1. 01アジャイルとは？
2. 02ウォータフォールとアジャイル
3. 03アジャイル開発の背景
4. 04アジャイル開発の基本
5. 05アジャイル開発の関連用語
6. 06アジャイル開発のフレームワーク
   • スクラム
   • XP
7. 07アジャイル開発の普及率
8. 08アジャイル開発のメリット・デメリット
9. 09まとめ

01アジャイル開発とは？

アジャイル開発は、システムやソフトウェアを開発する手法の一つです。
アジャイルとは直訳すると「素早い」「機敏な」「頭の回転が早い」という意味で文字通り「計画→設計→実装→テスト」といった開発工程を機能単位の小さいサイクルで繰り返すので従来よりもスピード感が出る点が最大の特徴です。
機能を優先度の高い要件から順に開発を進めていき、開発した各機能の集合体として1つの大きなシステムを形成します。
現在はソフトウェア開発だけではなくビジネスのスタートアップなどにもこの手法を取り入れている企業もあります。

02ウォータフォールとアジャイル

従来のウォーターフォール型

従来の開発手法はウォーターフォールと言われ、要件定義から設計、開発、実装、テスト、運用までの各工程を段階的に完了させていく手法になります。
図のように上から下に順番ずつ工程を終えていくところが滝が上から下に落ちていく様子になぞらえてウォーターフォールと呼ばれています。
要件定義や全体の機能設計を固めてから開発に着手するため、実際に開発が始まるまでに時間がかかる傾向があります。
しっかり固めてから始めるため、進捗管理がしやすく人員配置を含め計画を立てやすいなどのメリットを持つウォーターフォール開発ですが、 前工程に誤りがあった場合の手戻り工数が大きく、ユーザーなどの意見を反映できないというデメリットがあります。
最初からきっちり決めるような大規模開発だとウォーターフォールの方が良いですが、スタートアップの開発に関してはアジャイルの方がスピードを持ってリリースまでいけるのでどちらがいいというよりは向き不向きで判断するのが良いでしょう。

03アジャイル開発の背景

アジャイル開発が生まれる背景に「アジャイルソフトウェア開発宣言」というものがあります。
2001年に当時アメリカのユタ州に従来型のソフトウェア開発とは異なる手法でのソフトウェア開発を当時実践していた17人のソフトウェア技術者が集まり、ユーザーのニーズ・プログラミングの手法や言語・ソフトウェアの設計などについて議論し生み出された公式にアジャイル開発を定義した文書。リンクの一つ目を開いていただきたい。太字の4つがアジャイル開発における価値観を定義したものです。
アジャイル開発はこういった価値観のもとに生み出されました。

参考：アジャイルソフトウェア開発宣言

04アジャイル開発の基本

アジャイル開発の基本工程は一般的に1週間から4週間の反復期間を設定し、「計画」→「開発」→「実装」→「テスト」→「リリース」という開発工程を小さな機能開発毎に行っていきます。

1. 「リリース計画」 →仕様や要求を取りまとめる過程のことをアジャイル開発ではリリース計画と呼びます。
2. 「開発」 →機能ごとに設計・実装・テストを行います。
   開発者はテスト専任、実装専任などの役割分担はなく全ての役割を担当します。
3. 「実装」
4. 「テスト」
5. 「リリース」 →受入テストをパスした機能をリリースします。
6. 「計画」 →リリースできた機能や残っている業務プロセスの範囲を検討し、次に着手する優先すべき区分を決めます。

05アジャイル開発の関連用語

関連用語

• ユーザーストーリー アジャイル開発において「要件」の代わりに用いられる概念。
  「ユーザーが実現したいこと」「ユーザーにとって価値があること」（意図・要求）を簡潔にまとめた文章です。
• 受入テスト/ユニットテスト 当初想定した要件や目的に沿ったソフトウェアになっているか、プログラム実装後に検証するプロセスです。
• イテレーション（スプリント） イテレーション（iteration）とは「反復・繰り返し」という意味。
  短期間で反復しながら効率的に開発を進めるアジャイル開発の1サイクルを単位にしたものです。
• ステークホルダー 主にスクラム開発で用いられる単語でスクラムチーム以外のプロダクト関係者の総称。
  プロダクトの利用者やスポンサー、社内の上司や他部門などが該当します。

06アジャイル開発のフレームワーク

アジャイル開発にはさまざまなフレームワークと呼ばれる型がありますが、今回はその中でも有名な2つのフレームワークを紹介します。

スクラム

1つ目は最も有名なフレームワークである「スクラム」です。
スクラムの由来はラグビーのスクラムを組む様子からで関わっている人が一体となって作業するコミュニケーションを重視している点が特徴。

スクラムチームを構成

スクラムチームはスクラムマスター1⼈、プロダクトオーナー1⼈、複数⼈の開発者で構成されます。
コミュニケーションを円滑にするためにもチームの人数は10人以下が推奨されています。

• プロダクトオーナー →プロダクトの価値を最大にすることに責任を持ちます。 ・プロダクトバックログを優先順位順に並べる（並び替える） ・開発チームに対して次に開発する機能を示し、開発の動機づけを行う 折衝力や交渉力も求められる職務といえるでしょう。
• スクラムマスター →スクラムチーム全体の責任者のことです。 プロジェクト全体が円滑に進むように取り計らい、 チームのメンバーが能力を十分に発揮できるようにサポートします。 また、現場とプロダクトオーナーとのパイプ役としての役割も果たします。 スクラムマスターとして重要なのはチームのメンバーに対し献身的に働きかけ啓発をおこなっていくことが求められます。
• 開発チーム →スプリントごとにソフトウェアを提供することに責任を持ちます。 開発チームは実際に動作するソフトウェアを開発します。 開発プロセスや開発手法の新たな採用や、改善の方法を決定します。 開発チームの人数は7±2人が望ましいとされています。

スクラム開発の流れ

1. プロダクトバックログの作成 プロダクトバックログとは、プロダクトを作成するにあたっての要求事項を作る順番に並べたリストです。
   直近のスプリントで手を付けるプロダクトバックログアイテムが詳細に記述されており、定期的に見直す必要があります。
   順位の並べ替えについてはプロダクトオーナーが責任を持ち、他のロールによって順番が変えられることはありません。
2. スプリントプランニング(スプリント計画) 作成したプロダクトバックログをもとにスプリントで実装する機能を選びます。
   スクラム開発の場合は優先順位の高い機能から実装していくという特徴があります。
   このスプリントで実装する機能一覧のことを「スプリント・バックログ」と呼び、スプリントプランニングで決定していきます。
3. デイリースクラム 毎朝チームメンバーで集まり、15分など短い時間を区切り、昨日やったこと、今日やること、障害となっていることを一人一人報告・共有します。
   このミーティングにより、チーム全員の状況、障害や問題の共有、今日どこまで完了するかの宣言を行い、プロジェクト全体の見える化を行います。
4. スプリントレビュー スプリントの最終日に、プロダクトオーナーや主要ステークホルダーがスプリントでの成果物を確認するためのレビュー会のことを言います。
   基本的には動くアプリケーションによってレビューを実施し、バックログで定義された基準を満たしているかどうかを評価することになります。
5. スプリントレトロプロスペクティブ(振り返り) スプリントの振り返りミーティングのことです。 スプリントレビューと同様にスプリント最終日に開催されることが多く、スプリント内でのよかった点や課題点、要因を分析し、改善策などをメンバーで議論し、次のスプリントですぐに生かせるようにします。
   振り返りにはKPT法がよく用いられます。

   KPT法：キープ、プロブレム、トライの略でホワイトボードに図のような枠を書いて全員が「Keep（成果が出ていて継続すること）」「Problem（解決すべき課題）」を書き出しその点について深掘りしてTRYにそこから次回挑戦することをかく方式

   

エクストリーム・プログラミング（XP）

アジャイル開発手法の1つで、「変化」が起こることを前提とし柔軟に対応することができる開発手法です。
XPでは、「5つの価値基準」と「プラクティス」と呼ばれるものを重視します。

5つの価値基準

• 1.コミュニケーション（Communication） システム開発者と顧客の間でシステムに対する認識が間違っていれば作り直しが発生したり、完成したものが満足度の低いものになることもあります。
  開発者同士でのコミュニケーションが不足すると、必要な情報が連携されず、重大な問題になってしまうこともあります。
  このことからXPはコミュニケーションに重きを置いています。
• 2.シンプル（Simplicity） 仕様変更が発生しがちなシステム開発において、シンプルな仕組みでシステムを開発することに重きを置きます。
• 3.フィードバック（Feedback） 開発したシステムのフィードバックをもらうことで、必要な機能を明確にすることができ、無駄な機能開発が少なく済みます。
• 4.勇気（Courage） XPでは、綿密な計画を立てません。
  そのため、開発中に大きな仕様変更が起こることもあり、既に作成した機能を大幅に変えなければいけない時がくるかもしれません。
  そういった場合、既に作ったものを作り直すために勇気が必要になります。
• 5.尊重（Respect） コミュニケーションを積極的に行う上で、開発者同士や顧客でお互いの意見や姿勢を尊重する必要があります。
  異なる意見を交える時、相手を尊重する気持ちがないと自分の意見のみを押し通そうとしてしまい、関係が不和になってしまったりすると、コミュニケーションも発生しづらくなってしまいます。

XPのプラクティス

XPでは、ソフトウェア開発における問題発生のリスクを低減する具体的かつ経験則的な活動を「プラクティス」と呼んでいます。
プラクティスは大きく4つに分けられます。

• 開発プラクティス
• 管理者プラクティス
• 顧客プラクティス
• 共同プラクティス

開発プラクティス

開発に関する実践内容で、プログラマなどの開発チームを対象とします。

• テスト駆動開発 テスト駆動開発とは、実装の前にテストを作成し、実装はテストをパスすることを目標として行います。先にテストを作成することで、必要とされる機能が明確化され、シンプルな設計に繋がります。 なお、テストはユニットテストと受け入れテストからなり、どちらのテストも自動化が望ましいです。
• ペアプログラミング ペアプログラミングとは2人1組でプログラミングを行うことです。1人がコードを書き、もう1人がコードのレビューを行なったり、仕様書を基にどういった開発を行うかといったナビゲーターの役割を担います。 記述しながら確認を行うと、細々とした問題をその場で解決できるメリットがあります。また、記述されたコードを把握している人物が２人いるので、その後の問題発生時にも迅速な対応が可能になるでしょう。
• YAGNI You Aren’t Going to Need It.（必要なことだけ行う）の頭文字。先取りして実装を複雑化させることを回避し、無駄な機能は削除して今必要とされている機能だけのシンプルな実装を心がけます。
• リファクタリング リファクタリングとは、完成したコードをわかりやすく書き換え内部構造を整える取り組みです。同じ動作をするコードでも、わかりやすいものに変換されるので、メンテナンス性の向上や不具合の発生頻度の低下させることができます。
• 継続的インテグレーション
• ソースコードの共同所有

管理者プラクティス

短期間で開発を行うため、チームの負荷が適切か、また開発そのものを適切に管理するための実践内容で、プロジェクトの管理者を対象とします。

• 最適なペースの仕事 チーム関係者への負荷が適切か、詰め込みすぎた開発となっていないかを判断します。短期開発を行う際、開発の期間が短いため負荷がかかりがちになってしまい、関係者のパフォーマンスが十二分に発揮できない可能性があります。
• 責任の受け入れ
• 援護
• 四半期ごとの見直し
• ミラー

顧客プラクティス

ビジネス的視点から必要な機能を考え、開発の優先順位をつけるための実践内容で、顧客を対象とします。

• ストーリーの作成 ストーリーカードと呼ばれる実装する予定の機能を記したカードを機能ごとに作成します。そのカードを元に、開発者・責任者・顧客の全員を含むチームでミーティングを行い、実装の詳細を決定します
• リリース計画
• 受け入れテスト
• 短期リリース

共同プラクティス

関係者全員に関わる実践内容で、開発チームだけでなく顧客まで含めて、エクストリームプログラミングに関わるすべての人を対象とします。

• 反復 要件定義からテストまでの1つのイテレーションが約1〜2週間で終わるような開発とし、これを何度も繰り返しながら開発を進めます。
• 共通の用語 コミュニケーションの齟齬を防止するために用語集を作成します。
• 開けた作業空間 開発チームと顧客で密なコミュニケーションをとりやすく、作業に集中できる環境を構築します。
• 回顧 過去のフィードバックを活かしてミスを再発しないように作業状況を明確化します。

XPの流れ

XPのプロセスは、イテレーションと呼ばれる反復期間を繰り返すことで増加的に機能を開発します。
イテレーションおよびその前後に、以下に挙げる活動が実施されます。

1. 計画ゲーム イテレーションの期間内に実装する機能を決定します。
   開発技術者は機能の規模を見積り、オンサイト顧客は機能の優先順位を提示します。
   両者のやりとりによって開発機能が決定されます。
   オンサイト顧客：顧客はチームメンバーの一員です。オンサイト顧客と呼ばれチームと常に同席し、技術者と協働してソフトウェアを開発します。
2. イテレーション オンサイト顧客と開発技術者が協働して開発を行います。
   オンサイト顧客は機能の受入条件を作成します。
   オンサイト顧客は開発技術者と協働して受入テストを作成、実施します。
   オンサイト顧客と開発技術者は常に同席し緊密なコミュニケーションのもとで、機能の詳細／技術上の制約／ビジネスサイドの目的を明らかにします。
   開発技術者は機能の開発と同時にテストを作成実施し、ソフトウェアが正常に動作する状態を維持します。
   動作するソフトウェアを共にみて触れることで、オンサイト顧客と開発技術者は齟齬のないコミュニケーションを図ります。
3. リリース イテレーションの終了時に、オンサイト顧客の受入テストが完了している機能をリリースします。
   イテレーションの期間は1週間から2週間に設定されることが一般的です。

07アジャイル開発の普及率

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

メリット

• 開発スピードが早くなり納期を短縮できる アジャイル開発は機能単位で設計→開発→実装→テストを繰り返しているのでリリースのタイミングが早くできます。
• 柔軟に対応可能（不具合の際の手戻りが少ない、顧客の要求を反映させやすい） 機能単位で設計→開発→実装→テストを繰り返しているので不具合が発生したとしても修正にかかる工数が少なく、開発途中もコミュニケーションを取りながらフィードバックを行うため顧客のニーズに最大限応えることができます。
• 余分な仕様書などのドキュメントの手間を省く アジャイル開発では対面のコミュニケーションによる意思疎通と実際に動くソフトウェアを進行管理の尺度とすることで、作成される文書の量が減らせます。

デメリット

• 最初に厳密に仕様を決めないため開発の方向性がブレやすい 計画段階で具体的な仕様を決めて取りかからないため、顧客の要求に対応し続けたりすることによって、当初、頭に描いていた方向性からブレやすくなってしまいます。
• スケジュール管理が難しい 仕様変更に対して柔軟な対応が可能ゆえに、テストや改善を繰り返した結果、当初の計画の方向性がブレてしまう可能性があるからです。
  また、多くの仕様変更や要望を受け入れてしまった結果、予定より工期がかかり、コストも高くなってしまうという可能性もあります。

09まとめ

ここまでアジャイル開発について説明しましたが、基本的な部分をおさらいしたいと思います。

アジャイル開発

ソフトウェアやサービスの開発手法の一つ。
従来の要件定義や機能設計をしっかり固めてから開発、実装、テスト、運用までの各工程を段階的に完了させていく手法ではなく、「計画→設計→実装→テスト」といった開発工程を機能単位の小さいサイクルで繰り返す手法で仕様変更に強く、プロダクトの価値を最大化することに重点を置いた開発手法。

基本的な流れ

1. リリース計画：仕様や要求のおおよその方向性を取りまとめる過程
2. イテレーション：機能ごとに「要件定義→設計→実装→テスト」を短期間のサイクルで繰り返す開発段階
3. リリース

メリット

• 機能単位で開発を進めているため仕様変更などの要求に柔軟に対応する事が可能で、戻り工数も最小限で済む
• 厳密な仕様を決めずに実際に動くものを見て進行状況などを確認するため余分なドキュメントを作ることに時間を割く必要がなくなる
• 短期間で機能単位で開発を進めるのでリリース時期を早めることができる

デメリット

• 最初に厳密に仕様を決めないため改善等の要求を反映しているうちに開発の方向性がブレやすくなってしまう
• 最初に仕様を固めないため全体のスケジュール感が把握しづらく、柔軟に対応できる反面要求を反映し続けることでよりスケジュール把握が困難になり最悪の場合は納期に間に合わなくなる恐れがある

終わりに

変化の激しい現代社会においてはよりスピーディーに開発を行えるアジャイル開発というのは時代に適したものであると感じます。
しかしながら従来のウォーターフォール型が悪いというわけでもなく、最初からしっかりと決めて途中の仕様変更がないと決まっているものに関してはむしろウォーターフォール型の方が効率が良い場合があります。
それぞれの特性を理解しながら使い分ける、そういった柔軟さもポイントとなるでしょう。