はじめに
プロダクト開発エンジニアとなって早10数年、いくつかのプロダクトに関わってきました。
しかし私が開発をしてきた／今しているサービスの背景にある業務を、私自身、これまで実際に経験したことはありません。
それでも製品や機能は作らなければいけません。
そのためにその業務を実際にどのように行っていて、どういった点に困っているのかを、実際の業務担当者に聴ける機会は非常に貴重で、大切にしたいと思っています。
・・・と偉そうに書きましたが、私はそこまでユーザーヒアリングの経験が多いわけではありません。
残念ながら、頻度もそこまで高くありません。
それがゆえに、ヒアリング時に気にすべきポイント、ともすると思考から外れてしまいがちなポイントを、ヒアリングの都度思い出している状態です。
それはよくない。絶対に零れ落ちる観点がある。
というわけで、私自身の備忘の意味を込めて列挙してきます。
なお、これ以降記載する内容は、私自身のあまり多くない経験則や、先輩や同僚からのアドバイスを元にした、あくまで n = 1 のお話です。
ユーザーヒアリングの目的は数多くあると思いますが、私が経験したもののみ記載します。
お忙しい方は、目次だけさらっと読んでいただくとよいかなと思います。
前提
- 大企業向けの基幹業務パッケージシステムを自社開発している会社でのお話です
- 個々のヒアリング内容をベースに、パッケージシステムとして汎化させる必要があります
- 中でも、勤怠管理システム開発者としてのヒアリング経験に基づくものがほとんどです
目次
そのヒアリング、目的は？
これまでのところ、プロダクト開発をしていてヒアリングを実施する目的は大きく4つあっまと感じます。
それぞれはMECEかというと全くそんなことはなく、ゆるやかに重複しています。また、私が経験したことのない目的でのヒアリングに関しては割愛しています。
シンプルに業務を知るため
これから自分が向き合っていく業務について教えてもらうのが主な目的です。
はじめにに書いたとおり、携わるすべてのサービスのターゲット業務を実際にやったことがある人は稀だと思います。それでもサービスを育てていかなければいけません。
その状況の中、自分が携わるサービスの向こうにある業務を、実際に見聞きさせてもらうというのは得難い体験です。
もちろんすでにチームに蓄積されている業務知識を辿ったり、チームの先輩からターゲットの業界や業種、業務についての話を聴くことで業務を知ることはできます。
しかし、やはり百聞は一見に如かず。実際にユーザーに業務を見せてもらったり内容を聞かせてもらったりすることで、その業務がしっかりと腑に落ちる感覚があります。
新機能の開発に向けた潜在ニーズの発掘のため
プロダクトとして搭載すべき機能を考えていくにあたり、ターゲット層のユーザーにターゲット業務の内容やその際に考えていることなどをヒアリングすることが主な目的です。
自社製品に機能を搭載できていないがゆえに、業務担当者の頭の中に業務内容が存在している可能性があります。その場合、その担当者に1つ1つやっていることを解説してもらいます。
エクセルなどを駆使して"がんばって"しまっていたり、その業務のみ他社製品を導入していたり、アドオン開発していたりする場合があります。その場合、そのエクセルファイルや他社製品などを利用してどのような業務を行っているのかヒアリングします。
既存機能への機能強化のため
新たに自社製品の導入を検討いただく中での要望や、現在サービスをご利用中のユーザーからの要望をきっかけに、既存サービスへの機能強化をすることは多くあります。
このとき、ユーザー要望と機能強化の内容にずれが生じないよう、ヒアリングを行います。
またこの場合、具体的にどのような機能にする必要がありそうかを考えるのと同時に、以下の点を明確にする必要があります。
- その機能がないことで何が起こっているのか？
- いつまでにないと困るのか？
既存機能のリニューアルのため
さまざまな理由で、現在進行形でご利用いただいている自社製品の機能をリニューアルしたり、新機能への移行が必要な場合があります。
リニューアル先の機能を作るにあたり、現行機能をどのような使い方をしていて、どのように業務に利用しているのかを確認するのが目的です。
ヒアリングするのはどんな立場の人？
ヒアリングの目的や内容が決まっている場合、「今回ヒアリングしたい人は誰なのか？」をあらかじめ明らかにし、ヒアリング対象者を探すべきです。
ヒアリングできる人が誰かによって、ヒアリングしたい内容の方向性と深さが変わるからです。
「ユーザー」とまとめるのは簡単だけれど
直接ユーザー1にヒアリング可能な場合、どういった役割の方にヒアリングできるのかは必ず確認します。
「ユーザー」と一言で言っても、弊社のようなシステム会社とやり取りをする人、システムのメンテナンスをする人、実際に使う人が全員異なる、ということはよくあるからです。
たとえば勤怠管理システムの場合、システムをメンテナンスする人は情報システム部、システムに登録すべき内容を把握している人は労務部、システムを実際に使う人は一般従業員です。
ただし、同じ勤怠管理システムでも、シフト管理の場合は、システムに登録すべき内容を把握しているのは現場部門を統括する店舗運営部のような部署だったり、現場の店長に直接聞かなければわからない、ということもあります。
「一般従業員」も一括りにしましたが、ヒアリングしたい対象業務次第では、場合によって「一般従業員」の幅がかなり限定されます。
打刻業務であれば企業で働く従業員のほとんどが行っていることが多いので、かなりターゲット層は広めです。2
しかしシフト管理業務であれば、シフト制を敷いている業種業態に限定されます。
シフト管理の中でも、シフトを組むこと自体のヒアリングをしたいのであれば店舗などでシフトを組んでいる店長やリーダーのようなポジションの方に聞くのがよいですし、
アルバイトスタッフの勤務時間を店舗単位で予実比較するような業務について確認したいのであれば、複数店舗を束ねるスーパーバイザーのような立場の方に聞くのがよいです。
フロント部門の同僚
弊社の場合、開発とユーザーの間には基本的にフロント部門（主にコンサル）が入ります。
コンサルがユーザーの状況を深く把握している場合、ヒアリング相手はそのユーザーの担当コンサル、ということもよくあります。
フロント部門の同僚は、ユーザーの業務を直接実施しているわけではないものの、日々ユーザーと直接話して、悩みポイントの細部のニュアンスまで熟知していることもしばしばです。特定のユーザーの困りごとをしっかりと理解したうえで、咀嚼して開発者に伝えてくれることもあります。
社内なので調整も比較的容易なので、ヒアリング内容によってはフロント部門の同僚から間接ヒアリングさせてもらうのもアリです。
（余談）ヒアリング相手の見つけ方
扱っている製品がBtoBのパッケージシステムであるという性質上、特にシンプルに業務を知りたい場合と、新機能の潜在ニーズをヒアリングしたい場合、ヒアリング可能な相手を見つけるのには苦労します。
ターゲット業務、ターゲットユーザー層からヒアリングしたいユーザーを選定し担当コンサルに個別で依頼する
明確なターゲットがある場合、そこに合致するユーザーを絞り込んで担当コンサルに直接相談に行くのが1番です。
フロント部門に広くヒアリングをしたいという意思表示をする
「XXXという理由でユーザーヒアリングを実施したいです、協力してもらえるユーザーがいれば教えてください」という発信をフロント部門（コンサル）向けにしておくと、ヒアリングなどに積極的なユーザーの担当コンサルから連絡がもらえる場合があります。
同僚、知人友人にヒアリング相手がいないかアンテナを張っておく
ターゲット業務の内容を知りたいという目的であれば、必ずしもユーザーである必要はありません。
社内の同僚や知人友人に有識者がいるかもしれませんし、新たに入社してきた同僚が有識者かもしれません。
入社していた人のことはすぐにはわからないよ・・・という方も多いかもしれませんが、幸い弊社は大学時代/前職でやっていたことを含んだ自己紹介が入社後ほどなくして全社向けに回ってくるので、私はそれを具に確認しています。
そしてその中に「前職では某飲食チェーンで店長をしていました」などの書き込みを見かけたら、その方にSlackのDMで突撃しています。
ヒアリング以外の手法を採る：過去の問い合わせに一通り目を通す
過去に寄せられたユーザーからの問い合わせに対していくつかのキーワードで検索をかけ、過去に要望に近い内容の問い合わせがないかを探します。
検索ワードによっては膨大な数の問い合わせがヒットしてしまう＆あくまで現行機能ベースでの問い合わせになるので諸刃の剣ですが、まれに「弊社ではXXXという業務を実施しているため、○○○ができると助かる」というようなやりとりを発見できることがあります。
現行機能への機能強化をする際には割と有効です。
ヒアリング時のお作法は？
ヒアリングにもいくつかパターンがあるとはいえ、気を付けるべき点はある程度共通しています。
可能な限り実際に業務をしている様子を見せてもらう
業務内容を直接見せてもらうことはとても重要です。
担当者が業務を行うために使っているモノを実際に動かしてもらいましょう。
説明する側としても、たとえ普段やっている業務であっても、思い起こしながら説明するより実際にモノを動かしながらの方が断然説明しやすいです。
また、目の前に実物がないと、どうしても補正をかけながら回答してしまうことは起こり得ます。
実物を見ながらだと「たとえばここにこういう情報が出てたらこの業務捗りますか？」みたいな話を発展させやすいです。
今説明してもらっている個所以外でも、気になる部分が出てきたりします。そういった箇所も質問させてもらえます。
最近はWebミーティングが増えてきましたが、選択できるのであれば、ユーザー先に訪問させてもらうのをおすすめします。
会社の立地やたたずまいから始まり、オフィスに掲示されているポスター、従業員同士が会話する際の雰囲気、従業員の方々が利用しているパソコンの種類などなど、「ああ、この人たちはこういう場所で、こういう機器を利用して、うちの製品を使ってくれているんだな・・・」ということを、身をもって知ることができます。
「答え合わせの場」として臨む
たとえ業務内容がわからなかったとしても、わからないので全部教えてください！は絶対にやめましょう。
業務経験がなくても、書籍やネットで調べることはできますし、想像してみることはできます。
- なぜその業務が必要なのか？
- どんな人が、いつ行う業務なのか？
- 何かの法令に基づいているのか？
- 法令がないとすれば、社内規程で定まっているのか？慣習？
- 実際に業務を実施する場合、どういう手順を踏むんだろう？
- ここはコミュニケーションで補っていそうだな
- この業務をするためにこの機能を使うとしたら、ここは使いやすいのだろうか？
などなど、ヒアリングの前に、必ずヒアリング対象の業務内容を想像してから臨みましょう。
仮説を立てたうえでヒアリング内で答え合わせをすることで、よりヒアリング対象の業務への解像度が上がります。
仮説が正しいかはヒアリング相手に必ず確認する
ヒアリングを通じて「あ、きっとこの機能はこの業務をこうやる必要があるからこう使うんだろうな」と予測できることはありますが、それは自分の仮説の域を出ません。
ヒアリング相手にそれで合ってますよね？をちゃんと確認しましょう。
事前にヒアリングシートを送付し、できる限り一次回答をもらう
事前にヒアリングシートを送付し、一次回答をもらえるよう打診することを強くおすすめします。
ヒアリング時間は限られています。
一問一答で答えてもらえるような内容はあらかじめ明らかにした上で、追加の質問や実際の業務を見学しながら生まれる疑問、ユーザーとの会話から生まれる疑問を解消する場にすることで、ヒアリングの時間をより密度の濃いものにできます。
また、ヒアリングされる側も、ヒアリングシートを見た上でどんなメンバーをヒアリングの場に呼ぶべきかを考えて調整してくれることがあります。
ヒアリングシートにはこちらが想定する回答を記載する
ヒアリングシートを作成する場合、ただ質問内容を記載するだけでなく、想定する回答を併記するといいです。
ヒアリングを答え合わせの場にすると重複しますが、想定する回答を書くためには、ヒアリング相手の業務を想定しなければいけません。
回答をもらった際の解像度を上げるという意味で、想定しておくのはとても重要です。
また、これはあくまで想像ですが、ヒアリングシートを受けとった側としても、「このヒアリングシートを送ってきた人は多少なりとも業務について考えてくれているんだな」と思ってくれている・・・と思います。
ヒアリングシートの回答者が質問の意図をくみ取れない場合、想定する回答から意図をくみ取ってもらえる可能性もあります。
ヒアリング当日はヒアリングシートに頼りすぎない
一方で、ヒアリング当日はヒアリングシートに頼りすぎないようにできるとよいです。
ヒアリングシートを使うと「ヒアリングシートを消化しなくちゃ」という気持ちが無意識に起こってしまったり、一問一答になってしまったり、ヒアリングシートとだけにらめっこしておしまい、などとなってしまいがちです。
当日はヒアリングシートはヒアリングを進めるためのアジェンダ程度にとどめるのがよいです。
ヒアリング相手の話をよく聴き、内容がわからなければ遠慮なく追加質問したり、実際に使っている資料やツールを見せてもらったり、回答を受けて自分なりに咀嚼した内容をヒアリング相手に聴いてもらい、認識があっているかを確認したりなど、その場を掘り下げる内容にしましょう。
（既存機能がある場合）機能でやりたいことではなく、やりたい業務の話を聞く
機能が絡んでくるヒアリングの場合、ともすると今使っている機能ベースの要望（「今はこういうことができるから同じようにしてほしいな～」）や、今使っている機能への要望（「この画面のここからこういう情報が見たいな～」）に偏りがちです。
もちろんそういった観点も大事ですが、そればかり聴いて終わってしまうのはもったいないです。ユーザーは業務の専門家であって、機能を作る専門家ではないからです。
なぜそう考えているか、理由や背景となる業務内容をユーザーに聴いた方がよいです。
それらの回答によっては、たしかにそうだと納得できるかもしれませんし、別の表現方法の方がより深くニーズに応えられる可能性があります。
たとえばシフト作成機能に対して、「シフト表上で、従業員の情報をある程度表示させたいんだけど」という要望を受けたとします。シフト作成機能はパソコンのWebブラウザ経由でアクセスする機能とします。
※③：筆者、ユ：ユーザー
③「個人情報、具体的にどんなものを見たいんですか？」
ユ「住所、電話番号、メールアドレスがとりあえずほしいです」
③「たとえば住所はどんなときに使うんですか？」
ユ「他店舗からヘルプ要請が来たときに、比較的近所に住む人から打診をかけたいんですよね」
③「比較的近隣店舗からのヘルプ要請が多いですか？住所だけ見て近さがわかるものでしょうか？」
ユ「大体同一区内からが多いかな。住所見てわかるところもあればわからないところもあるけど、逆にわからないということはちょっと遠いということだから」
③「なるほど。では、電話番号は住所を確認したうえで電話をかける際に利用しますかね？」
ユ「そうですね、それもあります。あとは自店舗で急に欠員が出たときにも利用しますし、まあ遅刻とか無断欠勤とかもなくはないので、そういうときにぱっと電話できたらいいかなって」
③「ちなみに、社用携帯などの電話帳に従業員の連絡先を登録しておく、では不足しそうでしょうか？」
ユ「あーたしかに電話番号はそれで事足りるかもしれませんね。メールアドレスもそれでいいかもしれません」
ちょっと極端な例ですが、最初にあった要望とは少し異なる機能の形になりそうだなというのは想像がつきます。
（機能の移行やリニューアルの場合）今やっていることベース＋本来やりたいことを整理する
特に他社製品からの移行や自プロダクトの機能のリニューアルの場合、以下を意識してヒアリングする必要があります。
- 今できていることは何か？
- なぜそれをやる必要があるか？
- なぜこれまで通りにできる必要があるのか？
- いらないものはあるか？
- もっとよくできるか？
機能のリニューアルの場合、サービス提供元である私たちの都合である場合も一定あります。
そのため、基本的には現行機能を通して今やっている運用や機能の利用方法を確認します。
現行機能がベースとなっているため、今やれていることができなくなってしまうのは避けなければいけないからです。
一方で、システム起因・ルール起因、いずれかの理由で形骸化している運用があれば、これを機にサービスやルールの見直しをするきっかけになります。
中には、リリース当初は利用されていたものの、時間が経つにつれて利用されなくなった機能なども存在します。
ユーザーも利用しておらず、開発担当としても機能の必要性や将来性を感じない場合、その機能は再実装しない、という選択をすることもあります。
自プロダクトで実現しなくてもよい箇所を探る
エンジニアをやっていると、ついつい今ある業務をすべてシステム化するよう努力してしまいますが、そんな必要はないと思っています。
業務を便利にするためのシステムなのに、そのシステムに流し込もうとすることで担当者の業務が増えてしまっては本末転倒です。
会社として厳密な管理を求めていない、ちょっとした業務ヘルプ依頼などは、わざわざ申請を挙げて、確認依頼を出して、承認して・・・とするよりも、コミュニケーションベースで「ちょっと1時間だけ手伝って！」「OK！」のやり取りで十分かもしれません。
たとえば勤怠の提出のリマインドであれば、以下の順で影響力が上がっていくのは感覚的にそりゃそうだと思います。
- 無機質なbotによる自動送信
- その先に人が見えるダイレクトメッセージ
- 担当者による電話
- 担当者が直接デスクまで来訪
「直接来訪」に代わる方法をシステムで実現！も命題の1つかもしれませんが、担当者は3や4の解決をシステムには求めていないかもしれません。
・・・という想定があったうえで、担当者から「電話までするのは本当に数人なので、そこは人力で十分で困ってないです」という言質がヒアリングで複数取れれば、たしかにこれはシステム化は不要だなと判断することができます。
ヒアリングの進め方
ここまでの内容を踏まえて、ヒアリングをしたいシーンが発生した場合のヒアリングの進め方を記載します。
- 事前準備
- ヒアリングしたい項目と想定回答を作成する
- ヒアリングの目的を相手に伝える
- 事前にヒアリングシートを送付し、できる限り一次回答をもらう
- （一次回答がもらえたら）当日のヒアリング内容を再構築し、先方に伝える
- 実際に業務で利用している資料やツールを見せてもらえるか確認する
- ヒアリング出席者、録音・録画可否を確認する
- 当日の流れをフロント部門のメンバーと確認する
- 当日
- ヒアリングシートはアジェンダにしつつ、その場で出た内容を掘り下げたり認識を合わせたりする
- 議事録担当を自分以外に依頼する
- ヒアリング終了後
- 議事録とTODO（あれば）をヒアリング相手に送付する
ヒアリング時に使えるかもしれない質問たち
- その機能を使ってどんなことをしていますか／したいですか？
- 誰がその機能を使いますか？
- その機能はどんなときに使いますか？
- 今の機能だとどんなところが便利だと思いますか？
- 後続業務はありますか？
- 関係者はどんな方々ですか？
- この業務のためにシステム外でのコミュニケーションはしていますか？
おわりに
要件定義を専門でやっているわけではないのできっと不足している観点があるとは思いますが、現時点で自分がまとめられる範囲でだいたい4つの目的と7つのお作法（とヒアリング対象者と当日の流れと大雑把な質問集）をまとめてみました。
将来の自分に加え、本記事をご覧になった方のどなたかの参考になれば幸いです～！
-
弊社の場合、「ユーザー」も大きく2つに分かれます。自プロダクトを利用してくれているユーザー／同じ製品群の他プロダクトのみ導入しているユーザーです。後者の場合、製品共通のコンセプトはご理解いただきつつ、個別の機能については知らないという状況であることを理解したうえでヒアリングに臨む必要があります。 ↩
-
「打刻」も一括りにしてしまいましたが、打刻方式も細かく分かれていくので、誰でもいいから聴ければOK、とはなりません。1人1台貸与されたパソコンでの打刻をするのはいわゆるホワイトカラーの人だけかもしれません。工場や店舗勤務の従業員の場合、勤務場所にある共用パソコンやタブレットを利用して打刻をするかもしれません。打刻機での打刻の可能性もあります。どの打刻形態に関するヒアリングをしたいのかで、ヒアリング対象者が限定されてきます。 ↩