この度、私たちの開発チームが、Findy様が主催する「Findy Team+ Award」を2年連続で受賞するという、大変光栄な機会に恵まれました。これもひとえに、日々変化する状況の中で試行錯誤を続けてくれたチームメンバー一人ひとりの努力と、客観的な指標を与えてくれるFindy Team+というプロダクトのおかげです！
今回の受賞を一つの節目とし、この2年間でチームの生産性にどのように向き合い、組織をスケールさせてきたのか、その試行錯誤の歩みを振り返ってみたいと思います。
この記事が、同じように開発組織の成長や生産性向上に課題を感じている方々にとって、何かしらのヒントになれば、嬉しいです！
実際にエンジニア同士で語っている動画も作成したのでぜひご覧ください！！
1年目：戦略的にフォーカスをリードタイム改善に絞り着実に改善
現状診断
今から2年前、Findy Team+を導入した当初、私たちはまずチームの現状を客観的なデータで把握することから始めました。それまでの感覚として「開発者体験は決して悪くないはずだ」という自負はありましたが、Four Keysの数値を可視化してみると、予想とは少し違いました...
それは、「デプロイまでのリードタイムが長い」そして「スループットが安定しない」という、開発生産性における課題でした。具体的には、プルリクエストが作成されてからマージされ、本番環境にデプロイされるまで、時として1週間以上かかるものもありました。これでは、ビジネスサイドの要求に迅速に応えることは難しく、エンジニアにとっても手触り感のある開発ができているとは言えません。
自分が「開発者体験は決して悪くないはずだ」と思っていたのは、2時間くらい待ってレビューなかったら鬼リマインドしていて開発を進めていたからであり、健全では無かったというのが数値をみて理解できた感じでした。今思うと誰もが気兼ねなくリマインドできるわけではないので、全然チームのこと考えられてなかったなぁと思っています。
「やらないこと」を決める
Findy Team+による診断で課題は明確になったものの、当時の開発チームはまだ正社員3名という少数精鋭の体制。リソースが限られる中で、すべての指標を一度に改善しようとすることは、かえって全てを中途半端にしてしまう危険性を孕んでいました。
ここでリチャード・P・ルメルト氏の名著『良い戦略、悪い戦略』を思い出しました。この本は、良い戦略が「あれもこれも」という足し算ではなく、「何に集中し、何を捨てるか」という引き算によって生まれることを教えてくれます。
良い戦略は、進むべき道筋を指し示す力強い指針である。行動を統合し、的を絞ることで力を生み出すのだ。悪い戦略はその逆で、相反する要求や利害をあれもこれもと取り込もうとする。
（『良い戦略、悪い戦略』より）
この教えに基づき、「変更障害率」と「サービス復旧時間」の2つの指標を、一旦は戦略的に「追わない」と決めました。なぜなら、私たちのチームには、すべてのプルリクエストに対してコードレビューを行う文化が根付いており、Staging環境での動作確認やリリース後の挙動監視も当たり前のフローとして組み込まれていたからです。つまり、障害発生率は元々低く、致命的な問題にはなりづらいという確信がありました。
それに加え、「万が一バグが発生したとしても、それを修正するプロセス自体を爆速にできるリードタイムを実現すれば一石二鳥でいけるやろ」と楽観的に決め、リードタイムの改善に突き進みました！
この戦略的な選択と集中により、私たちは持てるエネルギーのすべてを「リードタイムの短縮」という一点に注ぎ込みました。
リードタイムを分解し、ボトルネックを特定する
「リードタイムの短縮」という大きな目標を達成するためには、その内訳をさらに分解し、どこにボトルネックがあるのかを特定する必要があります。Findy Team+では、リードタイムを以下の4つの区間に分解して計測してくれるので大いに活用しました。
- コミットからプルリクエストオープンまでの時間
- オープンからレビュー開始までの時間
- レビュー開始から承認までの時間
- 承認からマージまでの時間
2年前、私たちのチームの数値は以下のような状態でした。
このデータを見て、私たちがまず注目したのは「オープンからレビュー開始までの時間」でした。ここは、チームの認識や方針を揃えるだけで、最もコストパフォーマンス高く改善できる領域だと考え、レビューに関する基本方針を明文化することから着手しました。体感としても、プルリクエストがオープンされてから最初のレビューまで数時間かかるケースが散見され、改善の余地が大きいと感じていました。
方針の作成にあたっては、開発生産性カンファレンス2024でLayerXの高江さんが発表されたこちらのスライドを大いに参考にさせていただき、私たちのチームの状況に合わせてカスタマイズしました。
主な内容は、これら4つの区間ごとに目標時間を設定し、レビュワーとレビュイー双方の心構えを明記するというシンプルなものですが、実行力の高いチームメンバーのおかげで、目標に向けて一気に改善が進みました。
導入当初は「レビューのために自分の実装を中断すると集中力が削がれる」という懸念の声もありました。しかし実際には、「プルリクエストを出す→即座にレビューされる→即座に修正してマージ」という高速なサイクルが回ることで、複数のタスクを頭の中で並行して抱える必要がなくなり、かえって目の前のタスクに深く集中できる、という嬉しい副次的効果がありました。
並行してタスクをやる必要がなくなったことにより、「オープンからレビュー開始までの時間」以外の部分も圧倒的に時間が短くなったのには、とても驚きましたが、1点集中して全体の数値が上がったのはissueの見極めが良かったなと感じています。
こうした取り組みの結果、1年目には大きな成果を上げ、Findy Team+ Awardで「優れた開発者体験が実現されているチーム」を受賞するに至ったのです。
2年目：チームの成長に合わせ、スループットの安定と向上へ
次の課題：「アウトプット」の壁と安定性
1年目の成功体験は、リードタイム改善の「勝ちパターン」に繋がりました。チームは勢いに乗り、その裏で正社員も5名へと着実に成長しました。
幸い、私たちのチームにはオンボーディングの仕組み化やドキュメント整理といった、組織のスケールを支える文化が根付いていたため、人数の増加は順調に吸収できていました。
そこでサイクルタイム(リードタイム)の改善は一時止め、少なくとも維持したまま開発生産性スコアの向上に着手しました。
1年目の段階で全ての項目が「Elite」という評価になっていましたが、どの会社も生産性に注力しているという話を聞いていたので、現状に甘んじることなく個人のスキルへの依存から脱却し、チームとしてさらに突き抜けた存在になるにはどうすればよいか。
私たちの次なるテーマは、アウトプットの総量を増やし、かつチーム全体で安定させることへと移っていきました。
アウトプットを最大化するための、泥臭くも効果的だった3つの打ち手
1. 無駄なミーティングの廃止と気付いたタイミングで直接話す
エンジニアの生産性を蝕む最大の要因の一つは、細切れのミーティングによる「集中時間の中断」です。私たちは、チーム内のすべての定例ミーティングを洗い出し、一度すべてを無くす、もしくは頻度を落とすという方針を取りました。特に、形式的になりがちだった1on1の定例枠を思い切って廃止しました。
その代わりに、フル出社という働き方の利点を最大限に活かし、「必要なときに、必要な人と、必要なだけ話す」という、より柔軟なコミュニケーションスタイルへと舵を切りました。この方針はドクターズプライムのカルチャーとしても定義されているのですが、改めてそのプリンシプルに沿って整えた形となります。
一見すると、この「必要な時に声をかける」スタイルは、かえって中断を増やしてしまうのではないか、と思われるかもしれません。しかし、私たちの狙いはその逆です。
定例ミーティングは、たとえアジェンダがなくとも時間を確保し、参加者全員のコンテキストを強制的に切り替えてしまいます。
一方で、私たちの推奨する同期コミュニケーションは、「誰かのタスクが止まってしまうのを防ぐための、必要最小限のやりとり」です。
Slackで数日返信を待ったり、次の定例まで質問を寝かせておくことで失われる時間的コストは、5分間の短い同期コミュニケーションで解消されるコストよりもはるかに大きい、と私たちは考えます。疑問が即座に解消されることで、開発者は再び深い集中状態に戻ることができ、タスクの滞留を防ぎます。
結果として、予定に縛られる大きなコンテキストスイッチがなくなり、タスクを前に進めるための質の高い小さな同期コミュニケーションが増えることで、メンバー一人ひとりがより長く、本質的な集中時間を確保できるようになったのです。これは、時間を「作る」ための重要な一歩でした。
2. Claude Codeの“強制”導入する
これまでも任意でAIを使っていましたが、チーム全体のアウトプットのベースラインを引き上げ安定させるため、Claude Codeを全員導入し、利用を「全員必須」としました。
導入にあたり、私たちは「使いたい人が使う」という任意な形ではなく、全エンジニアアカウントにライセンスを付与し、「利用数最下位は剥奪」という、少し強引なルールを設けました。(半分冗談です笑)
全員必須にすることで必然的に勉強会の開催やスラッシュコマンドの急速な設定などがより加速して進みました。煩雑なボイラープレートコードの記述から解放され、より本質的なロジックの実装に集中できるようになったのです。コーディングスタイルのばらつきが自然と抑制され、レビューの負荷が軽減されるという副次的な効果もありました。
どのような設定をしているかは、こちらも見てみてください。
3. ホワイトボードで指標を可視化する
最後の打ち手は、驚くほどアナログなものでした。インテルの元CEO、アンディ・グローブ氏によるマネジメントのバイブル『HIGH OUTPUT MANAGEMENT』では、マネジャーのアウトプットを最大化するための「テコ作用」の考え方と、そのための「インジケーター（指標）」の重要性が繰り返し説かれています。
マネジャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット
（『HIGH OUTPUT MANAGEMENT』より）
直接では無いですが隣接している成果を出している営業チームが受注件数をオフィス内のホワイトボードに書き出しているのを真似て、開発チームの重要指標（週次のデプロイ数など）を、物理的なホワイトボードに毎日手書きで書き出す、という試みを始めました。
デジタルツールでいつでも見られる指標を、なぜわざわざ手で書くのか。最初は「意味があるのか？」と半信半疑でしたが、このアナログな行為が、チームに予想以上の効果をもたらしました。指標が常に目に入る物理的な空間に存在することで、チーム全体の共通言語となり、日々の進捗が自分事として捉えられるようになったのです。「今日は目標まであと少しだね」「今週はペースが速いね」といった自然な会話が生まれ、健全な競争心と一体感が醸成されました。他チームのメンバーからも「開発チーム、すごい勢いだね！」と声をかけられることが増え、メンバーのモチベーションを大きく高める結果となったのです。
「アウトプット」の追求をする中での葛藤を乗り越えて
一連の施策を進める中で、実は心の中に常に一つの葛藤がありました。それは、「アウトカム（事業への貢献）が重要視される現代において、アウトプット（生産量）を追い求めることに、果たして本質的な価値はあるのか？」「数値を追い求めるだけでメンバーは疲弊しないか」「アウトプットを上げたところでバグが増えたり変な価値観が蔓延しないか」という問いです。
数字を追い求めるあまり、安易な実装や価値の低い機能改修に走ってしまう「数字稼ぎ」を助長してしまうのではないか。この懸念は、人数が増えていく中で最も警戒していたことでした。
この根源的な問いに対し、チーム内で「ズル賢しい数字の稼ぎ方は絶対にしない」という共通認識を醸成すると同時に、事業戦略やチームのミッションに紐づいた、価値ある課題解決に繋がるリリースだけを称賛するという文化を、意識的に作り上げていきました。
また、メンバーの経験やスキルレベル（グレード）に応じて、期待する役割やアウトプットのレベルを個別に調整する仕組みも整えました。リードエンジニアが中心となり、各メンバーのタスクの難易度設定や目標達成をきめ細かくサポートすることで、若手メンバーも安心してチャレンジでき、シニアメンバーはより難易度の高い課題に集中できる。こうした心理的安全性の高い環境づくりが、結果としてチーム全体の健全なアウトプット向上に繋がったのだと信じています。
未来に向けて：次は「PdMの生産性向上」
現状に満足せず「Elite」のその先へ向かい続けたいと考えています！
AIの進化により、エンジニア個人の生産性が飛躍的に向上した今、「PdM（プロダクトマネージャー）の生産性をいかに向上させるか」という、プロダクト開発全体に関わる大きなテーマが次の課題となっています。
ボトルネックは移り変わるもので、現状はエンジニアの生産性が1.5倍近く高まりPdM側の仕様が追いついていない状況になっています。直近はPdM側でもAIを用いて生産性を高める動きをしていますが、その次はきっとエンジニアの開発ラインがボトルネックになると考えています。
その時までに開発ラインを整える必要があるため、先んじて採用も進めています！！
Findy Team+で得られた客観的なデータと、この2年間で培ってきた試行錯誤の経験を武器に、私たちはこれからもプロダクト開発プロセス全体の最適化に向けて、分析と改善を続けていきたいので、このフェーズや実施していることにご興味がある方はぜひご連絡ください！！
参考書籍
良い戦略、悪い戦略 | リチャード・P・ルメルト, 村井 章子
HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント | アンドリュー・S・グローブ, 小林 薫
Discussion