チームが自律して生産性を改善できる3つの原則
※2023年6月13日時点の情報です。初めまして、SODAでVPoE※を担当している林と申します。
※2023年10月よりCTOになっています。今回のテーマは「チームが自律して生産性を改善できる3つの原則」についてお話しいたします。
資料はこちら
発表は、3つのアジェンダでお伝えします。
一つ目はSmartHRのすがわらさんもお話されたように、生産性の要件はプロジェクトの規模によって異なりますので、この点について弊社SODAが開発している「スニーカーダンク」というサービスにおける組織体制についてご紹介します。
二つ目は組織の拡大の速度や規模により、遭遇する課題も変わってきます。過去2〜3年での我々のエンジニアリング組織の変遷について、人数やチームの体制、開発のプロセスなどを中心にお話します。
そして三つ目は、タイトルにもある「チームが自律して生産性を改善できる3つの原則」について、具体的な取り組みを交えてご紹介します。
本格的な話に移る前に、少し私のことを話させてください。
株式会社SODAには2020年の10月にジョインし、初めはWebエンジニアとしてプロダクトの開発を担当していました。去年からは、VPoEとEMの役職を兼務しています。前職では、サイバーエージェントという会社で、GoやAWSを用いたサービス開発をしていました。
我々の主なミッションは、エンジニアリングマネジメントを改善することです。これは「プロダクトマネジメント」「テクノロジーマネジメント」「プロジェクトマネジメント」「ピープルマネジメント」という4領域に分けられます。弊社のEMは現在3人しかいないため、補いあいながら4領域をみています。
SODAが開発するサービス・開発規模について
では、一つ目です。まずは弊社のスニーカーダンクというサービスについてご紹介します。これはスニーカーやトレーディングカードなど特定のカテゴリに特化したC2Cのフリマアプリです。取引が成立した場合、購入者と出品者が直接やりとりするのではなく、弊社の倉庫で商品の真贋鑑定を行い、その後購入者に商品を送るシステムが特徴です。
スニーカーダンクは2018年に開始され、2019年にフリマの機能が追加されました。現在のMAUは約500万人で、人気スニーカーの発売時には負荷が非常に高まることが特徴です。実際、特定のタイミングでのリクエストは非常に多いですが、それに伴う障害も発生したこともありました。
最近2年半ほどで、MAUは約100万人からこの数に増加しており、急成長していると言えます。弊社のシステムはGoを主として使用しており、ファイル数は4000ほど、コードの行数はテストを含めて約80万行になります。現在、大きなモノリシックなシステムを、モジュラーモノリスに変更する方向を模索しています。そういう技術面に興味のある方も募集しております。
デプロイの頻度についても触れたいと思います。いわゆるDDDというデプロイのカウントを開発者と営業日数で割った数がよくFour Keysのうちの1つの指標であるデプロイ頻度の計算方法として使われますが、それでいうと現在のデプロイ頻度は0.3で、弊社の開発生産性をトラッキングしているツールによれば、1年間の平均デプロイ頻度は6.6でした。
2. 直近2~3年の組織の変化について
続いて、二つ目のポイントの話に移ります。
beforeと書いている通り、組織の変化について2段階に分けて説明しようと思っております。
最初の期間は私がジョインした2020年10月から、2021年の12月までになります。この1年余りの間に、当初、CTOと私の2人だけだった開発組織が15人まで成長しました。
当時のアプローチは、リソース効率を重視し、開発タスクを上から順に取り組む形でした。このフェーズで事業が成長し、組織文化として事業成長を第一に考えるようになりました。現在、35人ほどのエンジニア組織がありますが、この規模でも事業成長を意識して動けるのは素晴らしいと思います。
しかし、リソース効率を重視することで属人化が発生しました。タスクの品質やスケジュールが異なる場合があり、プロダクトマネージャーとのコミュニケーションコストも増加しました。
2022年の初めから現在までのフェーズを「フロー効率期」と呼んでいます。エンジニアが35人まで成長し※、開発プロセスも変わりました。重要なのはフロー効率の向上、チームでの見積もりや振り返りです。このアプローチにより、ベロシティが安定し、スプリントの計画がスムーズに進行しています。
※2024/01現在では45名の組織になっています。
ただ、現状でも課題は存在します。例えばデザイナーの配置や役割が明確でないことで色々なチームに引っ張られ、社内チームであるにもかかわらず外注組織のようになっている点があります。
技術的な面では、モノリスからモジュラーモノリスへの移行が挙げられます。現在のチーム構成は各チームが独立してプロダクト開発のサイクルを回せる状態を目指しています。しかし、チーム間の知識共有や連携が弱く、これが課題です。
3. チームが自律して生産性を改善できる3つの原則
では最後に「チームが自律して生産性を改善できる3つの原則」について紹介します。この内容は、去年の年末に書いた記事から抜粋したもので、今回紹介する点はその具体的な取り組みについてです。
- 人事評価に活用されない生産性に関するメトリクスがある
- バリューストリーム全体に関与できる体制と権限がある
- 課題解決が評価される文化がある
まず、メトリクスは生産性を理解するための定量的な指標として必要です。ただ、これを人事評価にそのまま使用すると、不適切な数値操作が生まれる可能性があると感じています。
数値を操作する「ハック」についても、それが本質的な目的に沿った形であれば問題ないと考えています。例として、プルリクエストの数量を増やすことが、レビューコストの削減やサイクルタイムの短縮に繋がる場合などです。
次に、二つ目の原則についてです。
バリューストリームとは、開発からユーザーに価値を届けるまでの全てのプロセスを指します。これには、何を作るかの認識、制作方法の考慮、リリース、そしてフィードバックの取得などが含まれます。
バリューストリームを把握していないと、本質的な課題を見逃してしまいます。また、全体を管理しないと、課題の解決も難しくなります。
弊社では、フロー効率を向上させるために、PdMとエンジニアの連携を強化する体制に変更しています。これは、バリューストリーム全体に関わらなければ達成できない目標です。
チームに体制や権限が存在してたとして、各チームが自主的に改善するのは難しいと感じています。そのため、EMやSREチームのEnabling/Platform的なチームのサポートが不可欠です。
続いて、「課題の解決が評価される文化がある」という点。
弊社の評価制度は課題解決力を中心に据えています。課題をどのように解決し、その結果として何が得られたか、未解決の課題は何かというサイクルを明確にすることが大切です。このため、STARフレームワークを積極的に活用しています。
EMやIC（インディビジュアルコントリビューター）の価値観の中で、最近「スタッフエンジニア」という本が出版され、ICの世界でも意思決定を伴う課題解決が求められる動きが広がりつつあります。重要なのは、結果としての成果をチーム全体で確認できることだと考えています。
