UI/UXの案件に入ると、まず利用者への調査を任されます。話を聞き、画面を触ってもらい、気づいたことをメモに残す。ここまでは案件を問わず共通する動きです。問題は次の段階で起こります。集めた声を要件に変えるとき、順番を持たずに進めると、印象や好みの話として受け止められてしまう場面が出てきます。

1. 調査が感覚の話に見えるのは、順番が無いから

UI/UXの調査は、担当者ごとにやり方がばらつきやすい作業です。聞き取りの粒度も、ユーザーテストの回数も現場によって違います。この状態のまま要件を出すと、根拠を尋ねられたときに説明が詰まりやすくなります。まとまりのなさは、資料の見た目や言葉づかいの差だと受け取られがちですが、実際には調査の「順番」が決まっていないことが原因です。

順番が無い調査は、聞いた話をそのまま並べるだけになりがちです。どの声を先に扱うか、どの数字から読むかという基準が無いため、最終的に「担当者の好みではないか」と受け取られる隙が生まれます。逆に、進める順番を先に決めておけば、途中の判断も後から説明できる形で残ります。順番の有無は、調査の質そのものより先に効いてくる要素です。

調査は企画の活動として最初から位置づけられている

この順番を考えるときの手がかりになるのが、デジタル庁が示す実践ガイドブックです。ここでは企画の活動に、利用者のニーズ把握、利用者調査、要望やクレーム等の分析が含まれています¹。調査は思いつきで足す工程ではなく、企画の段階から組み込まれる仕事として扱われています。案件に入ってから慌てて調査の計画を立てるのではなく、企画の時点で調査の範囲を決めておく進め方が示されています。

この位置づけを知っておくと、案件の打診を受けた直後の動き方が変わります。調査を「頼まれたらやること」ではなく「企画の一部」として扱うと、クライアントと話す際に調査の必要性を説明する言葉が持てます。感覚で始めるよりも、企画の活動として調査を位置づけて始めるほうが、後の工程で迷いが減ります。

順番を飛ばした先に何が起きるか

同じ実践ガイドブックには、現場の業務と合わないサービスを提供し、活用されなかったシステムの例が挙げられています⁸。調査の順番を飛ばして進めた結果、利用者の実態と離れたものができあがるという例です。事例の詳しい中身までは公開情報に示されていませんが、順番を欠いた調査がどこに向かうかを示す材料になります。

この例が示しているのは、調査を怠ったという単純な話ではありません。調査自体は行われていても、数える・立場を取る・現場を見る・数字を読むという順番のどこかが抜け落ちると、現場と合わないものに行き着くという構図です。次の章から、この4つの段階を順番に見ていきます。

図の作成：Remogu編集部。実践ガイドブックが示す調査の段階を整理したもので、統計データではありません

2. まず、種類と人数を数える

調査の入口をどこに置くかは、案件によって揺れやすいところです。聞き取りから始める進め方もあれば、資料の読み込みから始める進め方もあります。実践ガイドブックが示す順番では、最初に置かれているのは聞き取りではなく、数えることです。

数えるといっても、難しい統計処理を指すわけではありません。サービスを使う人がどのような種類に分かれ、それぞれ何人くらいいるのかを把握する作業です。ここを飛ばして声の大きい利用者の意見から着手すると、後になって「他の利用者はどう考えているか」を尋ねられたときに答えが用意できません。

チェックリストの最初に置かれている項目

同じ実践ガイドブックのチェックリストでは、利用者視点でのニーズ把握の最初に「サービスの利用者の種類や人数を把握したか」という項目が置かれています²。種類と人数の把握が、立場を取る作業より先に来る形です。

この並びを踏まえると、案件の初期に取り組む作業の優先順位が見えてきます。声を集めることよりも、まず利用者の全体像を数で押さえることのほうが先に置かれています。全体像が無いまま個別の声を集めると、後で「それは一部の意見では」と問われたときに答えにくくなります。

数えると、後の議論の土台になる

利用者の種類と人数を数えておくと、後の工程で判断の土台として使えます。要件の優先順位を決める場面で「この種類の利用者が多いから」という説明ができるようになり、印象での判断と区別しやすくなります。数えることは調査の準備ではなく、要件を説明する材料そのものです。

逆に数を持たないまま議論に入ると、声の大きさや発言の順番が優先順位を決めてしまいます。数を先に置くことで、誰の声を先に扱うかという判断に理由を持たせられます。感覚より先に、数を土台に置く進め方です。

数えるときに分ける軸

利用者を数えるときは、ひとまとめにせず、いくつかの軸で分けておくと後で使いやすくなります。使う場面の違い、権限や役割の違い、利用の頻度、扱う業務の経験年数といった軸です。軸を決めずに合計人数だけを出すと、種類ごとの差が見えなくなり、次の立場を取る段階で誰を代表させるかを決めにくくなります。表にまとめた軸を、案件ごとに当てはめて使う形が実務的です。

分ける軸	見るポイント	次の段階への使い方
使う場面の違い	業務中に使うか、隙間時間に使うか	立場を取るときの代表者選びに使う
権限や役割の違い	入力する側か、承認する側か	要件の優先順位の説明に使う
利用の頻度	毎日使うか、月に数回か	現場を見る優先順位の説明に使う
業務の経験年数	始めたばかりか、長く担当しているか	数字を読むときの見方の調整に使う

軸を決めて数えたあとは、その中の誰かの立場に立って考える段階に進みます。数えることと立場を取ることは別の作業で、順番を保ったまま進めると、次に何を確認すればよいかが見えやすくなります。

3. 次に、立場を取る

種類と人数を数え終えると、次に迷うのは「誰の立場で考えるか」という点です。人数の多い層を代表とみなすのか、業務上の権限が強い層を優先するのか、判断に迷う場面が出てきます。

この迷いに順番を与えるのが、数えた次に立場を取るという流れです。数を持たずに立場だけを選ぶよりも、数の裏付けを持って立場を選ぶほうが、なぜその立場を優先したのかを説明しやすくなります。

利用者の立場でニーズを把握する項目

実践ガイドブックの同じチェックリストには、「利用者の立場でサービスへのニーズを把握したか」という項目が続けて置かれています³。種類と人数を数える項目のすぐあとに、立場を取る項目が並ぶ形です。

この並びから読み取れるのは、立場を取る作業が数える作業の代わりではなく、その先に続く作業だという位置づけです。数を飛ばして立場だけを深掘りすると、代表させた立場が全体の中でどれくらいの重みを持つのかが分からないまま話が進みます。

立場を取るための手法の位置づけ

利用者の立場からの分析を行うための手法として、ペルソナ分析やジャーニーマップといった手法が説明されています⁷。ここでは手法の名前と位置づけまでに触れ、具体的な作り方には立ち入りません。案件によって使う手法が異なるためです。

大切なのは、これらの手法が「数えたあとに立場を取る」という順番の中に置かれている点です。手法を単体で覚えるより、数える段階との接続を持って使うほうが、要件を説明するときの筋が通ります。次の章では、この立場を取ったあとに何を見るかに進みます。

図の作成：Remogu編集部。数える段階から立場を取る段階への流れを整理したもので、統計データではありません

4. 現場を見て、数字を読む

立場を取ったあとに進むのは、実際の業務がどう動いているかを見る段階です。ここでつまずきやすいのは、リモートで参画する案件では、現場に足を運ぶ機会が限られる点です。現場に行けないことは、この段階を飛ばしてよい理由にはなりません。

現場を見る目的は、利用者の話と実際の業務の動きとの間にあるずれを見つけることにあります。話を聞くだけでなく、実際の動きを見ることのほうが、聞き取りだけでは気づけないずれに近づけます。足を運べない場合でも、このずれを見つける手段を別に用意する必要があります。

現場に行って実態を把握する項目

実践ガイドブックの業務の現状把握のチェックリストには、「業務の現場へ行って業務実態を詳細に把握したか」という項目があります⁴。話を聞くだけでなく、現場に足を運ぶことが独立した項目として置かれています。

この項目が独立して置かれているのは、聞き取りと現場観察が別の情報を運ぶためです。利用者が話す内容と、実際の作業の流れには差が出ることがあります。現場を見て初めて気づく手順の重なりや待ち時間は、聞き取りだけでは拾いにくいものです。

実績データを収集して分析する項目

同じチェックリストには、「業務で生まれる各実績データを収集して分析したか」という項目も置かれています⁵。現場観察と実績データの分析は、どちらも聞き取りの外側にある情報源という点で共通しています。

実績データを見る作業は、現場に行けない場面での代わりにもなります。現場観察が難しいリモートの案件では、業務の中で生まれる記録を分析の材料にすることで、聞き取りだけに頼らない要件の根拠を作れます。現場を見ることと数字を読むことは、置き換え可能な二つの窓口です。

現場の代わりに見るもの

現場に足を運べない案件でも、業務実態に近づく手段はいくつか残っています。業務の記録として残るログや、担当者が日々つけている作業メモ、定例の打ち合わせで共有される進捗資料などです。これらは現場を見ることそのものではありませんが、実態とのずれに気づく手がかりになります。表にまとめた項目を、案件の中で確認できるものから順に当たっていく進め方が現実的です。

見るもの	拾える情報	気づきやすいずれ
業務ログ・操作記録	実際に使われている機能や手順の頻度	話に出ない機能の使われ方
作業メモ・引き継ぎ資料	その場で対応した例外的な作業	手順書に無い運用
定例会議の進捗資料	業務が滞留している工程	聞き取りで語られない停滞

現場の記録と実績データを読み終えると、要件の根拠は聞き取りだけに頼らない形になります。次の章では、その数字をどう読むと利用者の話と矛盾しない要件になるかを見ていきます。

図の作成：Remogu編集部。現場観察と実績データ分析の関係を整理したもので、統計データではありません

5. 平均だけで読まない

現場の記録と実績データが揃うと、次はその数字をどう読むかという段階に入ります。ここでよくあるのが、平均や合計だけを見て終える読み方です。全体の傾向はつかめますが、それだけでは要件の理由まで説明しきれない場面が出てきます。

数字の読み方にも、順番と同じように注意点があります。集めた実績データをひとまとめにして平均を出すと、実態の凸凹が均されてしまい、個別の利用者が抱える負担が見えなくなることがあります。

平均や合計での分析だけでは不十分な理由

実践ガイドブックの分析の着眼点には、平均や合計での分析だけでは不十分であること、時間と期間を区別することが挙げられています⁶。数字を出すこと自体は目的ではなく、読み方に注意点があるという指摘です。

平均だけで語ると、極端に時間がかかる利用者と、短時間で済ませられる利用者の差が消えてしまいます。要件を出す場面では、この差こそが優先順位を決める材料になることが多く、平均に隠れた差を残したまま分析を進める必要があります。

時間と期間を区別して読む

時間と期間を区別するという指摘は、同じ「時間」でも指しているものが違うことへの注意です⁶。一回あたりにかかる時間と、その作業が発生する期間や頻度は別の軸であり、どちらか一方だけを見ると読み違いが起こります。

一回の作業は短くても、頻繁に発生する作業であれば、利用者にとっての負担は積み重なります。逆に一回は長くても、めったに発生しない作業であれば、優先順位は下がることがあります。時間の長さより、期間の中での繰り返しを見る視点が要件の理由を支えます。

UI/UXの経験を4つの層で書き出す

ここまでの数え方・立場の取り方・現場の見方・数字の読み方は、そのまま自分の経験を言葉にする材料にもなります。UI/UXの経験を振り返るときは、担当した工程を1つの塊として語るのではなく、層に分けて書き出すと、案件で求められる経験と照らし合わせやすくなります。表にまとめた4つの層を、過去の案件に当てはめて棚卸しする使い方ができます。

層	この記事との対応	棚卸しの視点
利用者を数えた経験	数える段階	種類・人数をどの軸で分けたか
立場を取った経験	立場を取る段階	どの立場を代表として選んだか
現場・記録を読んだ経験	現場を見る段階	現場観察と実績データのどちらを使ったか
数字を要件に変えた経験	数字を読む段階	平均でなく期間で語った場面があるか

4つの層で経験を書き出しておくと、次に案件の打診を受けたときに、どの段階の経験を先に伝えるかを選べるようになります。感覚で語っていた経験が、順番のある言葉に変わります。

図の作成：Remogu編集部。平均だけで見た場合との違いを整理したもので、統計データではありません

6. まとめ

ここまで見てきた順番は、数える・立場を取る・現場を見る・数字を読む、の4段階です。この順番を保つと、調査が感覚の話に見えることは減り、要件の理由を最後まで言葉で追えるようになります。

現場に行けない案件やリモートで参画する案件でも、記録や実績データという形で代わりの経路が用意できます。順番さえ崩さなければ、参画の形が変わっても要件を組み立てる筋道は保てます。

Remogu(株式会社LASSIC運営)が扱う案件は、90%以上がフルリモート可能です⁹。現場に足を運べる頻度が限られる働き方でも、記録や実績データを読む力を持っていれば、この記事で見てきた順番はそのまま活かせます。

まずは登録して、自分がこれまで数え、立場を取り、読んできた経験に近い案件がどれくらいあるかを確かめてみませんか。

7. よくある質問

調査の時間をもらえない案件ではどうするか

調査の時間が十分に取れない案件では、数える段階だけでも先に済ませておくと、その後の会話が変わります。利用者の種類と人数さえ分かっていれば、限られた時間の中でも、どの立場を優先して聞くかを絞り込めます。

時間が無い中で全部の段階を丁寧に進めるより、数える段階を先に済ませ、立場を取る段階は最小限に絞る進め方が現実的です。現場を見る段階と数字を読む段階は、記録やデータが手に入り次第、後から補えます。

現場に行けないリモートの案件ではどうするか

現場に行けない場合は、業務ログや作業メモ、定例会議の進捗資料といった記録を、現場観察の代わりに使います。この記事の4章で挙げた記録を、参画する案件の中で手に入るものから確認していく進め方です。

記録だけで判断が難しい場面では、定例の打ち合わせで担当者に直接確認する時間を作ることも有効です。現場に行けないことは、実態を把握できない理由にはなりません。

数字は他の担当が持っている場合はどうするか

実績データを他の担当が管理している案件では、まず何のデータが、どの単位で残っているかを確認するところから始めます。平均だけでなく、時間と期間を区別した形でデータを見せてもらえるか、担当者に相談してみましょう。

データそのものを自分で集計できない場合でも、期間ごとの傾向を教えてもらうだけで、平均に隠れた差に気づける場面があります。数字を扱う担当と早い段階で情報を共有しておくと、要件を出す段階での手戻りが減ります。

好みの話にされないためにどう伝えるか

要件を伝えるときに好みの話として受け取られやすいのは、判断の理由を省いて結論だけを話す場面です。数えた人数、取った立場、見た現場、読んだ数字の順番で説明すると、結論に至った理由が伝わりやすくなります。

この記事で見た4段階を説明の順番として使うと、なぜその要件になったのかを最後まで言葉で追ってもらえます。まずは、これまで担当してきた案件を、数える段階から振り返ってみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第2章 プロジェクトの管理（企画の活動の総括）（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（利用者視点でのニーズ把握）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（利用者視点でのニーズ把握）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（業務の現状把握）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（業務の現状把握）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 サービス・業務企画（章の紹介）（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 サービス・業務企画（章の紹介）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 事例・参考の一覧（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）