「なんとなく使いにくい」を論理的に説明する⽅法 〜プロダクトエンジニアとしてUXを議論できる第⼀歩〜 2025-08-21 Product Engineer Session #4 みきてぃ / きたはら (mkitahara) 

名前 ● みきてぃ / きたはら (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 

プロダクトエンジニアとは？ 4 顧客の成功を技術で実現する存在。プロダクトの成功全体にコミットする存在。 プロダクトエンジニアは、3つの主要な要素に分解できる ● 技術⼒ ○ 単にコードを書くスキルだけでなく、スケーラブルなシステム設計や、 開発を効率化する⽣産性の追求して、ユーザーに価値を届けるための技術的な意思決定を⾏う ● ドメイン ○ 単なる要件をこなすのではなく、顧客が本当に必要としている価値は何かを理解し、 技術でそれをどう実現するかを判断できる ● UXデザイン ○ ⾒た⽬の美しさだけでなく、顧客の感情や⾏動を理解し、タスクの達成を助ける使いやすさ を追求する 

UXデザイン の能⼒を獲得するのは難しい？ 5 エンジニアが直⾯するUXの壁 ● 「感覚」でしか話せない ○ 知識が不⾜しているため、「なんとなく使いにくい」「なんかデザインがしっくりこない」 といった曖昧なフィードバックしかできず、理論的な議論ができない ● 「何を評価すべきか」がわからない ○ 「良いUX」が何を指すのか不明確で、どこから⼿を付けていいか分からない。 評価が主観的になり、客観的な根拠に⽋ける 

プロダクトエンジニアがUXに関わるべき理由 6 UXデザインを専⾨家であるデザイナーに依頼するのも賢明な判断ではあるが プロダクトエンジニアはUXの「受け⼿」ではなく、「共創者」として深く関わるべきである ● 顧客理解の深化 ○ 単なる仕様書に書かれた機能ではなく、顧客の課題を解決する最適な技術ソリューションを 提案‧検討できるようになる ● 議論の質の向上 ○ デザイナーとの対話が「なんとなく使いにくい」といった曖昧なものから、 「このインタラクションではタスク完了率が下がる可能性がある」といった論理的かつ具体的な 議論に変わる ● ⼿戻りの削減 ○ 実装段階でUX上の問題に早期に気づくことができ、開発後の⼤きな⼿戻りを防ぎ、より効率的に プロダクトを改善できる UXについて知識も経験もない私でも、なんとかUXの検討する⽅法をお話します 

知識や経験がなくても なんとかUXの検討する⽅法 7 

知識がなくても、UXについて検討するには 8 ● プロセス１：UXを評価できるモノを作成する ● プロセス２：UXの評価軸を決める ● プロセス３：UXを評価する 

UXを検討する⽅法 プロセス1 UXを評価できるモノを作成する 9 

UXを評価できるモノを作成する 10 ● ステップ1：解決すべき課題とゴールを定義する ● ステップ2：ユーザーの旅を可視化する ● ステップ3：評価指標を定める ● ステップ4：評価を実践し、⾏動に移す 

UXを評価できるモノを作成する：ステップ1. 解決すべき課題とゴールを定義する 11 ■ 考えること ● プロダクトの根幹から、誰のどんな課題を解決するのかを明確する。 ● 抽象的な課題を、ユーザーが達成する具体的なコンバージョンに落とし込みます。 ● CPM (Customer-Problem Fit) → PSM (Problem-Solution Fit) → PMF (Product-Market Fit) の仮説があると検討しやすい ■ 成果物 ● 課題ステートメント： ○ 簡潔な⾔葉で、解決すべき課題を定義 ● コンバージョン⽬標： ○ 課題を解決した状態を、ユーザーの⾏動（例：有料プラン登録、タスク完了）で明確 にする 

UXを評価できるモノを作成する：ステップ2. ユーザーの旅を可視化する 12 ■ 考えること ● ユーザーがそこにたどり着くまでの⼀連の⾏動を可視化する ○ どの段階でUXの問題が起きているかを⾒つけやすくなる ■ 成果物 ● プロダクトのカスタマーライフサイクル ： ○ プロダクトの「新規獲得」「継続」「拡⼤」「解約」といった⼤きなフェーズで、 各ステータスへ切り替わる条件を明確にする ○ 時系列を含めると考えやすい (初回起動、2週間後、1ヶ⽉後 etc.) ● ユーザーストーリー： ○ 「〜したいので、〜する」という形式で、ユーザーの⽬的と⾏動を記述 ● 画⾯遷移図： ○ ユーザーストーリーに沿って、具体的な画⾯の流れを図⽰する 

UXを評価できるモノを作成する：ステップ3. 評価指標を定める 13 ■ 考えること ● UXの良し悪しを客観的なデータで議論するために、具体的な評価指標を設定する ○ 評価指標は、ユーザーストーリーの⾏動や画⾯単位で設定すると良い ■ 成果物 ● UX評価シート ： ○ タスク名：評価したい具体的なタスク ○ 評価指標 ■ タスク完了率：ゴールに到達したユーザーの割合 ■ タスク完了時間：完了までにかかった時間 ■ エラー率：タスク中に発⽣したエラーの回数 

UXを評価できるモノを作成する：ステップ4.評価を実践し、⾏動に移す 14 ■ 考えること ● 評価指標を基に改善施策を実施し、その効果を検証する。 ○ その結果によって、次の⾏動を決定する ■ 成果物 ● 評価結果レポート： ○ 施策実施前後の評価指標の変化の仮説まとめと、定性的なフィードバック ■ ネクストアクション ● 評価指標が改善した(しそうだと⾃信が持てる)場合： ○ 施策を本番環境に反映して、評価指標を検証する ● 評価指標が改善しない(する⾃信が持てない)場合： ○ プロダクト案を⾒直し ○ 必要あれば、プロセス1〜3の成果物も⾒直す 

⼀旦まとめ：UXを評価できるモノを作成する 15 UXを評価できるものを作成するプロセスは、抽象的な課題を具体的な成果物に 落とし込み、実践と改善のサイクルを回す ● ゴール設定： ○ 「解決すべき課題」を起点に「達成すべきゴール」を明確する。 ● 可視化: ○ ゴール達成までのユーザーの⾏動を可視化することで、課題の所在を把握できる ● 測定: ○ ユーザーの⾏動を客観的な指標で測定することで、UXの良し悪しをデータで議論できる ● ⾏動: ○ 評価結果に基づいて改善と検証を繰り返し、プロダクトの品質を継続的に向上させる 

UXを検討する⽅法 プロセス2 UXの評価軸を決める 16 

UXの評価軸 17 UXを評価する軸にはいくつかあるが、代表的な3つの⼿法をピックアップ。 ● HEARTフレームワーク ● ニールセンのヒューリスティック評価 ● ISO品質モデル 

UX評価基準案：GoogleのHEARTフレームワーク を 参考 18 ユーザーがプロダクトを利⽤する体験全体を評価するためのフレームワーク。 ユーザーの感情や⾏動を包括的に測定する ■ 満⾜度 (Happiness)： ● ユーザーの態度や感情を測定。アンケートやNPS（ネット‧プロモーター‧スコア）などを通じて、「製品をどれだけ気 に⼊っているか」を評価。 ■ エンゲージメント (Engagement)： ● ユーザーが製品にどれだけ深く関わっているかを測定。 ● 週当たりの訪問回数やアップロードされた写真の数など、⾏動の頻度や強度を指標とする。 ■ 採⽤率 (Adoption)： ● 新規ユーザーや、特定の機能を使い始めたユーザーの数を測定。 ● 新機能がどれだけ受け⼊れられているかを知るのに役⽴つ。 ■ リテンション (Retention)： ● 既存ユーザーが製品にどれだけ留まっているかを測定。 ● ユーザーが製品を使い続ける割合を⾒ることで、製品の⻑期的な価値を評価。 ■ タスク成功 (Task Success)： ● ユーザーがタスクをどれだけ効率的かつ正確に完了できたかを測定。 ● タスク完了時間やエラー率といった、従来のUX指標が含まれる。 

UI評価基準案：ニールセンのヒューリスティック評価を参考 19 UIの使いやすさや、⾒た⽬‧操作性の問題点を素早く⾒つけるための基準。 5項⽬に絞って簡易的に評価することも可能 ■ 学習しやすさ (Learnability)： ● 初めてのユーザーがどれだけ早く操作⽅法を習得できるかを評価する ● 直感的なUIや分かりやすいチュートリアルが重要 ■ 効率性 (Efficiency)： ● 熟練したユーザーが、ショートカットキーや効率的なワークフローを使ってタスクをどれだけ迅速にこなせるかを評価。 ■ 記憶のしやすさ (Memorability)： ● しばらく使っていないユーザーが、⼀貫したデザインや分かりやすいアイコンによって、どれだけ簡単に操作を 思い出せるかを評価。 ■ エラー (Errors)： ● ユーザーが誤操作を起こしにくい設計になっているか、またエラーが発⽣した際にどれだけ簡単に回復できるかを評価。 ■ 主観的満⾜度 (Satisfaction)： ● ユーザーがデザインや操作性を通じて、どれだけ満⾜感や⼼地よさを得られるかを評価。 

プロダクトの品質特性：品質向上のため、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）: ユーザーがプロダクトを利⽤した結果、どれだけ満⾜したか。感情も含まれます。 

⼀旦まとめ：UX‧UIの評価基準 21 様々なUX‧UI評価基準が存在しますが、それぞれに共通する項⽬があり。 重要なのは、全ての基準を網羅することではなく プロダクトチーム内で、評価項⽬をピックアップする ● ユーザーの⾏動や事業のKPIと紐づく項⽬を選択する。 ○ 例：「新規ユーザーの獲得」が重要なら、 　　　HEARTの『採用率』やニールセンの『学習しやすさ』を優先的に評価する 評価軸をチーム全員で共有すること ● UI/UXに関する議論を「感覚的」なものから「論理的」なものに変えるには、共通の評価軸が必要 ● 全員が同じ基準で評価することで、建設的な対話が可能になり、結果としてプロダクトの品質が向上 

UXを検討する⽅法 プロセス3 UXを評価する 22 

UXの評価⼿法 23 UXを評価するにはいくつかの⽅法があるが、代表的な3つの⼿法をピックアップ。 ● 評価⽅法1：ヒューリスティック評価 ● 評価⽅法2：認知的ウォークスルー ● 評価⽅法3：ユーザビリティテスト 

UXの評価⼿法：評価⽅法 1. ヒューリスティック評価 24 ■ 概要 ● UXの専⾨家が、あらかじめ定められた原則に基づいてUIを評価する。 ■ 特徴 ● ユーザーを必要とせず、専⾨家の知⾒に頼って⾏われる。 ■ メリット: ● 迅速‧低コスト: 時間や費⽤を抑えて、素早く実施できる。 ● 早期発⾒: 開発のごく初期段階、プロトタイプやモックアップの時点でも実施可能。 ■ デメリット: ● 主観に依存: 評価者の経験や知識に結果が⼤きく左右される。 ● ユーザーとの乖離: 専⾨家の視点と実際のユーザーの感覚が異なる場合がある。 

UXの評価⼿法：評価⽅法 2. 認知的ウォークスルー 25 ■ 概要 ● ユーザーが初めてタスクを完了する際の思考プロセスを、ステップ‧バイ‧ステップ (⽬標設定→探査 →選択→判断 )でシミュレーションをする ● 評価者がユーザーの「⼼の声」を再現しながら、UIの問題点を洗い出す ■ 特徴 ● ユーザーを必要とせず、評価者⾃⾝がユーザーになりきってタスクを実⾏する。 ■ メリット: ● 「なぜ」を解明: 「なぜここでユーザーは迷うのか？」という具体的な原因を深く掘り下げられる。 ● 学習しやすさの評価: 初めてのユーザーがUIをどれだけスムーズに使い始められるか、 という観点に特化している。 ● 低コスト: 専⾨家数名で実施できるため、コストを抑えられる。 ■ デメリット: ● 評価者の主観: ヒューリスティック評価と同様に、評価者の知識や経験が結果に影響する。 ● タスク以外の問題は⾒つけにくい: あらかじめ設定したタスク以外の問題点を⾒つけにくい。 

UXの評価⼿法：評価⽅法 3. ユーザビリティテスト 26 ■ 概要 ● 実際のユーザーにプロダクトを操作してもらい、その⾏動や発⾔を観察する ● UIの使いやすさや問題点を直接的に把握できる ■ 特徴 ● 実際のユーザーが参加し、現実の利⽤状況に近い形で評価を⾏う ■ メリット: ● 最も信頼性が⾼い: 実際のユーザーの⾏動に基づいているため、最も客観的で信頼性の⾼い結果が 得られる。 ● 予測不能な発⾒: 評価者が事前に想定していなかった問題や、ユーザーの新たなニーズを発⾒できる ● チームの共感: チームメンバーがユーザーの苦労を直接観察することで、プロダクトに対する共通の 課題認識を持てる。 ■ デメリット: ● ⾼コスト‧時間: ユーザーの募集やテスト環境の準備に、時間と費⽤がかかる。 ● 環境の制約: テスト環境下での⾏動が、必ずしも⾃然な利⽤状況を反映しているとは限らない。 

⼀旦まとめ：UXの評価⽅法 27 プロダクトエンジニアは、まず認知的ウォークスルーから始めてみる ● ヒューリスティック評価は、UXの専⾨的な知識が必要な場合がある。 ● しかし、認知的ウォークスルーは、ユーザーの視点に⽴つことで、専⾨知識がなくても実施可能。 「なぜユーザーはここで迷うのか？」という問いは、エンジニアの論理的な思考と相性が良い。 ● プロトタイプの時点で認知的ウォークスルーを繰り返し、ある程度課題が解決されたら、 次のステップとしてユーザビリティテストを検討する。 このステップを踏むことで、UXの評価が「センス」から「論理」へと変わり、 より効率的で質の⾼いプロダクト開発につながります。 

UXの検討する⽅法 おまけ 28 

各項⽬を簡易的に評価を⾏い、改善に活かす 29 ■ 評価のプロセス ● 評価項⽬の設定: ○ UIの学習しやすさ、タスクの成功度など、評価したい項⽬を明確にする。 ● 点数付けと理由の記述: ○ 各項⽬を10段階で評価する。 ○ 点数は主観的で良いが、特に6点以下の場合はその理由を詳細に書き込んでもらう。 ● 分析と改善: 得られた点数と理由を分析: ○ ⾼得点の理由: プロダクトの強みとして⾔語化し、マーケティングや今後の開発に活かす ○ 低得点の理由: 最優先の課題として改善策を検討し、次の開発サイクルに組み込む ■ 評価の基準と理由の重要性 ● 10〜9点：⾮常に優れている ○ ユーザーにとって⾮常に直感的で、期待をはるかに超える体験が提供されている状態 ● 7〜8点：合格点 ○ ⼤きな問題なく、⽬的を達成できる状態 ● 6〜1点：改善点あり ○ ユーザーがタスクを達成する上で、明らかに課題や不満を抱えている状態 

まとめ 30 

まとめ 31 ■ UXはプロダクトの品質を左右する技術 ● UXデザインには専⾨性が求められるが、特別な知識がなくてもできることはたくさんある ● UXはプロダクトの品質に⼤きく影響し、顧客の課題解決に直接貢献する ■検証の質を⾼める事前準備 ● プロダクトを実際のユーザーに当てて検証することが最も重要である ● しかし、提供前に仮説を⽴て、事前検証を⾏うことで、より効果的な⽰唆を得られる ■ まずは、⼀歩踏み出してみよう ● UXに苦⼿意識があっても、できるところから、まずはやってみる。 ● プロダクトと同様、試⾏錯誤しながら、少しずつ改善していく ● 専⾨家と⼀緒にこのプロセスを実践できると、さらに⼤きな成果が得られる 技術⼒だけでなく、UXデザインの視点を持つことで 「ユーザーに真の価値を届けるプロダクトの作り⼿」へ 

ご静聴ありがとうございました 32