「なんとなく使いにくい」を論理的に説明する方法 〜プロダクトエンジニアとしてUXを議論できる第一歩〜

2025-08-21 Product Engineer Session #4
https://pesess.connpass.com/event/360685/

Transcript

1. 「なんとなく使いにくい」を論理的に説明する⽅法 〜プロダクトエンジニアとしてUXを議論できる第⼀歩〜 2025-08-21 Product Engineer Session #4 みきてぃ / きたはら (mkitahara)
2. 名前 • みきてぃ / きたはら (mkitahara) ：@mikity01985 出⾝ • 静岡県 - 埼⽟県 - 千葉県 ⾃⼰紹介 職能 • エンジニアリングマネージャー / テックリード / Androidアプリ開発 / プロダクトマネージャー 職歴 • FinTech会社 (2023/07〜 ) ◦ モバイルアプリチームのエンジニアリングマネージャーを中⼼にいろいろ ◦ 2024/10 より新規事業のテックリード(Next.js、Spring Boot) を中⼼にいろいろ ◦ 新規事業にまつわるプロジェクトマネジメント、ピープルマネジメント、採⽤、広報 もちょいちょい --------------------------------- • SES会社 (3年9ヶ⽉) → 開発受託会社 2社 (1年、1年9ヶ⽉) → EdTech会社 (5年9ヶ⽉) → 現職 ◦ 2011/04 に 新卒未経験でIT業界へ。研修でAndroidアプリ開発に出会う ◦ 受託企業はそれぞれ10名以下。なんでも⾃分でやらざるをえない環境 を経験 ◦ EdTechでは出向‧業務委託のみ 30名程度の会社から 社員200⼈超えの組織の成⻑を経験 ◦ Androidアプリ開発を中⼼にサーバーサイド(PHP Ruby on Rails)、CRE、 PO、チーム責任者を経験 名前とアイコン 変えました！ 2
3. プロダクトエンジニアとプロダクトづくり 今回のテーマ 3
4. プロダクトエンジニアとは？ 4 顧客の成功を技術で実現する存在。プロダクトの成功全体にコミットする存在。 プロダクトエンジニアは、3つの主要な要素に分解できる • 技術⼒ ◦ 単にコードを書くスキルだけでなく、スケーラブルなシステム設計や、 開発を効率化する⽣産性の追求して、ユーザーに価値を届けるための技術的な意思決定を⾏う • ドメイン ◦ 単なる要件をこなすのではなく、顧客が本当に必要としている価値は何かを理解し、 技術でそれをどう実現するかを判断できる • UXデザイン ◦ ⾒た⽬の美しさだけでなく、顧客の感情や⾏動を理解し、タスクの達成を助ける使いやすさ を追求する
5. UXデザイン の能⼒を獲得するのは難しい？ 5 エンジニアが直⾯するUXの壁 • 「感覚」でしか話せない ◦ 知識が不⾜しているため、「なんとなく使いにくい」「なんかデザインがしっくりこない」 といった曖昧なフィードバックしかできず、理論的な議論ができない • 「何を評価すべきか」がわからない ◦ 「良いUX」が何を指すのか不明確で、どこから⼿を付けていいか分からない。 評価が主観的になり、客観的な根拠に⽋ける
6. プロダクトエンジニアがUXに関わるべき理由 6 UXデザインを専⾨家であるデザイナーに依頼するのも賢明な判断ではあるが プロダクトエンジニアはUXの「受け⼿」ではなく、「共創者」として深く関わるべきである • 顧客理解の深化 ◦ 単なる仕様書に書かれた機能ではなく、顧客の課題を解決する最適な技術ソリューションを 提案‧検討できるようになる • 議論の質の向上 ◦ デザイナーとの対話が「なんとなく使いにくい」といった曖昧なものから、 「このインタラクションではタスク完了率が下がる可能性がある」といった論理的かつ具体的な 議論に変わる • ⼿戻りの削減 ◦ 実装段階でUX上の問題に早期に気づくことができ、開発後の⼤きな⼿戻りを防ぎ、より効率的に プロダクトを改善できる UXについて知識も経験もない私でも、なんとかUXの検討する⽅法をお話します
7. 知識や経験がなくても なんとかUXの検討する⽅法 7
8. 知識がなくても、UXについて検討するには 8 • プロセス１：UXを評価できるモノを作成する • プロセス２：UXの評価軸を決める • プロセス３：UXを評価する
9. UXを検討する⽅法 プロセス1 UXを評価できるモノを作成する 9
10. UXを評価できるモノを作成する 10 • ステップ1：解決すべき課題とゴールを定義する • ステップ2：ユーザーの旅を可視化する • ステップ3：評価指標を定める • ステップ4：評価を実践し、⾏動に移す
11. UXを評価できるモノを作成する：ステップ1. 解決すべき課題とゴールを定義する 11 ▪ 考えること • プロダクトの根幹から、誰のどんな課題を解決するのかを明確する。 • 抽象的な課題を、ユーザーが達成する具体的なコンバージョンに落とし込みます。 • CPM (Customer-Problem Fit) → PSM (Problem-Solution Fit) → PMF (Product-Market Fit) の仮説があると検討しやすい ▪ 成果物 • 課題ステートメント： ◦ 簡潔な⾔葉で、解決すべき課題を定義 • コンバージョン⽬標： ◦ 課題を解決した状態を、ユーザーの⾏動（例：有料プラン登録、タスク完了）で明確 にする
12. UXを評価できるモノを作成する：ステップ2. ユーザーの旅を可視化する 12 ▪ 考えること • ユーザーがそこにたどり着くまでの⼀連の⾏動を可視化する ◦ どの段階でUXの問題が起きているかを⾒つけやすくなる ▪ 成果物 • プロダクトのカスタマーライフサイクル ： ◦ プロダクトの「新規獲得」「継続」「拡⼤」「解約」といった⼤きなフェーズで、 各ステータスへ切り替わる条件を明確にする ◦ 時系列を含めると考えやすい (初回起動、2週間後、1ヶ⽉後 etc.) • ユーザーストーリー： ◦ 「〜したいので、〜する」という形式で、ユーザーの⽬的と⾏動を記述 • 画⾯遷移図： ◦ ユーザーストーリーに沿って、具体的な画⾯の流れを図⽰する
13. UXを評価できるモノを作成する：ステップ3. 評価指標を定める 13 ▪ 考えること • UXの良し悪しを客観的なデータで議論するために、具体的な評価指標を設定する ◦ 評価指標は、ユーザーストーリーの⾏動や画⾯単位で設定すると良い ▪ 成果物 • UX評価シート ： ◦ タスク名：評価したい具体的なタスク ◦ 評価指標 ▪ タスク完了率：ゴールに到達したユーザーの割合 ▪ タスク完了時間：完了までにかかった時間 ▪ エラー率：タスク中に発⽣したエラーの回数
14. UXを評価できるモノを作成する：ステップ4.評価を実践し、⾏動に移す 14 ▪ 考えること • 評価指標を基に改善施策を実施し、その効果を検証する。 ◦ その結果によって、次の⾏動を決定する ▪ 成果物 • 評価結果レポート： ◦ 施策実施前後の評価指標の変化の仮説まとめと、定性的なフィードバック ▪ ネクストアクション • 評価指標が改善した(しそうだと⾃信が持てる)場合： ◦ 施策を本番環境に反映して、評価指標を検証する • 評価指標が改善しない(する⾃信が持てない)場合： ◦ プロダクト案を⾒直し ◦ 必要あれば、プロセス1〜3の成果物も⾒直す
15. ⼀旦まとめ：UXを評価できるモノを作成する 15 UXを評価できるものを作成するプロセスは、抽象的な課題を具体的な成果物に 落とし込み、実践と改善のサイクルを回す • ゴール設定： ◦ 「解決すべき課題」を起点に「達成すべきゴール」を明確する。 • 可視化: ◦ ゴール達成までのユーザーの⾏動を可視化することで、課題の所在を把握できる • 測定: ◦ ユーザーの⾏動を客観的な指標で測定することで、UXの良し悪しをデータで議論できる • ⾏動: ◦ 評価結果に基づいて改善と検証を繰り返し、プロダクトの品質を継続的に向上させる
16. UXを検討する⽅法 プロセス2 UXの評価軸を決める 16
17. UXの評価軸 17 UXを評価する軸にはいくつかあるが、代表的な3つの⼿法をピックアップ。 • HEARTフレームワーク • ニールセンのヒューリスティック評価 • ISO品質モデル
18. UX評価基準案：GoogleのHEARTフレームワーク を 参考 18 ユーザーがプロダクトを利⽤する体験全体を評価するためのフレームワーク。 ユーザーの感情や⾏動を包括的に測定する ▪ 満⾜度 (Happiness)： • ユーザーの態度や感情を測定。アンケートやNPS（ネット‧プロモーター‧スコア）などを通じて、「製品をどれだけ気 に⼊っているか」を評価。 ▪ エンゲージメント (Engagement)： • ユーザーが製品にどれだけ深く関わっているかを測定。 • 週当たりの訪問回数やアップロードされた写真の数など、⾏動の頻度や強度を指標とする。 ▪ 採⽤率 (Adoption)： • 新規ユーザーや、特定の機能を使い始めたユーザーの数を測定。 • 新機能がどれだけ受け⼊れられているかを知るのに役⽴つ。 ▪ リテンション (Retention)： • 既存ユーザーが製品にどれだけ留まっているかを測定。 • ユーザーが製品を使い続ける割合を⾒ることで、製品の⻑期的な価値を評価。 ▪ タスク成功 (Task Success)： • ユーザーがタスクをどれだけ効率的かつ正確に完了できたかを測定。 • タスク完了時間やエラー率といった、従来のUX指標が含まれる。
19. UI評価基準案：ニールセンのヒューリスティック評価を参考 19 UIの使いやすさや、⾒た⽬‧操作性の問題点を素早く⾒つけるための基準。 5項⽬に絞って簡易的に評価することも可能 ▪ 学習しやすさ (Learnability)： • 初めてのユーザーがどれだけ早く操作⽅法を習得できるかを評価する • 直感的なUIや分かりやすいチュートリアルが重要 ▪ 効率性 (Efficiency)： • 熟練したユーザーが、ショートカットキーや効率的なワークフローを使ってタスクをどれだけ迅速にこなせるかを評価。 ▪ 記憶のしやすさ (Memorability)： • しばらく使っていないユーザーが、⼀貫したデザインや分かりやすいアイコンによって、どれだけ簡単に操作を 思い出せるかを評価。 ▪ エラー (Errors)： • ユーザーが誤操作を起こしにくい設計になっているか、またエラーが発⽣した際にどれだけ簡単に回復できるかを評価。 ▪ 主観的満⾜度 (Satisfaction)： • ユーザーがデザインや操作性を通じて、どれだけ満⾜感や⼼地よさを得られるかを評価。
20. プロダクトの品質特性：品質向上のため、UXを検討できる能⼒は必要である 20 ▪ ISO 9241-11 • 有効さ：⽬的は達成できたのかどうか？と⽬的は意図通りに達成できたのかどうか？ • 効率：⽬的を達成するために費やした資源 (時間など) • 満⾜度：⽬的を達成するための過程および利⽤後の、ユーザーの⾝体的や認知的、感情的な受け⽌め⽅ ▪ ISO/IEC 25010:2023：相互作⽤能⼒（Interaction capability）の副特性 • 習得性 (Learnability)： ◦ ユーザーがどれだけ簡単に操作⽅法を学習できるか。 • ユーザー⽀援 (User assistance)： ◦ ユーザーが⽬標を達成するために、どれだけ適切なガイダンスやヘルプを提供するか。 • ユーザー操作保護 (User error protection)： ◦ ユーザーが誤操作を起こしにくいか、また誤操作した場合の影響を最⼩限に抑えられるか。 • 包括性 (Inclusivity)： ◦ さまざまな背景（年齢、能⼒、⽂化など）を持つユーザーがどれだけ製品を利⽤できるか。 • ユーザーエンゲージメント (User engagement)： ◦ ユーザーインターフェースがどれだけ魅⼒的で、継続的な利⽤を促すか。 ▪ ISO/IEC 25019:2023における「利⽤時の品質」の観点 • 有効性（Effectiveness）: ユーザーが⽬標をどれだけ正確かつ完全に達成できたか。 • 効率性（Efficiency）: ユーザーが⽬標を達成するために、どれだけの労⼒や時間を費やしたか。 • 満⾜度（Satisfaction）: ユーザーがプロダクトを利⽤した結果、どれだけ満⾜したか。感情も含まれます。
21. ⼀旦まとめ：UX‧UIの評価基準 21 様々なUX‧UI評価基準が存在しますが、それぞれに共通する項⽬があり。 重要なのは、全ての基準を網羅することではなく プロダクトチーム内で、評価項⽬をピックアップする • ユーザーの⾏動や事業のKPIと紐づく項⽬を選択する。 ◦ 例：「新規ユーザーの獲得」が重要なら、 　　　HEARTの『採用率』やニールセンの『学習しやすさ』を優先的に評価する 評価軸をチーム全員で共有すること • UI/UXに関する議論を「感覚的」なものから「論理的」なものに変えるには、共通の評価軸が必要 • 全員が同じ基準で評価することで、建設的な対話が可能になり、結果としてプロダクトの品質が向上
22. UXを検討する⽅法 プロセス3 UXを評価する 22
23. UXの評価⼿法 23 UXを評価するにはいくつかの⽅法があるが、代表的な3つの⼿法をピックアップ。 • 評価⽅法1：ヒューリスティック評価 • 評価⽅法2：認知的ウォークスルー • 評価⽅法3：ユーザビリティテスト
24. UXの評価⼿法：評価⽅法 1. ヒューリスティック評価 24 ▪ 概要 • UXの専⾨家が、あらかじめ定められた原則に基づいてUIを評価する。 ▪ 特徴 • ユーザーを必要とせず、専⾨家の知⾒に頼って⾏われる。 ▪ メリット: • 迅速‧低コスト: 時間や費⽤を抑えて、素早く実施できる。 • 早期発⾒: 開発のごく初期段階、プロトタイプやモックアップの時点でも実施可能。 ▪ デメリット: • 主観に依存: 評価者の経験や知識に結果が⼤きく左右される。 • ユーザーとの乖離: 専⾨家の視点と実際のユーザーの感覚が異なる場合がある。
25. UXの評価⼿法：評価⽅法 2. 認知的ウォークスルー 25 ▪ 概要 • ユーザーが初めてタスクを完了する際の思考プロセスを、ステップ‧バイ‧ステップ (⽬標設定→探査 →選択→判断 )でシミュレーションをする • 評価者がユーザーの「⼼の声」を再現しながら、UIの問題点を洗い出す ▪ 特徴 • ユーザーを必要とせず、評価者⾃⾝がユーザーになりきってタスクを実⾏する。 ▪ メリット: • 「なぜ」を解明: 「なぜここでユーザーは迷うのか？」という具体的な原因を深く掘り下げられる。 • 学習しやすさの評価: 初めてのユーザーがUIをどれだけスムーズに使い始められるか、 という観点に特化している。 • 低コスト: 専⾨家数名で実施できるため、コストを抑えられる。 ▪ デメリット: • 評価者の主観: ヒューリスティック評価と同様に、評価者の知識や経験が結果に影響する。 • タスク以外の問題は⾒つけにくい: あらかじめ設定したタスク以外の問題点を⾒つけにくい。
26. UXの評価⼿法：評価⽅法 3. ユーザビリティテスト 26 ▪ 概要 • 実際のユーザーにプロダクトを操作してもらい、その⾏動や発⾔を観察する • UIの使いやすさや問題点を直接的に把握できる ▪ 特徴 • 実際のユーザーが参加し、現実の利⽤状況に近い形で評価を⾏う ▪ メリット: • 最も信頼性が⾼い: 実際のユーザーの⾏動に基づいているため、最も客観的で信頼性の⾼い結果が 得られる。 • 予測不能な発⾒: 評価者が事前に想定していなかった問題や、ユーザーの新たなニーズを発⾒できる • チームの共感: チームメンバーがユーザーの苦労を直接観察することで、プロダクトに対する共通の 課題認識を持てる。 ▪ デメリット: • ⾼コスト‧時間: ユーザーの募集やテスト環境の準備に、時間と費⽤がかかる。 • 環境の制約: テスト環境下での⾏動が、必ずしも⾃然な利⽤状況を反映しているとは限らない。
27. ⼀旦まとめ：UXの評価⽅法 27 プロダクトエンジニアは、まず認知的ウォークスルーから始めてみる • ヒューリスティック評価は、UXの専⾨的な知識が必要な場合がある。 • しかし、認知的ウォークスルーは、ユーザーの視点に⽴つことで、専⾨知識がなくても実施可能。 「なぜユーザーはここで迷うのか？」という問いは、エンジニアの論理的な思考と相性が良い。 • プロトタイプの時点で認知的ウォークスルーを繰り返し、ある程度課題が解決されたら、 次のステップとしてユーザビリティテストを検討する。 このステップを踏むことで、UXの評価が「センス」から「論理」へと変わり、 より効率的で質の⾼いプロダクト開発につながります。
28. UXの検討する⽅法 おまけ 28
29. 各項⽬を簡易的に評価を⾏い、改善に活かす 29 ▪ 評価のプロセス • 評価項⽬の設定: ◦ UIの学習しやすさ、タスクの成功度など、評価したい項⽬を明確にする。 • 点数付けと理由の記述: ◦ 各項⽬を10段階で評価する。 ◦ 点数は主観的で良いが、特に6点以下の場合はその理由を詳細に書き込んでもらう。 • 分析と改善: 得られた点数と理由を分析: ◦ ⾼得点の理由: プロダクトの強みとして⾔語化し、マーケティングや今後の開発に活かす ◦ 低得点の理由: 最優先の課題として改善策を検討し、次の開発サイクルに組み込む ▪ 評価の基準と理由の重要性 • 10〜9点：⾮常に優れている ◦ ユーザーにとって⾮常に直感的で、期待をはるかに超える体験が提供されている状態 • 7〜8点：合格点 ◦ ⼤きな問題なく、⽬的を達成できる状態 • 6〜1点：改善点あり ◦ ユーザーがタスクを達成する上で、明らかに課題や不満を抱えている状態
30. まとめ 30
31. まとめ 31 ▪ UXはプロダクトの品質を左右する技術 • UXデザインには専⾨性が求められるが、特別な知識がなくてもできることはたくさんある • UXはプロダクトの品質に⼤きく影響し、顧客の課題解決に直接貢献する ▪検証の質を⾼める事前準備 • プロダクトを実際のユーザーに当てて検証することが最も重要である • しかし、提供前に仮説を⽴て、事前検証を⾏うことで、より効果的な⽰唆を得られる ▪ まずは、⼀歩踏み出してみよう • UXに苦⼿意識があっても、できるところから、まずはやってみる。 • プロダクトと同様、試⾏錯誤しながら、少しずつ改善していく • 専⾨家と⼀緒にこのプロセスを実践できると、さらに⼤きな成果が得られる 技術⼒だけでなく、UXデザインの視点を持つことで 「ユーザーに真の価値を届けるプロダクトの作り⼿」へ
32. ご静聴ありがとうございました 32