開発組織にモノサシを - モチベーションクラウド開発におけるDX Criteriaの活用事例 -

8073 ワード
SRE DX 組織 QA マネジメント マネジメント テキストリンク

この記事はモチベーションクラウドシリーズアドベントカレンダー2020の5日目の記事です。

Intro - はじめに

はじめまして。リンクアンドモチベーションでSREチームのテックリードをしている河野です。

私は今年の6月に入社したのですが、尊敬できる優秀な仲間たちとエンゲージメント高く働いております。
コロナ禍真っ只中での転職だったため、フルリモート環境で信頼関係を構築できるか、パフォーマンスが発揮できるかといった不安がありました。
ただ、そこは組織開発を専門としてる会社だけあり、多くのサポートがありました。
おかげでスムーズにオンボーディングできたと実感しております。

...この辺の話をし出すと、オンボードエピソードだけでも記事にできるレベルなのですが笑
本記事では、私が取り組んだ開発組織のメトリクスを定義し、測定・改善した事例を紹介します。

Why - なぜやるのか

私たちはHR SaaSプロダクトであるモチベーションクラウドをはじめとした、複数のSaaSプロダクトの運用・改善をしております。

モチベーションクラウド
https://www.motivation-cloud.com/

私たちの開発組織は内製化がはじまって約2年が経ちました。
これまで、多くのシステムや業務プロセスの改善に取り組んで来ました。

そんな中、改善は進む一方で開発組織・システムの習熟度が可視化されておらず、
「我々の開発組織・システムは今どの程度の習熟レベルなのか」
「どのケイパビリティをどこまで伸ばすべきか」
といった、客観的な状況や課題、目指すべきゴールが分かりづらく合意形成しづらいという課題がありました。

現在、リンクアンドモチベーションは事業拡大に伴い、エンジニア採用を強化をしています。
組織がスケールする中で、TL/EMといった技術・組織における裁量をもったメンバーが増えています。
今後、上記の課題が技術的な意思決定をする上でのボトルネックになり得る状況でした。

こういった背景から、事業責任者から「開発組織の習熟度を計測できるようにしたい」という期待もあり、開発組織メトリクスを策定し、運用することになりました。

What - 何をしたのか

大きく分けると、以下の2つのことを実施しました。

  1. テーマとメトリクスの策定
  2. メトリクスの運用サイクルの設計

1. テーマとメトリクス

まずは、我々が追うべきテーマとメトリクスの策定を行いました。
事業責任者とEM/TL陣とも議論を重ね、4つのテーマとそのメトリクスを決めました。

4つのテーマ

テーマごとのメトリクス

まずは、今では一般的になった以下のメトリクスを活用しました。

それ以外にも、品質と信頼性をテーマに置き、以下の3つの独自メトリクスを設けました。

セキュリティリスクスコア

システムやプロセスにおけるセキュリティリスクを低減することを目的としたスコア。
潜在的なセキュリティリスクを影響度と発生可能性でスコア化し、High/Middle/Lowにレベル分けし対応優先度を決める。
他にも、AWSのTrustedAdvisorやSecurityHubといった第三者による評価もスコアに含め管理している。

インシデントスコア

リリース品質を向上させることを目的としたスコア。
リリースで発生したインシデントをスコア化したもの。
インシデントの影響度、リリースの頻度、発生要因などを元にスコアを算出する。

インシデント再発防止スコア

インシデントの再発防止対応が徹底されることを目的としたスコア。
インシデントの事後対応の状況をスコア化したもの。
状況によっては、既存開発の優先度を下げてでも対応する。

2. メトリクスの運用サイクル

メトリクス策定後、これをどう運用するかを設計しました。
設計にあたり、冒頭にあった弊社プロダクトのモチベーションクラウドの改善プロセスを参考にしました。

「組織の改善サイクルをまわすためには、"モノサシ"が必要。」
というプロダクトの思想と、メトリクス運用に親和性があること。
また、社内で浸透したフレームであるため、導入が容易であると考えました。

次に、メトリクスの基準を策定し、"何をどこまでやるべきか"が組織内で合意が取りやすいよう以下のように整理しました。

上記のメトリクス基準を元に、下図のようなマトリクスに項目をマッピングしていきます。
この作業は特定の一人で行わず、ステークホルダー（弊社の場合は事業責任者とEM/TL）を集めて実施します。
この表を元に、"フォーカスポイント"および"注力しない・やらないこと"を明確にしました。

フォーカスポイントを決めたら、メトリクスごとにOKRとアクションプラン、オーナーを決めてQ〜半年といった期間を設けて改善サイクルをまわします。

Outcome - 結果どうなったか

開発組織メトリクスを本格的に運用し始めたのが9月ごろ。
この3ヶ月の運用で、大きく5つの効果がありました。

定性面

まず、技術課題のどこにフォーカスすべきかの合意形成がスムーズになったように感じます。メンバーからも「指標全体から直近で解くべき課題を選定し、Mgrと合意できた」といったポジティブな意見をもらえました。

また、リードタイム短縮を目的とした中長期的な技術投資として、アーキテクチャの刷新をするという大きな意思決定ができました。事業責任者とメトリクスの策定・運用をする中で、「足元の改善だけでなく、抜本的な改善が必要である」という課題感がすり合ったおかげだと思います。

他にも、コードの複雑性解消やデッドコード削除、リリースプロセス改善を目的とした改善PJが発足しました。これまでは個々人の善意に頼っていたものが、目的と目標を持って取り組めるようになったことで改善が加速し、メトリクスにも良い影響を与えました。また、これらの改善PJのオーナーの多くは若手に任せており、若手がオーナーシップを発揮する機会創出の場としても機能しています。

定量面

具体的にどの指標が伸びたかはここでは触れませんが、着実にDX Criteriaのスコアが向上しています。
ただ、DX Criteriaのサイトにもあるとおり、過度な数字目標にすることは推奨されていません。
私たちも、現状を可視化したことで課題が明確になり、それを解決したことで結果としてスコアが向上したと捉えています。項目によっては、戦略的に低いスコアのままでステイさせているものもあります。

リードタイムはボラが大きい指標という前提で、意識して計測を初めてまだ数ヶ月の状況で成果と言うのは早計かも知れませんが、こちらも着実に短縮できています。
リードタイムの計測には、shibayu36さんの以下の記事を参考に計測ツールを活用しております。

PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた

Outro - おわりに

いかがでしたでしょうか。
メトリクスはただの数値管理だけでなく、現在地と未来を紡ぐコミュニケーションツールとしてもとても有益であると感じました。

今後の展望として、さらなるメトリクスの活用を視野に入れております。

  • 事業戦略と照らし合わせた新たなテーマやメトリクスの追加する
  • モチベーションクラウドだけでなく、他システムにも活用する
  • 開発組織に限らず、他組織にノウハウを横展開する
  • etc

弊社開発組織は、2018年より内製化に着手しており、上場企業ではあるものの開発組織は内製化してから2年足らずでスタートアップ企業と変わらないスピード感や裁量があります。
コンサル会社と思われがちですが、コロナ後も前年比110%で成長しているSaaS企業です。

少しでも興味がある方はぜひこちらをご確認ください。
https://open.talentio.com/1/c/lmi-jp/requisitions/1616

また、開発組織の記事も是非ご覧ください！
https://www.wantedly.com/stories/s/lim_engineer_story

私どもの取り組みがなにかの参考になれば幸いです。
明日は、QAチームリーダーの小島による「QAの私にとって心強かった、バグを出さないエンジニアの行動3つ」です。
お楽しみに！