はじめに
HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。
私たちのチームには、プロダクト開発を進める上で次のような課題がありました。
- プロダクトオーナー（以下、PO）の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた
- 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた
これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー（以下、EM）の業務負担を削減するものです。 本記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。
この記事では、プロダクト開発において以下に当てはまる方々を想定読者としています。
- 開発メンバーやPOで、POの業務過重やドキュメントの問題に直面している方々
- 開発リードやEM、POとして働いている、またはそのキャリアパスを考えている方々
エピック主管とは
エピック主管の担当範囲
以下は、開発プロセスにおけるPO、プロダクトデザイナー（以下、PD）、エピック主管、開発メンバーのメインの担当を表した簡易的な図です。黄色の箇所がエピック主管の担当範囲です。
文書の番人であり、プロジェクトマネージャー
エピック主管とは、要求が登場してからリリースされるまでのエピック開発プロセスの一連を主導する役割を担っています。 別の部署や企業では開発リードと表現されたり、EMが担っていたりする場合もあるかと思います。
エピック主管は、エピックのリリースを達成するための技術仕様や要求仕様を最新に保ち文書化するという「番人」的な役割から始まりました。そして今では、プロジェクトマネジメントの役割も持つようになりました。
エピック主管導入前の課題
エピック開発を進める上で、具体的には以下のような課題がありました。
ドキュメントの管理の負担が大きかった
- POが技術仕様書を管理していくのは負担が大きかった
- ステークホルダー全員が同期的に技術仕様書を更新するのは合意コストが高かった
相談相手の候補が多すぎてコミュニケーションコストが大きかった
- POやステークホルダーがエピックの要求をトレースまたは相談する場合に誰に相談すればいいかわからず、EMか開発者全員に聞いていた
- EMだけに相談するとEMの負荷が高くなり、また、全員に相談するのはコストが大きすぎる
- 要件・仕様が頻繁に更新されていく中でどれが一番新しい情報かわかりずらく、コミュニケーションミスが起きる場合があった
何をするか
主な活動は、ドキュメント管理とプロジェクトマネジメントです。エピックの開発プロセス全体を俯瞰し、開発がスムーズに作業を進められるように舵をとっていきます。
具体的にはエピック開発において以下のようなことをしています。
- ドキュメント管理
- 要求定義書、要件定義書、技術仕様書、QA項目などのドキュメントを管理
- 解決したこと
- ドキュメントをメインで管理する人を設けて管理の負担を分散させることにより、前述のドキュメントの管理の負担の課題を解決
- PO、PDとともに要求・大まかな要件を詰めていく
- 要求・要件について開発観点でのフィードバックをする
- 開発者視点で議論の頭出しをする
- 解決したこと
- 要求・要件をPO、PDと詰めていく開発者となることにより、前述のコミュニケーションコストの課題を解決
- 開発プロセスがスムーズに進むように段取り
- 開発における実現可能性の不安を洗い出して早めに解消・議論の頭出しをする
- 他部署とのコミュニケーションを前倒して早めに行う
- 開発メンバー各々の得意領域や希望を考慮しながら各タスクの移譲
- 実現可否の検証
- 設計
- 他部署とのコミュニケーション
- 実装
- プロダクトバックログアイテム（PBI）やその依存関係の整理
何をしないか
基本的には上述の役割があるからする/しないではなく、開発を進めていく上でエピック主管がする、または協力する方がベターであれば、する判断をしています。以下はメインの責務ではありませんが、必要に応じて行っていることです。
- エピックの企画・要求の整理
- 主にPOの責務のもと進行。エピック主管はなぜやるかやVOCを確認しながらPOとともに要求定義をブラッシュアップしていく
- 要件・仕様を最終的に決めること
- 主にPOの責務のもと進行。エピック主管は開発として最速で最大の価値を提供できる方法をPOとともに考えたり、実現可能性の検証をしてから仕様策定をするように提案していく
- スプリントのタスク配置
- 主にPOの責務のもと進行。エピック主観はタスクの依存関係や優先度を考慮してタスク配置の助言をする
- 開発プロセスにおいての責任範囲全てをやること
- 必要に応じて他開発メンバーに移譲する
- 開発メンバーそれぞれに得意・興味領域があるので、そういったメンバーに移譲する
- 必要に応じて他開発メンバーに移譲する
うまくいったこと・副次的な効果
エピック主管の仕組みを取り入れたことによりうまくいったことや、気づきを紹介します。
- POのドキュメント管理の負担が下がった
- PO、PD、開発メンバーが誰と話せばいいかが明確になり、コミュニケーションコストが下がった
- コミュニケーションミスが減った
- エピック主管を担う開発メンバーの成長
- ソフトスキルアップ
- PO、PD、SREなど他部署との調整業務
- 仕様化・スケジューリングに関われる
- 個人の得意分野・興味を考慮しながらタスクの移譲をする
- ハードスキルアップ
- 開発時の懸念を洗い出す・払拭するためにコード読み書きする
- 技術選定をする
- コアな実装を担当する
- エンジニアのキャリアパスとして開発リード、EMがあるがそのロールを体験でき、キャリアの可能性が広がる
- ソフトスキルアップ
注意点・Tips
- エピック主管以外の開発メンバーはそのエピックに関心が薄れ、状況把握やレビューが難しくなる場合があること
- 対策としてリファインメントやスプリントプランニングで状況共有したり、ドキュメントの執筆やレビュー、実装をしてもらったりしてキャッチアップを促しています。
- なぜやるかを意識すること
- 開発者視点としてはどうすれば早く、負債を貯めすぎずに開発できるかを考えることが多いです。そのため、なぜやるか・本当に実現するべきことは何なのか・インパクトは大きいのかを強く意識して要求・要件・仕様の策定に取り組んでいます。
- 要求を全て飲んで開発するのではなく、部分的に優先度を落としてコアな価値提供にのみ集中して開発したり、時には運用回避をしてもらう前提で開発しています。それが結果的に早く価値提供を続けていくことにつながります。
- エピック主管はやりたい人がやること
- ドキュメント管理や他チームとの調整など開発以外のことが多く、オーナーシップがなければ疎かになりやすい仕事が多いからです。
- エピック主管が個人の目標・キャリアとマッチしているかも考慮して任命しています。
- 開発メンバーの誰もがエピック主管として活躍できるように環境を整えること
- サブのエピック主管を立ててサポートしたり、EMや他開発メンバーがフォローできるようにしています。
- チームで定めた開発プロセスを実践したり、改善したりしています。
- 進捗共有・相談すること
- オーナーシップを持っているからこそ、ある程度のことは独断で自分で行いたくなるものです。ただし、手戻りなど非効率な作業をしてしまうのは避けたいので、他メンバーも気に掛けられるように適宜進捗共有する場を設けたり、困りそうな予感がしたらすぐに相談することを意識しています。
- エピック主管はタスク量が多かったり技術的に難しいことを検討する場合があるので、リソース分散・得意領域カバーの観点で適宜タスクの移譲をしています。
- 開発メンバー各々の個人目標とすりあわせて全員が目標を達成できるようにしていくこと
- 個人目標はエピック主管に関わらずどのようなキャリアを目指すかやチームや部にどのように貢献していくかを踏まえて決めていきます。例えば個人目標として、エピック主管でなくてもエピックにおいて設計やコアな実装を担当していく、安定したリリースをするために活動していくなどがあります。したがって、なるべく各々の個人目標を達成できるようにエピック開発においてタスク割当をしていくように意識しています。
まとめ
エピック主管の導入により、ドキュメントの管理の負担を分散したりコミュニケーションコストを減らしたりなど多くの課題を解決しました。また、開発メンバーがプロジェクトマネジメントも担うことでPO、EMの責務過多を減らすことや個人のスキルアップにもつながりました。今後もエピック主管の仕組みはチームの状況に応じて変化・改善を続けていくつもりです。
参考文献
執筆にあたり参考にさせていただきました。SmartHRさんでも似たような取り組みが行われているようです。とても良い活動だと思うので、ぜひ拡げていきたいですね！
