要件定義のヒアリングで漏れを防ぐ「全部見せてください会」｜現行業務を画面共有で確かめるチェックリスト

「全部見せてください会」とは、CRMなどの業務システムの要件定義を確定する前に、口頭のヒアリングに加えて、お客様が現在の業務で使っている管理シート・帳票・やり取りの実物を、画面共有で業務の最初から順に見せていただく場のことです。私たちが支援の中で使っている呼び方で、目的は「要件の前提が実態と合っているか」を確かめることにあります。

この記事では、中小の人材紹介企業でのCRM導入支援で、実際に使った確認チェックリストを、他の業種でも使える形に一般化して公開します。あわせて、その会で何が分かったのかを「調べて分かったこと」として紹介します。この案件は構築中のため、導入の成果は書いていません。

なぜ要件定義のヒアリングだけでは漏れが出るのですか？

口頭のヒアリングで得られる答えは、どうしても「普段こうしています」という要約になるからです。要約には、例外や手作業、本人も意識していない管理のルールが入りません。

たとえば「求人はどう管理していますか」と聞けば、「スプレッドシートで管理しています」と返ってきます。しかし、そのシートが取引先ごとに1行なのか、求人ごとに1行なのかで、CRMのデータの持ち方は変わります。こうした違いは、実物を開いてもらわないと分かりません。

もう一つの理由は、「どこにも記録されていない情報」を見つけるためです。業務を回すのに必要なのに、シートにもシステムにも書かれておらず、担当者の記憶の中にだけある情報があります。これは質問しても出てきにくく、実物を順に見ていく中で「この判断は何を見てしているのですか」と聞いて初めて分かります。

人材紹介企業の会で、何が分かったのですか？

支援先の会では、求人のオーダーを受けるところから、採用後の支援、請求までを、画面共有で順に見せていただきました。口頭のヒアリングでは出てこなかった論点が、いくつも見つかりました。

1. 候補者の情報は、フォルダの構造の中にしかなかった

応募者の履歴書は、候補者を紹介してくれる外部の提携先から、PDFや表計算ファイルなど相手ごとにばらばらの形式で届いていました。支援先が自社の書式を渡しても、自由な形式で届くことが多いとのことでした。これらはクラウドストレージ上で、取引先・求人・候補者の属性ごとのフォルダに分けて保管されていました。つまり「どの求人に応募したか」「どの提携先から来たか」「候補者の属性」という、候補者に紐づけたい情報が、項目ではなくフォルダの場所として表現されていたのです。

2. マッチングの軸になる情報が、どこにも記録されていなかった

この業務では、候補者が持つ資格の種類と、求人が求める資格の種類が合っていることが、紹介の前提になります。ところが、その種類は管理シートに記録されておらず、担当者が取引先ごとに覚えている状態でした。会の中で、資格の種類を候補者・取引先・求人のそれぞれに持たせ、照合できるようにする必要があると分かりました。あわせて「求人は原則1つの種類、取引先は複数の種類を持ちうる」という管理単位も確認できました。

3. 誰が入力するかの前提が変わった

履歴書の情報を誰がCRMに入力するかは、当初は支援先の社内で行う前提でした。実物を見て、提携先から届く情報の形式がそろわないことが分かり、提携先の担当者にWebフォームから直接登録してもらう方針に変わりました。さらに、選考段階で必要な情報と、内定後の手続きで必要な情報は粒度が違うため、フォームを2段階に分ける形になりました。

4. 連携できない道具が分かった

新規開拓のテレアポで使っている電話システムは、外部と連携できないことが分かりました。そのため、アポイントが確定した時点で担当者がCRMに登録する流れにしました。連携できるかどうかは、道具の実物を見ないと判断できません。

5. 記録すべき活動の種類が見えた

採用後の支援では、本人との定期面談、受け入れ先企業との定例、日常的にチャットで寄せられる生活上の相談がありました。面談記録は文書のテンプレートで運用されており、これをCRMの活動記録として再現する方針になりました。請求は会計ソフトで3つの区分に分けて管理していることも分かり、CRM側でどの粒度の情報を持てばよいかの判断材料になりました。

人材紹介業のデータの持ち方全体については、人材紹介業の案件・候補者管理システムの作り方で詳しく書いています。

業務ヒアリングの確認チェックリスト（そのまま使える7分類）

支援先の会で使ったチェックリストを、業種を問わず使える形に直したものです。会の前に共有しておくと、どの画面を開くかを準備していただけます（当社の推奨）。

A. 取引先側の管理（実物を画面共有で）

• 見込み客から取引先までを管理しているシート（項目の一覧、ステータスの区分、誰がいつ更新しているか）
• 案件・求人・注文などの管理の単位（取引先ごとか、案件ごとか。CRMでどこに紐づけるかの判断材料）
• 進捗の管理方法（実際に使われているステップ。商談ステージの設計に反映する）
• 取引先に提出している報告資料の書式（システムで代わりに見せる範囲の判断材料）
• 見込み客への架電・接触の記録方法

B. もう一方の管理対象（人材・物件・案件の相手方など）

• 管理シートの項目の一覧
• ステータスの移り変わりの実際の運用（どんな区分で、どこで次に進むか）
• チャットでの実際のやり取り（頻度、対応する人、過去の履歴の扱い。連携方式を決める判断材料）
• 外部から情報を受け取る方法（書式とチャネル）

C. 帳票の実物

• 見積書（記載項目、値引きの書き方、インボイス対応、体裁）
• 請求書（どのシステムで発行しているか、CRM側に持つ金額の粒度）

D. 社内の仮決定事項の答え合わせ

要件定義書の初版で「仮決定」にしている論点を、表にして持ち込みます。

論点	仮決定（当社の推奨）	当日の確認
（例）どの段階の相手からシステムに登録するか	（例）選考を通過した人だけ登録する	決定内容
（例）取引先に見せる範囲	（例）閲覧とコメントまで	決定内容
（例）フォームの項目と必須の範囲	（例）最小構成から始める	決定内容

E. マスタ・データ・環境

• 商品・サービスのマスタ（会計ソフトなどから流用できるか）
• 既存シートからのデータ移行の範囲（どこまで移すか。大きい場合は別に見積もる）
• システムを使う人と人数
• 連携したい外部サービスの契約状況と管理者権限

F. 先行して動いているタスク

• 広告やLPなど、システム本稼働より先に動く施策の予定日（フォームを先に作る必要があるか）
• 外部の制作会社に伝えるべきこと（フォームの埋め込み方法など）
• 流入経路の計測で、何を単位に見たいか

G. スケジュール・体制・持ち帰り

• 全体スケジュールの承認（補助金などの期限がある場合は、そこからの逆算）
• 要件定義期間中の打ち合わせの頻度と曜日
• 当社から当日示す見立てと、持ち帰って判断するものの区別
• 当日の結果を踏まえた、要件定義書の更新箇所の特定

当日はどう進めればいいですか？

進め方の要点は4つです。

1. 業務の最初から順に見せていただく。 「どこから話せばいいですか」と聞かれたら、「最初の情報が入ってくるところから」とお願いします。途中から見ると、前工程で何が決まっているかが分かりません。
2. 実物を開いていただく。 シートは項目名だけでなく、実際の行を数件見せていただきます。フォルダの分け方、色分け、メモ欄の使い方に、運用のルールが表れます。
3. 判断の根拠を聞く。 「この振り分けは何を見て決めていますか」「この情報はどこに書いてありますか」と聞きます。答えが「覚えています」なら、それはシステムに持たせるべき情報の候補です。
4. 仮決定はその場で答え合わせする。 白紙で「どうしますか」と聞くと、その場では決まりません。推奨案を添えて「この方針でよいですか」と確認すると、判断が早く進みます。

画面に個人情報が映る場合は、録画や文字起こしの有無と、記録の扱いを事前に確認しておきます。

外部に依頼する場合の見極め方は、CRM導入支援会社・営業DXコンサルの選び方にまとめています。

1回で、全部分かりますか？

分かりません。私たちの支援でも、会の後に設計を見直した論点がありました。

一つは、データの持ち方です。会の後の定例で、選考段階の人と採用後に支援する人を「同じ箱でステータスを切り替える」か「箱を分ける」かを議論しました。当社は1つにまとめる案を推していましたが、支援先は、それぞれの段階でためていく情報の性質が大きく違うことを理由に、箱を分ける判断をされ、その方針で確定しました。実物を見たうえでも、使う側の感覚で決まる論点は残ります。

もう一つは、確認の範囲です。会のチェックリストには取引先側と候補者側の両方を入れていましたが、1回の会で両方を見切ることはできませんでした。その後に配布した項目ヒアリングシートは候補者側の観点だけだったため、取引先側の業務フローと入力項目は、別のヒアリングシートを作って確認することになりました。管理対象が2系統ある業務では、両方の確認の場を最初から分けて計画しておくのが安全です。

この経験から、私たちは全部見せてください会を「要件を確定する場」ではなく、「要件の前提を実物で答え合わせし、残りの穴を特定する場」と位置づけています。会の後は、ヒアリングシートで穴を埋め、要件定義書の版を上げながら固めていきます。

自社だけでも実施できますか？

できます。外部の支援会社に頼む前でも、社内でこのチェックリストを使って自社の業務を一通り見直すと、システムに何を持たせるべきかが見えてきます。特に、表計算ソフトで案件を管理している会社では、「どの列が実際には使われていないか」「どの情報がシートの外にあるか」が分かるだけでも、移行の準備になります。今の管理表の限界の見極め方は、エクセル案件管理の限界はどこかも参考にしてください。

ただし、自社の業務を自社で見ると、当たり前になっている手作業や例外に気づきにくいものです。外の目が入ると「なぜこれをしているのですか」という質問が生まれ、そこから要件が見つかります。

まとめ

全部見せてください会は、要件定義を確定する前に、現行業務の実物を画面共有で最初から順に見せていただく場です。口頭のヒアリングでは要約されてしまう「管理の単位」「記録されていない情報」「手作業の転記」「連携できない道具」が、実物から見えてきます。チェックリストは会の前に共有し、仮決定は推奨案つきで持ち込み、1回で終わらない前提で後のヒアリングシートと要件定義書の更新につなげる。この進め方で、システムを作ってから「実はこう管理していた」と分かる手戻りを減らせます。

CRM導入の前に、いまの業務のどこから見直すべきかを整理したい方は、受注プロセスの無料診断から現在の管理方法をお知らせください。要件定義から現場への定着までの支援の内容は、見込み客から受注までのプロセス管理にまとめています。

よくある質問

「全部見せてください会」は、要件定義の通常のヒアリングと何が違うのですか？

通常のヒアリングは質問に口頭で答えてもらう形式で、答えは「普段こうしています」という要約になりがちです。全部見せてください会では、管理シートや帳票、チャットのやり取りなどの実物を、業務の最初から順に画面共有で見せてもらいます。実物を見ると、フォルダの分け方や列の使い方から、口頭では出てこない管理の単位や例外処理が分かります。

どのタイミングで実施するのがよいですか？

提案内容と大まかなスコープが固まり、要件定義書の初版を作った段階が適しています。早すぎると何を確かめるべきか定まらず、要件を確定した後では設計をやり直すことになります。私たちの支援では、要件定義書の初版を作った後、その中の「仮決定事項」を答え合わせする場として位置づけ、会の結果で次の版に更新しました。

所要時間と参加者はどう決めればいいですか？

実務を一番よく知っている方に必ず入ってもらってください。管理職だけでは、実際の入力や転記のやり方が分かりません。時間は業務の範囲によりますが、取引先側と候補者側のように管理対象が2系統ある業務なら、1回で両方を終えるのは難しいと考えておくのが安全です。見切れなかった部分は、後日ヒアリングシートで補います。

画面に個人情報が映る場合はどうすればいいですか？

事前に、画面共有で実データが映ることを双方で確認し、録画や文字起こしをするかどうか、記録の保管範囲を決めておきます。見せていただく側が不安なら、項目名と数件だけを見せていただく、氏名列を隠していただくといった形でも、管理の構造は十分に確認できます。

会で確認したことは、どう要件定義に反映すればいいですか？

会の直後に、要件定義書のどこを直すかを特定し、版を上げて更新します。私たちの支援でも、会の最後に「本日の結果を踏まえた次の版の更新箇所の特定」をチェック項目に入れていました。確認できなかった項目は「未確認」として残し、ヒアリングシートや次回の定例で埋めていきます。