レッスン8：UX を組織で運用する——測り続ける仕組み

このレッスンで学ぶこと

単発の改善で終わらせず、継続的に測る仕組みの必要性を理解する
定量データと定性データの役割分担を説明できる
「何が、どれだけ変わるか」で改善提案を通す書き方を身につける
UX の取り組みを組織で育てていく視点を持つ

レッスン7では、画面の外側にある業務まで含めて設計するサービスブループリントを学びました。ここまでの 7 つのレッスンで、ヒューリスティック評価・ユーザビリティテスト・情報設計・仕様の書き方・アクセシビリティ・サービスブループリントという、実務で使える技法をひととおり学んできました。最終レッスンとなるこのレッスンでは、これらの技法を単発の取り組みで終わらせず、組織の中で測り続ける仕組みへとつなげる方法を扱います。

単発の改善で終わらせない

多くの現場で見られる残念なパターンは、1 度きりのユーザビリティテストや、1 度きりのヒューリスティック評価で見つかった問題を直し、そこで取り組みが止まってしまうことです。画面は一度作って終わりではなく、利用者の状況や、扱う情報、周囲の環境が変化するのに合わせて、常に変化し続けるものです。1 度の点検で見つかった問題を直しても、時間が経てば新しい問題が生まれます。

継続的に測る仕組みを持つことの利点は、問題が小さいうちに見つけられる点にあります。半年に 1 度、あるいは四半期に 1 度といった間隔で、軽い規模のヒューリスティック評価やユーザビリティテストを繰り返し実施できれば、問題が大きく積み重なる前に手を打てます。逆に、何年も点検をしないまま放置すると、いざ問題に気づいたときには、直すべき箇所が広範囲におよび、対応の負担も大きくなります。

💡 ポイント 継続的に測る仕組みを作る際は、毎回大がかりな調査を計画する必要はありません。レッスン3で扱ったとおり、少人数の観察でも重大な問題は見えやすいという考え方を思い出しましょう。小さな点検を、決まった間隔で繰り返すことのほうが、たまに行う大規模な調査よりも、実務では継続しやすいものです。

定量データと定性データの役割分担

UX を継続的に測る際には、性質の異なる 2 種類のデータを組み合わせることが有効です。

定量データとは、数値として集計できる情報です。目的の作業を完了できた利用者の割合、作業にかかった時間、誤操作の発生回数などが該当します。定量データの強みは、多くの利用者からまとめて情報を集められる点と、時間の経過とともに数値の変化を追える点にあります。

定性データとは、数値には還元しにくい、行動や発言の中身そのものを指す情報です。レッスン3で扱った思考発話法での発言や、行動の観察記録が該当します。定性データの強みは、「なぜそうなったのか」という原因を説明できる点にあります。

	定量データ	定性データ
得られる情報	数値としての傾向	行動や発言の中身
強み	多くの利用者から集められる、変化を追える	原因を説明できる
弱み	なぜそうなったかまではわからない	多くの利用者を対象にしにくい
代表的な収集方法	完了率、所要時間、誤操作の回数の計測	ユーザビリティテスト、ヒューリスティック評価

両者は、どちらか一方があれば十分というものではありません。定量データだけを見ていると、「完了率が下がった」という事実はわかっても、なぜ下がったのかがわかりません。定性データだけを見ていると、少人数から得られた発見が、実際にどれだけ多くの利用者に当てはまるのかがわかりません。定量データで変化の大きさをつかみ、定性データでその原因を掘り下げるという組み合わせが、実務では効果的です。

📝 補足 ユーザビリティの評価に特化した、定量的な指標を得るための質問票も存在します。代表的なものに SUS（System Usability Scale）があります。決まった質問項目に利用者が回答し、その回答から 1 つの点数を算出する仕組みで、異なる時点や異なる画面どうしの使いやすさを、大まかに比較する際の目安として使われます。

改善提案を「何が、どれだけ変わるか」で通す

レッスン1で示した中核メッセージの 6 つ目、「提案は『良くなる』ではなく『何が、どれだけ変わるか』で通す」を、ここで具体的な書き方として掘り下げます。

「使いやすくなります」「利用者の満足度が上がります」といった提案は、聞こえはよいものの、意思決定をする立場の人にとっては、判断材料に乏しい表現です。何がどう変わるのかが具体的でないと、その提案にどれだけの労力をかける価値があるのか、判断がつきません。

改善提案を通しやすくするための書き方の基本は、次の 3 つを明記することです。

観察された事実：何が、どのように起きているかを、観察にもとづいて具体的に示す
想定される原因：その事実が、どの原則や、どの構造上の問題に由来するかを示す
変化の見込み：改善によって、何が、どの程度変わると見込まれるかを示す

具体的な例で確認しましょう。「申し込み画面がわかりにくい」という提案では、判断材料になりません。これを、「申し込み画面で、10 人中 7 人の参加者が必須項目と任意項目の区別がつかず、平均で 40 秒余分に時間をかけていました（観察された事実）。原因は、必須と任意を色以外の方法で示していない点にあります（想定される原因）。項目の先頭に『必須』の文字を明記する対応により、区別に迷う時間を大きく減らせると見込まれます（変化の見込み）」のように書き直すと、意思決定をする人は、何にどれだけの効果が見込めるかを踏まえて判断できます。

⚠️ 注意 「変化の見込み」を書く際、確信の持てない数値を、あたかも確定した効果であるかのように書かないよう注意してください。観察された事実にもとづく合理的な見込みであることを示しつつ、「見込まれます」「期待できます」のように、断定を避けた表現を使うことが、提案の誠実さを保ちます。

定量データを使った変化の裏付け

「変化の見込み」を示すだけでなく、実際に改善を行ったあとに、定量データでその効果を確かめることも重要です。改善の前後で、完了率や所要時間、誤操作の発生回数を比較することで、提案時に見込んだ変化が、実際にどの程度実現したかを検証できます。

この検証の結果は、次の改善提案を通す際の、説得力のある材料になります。「前回の改善では、必須項目を明記したことで、区別に迷う時間が平均で 3 分の 1 に減りました」という実績があれば、次に別の画面で同様の提案をする際にも、関係者からの信頼を得やすくなります。改善提案は、1 回だけの説得の場ではなく、実績を積み重ねながら、組織からの信頼を育てていく継続的な営みとして捉えることが大切です。

検証の際に注意したいのは、見込んだとおりの変化が得られなかった場合の扱いです。効果が見られなかった結果を隠したり、都合の良い数値だけを選んで報告したりすると、長期的には信頼を損ないます。見込みが外れた場合は、なぜ外れたのかを、レッスン3で扱った観察の手法を使って改めて確かめ、次の改善につなげる材料として扱いましょう。うまくいかなかった結果も、正直に共有し、次に生かす姿勢が、継続的な運用を支える土台になります。

flowchart LR
    A[観察して問題を見つける] --> B[改善案を提案する]
    B --> C[改善を実施する]
    C --> D[定量データで効果を確かめる]
    D --> A

この図は、観察・提案・実施・検証という 4 つの段階が、1 回で終わるのではなく、繰り返しのサイクルとして回り続けることを示しています。検証の結果が、次の観察の材料にもなり、サイクルが途切れることなく続いていく点が重要です。

デザイン部門と事業部門の距離

UX の取り組みを組織で継続する際、しばしば課題になるのが、デザインを担当する部門と、事業の成果を担う部門とのあいだの距離です。デザインを担当する部門は、利用者にとっての使いやすさを重視する立場にあり、事業部門は、限られた予算と期限の中で成果を出す立場にあります。両者の目線が異なるため、優先順位についての意見が食い違うことも珍しくありません。

この距離を縮めるために有効なのが、ここまで説明してきた「何が、どれだけ変わるか」という書き方です。使いやすさの向上を、事業部門にとっても意味のある言葉、つまり完了率の改善や、問い合わせ対応の負担軽減といった、具体的な変化として示すことで、両者は同じ土台の上で会話できるようになります。

もう 1 つ有効なのは、デザインを担当する部門が、早い段階から事業部門を巻き込むことです。改善案がすっかり固まってから事業部門に説明するのではなく、レッスン3で扱ったユーザビリティテストの実施計画を立てる段階や、レッスン7で扱ったサービスブループリントを描く段階から、事業部門の担当者に同席してもらうと、完成した結果だけを見せられるよりも、変化の背景にある理由が伝わりやすくなります。共に観察した経験は、あとから資料で説明するよりも、はるかに強い説得力を持ちます。

🔰 初学者の方へ デザインを担当する部門と事業部門の距離を、一度の会議で完全に縮めることは難しいものです。小さな改善を積み重ね、その都度、変化を具体的な言葉で共有し続けることが、長い目で見て両者の信頼関係を築く近道になります。

成熟度の段階

組織における UX の取り組みは、段階を追って育っていくものです。おおまかな段階として、次のような整理ができます。

個人の気づきの段階：特定の担当者が、自発的に使いにくさに気づき、個別に改善する段階
手法の定着の段階：ヒューリスティック評価やユーザビリティテストといった手法が、チームの中で繰り返し使われるようになる段階
組織的な運用の段階：定期的な点検の仕組みが整い、複数の部門を巻き込んで運用される段階
前提としての定着の段階：新しい画面や仕組みを作る最初の段階から、使いやすさとアクセシビリティが前提として組み込まれる段階

多くの組織は、最初から 4 段階目を目指そうとして、計画が大きくなりすぎ、動き出せなくなってしまいます。まずは 1 段階目、身近な範囲での小さな気づきと改善から始め、その積み重ねを周囲に見せながら、少しずつ次の段階へと進んでいく現実的な進め方が推奨されます。

段階	特徴	次の段階への鍵
1．個人の気づき	特定の担当者が自発的に気づき、個別に改善する	改善の成果を周囲に見せ、関心を持つ人を増やす
2．手法の定着	ヒューリスティック評価やユーザビリティテストがチームで繰り返し使われる	実施の手順を型として整理し、誰でも再現できるようにする
3．組織的な運用	定期的な点検の仕組みが整い、複数の部門を巻き込んで運用される	定量データによる効果測定を仕組みに組み込む
4．前提としての定着	新しい取り組みの最初の段階から、使いやすさとアクセシビリティが前提になる	定着した状態を保ちながら、次の担い手を育てる

この表からわかるとおり、次の段階に進む鍵は、段階ごとに異なります。いまの自分たちの組織がどの段階にあるかを見極め、その段階に合った次の一歩を選ぶことが、遠回りに見えて、実は最も着実な進み方です。

💡 ポイント いまの自分たちの組織が、どの段階にあるかを把握することも、次の一歩を考えるうえで役立ちます。焦って先の段階を目指すよりも、いまの段階でできることを着実に積み重ねる姿勢のほうが、長く続く取り組みにつながります。

生成 AI をリサーチに使うときの線引き

近年、生成 AI をユーザビリティ評価や情報設計の作業に取り入れる動きも見られます。ヒューリスティック評価の観点の洗い出しを補助させる、大量の自由記述の回答を要約させる、といった使い方は、作業の効率を高めるうえで有効です。

一方で、生成 AI の出力を、実際の利用者の声そのものであるかのように扱うことには注意が必要です。生成 AI は、実在する利用者を観察したわけではなく、学習した情報にもとづいてもっともらしい文章を作り出す仕組みです。実際の利用者の行動や発言を、生成 AI が作った文章で置き換えてしまうと、レッスン1で学んだ「感想と観察の違い」という土台そのものが崩れてしまいます。

生成 AI を使う際の線引きとして、次のような整理が役立ちます。

向いている使い方：観察記録の要約、評価の観点の洗い出しの補助、報告資料の下書き作成
向いていない使い方：実際の利用者の代わりとして意見を生成させる、観察していない行動をもっともらしく描写させる

⚠️ 注意 生成 AI は、あくまで人間が行った観察を効率化する補助として使う道具です。観察そのものを代替する道具ではないという線引きを、組織の中で共有しておくことが大切です。

修了後の学習方向

本コースでは、UX を「感性の話」ではなく「測って直す話」として、8 つのレッスンを通じて扱ってきました。ヒューリスティック評価とユーザビリティテストという 2 つの評価手法、情報設計と仕様の書き方という 2 つの設計技法、アクセシビリティという設計の前提、そしてサービスブループリントという裏側までを含めた視点。最後のこのレッスンでは、それらを継続的な仕組みへとつなげる考え方を扱いました。

本コースを修了したあとの学習の方向としては、次のような広がりが考えられます。

まず、本コースで扱った技法を、実際の自分の業務の中で、小さな規模から試してみることです。技法は、知識として知っているだけでは身につかず、実際に手を動かして初めて、自分のものになります。身近な同僚数名を相手にしたカードソーティングや、たった 1 つのタスクだけを設計した小さなユーザビリティテストからでも、十分に始められます。

次に、WCAG や JIS X 8341-3 といった規格の原文にあたり、レッスン6で扱った内容をさらに深めることです。規格は改訂されることがあるため、最新の公式情報を確認する習慣を持つとよいでしょう。特にアクセシビリティは、社会的な関心の高まりとともに、関連する制度や解釈が今後も更新されていく領域です。

また、情報設計やユーザビリティ評価をより体系的に学びたい場合は、この分野を扱う専門書にあたることも有効です。次の参考資料に、学びを深めるための書籍や公的資料をまとめていますので、あわせて活用してください。

最後に、本コースが扱わなかった、利用者像を具体的に描く技法や、体験全体を道のりとして設計する技法についても、関心があれば、それぞれを専門に扱うコースで学びを広げることをおすすめします。本コースで身につけた「観察と基準で事実を特定する」という姿勢は、そうした別の技法を学ぶ際にも、共通の土台として役立つはずです。

まとめ

このレッスンでは、以下のことを学びました。

単発の改善で終わらせず、小さな点検を継続することで、問題が大きくなる前に手を打てる
定量データは変化の大きさをつかむのに向き、定性データは原因を説明するのに向く。両者を組み合わせることが実務では効果的である
改善提案は、観察された事実・想定される原因・変化の見込みの 3 つを明記することで、意思決定の材料になる
改善提案を通したあとは、定量データで実際の効果を確かめ、次の改善提案の説得力につなげる
デザイン部門と事業部門の距離は、変化を具体的な言葉で共有し続けることで縮められる
UX の取り組みは、個人の気づきから、前提としての定着まで、段階を追って組織に育っていく
生成 AI は観察を効率化する補助として使い、実際の利用者の代わりに意見を生成させることは避ける

本コースは、これで終わりです。使いにくさは、感想ではなく、観察と基準によって特定できる事実です。センスに頼るのではなく、ここまで学んできた手順を、明日からの業務の中で、まずは小さく試してみてください。使いやすさを事実として扱う積み重ねが、やがて組織全体の力になっていきます。ここまで学習を続けてこられたことに、敬意を表します。

確認クイズ

このレッスンの理解度をチェックしましょう。