業務システムの利用者ヒアリングは何を聞く？現場の仕事から要求へつなぐ方法

ヒアリングで、何を分かるようにする？

利用者ヒアリングは、実際に仕事をする人から、仕事の進め方と困る条件を聞くことです。新しい画面の要望を集める前に、誰が、何を受け取り、どこで判断し、次の人へ何を渡すのかを理解します。ここが曖昧なまま「自動化したい」とまとめると、どの作業を変える話なのかが揃いません。

この記事の対象は、訪問修理の依頼受付を見直す架空の会社です。受付担当は電話メモを受付表へ写して現場調整担当へ渡し、現場調整担当は訪問候補を調べて受付へ返す、という仕事を想定します。情報不足や変更連絡の行き違いがどのような条件で起こるかを、これから聞き取る段階です。困りごとの頻度や実際の影響はまだ分かっていません。

面談を終えた時点で、対象の仕事を本人の説明に沿ってたどれ、分かったことと次に聞くことを分けられる状態を目指します。すべての要求や仕様を一度で確定する、という意味ではありません。初めて聞く仕事なら、まず一件を最後まで説明してもらうことから始めます。

最初に、仕事一つと聞く相手を選ぶ

「受付業務を全部教えてください」では、問い合わせ、修理依頼、日程変更、請求の話が混ざりやすくなります。最初は「修理を依頼された電話を受けてから、受付内容を現場調整へ渡すまで」のように、始まりと終わりを決めます。日程変更は、最初の仕事との違いを聞く別の話題にします。

聞く相手は、実際にその作業をする人です。責任者が手順を説明できても、担当者が手元で補っている確認や、資料を探す場面まで知っているとは限りません。まず作業担当へ実例を聞き、判断の権限や共通のルールは、決める立場の人へ確かめます。役職の高い人一人の説明を、全担当の実態へ広げないことが大切です。

受付の話を聞くときは、現場調整へ「何を受け取ると次へ進めるか」を後から照会できるようにします。担当によって説明が違った場合は、どちらが正しいかをすぐ決めず、対象の依頼、資料の版、通常時か例外時かを揃えて比べます。同じ言葉でも、見ている仕事の範囲が違う場合があります。

事前の問いと、当日使う質問を分ける

準備では、チームが知りたいことと、相手が答えやすい質問を分けます。「入力の抜けを減らしたい」はこちらの関心です。そのまま「抜けを防ぐ必須入力が要りますよね」と聞くと、実態を知る前に方法へ誘導してしまいます。

例えば知りたいことが「受付で情報が揃わない場合の扱い」なら、当日は「最近、必要な情報が分からない依頼はありましたか。何が分からず、その後どうしましたか」と具体例を聞きます。「誰が不足情報を判断するか」「受付表のどこに残すか」「渡した後に何が起きるか」は、その説明に応じた追問です。質問の順を用意しても、答えを先に作らないようにします。

事前資料があれば、受付表の項目名や、仕事の始まりと終わりを予習します。ただし、資料に書いてある手順を現状と断定しません。「この手順は今も同じですか」「資料にない作業はありますか」と確かめる材料にします。資料がないなら、相手の直近の作業から、使った情報や渡したものを順に教えてもらいます。

面談の目的、参加する人、記録の方法、内容を共有する範囲も先に説明します。録音や資料の複写を前提にせず、許可された方法で記録します。顧客名や折返し先など、仕事の理解に不要な個人情報は持ち出さず、伏せた資料や説明で確認できる範囲を選びます。実際の取り扱いは自社の規程と関係者の確認に従います。

GOV.UKの調査準備の指針は、調査で学びたい問いと、そのまま利用者へ尋ねる質問を区別しています。ここではその考え方を、受付の判断条件を具体例から聞く準備へ応用しています。英国政府サービスの指針を、日本の民間企業の決まった面談回数・時間として使うものではありません。調査で学びたい問いの整理を原典で読む

一件の仕事を、受け取るものから順に聞く

当日は、相手の担当と普段の仕事を聞いてから、対象の一件へ入ります。作業を説明してもらいながら、「きっかけ」「受け取った情報」「行った作業」「判断したこと」「次へ渡した結果」を追います。先に画面の項目を読み上げるより、その情報をいつ、何のために使ったかを確かめやすくなります。

作業の説明を、実際に使う情報へ近づける

「電話を受けて受付表へ入力します」という説明なら、「電話のどの内容を写しますか」「受付表に書けない情報はどう扱いますか」「入力した後は誰が見ますか」と聞きます。「チェックします」と言われたら、何を見て、どんな状態なら次へ進めるのかを尋ねます。使ってよい資料があれば、項目や一例を指して説明してもらうと、同じ言葉の意味を合わせやすくなります。

ただし、その場で資料を見せてもらったことと、普段の作業を観察したことは別です。説明のために再現した操作なら、その条件を残します。普段も常に同じ手順だと決めつけず、実際の仕事を確認できた範囲を区切ります。

「便利にしたい」の先にある仕事を聞く

「通知がほしい」と言われた場合は、その案を消さず、「誰が、どの時点で、何に気付けないと困るか」を聞きます。受付内容が調整担当へ届いたことを知りたいのか、訪問候補が返ったことを知りたいのかで、求める結果が変わります。通知という実現方法だけを要求として写さず、困る状況と必要な結果を分けて理解します。

GOV.UKの面談指針も、抽象的な理想論より具体的な出来事を聞き、分からない発言には追問する考え方を示しています。この記事の仕事の流れと質問例は、架空の修理受付に合わせた説明です。具体例と追問の考え方を原典で読む

普段と違う依頼・手戻りをどう聞く？

通常の一件を理解したら、進め方が変わる条件を聞きます。受付であれば、機器の状態を十分に聞けない、折返しの連絡がつかない、渡した後に依頼内容が変わる、といった場面が質問の候補です。これらが実際に起きているかどうかも、これから確認することです。

「例外はありますか」だけで終えず、「普段の順番で進められなかった直近の依頼はありましたか」と尋ねます。その説明から、何が足りず、誰が気付き、どこへ戻し、何が分かってから再開したかをたどります。相手が思い出せなければ、無理に事例を作らず、資料の確認や別の担当への照会が必要と残します。

急ぎの依頼について聞くときも、「急ぎなら誰でも順番を変えてよい」とはしません。急ぎと判断する条件、変えてよい人、次の担当への伝え方を分けて聞きます。現場の工夫が社内の正式なルールなのか、その人が補っているやり方なのかも確かめます。

件数や時間の話が出たら、対象期間、数えた依頼、根拠の資料が分かるかを確かめます。「よく起きる」「少し待つ」という表現を、そのまま件数や処理時間へ置き換えません。数字を得られなくても、どの条件で困るかと、次に何を調べるかは整理できます。

二つの担当の話を、確認した範囲ごとに並べる

受付担当には「電話で何を聞き、誰へ渡すか」、現場調整担当には「訪問予定をどう決め、変更をどう伝えるか」を尋ねます。別々の仕事について、受け取る情報、判断、次へ渡す内容を同じ項目で比べます。困りごとは聞き取り前の想定で、本人の発言や実作業として確認した内容ではありません。

次は、同じ架空会社の受付担当と現場調整担当へ、何を聞くかを並べた例です。面談を実施した記録ではありません。受付の説明を直した結果として、現場調整の例を置いているわけでもありません。別の担当・別の仕事として読み比べてください。

受付では、電話から受付表へ写して渡す場面を、現場調整では、受け取った依頼から訪問候補を返す場面を確かめます。どちらも実際の本人発言、作業の観察、要求承認、追問担当は未確認です。説明用の作業想定を、確認済みの現状へ格上げしません。

実際の面談では、対象の仕事、聞いた相手と役割、日付、参照した資料と版、記録を見直す人を結びます。詳しい発言を全部書けない場合も、判断条件や、後で確認が必要な言葉を見失わないようにします。聞き取りと記録を同時に進めにくければ、参加者に説明したうえで、聞く役と記録する役を分けられるか検討します。人数を固定する必要はありません。

発言・観察・こちらの案・未確認を分ける

面談中の記録は、何を根拠に書いたかを分けておくと、後で要求へ移すときに混乱しにくくなります。相手が話したこと、自分が見たこと、自分の解釈、実現方法の提案を、同じ確かさの情報として並べないようにします。

例えば「受付表が埋まっていない」という話だけでは、入力忘れ、電話で聞けなかった、調整担当が後から補う項目などの違いが分かりません。「すべて必須入力にする」と先に決めず、どの項目が、いつまでに、誰の判断で必要かを追問します。本人の説明を誤解していないか、その場で短く言い換えて確かめる方法もあります。

GOV.UKの記録の指針は、観察したことと個人の解釈を分ける考え方を示しています。録音・写真・複写は、仕事の理解に必要な範囲と許可された方法を選びます。この原典から、特定の録音サービスや保存期間を必須にはしません。記録と観察の区別を原典で読む

分からない話や、担当同士の違いをどう扱う？

その場で問い返すか、後で確認するかは、話を理解するために必要な情報かどうかで考えます。仕事の対象や、前後の受け渡しが分からないままでは、その後の説明も誤って捉えるため、短い確認を挟みます。「ここでいう受付完了は、表に写した時点ですか。それとも調整担当へ渡した時点ですか」のように、言葉の範囲を揃えます。

一方、その人が知らないシステムの処理や、別の責任者が決める条件は、その場で無理に答えてもらいません。「何が未確認か」「誰なら答えられそうか」「何を見れば確かめられるか」を残し、追問する人を後から決めます。この記事の架空例では、その担当も未確認のままです。

受付は「渡したら完了」、現場調整は「不足情報が揃ってから着手」と考えているかもしれません。実際にそうかは双方へ確かめ、同じ一件で渡す情報、受け取ったとする条件、戻す相手を比べます。食い違いを隠して一つの綺麗な手順にせず、どの条件で説明が違ったかを残します。

管理者と担当者が同席すると話しにくい内容や、顧客情報を含む資料がある場合は、話せる範囲と参加方法を調整します。話せない部分を「問題なし」と扱わず、許可された資料や別の確認方法で補えるかを検討します。聞き取りができた範囲だけで、利用者全員を代表する結論を出さないようにします。

面談後、理解を確認してから要求へつなぐ

面談後は、記憶だけで整えず、元の記録と資料を見て、仕事の順番と残る問いをまとめます。本人へは、「この理解で合っていますか」と、対象の作業、判断、受け渡しを具体的に確かめます。返答がない箇所を、暗黙の承認として確定しません。

現状の説明から、望む結果を取り出す

例えば、情報が不足した依頼をどう扱うかを確かめた後なら、「情報が揃わないときも受付の状態と残る確認を担当者が分かるようにしたい」といった要求の候補を整理できます。ただし、これはこの記事の検討例です。架空の面談で本人が述べた要求や、承認された仕様ではありません。どの不足情報を扱うか、誰が状態を変えられるか、後工程が何を受け取るかは、関係者への確認が必要です。

次に、要求の候補が誰の困りごとを解くか、通常と例外のどこに効くか、実際の仕事を変えてよいかを業務責任者と相談します。「通知を増やす」という方法の案とは分け、別の方法でも必要な結果を満たせるかを考えます。採用・保留・追加調査の扱いと、その判断をする人が分かる形にします。

回答が来たら、元の問いと記録を更新する

未回答の問いには、対象、確認先、確認する人、次に扱う機会を決めます。担当が決まっていなければ、その事実を残して責任者へ相談します。日程を自分だけで約束したり、確認先を名前だけ書いて依頼済みにしたりしません。

新しい回答や資料が来たら、どの問いが解け、現状の理解や要求候補をどう直したかがたどれるようにします。影響する担当へ再度確かめ、資料の版を揃えます。一度聞いてまとめたことで完了ではなく、その理解で次の検討へ進めるかを確かめます。

機能の合否を確かめる条件を具体化する段階は、要件定義の受入条件で扱っています。依頼資料・開発会社への質問・提案評価の作業順は、システム開発の発注準備へつなぎます。本稿では、その前提になる、現場の話を聞き、理解と残る問いを整理する仕事を扱いました。

まとめ：一つの仕事を、本人の説明でたどる

利用者ヒアリングで最初に揃えるのは、作りたい画面の一覧より、対象の仕事と困る条件です。実際に作業する人へ、最近の一件のきっかけ、受け取る情報、作業、判断、次へ渡す結果を順に聞きます。普段と違う依頼や戻る場面も確かめると、必要な条件と残る問いを分けやすくなります。

記録では、本人の発言、見た作業、こちらの解釈や提案、未確認を区別します。面談後に本人へ理解を戻し、業務責任者と要求候補・保留・追加確認を整理してから、次の検討へ進めます。聞いたという事実を、要求の承認や開発の完了と同じに扱わないことが大切です。