何を書く？
アジャイル開発とは何か？ この答えはボンヤリ説明されることが多くて、なんかわかったような、わからないような。 Scrum の朝会をやってればいいの？ 普通の開発を素早く繰り返したらアジャイル開発なの？ などなど疑問は多いです。
あらためて、煙に巻かずに、実践的に、誤魔化さずに、その背景を説明してみるというチャレンジです。
2019.10 : 「評価（テスト/レビュー）についての考え方」を追加しました
アジャイル開発とは（ぼんやりした版）
一応、哲学的な、でも本当は正しい、説明を書いておきます。 でもこれは忘れてくれても大丈夫です。 免罪符的に書いておくだけです。
アジャイルとは、常に改善している状態・より良いものを目指している状態です。 本質的にはこれがアジャイルで、アジャイル開発について言われるさまざまな手法やルールがありますが全てはこの状態を目指してのことです。
その考え方の本質はとてもシンプルな言葉で「アジャイルソフトウェア開発宣言」に書かれています。
……さて何のことかわかりませんね……忘れましょう。
アジャイル開発とは（きっちりした版）
さて、きっちり説明していきます。 アジャイルでの開発 と アジャイルではない従来型開発 との違いをはっきりさせることで、アジャイル開発とは何か？をあきらかにしていきましょう。
厳密にいうとここでアジャイルと呼んでいるものは、ほぼ Scrum を指しています。 でも、Scrumだのアジャイルだのややこしいことを言いだすと混乱してくるので（いえ、別に本当はややこしくないですけど……）ここではScrumでも気にせず「アジャイル」と言ってしまいます
アジャイル開発 vs. 従来型開発
鉄の三角形による説明
鉄の三角形とは、Scope と Time と Cost による三角形です。
- Scope ... 何を作るか
- Time ... どれだけの時間をかけるか
- Cost ... どれだけのお金をかけるか
無限にお金も時間もあれば何でも作れますが、実際はそんなことはなく何かを優先して何かを捨てないといけません。 さて何を守って何を捨てましょう。 ここがアジャイル開発と従来型開発とのもっとも大きな違いです。
従来型開発では、Scope を固定にします。 何を作るかというのを決めて、その作るものに対して、Time と Cost を考えます。 作るものにあわせて、お金と時間を考えるのです。
アジャイル開発では、Time と Cost を固定にします。 例えば5人で1週間と決めてその中で何を作ることができるか（Scope）を考えます。 つまり開発チームと時間にあわせて、どれだけのものを作ることができるかを考えるのです。
Scopeが固定ということの意味をもう少し考えてみると、つまり、要件が変わらないということです。 いわゆる従来型のウォーターフォールでよく言われる、作るものを決めたら途中で変えられないということです。 逆に、Time と Cost を固定にして Scope を変えられるということは、要件を変えられるということです。 途中で要件が変えられるというアジャイルの特性です。
成果物の分割と時間の使い方
アジャイル開発ではTimeを固定にするとはどういうことでしょう。
※Costについては後で
従来型開発では、Time は変動です。 成果物を大きな1つの塊として考えます。 その大きな成果物を作るためにはどれだけの時間でもかけます。（つまりは、成果物ができあがるまでどれだけでも残業でも休日出勤でもしろということですよ）
アジャイル開発では、Time は固定です。それも、かなり短い時間で固定します。 通常は1～2週間です。 その1～2週間で作れるだけの小ささに成果物を分割します。 そしてその1～2週間を何回も繰り返して組み合わせることで大きな成果物を完成させます。 成果物の分割は「設計」「実装」といった時間的な分割ではなく、「XX機能」「YY機能」のような機能的な分割です。（専門的には リリース可能性な成果物 という言い方をします） どうして機能的な分割にするか？ですが、それは機能的な分割にすることで個々の機能が検証可能になるからです。 検証した結果、イマイチうまくいかない、いけてない、ということがわかれば要件を変えていきます。 もっと優先度が高い案件がくればそれを対応します。短い時間の繰り返しにすることの他のメリットとしては、締め切りを短くきめてゴールの達成感を頻繁にあたえることでモチベーションを保ち続けるという効果もあります。
人と開発工程
次に、Costを固定にするとはどいうことでしょう。
ソフトウェア開発での Cost とはほぼ人のお金です。 設備やライセンスのお金の場合もありますが、ほとんどは人、つまり、何人かということになります。 ソフトウェア開発は、要件定義 → 設計 → 開発 → テスト と進みます。 その時のかかわり方についてです。
従来型開発では、各工程にあわせて人をわりあてます。 要件定義であれば要件定義書を作るために必要な人と時間をわりあてます。 設計であれば設計書を作るために人と時間をわりあてます。 開発工程ごとに必要な人を必要な時間だけわりあてていきます。 工程ごとに必要な時間も人数も変わってくるので、工程ごとに別の人が対応することがほとんどです。 要件定義チーム、設計チーム、開発チーム などです。
要件定義は親会社のお偉いさんがやって、設計はエンジニアチームがやって（お偉いさんの曖昧な要件に苦労して）、開発は外部のパートナーがやって（技術力のない設計者に苦労して）、という構図ができあがります
アジャイル開発では、逆で、チームを固定にして、そのチームでできる範囲で 要件定義 → 設計 → 開発 → テスト をやっていきます。 固定されたチーム、つまり、同じ人がずっとすべての工程を行います。
この違いがドキュメントの考え方など様々なところにきいています。
ドキュメントとスキルの考え方
アジャイル開発ではドキュメントを作らないという噂があります。それは嘘です、作ります。でも無駄なものは作らないのです。なぜならドキュメントではなくコミュニケーションやスキルアップでそれをまかなえるからです。
従来型開発では、各工程にあわせて人が変わるため、工程間の情報の引継ぎとして設計書を作る必要性が出てきます。 前工程で学んだことはドキュメントにして、次の工程に引き渡します。 チームがかわって会社がかわったりするので納品物としての位置づけでもドキュメントが大事になります。
アジャイル開発では、工程が変わってもチームは変わりません。 なので前工程で学んだことはチーム内のスキル・ノウハウとして人に残っていきます。 そのため無駄なドキュメントがいりません。
ちょっと誤解される方がいたので補足で。「ドキュメントがいらない」ではないです「無駄なドキュメントがいらない」です。絵で描いた方が理解が早ければ絵を描くし、大事なことは文章で残します。ただチーム活動がメインになることで（ドキュメントやメールより）共同作業や会話などでのコミュニケーションに重きがおかれるので必然的にドキュメントが減っていく方向になります。
責任や目標の考え方
従来型開発では、工程ごとにチームが変わります。 つまり、各チームの責任は、その工程を終わらせることにあります。 目標は、その工程において問題を起こさないことです。 プログラマが設計の不備を見つけたら、設計者に文句を言います、設計者は要件の不備を見つけて文句を言います。 お互い、自分たちの身を守ることが目標になりがちです。
アジャイル開発では、チームが固定になります。 かかわる人が固定です。 その人たちがずっとシステムを作り続けます。 つまり、チームの責任はシステムを作ることですし、目標もよりよいシステムを作ることになります。
評価（テスト/レビュー）についての考え方
アジャイルは「課題を早期に発見するためのフレームワーク」という言われ方をすることがあります。
従来型開発では、中間成果物に対して評価を行います。いわゆる設計書などです。ただ人間はそこまで完璧な生き物ではないので設計書から完成品をイメージすることはできません。実際に完成品を使ってみないと正しい評価ができません。そのため全工程を終えて最後にソリューションが出来上がった時に「思ってたのと違う」という大きな失敗になり取り返しがつかない状態になりがちです。
アジャイル開発では、常に実際に動作するソリューションに対して評価を行います。開発途中に正しい評価ができる可能性が高く小さく失敗して改善を繰り返すことが出来ます。
ドキュメントよりも顔色がわかる朝会でのFace to Faceを大事にしたり、ダンの定義と言って終了条件を明確にしたり、小さなリリースを繰り返すのも「課題を早期に発見する」ためといっても良いです。課題さえ早期に気付くことが出来れば対応をすることはできます。
本当に速いのか？価値あるものを生み出すか？
これはハッキリ言ってそんなことありません。
まずそもそも従来型開発とアジャイル開発では出来上がるものが異なることがほとんです。なので単純に比較はできません。もしまったく同じものが出来あがる、という前提であれば最初に方針をしっかり決めて無駄に多くのチェックポイントも作らず後戻りも考えない従来型開発の方が速いと思います。
価値あるものを生み出せるのか？ それもハッキリ言ってそんなことありません。 従来型開発でもレビューにユーザーを入れることはできますし要件定義段階でユーザーのコメントを緻密にヒアリングすることも可能です。
他の開発手法でスキル不足で出来なかったことが、手法を変えたからと言って急にスキルアップして出来るようになるみたいな魔法のようなことは起きません。
まとめてみる
そろそろまとめてみます。
アジャイル開発とは、固定チームで、短い時間で小さな機能を作る、を繰り返す手法。
チームを固定にすることで、無駄な引継ぎドキュメントを作らずにすみ、チーム自体の継続的なスキルアップによってシステムの開発速度と品質を高めることができる。
システムを小さく分割することで、システム自体の良し悪しの検証が可能になり、より良いシステムを目指すことできる。
そんな手法です。
とまとめてみました。
いかがでしょうか？
蛇足： "Scrum" について
上記に書いたのは「アジャイル開発」についての背景や心がけの部分です。
Scrum というアジャイル開発の代表的な手法があります。 Scrum のさまざまなルールやセレモニーを守ることで、なんとなくアジャイルっぽいことはできますし、アジャイルっぽい効果は出ます。 ただ、形だけまねてもやっぱりそれはカタチだけですし、Scrum のすべてを忠実に実施するのは実はとても大変です。 今回のようなその背景の部分を理解することで、ぜひ、本質的にアジャイルな開発を実践してくれるとうれしいです。 アジャイル開発は、それにかかわる人たちを Happy にしてくれる手法です。 ぜひみなさんやってみましょう。
わたしの思い浮かべる "アジャイル" もまだまだこれから改善していかなければいけないです。 道途中です。 アジャイルは常に改善していくことであって、振り返った時に、はじめて、あの時はアジャイルだったとわかるものです。
この記事に書ききれなかった追加分を書きました。もう少し細かいテクニック的な部分になります。
https://qiita.com/567000/items/cae22014776437e6d6a2