業務システムにおけるUXリサーチのポイント

UXリサーチとは、ユーザー体験に関する調査の総称です。

ユーザーファーストのシステムやサービスを提供するためには、ユーザー体験からユーザーニーズを掴むUXリサーチは欠かせません。UXを重視する企業では、UXリサーチは積極的に行われています。UXリサーチについて言及した書籍も多く、ネット上には有益な記事が多数アップされています。

ただその一方、世に出回っているUXリサーチに関する解説の多くは、調査対象が生活者であることが前提です。

UXリサーチの総論は、対象が生活者であっても企業内のビジネスパーソンであっても変わりません。しかしながら、各論となる具体的な手法は、ターゲットなどの前提が変わると、そのまま使えません。

例えば、企業内で使われる業務システムやSaaSのUXリサーチは、生活者向けのUXリサーチとまったく同じというわけにはいきません。対象者が社内の限定的なユーザーとなる場合、インターネットリサーチのような手法は取れません。そもそも対象者が極端に少ないと、定量分析に適さないことも多いです。そのため業務システムでは、定性的なリサーチが中心となりがちですが、そのやり方や勘所も、生活者の場合とやや異なります。

今回は、業務システムの改善にずっと関わってきた私なりの、SaaSを含む業務システムを調査対象とする場合のUXリサーチついて、詳しく解説したいと思います。

ユーザーニーズとは

UXリサーチとは、ユーザー体験を理解することでユーザーニーズを発見するための手法です。業務システムの世界でこのUXリサーチがあまり浸透していないのは、ユーザーニーズという考え自体がそもそも浸透していないならでしょう。そこでまず、業務システムを前提とした場合のユーザーニーズについて、少し説明します。

顕在ニーズと潜在ニーズ

ユーザーニーズは、「顕在ニーズ」と「潜在ニーズ」の二種類に大きく分かれます。

顕在ニーズは、ユーザーが自覚しており、本人が口頭で説明できるニーズです。アンケートやインタビューも把握しやすいニーズです。一方の潜在ニーズは、ユーザーが意識しておらず、言語化しにくいニーズです。表面的な調査だけでは把握することが難しいです。

ハーバードビジネススクールのジェラルド・ザルトマン名誉教授は、自著である『How Customers Think』で、「人間の意識的活動は僅か5％で、残りの95％は無意識である」と述べています。

業務システムに限らない話ですが、5%の顕在ニーズに対応しているだけでは、本当にユーザーを満足させることは難しいでしょう。そしてUXリサーチにおいては、表面化していない、ユーザーの心の奥に潜む95％の潜在ニーズをいかに引き出すかが、重要なポイントになります。

業務システムのニーズの問題点

業務システムの開発は、大規模であればSIer、中小規模であればシステム開発会社が担当することがほとんどです。SIerやシステム開発会社の多くはウォーターフォール型の開発ワークフローを採用しており、プロジェクト序盤にある「要件定義フェーズ」の中で、考えられるユーザーニーズを想定した要件を整理します。ドキュメントとしては、「要件定義書」「機能要件定義一覧表」のようなものがそれに該当します。

しかし、SEやエンジニアが作成するこれら要件定義関連のドキュメントには、多くの場合、以下のような問題が含まれます。

(1)顕在ニーズしか考慮されていない

要件定義関連のドキュメントには、問題の解決手段や機能のみが書かれることがほとんどです。しかし、要件定義を担当するSEやエンジニアの多くはUXの専門家ではありません。適切なUXリサーチが行われず、表面的なニーズをなぞっただけの要件から設計～開発を行い、その結果、ユーザーニーズの95％に応えないシステムになってしまいます。

(2)ニーズの優先順位が加味されていない

ユーザーニーズが考慮されない要件定義では、主にコストや開発実現性で、開発の優先度を評価しがちです。しかし、このように開発側の都合で優先順位を決めると、当然ながら、実際にそのシステムを使うユーザーには不満の多いシステムになりやすいです。

このようなユーザー不在の要件定義によって発生する問題の解決に、UXリサーチは活用できます。

手順としては、比較的把握することが容易な顕在ニーズを調査した後に、それをヒントに潜在ニーズを探っていくと進め方が効率的です。顕在ニーズは「アンケート」で、潜在ニーズは「インタビュー」→「エスノグラフィ」の順に徐々に掘り下げていきます。そこで得られた仮説をもとに、より具体的な課題を把握するために、「ユーザーテスト」をするとよいでしょう。

ここから先は、このプロセスに従ってより詳細に解説していきます。

プロセス0：事前準備

業務システムは、生活者向けのシステムやアプリと異なり、業務プロセスやユーザー行動がマニュアルである程度定義されていることが多いです。そこでまずは、業務マニュアルなどから、おおまかな業務フローを整理していきます。

現状の業務フローの確認

業務マニュアルに業務フロー図が記載されていることもありますが、私の経験上、フロー図が実態と異なっていたり、書き方が抽象的すぎたりして、リサーチの事前情報としては役に立たないことも多いです。そのため、既存の業務フロー図は参考程度とし、実態を改めて整理することをオススメします。

業務量が多くて、全てを整理することが難しい場合は、改善の効果が見込まれる以下に的を絞って把握するといいでしょう。

• 顧客が課題に感じているフロー
• 利用頻度の高いフロー
• 業務ミスが許されないフロー

エンドユーザーと関係者の確認

ターゲット単独の行動で完結することが多い生活者向けの商材と異なり、業務システムは、様々な関係者との連携の中で使われることが多いです。そのためエンドユーザーだけに焦点を当てた調査だと、根本的なニーズや課題が見えてこないことも多いです。

そこで、業務フローの整理だけではなく、エンドユーザーの関係者も洗い出しましょう。例えば、ある金融機関の窓口業務で使われる業務システムを担当した際、エンドユーザーは窓口担当でしたが、業務プロセスを理解するためには、関係者にあたるバックヤードの事務担当、レビュー担当、営業担当へのヒアリングも必要でした。

また、より重要な課題に焦点を絞るための、どういう属性のユーザーをメインターゲットにするかを決めることも重要です。例えば先ほどの例であれば、同じ窓口業務担当であっても、都市部大型店舗 or 地方小型店舗、新人 or ベテランでセグメントし、リサーチ対象としての優先順位を決めていきました。

その他の情報の確認

メインターゲットを決めたら、現状の業務フロー図の各タスクに関連する「使うもの」を洗い出します。ここでいう「使うもの」の例は、電話、ファックス、紙書類、プリンター、他のシステム、メモ帳などが考えられます。

さらに、もし、要望・クレーム一覧などが存在するようであれば、業務フロー中の各ポイントに顕在ニーズを落とし込んでいきます。この時、仮説ベースでもいいので潜在ニーズを洗い出しておくと、UXリサーチの設計に役立ちます。

可能であれば、最後に可視化した業務フロー通りに対象システムを操作してみましょう。システムの課題がより明確になります。現状の業務フロー全体を把握できたら、UXリサーチを始めます。

プロセス1：アンケート

アンケートは定量的なUXリサーチ手法のひとつですが、インタビューやエスノグラフィーの調査対象者を選定するためにも用いられます。

サンプル数の考え方

一般的にアンケートは、サンプル数が十分にあることで初めて統計データとして活用できます。業務システムのユーザー数自体はそれほど多くありませんが、同じシステムで同じ業務を行っているユーザーが多く、アンケート結果に誤差が生じにくいため、サンプル数が少な目でも効果を得やすいです。

サンプル数の指標は諸説ありますが、サンプル数が30あれば、業務システムとしては有用なデータになるでしょう。もちろん、多いにこしたことはありませんが、ある程度の現実的な数で実施してしまうのがオススメです。

逆にシステムの利用ユーザーが少ない場合は、無理にアンケートを実施する必要はありません。その後のプロセスにおける調査対象者は、クライアントに指名してもらっても問題ありません。

アンケートの設計

アンケート実施が決まったら、まずアンケートの設計を行います。UXリサーチの目的を踏まえて質問を考えますが、対象者の絞込みのために、「業務の実施頻度」「想定される課題を本当に抱えているか」は必ず入れておきましょう。

また、「課題を抱えている業務上の関係者」への質問も用意します。業務システムでは、連携する関係者がボトルネックになるケースが多いからです。アンケートの時点でこれを明らかにしておけば、より的を絞ったインタビューやエスノグラフィが可能になります。

さらに、定量分析したい内容がある場合は、アンケートの質問に加えます。業務システムを対象とした場合は特に、改善効率化の効果を把握するための「実施人数」や「実施時間」に関する質問が重要になります。

より多くの対象者からアンケートを収集したい場合は、回答率を上げるために、10個程度を上限に選択式の質問にするとよいです。質問とセットで自由記述欄を設けておくと、質問に関連する業務課題を抽出できる可能性が高まります。

プロセス2：インタビュー

インタビューでは、既知の行動、発言、課題感などの顕在ニーズの裏にある、本質的な潜在ニーズを引き出します。例えば業務システムでのインタビューでは、以下のようなことを明らかにします。

• 開発者の思い込みと、ユーザーの本当の思いのギャップ
• システムだけではなく、業務フロー全体の正確な実態
• ニーズの優先度
• 人前で話せないこと（上司には言えないこと、従事者同士の関係性など）

インタビューの手法

まずは、アンケート結果を踏まえて、さらに詳しく話を聞きたいインタビューの対象者を選します。そして、企業規模や業務特性に合わせてインタビュー手法を決めます。代表的な手法は以下の通りです。

グループインタビュー

同じ属性の２名以上に対して同時にインタビューを行います。様々な視点の意見やニーズを短時間で得られます。ただし、周りのユーザーに無意識に同調するケースもあるため、個人としての真意を探りづらいというデメリットもあります。

デプスインタビュー

調査対象者とインタビュアーが１対１で長時間インタビューを行います。ニーズを探りやすいですが、複数人にインタビューをしないと偏った回答しか得られない可能性があります。少なくとも３名以上にインタビューすることをオススメします。

半構造化インタビュー

あらかじめ質問したい内容をおおまかに決めておき、回答によって、適宜質問の順序を組み替えたり、追加の質問をしたりしながらインタビューを行います。漏れなく、かつニーズをより深く探るのに効率的です。（これに対して、質問内容を完璧に決める「構造化インタビュー」、ほぼ決めない自由度の高い「非構造化インタビュー」があります）

一般的には、「デプスインタビュー＋半構造化インタビュー」または「グループインタビュー＋半構造化インタビュー」で行います。時間がとれるようであれば、同調のリスクがないデプスインタビューがオススメです。

インタビューの設計

インタビューの手法が決まったら、質問の内容を検討します。１回のインタビュー時間は60～90分で計画します。一般的なインタビューで行う以下のような質問は、業務システムでも同様にしておく必要があります。

• 想定フローで間違いないか？
• フロー前後の行動は？
• 毎日のゴールは？
• 一日のタスクの時間配分は？
• やりがい/モチベーションを感じる事は？
• 逆にプレッシャーを感じるタスク・苦労していることは？
• 苦労していることの現在の解決方法は？

特に、現場目線の「プレッシャーを感じるタスク・苦労していること」を、インタビューの時点で確実に把握しておきましょう。次に実施するエスノグラフィでは、観察観点が多岐に渡ります。重点的に観察するポイントとして課題のあるタスクを把握しておくと、次のエスノグラフィがやりやすくなります。

それ以外にも質問しておくといいのは「業務の学習の方法」や「業務を上手く回すためのコツ」です。業務システムでは、業務の初心者、ベテランというユーザー属性が必ず存在し、その差異を明らかにすることが業務効率化を実現する上でのポイントとなります。これらの質問を深堀りすれば、潜在ニーズに辿り着きやすくなります。

質問の仕方は、質問者側に都合の良い回答に誘導しないよう、以下の点に注意します。

• 誘導型、YES/NO型の質問はしない
• 抽象的な質問で自由な回答を促す
• １つの質問に２つ以上の要素を入れない
• ユーザーに何が必要かを聞かない
• 一般論ではなく実体験を聞きながら、その行動の根拠を探る

実体験から行動の根拠を探るコツ

特に重要なのは「一般論ではなく実体験を聞きながら、その行動の根拠を探る」ことです。例えば「業務ミスが多いこのタスクには、どのような課題がありますか？」と質問した場合、既に「要望・クレーム一覧」で挙がっている、分かりきった回答しか得られない可能性が高いです。

ここでは、「最近職場で起こった、このタスクの業務ミスは何ですか？ミスが発生した時、どういう行動を取りましたか？」と聞くと、具体的な回答が得られる可能性が高まります。「引継ぎ者に報告したつもりだったが、ちゃんと伝わっておらず対応が遅れた。その後は伝わったかをちゃんと引継者に確認するようにした」という詳細レベルの回答が得られれば、より業務の本質的な潜在ニーズが明確になってきます。

インタビュー実施時の体制

インタビューは、インタビュー担当とメモ担当の２名以上で行います。メモはユーザーが口にした事実をそのまま書き留めます。録音しておくとその後の整理がスムーズです。

また、なるべくシステム開発ベンダーの関係者（開発、営業など）を同席させましょう。開発側の思い込みとのギャップを間近に感じることで、開発フェーズがスムーズに進むことが多いです。

業務システムのインタビューは、クライアント先の会議室などの小さい部屋で行うことがほとんどですが、メモ担当と同席者は、なるべくインタビュー対象者の視界に入らないよう、席に配慮しましょう。

プロセス3：エスノグラフィ

エスノグラフィとは、人が活動している現場を深く観察・理解することで、本当の姿を感覚として知ることができるUXリサーチの手法です。

インタビューでは、顕在ニーズの裏にある潜在ニーズを中心に詳らかにしてきました。エスノグラフィでは、インタビューだと気づきにくい潜在ニーズを探るための以下の事項を確認できます。

• ユーザーの無意識な想定外の業務手順
• より正確なタスクと使うもの（メモ、封筒、電卓、他システムの参照など）
• ユーザーが意識しない関係者（作業協力者、レビュー者、電話相手など）
• ユーザーの慣れで埋もれた問題点

特に業務システムでは、業務フローに問題があっても、ユーザーが上手く適応してしまい、問題が埋もれてしまうことも多いため、インタビューでは顕在化しにくいです。実際に業務の様子を観察することで、初めて明らかになります。

エスノグラフィの設計

まずはアンケートやインタビューで確認できた情報を整理し、以下を設計します。

• 観察対象にすべきシナリオやシーンの選定
• 特に注視すべき課題のあるタスクの選定
• 現時点で分かっている業務フローの設定
• 不明点やより詳細に知りたい事項の整理
• ユーザーの選定とリクルーティング

エスノグラフィでは、観察と記録に注力します。観察者の行動を阻害しないよう、なるべく複数人で観察を行いましょう。すべてを観察することは難しいため、事前に何に注意し、何を無視するかを選別しておくとよいでしょう。

観察観点

観察観点の参考となるエスノグラフィーフレームワークが複数存在しますが、今回は「POEMS」を例に説明します。「POEMS」は観察観点の頭文字で構成されます。

• People（人々）：役割、ポジション、行動の特徴など
• Objects（目的）：システム、ツール、機能などの調査対象
• Environments（環境）：レイアウト、雰囲気、照明、温度など
• Messages（メッセージ）：専門用語、言い回し、頻出フレーズなど
• Services（サービス）：影響を与えるすべての周辺アプリ、ツール、システム

業務フローのタスク順序を軸に、POEMSを活用した以下のようなテンプレートを利用すると、記録がしやすくなります。

観察後には、簡単にユーザーにインタビューできる時間を確保しておくとよいでしょう。インタビューでは、観察で得られた新たな気づきや、行動の根拠を聞き出します。観察が終了したら、観察者全員の記録を１つに纏めて、特徴的な行動を中心に整理します。

プロセス4：ユーザーテスト

ここまでのUXリサーチでは、業務フローの中でもタスクに焦点を当てた抽象度の高い潜在ニーズを探ってきました。このニーズから導かれるアイデアは、最終的に業務システムに機能レベルで落とし込まれます。しかし、業務システムのUIに対する詳細な課題やニーズは仮説にすぎず、まだ明らかになっていません。

ここでは実際に、ユーザーに既存の業務システムを操作してもらい、手順を細かく観察するユーザーテストを活用して、業務システムの操作に特化したニーズを確認します。

テストの設計

まずは今までのUXリサーチで判明した、業務システムの中で課題の大きな機能を中心に以下を行います。

• テストの目的の設定
• テスト対象にすべき機能の決定
• 想定されるユーザーの行動シナリオ・画面フローの設定
• テスト時にユーザーに伝えるべき前提条件やゴールの設定

ユーザーテストは、細かいシナリオ設定が必要になるため、事前にリハーサルをして、設計した手順でスムーズにテストができるかを確認し、内容をブラッシュアップすることをオススメします。

業務システムの場合、熟練者向けの操作のショートカット機能が提供されていることも多く、操作手順が複数存在する傾向にあります。事前に業務システムの機能を確認し、操作手順のバリエーションを把握しておくと、テスト実施時に想定外の操作をされても、臨機応変に対応しやすくなります。

テストの実施

インタビューと同様に、モデレーター担当とメモ担当の２名以上で行います。ユーザーには、操作中に考えていることを発話しながら操作してもらい、メモはユーザーの特徴的な操作や口にした事実をそのまま書き留めます。同時に録画をしておけば、漏れなく事実を抽出できます。

業務システムでは、システム設計者が想定した操作方法をしていなかったり、エクセルなどの外部ツールを駆使して独自の操作方法をしているユーザーも多いため、それらの特徴的な行動がないかは必ず確認します。さらに、その操作方法に至った理由も都度確認し、現状のシステムのどこに問題がるのかを判断するための情報を集めます。

ここでのユーザーテストは、現在の業務システムに対するUXリサーチとして行う前提で説明しましたが、改修後のUIデザインに対して改善効果があるかを、本格開発前に検証するのにも有効です。各フェーズでの実施を計画することをオススメします。

さいごに

UXリサーチの結果は、UX/UIデザインのその後のプロセス全てに影響します。ジャーニーマップ、開発要件の根拠、デザインコンセプトなど、さまざまな制作物のインプットとなるのです。業務システム特有のリサーチ観点を理解し、ニーズを探ることでリサーチの精度を高めることが重要です。

また、今回は定性的なUXリサーチに焦点を当ててお話しましたが、ログなど定量データも得られる場合は、併せて分析し、改善の最適解を考えましょう。