UIの使いやすさを指摘すると、好みの話として片付けられることがあります。設計の初期段階から関わりたいと考えていても、根拠を示せなければ提案は通りにくいものです。使いにくさは見た目の印象だけの問題ではなく、使用エラーや事故につながる要因の一つとして扱われています¹。この記事では、使いにくさが招く損失と、初期段階から関わるための言葉を整理します。

1. 「使いやすさ」は好みの問題ではない

好みの評価と、事故につながる評価は別の軸

UIレビューの場で、使いやすさへの指摘が「好みの問題」の一言で片付けられることがあります。優先度の低い要望として後回しにされ、設計の初期段階から関わりたいという声が届きにくくなります。

動作に不具合がなければ「正しく動いている」と評価され、使いやすさの指摘は別枠に置かれやすくなります。仕様どおりに動くことと、利用者が迷わずに使えることは、確認する観点が異なります。不具合は再現手順を示せば合意が得やすいのに対し、使いにくさは体感の差として扱われ、指摘のたびに一から説明し直す場面が増えます。

しかし、使いにくさは好みの範囲を超えて、使用エラーや事故につながる要因の一つとして扱われています。デジタル庁のユーザビリティガイドラインでは、情報システムに関連した使用エラーの多くに、分かりやすい情報の不足や、理解・操作が難しい難解なインタフェース、操作を誤った際に被害を抑える仕組みの不足といったユーザビリティの考慮不足が関係していると示されています¹。

「好みでは」という一言に対して、使用エラーや事故につながる要因として位置づけられているという事実は、提案を後回しにしない根拠になります。レビューの場でも、好みの話ではなく、事故を抑える設計としての位置づけを共有することが、話を前に進める一歩になります。

使用エラーの手前にある3つの要因

使用エラーにつながりやすい要因は、大きく3つに整理できます。分かりやすい情報が届いているか、操作の手順や表示が理解・操作しやすいか、そして操作を誤った場合に被害を抑える仕組みが備わっているか、という3つの視点です¹。設計の初期段階でこの3つを確認しておくと、後工程で「使いにくい」という指摘を受けてから直すよりも、手戻りを抑えやすくなります。3つはそれぞれ独立した確認事項なので、一度にすべてを直そうとせず、優先度をつけて一つずつ提案していく進め方もできます。

要因	内容	提案で使える視点
分かりやすい情報の不足	必要な情報が伝わりにくい表示や説明になっている状態	情報の見え方を早い段階で確認する材料になる
難解なインタフェース	操作の手順や画面の構成が理解・操作しにくい状態	操作の流れを設計段階で見直す材料になる
被害を抑える仕組みの不足	操作を誤った際に被害を抑える仕組みが備わっていない状態	誤操作を想定した設計を提案する材料になる

3つの要因は独立して起きるだけでなく、重なって現れることもあります。分かりやすい情報が不足した状態で難解なインタフェースが重なると、利用者が誤操作に気づく機会そのものが減ってしまいます。

図の作成：Remogu編集部。デジタル庁「ユーザビリティガイドライン」の内容を整理したもので、統計データではありません。

好みではないと示すための材料が集まったところで、次に整理したいのは、使いにくさへの向き合い方です。使用エラーや事故につながる要因があるとわかれば、次に考えるのは、どう抑えるかという設計の姿勢です。抑え方を言葉にできれば、設計の話としてだけでなく、費用の話としても提案できるようになります。

2. 起こさない設計と、起きても小さくする設計

二段構えで捉えると、提案の切り口が増える

使いにくさへの対策は、発生を防ぐことだけに目が向きがちです。しかし、デジタル庁のユーザビリティガイドラインは、人に起因した使用エラーをなるべく引き起こさないことと、使用エラーが起きた場合の影響を低減させることの両方が大切だと示しています²。防ぐことよりも、起きた後の影響を小さくする視点のほうが、設計の話題として見落とされやすい部分です。

起こさない設計は、操作の手順や表示を分かりやすくすることに重きを置きます。起きても小さくする設計は、操作を誤った場合でも被害が広がらないように受け止める仕組みを指します。この二段構えで捉えると、「防ぐ」という提案が通らなかった場面でも、「小さくする」という別の切り口から再提案できます。

どちらか一方だけを整えても、もう一方が手薄なままでは、使用エラーや事故につながる要因は残ります。二段構えで示すことは、対策に漏れがないことをクライアントに伝える材料にもなります。

起こさない設計と起きても小さくする設計は、それぞれ議論する相手が異なる場合があります。起こさない設計は要件定義や設計レビューの場で、起きても小さくする設計は運用やサポートの議論の場で扱われやすい傾向があります。議論の場が分かれているからこそ、両方の言葉を持っておくことに意味があります。

起こさない設計だけで押し切ろうとすると、発生をゼロにする保証はできないという反論で止まりやすくなります。起きた後の対応も合わせて示すことで、提案全体の説得力が増します。

起こさない設計と起きても小さくする設計は、優先順位が入れ替わる場面もあります。リリース間近で仕様変更が難しい案件では、起きても小さくする設計から着手し、次の改修サイクルで起こさない設計を整えるという順番も選べます。稼働期間や案件の制約によって、二段構えの当てはめ方は変わります。起こさない設計は要件整理や情報設計のスキルと結びつきやすく、起きても小さくする設計は例外処理や復旧の設計スキルと結びつきやすい領域です。

図の作成：Remogu編集部。デジタル庁「ユーザビリティガイドライン」の内容を整理したもので、統計データではありません。

3. 使いにくさは費用として返ってくる

使いにくさが招く損失の種類

使いにくいシステムは、見た目の印象だけでなく、実際の費用としても現れます。デジタル庁のユーザビリティガイドラインは、使いにくいシステムが利用率の低迷や機会損失、操作に要する時間や精神的負担の増加、サポートコストや改修コストの増大といった損失を招くと示しています³。損失の種類を言葉にしておくと、設計の初期段階で手をかける理由を、費用の話として伝えやすくなります。

損失の種類	内容
利用率の低迷・機会損失	使いにくさを理由に利用が広がらず、機会を取りこぼす状態
操作時間・精神的負担の増加	操作に時間がかかり、利用者の負担が増える状態
サポート・改修コストの増大	問い合わせ対応や後からの改修に費用がかかる状態

こうした損失は公開した直後には見えにくく、利用が進むにつれて徐々に表面化する性質があります。サポート対応や改修にかかる時間として、後になって気づく場合があります。利用率の低迷や機会損失は事業側の関心事になりやすく、操作時間や精神的負担の増加は利用者側の実感に直結します。サポートコストや改修コストの増大は、双方に影響が及ぶ項目です。

秒単位の削減が、累計のコストに効く理由

大きな改修でなければ提案にならないと思われがちですが、そうとは限りません。ユーザビリティガイドラインは、秒単位であっても操作を完了させる時間を削減できることは、積み重ねれば大きなコスト低減に直結すると示しています⁴。具体的な削減額は案件ごとに異なるため触れませんが、小さな改善でも積み重なるという考え方自体が、提案の一歩を後押しします。操作の途中で迷う場面を一つ減らすだけでも、積み重なれば影響は小さくありません。日常的に繰り返される操作ほど、秒単位の差が積み重なる回数も増えます。頻度の高い操作から見直す進め方は、対象を絞って提案しやすいという利点もあります。損失の種類ごとに整理しておくと、複数の改善案を比べるときに、どの損失を優先して抑えるかという判断がしやすくなります。

図の作成：Remogu編集部。デジタル庁「ユーザビリティガイドライン」の内容を整理したもので、統計データではありません。

損失として現れることが分かれば、次に考えたいのは、いつ手をかけるかという順番です。費用として返ってくるという理解が共有できれば、設計の初期段階に時間をかける提案も、単なる要望ではなく投資の話として受け止めてもらいやすくなります。

4. 初期段階から見るほど効く

早い段階の把握が、選べる範囲を広げる

使いにくさへの対応は、リリース後に指摘を受けてから動くものだと捉えられがちです。しかし、ユーザビリティガイドラインは、プロジェクトの初期段階から多様な利用者のニーズや利用状況を把握し、そのニーズを満たす仕様になっているかを段階的に検証していくことが欠かせないと示しています⁵。後工程で直すことよりも、初期段階で把握しておくことのほうが、選べる設計の範囲を広く保てます。利用者のニーズを把握する作業を後回しにすると、すでに決まった仕様に利用者を当てはめる形になり、合わない部分が後から見つかりやすくなります。段階的な検証は、一度にすべてを確認するのではなく、区切りごとに確認を積み重ねる進め方です。区切りを細かくするほど、後から見つかる不一致は小さく収まりやすくなります。早い段階の把握は、要件が固まっていない時期に行うからこそ、選択肢を狭めずに検討できるという利点があります。

特定しておきたい利用者の背景

利用者の幅を決める作業は、設計の初期段階で行うほど効果的です。ユーザビリティガイドラインは、性別、年齢、障害の有無、言語、経済状況など、多様な背景のある利用者及びその特性を特定すると示しています⁶。特定した背景をもとに、対象者がプロジェクトの各段階に参加し、設計や評価に寄与するインクルーシブデザインのアプローチを取り入れることも示されています⁷。対象者が設計や評価に参加する進め方を、初期段階から組み込んでおくと、後から進め方を大きく変える場面は少なくなります。

背景の例	設計で確認したい視点
性別・年齢	想定する利用者の幅を狭めていないか
障害の有無	操作や理解のしやすさに関わる特性があるか
言語・経済状況	表示や利用条件が特定の利用者に偏っていないか

多様な背景を特定する作業は、設計を担当するメンバーだけでなく、企画や運用に関わるメンバーも加わることで、見落としを減らせます。立場によって気づく背景が異なるためです。背景を特定する作業と、対象者が加わる進め方は、それぞれ別々に行うよりも、同じ初期段階で並べて進めるほうが噛み合いやすくなります。利用者の幅を特定する作業は、一度決めたら終わりというものではありません。プロジェクトが進むにつれて、想定していなかった利用者や利用場面が見つかることもあります。そのつど背景を更新し、検証の対象に加えていく姿勢が、段階的な検証という考え方と噛み合います。

図の作成：Remogu編集部。デジタル庁「ユーザビリティガイドライン」の内容を整理したもので、統計データではありません。

初期段階から関わるための材料が揃ったところで、次に考えたいのは、実際にどう案件に関わるかという場面です。言葉にできる根拠が増えるほど、参画先との協議で提案できる範囲も広がります。

5. リモート・フリーランス案件でどう関わるか

上流から入るための言葉

このガイドラインは、行政情報及び機能提供を利用者にとってより使いやすく安全に見直す際に適用するものと示されています⁸。行政向けの指針であるため、民間の案件すべてに同じ基準がそのまま当てはまるわけではありません。ただし、「使いにくさは使用エラーや事故につながる要因として扱われている」「早い段階からの把握と段階的な検証が欠かせない」という言葉自体は、業種を問わず提案の場で使える材料になります。打ち合わせの場では、設計の優先度を上げる理由として使えます。後工程に回されそうな確認作業を、初期段階のタスクとして組み込む理由にもなります。

設計の初期段階から関わりたいという理想と、リモートで働く環境を両立させたいと考える人にとって、Remoguはリモートワークの案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です⁹。上流から関わりたいという声を、根拠のある言葉に変えて示すことができれば、クライアントとの協議でも、設計の初期段階から関わる提案がしやすくなります。常駐前提の座組みでは、設計の議論がその場の口頭でまとまり、記録が残らないまま次の工程に進むことがあります。リモートでの参画は、資料やチャットでのやり取りが基本になるため、使いにくさの指摘や検証の結果を言葉にして残す機会が自然に増えます。設計の初期段階から関わった経験は、次の案件を探すときにも、具体的な言葉で伝えやすい実績になります。「どの段階から関わったか」を明確に語れることは、上流工程を任せてもらえるかどうかの判断材料にもなります。まずは登録して、自分の経験に近い案件の条件を確かめてみるのも一つの進め方です。

6. まとめ

使いにくさは好みの問題ではなく、使用エラーや事故につながる要因の一つとして挙げられています¹。抑え方には二段構えがあり、人に起因した使用エラーをなるべく引き起こさないことと、起きた場合の影響を低減させることの両方が大切だと示されています²。大きな改修でなくても、秒単位であっても操作を完了させる時間を削減できることは、積み重ねれば大きなコスト低減に直結すると示されており⁴、小さな改善からでも提案できます。

こうした抑え方や小さな改善の効果は、プロジェクトの初期段階から多様な利用者のニーズや利用状況を把握し、ニーズを満たす仕様になっているかを段階的に検証していくことで、より効きやすくなります⁵。好みの話として片付けられがちな指摘を、事故につながる要因の話、そして費用の話として言葉にできれば、設計の初期段階から関わりたいという提案も通りやすくなります。この順序を早い段階から確認できる関わり方を探すなら、まずは登録して、自分の経験を活かせる案件の条件を確かめてみるのも一つの進め方です。

7. よくある質問

ユーザビリティは誰の仕事なのですか

設計や実装を担うメンバーだけの仕事ではありません。ユーザビリティガイドラインが示すとおり、対象者がプロジェクトの各段階に参加し、設計や評価に寄与する進め方も含まれます⁷。参画するメンバーが、早い段階から声を上げられる関わり方を持てることが望まれます。設計の初期段階からメンバー全員で確認できる体制のほうが、後から一人に負担が集中する事態を避けやすくなります。

使いやすさの確保は何から始めればよいのですか

まずは、利用者の幅を特定することから始まります。性別、年齢、障害の有無、言語、経済状況など、多様な背景のある利用者とその特性を特定することが、ユーザビリティガイドラインでも示されています⁶。特定した幅をもとに、初期段階から利用状況を把握し、段階的に検証していく進め方につながります⁵。特定を先に済ませておくと、後続の設計や検証の場で、確認する範囲がぶれにくくなります。案件によって特定する背景の重み付けは変わるため、要件定義の場で確認しておくと安心です。

使いにくさは後から直せないのですか

後からの改修がまったくできないわけではありません。ただし、ユーザビリティガイドラインは、使いにくいシステムがサポートコストや改修コストの増大といった損失を招くと示しており³、初期段階から把握しておくほうが、選べる設計の範囲を広く保てます⁵。後工程での直しは、費用と時間の面で不利になりやすい進め方です。そのため、直せるかどうかよりも、直すためにかかる費用と時間をどれだけ小さくできるかという観点で考えたいところです。

小さな改善でも提案していいのですか

大きな改修でなければ提案にならないというわけではありません。秒単位であっても操作を完了させる時間を削減できることは、積み重ねれば大きなコスト低減に直結すると示されています⁴。小さな改善を積み重ねる提案も、根拠のある進め方の一つです。小さな改善を積み重ねる姿勢自体が、大きな改修を求める提案よりも受け入れられやすい場面もあります。

リモートでも設計の初期段階から関われるのですか

リモートでの参画自体が、初期段階から関わることを妨げるものではありません。Remoguは、リモートワークの案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です⁹。設計の初期段階から関わりたいという希望を、根拠のある言葉とともにクライアントと協議していくことが、参画先との関わり方を広げる一歩になります。案件ごとに条件は異なるため、まずは登録して、実際の案件情報を確認しながら、参画先との相談を進めていく方法もあります。

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

出典・参考情報

＊1 デジタル庁「ユーザビリティガイドライン」DS-670.1 背景と課題（2026年6月12日）
＊2 デジタル庁「ユーザビリティガイドライン」DS-670.1 背景と課題（2026年6月12日）
＊3 デジタル庁「ユーザビリティガイドライン」DS-670.1 背景と課題（2026年6月12日）
＊4 デジタル庁「ユーザビリティガイドライン」DS-670.1 メリット（2026年6月12日）
＊5 デジタル庁「ユーザビリティガイドライン」DS-670.1 概要（2026年6月12日）
＊6 デジタル庁「ユーザビリティガイドライン」DS-670.1 3.2.1 多様な利用者の種類及び特性の特定（2026年6月12日）
＊7 デジタル庁「ユーザビリティガイドライン」DS-670.1 3.2.1 多様な利用者の種類及び特性の特定（2026年6月12日）
＊8 デジタル庁「ユーザビリティガイドライン」DS-670.1 適用対象（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）