hacomono CTO のまこ (@macococo) です。
今回は Engineering Office チームで推進している Dev Team Criteria という取り組みについてご紹介したいと思います。
Engineering Office チームについては以前に以下の記事でご紹介させていただきました。
Dev Team Criteria とは
名前から察する方も多いと思いますが、日本 CTO 協会が作成・公開している DX Criteria を参考に作成した、hacomono プロダクト開発チームとしてのガイドラインのことです。
hacomono では2022年1月からプロダクト開発チームが複数に分かれ、現在ではプロダクトの機能開発ラインとして4チームほど存在しています。
チーム毎にミッションや体制は異なりますが、その中でも hacomono の開発チームとして大切にしたい指標をカテゴリ別にまとめ、チームの現在位置を確認できるツールとして製作を進めました。
カテゴリは以下のような内容となっており、チームで最大のパフォーマンスを発揮するために様々な指標を網羅するようにしています。
なぜガイドラインが必要だったのか
立場上、各チームのメンバーと横断的に会話したり 1on1 をするケースが多いのですが、その中で
- 各チームで似たような課題を持っており、それぞれで取り組んでいる
- あるチームの模範的な取り組み・改善を、私から他チームに共有している
といったシーンが増えてきており、組織として洗練していくためにチーム間でエコシステムのようにお互いスムーズに還元できる動きができないかなと考えました。
また一方で組織がスケールしていく中で、各チームの現在位置を可視化・モニタリングしていくたための仕組みも合わせて考え始めていました。モニタリングには定量 or 定性、リアルタイム or 定期それぞれの観点があると考え、定期的にチームの現在位置を知る打ち手の一つとして DX Criteria を参考にしてみた、というのが背景となります。
改めて Dev Team Criteria の目的をまとめると以下となります。
- 開発チーム共通で追うべき指標を定義することで、開発チームにて予測されるアンチパターンを踏まずに、チームの高いパフォーマンスを支援する
- 各チームの課題感を可視化することで、組織全体で早期解決に向けて動けるようにする
- あるチームの模範的・参考にすべきアクションを拾い上げ、他チームに還元していく
実施の流れ
まだ各チームでアセスメントシートの記入を1周回してみたところですが、以下のルールで走り始めています。
- 四半期に1回実施する
- アセスメントシートに現在の Lv を記入する
- チーム体制や状況に応じて評価が難しい指標については
評価不要とする - 各指標に対して Keep (指標の達成に向けて実施している良い行動)、Problem (指標の達成を妨げている悪い兆候)、Try (指標の Lv アップに向けて実施したい行動) を記入する
- Try をチームの四半期のイシューとして推進する
実際に実施してみてどうだった？
実際に記入に参加したメンバーからは
- チームの現状や課題について、メンバー間で認識を合わせることができた
- 色々課題がたくさんある中で、今期どこに注力して改善していくか方針を検討できた
といった声をいただきました。
チームについて考えるとどうしても今できていないこと・課題に目が向きがちですが、改善できていること・達成できていることも正しく認識することで、よりチームとして成熟していくのではないかと思います。
また私の立場としても、各チームがどのような課題を持っているか、その中で今どのような取り組みを進めようとしているかをこれまで以上に俯瞰できるようになりました。
まとめ
まだまだアセスメントシートの内容自体も改善の余地が多く、元々の狙いでもあった「あるチームの模範的・参考にすべきアクションを他チームに還元していく」という動きはまだまだこれからになりますが、今後継続していくことで開発組織のパフォーマンス向上に貢献できればと思います。
