かつてDevとOpsの間で起きていた悲劇
日本ヒューレット・パッカード 荒木健一氏は国産メインフレームのフィールドエンジニアとしてエンジニア人生を始めた。作業場となるマシンルームには数百個ものLSIを搭載した水冷式のメインフレームが並び、その景色は子どものころに思い描いた「21世紀のコンピュータルームのようだった」という。
メインフレーム時代のDev（開発者）はアプリケーション開発実装やシステム設計を行い、Ops（運用者）はテープやフロッピー交換などの定常業務、ログの監視やジョブ実行などの管理業務、あとはQAやトラブル対応などをしていた。荒木氏にはDevが花形で、Opsは世話役のイメージだった。
後にオープンシステム、さらに仮想化の動きがあり、それまでDevが担当していたインフラ設計や運用設計がOpsに引き渡され、役割分担が変化していった。運用設計とはシステム運用のフレームワークを作ることにあたる。目的を定め、何をどこまで管理するか、定常業務の体制やスケジュール、トラブル発生時のフローなどを定める。最終的にはドキュメント化することで、属人化やブラックボックス化を防ぐ。
長年、DevとOpsの役割分担は難しい課題となっている。荒木氏もかつて、悲しい対立を目撃したことがある。顧客企業の社員向け営業支援システムの開発プロジェクトでのこと。システム開発担当と運用担当がそれぞれ設計を行っていた。設計書は共通の場に保存されていたものの、互いに無関心で、詳細の中間レビューがされることはなかった。インフラが構築され、その上で開発したシステムのテストを始めてみると、プロジェクトと関係ないサービスのパフォーマンスが不安定になるという事態に陥った。
対策会議を開いてみると、DevとOpsの間で「もう今さら変更できない。あなたがこちらに合わせてください」とバトルが勃発。最終的には互いに譲歩して設計を変更することになったものの、調整でサービス開始が遅れる羽目になった。荒木氏は部外者としてただ推移を見守るしかなく、心の中では「もっと早くからその話を進めてほしかった」と感じていたそうだ。
こうしたバトルは珍しい話ではない。DevとOpsは互いに無関心になりがちだ。それで後になり問題が発生する。荒木氏は「互いに積極的にコミュニケーションし、理解を深め、共通の運用観点を持つことが取り組みをうまく進めていくうえで必要だと考えます」と指摘する。
