ユーザビリティテストを習慣化する - レビュー会駆動 ユーザビリティテスト

「職能を横断するチームでユーザビリティをしっかり確かめて進む文化ってどうやって醸成したらいいの〜〜」という課題に取り組んだログです。
2026/07/07 - プロダクトマネジメントとUI/UXデザインを考える会 vol.3「シン・ユーザビリティテスト」 にて。

Transcript

1. レビュー会駆動 ユーザビリティテスト プラットフォーム開発本部 第3開発部 Developer Productivity Group 古川 純希 プロダクトマネジメントとUI/UXデザインを考える会 vol.3「シン・ユーザビリティテスト」 2026/07/07 🎋 ユーザビリティテストを習慣化する -
2. ⾃⼰紹介 ふるじゅん •前職：Webディレクション・デザイン・実装・解析など幅広く経験 •2023年4⽉ DMM ⼊社。デザインシステム開発と保守運⽤がメイン。 • Developer Productivity Group の Turtle チームにて、チームリーダー / プロダクトオーナー / デザイナー担当 •2025年度 ~ より広範囲な取り組みもちょいちょい... ◦ PF内でのユーザー中⼼設計アプローチ導⼊推進。 ◦ PF-AX 戦略を本部内で推進するグループを兼務。 • X: @design_oldriver 2
3. DMM.comについて 弊社のプロダクトデザイン⽣態系
4. •DMM.com： ◦ 60種以上の多様な事業・サービスを展開 •プラットフォーム開発本部： ◦ 共通基盤・共通機能を提供 •Developer Productivity Group： ◦ プラットフォーム開発の質とスピードを最⼤化 する •私たちのチーム： ◦ DMMプラットフォーム横断のUIUX統⼀機能と してデザインシステムの開発・保守・運⽤を担当 （Turtleチーム） DMM.com と Turtle 4
5. •皆さんが普段さわっている UI の「ボタンやフォー ム、スタイリングをプロダクト間で統⼀するためのガイ ドラインと機能群のキット」のようなもの •DMMプラットフォームのような複数機能・複数ド メインにまたがって使⽤されるケースでは、コアデザイ ンシステム / ローカルデザインシステムと管理レイヤー を分けたりする（ドメイン依存機能、ブランドカラーま で⼲渉しない） •Turtle は DMM プラットフォームのコアデザイン システムにあたり、汎⽤的な機能とスタイリングを管理 している デザインシステムとは 5
6. エンジニアも作った機能の使われ⽅は気になっている 👀 でも放っておいても「UTをやろう」とはなりにくい。 ちゃんとやろうとすると、「デザイナーやリサーチャーが設計するUT」は途端に敷居が⾼い ように感じられてしまう。 ユーザビリティテストに感じるハードル ハードルのイメージ 実態 準備が大変 完璧な設計がないとできないと思いがち 専門知識が必要 認知心理学やプロトコル分析が必要に見える デザイナー・リサーチャーがやるもの 開発者には関係ないと思われがち 6
7. •「開発者だから、現場の開発者のことはわかっている！」は危うい ◦ 案件のタイプ・関係者の多さ・業務フローの違い ◦ ドメインの違い・業務経験の違い •「わかっているつもり」は課題の解像度を下げる • じわじわと利⽤者⽂脈やニーズと離れていき、使いにくい機能を増やすリスク ユーザーとの乖離は⻑期的な理解負債を⽣む 7
8. 速く・安く、 UTの価値をチームで実感する 理解負債を⽣まずに⼿軽にユーザビリティを担保し続けるには？
9. ⽅針 問い：正しいやり⽅は後からいくらでも学習できる。「失敗前提で継続しながら学ぶ UT の MVP 」を根付かせるには？ •本当に使えるかどうかわからないまま、準備コストだけが積み上がるのを防ぎたい ◦ 「UTの時間を確保しよう」「進め⽅を相談しよう」「キャッチアップしよう」… •理解してから動く → 動いてから理解する、の順番に変える ◦ やり⽅やルールを説明して構えられるより、先に最⼩サイズで試し必要性を感じて もらう⽅が説得も容易！ 9
10. UTを広げるには、UTと⾔わない⽅がいいこともある。 「作って使われなかったら悲しいので、早めに触ってもらい反応を⾒ましょう。」 ̶̶抽象的なワードは認識齟齬を⽣みやすい。中学⽣にもわかる⾔葉で！が⼀番通じる！ １）「UTをやろう」と⾔わない 用語 受け取られ方 ユーザビリティテスト 専門家がやるものに見える ユーザーインタビュー 準備が大変そうに見える コンセプトテスト 何をすればいいかわかりにくい 10
11. 追加コストをできる限り払わずにできる仕組みを考える ２）すでにある機会をトリガーにする スクラムイベント どんなイベント？ デイリースタンドアップ（毎日） 小さなつまずきをその日のうちに拾う リファインメント（毎日・適宜） 着手するタスクの優先順位を見直し、内容を具体的に整理・詳細化する スプリントレビュー （火） 成果物と仮説に対して、上長や関係者からフィードバックをもらう ← ここが学びの絶好ポイント！ レトロスペクティブ（火） 前スプリントでわかったことをもとに、提供する価値を決める ← ここまでに学びを得て議論・チケット作成までやりたい！ プランニング（水） スプリントの振り返り 11
12. 既存MTG内でルールに基づいた意思決定を⾏い、適切なゲストを招待するだけ。 ３）思いっきり敷居を下げる 観点 ルール いつやるか ・毎プランニングでゲストを呼ぶ・呼ばないを判断 。 ・スプリントレビューで実施 何を見るか ・確かめたい仮説を言語化し、それを確かめる 「迷いなく使えそうか」「PF 内プロダクトで汎用的に使えそうか」「使い方を誤解させてしまいそうな命名や 仕様はあるか」「活用しようとした時に、不足を感じる・不便に感じていそうな点はあるか」... 誰をよぶか ・仮説を確かめるのに適切なゲストを決め、アポをとる どう判断するか ・スプリントレビュー振り返りにて「迷い・反応」等非言語反応含めチームメンバーで感想戦 。 12
13. 実際にやってみて スプリントレビューでのUT導⼊してみて...
14. チームで利⽤者の反応を確かめながら作ることを当たり前に。 • 毎回ではないものの、スプリントの中に成果物のユーザビリティ課題を察知するトリ ガーポイントを設置でき、チームにとって当たり前 = 習慣になった • やってみると「あれ..!想像通りに使われない！」といったチームの共通理解に繋がり、 利⽤者⽂脈への関⼼が強化された • メンバーから、スプリントレビュー以外の場でも「利⽤者に確かめてみよう」という声 が⽣まれるように • オーナー以外の開発メンバー x 利⽤ユーザーとの関係性が構築され、勝⼿にフィード バックをくれたり、こちらからもヒアリングしたり...という流れが⽣まれた ⼿軽にUCD導⼊の⼀歩を踏み出せた！ 14
15. ユーザビリティテストの習慣化は、正確さよりも継続しやすさが命。 まとめ：UT導⼊には、正確さより継続しやすさが命 今日の話 スモールアクション 正確さより継続しやすさ チームの取り組みのどこに「学びの機会」を作るとレバレッジがきくか？の最小 プランを考えてみる UTと言わない 想定通り使われない課題を見つけ、「運用にのせる前に早めに反応をみてみな い？」と呼びかけてみる すでにある機会をトリガーにする スプリントレビューや関係者との定例にちょっとした「FBもらえる機会 」を仕込ん でみる 15
16. ご清聴ありがとうございました！ 🍺懇親会でもぜひ話しかけてください