要件定義書は使いません。HERPのPMがスクラム開発で模索する、新たな開発のカタチ

※2021年12月14日に開催された【開発PM勉強会】 より、株式会社HERP、元木直哉さんによる「要件定義とアジャイルな開発のバランス」セッションを書き起こし形式でお届けします。※記事内では「PO＝プロダクトオーナー、PM＝プロダクトマネージャー」として表記しています。

石油会社からHRテックベンチャーへ

はじめに簡単に自己紹介をさせていただきます。

「HERP」の元木と申します。HERPで採用コンサルタントとして働き、半年ほど前からプロダクトマネージャー兼チーム責任者をやっています。その前は石油の会社に勤めており、マレーシアなどで「LNG」プロジェクトをやってました。エンジニアやデザイナーなどのバックグラウンドがない、ビジネス側のプロダクトマネージャーをやっています。

今日は「要件定義」が題材ですので、HERPで今やっている開発の流れを共有したいと思います。HERPが要件定義をどのようにやっているのか、伝わると思うので、具体例を混ぜながらお話します。

累計導入企業は900社超

バックグラウンドが分からないと話が伝わらないと思うので、会社やサービスの説明を先にさせてください。

HERPは「採用を変え、日本を強く」をミッションに、2017に創業しました。ちょうどシリーズBの調達が終わり、従業員は55名（インターン含む）、正社員で40名ぐらいの規模の会社です。

採用関連のtoB SaaS、具体的には採用管理のサービスとタレントプール管理のサービスを開発、提供しています。

使って頂いてるユーザーは採用担当をはじめ、採用に関わる全員、面接官です。最近ではリファラル採用、スカウト送付担当など、採用担当以外の方も使用することを想定して作っています。現在、累計導入社数は900社を超えました。

HERPの開発組織

ここからは、どういう組織で開発しているか、ご紹介します。HERPには2つのサービスがあり、それぞれにチームがあります。それぞれにPOがいて、フロントエンドエンジニア、バックエンドエンジニアがいます。

右側の「Nurture」が新しい事業のため、少しこじんまりしたチームに。「SRE」が2名、基盤開発サポートとして業務委託の方が2名います。インターンの方が多く、開発を手伝ってもらっています。ちなみに私はプロダクトマネージャーですが、このPOにはカウントされていません。

開発のスタイルとしては、スクラム開発を採用しており、1週間スプリントでやっています。

毎週金曜日に全体会議があり、そこで全社メンバーの前でスプリントレビューを実施します。社内全体が開発に興味・関心を持ち、進捗を把握できるように進めています。

ちなみに開発メンバーたちの特徴はこのようになっています。

「要件定義」という単語が社内に存在しない

では、本題ですが、HERPがどのように開発をしているか、具体的に話していきたいと思います。まず「要件定義」がテーマのLTなので、要件定義というフレーズに触れておきます。

「何で要件定義にLTに来たの」と言われてしまうかもしれませんが…要件定義という単語は社内では使われていません。「ドキュメント等で要件定義書を作る」ことを全く行なっていない状況です。

・メンバー同士でよく会話して認知を揃える
・開発者がヒアリングをして一次情報を取得する

これらによって要件定義を補っています。あまり固定のフローもなく、要件定義フェーズもない状況で今はやっています。

前提が共有できたので、具体例を挙げて説明していきます。

現在は「Calendly」や「Spir」のような日程調整機能を作っています。

選考予定を設定する際、「HERP Hire」から発行したリンクで設定すると「HERP Hire」内に選考情報等が自動的に作成されるものを現在作っています。

ユーザーと密に連携を取りながら進めていく開発

実際どういったフローで開発しているか、次の資料の上から順に解説していきます。

まずは、POが「こういうのを作りたいです」という大元を持っていきます。小さいですが、右側が実際に書いた文章です。

候補者と面談の日程を調整しやすくしたいということで、

・多分この辺の課題があるよね
・こういう業務でやってるよね
・こういう機能があったりすれば、おそらくこういうソリューションがあり得るんだろうね

といった情報をまとめています。

また、ユーザーから

「他社にはこういう機能がある」
「こういう機能あると嬉しい」

といった話を聞くことがあるので、そういった一次情報を書いたものをまとめて共有します。ドキュメントがないとは言いましたが、メモはあり、検索で過去の履歴を取ってきたりはしてます。

ここから先の細かい話はチームで一次情報を得ながら開発を進めていきます。

さっきの榎本さんの話で「POからどんどん投げていく」というお話がありましたが、HERPでも同じくチームにボールを投げることが多いです。

次にユーザーヒアリングを行うのですが、Slack上で頻繁にコミュニケーションを取れるユーザーさんが多いです。そのためカジュアルにSlack上でアポ取りをしたり、画像を共有しつつ、「こういう画面ってどうですか？」と聞けるような状態になってます。

CSチームが密にユーザーさんとコミュニケーションをとっており、常日頃からユーザーさんがどんな要望を持っていそうなのか、把握しています。

そのため、CSチームに「どの会社さんに聞くと良さそうか」を尋ねてから、ピンポイントでユーザーヒアリングを行うことができます。

ヒアリングができたら、ユーザーストーリーマッピングを作成します。この時には業務フローの整理や課題の洗い出しをチームで一回整理します。見にくいですが、よくあるユーザーストーリーマッピングの図です。

こういったユーザーストーリーマッピングを開発チーム、PO、CSを混ぜた上でやっていきます。

ミニマムで作り、フィードバックを集める

重視しているのはアウトプットを出すことではありません。検討プロセスを通じて、開発メンバー全員が、

どういったユーザーのどういった要望に応えるために何を作ろうとしているのか

を理解することです。

そのために、ユーザーストーリーマッピングは「全員」でやるようにしています。最終的にバックログの管理はNotionでやっており、出てきたユーザーストーリーを上から順に優先順位をつけています。

みんなで検討しているため、迷ったところはPO判断になります。ただ、割とみんな同じ考えを持つことが多く、あまりズレることなく、優先順位の並べ替えをしていけます。逆に開発を進めていて、開発側から「やっぱり、こっちを先にやった方が良さそう」といった柔軟な判断がしやすいです。

Notion上にユーザーストーリーが積まれ、1週間のスプリントでスクラムの開発をしていきます。

ここは少しずつ作っていくっていうところなので、

・社内で使って社員で試験日を挟む
・テストユーザー数社で利用のようなステップを挟む

をしています。

これもCSチームに「どの会社さんが協力してくれそうか」を聞いた上で、アポを取っています。開発チームもテスト利用の導入説明に前提として、

「ミニマムで作ってます」
「若干UIが不自然なところがあったりします」

と多少の言い訳はさせていただき、ユーザーさんからのフィードバックをどんどん活かしてやっています。それが終わったらクローズドのベータ版でもう少し社数を増やす、というカタチです。まずは「使いたい」と言ってくださる10～20社ぐらいに使ってもらいます。

その流れでアクセスが増えていくので、インフラ側と機能要件とかの調整を行ないます。そこから「そろそろいけそうだ」となれば、本リリース。全てのユーザーさんにお使いいただく流れです。

要件定義で考えるより、実際に出して改善していく

以上がHERPの開発まわりの「要件定義」関連の話ですが、要件定義というフローや要件定義書もない状況でやってます。

ただ、メンバー間で、

・対話によって認知を揃えていく
・直接聞きにいって同じ一次情報を得る

ことで「認知のズレ」を防いでいます。

テスト提供や段階的なリリースをできる状態にしてあり、仮説検証を繰り返して、より良いものを目指しています。

要件定義で考えるよりも、実際に出してフィードバックをもらって改善していくことを大切にしてやっています。ただ、当然、善し悪しがある。そこで、こういう形で半年ほどやってみた感想をまとめてみました。

Goodとしては「こういうものが作りたい」というモチベーションが担保され、クオリティとスピードが出ていることかなと思います。あとは要件変更に柔軟に対応できていて。要件定義を用いると、後から変更した時に「それ聞いてないよ」となることがあるので、そういったところは避けられていると思います。

この方法であれば、そもそも一次情報を得ているため、みんなが薄々思っている「こういうのはあり得るよね」がすり合い、ある程度、細かい要件定義に表れない要件も折り込んで開発を進められていると思います。

逆に、ウォーターフォールで開発してきた人にはかなり違和感があるやり方。アンラーニングしていかないといけません。そういった意味でも、採用がかなり大変。また、SLO、SLAといった「非機能要件」が導入されてくると、もう少し考慮した上で開発する必要があると思います。こういった点を含め、より改善していければと思います。本日はありがとうございました！（おわり）

編集 ＝ CAREER HACK