高尚なタイトルだけれど、なんのことはない「アジャイル」と「DevOps」についてのまとめ。
どちらの概念もたくさんの方法論やツールがつきまとって、結局それらが何なのかがとても見えにくい気がする。根本となる哲学や世界観を理解すれば、どうして奴らがこうした方法論を重視するのかが少しは理解しやすくなるかもしれない。
アジャイルの世界観と哲学
アジャイル開発なる概念に通底するのは「予測不能性」という世界観だと思う：
「本当に」どのような価値が必要とされているのかは、実際にものが動くまで（もしかすると動いた後も）誰にもわからない。
上の原理は、「顧客本人が言っていることをそのまま実装しても、顧客がほんとうに欲しかったものは手に入らない」というよくある出来事が反映されている。
その上でアジャイル開発では（他の開発手法もそうだけれど）、「たとえ不確かであっても、顧客にとって重要な価値を発見し、提供する」という使命を至上命題として掲げる。
予測不能な現実のなかでこの至上命題を実現するには、どうしたらよいのか？そのための方法論として提起されているのが、いわゆる数々の「アジャイル手法」であるといえる。これらの手法の背後にあるアプローチは、基本的には
- 顧客と開発チームとのやりとりを密にする
- 顧客の要望に応じて柔軟にソリューションを変えていく
ということだろう。頻繁に「そこそこ動くソリューション」を顧客に見せて、その都度得たフィードバックをベースにして方向性を修正していくことで、開発しているものが「顧客がほんとうに欲しいもの」に近づいていく（はず）、というのがアジャイル開発の基礎になっていると思う。
DevOpsの哲学
DevOpsはアジャイル開発の考え方と近いようにも思えるけれど、おそらくその世界観の根本には「流動性」があると思う：
この世界は日々変化しており、昨日正解に思えた戦略が今日は間違いになっている可能性がある。
この種の要求によくある例としては、サービスが大規模化しても性能がスケールするようにしてほしいとか、（多少違うかもしれないけれど）バグがあったときにすぐパッチを当てられるようにしてほしいとか、そういうものが挙げられると思う。
その中でDevOps的な価値観では、「外部環境とのミスマッチ・誤差を迅速に検出して、機敏に対応する」ということを根本命題として掲げる。
この命題を実現するための方法論が、いわゆる「DevOps的」な手法であるといえる。基本的には、
- 運用・モニタリング手法を含めた設計
- ビルド・デプロイの自動化
というアプローチがとられるだろう。問題の検出や性能のモニタリングをするための（運用）手法を含めてソリューションを設計することで、問題の検知が速やかに開発チームの稼働につながるようにする。そして自動化を通じて、問題検知からソリューション更新までの時間をできるだけ短くする、という戦略が「DevOps的」なのだと思う。
おわりに
それだけ。基本的にはWikipediaにも書いてあるような内容だけれど、読むたびにわけわからなくなるので書いた。
個人的には、ほんとうに難しいのは実際には「誰がこのソリューションの利害関係者（ステークホルダ）なのか？」「利害関係者はどのような感想や要望を持っているのか？」といった点を明らかにする方法なのではないかと思うけれど、それはまあ「次のステップ」ということになるのだろうか…。