最近よく見る「DevOps」。

例えば、

マイクロソフトはYammerからDevOpsを学ぼうとしている - Publickey

とか

DevOps時代の開発者ための構成管理入門(1):現代のソフトウェア/サービス開発で構成管理が重要になった5つの理由 (½) - @IT 

とか。

開発と運用の連携を密にして、運用で得られるフィードバックを早く開発に戻し、さらに開発はそのフィードバックを早く製品に反映する、という手法の一つです。

でも、開発部門と運用部門っていうのはたいてい仲が悪い。なので、理想とするところはとてもよく分かるし、そうしたいのは山々なんだけど、現実的には難しいよなぁ。運用に任せるのは正直勇気いるし、開発がやっちゃった方がなにかと早いんだよなぁ。

って思ってたら、こんな記事が。

開発と運用の新しい関係、「DevOps」とは何か? - Publickey  

2011年3月8日の記事です。(けっこう前)

この中では、

伝統的な組織では、開発部門と運用部門は対立しています。

はい、そのとおりです。

開発部門は新しい機能を追加していきたいのですが、運用部門は安定したシステムに手を加えたくないためです。両部門の利害が対立しているわけです。

です。運用は保守的。

しかし運用も目的はシステムの安定稼働ではなく、ビジネスの実現ではないか。

ビジネスを進めて行くには変化が必要である(だから開発部門は新機能を作り続けている)。

そうです。そうありたいです。

変化・変更によるリスクを、ツールと社内文化によって低くすればよいのだ。

ツールはわかる。社内文化は…。

自動化されたインフラとバージョン管理、ビルドツールといったツール群、そしてお互いを尊敬し、信頼しあう文化が大事であると。

PaaSとgitとJenkinsと、あとは気持ちの問題、と。

システムは運用でコケるケースがけっこうあって、使われなくなっちゃうものが多い。「システムは使わないと錆びる」っていうのはホント。

こうならないように、運用は早くフィードバック、開発は早く改善、というサイクルが大事。で、そのサイクルを回すためにツールを駆使しよう、と。

たぶん、今後はこの考え方が主流なんだよな。じゃないと戦えないよなぁ。