DevOpsがキーワードとして挙がっていたので、その時に思ったことを、過去の経験と合わせて書いてみたくなった。
それが題名の部分。自分なりに身近に感じてきたDevOpsを開発状態や経営状態とからめた時間軸で考えてみたくなったから。
書く前に今はどんな認識なんだろう?って思ったので「DevOpsとは？」でぐぐる。
■調査結果
- DevOpsって何？(株)paperboy&co.宮下 剛輔2010/5/19
- DevOps とは何か何であるべきか qpstudy 2013.01 2013/01/26 宮下 剛輔
- インフラエンジニアに成る：TagDevOps
- DevOpsな現場で求められる 「インフラがわかる デベロッパとは？」 2012/09/27 （上記ブログのスライドを抜粋)
ざっと上記のスライドを見て大まかな定義をつかむ。概念として有用な形と、対象者を特定した具体的行動の指針とかが出ているってことは、始まっている感がある。
■開発規模や組織の人数
「DevOpsな現場で求められる 「インフラがわかる デベロッパとは？」 2012/09/27」でも冒頭に出ていた例があったけれど、NoOpsというスタートはけして珍しくないものになっていると感じている。
・リーンスタートアップやWEBサービスベンチャー創業時
2～5人程度で創業した当時とか。予算は長くても1年分（それも、当事者の持ち出しが半分とか、給料を生活ぎりぎりに食い詰めての1年とか）
このような時に、Ops専任とかって存在しているほうが珍しい。だって、運用すべきシステムは形すらないのだから。あるのは開発環境と本番環境がほぼ同意義となったクラウド上のサーバだけ。
もしかしたら、小さいオフィスにファイルサーバ兼開発環境があるかもしれない。モデルは既に解散してしまったが、友人が就職していた創業当時のベンチャー会社。
とにかく企画書なんて紙に殴り書きしてるプロデューサーと、仕様書というメモを作りながらコードを書きまくるプログラムとWEBデザイン担当者数人。サーバ構築をしながらも人材を集めたり金策の手伝いをするようなインフラエンジニア、グラフィックをとにかく作るグラフィッカー（とある業界では原画と色塗りで分かれていて、狭義のグラフィッカーは色塗りのみだけれど、このときは分かれずにとにかく完成品を作る人）
こんな状態で「Devの役割はー」とかのたまう時間もないし、Opsが「仕様書がちゃんとしてないので、構築できねえよ」なんていう世迷言も許されない。
許されていたら、数か月もしないうちに組織は解散しているのでDevOpsとか考える必要はない。
・運よく資本が尽きる前にサービス開始したり、大手の資本投下で運営が始まった
収支は赤字かもしれないけれど、従業員給与が1年分は払える見込みが立ったり、金融機関から融資が出たり。スタートして間もなくだけれど、利用者が付いたのでサービスとしては継続できる状態に。
こうなると、Opsが必要になってくる。それは、サービスを受けている利用者から苦情が入るから。それは改善要望だったり、単純にサーバが負荷で応答できなかったり、バグだったり。これに対応している人と、スタート時は見送られた未実装の機能を開発する人と、お知らせやイベント（ゲームなら特に最近はソシャゲ系）を入れ替えたりする人は、全部同じDevの人。
これでは、せっかく幸運なスタートができた人々も頭がおかしくなってしまう。
ここで、人材（もしくは運用会社）の追加が行われることが多い。追加されるのは同じような開発者が多いと思うが、サーバの拡張※や移行※をする担当者が入ることもあるし、毎日サービスを継続できているか監視する人も必要になってくる。これらの業務を全て行う一人だけが増員だと思うけれど。順調なパターンとしては、これを繰り返し、2～5人だった組織も10人程度まで膨れてくる。
※サーバの拡張や移行の補足
今ではクラウドサービスでリソースの拡張なんてメンテナンス1日なんていう作業見積りで行えるようになったけれど、物理サーバしかないという時代は、新しいサーバの手配で一か月、OSインストールからミドルウェア構築、アプリを載せてテストなどで1～2週間は軽く飛んでたので良い時代になったものだと思う。もちろん、機能拡張している間に構築の手順が変わっていたりして、事前調査からやらなきゃいけないなんて言う罰ゲームもあった。
この辺は前職の会社に入ったばかりのイメージ。フロア全体の人数は既に10人以上いたけれど、1サービスに関わる担当者は5～8人ぐらいだった。
当時は運用を行うチームという事で4人で仕事をしていた。個人差もあると思うけれど、仕事をしているときに連絡を密に取り合うのは5人程度が普通で
10人とか15人とかと意思を確認し合って仕事ができる人は特殊な才能の持ち主だと思う。極端な人なんて、1人と連絡を取り合うしかキャパがない人だっているし。
ここからDevとOpsが分かれてくる。
Opsに所属している人、Devに所属している人、この内部だけでやるべき仕事の話が完結したら、「チーム内で仕事が回る」という状態ができてしまうからだ。
DevとOpsが分かれていない当時の初期メンバーが居残っていれば、これらの組織間の境界ルータのように、仕事の連携をするから問題なく進む。
まれに、伝令が自分の天職だというエンジニア（？）もいるので、そういう人が初期メンバーに代って重宝されたりする。
・組織の分離とDevOpsがいがみ合う状態
システムやサービスは安定してきて、数年先を見越した計画が立てられるようになってくる。人員も仕事の規模も大きくなっている。トータル30人ぐらいは居るだろうかっていう状態。
一つのサービスをみんなで支えている感覚がある人と、自分に与えられた仕事を全うしたらよいと考える人に分かれてくる。
そうなると、仕事がうまくいかない時に「言った、言わないの喧嘩」「環境が整っていないから自分の仕事を始められない！という不満」「自分は苦しいのにあっちの組織は涼しい顔で定時帰りはおかしくない?という不満」「昼も夜も休日も。電話があればトラブル対応しないといけないプレッシャーに耐えられない。という不満」などが発生してくる。
結果、OpsはDevに対して「要求をはっきりとさせる書類を作ること」を始めるし、DevはOpsにたいして「いちいち書かないと何もやってくれないので自分たちの負担が増えるから開発者増員を」という要望を出す。
これらは、前職だけじゃなくて今色々な現場で働くようになってからも見えることなので、共通なんだろうなぁとぼんやり思っている。
DevOpsの話になると、この状態を解決しようという話が多いような気がする。
・組織管理の組織ができて官僚化していく
安定運用や大胆なシステム拡張ができる状態。金銭面での心配はあまりないが、経営資源、人的資源の投入先は現場ではなく、営業活動が大半だったり、法的部分や株式市場などに向いていて、現場はとりあえず、小規模改善で何とかしなさいという雰囲気。
組織間で直接やりあうと喧嘩ばかりなので、一定のルールを定めたり組織間のやり取りは、別の組織が取り締まる。
部門長や経営者で構成された組織が決定をするので、判断材料としての紙をいっぱい必要とする。
僕が新入社員で入った時の会社がモデルかな。あと、前職の取引先とか、今職の取引先とかにもちらほら。中小企業の大きいほうや大会社。
結構日本的にどこでもありそうな感じの会社。
エンジニアが行う仕事に政治的交渉や迅速な決定が含まれていないという特徴があるので、失敗しないように責任を分割する方法として、企画書とか、申請書とか、調査票とかいろんなものが文書になって生成され、判断され、命令に変わり、失敗は報告書の形で処理されて、人間的には傷もつかないし働くことに摩擦が起きないような状態。
こうなってくると、DevとOpsの間とか直接話が全くなくても問題なし。時々は呼ばれて話すこともあるけれど、腫れ物に触るごとく波風も立たず。
DevOpsという概念は必要ないけれど、実現コストとこれに至るまでの時間は大変だなと思う。
ただ、企業の資本も拡大しているし、焦ってトラブルを招くよりは時間をかけてでも安全策で。人件費みたいな固定費用は増やしたり減らしたりの調整が難しいので、設備（おもに使用するパソコンとか）を削ったりして売り上げとかのバランスを取ろうとしているので、人の問題はなるべく起こらないようにしていくんだろうな。
あ。OpsはOps内部の、DevはDev内部でのルール徹底とか作業ノルマだとかいろいろあるので、仕事をする上でのストレスから解放されているかは別の話。
異なる組織間の摩擦が担当者の間では無いっていうだけ。もちろん、部門長の間とかは協力と駆け引きと陰謀で誰が組織の権力を握るかというパワーゲームの小っちゃい版は行われていると思う。
■まとめ
DevOpsの概念は1サービス10～30人規模の開発、運用部隊が分かれて存在し、組織間を取り持つルールや上意権限を持つ組織が未整備だったりする場合に有効な概念だと思った。サービス継続を安定的にしていくという点では資本の力が偉大だなと思うけれど、すべてのスタートアップがそこに辿り着くでもないので、実践できたら強みになるだろうと思った。