仕様通りに実装した機能なのに、リリース後に問い合わせが増え、修正の依頼が積み重なる場面があります。上流の判断は担当外だと考えられがちですが、実装まで担うエンジニアが利用者起点の判断基準を持ち込む案件が増えています。この記事では、行政サービスの改善にも使われている「サービス設計12箇条」を手がかりに、思い込みで作らないための考え方と、リモート・フリーランスの案件でどう活かすかを整理します。

1. なぜ利用者中心設計の案件が増えているのか

作られたのに使われない機能が増えている

機能自体は仕様どおりに動いていても、公開後に問い合わせが増え、使い方の説明を追加し、想定していなかった手戻りに追われる案件があります。原因は、実装の精度ではなく、利用者が実際にどう困っているかを把握しないまま設計を進めたところにあります。

エンジニアが担う範囲は実装だけではなくなってきました。上流の要件定義や画面設計にも、利用者起点の判断が求められる場面が増えています。行政サービスの分野では、利用者視点を組み込むための考え方として「サービス設計12箇条」¹が整理されており、行政に限らず一般のプロダクト開発にも読み替えて使えます。

図1は、利用者視点を欠いたまま進めた場合に起きやすい流れを示したものです。仕様が固まった時点で利用者への確認を省くと、公開後の問い合わせと手戻りという形でコストが後ろにずれ込みます。

図の作成：Remogu編集部。案件で起きやすい流れを整理したもので、統計データではありません

この流れを早い段階で断ち切れるかどうかが、案件の評価を分けます。実装の速さだけでなく、利用者の実態を踏まえた判断ができるかどうかが問われるようになっているためで、次の章ではその判断基準を具体的に見ていきます。

2. 判断基準になる「サービス設計12箇条」の要点

設計に直結する6つの原則

「サービス設計12箇条」はデジタル庁が示す行政サービス改善の指針¹で、12の原則のうち、設計判断に直結するのは前半の6つです。ここでは実装まで担うエンジニアの立場で、それぞれをどう案件に落とし込むかを整理します。

第1条は利用者のニーズから出発する¹という原則です。提供する側の都合を起点にせず、利用者が本当に求めていることから設計を始める考え方です。第2条は事実を詳細に把握する²ことを求めており、思い込みではなく調査で得た事実に基づいて判断します。

第3条のエンドツーエンドで考える³は、一部の画面や機能だけでなく、利用者の一連の体験全体を対象にする原則です。第4条は全ての関係者に気を配る⁴ことを挙げており、利用者だけでなく運用する現場や関係部門まで視野に入れます。

第5条はサービスはシンプルにする⁵という原則です。利用者が迷わず使えるよう、複雑さを持ち込まないことを求めています。第6条ではデジタル技術を活用しサービスの価値を高めること⁶が挙げられており、技術そのものを目的にせず、価値を高める手段として位置づける考え方です。

6原則を案件の行動に落とし込む

6つの原則は、知っているだけでは案件の判断に使えません。表1は、それぞれの原則が求める内容と、実装フェーズで確認できる具体的な行動を対応させたものです。仕様書を読むとき、画面設計の背景を確認するとき、実装の途中で判断に迷ったときに、どの原則に立ち返ればよいかの手がかりとして使えます。原則を覚えることよりも、案件で実際に確認する行動に変換できているかどうかが重要です。

原則	内容	案件での確認行動
第1条：利用者のニーズから出発する	提供側の都合ではなく利用者が求めることを起点にする	仕様の背景に利用者の要望が反映されているかを確認する
第2条：事実を詳細に把握する	思い込みではなく調査で得た事実に基づいて判断する	要件定義書に利用者調査の記録があるかを確かめる
第3条：エンドツーエンドで考える	一部の画面ではなく一連の体験全体を対象にする	画面同士のつなぎ目で利用者が迷わないかを確認する
第4条：全ての関係者に気を配る	利用者だけでなく運用現場や関係部門まで視野に入れる	運用担当者の負担が増えていないかを確認する
第5条：サービスはシンプルにする	複雑さを持ち込まず利用者が迷わず使える設計にする	機能を絞り込めないかを提案する
第6条：デジタル技術を活用しサービスの価値を高める	技術を目的化せず価値を高める手段として使う	技術選定が利用者の体験向上につながっているかを確認する

図2は、設計に効く6原則を並べたものです。個々の原則は独立していますが、案件の場面によっては複数の原則が同時に関わることもあります。

出典：デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）をもとに作成

ここまでの6原則は、どれも単独で完結するものではなく、事実の把握と体験全体の設計は特に関わりが深いものです。次の章では、思い込みで作らないための事実確認の進め方を具体的に見ていきます。

3. 事実から始める：思い込みで作らないための調査

思い込みで進めた設計が手戻りを生む

第1条¹は利用者のニーズを起点にすることを求め、第2条²は思い込みではなく事実の把握を求めています。この2つは、設計の入り口で何を確認するかを決める原則です。

案件でよくあるのは、過去の類似案件や担当者の経験則をもとに仕様を決め、利用者への確認を後回しにする進め方です。経験則は判断の助けになりますが、対象の利用者や利用場面が変われば前提も変わります。事実を確認しないまま進めると、公開後になって想定と違う使われ方が見つかり、手戻りにつながります。

思い込みと事実確認の分かれ目

思い込みで仕様を決めることと、事実を確認してから仕様を決めることは、途中までは同じ工程に見えても、公開後の結果に差が出ます。表2は、代表的な3つの場面で、思い込みで進めた場合と事実を確認した場合の違いを比べたものです。どちらの進め方も見た目はスムーズに進むため、事実確認を省いたかどうかは、案件の途中では気づきにくいという特徴があります。

場面	思い込みで進める場合	事実を確認する場合
画面設計の根拠	過去の類似案件や経験則で仕様を決める	利用者調査や問い合わせ内容を確認してから決める
利用者像の想定	担当者がイメージする利用者像を前提にする	実際の操作ログや利用場面を確認して前提を見直す
公開後の対応	想定と違う使われ方に気づかず問い合わせが増える	事実に基づく設計で手戻りを小さく抑える

図3は、思い込みで作る場合と事実を把握して作る場合の違いを、代表的な場面ごとに対比したものです。

図の作成：Remogu編集部。進め方の違いを整理したもので、統計データではありません

事実の確認は大がかりな調査でなくても始められます。既存の問い合わせ内容を読み込む、実際の利用画面の操作の流れを一通りたどる、関係者に利用場面を聞くといった、案件の規模に合わせた方法で十分です。重要なのは、確認した事実を設計の根拠として言葉に残すことで、次の章ではこの事実確認を体験全体の設計にどうつなげるかを見ていきます。

4. 体験全体を設計し、作りすぎない

一連の体験を対象にし、試作して確かめる

第3条のエンドツーエンドで考える³は、画面単位ではなく利用者の一連の体験を対象にする原則です。ログインから目的の達成までの流れを通しで見ると、個々の画面では問題がなくても、つなぎ目で利用者が迷う箇所が見つかります。

第4条⁴は、利用者だけでなく運用する現場や関係部門まで視野に入れることを求めています。利用者にとって使いやすい設計でも、運用側の負担が大きければサービス全体としては成立しません。第5条のサービスはシンプルにする⁵は、この両方を満たす手段として、機能を絞り込む判断につながります。

これらの原則を実装に落とし込むうえで有効なのが、作り込む前に試作し、確かめてから次に進める進め方です。一度で仕上げようとせず、小さく作って確かめる回数を重ねることで、手戻りの規模を小さく抑えられます。

図の作成：Remogu編集部。試作と検証を繰り返す進め方を整理したもので、統計データではありません

工程ごとに利用者視点を確認する

表3は、要件定義から試作・検証までの工程ごとに、利用者視点で確認する内容と、陥りやすい思い込みを整理したものです。工程が進むほど手戻りの規模は大きくなるため、早い工程で確認しておくことの効果は大きくなります。

工程	利用者視点で確認すること	陥りやすい思い込み
要件定義	利用者のニーズが仕様の起点になっているか	提供側の都合を利用者の要望と思い込む
画面設計	一連の体験の中でつなぎ目に迷いが生じないか	個々の画面だけを見て全体を確認しない
実装	機能を増やしすぎずシンプルさを保てているか	機能を増やすことが価値の向上だと思い込む
試作・検証	試作を通じて利用者の反応を確かめられているか	一度の実装で仕上がると思い込む

要件定義の段階で確認を怠ると、実装が進んでから設計をやり直す規模の手戻りになります。逆に、試作の段階で確かめておけば、修正は小さく済み、次の章ではこの考え方をリモート・フリーランスの案件でどう活かすかを見ていきます。

5. リモート・フリーランス案件でどう活かすか

上流の判断に加われる材料になる

利用者中心設計の考え方は、実装だけを担当する場合でも使えます。仕様として渡された画面設計に疑問を感じたときに、利用者のニーズから出発しているか¹、事実に基づいているか²を確認する視点があれば、実装の担当であっても改善の提案がしやすくなります。

関わり方は案件によって異なります。要件定義から参加する案件もあれば、実装フェーズから参画し、仕様の背景を確認しながら進める案件もあります。どちらの関わり方でも、事実を確認する姿勢と、体験全体を見る視点は共通して使えます。

案件を見極めるときは、要件定義書に利用者調査の記録があるか、画面設計の背景が説明されているかを確認すると、進め方の見通しが立てやすくなります。記録が薄い案件では、実装を進めながら事実を確認する時間をどれだけ確保できるかをクライアントと協議しておくと、後の手戻りを避けやすくなります。

リモートでの案件は、Remogu（株式会社LASSIC運営）のようにリモートワーク案件に特化したエンジニアマッチングでも扱われています。Remoguが扱う案件は90%以上がフルリモート可能です⁷。場所に縛られずに、上流の判断まで担う案件を探す選択肢として使えます。

これまで担ってきた工程と、関わってみたい上流の範囲を照らし合わせ、条件に近い案件があるかをまず確かめてみましょう。会員登録をしておくと、条件に合う案件の情報を継続して確認できます。

6. まとめ

利用者中心設計は、UXデザイナーだけの領域ではありません。実装まで担うエンジニアが、利用者のニーズから出発する¹、事実を詳細に把握する²という原則を判断基準として持っていれば、仕様の背景を確認し、必要であれば見直しを提案できます。

作られたのに使われない機能を防ぐ鍵は、大がかりな調査ではなく、思い込みで進めていないかをそのつど確認する姿勢と、小さく試作して確かめる進め方にあります。この視点を持つエンジニアは、実装力に加えて上流の判断力を示せるため、任される案件の幅が広がります。

積み上げてきた実装の経験に、利用者起点の判断基準を重ねていくことで、任される工程は広がっていきます。まずは自分の担当範囲に近い案件を確認し、条件に合うものがあれば登録して詳細を確かめてみましょう。

7. よくある質問

UXデザイナーでないと利用者中心設計は扱えませんか

利用者中心設計は職種を問わず使える考え方です。第1条の利用者のニーズから出発する¹という原則は、画面設計だけでなく、実装の細部の判断にも当てはめられます。UXデザイナーの専門知識がなくても、事実を確認する姿勢があれば取り入れられます。

どの工程から関わるのが向いていますか

要件定義から関われる案件が理想ですが、実装フェーズからの参画でも活かせます。仕様の背景を確認し、事実に基づいているか²を確かめる習慣があれば、途中からの参画でも改善の提案がしやすくなります。

小規模な案件でも使える考え方ですか

使えます。大がかりな利用者調査を行わなくても、既存の問い合わせ内容を確認したり、実際の操作の流れを一通りたどったりするだけで、思い込みに気づく場面があります。案件の規模に合わせて、確認できる範囲から始めれば十分です。

実装だけを担当する案件でも活かせますか

活かせます。仕様書どおりに実装する場合でも、エンドツーエンドで考える³視点があれば、画面同士のつなぎ目で利用者が迷う箇所に気づきやすくなります。気づいた点はクライアントと協議し、修正の要否を判断する材料にできます。

この考え方を活かす案件はフルリモートでもできますか

案件によって異なりますが、リモートで進められるものは少なくありません。利用者への事実確認や試作の共有は、オンラインの環境でも十分に進められます。まずは自分の経験に近い案件を確認し、条件を確かめてみましょう。

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

出典・参考情報

＊1 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊2 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊3 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊4 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊5 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊6 デジタル庁「行政サービスにおける利用者視点導入ガイドブック」（2025年4月1日）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能