要件定義フェーズが「ない」組織での開発の進め方　課題を担保する、ユーザーからの一次情報とメンバーとの対話

サービスと開発環境

元木直哉氏：HERPの元木です。初めに簡単に自己紹介します。2年半くらい前からHERPのプロダクトマネージャー兼開発チーム責任者をしています。その前はHERPで採用コンサルタントを、その前は石油会社にいてマレーシアでLNG（液化天然ガス）のプロジェクトをやっていました。要するに、デザイナーやエンジニアなどのバックグラウンドがない状態で、ビジネスよりのプロダクトマネージャーをやっています。

要件定義という話ではありますが、HERPが今やっている開発の流れを共有すれば、どのように要件定義をやってるかを伝えられると思ったので、具体例を混ぜながら話せればと思います。

バックグラウンドがわからないと話も全然わからないと思うので、先に会社やサービスの説明をします。「採用を変え、日本を強く。」をミッションに掲げている、創業から4年半くらい経った会社です。（スライドを指して）シリーズBの調達が終わったくらい（の状態）で、社員数は「55名（インターン含む）」と書いていますが、正社員は40名くらいの規模です。

採用関連のtoBのSaaSのサービスを開発提供しています。ユーザーは採用担当をはじめとした採用に関わる方全員ですが、面接官のほか、最近はリファラル採用やスカウトを打つ方など、採用担当者以外に現場のメンバーも関わっていると思うので、そういった方が使うことも想定して作っています。累計の導入社数は、現在900社を超えました。

どういう開発組織で開発していくかという、会社のバックグラウンドを共有します。先ほど、大まかに2つのサービスがあると言いましたが、それぞれに開発チームがあります。それぞれにPOとフロントエンジニア、バックエンドエンジニアがいます。

Nurtureのほうが新しい事業なので、（Hireに比べると）少しこぢんまりしたチームでやっています。SREが2名のほか、基盤開発サポートとして業務委託の方が2名います。インターンの方々にも開発を手伝ってもらっています。

HERPの開発スタイルですが、スクラム開発を採用し、1週間スプリントでやっています。特徴的なものとして、スプリントレビューがあります。（スクラム開発には）スプリント終わりに成果物を発表するイベントがあると思いますが、毎週金曜日にやる週次の全体会議で、全社メンバーの前で実施しています。社内全体が開発に興味・関心を持って、進捗を把握できるように進めています。

メンバーや雰囲気の特徴なども共有できたらと思います。ウォーターフォール開発を経験した人が20名弱のメンバーの中にほぼおらず、その中でも10名弱が新卒だったり、Web系の新しいの会社にいた人だったりします。メンバーの入れ替わりが少なく、まだ1人か2人しか退職していないため、引き継ぎが発生したことがあまりありません。

初期からいるメンバーが多いので、役割・役職関係なく自律してやっていこうとか、スクラムマスターというオフィシャルな資格・研修を受けた上で来ている人もいるので、アジャイルソフトウェア開発宣言の内容は尊重していこうと考えています。

今、採用関連ツールを作っていますが、もちろん自社でも採用を行っているので、エンジニアも自社内で積極的にツールを使い、ドッグフーディングできています。HERPのユーザーは、協力的にフィードバックをくれるなど、開発に協力してくれる方が多い環境があります。以上のような前提で、HERPがどのように開発しているか、具体的な話をしようと思います。

要件定義をしない開発の進め方

要件定義のLTなので“要件定義”というフレーズに触れておきます。この単語は今社内で使われておらず、要件定義書のようなドキュメントもまったく作っていない状況です。

メンバー同士でたくさん会話して、認知を揃えたり、開発者がヒアリングしたりして一次情報を取っていくことで、このあたりを担保していこうとしています。特に固定の開発フローもないので、要件定義フェーズなどもない状況でやっています。

前提共有が終わったので、具体的な事例を挙げて、どのような開発をしているか共有します。現在は日程調整機能を開発しています。平たく言うと「Calendly」や「Spir」などのような日程調整機能を採用管理ツール内で使えるようなものです。

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

（スライドを指して）実際にどのように開発しているかを、ざっとフローに書いてみたので共有します。

（スライドを指して）まず、プロダクトオーナーが「こういうのを作りたい」という提案をします。右にある文章が実際に書いたものです。「候補者との面談・面接の日程を調整しやすくしたいので、このあたりに課題がある」「こういう業務でやっている」「他社ではこういう機能があるけど、おそらくこういうソリューションがあり得るのだろう」とか。

「ユーザーから他社にはこういう機能がある」とか、「こういう機能があるとうれしい」という話をPOがもらって、一次情報を書いたものをまとめて共有します。ドキュメントはないと言いましたが、メモはあるので、全文検索で過去の履歴を取ってきたりしています。

POから提案のあとは開発チームにボールを投げていることが多いので、そこから先の細かい話は、開発チームが一次情報を得ながら進めています。例えばユーザーヒアリングは、頻繁にコミュニケーションが取れるユーザーが多いので、カジュアルにSlack上でアポを取ったり画像を共有したりして、開発チーム自ら「こういうのどうですか？」と聞けるような状況です。

CSがユーザーと密にコミュニケーションを取り、日頃から要望を聞いて、どういうユーザーがどういう要望を持っていそうかを把握しているので、どういうことを聞いたらいいかを開発チームがCSに聞いて、そのあたりをユーザーに聞くというような、自立したユーザーリアリングをしています。

ユーザーヒアリングのあとによくユーザーストーリーマッピングをしますが、開発チームでも業務フローの整理や課題の洗い出しなどをMiroを使って一度整理します。

（スライドを指して）少し見にくいですが、よくあるユーザーストーリーマッピングの図です。このようなユーザーストーリーマッピングを、開発チームがプロダクトオーナーやCSと一緒にやっています。

アウトプットを出すことより重視しているのは、検討プロセスを通じて、開発メンバー全員がどういったユーザーのどういった要望に応えるために、何を作ろうとしているのか、それを理解するために、このようなものを全員でやるようにしています。

バックログの管理はNotionを使って、出てきたユーザーストーリーを、上から順に優先順位をつけて並べています。みんなで検討していますが、プロダクトオーナーには優先順位を決める仕事があります。迷ったところはPO判断になりますが、割とみんなが同じ情報を持っているので、大きくズレることなく優先順位の並び替えができます。

逆に開発者側からは「やはりこちらを先にやったほうがいい」という、柔軟な判断がしやすくなっています。ほかに、テスト利用を通じて得た情報を元に、全員が頻繁に優先順位を提案して、変更して、開発を進めています。

テストとヒアリングを繰り返しながら開発を進める

これでユーザーストーリーが積まれたので、1週間のスプリントでスクラムの開発をしていきます。つまり、週次で作っていく。ここは少しずつ作っていくところなので、社内でも使って、社員で試験利用を挟んだりもしています。

テストユーザー数社で利用するステップを挟んでいます。（スライドを指して）このようにテストユーザーを募集します。募集というより、カスタマーサクセスチームにどの会社が協力してくれそうかを聞いた上でアポを取り、開発チームもテスト利用の導入説明に行って、フィードバックをもらったりしています。

下の赤枠にありますが、前提としてミニマムで作っています。不自然なUIもあるという前提でも、開発に協力してくれるユーザーがいるので、ユーザーと一緒に新機能を作って、フィードバックをどんどん活かしています。

それが終わったらクローズドベータ版で、もう少し社数を増やし、使いたいと言ってくれる10～20社くらいに使ってもらっています。そのような流れでどんどんアクセス数が増えているので、インフラ側と非機能要件などの調整も進めつつ、そろそろ行けそうだとなると、本リリースして全ユーザーに使ってもらうという流れで、大きい機能の開発を進めています。

HERPの開発周りの要件定義関連の話ですが、今は要件定義というフローや要件定義書がない状況でやっています。ただし、メンバー間で対話によって認知を揃えていくとか、直接聞きに行って同じ一次情報を得ることで、認知のズレを防ぐようにしています。

テスト提供や段階的なリリースができる状態にしてあるので、そういうときは仮説・検証を繰り返して、よりよいものにしていく。要件定義で考えるよりも、実際に出して、フィードバックをもらって、改善していくことを大切にしています。

要件定義をしないからこそ、柔軟に自律開発できる

善し悪しあるので、今やっているものの感想を。実は、この開発体制は1年は経っていません。スクラム開発を導入して1年くらいで、その前はあまり形式のない、自由な開発をしていました。

こういう形式で半年くらいやった感想ですが、要件定義や「これを作ろう」と上から言って作ってもらうよりは、かなりやらされている感が少ないです。その分、「こういうものを作りたい」というモチベーションが担保されて、高クオリティというか、スピードが出ているのかなと思っています。

さらに、要件の変更に柔軟に対応できます。（普通は）あとから「それ聞いてないよ」となることがあると思いますが、一次情報を得ていることで、みんな「こういうことがあり得るよね」と薄々思っているので、要件をある程度織り込んで、開発を進めてられている気がしています。

手法も、5日間で仮説・検証するデザインスプリントのようなものも、開発チームからやりたいという声が挙がってきています。内製なので（体外的な）締め切りがなかったり、（対外的に）コミットしている機能要件がないからこそできることなのかなと思うことがあります。

（スライドを指して）MOREについては、（現在のHERPの開発は）けっこうトリッキーというか、かなり自主性を重んじているというか、ウォーターフォールで開発していると、かなり違和感のあるやり方だと思います。そういうところでやっているエンジニアがもしHERPに入社するとするとアンラーンしていかないといけないので、採用は大変だという気持ちはあります。一方よさもあるので、よさは活かしつつスケールしていきたいと思っています。

3年強くらいプロダクトを提供していますが、今はSLO（Service Level Objective）、SLA（Service Level Agreement）のような非機能要件の数字の決めがなくて導入中です。導入されたら、もう少しそのあたりに気をつかって開発する必要があるのかなと思っています。以上です。