スクラムにキャプテン制度を取り入れ、開発効率とエンジニア育成を両立させた話

こんにちは。プロダクト開発部でエンジニアリングマネージャーをやっている野田です。

今年、JMDCではアドベントカレンダーに参加しています。

qiita.com

本記事は、JMDC Advent Calendar 2025 1日目の記事です。

はじめに

スクラムに属人的な要素を少量取り入れることで開発がやりやすくなり育成の面でも良い影響があったという話をします。

Pep Up（ペップアップ）ではスクラムによる開発を行っています。基本的なプロセスとして、プロダクトバックログの上から順に手が空いた開発者がプロダクトバックログアイテムをセルフアサインし、開発を進めるスタイルをとっています。

このプロセスはフロー効率に重点を置いた、非常にスクラムらしい動きではあるのですが、運用を続ける中で以下の問題が顕在化してきました。

プロダクトオーナーからエピック¹について開発者に聞きたい場合、誰に聞いたらいいかわからない。
コードの設計がプロダクトバックログアイテムを担当した開発者ごとに異なる。エピックにおいて設計の一貫性がない。
プロダクトバックログアイテムをこなすようになってしまい機能全体を俯瞰してリードする経験が積みにくい。

これらの課題を解決するため、エピックに対して明示的に一名の代表開発者を割り当てる試みを始めました。いわばリードエンジニアの動きを、エピック単位で担当するイメージです。名称については、本施策の検討にあたり大いに参考にさせていただいたスクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログから借用させていただき、エピックをリードするという意味も込めて、キャプテン制度と命名しました。なお私はエンジニアリングマネージャーではありますがスクラムへはスクラムマスターとして参加しており、スクラムマスターの帽子をかぶって決定した施策となります。

キャプテンの役割と責務

キャプテンはエピックをうまく終わらせるために開発者の立場からできることについて責務を持ちます。具体的には、開発者の立場から以下の動きを行います。

要件定義からリリースまで一貫してみる

要件定義段階でプロダクトオーナー、ステークホルダーと協働する。実現可能性が考慮されたプロダクトバックログアイテムを作成する。
- 要件定義段階から入ることで開発者視点の考慮がないままリファインメントが進むことを防ぐ。
- 要件についてプロダクトオーナー任せでなく開発者の意見も積極的に反映する。
設計の進行をリードする。
- 適宜専門家の力を借りる。あるいは部分的に任せても良い。全部自分でやる・できる必要はなく、任せるかどうか判断するのもキャプテン

開発者の窓口

プロダクトオーナー、ステークホルダーとの確認、仕様相談
- 開発者全員と都度確認となってスピード感が損なわれてしまうのを防ぐ。
- スクラムマスターはフォローで中身の話には原則関与しない。
開発自体は開発者全員で行う。

品質保証

完成の定義や受け入れ基準を保証するための段取りを考える。
- どの環境で検証すると最も効果的か考え決定する。
- ステージング環境でデータや外部サービスなどの準備をリードする。
プロダクトで確認しづらい内容について品質保証する内容をプロダクトオーナーと合意する。
- 例えば外部サービスがステージング環境で使えない場合、モックでの検証を持ってよしとすることをプロダクトオーナーと合意する。

リリース

リリースの段取りを考える。
- リリース時のリスクを洗い出す。
  - 適宜専門家の力を借りる。
- データマイグレーションが必要な場合、デプロイ前に実行するかデプロイ後に実行するか。
- メンテナンス時にリリースするか定時内にリリースするか。

注意点

当然ながらスクラムガイドには記載のない独自定義のロールです。スクラムではプロダクトオーナー、スクラムマスター、開発者以外のロールは存在しないため、その他のロールを加えるということはスクラムとは言えないかもしれません。正しいスクラムをやることより私たちの置かれてる状況でプロダクト開発がうまくいくことを優先したため独自定義のロール導入を決定しました。

導入結果と考察

当初の目論見通り、プロダクトオーナーからエピックについて開発者に聞きたい場合はまずキャプテンに聞くと明確になったため、プロダクトオーナーのコミュニケーションコストが減りました。また、テーブル設計といったユーザーストーリーに着手する前に行うべきタスクについてキャプテンがリードすると明確になったため、開発者間でのお見合いがなくなり一貫性を持った設計が可能になりました。開発者が横並びの中、自己組織化だけでプロダクト開発が機能するには相当条件が揃っていないと難しく、ある程度役割を決めたほうが結局機能しやすいということかと個人的には考えています。

エンジニアリングマネージャーの立場からすると育成の観点で特に効果がありました。ある程度の難易度・規模の開発を一人称でやりきりました、と胸を張っていえる経験がエンジニアの成長にあたって必要と考えています。そのためには、当たり前ですがある程度の難易度・規模の開発を任せて全体感を持ってリードしてもらう必要があります。難易度・規模を徐々に上げながらこれを繰り返すことで成長し問題解決できる範囲が広がっていきます。プロダクトバックログの上から順にプロダクトバックログアイテムをこなすプロセスだと全体感を持ってリードする経験を積むことができません。キャプテンとしてエピック単位でおまかせした結果、リファインメントを行う前に見ておきたい部分をチェックしたり、必要な作業アイテムを作成するといった主体性を発揮した行動が見られています。