#はじめに
近年、注目を集めているアジャイル。
海外のほとんどの企業がこのアジャイルが導入されています。
日本でもアジャイルを導入している企業が年々増えていますが、海外の企業に比べるとまだまだ導入率が低く、ウォーターフォールでの開発が一般的と言えます。

そこで、現場でスクラムによるアジャイルを経験させて頂いているので、所感を交えてアジャイルについて説明していこうと思います。(スクラムの詳細はまた別で記事にしたいと思います。)
「アジャイルって何？」「聞いたことあるけどよく分からない。」「興味はある。」という方は是非一読を。
#ウォーターフォールについて
アジャイルを説明する前に日本の開発で一般的であるウォーターフォールについて簡単に説明したいと思います。

「ウォーターフォール(waterfall)」という言葉はその名の通り「滝」という意味があり、上流工程から下流工程に順次移行していく開発手法です。
その工程が水が流れ落ちる様子に見えることからウォーターフォールという名前がついています。
(「V字モデル」というのが存在するが、ウォーターフォールを変形したもので実態は同じです。)

ウォーターフォールでは『要件定義⇒設計⇒実装⇒テスト』と開発のフェーズを順に行う為、プロジェクトの進捗管理が行いやすいというメリットがあります。
その一方で要件定義や設計、ドキュメントの作成に時間が掛かることや、プロジェクトの途中での仕様変更に対応しづらいというデメリットがあります。

IT業界についてよく知らない人も、「開発者の人って残業が多くて忙しいイメージ」というのをよく聞きます。
上記のウォーターフォールのデメリットが開発者の残業を多くしている要因だと思います。(開発のフェーズまでに時間が掛かったり、仕様変更が行われても納期は変わらないなどで開発者の方々にしわ寄せが来るわけですねぇ...)
#アジャイルとは
それではアジャイルの説明をしていきたいと思います。

「アジャイル(agile)」という言葉には「機敏な」や「素早い」という意味があり、要求仕様の変更などに対して素早く柔軟に対応するというソフトウェア開発方法の一つです。
仕様や設計の変更があることが当然であるという前提の基、初めから厳密な仕様などは決めずに開発を行いながら仕様や設計の変更に対応していきます。

ウォーターフォールで開発を行っている開発者の方々は『仕様変更』という言葉が嫌いな人が多いのではないでしょうか？
筆者もウォーターフォールで開発を行っていた時は大っ嫌いでした(笑)。
しかし、アジャイルでの開発を行っている時は「仕様変更ですか？良いですよー。修正しておきまーす。」の様に直ぐに機能の修正を加えられるのでストレスフリーで仕様変更を行っています。

また、アジャイルでは**『ドキュメントは必要なものだけを作ればよい』**という考え方があります。
これは、不必要なドキュメントの作成や既存のドキュメント修正といった時間の無駄を排除し、効率的に開発を行うということです。

筆者もアジャイルで開発を行うようになってから設計書や仕様書などは一度も作ったことはありません。
そもそもドキュメントを作成することがほとんどないから、現場のPCにExcelやPowerPointが入ってないというね(笑)。
ただ、「アジャイルってドキュメントはいらないのかぁ...」と勘違いはしないで下さい。
あくまで、**『不必要なドキュメントは作成しない』**ということであって、開発するうえで必須であるドキュメントや顧客にとって価値のあるドキュメントであれば、その都度作成します。

#アジャイルの進め方
アジャイル開発では、プロジェクトの全体を管理するリリース計画と短期間(数週間)で開発を繰り返すイテレーションに基づいて進めていきます。

・リリース計画
　『アジャイルとは』でも記載しましたが、アジャイルには「開発途中で仕様や設計の変更は当たり前である。」という概念がある為、ソフトウェアの計画段階では厳密な仕様は決めずに大まかな仕様と要求を決めていきます。
リリース計画はユーザーストーリーを使用して立案します。
ユーザーストーリーとは、ユーザーの意図や要求を時系列に並べて短い物語にしたものです。
ユーザーストーリーで機能が出揃ったら、その中で**MVP(Minimum Viable Product)**を決めます。
MVPとは顧客に価値を提供できる最小限の製品や、それを使ったアプローチのことを言います。

・イテレーション
　リリース計画にてユーザーストーリーが完成したら、イテレーション(iteration)と呼ばれる開発サイクルに入ります。
「イテレーション(iteration)」という言葉には「反復」という意味があり、一連の工程（計画⇒設計⇒実装⇒テスト）を短い期間にまとめ、何度も繰り返し行います。
イテレーション毎に実際に開発したソフトウェアに対してのフィードバックをもらい改善を行っていきます。
イテレーションは1週間~2週間ごとが一般的と言われています。
ちなみに筆者はこのイテレーションを1週間ごとで行っていました。
イテレーションはユーザーストーリーで決めたMVPの機能から実装していきます。

このように開発を進めているため、アジャイルが仕様変更に素早く対応できると言われているのです。

#アジャイルの手法
アジャイルにも様々な手法があります。その中でも代表的な手法と言われているのは下記の3つがあります。

・スクラム
　スクラムとはラグビーの肩を組んでチーム一丸となってぶつかり合うフォーメーションを指しており、その名の通りチーム間のコミュニケーションを重要視し、開発を効率的に進める手法です。

・XP（エクストリームプログラミング）
　「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値をチームで共有し、コーディングとテストの両方を開発初期段階から重要視する手法です。

・ユーザー機能駆動開発（FDD）
　顧客にとって価値のある機能という観点を重要視し、実際に動作するソフトウェアを適切な間隔で繰り返す手法です。

筆者はスクラムという手法でアジャイル開発を行っています。
それぞれの手法はアジャイルの中にある様々な価値の中で、どこを重要視するかが違うだけであり、スクラムでもユーザー機能駆動開発(FDD)で重要視している「顧客にとって価値のある機能」を軽視しているという訳ではありません。

#アジャイルのメリット
・顧客のニーズを最大限に反映できる
　イテレーションを重ねて開発を行っていくため、イテレーション毎に顧客からフィードバックをもらい改善していくことが出来ます。
顧客の要望がすぐに反映することが可能な為、要求通りのソフトウェアを提供することが可能になります。
また、実際に動くソフトウェアを見てもらいながらフィードバックをもらうので、開発者も顧客が思い描いている要求が伝わりやすいです。

・工数の出戻りが少ない
　小単位で開発を行っている為、何か不具合やテストで問題が起こった場合にひとつイテレーションを戻れば良いので、出戻りの工数がかなり少なくすることが出来ます。

・開発途中でも仕様変更や要件変更がしやすい
　仕様や設計の変更があることが当然であるという前提の基、厳密な仕様は決めずに大まかな仕様と要求を決めています。
その為、開発の途中で仕様や要件の変更が起きても柔軟に対応が出来るので大きな問題にはなりません。

その他にもメリットはいくつかありますが、大きなメリットは上記の3つでしょうかね。

アジャイルのデメリット

メリットばかりに思われるアジャイルですが、デメリットも当然あります。

・開発の方向性がブレやすい
　仕様の変更や修正が簡単に行えてしまう為、開発を行っている中で方向性がブレてしまうことがあります。
プロジェクトの根幹となる部分をはっきりさせて、柔軟に対応すべき部分との切り分けが大事になります。

・スケジュールや進捗具合の把握がしづらい
　アジャイルではウォーターフォールの様に最初に詳細な計画を立案しない為、スケジュールや進捗具合の把握がとても難しいです。
その為、全体の把握が出来ずにコントロールが困難になり納期に間に合わないなんてことがあります。
イテレーションで行う計画をしっかり行うことと、全体のバランスを考えることは常に意識しましょう。

このデメリットをどのように潰していくかが、アジャイルを成功させる鍵となります。

#最後に
最近は市場の変化が早く、要求がどんどん変わっていくような時代です。
そういった理由で日本の企業がアジャイルを注目し始めているのだと感じます。
日本でもアジャイルが一般的になるのもそう遠くはないと思います。

いかがでしたでしょうか？
少しでもアジャイルについて理解が深まったり、興味が湧いたりしていたら嬉しいです。