こんにちは。技術統括本部 タレントマネジメントプロダクト開発本部 タレントマネジメント開発 1 部 のプロダクトエンジニアの@Tacto（岸川 拓斗）です。
私たちのユニットでは、2024 年 12 月ごろに開始した大型開発プロジェクト（現在はベータ版であり、一般には未公開です）を約 1 年にわたり推進してきました。本記事では、開発プロジェクトにおける SmartHR 独自の役割である「フィーチャーリード」の運用を、あえて“分割”してみた取り組みと、そこで得られた学びを紹介します。
フィーチャーリードとは
フィーチャーリードは、SmartHR で数スプリント〜数カ月にわたる特定機能の開発を進める際に、スクラムチーム内のエンジニアの中から任命される役割です。 このブログでも過去にフィーチャーリードについて書かれた記事があります。
tech.smarthr.jp tech.smarthr.jp
特に大規模機能の開発では、プロダクトマネージャー（以下、PM）の負荷や仕様の手戻りリスクが跳ね上がります。また、複数のエンジニア間での技術判断も拡散しがちです。そのため SmartHR では、仕様の検討・プロジェクトマネジメントを技術面からサポート・推進する代表エンジニアを明確に置く目的でフィーチャーリードを設置しています。
この役割は大きく下記の 5 つです。
価値やスコープの定義（What/Why）
PM と並走し、機能の目的・成功指標・スコープ境界を明確化します。機能が提供するユーザー価値を定義する際はインパクトマッピングなどを作成します。プロジェクト初期段階から実現可能性・考慮漏れを潰し、実装フェーズの手戻りを減らします。
ソリューションの設計（How）
機能/非機能要件、データ/状態遷移、API/UI の整合を先行設計します。必要に応じて仮実装を行い、実装の不確実性を事前に下げます。
デリバリープランニング（When/順序）
定まったソリューションをプロダクトバックログアイテム（以下、PBI）単位に分解するとともに依存関係を可視化し、着手順を設計します。段階的なリリース戦略を策定し、バーンダウンチャートなどを作成します。
実行ファシリテーション（進め方）
あらかじめ PBI を作成し、スクラムチームがプロダクトバックログリファインメントをしやすくなるようにします。論点整理を通じてミーティングを設計し、エンジニア間の合意形成を促進します。
関係者対応（窓口）
PM/デザイナー/QA/他プロダクト/CS などの相談窓口になります。多職種からの問い合わせにエンジニアの代表として回答し、情報を一つにまとめます。
このロールは、単に「実装を取りまとめる人」ではなく、プロダクトの価値を早く安全に届けるための技術面の先行探索と意思決定のファシリテーションを担う存在です。
なぜ“分割”したのか
本プロジェクトは規模が大きく期間も約 1 年と長期に渡るため、従来の「フィーチャーリード」が 1 人で担うには負荷が高いという課題がありました。実務を改めて棚卸しすると、フィーチャーリードには次の 3 層の仕事が内包されていると分かります。
- プロジェクト全体（長期）の見取り図を持つこと
- 他職種・他部門との窓口となること（関係者との調整・合意形成）
- 数週間〜1 か月以上先の重い論点を先回りして潰すこと（要件整理、仕様書作成、技術調査、チケット作成 等）
この役割の広さが、コンテキストスイッチの多発やボトルネック化につながりやすく、結果として開発スループットに影響する懸念がありました。 そのため、フィーチャーリードの役割を分割する取り組みを始めました。
役割の再定義と分割
混乱を避けるため、同じ名称は使わず、次の 2 ロールに明確に分割しました。
- リリースマネージャー（Release Manager）
- フィーチャー開発全体のリリーススケジュール管理を担う
- バーンダウンチャートを整備し、リリースまでにかかるスプリント数（期間）を試算する
- 試算した必要スプリント数から「リリース予定日」を決定する
- リリース予定日を遅延しそうな場合はスクラムチームにアラートを伝える
- ディスカバリーリード（Discovery Lead）
- プロダクト要求仕様書（PRD）作成段階から PM と並走し、What（何を作るか）を設計・先導する
- インパクトマップ作成、論点の洗い出し
- How（実装方法）を設計する
- 技術調査、機能/非機能要件やデータ構造の先行設計を行う
- PBI への分解や各 PBI の依存順の整理を行う
筆者はこのプロジェクトでディスカバリーリードを担当しました。また同じスクラムチームの別のエンジニアがリリースマネージャーを担当しています。要件整理段階から技術の観点で"先に考える"ことに重心を置き、実装フェーズでの手戻りを最小化することを目指しました。
ディスカバリーリードとして実際にやったこと
ディスカバリーリードとして、要件整理から技術設計まで幅広い業務を担当しました。具体的には以下のような活動を行いました。
- PRD/要件の作成
- PM と共同で PRD の雛形を整備し、機能要件や前提・除外事項を明文化した
- インパクトマッピングの作成
- ビジネス目標 → ユーザー行動 → 成果 → 施策を可視化し、MVP（ミニマム・バイアブル・プロダクト）のスコープを明確化した
- タスクの管理
- 論点・イシューを「誰が、いつまでに、どの根拠で」決めるかを管理した
- 情報設計/技術設計のすり合わせ
- UI フローや DB・API 仕様書を作成し、ミスコミュニケーションのリスクを最小化した
- 技術調査
- 後工程の詰まりになり得る箇所（性能・API 制約・データ整合性など）を先に検証した
リリースマネージャーが実際にやったこと
リリースマネージャーは、プロジェクトのスケジュール管理とリリース計画の策定を担当しました。以下のような業務を実施しました。
- リリースバーンダウンチャートの作成と更新
- スコープ変更を前提に“生きた計画”として適宜見直し、クリティカルパスとリリース予定日を明確にした
- PBI 分解と順序付け
- 依存関係を踏まえて段階的なリリース計画に落とし込んだ。各 PBI の目的や受け入れ条件を明記した。
- リリース予定日の設定とアラート運用
- リリース予定日を明確に定め、遅延の兆候が見えた場合はスクラムチーム全体に速やかにアラートを出した。アラート後はスコープ変更や優先順位の入れ替え、追加アサインなど、遅延を回避するためのアクションを取れるようにした。
分割して良かったこと
フィーチャーリードを分割することで、以下のような効果を得ることができました。
ロールに集中でき、負荷分散が機能
ディスカバリーリードは探索と設計に、リリースマネージャーはスケジュールとリスクにフルフォーカスできるようになりました。特にガントチャート整備のような負荷が高くセンシティブな作業にリソースを集中できました。
実装が現実的に困難な企画への着手リスクを最小化
企画段階からエンジニアが深く参画し、非現実的な仕様・設計の芽を早期に摘めました。約 1 年におよぶプロジェクト期間でも、技術的困難を理由に手戻り/断念したケースはゼロでした。
“次にやるべきこと”の連続性が担保され、待ち時間のロスが減少
次フィーチャーにスムーズに着手できるよう、事前のディスカバリー作業ですぐに開発に取りかかれる状態のチケットを増やし、優先度の低いタスクへ流れてしまう無駄を減らせました。
工夫したこと
フィーチャーリードの分割とは無関係に、フィーチャーリードの役割を担う上で以下のような工夫も行いました。
PM 視点の習得とチーム運営の改善
ディスカバリーリード/リリースマネージャーともに、エンジニアリングだけではなくプロジェクトマネジメントの視座が必要です。チーム全体の進捗把握、待ちの発生予防、関係者調整など、一エンジニアにはハードルが高い側面もあります。
対処として下記の行動をとりました。
- 週次レトロスペクティブの徹底
- 毎週「うまくいったこと/気になっていること/次スプリントで試すこと」をざっくばらんに話し合った
- PDCA サイクルの運用
- レトロスペクティブで決めた改善策を翌週のスプリント計画に反映し、実行（Do）→ 振り返り（Check）→ 定着（Act）まで回した。プロジェクトマネジメントに不慣れなメンバーでも改善点を自分で見つけて修正でき、チームとしてスムーズに立ち上がることができた。
PM との役割分担と協力関係の構築
ディスカバリーリード/リリースマネージャーは PM 業の一部を支援する場面が増えます。行き過ぎるとPM の本来業務（市場機会の探索、ロードマップ設計など）を圧迫しかねません。
対処として下記の行動をとりました。
- 相互リスペクトを前提とした役割分担
- 技術判断はエンジニア、プロジェクト運営の主導は PM というふうに、各職種の得意分野に応じて役割を分担した
- 技術起点の PM 支援に限定
- エンジニア間の合意形成など、より技術的観点が求められる補助的なプロジェクトマネジメントは支援するが、最終責任は PM に帰するようにした
なお、SmartHR のプロダクトエンジニア（PdE）には、会社の行動指標や等級要件を通じて「プロダクト開発推進能力」が一定程度求められています。等級レベルによって求められる水準は異なりますが、エンジニア側の推進力を計画的に育成する狙いがあります。
- 越境して協力関係を構築
- 所属チームや組織・職種の枠を超えて、立場の異なる関係者と必要な協力関係を構築する
- プロセスを部分的に主導
- 自分が関わる範囲のプロセスを設計・運用し、必要に応じて改善をリードする
- 関係者間の合意を形成
- 技術・ビジネスの論点を整理し、意思決定の場を設計して合意形成を支援する
本記事で紹介したリリースマネージャー／ディスカバリーリードの分割運用は、こうした推進力をチームで育てるための実践でもあります。ローテーションやメンタリング、テンプレート化（PRD 雛形、論点リスト、アラート運用など）を通じて、等級に応じた段階的な成長を支援しています。
最後に
大規模・長期の機能開発では、1 人のフィーチャーリードに期待される役割が広がりがちです。私たちはロールをリリースマネージャーとディスカバリーリードに分けることで、負荷分散と意思決定の質の両立を目指しました。その結果、実装困難リスクの早期顕在化と回避、待ち時間の削減、役割集中による生産性向上といった手応えを得ています。
一方で、PM 視点の必要性や棲み分けの難しさなど、フィーチャーリードの役割そのものに伴う課題も明確になりました。今後もテンプレート化や PDCA を通じて、"先に考える"開発体制を磨いていきます。
読んでいただき、ありがとうございました。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
