非エンジニア系CPOが「システム運用のアンチパターン」を読んでみた
私はアキッパのCPOとして開発部門のマネジメントをしています。
開発部門にはエンジニア、デザイナー、プロダクトマネージャーの3職種の方々が日々プロダクト開発にいそしんでくれています。
私自身はIT業界で企画系のキャリアを歩んできて、プロダクトマネージャー上がりのCPOです。
技術系の話はプロダクト開発に必要な範囲で上流から下流まで一通り表面的にはこなせます（と思っている）が、あくまでほんとに表面的。
エンジニアが抱える悩み、課題、葛藤についてリアリティを持ったり寄り添ったり出来ているとは言いがたいですし、それが出来ていない以上、私が考えるプロダクト戦略・組織戦略の中にエンジニア視点が正しく織り込まれているとは言えないはずです。
そうした状況は遅かれ早かれ開発の生産性を下げ、やがてはチームの組織的な課題として顕在化しかねません。
なんなら実際に顕在化してる。
そんな悩みを抱える私が、チームのエンジニアがお勧めしてた「システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション」を読んでみたので、その感想を書いてみます。
書評や内容の解説は腐るほど検索したら転がってるのでそちらに譲るとして、あくまで非エンジニア系マネージャーがこの本を読む価値という点にフォーカスを当てたいと思っています。
自分と同じように、技術バックグラウンドがない管理職・マネージャーの方々に、この本が何をもたらしてくれるかを共有できれば幸いです。
そもそもなぜ非エンジニア系エンジニアリングマネージャーが存在してるのか
冒頭でも触れたように、私は「非エンジニア系CPO」としてエンジニアをマネジメントしています。
この構図には、メリットとデメリットがそれぞれ存在します。
メリット
ビジネス目線・ユーザー目線をプロダクトに反映しやすい
プロダクトのコンセプトやVisionについて語り、同じ方向性で物作りを行える
新機能やUX改善の企画からリソースアサインまで一貫して行うことで、開発スピードを上げられる
デメリット
技術的な評価やリスク管理が不十分になる恐れがある
エンジニアからの技術的信頼を得るまでに時間がかかる（一度損なうと「技術をわかっていない」というレッテルは払拭が困難）
リードエンジニアに負担が集中し、疲弊や組織スケーラビリティの低下を招く
非エンジニア系CPOがエンジニアリングチームを率いることは、“ビジネス寄りの意思決定”と“顧客価値重視のプロダクト開発”を推進できる一方で、技術的知見の不足によるリスク管理が課題になりがちです。
私見としては、サービス立ち上げ直後の小規模チームではメリットを享受しやすい一方、人数が10名を超えたあたりからデメリットが顕在化しやすいと考えています。
アキッパでも当初は小さな開発チームだったので、私がエンジニアのマネジメントも兼任していましたが、現在まさにそのデメリットが拡大してきている実感があります。
やばい。
システム運用のアンチパターンを読むことの価値
では、そんな非エンジニア系CPO/管理職がこの本を読むことで得られる価値は何でしょうか。
正直なところ、内容自体は「非エンジニア的にワクワクする」というよりも、教科書を読んでいるような感覚に近いかもしれません。スーパーヒーローのような経営者が劇的に意思決定をしてハードシングスを乗り越えていくようなストーリーはなく、淡々とシステム運用の失敗事例がケーススタディとして示され、あるべき姿が解説されていく構成です。
それでも私が、P.1からP.322まできちんと通読することを「非エンジニア系CPO/管理職」の皆さんにお勧めしたい理由を、以下にまとめます。
エンジニア思考に少しでも寄り添える
エンジニアが話すissueについて、点の話としては理解出来るんです。
一つ一つのissueに向き合って、その場で可能な限り適切な意思決定をしてきたつもりなんですが、恥ずかしながらこの本を読んで「ああ、エンジニアはこのスコープでものを考えてたのか」と新たに気づくシーンが何度かありました。
たとえば、本書にあった印象的な一文として、「DevOpsのほとんどすべてがそうであるように、自動化も文化から始まる」というものがあります。
いまアキッパの開発チームでは、運用の効率化や自動化を進めたり、アラート対応の体制を構築したり、顕在化している課題を一つひとつ着実に改善してくれています。
その推進を担ってくれているエンジニアの何名かは、入社当初から「エンジニアリングカルチャーがまだまだ足りていない」と口にしていました。
私としては、「この作業を自動化したらこれだけオペレーションコストが削減できる」「アラート対応力が上がることで、毀損する体験価値や売上をヘッジできる」など、どうしても“点”として捉えていたんですよね。
もちろんそれらは間違ってはいませんが、エンジニアの皆さんは「効率化・自動化」そのものよりも、カルチャーを育てることまで含めて（むしろそちらに）課題設定していたわけです。
一面的にしか捉えられてなかったです。ごめんなさい。
エンジニアとの共通言語を増やす
DevOps、メトリクス、アーキテクチャ、CI/CD、ポストモーテム——。非エンジニアからすると「なんとなく聞いたことあるけど、正直ちゃんと理解していない」という言葉、ありますよね。
ちなみに私はポストモーテムとトーテムポールが良く頭の中でごっちゃになり、ポストモーテムの話が出たときに「なんで急にインディアンの話してるんだろう」ってなることがあります。
もちろんネットで検索すれば解説はいくらでも出てきますし、ChatGPTに聞けば丁寧に教えてくれます。
しかし本書では、DevOpsの流れに沿ってそれらの用語がどう関わり合っているのかを体系立てて解説してくれているため、「こういう背景でこの言葉が生まれたのか」「この概念とあの概念はこう繋がるのか」といった深い理解に繋がります。
技術投資へのバランスについて考えさせられる
本書の主旨は、DevOpsの重要性と、その具体的・標準的な運用方法を提示することにあります。
要はサービスの可観測性を高め、ビジネスKPIと技術KPIを連動させて、システムの可用性とスケーラビリティを担保するための手法として、DevOpsをどう実践するかを描いているわけですね。
ビジネスKPIだけを追いかけても、ゴールにはたどり着けないことは承知のうえでも、「では、その技術KPIをどう紐付けるのか？」はなかなか実感しにくいところでした。
実際のところ、何を指標とするかはサービスごとに違うでしょうし、「これさえ見ればOK」なんて明快な答えが用意されているわけでもありません。
ただし、そうした指標はおそらく非エンジニアが一人で考えられるものではなく、エンジニアと一緒に考える必要があるという気づきは、本書で改めて感じました。
そして、KPIをビジネス面に紐付けるのは、非エンジニア系CPO/管理職の役割かもしれません。そこで初めて「今必要な技術投資や、将来的に必要となる技術投資」を冷静に検討し、意思決定できるようになります。
さいごに
この本を最後まで読んだとして、やはり「広く浅く」という感覚は拭えないかもしれません。
もっとも、今までよりは多少でも“深く”なったという感覚が得られれば、それだけでも十分に価値はあると思います。
ただし、本当に必要な技術的な課題設定や解決策の立案・推進は、最終的にエンジニアにリードしてもらう必要があります。
それがテックリードなのか、EM（エンジニアリングマネージャー）なのか、CTOなのかは組織によって異なるでしょうが、完全に丸投げすると必ず疲弊します。
上でも述べたように、DevOpsは単なる仕組みではなくカルチャーそのものでもあるので、人やシステムを含めて変えていくのは一朝一夕にはできません。
非エンジニア系CPO/管理職がまずやるべきは、そうした人材の確保や能力密度を高めること、裁量を与えて仕事をしやすくすること、評価や日々のコミュニケーションで意識改革を後押しすること——そういった部分かもしれません。しっかり腰を据えてエンジニアと密に会話しながら、時間をかけて進めていく必要があるでしょう。
非エンジニアとしてエンジニア思考の解像度を高めつつ、同時に“非エンジニアである自分”の限界を見極め、どうエンジニアと協同していくかを考えるきっかけとして、本書は非常に有益だと感じました。
おそらく、非エンジニア系CPO/管理職にとってのいちばんの価値は、そこにあるのだと思います。