概要
アジャイル開発とは何か。アジャイルを取り巻く大きな目的・理念について、ロバート・C・マーチン『アジャイルソフトウェア開発の奥義』を参考にしてまとめます。
この記事では、「ソフトウェア開発」というレベルで「アジャイル開発」がどういう問題意識のもとで実践されるべきものなのかということに焦点を当てます。
書籍では、具体的なケーススタディとともに説明されているので、より理解しやすいと思います。
もっと別の側面もあるかもしれません。その辺りは不勉強なのですが、まずは一つの側面を（自分の勉強のために）まとめます。
また、この記事では具体的な手法についてはほとんど触れていません。
手法については、以下の記事が参考になるんじゃないかと思います。
アジャイル開発の大枠
アジャイル開発とは、システムを取り巻く環境の変化に俊敏に反応し、開発を進める開発手法のことである。
定義と言っていいんじゃないかと思います。「アジャイルagile」という言葉の語義「俊敏性」をそのまま反映していますし。
この定義から派生して、「プロセスが雪だるま式に肥大化してしまう循環を断ち切り」、開発の規模を小さく保つということが求められる。これはいわゆる「リーン開発」にも繋がって来るところじゃないかと思います。
そして、開発の規模を保つためには、原則を守った継続的な実践が必要になります。
これをまとめると、アジャイル開発の概念上の目的のヒエラルキーが見えてきます。
| 上位 | < | 下位 |
|---|---|---|
| 環境・要求の変化に 俊敏に反応する |
開発の規模を小さく保つ | 原則※1を守る |
※1 この記事内には、「原則」が二つ登場する。1つは「アジャイルソフトウェアの12の原則」であり、もう一つはアジャイル設計のための「オブジェクト指向設計」のための原則である。いずれも、アジャイル開発のための原則だが、前者は開発手法の原則であり、後者はソフトウェア設計のための原則である。より上位に位置付けられるのは、前者であり、後者の原則はそれを守る限りで重要視される。
普段仕事をしていると、原則などにばかり目を奪われがちだが、より上位の目的を忘れないようにしたい。
アジャイルソフトウェア開発宣言
宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
原則
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
「アジャイル開発を可能にするソフトウェア設計＝アジャイル設計」とは？(第7章)
アジャイルな設計とは、「ソフトウェアの構造や可読性を向上させるために、原則、パターン、そしてプラクティスを継続的に適用する行為である。またそれは、システムの設計を可能な限り、シンプル、クリーン、かつわかりやすく保つための献身的な行為である」。
ソフトウェアの腐敗とは一般に言う所の「技術的負債」のことだと考えていいと思う。ソフトウェアの腐敗を放置すると、変更コストが嵩み、最終的には再設計を余儀無くされる。
こうした腐敗を防ぐためにより良い設計が必要になる。
アンチパターン（ソフトウェアの腐敗）
ソフトウェアの腐敗の特性として、次の点が挙げられている。
| 名称 | 特性 |
|---|---|
| 硬さ | ちょっとした変更が難しい |
| 脆さ | 副作用の多さ |
| 移植性のなさ | 役立つ部分の切り離しの困難さ |
| 扱いにくさ | 下に注記※2 |
| 不必要な複雑さ | 設計時点で不必要な要素を含んでいる |
| 不必要な繰り返し | 同じようなコードが繰り返し現れる |
| 不透明さ | 不透明で入り組んだモジュール |
※2 扱いにくさには「ソフトウェアの扱いにくさ」と「開発環境の扱いにくさ」がある。
| 扱いにくさのタイプ | 具体的には… |
|---|---|
| ソフトウェアの扱いにくさ | 設計構造を維持したまま変更を加えることの困難さ |
| 開発環境の扱いにくさ | 開発環境ののろさ |
設計のための原則=SOLIDの原則
これらの原則は、必ずしも最初から適用されるべきものではない。「むしろ、それら（引用者注：SOLIDの原則）はイテレーションとイテレーションの間で適用され、コードやそれを実現している設計をクリーンに保つために用いられる。」
- 単一責任の原則(SRP: Single Responsibility Principle)
- オープン・クローズドの原則(OCP: Open-Closed Principle)
- リスコフの置換原則(LSP: Liskov Substitution Principle)
- 依存関係逆転の原則（DIP: Dependency Inversion Principle）
- インターフェース分離の原則（ISP: Interface Segregation Principle）
これらの原則の詳細についてはこの記事ではまとめません。別途まとめるかもしれません。
付録 アジャイルとリーン
アジャイルとリーンの違いがよくわからないなと思ったのでまとめてみます。
リーンの種類
リーンにもいくつか種類があります。
wikipediaのLeanのページを見ると関連項目がたくさんありますが、ソフトウェア開発などの文脈で混同されそうな項目としては以下の3つになるかと思います。日本語のwikiページがないのを見ると、それだけ文化として浸透してないんだろうなって感じがしますね。デイヴィッド・リーンも面白そうな人ではありますが。
| 日本語名称 | 英語名称 | wiki | 概要 |
|---|---|---|---|
| リーン生産方式 | Lean manufacturing | ja/en | トヨタ生産方式から抽出された生産管理手法 |
| リーンソフトウェア開発 | Lean Software Development | ja(なし)/[en] (https://en.wikipedia.org/wiki/Lean_software_development) | リーン生産方式をアジャイルソフトウェア開発に適用した開発手法 |
| リーンインテグレーション | Lean integration | ja(なし)/en | エンドユーザーに価値を提供し続けるためのデータ統合・システム統合のマネジメント手法 |
| リーンスタートアップ | Lean startup | ja/en | ビジネスモデルが継続可能（viable）かどうかの検証をし、ビジネスと製品を開発するための手法 |
リーンソフトウェア開発
リーン開発手法はアジャイル開発手法の一つとして位置付けられており7つの原則（参考：[リーンソフトウェア開発の７つの原則|アイネット] (http://www.e-ainet.com/LeanSoftwareDevelopmentPrinciples.html)）を行動指針として位置付けるものとされているようです。この原則の他に`22のツール`も定義されていて、それによって原則がより具体的に考えられるのだろうと思います。この辺りについては、また別途まとめられたらまとめることにします。
原則１．全体を最適化する
原則２．ムダをなくす
原則３．チームに権限委譲する
原則４．学習を強化する
原則５．早く提供する
原則６．品質を作り込む
原則７．決定を遅らせる
リーンスタートアップ
個人的に注目したいリーンはリーンスタートアップです。
リーンスタートアップとアジャイル開発を区別して役立てることで、開発における目的を整理できるように思います。
リーンスタートアップとアジャイルとの違いは、「「リーン開発」と「アジャイル開発」はどう違う？製品開発の不確実性を乗り越えるプロセスを知っておこう | データのじかん」のサイトでまとまっていました。ここでも改めてまとめなおすと以下のようになります。
共通点
- マネジメント手法であること
- 短いサイクルを構築することを良しとすること
- 不確実性・変化に対処すること
相違点
| リーン | アジャイル | |
|---|---|---|
| 対象 | 顧客開発 | 製品開発 |
| 重視するポイント | 仮説の検証 | 開発の進行 |
ここでまとまっているように、関心の対象が異なっており、目指すものも違います。
リーンスタートアップとアジャイル開発を区別することで、ビジネスサイドとシステム開発サイドとの関心ごとを切り分け、うまく連携することにつながるように思います。
まとめ
こう見ていると、アジャイル開発手法は「環境の変化に素早く対応して製品を完成させる手法」であることがわかりました。だからもし、ビジネス側にそういった要求が生まれないならアジャイルを取り入れる必要はないかもしれないと思います。