12年続くB2DサービスとUXデザイン / UX Design keeps B2D service alive over 12 years

2024/12/09 に UX Bridge vol.11 で発表したものです。

https://uxbridge.connpass.com/event/323573/

「本質的なUXに向き合うことは、顧客への長期的な価値提供に繋がり事業の安定に貢献する」
「顧客と同じ立場をUXデザイナの視点を持って自ら体験することは、その後の様々な判断の品質も速度も上げる」

ということを話しています。

Transcript

1. 12年続くB2DサービスとUXデザイン Yuki Fujisaki DeployGate Inc. Co-founder, CEO 1
2. 今日伝えたいこと UXデザインに注力することには、継続する事業を築くほどの価値があります ただし、むちゃくちゃ解像度の高いユーザー理解が必要です それはちゃんと手に入れられます 2
3. 解像度の高いユーザー理解で作られた製品は、長期的に価値をもたらす 3
4. Yuki Fujisaki @tnj DeployGate Inc. Co-founder, CEO アプリのテスト配布を軸に開発チームの 効率的な意思疎通を支えています 4
5. UX職ではなく愛好家 株式会社MIXI (2008-2015) mixi for Android HCDワークショップ リサーチ手法 学生時代 nazobmplay, Gyazowin, QuicToday (Windows Mobile) #UI #情報設計 #インタラクション #UX 5
6. UXが事業成功に与える影響 6
7. 一般的な認識 UXは、 顧客満足度 や ロイヤリティ に直接影響を与える UXは、 長期的な 価値提供の源泉 7
8. UX提唱者における定義 企業、サービス、製品すべての側面における エンドユーザーのインタラクション 典型的なUXの第一要件は イライラや面倒なしに顧客ニーズを正確に満たすこと そして、所有にも使用にも喜びのある製品を生み出す シンプルさとエレガンスさ User Experience という概念を最初に用いだした Don Norman 博士が言っている The Definition of User Experience (UX) 8
9. UXを重視することは、事業成功に繋がっているのか？ Apple, Airbnb, Slack などなど、事例には事欠かない 実際のところはどうなのか 9
10. Case Study: DeployGate 市場環境が変わるなか、大きなピボットもなく 安定したサービスを提供している 10
11. DeployGate コア機能を端的に表現するなら、 「開発中のアプリ」を「テスターの端末に届ける」サービス 11
12. 12年の間に競合環境は大きく変わる たくさんの競合が生まれ、M&Aされ、形を変えていった TestFlight → Burstly → Apple Crashlytics Beta → Twitter → Google HockeyApp → Microsoft 現代: プラットフォーマーが無償で配布機能を提供している そんな市場でも生きのこっているのは当初からUXを大事にしていたから 12
13. 中核にあるUX (2024時点) アプリのQAプロセスの構築と運用を 負担なく、拡張可能な形で実現できる 初期(2015)は「開発中のアプリの実機検証を一瞬で」 目線はシフトしつつ、手間なく・素早くという要素は変わらない 13
14. CI/CD サービスの一般的な価値 継続的インテグレーション、継続的デリバリー（デプロイメント） 品質の向上のため（自動でビルド、テストで早期の問題発見、オペミスを減らす） 速度の向上のため（粒度を細かくできる、コンフリクトが減る、作業待ちが減る） チームの動きの可視化（暗黙知が減る、個人依存が減る、進行状況が見える） 14
15. 必要性はわかる、あるべき体験は？ 誰が、いつ、どのようなきっかけで導入を考えるのか？ どのような体験が期待されているのか？ 15
16. ある開発者視点の体験 16
17. CI/CDが必要だと思ったタイミング 新規プロジェクトの開発が中盤に入り、初期には起きなかった問題が起きはじめた 新しいメンバーが増え、同時に複数のブランチが存在する状態になる QAテストで、ブランチ違いによるミスコミュニケーションが起きる トラブルシューティングのコミュニケーションにも時間を取られる 17
18. ペイン 本質的な開発に集中できる時間を増やしたい、 集中している時の割り込みを避けたい 集中が必要になる時に「割り込み」で思考や判断を持っていかれるのがペイン もしデリバリーを一元化し、対象を渡すための統一された手段ができれば、 割り込みの元となる問題の発生自体を防げる 18
19. その開発者視点で欲しいもの 適切な デリバリー手段 1 人の時から自動テストを行うための CI (自動ビルド) 環境は存在している 1. 会社で使え、すぐ使い始められる 2. 限られたメンバー内でアプリを共有できる 3. 使っているCIと繋がる（インテグレーション、APIがある） 4. テスターに説明しやすい、トラブルシューティングしやすい 19
20. 期待される要件 1. 会社で使える、すぐ使い始められる 小さく試せるように無料から開始できる料金体系になっている すぐにアカウントが作成できる (資料請求ではない) 必要な社内手続きを通せる (見込みがある情報が提供されている) 2. 限られたメンバー内でアプリを共有できる 明示的にアカウントを持ったメンバーに共有ができ、不要になったら削除できる 20
21. 期待される要件 3. 使っているCIと繋がる（インテグレーション、APIがある） CIのプラグイン、APIがあり、ドキュメントが充実している 4. テスターに説明しやすい、トラブルシューティングしやすい 画面もドキュメントも日本語で、テスターのUIも平易で問題があれば説明してくれる 21
22. 期待される要件から 体験 に踏み込む アプリのQAプロセス の 構築 と 運用 を なるべく負担なく 、 拡張可能な形 で実現する 22
23. 実際に提供している体験 アプリのQAを負担なく 1日に何度も更新と確認を繰り返せる ビルドされた更新が待ち時間なく反映され、プッシュ通知が届く 手元で過去バージョンのインストールができる 開発者の手を借りずに、アップデート時の挙動の検証ができる 数ある端末でのログイン認証を手軽に行える Webブラウザ上のQRコードを読み取って端末のログインを行える リモート環境であっても即時のオブザーバビリティが得られる 端末のアクティビティやログがブラウザ上で常に確認できる 23
24. 実際に提供している体験 QAプロセスの構築を負担なく 部分から始められる: 最低限アプリがあ ればいい、1人でもいい テスター「に」説明しやすい QAプロセスの運用を負担なく テスター「が」説明・理解しやすい 開発者の手を借りなくても、テストをス ケールできる 業務中にサービス停止しない 拡張可能 API, 各種プラグイン, Slack連携 Enterprise: Google Workspace, SAML 24
25. 繰り返しのコミュニケーションの 負担を減らす 誰かに聞かなくてもそれぞれが必要な情報を持てる テスター「が」説明・理解しやすい インストールができない場合のガイド リビジョン番号 ハッシュではなく、数字 日本語のUI 25
26. 12年間、同一の製品UXが価値を提供し続けている 開発者への割り込みの削減を手間なく負担なく実現する QAテスター自身でできることを増やす ミスコミュニケーションを削減する 26
27. アップデートはしなくて良いの？ もちろん、UXを磨き続けることが新たな価値につながる ずっと一人でやり続けていくことはできないから、組織化することが必要 27
28. 我々の反省点: 組織化がだいぶ後手に回った UX組織という意味ではなく、一般的なチーム活動レベルの組織化 権限委譲、役割定義、ゴールの言語化やKPIの設定といったものが曖昧なまま 明確に課題が表面化したのは、ローンチから数年経過後 28
29. ハンマーしか持っていなければすべてが釘のように見える すべての問題を最終的にUXの課題としてフレーミングしてしまった 自分自身の手で解決しなければならない課題という認識 スコープを「自分ができること」に落としてしまう 成果を感じやすいところに留まってしまう 29
30. 「ビジネスのコアがUX」 ≠ 「UX課題の解決がすべて」 30
31. 組織化はまだ道半ば また別の機会に 31
32. 骨太なコアのUX、どのように見いだすか 我々の場合は、そもそも自身がターゲットユーザー ニーズや期待されるUXがめちゃくちゃ明確 なんならプロトタイプも一度作って検証していた ペルソナになりきった正確なシナリオも立てやすかった ただし、それはあくまでも初期の話 32
33. 最初期 ペルソナ／シナリオ法: ユーザーストーリーを 作って洗いだす 情報感度の高いエンジニアを対象としたオ ンボーディングと実際の体験 画面モックでのユーザーヒアリング 定量手法は実施せず 対象が小さくサンプル数が不十分 企画→リリースが2ヶ月しかなかった 33
34. 最初はよくても、継続すると難しくなっていく 顧客の現場との乖離が発生して見えなくなる 我々が作っているのは、WebとAPI中心のSaaSであって、アプリではない アプリ開発において何が本当に大事なのか、どんどん見えなくなる ここをうまく解消できずにいた 34
35. リサーチしていても手応えを感じられない 十分とは言い難いものの 各種ヒアリングを通じて、新たにたくさんの気づきや学びが得られてはいた いろんな要望も出てくる 「いい気づきを得ることができた」という感覚はある 仮説を構築して、プロトタイプを作って、当てて、それなりにいい反応 でも「明日にでも使いたい」には届かない 35
36. 最終的に辿り着いたところ 36
37. 自分で 対象業務を行う いわゆるエスノグラフィー 対象: テスト効率改善ツールのプロトタイプ ヒアリングを元に計画、開発し、一部の顧客にも 試用してもらい、フィードバックを得ていた しかし反応は期待ほどではなかった QAテスターとして全行程を実施してみた https://note.com/tnj/n/n4c100a6321a0 37
38. すごい解像度の情報が得られる プロトタイプの狙いは当たっていて、確かに便利にはなる でも、必須で手放せない存在になりうる感じはしない 38
39. QAテスト実施中、頭の中はどんな思考になっている? 39
40. とにかくテスト以外の思考を挟みたくない 40
41. 例 テスト結果をスプレッドシートに入力 判定の選択はよいが 確認日時を入力するのがとても大変 「ショートカットキーで省力化できるよ！」 41
42. ショートカットキーでもまだ億劫 実際の操作 1. 判定を選択して 2. 対応する確認日時欄に適切にフォーカスを移動して 3. ショートカットキーを押す 目視の判断や思考が存在する 42
43. 根底の欲求の理解 「とにかく手間や待ちを減らしたい」の感覚が強い 集中力を奪わないように「テスト以外の思考を挟む場面を減らしたい」という感覚 それはどこから来ているのか？ 43
44. 人間に向いてない: 視覚と短期記憶を使うタスクの並列 「同じ感覚モダリティ（聴覚・視覚など）かつ同じ情報ドメイン（時間的・空間的な ど） 」で処理するタスク同士を同時遂行すると、認知資源が競合し干渉が大きくなる。 メインのタスク 手順書の通り のタスクを実施し、結果が 期待値と一致しているか を確認する テストケースをワーキングメモリに積み、実際の画面に視覚的な注意を向ける 記入のタスク 入力欄に入力するだけ　→新たな判断はなくスムーズ 「入力欄が正しいか」 「適切に移動できたか」→判断にワーキングメモリが必要 1: https://www.biorxiv.org/content/10.1101/2021.04.20.440675v1 44
45. 優先したいことの認識が変わる 1. メインのタスク外で判断が必要になることを減らしたい 2. 作業中の不便や手間を減らしたい 45
46. 明確なペイン は、 インタビューに表出する 例: 「確認日時」の入力支援 無いことによるペイン、 あるべき姿の期待値も分かりやすい 「結果の選択時に自動的に入力されてほ しい」 便利な新機能や体験 は、 ペインが感じられない プロトタイプの機能 いままで無かったものなので、 なくてもこれまで通りなだけ インタビューでの課題抽出が難しい 46
47. 魅力的品質の 不充足 は認知できない 狩野モデル 言語化されるペインから見つけられるのは 「一元的品質」 「当たり前品質」 新たな価値はペインが伴わない 「魅力的品質」 出典: 狩野モデルから探る品質のあり方とは - SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル- 47
48. 「まあ」の重要さ 使って思い浮かぶ感想や実際の発言に現れる 「ここでこれが欲しいってところで、ちょっと足りないけど、まあ工夫したら使えるかな」 「ここで少し待たされるな、まあ待てばいいか」 48
49. 「まあ」 ≒ 使うことを避けるいい理由 結果として「不充足」の示唆になっていた まあ工夫したら使えるかな → 工夫しないと使えない 考えなくても済むから、従来通りの手段 を使おう まあ待てばいいか → 待たされたくない 早く終わらせたいから、従来通りの手段 を使おう 49
50. 判断が必要になることが減る ＞ 作業の不便や手間が減る プロトタイプの開発者である自分自身でさえ、そういう判断をした 50
51. 発見を活かしたMVP 機能のフォーカスを絞り、そもそも判断をなくした 処理を最適化して、待ち時間も無視できるレベルに 51
52. 試してもらった結果 QAテスター 「すぐに業務で使ってみたいです」 開発者の反応もよいが温度感はあまり変わらず、ターゲットだけが如実に反応が変化 52
53. 理解の解像度の高さはとてつもないレバレッジが効く すべての判断の精度が上がる 体験そのものの設計 優先順位づけ チームとの壁打ち 53
54. とはいうものの 54
55. ユーザーと同じ体験が得られる機会は手に入るのか？ 顧客と同じ体験を社内でできるか？ 顧客がまったく他業種である場合は難しいよね？ 55
56. 社内になければ社外に出る こんにちは！ 最近、 【対象領域】の製品を開発するにあたって、実際に行われる業務の理解を深めるた めに、 【自身の職種】自身が身をもって【対象領域】のお仕事をお手伝いさせていただく という活動をしております。 可能であれば、御社で活動の機会を頂けると嬉しいのですが、なにか【対象領域】周り でお手伝いできることはありませんでしょうか？ 関係性のある知り合いづてにあたっていく、もしくは紹介してもらう 既存の顧客ではない 方が忖度がなくてよい 56
57. そんなこと実際できるの？というかやっていいの？ A1. できる 10社打てば1社ぐらいはいける A2. やっていいやらないといけない メリットしかない 57
58. Case Study: DeployGateの CEO貸します 実際に入らせていただいている 前職の繋がりから紹介 何ができるかは分からない、でスタート 顧客ではなく、営業目的でもない、中立の立場 58
59. 「わたし、CEOじゃないんですが…」 どんなロールでもよい 第三者の立場というだけで提供できる視点があり、役に立てる 「構造の中から構造自体を俯瞰すること」はそもそも難しい ミーティングや1on1でも、気付いた違和感を質問するだけで十分な価値が出せる これまでの知見「も」活かせる UXデザインでもPdMでもチームビルディングでもIT全般の知識でも 自身が持つこれまでの知見が提供できればよりよい 59
60. 得られること 見えてくるものがたくさんある 事業環境、組織文化、目下の課題、優先度 人ごとの視点の違い どのような課題をどのぐらいの温度感で感じているのか明確な理解が進む UXデザイン視点、プロダクト視点 60
61. そのなかでも大事なこと 日々「コト」と向き合っているターゲット層の人々との関係性が構築できる 必要な時にすぐ質問できる 実際に手を動かしている様子を気軽に見せてもらえる SaaS製品を選定する議論や観点も知れる リサーチのハードルがどれだけ下がるか？ 61
62. ここまでの学び 本質的なUXに向き合うことは 顧客への長期的な価値提供に繋がり事業の安定に貢献する 組織化やマーケが不完全でも続いてしまうほど その上で、継続的に付加価値を増やすために組織化していくことは大事 顧客と同じ立場をUXデザイナの視点を持って自ら体験することは その後の様々な判断の品質も速度も上げる インタビューだけでは魅力的品質の種を拾うことはできない 顧客の現場に行くことはできる、人間対人間の関係も築ける 62
63. 「UX担当者としてやるべきこと」はシンプル UXの専門家の視点と道具を持って なるべく顧客と同じ現場に立って 自らのフィルタを通して本質的な課題を特定すること 適切な課題抽出ができれば、適切な解決策があなたとチームの引き出しにあるはず 63
64. まとめ UX大事にしたら12年続くB2D SaaSサービスができました 「やりきれている」とは言えないが、それでもなお価値があった 愚直に現場に行くことで、一度失った現場理解の解像度を高めています エスノグラフィー、効果は予想以上 今後は組織横断でのUX中心文化の構築にもチャレンジしていきます 64