アジャイル開発とは

先月アジャイル検定レベル1を受けてきましたので、
アジャイル開発とはなにか備忘録としてまとめていきたいと思います。
## アジャイル開発とは
「アジャイル開発」とはソフトウェア開発における手法の一つです。
従来のウォーターフォール型の開発の課題であった
開発途中の要件変更ができないことを解決するために生み出されました。
以下にアジャイル開発についてまとめていきたいと思います。
### アジャイルソフトウェア開発宣言
アジャイルソフトウェア開発の手法の共通事項を明記したものが
「アジャイルソフトウェア開発宣言(アジャイルマニフェスト)」となります。
<details><summary>アジャイルソフトウェア開発宣言</summary>


```rb
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。



Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas



© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい
```
</details>

**プロセスやツールよりも個人との対話を**
「プロセスやツールよりも個人との対話を」では、開発プロセスを厳格に守ることより、
対話によってコミュニケーションを重視し、効率よく仕事を遂行することを述べている。
対話によるコミュニケーションを重視しますが、必要であればツールも使います。

**包括的なドキュメントよりも動くソフトウェアを**
「包括なドキュメントよりも動くソフトウェアを」は、「ドキュメントで判断するより、
動くプログラムで動作を判断しましょう」という意味です。
「ドキュメントは全く書かない」という事はありません。
**契約交渉よりも顧客との協調を**
アジャイル開発は要件が変更されるのを前提としているため、
「契約交渉よりも顧客との協調を」は顧客とともにその都度合意して
開発を進めていこうという意味になります。
**計画に従うよりも変化への対応を**
「計画に従うよりも変化への対応を」は、初めから細かい計画を立ててプロセスを
進めていくよりも、その都度計画を修正しながら開発を進めていくことを意味します。
※全く計画を立てないという事ではありません
### アジャイル開発の特徴
#### 繰り返し型の開発
アジャイル開発は、短期間の開発を繰り返し行う反復型開発です。
**開発期間の変化**
〇従来の開発
ウォーターフォール型開発は、開発予定のすべての機能を
「分析」→「設計」→「実装」→「テスト」
と、各工程を順番に実装します。
そのため、開発途中の要件変更ができませんでした。
〇アジャイル型開発
アジャイル開発は開発期間を一週間から一か月程度にし、
短期間で開発を繰り返し行っていきます。
そのため、開発途中の要件変更を積極的に行うことができます。
**開発工程を平行させる**
アジャイル開発は短期間で開発を行うため、
要件単位で「テスト」「設計」「コーディング」を並行して行います。
また、アジャイル開発では要件を「ストーリー」と呼びます。
#### スコープの調整
**従来のプロジェクトの変動要因**
従来型の開発では、プロジェクトにおける変動要因として
「品質」「コスト」「期間」
の３つがありました。
アジャイル開発ではもう一つの要素として
「スコープ(開発範囲)」というものを追加します。
従来の開発では問題が発生した際は「品質」「コスト」「期間」の
いずれかを犠牲にしてきましたが、アジャイル開発では解決策として、
スコープを調整を行います。
結果として、柔軟に変化に対応し、常に稼働するシステムのリリースが可能となります。
#### 常時リリース
アジャイル開発は反復型開発であり、
一回の繰り返しごとにリリース可能なシステムを作り上げます。
**自動化**
アジャイル開発では短期間でシステムをリリースするため、
テストと本番環境への配置の作業を自動化して作業を行います。
#### 人的活用
**多能工**
アジャイル開発は従来のやり方と異なり「設計工程」「実装工程」「テスト工程」
を分けていないため、すべての工程を一人の開発者で行う多能工が必要となります。
また、多能工な開発者をそろえるためにも教育プログラムなど、
メンバーがスキルを習得するための環境を整備しておく必要があります。
**ペアで作業する**
一人の開発者ですべての工程を行うための多能工は必要ですが、
一人で開発を進めるわけではなく、常にペアで作業を行います。
結果、作業の正確さと高い品質を得ることができます。
**個人との対話**
メンバー間での連携を適切に行うために、
メンバーは10人以下の人数で構成する必要があります。
また、情報共有は開発者同士のコミュニケーションによって知識を共有し、
作業を進めます。
#### 適応型プロセス
従来の開発プロセスでは、予めすべてを想定して、計画的に開発を進めていく
「予測型開発プロセス」を行っていました。
一方、アジャイル開発では開発を行っているときに問題が発生したら、
開発プロセスを変更させて対応する「適応型開発プロセス」を行います。
### アジャイル開発のメリットデメリット
#### メリット
**開発期間を短くする効果**
動作するソフトウェアをすぐ作り、顧客に確認してもらう事で、
素早いフィードバックをもらう事が可能となります。
結果、顧客の意図にあったシステムを構築しやすく、
終盤の大掛かりな修正も発生しなくなる。
**スコープの変動**
従来の開発では、問題発生時は「品質」「コスト」「期間」の
いずれかを犠牲にしなければならないと考えられていましたが、
アジャイル開発ではスコープの変動によって、
以上の三つの要素をどれも犠牲にせずともプロジェクトの進行が可能となりました。
**常時リリース**
従来型の開発ではすべての機能がそろわないとサービスが開始できないため、
コストの回収は遅くなっていた。
アジャイル開発は常時リリースで行うため、短期間でシステムが稼働でき、
サービスを早く始めることでコストを早く回収できるようになりました。
#### デメリット
**プロジェクト全体のスケジュール管理**
アジャイル開発は仕様・要件ごとにスケジュールを設定して開発するため、
全体スケジュールのコントロールが難しい傾向にある。
**開発の方向性**
仕様の変更を加えやすいメリットの反面、プロジェクト開始当初の目標、
方向性を見失ってしまうことがある。
#### まとめ
以上がアジャイル開発についての大まかな内容となります。
アジャイル開発は従来のウォーターフォール型の開発の欠点であった柔軟性の無さを
克服するために編み出された開発技法であり、アジャイル開発の特徴や
メリット、デメリットについてまとめていく中でアジャイル開発について
今一度確認することができました。
アジャイル開発についてデメリットはありましたが、その分メリットも多くあったので、
実際の業務の中で取り入れてみたいなと思いました。
## 参考
http://agilemanifesto.org/iso/ja/manifesto.html

https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E6%A4%9C%E5%AE%9A%E5%85%AC%E5%BC%8F%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A8%E3%82%A2%E9%96%8B%E7%99%BA%E6%8A%80%E8%A1%93%E8%80%85%E6%A4%9C%E5%AE%9A%E8%A9%A6%E9%A8%93-%E3%83%AC%E3%83%99%E3%83%AB1%E5%AF%BE%E5%BF%9C-%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A8%E3%82%A2%E9%96%8B%E7%99%BA%E6%8A%80%E8%A1%93%E8%80%85%E6%A4%9C%E5%AE%9A%E8%A9%A6%E9%A8%93%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B7%E3%82%A2%E3%83%A0/dp/4865940871

https://monstar-lab.com/dx/solution/about-agile_methods/#section-25