この記事は「開発生産性 Advent Calendar 2022」に参加しています
18日目の記事です。
昨日は y_matsuwitter さんによる 「プロダクト拡大と開発生産性」 でした。
20名のエンジニア組織でエンジニアリングマネージャーをしています
株式会社SODAでエンジニアリングマネージャーをしている @rinchsan です。
SODAは現在20名ほどのエンジニア組織で、プロダクトマネージャーやデザイナーと協力しながら「SNKRDUNK（スニーカーダンク）」というプロダクトを開発しています。
不確実性の高い課題に立ち向かうは特にチームの自律的改善が重要
不確実性の高い課題を解決すべくソフトウェアプロダクトを開発している組織では、各開発チームが自律して自分たちの開発生産性を改善していけることがプロダクトの急成長には欠かせません。
1人のスーパーマンに頼っていては近いうちに頭打ちが来るでしょう（しらんけど）。
同じアドベントカレンダーの10日目の @isanasan_ さんの記事でも言及されていたことにも通ずると思います。
チームが自律して改善していける状態を作るための3つの原則
他にも細かいプラクティスはあると思いますが、大枠としては下記3つの原則を満たすことができれば自律的に改善していけるチーム作りが出来ると考えています。
- 人事評価に活用されない生産性に関するメトリクスがある
- バリューストリーム全体に関与できる体制と権限がある
- 課題を解決していくことが評価される文化がある
順番に詳細を見ていきましょう。
1. 人事評価に活用されない生産性に関するメトリクスがある
建設的な議論・定量的な分析をするには、メトリクスがあることが重要です。
メトリクスを人事評価に使ってしまうと本質的ではない目的で数値がハックされるかもしれないのでやめておきましょう。
ただ、生産性の改善に繋がるのであればハックしてしまうのは問題ないと考えます。
また、定量的なデータのみに注目してしまうと、それはそれで本質的な方向に議論が進まない場合も多いので、チームメンバーの定性的な感想などを議論に織り交ぜることも同様に重要です。
よく利用される指標としては、Four Keysやサイクルタイム、Velocity（Sprint中に消費できる合計Story Point）、PR作成数などが見受けられます。
弊社SODAでは、 Findy Team+ や Notion のDatabase/Viewを使ってこれらのメトリクスを可視化・分析しています。
HIGH OUTPUT MANAGEMENT でもこのように言われていました。
各ビルの維持保全状況を定期的に採点させることにした。次にこの採点を別のビルの得点と比較させた。すると、〝全ビル〟の状態が急激に良くなった。他に何もしたわけではない。金や報酬を良くしたのでもない。彼らが手にしたのは競馬場、すなわち、競争の場であった。
アンドリュー・S・グローブ. HIGH OUTPUT MANAGEMENT (Japanese Edition) (p.258). Kindle 版.
2. バリューストリーム全体に関与できる体制と権限がある
効率的に開発生産性を改善するには、バリューストリーム全体に関与し、本質的な課題を発見することが重要です。
また、見つけた課題を改善するための取り組みを実行できる権限をチームが持っていることも重要です。
「権限を持っている」と言い切れなくても、取り組みを進めるのが難しい場合にサポートを求められるエンジニアリングマネージャーなどがいるとよいでしょう。
改善の取り組み自体をサポートしてくれるDPE（Developer Productivity Engineering）チームなどのEnabling Teamが存在することも価値が高いでしょう。
Team Topologies で導入されるStream-aligned Teamなんかはまさに「バリューストリーム全体に関与できる体制と権限があるチーム」ですね。
ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるだろう。さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。
マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (p.144). Kindle 版.
ちなみに、Enabling Teamの定義についてはこのように言及されています。
イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。そうすることで、ストリームアラインドチームは、多大な労力をかけずに能力を獲得し進化できる（私たちの経験では、能力獲得と進化を自分でやる場合に必要な労力がチームに与える影響は、10～15倍過小評価されている）。
マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (pp.151-152). Kindle 版.
3. 課題を解決していくことが評価される文化がある
最後に、プロダクト開発を効率的・効果的に進めて事業成長に寄与することが会社・チームのバリューとして定義されていて、バリューの体現が人事評価に繋がることが重要です。
バリュー体現に向けて動くにあたって必要な職務が言語化されていることも重要です。
さらに言うと、その職務が一般的に見たソフトウェアエンジニアとしての市場価値の向上に繋がることも重要です。
THE TEAM 5つの法則 でも、チームには共通の目標があることが重要で、それをサポートするために目標設定を行うことが言及されています。
「共通の目的がない集団」は「チーム」ではなく「グループ」
〜中略〜
チームをチームたらしめる必要条件は「共通の目的」です。麻野耕司. 『THE TEAM 5つの法則』
ありがたいことにFindy Team+ Awardも受賞しました
本記事でご紹介したような取り組みが少しずつ成果に結びついているのか、ありがたいことに「Findy Team+ Award 2022」を受賞することが出来ました。
もっと強い組織になっていきます
上記3つの原則を意識しながら開発組織を強化してきました。
ただ、まだまだ出来ていないことが多くありますし、もっと強い組織になれると思っています。
引き続きこの3つを担保しながら開発組織を強化していきたいので、一緒に歩んでくれるソフトウェアエンジニアやエンジニアリングマネージャー求む！！！
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion