devopsチームのリーダーになって始めたエモい目標と取り組み

PLAN-Bに入社して5年と10ヶ月が過ぎました。 入社した当時はエンジニアとしてDMPプラットフォームの開発や、新規プロダクトの開発を行っていました。 2年ほど前から社内のdevopsチームのリーダーを経て、現在はエンジニアチームのマネージャーをしています。組織や文化をどう作っていくのかを考えつつ、新規プロダクトの開発・運用をdevopsとしても行っています。 入社当時の5年10ヶ月前の自分は、現在のマネージャーの立場・役職になるとは想像もしていませんでした。一生エンジニアとして現場にいると思っていました。

PLAN-Bに入る前の会社でも開発部のマネージャーをしていましたが、完全なプレイングマネージャーでした。組織について考えることはなかったですし、自分自身もマネジメントへの興味はなかったです。
一生エンジニアの現場にいようと思っていた自分が、どんな心境の変化があり今の立場になっていったのか？
１エンジニアからdevopsチームのリーダーとしてチームをどう作っていったのか？
マネージャーになる前に経験したdevopsチームリーダーとしての活動や学びを紹介します。

エンジニアからマネージャーへのきっかけ

エンジニアのままでは変えられる範囲に限界があるなと思いました。例えば組織や技術戦略などはエンジニアの責任の範囲とは違うこともあり、携われる面積が少ないなと思ったのが最初でした。 簡単にいうと「変えていく為の権限がないなぁー」と思っていました。 例えば、その当時僕がメンバーとして所属していたdevチーム内での決めごとには参加できるけど、devチーム自体をPLAN-Bの中でどういった 組織にしていくのかなどの議論には入れなかったことがありました。 一生現場にいたいと思っていたにも関わらず、自分で組織を変えたい・作りたいと思っていることに気づきました。

この時、エンジニア組織のマネジメントを行っていく覚悟ができたと思います。その当時のリーダーやマネージャーがどういったことを考えているのかなんかを、背伸びして考えるようになりました。 それまでの自分に関わってくれていたリーダーマネージャー・部長など色々な人の影響もあり、マネジメントを学び始めました。

devopsチームのリーダーへ

当時のマネージャーに「マネジメントの方をやっていきたい」と伝えたことで、まずチームリーダーとして、社内で新しくできたdevopsチームを任されました。 devopsチームは、社内にあった複数のプロダクトの運用をまとめて行うチームです。

運用するプロダクトは4つ

当時、以下の４つのシステムやサービスがdevopsチームで担当したものです。ほとんどが、新規開発を行うフェーズは終了して運用フェーズに入っていました。

• Jucier（DMPプラットフォーム）
• OLIVE （社内業務支援システム）
• Reallo（社内広告管理システム）
• Comee（漫画の口コミサービス）

ゴール設定を行う

まず初めに「devopsチームとしてプロダクトをどういった状態に持っていくのか？」などからチームとしての目指すべき目標を決めました。 以下の３つの目標です。

1. 宇宙一ローコストなシステムにする
2. 人類が滅亡してもシステムが稼働しているようにする
3. 事業の利益を倍増させる

運用フェーズに入っているとは言え、プロダクトごとに置かれている状況や課題は違います。プロダクトごとに細かく考えてしまうとチームとしての共通の目標がなくなり、向かっていく先がずれてしまうので、出来るだけエモい目標を掲げるようにしました。

ゴールに向かうための指標を決める

次に目標を達成するための指標と、指標の目標値を決めました。 事業の利益とシステムの障害が一見すると結びつかないのですが、「システム障害に対応する時間をなくして、新規開発やサービスの改善に使える時間を増やす」ことで、サービス（事業）の価値を倍増させられると考えていました。また、障害の件数とレベルを把握することで、小手先の対応ではなく根本的対策を行うための指標となります。 システムの障害というのは本当にいらない時間です。１ミリもサービスの価値を上げていないです。

エモい目標は漠然とイメージはしやすいですが、「じゃー実際どうやったらええねん」となりがちなので、目に見える指標（数値）として定義するのが大事だと思います。

指標の数値を取る仕組み

次に行ったのは指標とした数値を取る仕組みを作ることです。あまり手間にならないように仕組み化するのが大事だと思います。 指標となる数値を出すために、他の数値が必要なこともあるので、必要な数値関連をまとめて取得できる仕組みが必要です。

例えばシステム稼働率は、「システム稼働時間（月）」と「サービス障害発生時間」の２つの数値から計算する必要があります。 稼働時間とサービス障害発生時間をどこに集めるのか？どのタイミングで集めるのかなどを一つずつ決めていきました。

(集めた指標とデータはチームで見られるようにしましょう。本サイト参考記事: Metabaseを使って成果の可視化でチームの心を1つにしよう！ツール選定と実際の手順をご紹介！ )

ふりかえりの設定

次がふりかえりの設定です。目標を決めた、指標も決めた、数値を取得する場所や期間も決めたあと、ふりかえりを行うタイミングを決めました。 数値を取って満足してしまうパターンも多いかと思うので、数値をもってふりかえりをするタイミングを決めておくのが大事です。 ふりかえりで話す内容もここで決めていました。

ふりかえりの内容

作業割合・コスト、サービス稼働率・MTTR、障害の３つ観点か、KPT（Keep, Problem, Try)でふりかえりをしました。

ふりかえりの頻度

ふりかえりは月に1回、月初に行っていました。 当初1週間ごとにしていましたが、短すぎると対策が終わりきらないのと、1週間単位では数値の変化があまりでなかったので、最終的に月1回になりました。

メンバーへの説明

最後になりますが、目標、指標、数値のとり方をメンバーに伝えます。決めたことを淡々と落とすのではなく「なぜやるのか？いつまでにやるのか？だれがやるのか？」を意識して伝えました。How（手段）はメンバーに考えてもらうようにしました。各プロダクトによって課題も違うし、状況もちがうので、自分たちで手段を検討してほしかったからですね。

devopsチームでの学び

devopsチームリーダー時代の取り組みを書きました。苦労したことも、うまくいったことありました。

苦労したこと

コミュニケーションには苦労しましたね。メンバーはそれぞれで各プロダクトに向き合っているので、メンバー間での横のやり取りがなくなり、助け合いが少なくなってしまうことがありました。「チームで解決する」仕組みを作るのに苦労したのを思い出します。

当時はエンジニアとしてもプロダクトに関わっていたので、リーダーの仕事とエンジニアの仕事の両立ができないことがありました。特に障害が発生した時なんかはプロダクトにかかりっきりになってしまうので、その間はリーダーとしての業務が止まってしまい迷惑をかけることも多々ありました。

うまくいったこと

プロダクトの数値をできる限り見える化していったことで、プロダクトについて定性で話すのではなく、数値をもとに定量で話をできるようになりました。 チームメンバー同士の「労務費とか通信費とか稼働率がこうだからあーだから」みたいな会話を聞いた時は、やってきた取り組みが定着したなーと実感した瞬間でしたね。。。

さいごに

自分がやってきた取り組みを振り返ってみることがあんまりなかったので、今回書き出せてよかったです。 実際に本稿の取り組みを行って改善したことは多くありました。毎月数値を意識したふりかえりを行うことで改善するポイントが明確になったり、担当プロダクト以外の部分の改善にも意見がいえるようになったりしました。 特に大きく改善が見られたのはコストの部分で、数値をもとにした改善活動の結果、通信費を大きく減らすことができました。 ここに書いてある方法以外に手段はたくさんあると思いますが一つの成果が出た方法としてお役立ちできれば幸いです。

どれだけ改善を続けても、数値をとって見ていく中で新たな課題がどんどん出てきます。プロダクトは運用だなーと実感します。 devopsチームのリーダーとして、1エンジニアではなくチームで課題に立ち向かうことで、よりプロダクトに成果を出すことができました。マネージャーとして組織作りに関わる前に、リーダーとしてチームを持てたことは良い経験になりました。