手戻りしない業務ヒアリングのコツ～基礎編～
はじめに
業務をヒアリングしてマニュアルを作って業務をやってみたけど、全然できなくて困ったわ！そんな人たちに向けて本記事を書いています。
本記事において業務ヒアリングは、現在運用されている何かしらの業務を引き継ぐ、外注したいなど様々な目的に応じて、業務を手順化し誰かに運用してもらうことと定義します。（ざっくりとした業務の流れを可視化したいなどの目的もあると思いますが、そこは今回対象外とします）
本記事に書いていること
・業務ヒアリングの基本的なステップと各ステップにおいて重要となるポイント ※各ステップの詳細は気が向いたら追記します。
本記事の目的
・マニュアルの体裁は整っているが中身が薄く、業務が運用できない手順書を減らしたい。
本記事における業務の定義
・何かしらのインプットを受領し、それを加工して、何かしらのアウトプットを作成する一連の流れのひとまとまりを指します。
・業務は、非定型ではなく定型の業務で、定常的に実行されるものを指します。（日次、週次、月次、年次など）
例：通勤費認定、経費審査、営業数値ダッシュボード運用、業務カテゴリマスタ更新などなど
ヒアリングステップ
大きく分けると以下の3つとなります。
1.事前準備・・ヒアリングの前段階でするべきこと
2.ヒアリング・・ヒアリング当日の開始～終了にするべきこと
3.ヒアリング纏め・・ヒアリング終了後にするべきこと
1.事前準備
この段階で重要なことは「ヒアリング当日までに事前に関連する資料をできるだけ見ておく」ことです。
現在運用に使用している手順書、業務フロー、用語集、ルール、規定など、もらえるものは全てもらえるようにしましょう。業務が属人化されていて、そういった手順書がないケースもありますが、完璧に揃える必要はありません。（現行の手順書がなくても絶望する必要はありません）
資料を受領後は、それを読み込んで全体感を把握することが目的です。当然ながら、この段階でわからない点など腐るほど出てくると思いますが、それをエクセル等でメモしておきましょう。
メモする粒度は「〇〇って単語の意味はなに」などのレベルで構いません。（このメモを作る上での必要な観点やコツは別途記事を書くつもりです）
2.ヒアリング
ここまでで受領した資料があれば、ある程度業務が想像ができている状態です。この状態でヒアリングに臨みます。（繰り返しますが、業務が属人化しておりマニュアルなんてねーよって時もあると思いますが、それでも全然大丈夫です）
＜ヒアリングの形式＞
ヒアリング実施において一番重要なこと、それは相手に
「実演形式で業務を目の前でやってもらいながら説明をしてもらい、それに対して質疑を重ねる」
これの一択です。
最初のヒアリングの段階で、実演せずに相手が業務フローを使って、詳細の手順を口頭のみで相手に説明する方法がありますが、これでは抜け漏れが多く、最終的に中途半端な業務フロー・マニュアルが完成し、それを運用する人が困ることになります。
なぜこうなるのかというと、プロセスを聞いて理解した気分になってしまい手順を聞き切れない状態になるからです。
例えば、料理を全くやったことない人に卵焼きの作り方を教えるとします。
＊＊＊＊＊＊まず、たまごは3個使います。それを混ぜたあとに、油を入れて、フライパンが温まったら、4分の1ぐらい卵を入れて、巻いていきます。あとはそれの繰り返しです＊＊＊＊＊＊
この説明で、料理をしたことがある人ならある程度できるでしょう。ただ料理をしたことがない人が聞いたらどうなるでしょうか。
たまごのサイズいろいろあるけどどれでも3個？、混ぜるってどれぐらい混ぜるの？具体的な回数は、てか何を使って混ぜるのがよいのだろうか。
油はどれぐらいいれるの？フライパンが温まるって、何で判断するの？
巻いていきますって言われてもさ・・なんとなくイメージは沸くけどさ。
あとは繰り返しって言われてもわかんねーよ。
ってなると思います。つまり、最初の説明だとざっくりとしたプロセス（というか手順）に留まっており、詳細な手順がないのです。
いつ、どこで、なんの情報をどんな状態に加工するべきなのか、一つひとつの手順のゴールを明確にイメージする必要があります。
卵焼きの例だときっと、こんな説明よりもユーチューブの料理動画を見たほうが100倍わかるでしょう。
それが＝実演形式なのです。
実演形式では、相手に実際の画面、ツール、ファイル、格納フォルダなどを直接操作してもらって、ステップバイステップでその業務を始まりから終わりまで全て実演してもらうことが必要です。
どれぐらい細かく説明してもらうのかというと、「まずはここのフォルダのこのファイルを開きます」といった作業の最小単位での実演です。
そのため、ヒアリング担当者は、事前に実演形式で説明してもらうように依頼しておくのが良いでしょう。また、後からほぼ100％抜け漏れが発生するため、後から見返せるように動画で記録しておく準備もしてください。（相手に許可をもらう）
＜ヒアリング時の質問方法＞
実演が始まったら、どのように質疑をしていけばいいかというと、基本的なスタンスとして「わからないところがあったら、都度立ち止まって質問を重ねる」ことが重要です。
つまり、一通り説明が終わったらまとめて質問するのではなく、「逐一説明を止めて聞く」ということです。例えば、あるファイルが開かれた状態で、実演が始まったら、「それってどこに普段格納されているのでしょうか」といった具合です。
相手は業務に慣れており、こちらがどこまで知っていて、だからこんな説明をしようと準備をしっかりして臨むケースは少ないため、その業務特有の単語をそのまま話したり、これは説明しなくてもいいかと悪気なく勝手に省略して説明します。
そのため、単に説明を聞いているだけだと大量の抜け漏れが発生します。（説明している本人はきちんと説明しているつもりでいるケースが非常に多いです）
更に、ヒアリング担当者は、慣れていない業務の知らない単語のオンパレードの説明を一気に受けるので、聞き取るだけでも精一杯です。説明が終わったあとにまとめて聞くと、聞こうと思っていたことの半分も聞けなかったという事態に陥るという点も考慮に入れておくべきです。
＜ヒアリング時の質問のレベル感＞
事前に資料を受領しているケースや、相手から業務ヒアリングのプロとして見られているケースなどにおいて、「どこまでレベルの低い質問をして良いのか」という質問がよくありますが、回答としては「自分が知らないことは、どんな些細な事でもレベル感とか無視して聞くべき」です。
事前の資料に書いてあったかもしれないから、ヒアリングが終わったら自分で資料を読んで理解しようとするのは絶対にNGです。「その場で聞き切ること」が重要です。質問をすることで相手にどう思われるかは気にしなくて良いです。
その思えるようになったきっかけの一つが、私の後輩が担当していたプロジェクトでのある事件です。そのプロジェクトでは、相手からその領域のプロとして見られており、ヒアリング時に相手の担当者の他に偉い人が毎回出席していました。
結果として、ヒアリング時に「これを聞いたらまずいかな、良いかな、こんなのもわからないんですかとか言われないかな」などいちいち躊躇・判断してしまい、結果として細かいところが聞けておらず、マニュアル作成時に再度ヒアリングを重ねることになりました。（工数が約2倍に膨らみました）
これを回避するために、ヒアリング担当者側から相手に「業務ヒアリングでは、皆さんにとっては当たり前のことを聞くかもしれませんが、それにより、後工程のマニュアル作成や運用後の業務改善に繋がるため、質問させていただきます」と一言入れると良いでしょう。
＜ヒアリング時の質問の観点＞
「実演形式」「逐一止めて質問」が基本的に大きく外さない方法ですが、質問の仕方にはコツがあります。結論としては、「5W1HとSIPOCの観点を持って質問をする」ですが詳細はまた別の記事で書く予定です。
＜ヒアリング時に聞くべきこと＞
実例を挙げると切りがありませんが、重要なポイントは以下となります。
■業務/作業の目的意義
実演するとよくあるのが、作業のステップは理解したけれど、なぜその作業が必要なのか、そもそもなぜその業務が必要なのかを聞かずに単なる作業としてヒアリングしてしまうケースが非常に多いです。
理解しないまま進めた場合、ちょっとしたイレギュラーの発生や、手順を間違えて集計が間違った場合にリカバリーできないことが多いです。少しでも手順から外れると途端に品質担保が難しくなるということです。
また、どこが無駄なのかを本質的に理解していないため、後に業務改善に取り組む際、どこをどうするのが工数削減に寄与するのか適切な判断ができません。
その作業がなんの目的で行われているのか、システムの仕様だから仕方なくやっているのか、前任者がなんとなくやっていたから特に気にしなくてよいものなのか、納品物の品質を担保するために絶対に必要な手順なのか理解することが重要です。
■作業の条件分岐
条件分岐というのは、「この項目の値が100以上だったらOK、100未満だったらNG」といった判定条件を必ず記載しましょうということです。残念な手順としてよくあるのが、「データを貼り付ける」だけ書いてあって、データがどのような状態なら次のステップに進むべきかの記載がないことです。
OKケースのみ書いてあって、NGケースの場合のアクションが書かれていないことも多いため、注意が必要です。
例えば「〇〇フォルダに格納されているファイルを開く」といった一見よさそうな手順ですが、ファイル名の日付がいつなら正しいと言えるのか、そもそも、そのフォルダにファイルが確実に毎月格納されているのか、ファイルがフォルダに存在しない場合は誰にどのようにエスカレーションすればよいのかなどが情報として漏れるなどです。
■曖昧な表現
条件分岐と近い話ですが、「データを確認する」「資料参照して転記する」などの表現で説明された場面は注意が必要です。
例えば「金額を確認する」といった説明があった場合、その金額はどの項目に関連しているのか、それをどこかと比較して正誤判定するのかしないのか、値が単に入っていればいいのかなど・・・
自分が業務を運用する立場に立つと気になることが多すぎます。このような曖昧な説明をされた場合は迷わず、具体的に聞くようにしましょう。
■業務の開始日・対応期間・納期
これだけで一記事書けそうなので詳細は割愛しますが、ひとまず重要なポイントのみお伝えすると、質問する項目としては、業務の開始日・終了日だけではなく、以下を可視化する必要があります。
業務を開始できる日
実際に業務を開始している日
実際に業務を完了している日
成果物が納品可能となる日
実際に成果物を納品している日
イメージは以下の通りです。
前月業務が締まってデータがシステムに反映されるのが第一週の第一営業日だから、そこから業務は開始可能である。
第一週目の第一営業日以降、業務を開始できるが実際に開始しているのは第二週の水曜日。
第二週目の水曜日から始めて、その週の金曜日の15時には業務が終わる。
第三週目の月曜日からシステムに納品物となるデータがアップロード可能となる。
三週目の金曜日に他の業務の納品物と共にアップロードしている。
…3と5だけで良くない?と思いがちですが、1〜5の考え方が必要です。単発の小さい業務で工数が非常に小さい場合は別ですが、複数の業務を引き継ぐ場合は、それぞれのスケジュールを考慮し、効率的に業務を進めるためにはこれらの可視化が必要です。
また、何かイレギュラー対応が起こった場合に、いつまでなら業務の納品を遅らせることができるのかといった判断やインプットデータを受領が遅延した場合にいつリマインドするのかなどにも役立ちます。
3.ヒアリング纏め
まず、ヒアリングした後の整理は当日中に行うようにしてください。最悪翌日までに行うべきですが、それ以降になると忘れている率が格段に高くなります。
ヒアリング時は、聞くこと・理解すること・質問することに全集中しているため、おそらくメモが雑な状態だと思います。（人は複数のことを同時に高いクオリティで行うことは難しいです）それを見返しながら、業務の流れに問題がないか、抜け漏れがないか、細かく確認します。
この時点では、手順にタイトルやサブタイトルをつけるような体裁を整えることはしなくて良いです。後でどうせ直すので。
メモと共に、受領資料や録画動画（1.5倍～2倍速で）を確認し、曖昧なメモの部分は補記するなどしてください。このヒアリング後の整理のゴールは、「ヒアリングメモを見ながら時間をかけても自分が業務を実行できそうかどうか」です。これがYESでない場合も多々ありますが、どこがわからないかを書き残しておくことが必要です。
もう少し具体的な話を書きたいところですが、まずは概要の理解ということでご容赦ください。
まとめ
業務ヒアリングは「実演形式でやってもらう」「逐一止めて質問する」を達成すれば、大きく外すことはない。
些細なこともでも聞く。質問のレベル感は問わない。
ヒアリング時の質問は5W1H、SIPOCの観点を持って質問する。
質問内容は大きく分けて4つ、相手から説明を受けつつ、業務/作業の目的意義 作業の条件分岐 曖昧な表現 業務の開始日・対応期間・納期を漏らさずに聞く。
ヒアリングのまとめは遅くとも翌日中に済ませること。
業務ヒアリングの精度が低いと、その後の工程で作成するマニュアルの品質も悪くなり、マニュアルを基にした運用も困難になります。「たかがヒアリング」と思わず、重要性を認識してください。業務ヒアリングは非常に難しいですが、その分だけ価値があります。
それでは、また。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？