高さの差はあれ、開発と運用の壁の存在は昔から問題視されていましたが、先日見た東日本大震災（東北関東大震災）後のツイートで、これはどうしたもんだろうと思うものがあったため、今更ながらのテーマですが取り上げます。

私が見かけたのは、「運用部門はこれからBCPやデータセンター内の電力確保に動かなければならないのに、開発部門の人たちは、こちらの事情をお構いなしでテストを実行し続け、開発サーバの電源も落とさずに帰ってしまった」というTwitterのつぶやきです。

みなさん知っての通り、震災直後から東日本全域で電力が不足しています。以前のエントリーで扱ったように、首都圏のデータセンターでは非常用電源の発電エンジンで使う燃料が不足しており、「ITサービスを安定供給するために如何にして電力消費量を抑えて計画停電を凌ぐべきか」について、運用に携わる人間は頭を悩ましています。

【石油燃料が入手できず、計画停電（輪番停電）でサービス停止するデータセンターに要注意】
http://blogs.itmedia.co.jp/infra/2011/03/post-bef8.html

そのような状況を前にして、「自分たちは開発側の人間だから、目の前の構築スケジュールを遵守することだけ気にしていればいいや」と思考停止してしまい、組織全体の視点でモノゴトを判断できない人たちがいるのは悲しいですね。

”想像力が足りない”

この言葉を最近よく見かけるようになりました。被災地の方が新聞社のインタビューで「現地の人が何に困っているのか、政府の人は想像力が足りていないんじゃないか」とコメントしていたからなのか、鉄のラインバレルの影響なのかは分かりかねますが、自分で調べて考える「自調自考」の姿勢に欠けている人が増えている気がします。

IT部門でいえば、その典型が、開発と運用の相互理解の無さでしょう。

私が敢えて「相互理解」という言葉を使っているのは、運用側の人間も開発側に対する理解を積極的にしてこなかったからです。運用部門に求められるのは、開発側から引き継いだITサービスを維持運用していくことであり、程度の大小はあれ、保守的に今の環境を守ろうとします。主な変化は開発側から与えられるため、受け身の姿勢が当たり前なのです。

受け身の姿勢で精一杯だという組織が多いのは事実だと思いますが、やはり、開発側との接点を積極的に持とうとしないスタンスは、システムライフサイクルを踏まえた長期的な観点からすると、組織全体のITサービスの発展に寄与しているとは言えません。

2010年頃から欧米ではDevOpsという言葉が登場しています。DevelopmentとOperationが頻繁に情報交流し、新しいITサービスのリリースで生じる障害リスクを低減しようというアプローチです。ここには開発と運用という壁はありません。ITサービスを提供する1つの組織がただあるだけです。

※DevOpsについてもっと知りたい方はPublic Keyのエントリーをご覧ください。
http://www.publickey1.jp/blog/11/devops.html

これを実現する第一歩は、開発部門と運用部門の人的交流であり、「開発側ではこうやってましたよ」「運用の人たちはこうすると助かると思いますよ」といったノウハウレベルの知識共有を始めることです。お互いが何を考えているかが見えてくると、相手の立場で思いやることができるようになります。その結果、組織のITサービス提供力（競争力）は高まり、一体感を持ったIT部門が誕生することでしょう。

東日本大震災に係る草の根的な互助活動の有り様を、この1週間見てきました。他人のためにここまで一体感を持てる人たちが、たかだか開発と運用という壁を越えられないはずがありません。

今の世界的な機運に乗じて、開発と運用の壁を壊そうじゃありませんか。同意して下さる方は、下記のリンクをクリックしてみてください。他にどれくらいの人が共感してくれているかが分かります。

http://開発と運用の壁をなくして.ほしい.jp #kanael

厳しいご時世ですが、前向きな姿勢を崩さすに進んでいきましょう。