
【HRスカウト業務のAI効率化を"要件定義で地に足をつける"】
業務フロー整理とROI試算で優先順位を決め、2ヶ月でプロトタイプ+定義ドキュメントまで落とし切った設計事例
AIツールが注目される一方で、「AIを入れること」自体が目的化してしまい、現場で使われないまま止まってしまうというお悩みは、ここ近年では珍しいことではありません。
今回ご紹介するのは、人材紹介(エージェント)事業のスカウト業務を対象に、"AIで効率化したい"というアイデア先行の状態から、業務フローとROIを起点に要件を固め、開発に渡せるレベルまで落とし切った支援事例をPMとして参画された石川さんにお伺いしました。要件定義フェーズから参画し、ユーザーは誰か、どこにペインがあるか、何をKPIにするか、どこまでをAIに任せるか。前提を一つずつ揃えた上で、最終的にFigmaプロトタイプと、後続開発に渡せる定義ドキュメント一式(データ/ステータス/機能/AI要件など)を作成し、開発フェーズへ引き継ぎました。
こんな方に読んでほしい記事です
- 事業責任者/統括:AI導入の検討は進むが、成果に結びつける道筋が描けない
- BizPM/PdM:AI活用を進めたいが、業務理解・KPI・スコープが曖昧で前に進まない
- 現場マネージャー:人手のかかる業務が多く、改善したいが優先順位をつけられない
- 開発側:「何をどこまでAI化するか」が決まらず、実装判断がブレる
1. 本事例の背景(相談の入口)

本事例の相談の入口としては、「現在行っているスカウト業務が人力の比重が大きく、ここをAIで効率化できないか」というものでした。AI導入がホットな領域である一方で、現場業務に落ちないケースも多くあります。だからこそ、このテーマ自体は"やりがいがある"一方で、難易度も高いという認識が共有されていました。石川さんが参画された要件定義フェーズに入った時点では、「機能として何ができるか」というアイデアが先にあり、そこから開発へ持っていくにあたってのギャップが残っていた、という状態でした。この段階でよく起きがちになってしまうのは、「AIで何かできそう」→「とりあえず作る」→「結局使われない」という流れです。そのため要件定義フェーズで必要だったのは、アイデアをただ受け入れるのではなく、"使われる前提"まで地に足をつけていくことでした。
2. 課題(支援先で起きていたこと)

プロジェクト初期に見えていた課題は、端的に言えば「アイデア先行で、WHYやユーザーのペインが不明確で地に足がついていない」ということでした。
- 業務整理(As-Is)が整理されておらず、To-Be設計に入れない
- 価値が出る領域と実現可能性が曖昧で、「どこまで作るか」が決められない
- KPI設定の議論がなく、「導入した結果どう良くなったか」を測れない
スカウト業務は、「候補者を探す」「選定する」「送信文面を作る」「送る」「反応を見る」など複数の工程が連なります。このときAI活用の論点は単純に「自動化する」ではなく、どこまでAIに任せ、どこを人が判断するかが要件そのものになります。たとえば、最終判断をAIに寄せすぎると、現場の納得感が崩れやすい。一方で慎重になりすぎると、"AIを入れたのに変わらない"になりやすい。だからこそ、いきなり作り始めるのではなく、最初に前提とスコープを固める必要がありました。
3. ゴール(何を"できる状態"にするか)

今回のゴールは単に「AIを現場に導入すること」ではありません。具体的には以下のように"開発に進めるレベル"まで要件を落とすことでした。
- ユーザーは誰で、どの業務のどこにペインがあるのか
- AIに任せる範囲/人が判断する範囲
- 優先順位とスコープ(限られた予算・スケジュール前提)
- 成果を測る観点(KPI含む)
- 実装へ渡すためのプロトタイプと定義ドキュメント
それらを揃え、後続の開発会社へ引き継げる前提を作ることです。「AIでできることの話」だけで終わらず、現場で使われ、評価され、継続的に改善できる土台までを要件定義で整えることがゴールでした。
4. 進め方(実行してきたこと)

4-1. ユーザーと業務フロー(As-Is)から着手する
最初に取ったアプローチはボトムアップでした。「As-Isが明確でないとTo-Beをデザインできない」という前提で、まずユーザーは誰か/業務フローはどうなっているかを整理します。支援側で叩き台となるフローを作り、クライアントへのヒアリングで現状の動きとペインを確認していきます。この段階では「AIに何をさせるか」よりも、まず「現場のどこで時間が溶けているか」「どの判断が重いか」を言葉にすることが重要になります。そのために業務整理に時間を使う価値がある点は、共通課題としてクライアントにも理解してもらえてスムーズに合意ができました。
4-2. 業務フロー整理を通じて、優先順位と"効くデータ"をシャープにする
業務フローを紐解く中で、大枠のアイデア自体は大きく変わらなかった一方で、議論が深まったのが優先順位です。「何を優先すべきか」が揃うほど、AIでどこを支援すると効くのかも見えやすくなります。さらに、機能の議論だけではなく、「どのデータが効果的か」「アウトプットをどう出すべきか」といった具体論が進み、ソリューションをシャープにできた、という振り返りでした。AIを入れる前に、"判断に必要な材料"が何かを先に整理する。ここが曖昧だと、AIが出した結果も評価できなくなりがちです。
4-3. ROI起点でスコープを絞り、開発フェーズに渡せる形にする
予算・スケジュールが限られていたため、全スコープでは間に合わない判断に至りました。そこで「どこまでやるか」を握るために、ROIが高そうな部分(特に人手がかかっている部分)を基準として優先順位を決めました。ROI試算は、クライアントから「どれくらいの時間をかけているか」「月に何件あるか」などをヒアリングし、支援側でドラフトを作って合意を取っていきました。このとき重要なのは、数字を厳密に当てることより、「投資対効果を議論できる土俵」を作ることでした。土俵ができると、スコープの議論が感覚論になりにくく、意思決定が前に進みます。
4-4. プロトタイプ中心に、週2回の認識合わせで2ヶ月で詰め切る
アウトプットの中心は、要件定義書ではなくFigmaプロトタイプで行いました。「入力として何が使われているか」「アウトプットはどんな形が効くか」を特定し、それを元にプロトタイプを作成します。週2回程度の頻度でクライアントと認識合わせを行いながら、開発に引き渡せるドキュメントへ落とし込んでいきました。短いサイクルで「見せる→直す」を回すことで2ヶ月で要件定義を完了させています。プロトタイプ中心の進め方は、言葉だけの合意よりもズレが出にくく、特にAIのように"イメージが割れやすいテーマ"では有効です。
4-5. 定義ドキュメント(データ/ステータス/機能/AI要件)まで作り、後続へ引き継ぐ
最終的に、プロトタイプに加えて、データ定義・ステータス定義・機能要件・AI要件などをドキュメント化し、開発に進めるレベルへ落とし込みました。ヒアリングとアウトプットの取りまとめは支援側が担い、クライアントは提示案のレビュー・承認・意思決定を行うという役割分担でした。要件定義完了後は、別会社にて開発フェーズへと引き継がれ、石川さんは基本ノータッチになったと述べています。つまり、本支援は「作り切る」ではなく、作るための前提(判断材料と仕様)を揃え、次のチームが迷わず進める状態を作る役割も担いました。
5. 成果

この支援で得られた成果は、数値の改善よりもまず、"明確なAs-IsとTo-Beを整理して、開発に渡せる状態"まで要件を締め切ったことにあります。
- プロジェクト初期に「何のために必要なのか」「誰が嬉しいのか」を言語化し、課題→解決策までの筋を通したことで、提案が"アイデア"ではなく"判断できる材料"になった
- 業務フローとペインの整理を起点に、スコープと優先順位をROI観点で絞り込み、限られた期間でも意思決定が止まりにくい状態を作れた
- Figmaプロトタイプと、データ定義/ステータス定義/機能要件/AI要件などの定義ドキュメントを揃え、後続の開発会社へ引き継げる粒度に落とし切った
- 「導入して終わり」ではなく、KPIや評価観点も含めて整理して、開発後に"改善の議論を回しやすい"設計に仕上げた
本質的に「価値があるシステム」にするために、課題感からソリューションまでのロジックを通して、チームの誰しもが納得感をもったプロダクトまでに仕上げました。
6. インタビュイーのこだわり
石川さんがこの案件を通して、改めて感じたのは、AIがどれだけ進化しても、取り組みの要点は変わらないという点でした。AIがトレンドとして強い今、「AIを入れること」自体が目的になるケースはこれからも出てくると思います。けれども、ユーザーは誰で、どんなペインを解くのか、ここが先に揃っていないと、結局は使われない仕組みになってしまいます。だからこそ、AI時代でもまず本質(誰の課題か/なぜ起きているか)を捉えるのが大事です。
また、AIの進化が速く「追うだけでも大変」になっているなかで、石川さんご自身としては、シリコンバレー系のAIトレンド情報を見たり、実際に手を動かして試したり(いわゆるバイブコーディング的に作ってみる)してキャッチアップしているという話もありました。ただし、作れるようになること自体はゴールではなく、最後に問われるのは、それが本当に使われるかであると語られます。だからこそ、情報収集や試作を続けつつも、最終的には「誰のペインであるのか」「なぜそれが起きているか」に立ち戻り、そこに解決策を当てることに意識を置いています。この姿勢が、今回の要件定義の進め方にも一貫していました。
7. 最後に(総括)

AI活用のプロジェクトが止まりやすいのは、技術が足りないからというよりは、意思決定の前提が揃わないまま"作る話"に入ってしまうからです。作れるものが増えるほど、選択肢は広がり、判断は重くなります。そこで「なんとなく良さそう」「とりあえず作ってみる」が先行すると、現場の使い方や評価基準が後回しになり、導入が"イベント"で終わりやすくなります。
今回の事例が示しているのは、AI活用を成功させるうえで必要なのは派手な機能ではなく、使われる前提を先に設計することだという点です。誰が使うのか。どこが詰まっているのか。何が減れば嬉しいのか。どの数字で良くなったと言えるのか。どこまでをAIに任せ、どこを人が握るのか。この前提が揃って初めて、プロトタイプも要件も「開発へ渡せるもの」になります。結果として、短期間でも後続が迷わず進める形に落ち、実装フェーズや運用フェーズで"改善が回る"土台が残ります。AIの時代だからこそ、最後まで効いてくるのは「本質を外さない要件定義」だと、改めて感じさせられる支援でした。
インタビュイー:石川さん
プロダクトマネージャー(PdM)。IBMでプロジェクトマネージャーとしてキャリアをスタートし、欧州MBAおよびデザインスクールでUX領域の専門教育を経て、日本および欧州のスタートアップでプロダクト開発に従事。現在はフリーランスとして、新規事業開発およびプロダクトマネジメント支援を行っている。事業検討から業務整理、要件定義、仕様策定、開発接続までを一貫して担当し、関係者間の認識を揃えながらプロジェクトを推進することを得意とする。特に、構想段階にあるプロダクトを実装可能なレベルまで具体化し、開発チームが動ける状態に落とし込む支援に強みがある。
スキル・強み
- 新規事業・プロダクト立ち上げ:仮説整理/MVPスコープ設計/0→1フェーズの推進
- 要件定義・設計:業務フロー整理/要件定義/仕様策定/開発接続
- UX・プロダクト設計:ユーザー・業務理解/体験設計/改善サイクル設計
- AI活用:AI機能要件定義/入力・出力設計/業務への組み込み/プロトタイピング・MVP開発
本事例の情報
- 業界:HR (Human Resource)
- 体制:クライアント:事業責任者/PM/担当者(2名)/協力会社:マネージャー/デザイナー(2名)/KSR:PM(3名)
