はじめに
日本ではアジャイル開発の導入が遅れていると言われており、その原因の一つとして、アジャイル開発への間違った理解があるのではないかと思います。
すでに同様の指摘をされているブログ記事などがありますが、改めてまとめておきたいと思います。
アジャイル開発のよくある勘違い
アジャイル開発とはアジャイルソフトウェア開発宣言に準ずる開発手法のことである
アジャイル開発という言葉を知っている方であれば、アジャイルソフトウェア開発宣言もご存知なのではないでしょうか。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
「アジャイル開発とはアジャイルソフトウェア開発宣言に準ずる開発手法のことである」というのは完全に間違いという訳ではありませんが、アジャイル開発の本質を見失ってしまう危険性があります。
書籍「アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣」では、アジャイル開発の本質について、以下のように述べられています。
引用：書籍「アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣」
ソフトウェア開発に対するアジャイルなアプローチとは、適応力と協調を重んじる人々が、一丸となって目に見える具体的な目標（きちんと動作するソフトウェア）に向かっていくことである。
これがアジャイルの本質だ。
アジャイル開発が適さないプロジェクトもあり、場合によってはウォーターフォール開発を選択する必要がある
アジャイル開発は、よくウォーターフォール開発と比較されます。
引用：私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
マイクロソフトのサム・グッケンハイマー氏（「Microsoft Visual Studio」のプロダクトオーナー）は、顧客からの
アジャイルと、ウォータフォールのメリット・デメリットを教えてください
という質問に対して、
ウォータフォールは一切メリットがないので止めておきなさい
と回答しています。
また、米国の国防総省では、ウォーターフォール開発による調達の失敗経験をもとに、2000 年からアジャイル開発の適用を義務化しています。
アジャイル開発は大規模なプロジェクトには適さない
アジャイル開発が登場した当初は、アジャイル開発は大規模なプロジェクトには適さないと考える企業が多かったのですが、最近ではプロジェクトの規模を問わず、アジャイル開発を採用するようになってきました。
ケント・ベック氏（エクストリーム・プログラミングの考案者）は著書「エクストリームプログラミング」の中で、以下のように述べています。
引用：書籍「エクストリームプログラミング」
XP は、あらゆる規模のチームに使える。
5 年前はそのことをあまり主張したくなかった。
だが、それ以降さまざまなプロジェクトに XP が導入され、プロジェクトやチームの規模を問わずに成功することがわかった。
XP の背景にある価値や原則は、あらゆる規模に適用可能である。
ただし、かかわる人数が増えたときには、プラクティスの追加や変更が必要になる。
参考：エクストリーム・プログラミング - Wikipedia
アジャイル開発はミッションクリティカルなプロジェクトには適さない
アジャイル開発は、ミッションクリティカルなプロジェクト（医療、金融、公共インフラなど）には適さないと考えている企業もあります。
ゼネラル・エレクトリック社も過去にそのように考えていた企業の一つでした。
引用：書籍「GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦」
リーンスタートアップでは、顧客を観察することによって得たアイデアを基に素早く「ＭＶＰ（実用上最小限の製品）」を作り、顧客にＭＶＰを試してもらって「学び」を得るというサイクルを何度も繰り返すことで、より良い製品を作り出していく。
「学び」が得られたのであれば失敗も尊重される。
むしろ早く失敗することが大切だとされている。
一方でそれまでのＧＥには「失敗を許さない」文化が行き渡っていた。
ＧＥが製造してきた発電所用のガスタービンやジェットエンジン、医療機器でトラブルが発生したらたいへんな影響が出るからだった。
失敗を尊重するリーンスタートアップは、失敗を許さないＧＥのそれまでの文化とは水と油の関係にあったのだ。
（中略）
なによりもリーンスタートアップを実践するためには、「なるべく早く失敗して経験から学んで、方針を何度もピボット（転換）し、失敗を心地よいもの（コンフォート）だと感じる態度をＧＥの全従業員に根付かせる必要があった」とピータースは振り返る。
現在のゼネラル・エレクトリック社は、積極的にアジャイル開発を採用しています。
アジャイル開発は受託開発に適さない
書籍「「納品」をなくせばうまくいく」では、**「納品のない受託開発」**を行うことで受託開発でもアジャイル開発を導入している事例が紹介されています。
受託開発では、開発手法よりも契約がボトルネックになることの方が多いのではないかと思います。
その場合、発注者にアジャイル開発のメリットを伝え、納得してもらう必要があります。
もし発注者が求める価値とアジャイル開発が目指す価値が一致しないのであれば、残念ながらアジャイル開発の適用は断念せざるを得ないでしょう。
アジャイル開発の導入コストは低い
アジャイル開発の導入が失敗する原因の一つとして、導入に掛かるコストを低く見積りすぎていることがよくあります。
新しい言語やフレームワークを導入するときにコストが掛かるのと同じように、新しい開発手法を導入するときにも、それなりのコストが掛かることは認識しておきましょう。
また、ネットや書籍でちょっと調べた程度の知識でアジャイル開発を導入することは、かなり無謀な行為と言えるでしょう。
アジャイル開発の経験があるエンジニア（またはコンサルタント）が中心となり、きちんと計画を立てた上で、導入を進めることをお薦めします。
アジャイル開発は仕様書を作成する必要がない
勘違いの発端はアジャイルソフトウェア開発宣言にある**「包括的なドキュメントよりも動くソフトウェアを」**という一文にあるのではないかと推測しますが、全くの誤解です。
アジャイル開発においてもドキュメントは重要です。
ただし、仕様書の作成には Word、Excel、PowerPoint ではなく、Wiki を利用することを推奨しています。
最近では、Qiita:Team のようなクラウドサービスもよく利用されています。
アジャイル開発は計画を立てる必要がない
これも同じく、勘違いの発端はアジャイルソフトウェア開発宣言にある**「計画に従うことよりも変化への対応を」**という一文にあるのではないかと推測しますが、全くの誤解です。
アジャイル開発においても計画は重要です。
ただし、計画に不都合が発生したときには、柔軟に計画を変更することを推奨しています。
アジャイルは死んだ（Agile is Dead）
「アジャイルは死んだ＝アジャイル開発はもう使われなくなった」という意味ではありません。
アジャイル開発は 2001 年に誕生してから進化を続けており、様々なプラクティスが考案されてきました。
最近では、アジャイル開発を更に発展させた DevOps と呼ばれる手法が注目を集めています。
しかし、アジャイル開発の本質は今も変わっておらず、今後も受け継がれていくことでしょう。
参考：「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita