PMと並走するフィーチャーリードをなぜ置いているのか

SmartHRで基本機能の開発をしているプロダクトエンジニアの@rihoです。入社して一年になります。

SmartHRでは、数スプリントにわたる特定機能の開発が始まる際に、開発チームのエンジニアの中から「フィーチャーリード」という役割を担う人を決めることがあります。今回、ある機能の開発で私が担当したため、開発においてどんな役割を担うのか、なぜ置いているのかなどを紹介したいと思います。

フィーチャーリードとは

PMと一緒にプロジェクトの少し先を見て動く人という位置付けで、フィーチャー開発※1をリードしていくエンジニアなので「フィーチャーリード」と社内で呼んでいます。

※1フィーチャーチームが進めていく開発を便宜上「フィーチャー開発」と表現しています。「フィーチャーチーム」については、過去のブログフィーチャーチームについてまとめてみた - SmartHR Tech Blogで触れていますので詳しくはそちらご参照ください。

以下はプロダクトの開発工程を表す簡易的なバリューストリームマッピング(VSM)ですが、点線の枠内が主にフィーチャーリードがPMと並走して動く領域です。なぜ・何をやるのか（What）の「要望整理」の段階まではPMがリードして行いますが、どうやってそれを実現するのか（How）の部分からはフィーチャーリード（エンジニア）が入り、PMと並走して進めます。

なぜフィーチャーリードを置いているのか

以下のような過去の背景があり、開発初期にフィーチャーリードを決めることが多いです。

実装段階での手戻りを防ぐため

以前は仕様検討やPBI（Product Backlog Item）の整理などがPM単独で行われており、PMの負担が大きいという問題があったようです。また、要件定義が終わってからエンジニアが入る場合、技術的観点で検討漏れがあり、実装着手後に仕様面での手戻りが発生するということがありました。
仕様検討段階からエンジニアが参加することで、技術的観点でのズレをなくしています。

フィーチャー開発を速く前に進めるため

PM単独でチケットの整理を行なっていたときは、チケットに技術的な制約があった場合、後で並び替えることが発生していました。
チケット作成と着手順の整理をエンジニアが行うことで、開発着手までのリードタイムを短縮しています。

エンジニア内での一次受け担当者を明確にするため

仕様検討段階で、PMやデザイナーから、エンジニア内で話してほしいことがある場合、誰に聞いていいのかわからない状態がありました。全員へのメンションだと対応する人が曖昧になり、コミュニケーションが遅延します。フィーチャーリードがいると一次受けの担当者が明確になるため、そういったコミュニケーションコストを下げる狙いがあります。

ユーザーの「欲しいもの」を、より小さく・速く届けるベストソリューションに落とし込むため

「必要な機能」ではなく「解決したい課題」をエンジニアの目線で読み解くことで、技術的な知識を加味して開発する機能をブラッシュアップしたり、削ぎ落としたりします。

フィーチャーリードがやること

フィーチャーリードがやることとして、主に以下のようなことがあります。（以下は社内での基本的な位置付けです）

PMやデザイナーと一緒に仕様検討段階から入る

主に実装観点で実現が困難なもの、考慮漏れがないかを考えます。
仕様検討段階からエンジニアが入ることで、そうした手戻りを防ぐ役割を担っています。

エンジニアで議論が必要なことを検知して、チームに議論を持ちかける

事前に実装の不確実性の高い箇所や、実装着手前に技術調査のチケットを入れた方が良い箇所がないか考えます。
エンジニア内で検討した方が良いことについてボールを持ち、チームに議論を持ちかけます。

リリースに向けて必要なPBIを作成・整理する

仕様やデザインが確定したら、リリースまでに必要なPBIを作成し、PBIの依存関係を整理します。どのチケットが後続のチケットのブロッキングになるのか、どのチケットは並列で進められるかなどの見通しをたて、実装の着手順を検討します。

フィーチャーリードがやらないこと

PMやデザイナーと常に一緒に活動すること

全てのMTGなどに同席する必要はなく、開発を優先します。

技術的な検討事項について一人で意思決定すること

経験豊富なシニアエンジニアでなければやってはいけないという役割ではないため、自分一人ではわからないことも多いです。個別のチーム・ケースにはよりますが、私のチームでは議論の場をもつことにオーナーシップを持つ、最初の選択肢を提案する、などまでを行い、意思決定はチームで行うことが多いです。

チームでの取り組み

具体的に私がある機能開発のフィーチャーリードを担当した時にやったことを紹介します。

PBIの洗い出しと優先度づけ

デザインと仕様が確定した段階で、ユーザーストーリーをもとに必要なチケットを洗い出します。チケットには優先度が高そうな順に「骨・肉・皮」のラベルをつけていきます。（社内でよく使われる優先度決めの基準。「高・中・低」などより具体度が上がってMVPなどの優先度の議論がしやすいのでおすすめ）チケットごとの優先度についてはチームで合意したい部分のため、たたきを作ってチーム全員でレビューを行いました。

PBIの依存関係を整理

必要なチケットがわかったら、PBIの着手順を整理するために依存関係を図に起こします。スプリントにチケットをアサインする際の参考にするため、後続のチケットのブロッキングになるポイントがどこかや、AとBのチケットは並列で進められる、などを図で可視化しておきます。

リファインメントの準備

必要なPBIをチケット化したら、リファインメントまでにPBIの内容について事前にある程度詳細化しておきます。チケットで網羅する内容についてはチームごとにフォーマットを持っていることが多いのですが、参考までに私のチームでは以下の内容を記載しています。

■概要

■やること

■やらないこと

■受入条件

■テスト項目

■ヘルプページ対応
影響： あり・なし

■スクール対応  ※SmartHRスクールの更新が必要かどうか
影響： あり・なし

■お知らせ対応　 ※リリースと同時にお知らせを掲載する必要があるかどうか
影響： あり・なし

また、バリデーション条件、要素が0個の場合の表示、ユーザー権限による制御の必要有無などの細かな観点リストをチームで持っており、事前にわかっている点についても記載しておくようにしていました※2。チケットの曖昧さを事前にできるだけ潰しておくとリファインメントがスムーズに進みますし、リリース後に考慮漏れによるバグが生まれることを防げます。チーム全体で合議が必要な事項については、「決まっていないこと」としてチケットに残していました。

※2長期にわたる開発の場合は、何スプリントも先の分までチケットを詳細化しすぎても（悪いことではないですが）無駄になることが多いため、バランスは大事だと思います。

意識していたこと

以下は社内での共通認識というより、私が個人的に意識していたことです。

実務的な話

プロジェクトの情報を集約する

プロジェクトに途中から参加した人、チーム外の人などが見ても状況や仕様が把握できる状態に情報を整理しておくことです。やり方はいろいろあると思いますが、目次のドキュメントを一つ用意してSlackのプロジェクトチャンネルのヘッダー（トピック）に貼っておき、そこを入り口にしてもらえばあらゆる資料が把握できる状態を維持するようにしていました。

ドキュメントをこまめにメンテナンスする

上記に関連して、入り口を整理するだけではなく、入った先の情報がメンテナンスされた状態を保つようにしていました。プロジェクト初期段階で作成されたドキュメントなどは、開発が後半に近づくにつれ仕様に調整が入り、ドキュメントと実態に差分ができることなどはよくあると思います。この状態を放置してしまうと、ドキュメントをもとにユーザーとコミュニケーションを行うチーム外の人が正しい情報をユーザーに伝えられなくなってしまうため、こまめにアップデートするようにしていました。

実装以外でリリースまでにやるべきことがないかに気を配る

開発以外にも、ヘルプページの追加・修正や翻訳対応の有無など、リリースによってアップデートしなければならない項目があります。それらもタスク洗い出しのチケットだけ用意しておき、対応が漏れないように気をつけていました。

モチベーション的な話

職種での線引きをしない

「これはエンジニアの仕事ではない」といったような、職種での区切りをつけないようにしていました。最終的に目指すところはチームで速く価値をデリバリーすることなので、「これはどの職種の仕事」みたいな境界線を引いたりせず、開発着手できる状態になるまでの事前の段取りやチーム外とのコミュニケーションなど、開発以外で発生するタスクのボールなどもできるだけ拾う役をしていました。

フィーチャーリードと並走したPM視点の話

一緒に並走したPMのgackeyさんからコメントをもらいました。

フィーチャーリードがスクラムチームにもたらしたこと

今回rihoさんが担ってくれた「フィーチャーリード」の役割は、チームの内外におけるコミュニケーションを圧倒的に促進するものでした。

チーム内で生まれたこと

もっとも印象的だったのは、フィーチャーリードとして能動的に活動するために、このフィーチャーにおいてどんな要求が・なぜ重要なのかをより深く・自分ごととして言語化してもらえたことです。 PMとエンジニア間の言語の壁が大きく取り払われる感覚がありました。その結果、ユーザーの課題定義から開発要件の詳細落とし込みまでのリードタイムが減り、価値提供を大きく早められたと感じています。また同時に、開発アイテムのうち「ミニマムで、バリュアブルと言える線引に欠かせないものはどこまでか、それはなぜか」という議論が行いやすくなり、小さく・速くリリースに向かうためのアクションが増えたことも素晴らしい点でした。

チーム外との間で生まれたこと

ミニマムな状態を満たすために必要なタスクは、チーム内で完結しきるものばかりではありません。他のプロダクトを開発している別のチームや、他の機能チームとの調整や依頼、相談が発生する場合も存在します。「このテストまで終わったら」や「この調査で技術要件が見えたら」のように、エンジニアのタスクの状況に応じてタイムリーにコミュニケーションを行っていくことや、技術観点を抜け漏れなく・端的に伝えていくことは、PMが介在するよりもエンジニアが主体的に進めてもらうほうが圧倒的にスムーズになると実感しました。

PMの役割や意義をより発揮しやすくなる

実は、フィーチャーリードが大きく活躍してくれることでもっともありがたかったのは、そのフィーチャーの開発がスムーズになったことではありません。PMにとってもっとも重要な、広く・先のことを考える余地が生まれやすくなったことでした。今後のプロダクトの成長にはどんな価値提供が必要なのか、未来のことを考える時間と、今目の前で向き合っているフィーチャーのことを考える時間とのバランスに悩むPMは多いと思います。目の前のフィーチャーの開発を止めないために「PMしかできない」ようになっていることが多いスクラムチームでは、場当たり的な開発になりやすく、長い目で見てより良いものをユーザーに届けていくことが難しくなってしまいます。さらにSmartHRは今後、マルチプロダクトで総合的に顧客に価値を届け、事業成長を目指そうとしています。そうした背景にとっても、PMが自身の担当する目の前の開発に集中するばかりでなく、広い視野を持って思考する余地が生まれることはとても嬉しいことでした。

フィーチャーリードと生み出すチームの成長へ向けて

rihoさんの「職種での区切りをつけない」という言葉に既にあらわれていますが、スクラムチーム全体でより有機的に・能動的に、顧客への価値提供に向かっていけることを目指したいと考えています。フィーチャーリードの役割の経験によってエンジニア自身が「どんなことが、なぜ顧客にとって価値と言えるのか」に向き合うことは、その価値提供のHOWを実装面で支える大きな強みになっていくと思います。一人ひとりのエンジニアの一分一秒の活動が、また一行のコードが、より顧客への広く・長い価値につながるものになっていくようなチームの成長に向けて、これからもフィーチャーリードとタッグを組んでやっていきたいです。