こんにちは。プロダクトエンジニアの廣瀬です。入社して1年が経ちました。
SmartHRでは、一定期間にわたる機能開発に取り組む際に、開発チームのエンジニアの一人が「フィーチャーリード」という役割を担うことがあります。このブログでも過去にフィーチャーリードについて書かれた記事があります。
今回、ある機能開発において、僕もフィーチャーリードをやることになったので、とくに開発の立ち上がり時にどういうことをやったかを紹介したいと思います。
フィーチャーリードの役割
機能開発には、プロダクトマーケティングマネージャー、プロダクトマネージャー、プロダクトデザイナー、プロダクトエンジニア、ドメインエキスパート、UXライター（ユーザー体験に関する文章を専門とするライター）…と、様々な職種が関わります。その中でフィーチャーリードは「開発に関わるプロダクトエンジニアの代表」だと理解しています。
なので、フィーチャーリードには以下の役割があると考えています。
- 仕様やUIデザインを、技術的に実現可能で最適な形に落とし込む
- 開発チームのエンジニアが、スムーズに実装を進められるようにする
実際にやったこと
上記の役割を意識しながら、実際には次のようなことをやっていました。
要件のインプット
僕がアサインされた時点で機能の大まかな要件は決まっていたので、まずはそれをインプットしました。あわせて、今回の機能は国の制度に関わるものであったため、その制度に関する資料も読み込みました。制度が理解できていなければ、要件を本当に理解することは難しいからです。
公式の説明資料だけでなく、SmartHRは人事労務システム協議会の会員でもあるため、そこで手に入った資料も読むことができました。制度をシステムに反映する上での現場の知見や、個別具体的な行政側の見解にも触れられるので、とても参考になります。
また、国の制度である以上、根拠となる法令が存在するので、関係していそうな条文にも目を通しました。僕は専門家ではないので正確な解釈ができるわけではないですが、制度の背景や制約を理解する一助になったと思います。
論点の洗い出し・整理
要件や制度上の制約から、画面やデータの流れなどを中心に機能の大まかな構成を考えます。そうすると開発を進めるために「決めないといけないこと（= 論点）」が山のように出てくるので、それらを「機能の大まかな構成」にマッピングしました。
こうやって洗い出した「論点」を、誰に相談すればよいか、どこと調整すればよいかを考えながら、一つ一つ潰していきました。技術的な調査が必要なものもここで見えてくるので、リストアップして実装に着手する前に解消していきました。
それぞれの論点が機能のどこに関わる話なのか一目瞭然なので、優先順位や依存関係を把握しながら進められて良かったと思っています。
顧客ヒアリングへの参加
技術的な準備と並行して、作ろうとしている機能についてユーザーにヒアリングする機会があったので、その場にも積極的に参加しました。実際に行われている業務に対する解像度を上げることで、資料等だけでは分からない「ユーザーが機能に求めていること」への理解を深めることができたと思います。
そして、人事労務というドメインの特性上、社内の担当部署の方の話も聞くことができます。ある現行業務を実際にやっているところを直接見せてもらいたくなったときは、お声がけして「見せてもらう会」をセッティングしたりもしました。（快くスピーディーに協力してくださり助かりました）
UIデザインと技術的仕様のすり合わせ
デザイナーがUIデザインを作成していくにあたって、技術的な観点でのレビューやすり合わせも行なっていきました。とくに初期は、決めなければならないことばかりなので、定例ミーティングを設定して毎日のようにコミュニケーションを取りながら進めていきました。
その中で最も注意を払ったのは、UIと技術的な構造とが乖離しないようにすることでした。両者が一致していると、開発もスムーズになり、後々の負債も少なくなると考えています。
そのために、デザイナーと会話しながらDBやステータス遷移などの設計を進めたり、逆に、デザイナーが行う情報設計などにも関わらせてもらいました。
また、デザイン的に判断が難しく、技術的にも設計が大きく変わってしまうような場面においては、共同してユーザビリティテストを実施することで、合理性の高い意思決定ができたと思います。
開発チケットの洗い出し・見積り
仕様とUIデザインが見えてきたところで、開発タスクを洗い出します。開発タスクには依存関係があるので、それが視覚的に分かるように、以下のようにまとめました。クリティカルパスも把握しやすく、柔軟に調整できるので便利です。
そして、チームのエンジニア全員で開発タスクのレビューと見積りを行いました。それを基に、開発の完了時期を予測するスプレッドシートも作りました。
開発着手
洗い出した開発タスクに従って、チームで実装を進めていきます。スムーズな開発のためにここまでの準備も大事ですが、開発に着手してからも、仕様の詳細化や変更の調整など、フィーチャーリードが中心となって進めていくことは色々あります。
俺たちの戦いはこれからだ！
心がけていること
フィーチャーリードとしての役割を担う上で、僕が心がけていることがあります。
待ちの姿勢にならないよう、技術以外の領域にも積極的に関わっていく
とくに仕様を検討している段階においては、関わっているエンジニアがフィーチャーリードだけになりがちなので、エンジニアとして技術的にできる・できないを判断するだけではなく、機能（プロダクト）をより良くするために「何ができるか」を能動的に提案していく責任があると考えています。
ビジネスやデザインなど、それぞれの領域にそれぞれのロジックや制約があります。それらを踏まえてエンジニアとして価値のあるアイデアを出すためには、やはり直接コミュニケーションを取っていくことが大事だと実感する場面が多いので、できるだけそこを厭わないように心がけています。
メンバー間で、できるだけ情報のラグが生まれないようにする
機能開発にあたって、様々なミーティングややりとりを通して意思決定が行われていくわけですが、すべての場に全員が参加できるわけではありません。それでも、その情報の差を少しでも減らすことができれば、それぞれが自律的に判断できることも増えるはずです。
そのために、例えば以下のようなことを行いました。
- フィーチャーリードとプロダクトマネージャーだけで会話することが多くなりがちなので、その内容を開発チームの朝会でも共有するようにしました。
- 技術的な検討をする上で、関係するメンバーでちゃんと認識を揃える必要があるものは、詳細なドキュメントを書いた上で議論できるようにしました。
- UIデザインなどは、まだ固まっていない段階のものであっても、できるだけ早め早めに関係するメンバーに共有する機会を作るようにしました。
最後に
実際のところ、SmartHRにおいて「フィーチャーリード」に明確な定義や定型化された手順があるわけではありません。なのでここまでの内容はその一例として捉えていただければ幸いです。
それでも、機能・プロダクトの開発を進捗させるために、やれることは何でもやるという姿勢は共通しているのかなと思っています。
We Are Hiring!
SmartHR では一緒に働く仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
