図説：SmartHRのプロダクト開発サイクル 2021 ver.

こんにちは。SmartHRでPM（プロダクトマネージャー）をしているadachiです。
最近、面接などで「SmartHRではどのような流れでプロダクトを作っているのか」という質問をよくいただくので、このあたりでいちど現状を整理しておこうと思い立ちました。

SmartHRでは、全社的にスクラム開発を採用しています。このブログにもスクラムに関する記事がたくさんあるのでぜひ読んでいただきたいのですが、今回はもう少し引いた視点から、顧客から受けた要望がどのように開発されていくのかという全体の流れを取り上げてみたいと思います。

なお、開発プロセスは状況に合わせて日々更新されていますので、今回ご紹介するのは2021年6月時点での内容になります。

プロダクトの構成

SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「本体」で、もうひとつは本体にアドオンする形で使える「プラスアプリ」です。

それぞれどんなプロダクトなのか、ここでひとつひとつ説明したい気持ちもあるのですが、今回の趣旨からは外れるのでいさぎよく割愛します。
とりあえず、大きい「本体」と小さい「プラスアプリ」があるのだなぁ、と覚えていただければOKです。

開発チームも基本的にプロダクトごとに分かれており、SmartHR本体は約50名、プラスアプリはそれぞれ3〜8名ほどのチームが担当しています。

SmartHR本体の開発サイクル

さてここからが本題ですが、SmartHR本体の開発サイクルは、おおまかには下図のようになっています。

以下、図中に登場する概念について説明していきたいと思います。

Productboard

SmartHRでは顧客からの要望を管理するデータベースとして、Productboardというツールを利用しています。
セールス、CS、サポートなどが受けた要望は、このツールで一元的に管理されます。同じ要望を何回でも投稿できるので、どの機能にどのくらい要望が来ているのか、定量的に把握することもできます。

要望を解説する会

SmartHRは人事労務のプロダクトなので、当然ながら人事労務の業務を理解していなければ、正しいプロダクトを作ることはできません。
しかしPMをはじめ開発メンバーは人事労務の専門家ではないため、顧客から要望をもらっても、なぜそのようなニーズが生まれるのか、それは一般的なことなのか、あるいは特殊な事例なのか、といった判断が難しい場合があります。

毎週開催される「要望を解説する会」では、ドメインエキスパート（人事労務に詳しいスペシャリスト）がProductboardに起票された要望をひとつひとつ確認しながら、その背景などを解説してくれます。
この会に参加することを通して、PMやPMMは人事労務ドメインへの理解を深めながら「最近これ系の要望が増えてきたな」とか「あれとこれは同時に解決できるかもな」といった肌感覚を養うことができます。

また、PMも全員がプロダクトの仕様すべてを把握しているわけではなく、機能によって理解に濃淡があります。
会のなかでは現状の仕様がどうなっているのか、どんな経緯でそれが作られたのかといった情報も共有されるので、関係者内でコンテキストを継承し、属人化を防ぐ効果もあります。

さらに、この会には要望を起票する側のセールス、CS、サポートの代表者も参加しているので、要望に補足をしてもらったり、逆にPMから「なぜ今はこの機能の優先度を上げられないのか」を説明するなど、部署をまたいだ情報交換の場としても機能しています。

なお、すぐに対応できそうな要望については、その場でバックログとして起票する判断をすることもあります。そのせいか、社内でも「要望のやる・やらを決める会」だと誤解されることもあるのですが、基本的にはインプットの場であり「勉強会」に近いイメージです。

ロードマップモム会

月に一度、各部門の代表者とPM、PMMなどが集まって開催されるのが「ロードマップモム会」です。
その名の通り、SmartHR本体のロードマップを揉む会議なのですが、なぜかSmartHRでは「揉む」をカタカナで表記する風習があります。

SmartHRは多種多様な業種・規模のお客さまに導入されているため、いただく要望も多種多様です。
すべての要望に応えることはできないので、何をどの順番で作るか、社内外の関係者が納得できる形で決めていく必要があります。

ロードマップモム会では、現行のロードマップに開発状況を反映したり、「この機能はもっと優先度を上げたい」「最近こういう要望が多いのでロードマップに入れたい」「この機能は一度作ることが決まったが、調査したところ別の解決策がありそうだ」といった議題が起案され、協議されます。
また、新たにプラスアプリを作る場合も、この会で協議して決定しています。

起案者の所属はセールスやCSであったり、PMやPMMであったり、特に制限はありません。
参加自由のオープンな会議なので、特にオンライン化してからは閲覧のみの参加者も増えてきています。（直近の会では120名以上が参加していました）

プロダクトや組織が大きくなるにつれて、ロードマップに関するコミュニケーションの難易度は上がってきています。
この会の進め方も含めて、ロードマップの作り方や合意のとり方については、まさにSmartHR本体のPMたちが試行錯誤しているところです。

なお前提として、SmartHRのビジネス部門のメンバーは、驚くほどプロダクト開発に協力的です。
個人的な感覚ですが、目の前の数字のためではなく、顧客にとっての価値を考えて要望を出してくれているのがよくわかりますし、リリース日を事前に約束できないことについても理解を示してくれます。

PMとしては大変めぐまれた環境ではありますが、今後もそのカルチャーを維持するために、透明性の高い意思決定を続け、関係者を巻き込んでいく工夫が必要だと考えています。

PRD

PRD（Product Requirements Document）は、開発するプロダクトや機能の目的、背景、要件などをまとめたドキュメントです。
SmartHRでは独自のPRDフォーマットが用意されており、担当のPMがそれを適宜カスタマイズしながらPRDを書いていきます。

先ほども触れましたが、SmartHRは業務用プロダクトという特性上、開発メンバーが対象となる業務に精通していません。そのため、PRDでは前提となるドメイン知識や業務フローに関する情報を、しっかり整理してわかりやすく記載することが求められます。
一方で、具体的な仕様についてはスクラム開発の中で協働的に作り上げていくことが重視されるので、PRDに細かく記載されることはありません。

PRDはある程度書き上がった時点で他のPMや開発チームなどにレビューしてもらい、精度を上げていきます。

ユーザーインタビュー

SmartHRでは様々なタイミング、様々な内容でユーザーインタビューが行われていますが、大きく分けるとPM・PMMによる予備調査的なものと、スクラム開発のなかで行われるものがあります。

これまでは既存の顧客にインタビューをお願いすることが多かったのですが、最近は商談中の顧客にインタビューすることも増えてきました。
その他にも、より広く深く顧客の声を集めるための試みがいろいろと動いていますので、またいずれ別の記事でご紹介できればと思います。

ちなみに、どの顧客からどんな要望をもらっているかは前述のProductboardで管理されているので、インタビュー候補を探すときにもとても便利です。

バザール

バザールは最近になって開催されるようになった不定期のイベントです。
詳しくはバザー形式のスプリントレビューを開催した話を読んでいただきたいのですが、簡単に言うと、開発中の機能を社内の様々な部署のメンバーに触ってもらい、フィードバックをもらう会です。

SmartHRは人事労務担当者向けの機能が多いので、人事労務担当者でない社員のフィードバックが、必ずしもターゲットとする顧客の意見とは一致しないこともあります。
それでも、バザールでは貴重な意見や気付きが得られることもありますし、なにより「全社でプロダクトを作っている」という実感を得られる機会でもあり、社内の注目度、満足度ともに高いイベントです。

また、バザールに本物のユーザーを招待する試みも始まっており、今後も継続していく予定です。

ユーザーへの報告

ユーザーから要望をもらっていた機能をリリースした際は、「ご要望の機能ができましたよ」報告を行っています。
SmartHRカスタマーサポートが実践する "ファンをつくる" クローズドループとはで詳しく解説されていますので、ぜひご一読ください。

以上、SmartHR本体の開発サイクルについて、ダイジェスト的にご紹介しました。
もっと書きたいことはたくさんあるのですが（心のバックログとか）、すでにだいぶ長くなってきたので、本体についてはこのあたりにしておきます。

プラスアプリの開発サイクル

次はプラスアプリについて、簡単に触れておきたいと思います。

プラスアプリはプロダクトごとに独立性が高く、開発プロセスも基本的に各チームに委ねられています。したがってプラスアプリに共通の開発サイクルというものはないのですが、ざっくりまとめてしまうと下図のようなプロセスで運用されていることが多いです。

プラスアプリでは、SmartHR本体のように定期的に関係者を集めてロードマップを協議する形はとっていません。かなりの部分が開発チームに委ねられており、機動的に開発を進められるようになっています。

ただ、最近ではプラスアプリが増えてくるにつれて、アプリ間での連携が求められる機会が増えてきました。今後はより横断的な動きがとりやすいように、開発プロセスも変わっていくかもしれません。

現状の課題

以上、SmartHR本体とプラスアプリの開発サイクルをご紹介してきましたが、やはり現状で課題が多いのは本体のほうです。

プロダクトと組織が大きくなると、意思決定の難易度が上がり、そして意思決定に納得してもらうことの難易度も上がります。このふたつは独立した問題ではなく、切り離して考えることはできません。

メンバーには、各領域の専門家としてオープンに議論に加わりながら、すべての意思決定には関われないことを納得し、人に任せるべきところは任せるというバランス感覚が求められます。
そのためには、本稿でみてきたようなプロセスや仕組みなどのハード面の整備に加えて、チーム内の信頼関係を高めたり、個々の意識を変えていくなど、ソフト面での改善も続けていく必要があるでしょう。