むかしむかし、組織がそしてシステムが小さな頃は開発や保守、運用という区切りは存在せず、みんなが全てを担当し、一丸となって運営を行っていました。
しかし、システムが複雑になるにつれ、組織も大きくなり、何時しかそれらの作業は1人1人のキャパでは回しきれなくなっていきました。
そこで困った組織長はチームを二分し、開発（・保守）と運用という役割に分けることにします。
チームの役割をはっきりさせることによって組織運営を円滑にするための措置でしたが、それによってチーム同士の戦いが始まることになりました。
開発と運用という縦割りと横割りの隊形
今ではシステム運営のイロハが世に出回っていますから、こんなストリーのように最初から非効率な状態で開始されるということはないかもしれませんが、それでも組織自体が小さかったり、要員が少ないという場合はどうしてもこのように非効率な状態から開始せざるを得ないというのはあるでしょう。
サービスを作り上げた当初、開発・運用の体制が数人というケースはよくあるでしょうし、そういった場合は書いたように全員が開発・運用を担っていくというような組織作りにせざるを得なかったりします。
私もこういった組織体制の変遷を辿ってきたりしましたが、最初はサービスやシステム単位でチームが組まれていきます。
あるシステムはこのチームが運営していく、別のシステムは別のチームが、というように組織が縦割りになって構成されます。
しかし、個々の規模が大きくなってくると各組織で同じような課題が出てきてそれを解決するための施策が立ち上がったりしてきますし、情報が共有されずに非効率な組織運営となっていきます。
それらを解決するために、どのシステムも横串で面倒を見れる開発チームや運用チームという横割りの組織体制に変わっていったりするわけですが、それでも情報共有がされないという課題は同じように出てきたり、横割り故に自分の作業に大きく弊害が出る問題が発生したりします。
縦割りの組織では、「よそはよそ、うちはうち」という割りきりができますが、横割りの組織の場合、業務上でお互いが通さなくてはならないフローを邪魔することがおき始めたりします。
開発には開発のルール、運用には運用のルールというものが出来上がるので、それはお互いのチームの中でよく吟味され、効率化やリスクを低減させるためのものだったりするわけですが、他のチームから見たらその良さは良さや理由が伝わってなくて面倒に思えてきたりします。
「なんでそんな面倒なことをするの？」「そんなの言わなくてもわかるでしょ？」という具合に、早くして欲しいのに遅々として進まない状況に苛立ちを覚えたりもするわけです。
運用チームの苛立ち、開発チームのジレンマ
運用チームから見れば開発の状況が見えないというのは苛立ちの一つでもあったりします。
もちろん進捗を確認する打ち合わせなどで開発担当者からの定期的な報告は聞いているんでしょうけど、何でそういう進捗になっているのかとか、そういった構成をとることになるのか、それを何故リリース後に運用が担当しないといけないのかなどなど、細かいところはなかなか共有されなかったりもします。
開発というのは一定の期間で終わることが多いですが、運用というのはそのサービスやシステムがある限り面倒を見なくてはならない業務です。
それ故に最初が肝心というのを運用の担当者は身にしみて覚えていたりします。
「最初は運用で回避して。後でシステム化するから」といったところで他の案件で開発要員の手が取られて一向に改善が進まないばかりか、そういったシステムが次々と回されてきて現場はパンク寸前なんてことがあったりするからでしょう。
一方で開発チームが受けるジレンマは、運用の細かなルールに縛られるところがあったりします。
「バグです」なら開発が悪いって事になりますが、サービスが止まった（止まりかけた）ってなると運用が責められますし、ユーザーとのやり取りの矢面に立つのが運用だったりもするので品質の維持に人一倍シビアに考えていたりもするからでしょう。
そのために多くのマニュアルが備えられ、ミスを防止するための細かいルールが整備されたりしますが、開発側から見ればそれは酷くまどろっこしいものだったりもするわけです。
ちょっとした機能をリリースしたり、サービスへの影響が無いメンテナンスをするためにも所定の手続きが必要だったりして、「そんなのこっちの責任でやらせてよ」って思ったりもします。
自分はどちらかというと開発側の経験の方が長かったりもするんですが、一番面倒に思えるのがサービスの維持のために必要なサービス監視だったりして、直接影響が無い作業でも監視引っかかったりするとアラートがあがって、運用の担当者に「何かやりましたか？」って都度都度状況を説明しないといけなかったりします。
もちろん監視自体は重要なものとわかっているのですが、そのちょっとしたことがすぐにできないジレンマがあったりするわけです。
「監視システムは5分おきにポーリングしているから、そのログから次の5分までに作業をすればばれないぞ！」みたいな変なノウハウを教わったりもします。
チームを一つにするための大義名分
開発と運用という組織が分かれた場合、その組織長が分かれたりしていて互いに仲が悪かったりする場合は困りものだったりするのですが、結局のところはその運営していくサービスをよりよくするためのことを考えていたりするわけです。
ただ、互いの領分を守ろうとするあまりに相手の言い分が聞こえないような状況に陥ってしまっているわけで、その目的達成のために自分たちの手法やルールが必要だと言い合っているだけだったりします。
こういった状況を打破するためにも、もう一度しっかりと互いの共通目的はなんなのかというチームを束ねるための大義名分が必要だと思います。
こういうのって結構シンプルなものでよくって、「このサービスをよりよくしてお客さんに喜んでもらいたい」とか、「世の中を良くするためのものを作ろう」とか、お互いにそういったことのためにしているんだけど忘れがちになっている部分をちゃんと互いに再認識しておくのって結構大事なんだなって思ったりします。
まぁ、こういうことをいえるのは互いの組織をさらに束ねる長がしっかりと示すべきでしょうけど、そういうのが期待できない場合は、相手の仕事を理解するためのチーム間のローテーションなども必要になってくるでしょう。
互いのチームのやっていることというものが見えればその理由というのもおのずと理解できますし、こういった情報が必要だろうとか、ここは運用とネゴしておこうとか、相手への気遣いというもの生まれて運営が円滑になったりもします。
何よりも互いのチームを回すための業務の知識というものは結構異なってきたりもしますし、システムの運用をするのにプログラムに理解が無いというのは結構開発視点でも運用視点でも辛かったりもします。
運用側の課題を解決するために自分たちでどうにかできないというのは、開発はサービスやアプリの開発に注力して運用の課題を解決するための施策に手を回す時間が取れなかったりもしますから、運用側は運用側で自分たちで運用ツールを構築していくといったことをしていかないと何時まで経っても仕事が降ってきて要員はパンク寸前という状況が打破できません。
あとは、何よりもチームが分かれているけど、互いにとって必要な存在ではあるわけですから、しっかりと情報を共有したり、言いたいことを言っておく場というのも大事になってきます。
色んなシステムの面倒を見ていて大変というのはあるんですけど、開発側も運用側もそれぞれの苦労があるわけで、互いの言い分だけでなくちゃんと理由を伝えることだったり、自分も運用側にいてその苦労がわかるからそれを回避するためにやってあげた方がいいことっていう気遣いをちゃんと示しておくとわかってくれたりもするものです。
そして、お互い何のためのこの仕事をしているのか？ってことの原点をちゃんと確認しておくべきじゃないかと思うわけです。