BtoBtoC サービスにおいて エンジニアが探るUXの ”勘所” / How engineers explored "Essentials" of UX in BtoBtoC products

2020年9月13日に登壇したUXデザインのイベント『UX MILK All Night』での発表資料となります。BtoBtoCという複雑なビジネス形式におけるUXの改善の工夫ついて、あるいはエンジニアが取り組めることやチームとの向き合い方について話しました。

- URL: https://www.uxmilkallnight.com/

Transcript

1. BtoBtoC サービスにおいて エンジニアが探るUXの ”勘所” 2020 / 09 / 13 UX MILK All Night @terry_i_ MedPeer, inc. - Engineer
2. Agenda 自己紹介 展開するサービス BtoBtoC ”あるある” UXの “勘所” を探る まとめ
3. 自己紹介
4. 福本 晃之 Teruhisa Fukumoto MedPeer, inc. Web Developer Gotanda.rb / .js Organizer f-teruhisa @terry_i_
5. Twitter #uxmilkallnight
6. 展開するサービス (not PR)
7. 特定保健指導
8. はァ
9. • 定期健診で ”引っかかった”, 40~74 歳までの方が対象 ◦ いわゆる “メタボ” の方とか • “管理栄養士” という国家資格を持つ方などが行う • 主に食事面から, 生活習慣の改善をサポート • 食のtoBサービスみたいなイメージ 特定保健指導って??
10. DietPlus Pro
11. • 特定保健指導のサポートの一環 • 食事の写真に管理栄養士がアドバイス • 個人の目標や計画に基づいた支援を行う DietPlus Pro
12. 弊社BtoBtoCの流れ フィッツプラス(メドピア) Business 健康保険組合 Business 特定保健指導対象者 Consumer
13. • BtoBtoCサービス独特の難しさ • エンジニアが特に力を入れて貢献できること • さまざまな職種の人たちとの関わり ◦ ”管理栄養士( 後述 )” “デザイナー” “エンジニア” ... アプリのUX改善で取り組んだ話をします
14. BtoBtoC ”あるある”
15. BtoBtoCとは？ 前提
16. BtoBtoC ( 諸説あり) • BtoCを支援するビジネスモデルのこと • サービスにお金を支払うのは企業・法人 • 企業の顧客がエンドユーザーになる
17. サービス例 ※Googleで「BtoBtoC」で検索し出てきたサービス + 自社サービスを載せています
18. BtoBtoC “あるある” 難しさ
19. 1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”
20. 1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”
21. ユーザーまでの距離が遠い ユーザーから声が 直接届きづらい 自社メンバーがユーザーの 課題の当事者ではない 2 コンテンツをクライアントが 作成する( ことがある ) 3 1
22. ユーザーの本質的な ニーズや課題を掴みづらい
23. 1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”
24. 目先の数字を追えてしまう クライアントの 個別対応 短期的な 数値目標の優先 2 既存市場の誘惑 3 1
25. 「UX」と「ビジネス目標の達成」を トレードオフの関係にしてしまう
26. 1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”
27. ステークホルダーが多い 直接の顧客である クライアントの存在 2 代理店などの 複雑な商流 3 1 クライアント別に 社内に”担当者”
28. 「課題の原因特定」と「解決のプロセス」を 複雑化させてしまう
29. ツライ( つらい )
30. どう向き合うか?? ユーザーのニーズや課題を 掴みづらい ユーザー体験とビジネスの トレードオフ化 複雑化した 原因特定と課題解決
31. UXの ”勘所” を探る
32. 勘所 物事の重要な部分。肝要なところ。急所。つぼ。 「 －をはずさぬ批評」 「 －を心得ている」 ― ”勘所” weblio辞書
33. イメージ
35. 　ボウリングの”スパット” • ピンと平行にマークされている目印 • スパットを撃ち抜き, 延長上のピンを倒す • 近い距離のもののほうが正確に狙いやすい （ ”スパット” って呼ぶことをはじめて知りました ...） ➤
36. Business Business Consumer Business Business Consumer ➤ ➤ ➤ ➤ ➤ ➤ ♥ ♥ Everyone
37. スパットを自分たちでマークする ( NOT KPI ) 基準となり得る 事象か？ マークする位置は 正しいか？
38. 勘所を探っていく 推測するな、計測せよ ― Rob Pike( プログラミング言語Go開発者 )
39. 民主化されたデータを取る
40. データ分析の民主主義状態とは 技術者 / 分析者の手を離れて インサイトを得られる システムやアプリケーションから 切り離されて分析できる 分析結果やインサイトに 容易にアクセスし議論できる 分析自体を目的にせず、全員で議論できる姿をめざす
41. • ログやDBのテーブル / モデル設計 • データの収集 • 分析環境の整備と布教 ➛ 文化にしていく • インサイトや議論の提示 まずは、エンジニア主体で進める必要がある
42. 実例
43. • 追うデータが不明確 ( ステークホルダーが多い→指標が多い ) • 曖昧な影響範囲 ( toBマーケ / 営業や顧客の施策etc… ) • データの偏在 ( パレートの法則: 一部の顧客にデータが集中 ) BtoBtoCならではの分析の難しさ
44. 1. UXをフローとファネルに落とす 2. toB / toC にデータをわけて考える 3. まずは後ろから 悩んだときの工夫
45. • ユーザーがサービスを使う流れ • フロー間での継続 / 脱落率を見る • ユーザーの体験を整理できる • チーム内で合意形成しやすい ◦ 手法としてメジャー ◦ 作成が容易で時間がかからない ◦ 直感的で理解しやすい 1. UXをフローとファネルに落とす ログイン 新規登録 投稿 プラン選択 課金
46. • 複数種のユーザーを混同しない • 誰の何を幸せにしたいのかを明確に • 優先順位に気をつける • 自社で解決できる範囲を意識する • toB ➛ toCと体験が地続きの場合も ◦ ex. クライアントがコンテンツを作れ ず、 　 結果ユーザーが流入しない 2. toB / toC にデータをわけて考える toB toC
47. • 優先度決めの方法 • ファネルのボトムから改善しよう ◦ バケツの穴をふさぐ • 離脱したユーザーはまず戻らない • アンチパターン ◦ ネットワーク外部性と競合 3. まずは後ろから 会員登録 ログイン 「穴あきバケツの成長モデル」の話 : https://note.com/fladdict/n/n6ef647f5cc8b
48. DietPlus Proでの気づき... アカウントを発行して渡すので、ユーザーは新規登録しなかった...（猛省）
49. データに関するまとめ • 分析それ自体で満足せず, 議論をしていこう • BtoBtoC ならではの分析の難しさに注意 • 困ったらファネルで考えると楽かも...??
50. 定性的な感覚や判断の導入
51. データや指標を過信しない 数値化された指標は, ハックの可能性を内包する 論理的思考や分析の限界 前後関係や相関関係を 因果関係と混同
52. 人は論理的な生き物ではない • 人は利己的行動をとらない ◦ 酒や肥満, 賭博の存在を説明できない • 自分の嗜好を理解していない • 複数の選択肢を比較して判断していない • 自分の満足度や効用を測っていない • 思考や効用は不変のものではない 友野 典男 『行動経済学 経済は「感情」で動いている』 (光文社新書)
53. 人はストーリーにすがる生き物 • “ストーリー” が人間の認知の枠組み • 人は前後関係を因果関係と結びつけたがる • 説明の妥当性や正確性より, その存在を重視 ◦ ”公正世界仮説”の信奉 • 因果関係に納得すると「わかって」しまう • “報告価値” の客観性にブレ • 人は ”なぜ？” を無くす権威を必要とする 千野 帽子『人はなぜ物語を求めるのか』 （ちくまプリマー新書）
54. 分析的・論理的な思考には限界がある • 正解の “コモディティ化” • 不確実な世界で問題の構成因子が増加 • 市場のステージが ”自己実現欲求” に移行 • ロジックはコピーが容易 • パターン認識から逃げられない ◦ フレームワーク問題 山口周『世界のエリートはなぜ「美意識」を鍛えるのか？～経営における「アート」と「サイエンス」～ 』（光文社新書）
55. 定性的な感覚や判断の導入 How??
56. ドメインエキスパート
57. • ある領域や分野に多くの知識をもつ • その専門的な知識を他人に提供できる • 設計と内容のレビュー能力に優れる • この人物と伴走し適切な開発モデルを探求 • ドメインエキスパートの例 ◦ 金融サービスの会計 / 経理の経験者 ◦ DietPlus Pro は管理栄養士さんが該当 ドメインエキスパートとは（諸説あり） 会員登録 ログイン 一部参考: エリック・エヴァンス『エリック・エヴァンスのドメイン駆動設計』 （翔泳社）
58. なぜドメインエキスパートなのか?? • BtoBtoC はユーザーの課題の当事者になりづらい ◦ 少しでも当事者と関わった方の感覚を注入 • サービスの仮想空間と現実との乖離の防止 • システム・デザインありきの先入観を除外
59. エキスパートとのUX向上の進め方 チーム全員で 同じ言葉を使う （ユビキタス言語） 1 機能や要件ではなく, 要望を上げてもらう 2 継続して双方向の コミュニケーションを （一方的に教えられがち） 3 共通認識の醸成･･･チーム全員で「いいね」が8割くらい共通する状態を作る
60. エキスパートとの向き合い方 • 好奇心を持ち, 自らドメインを学ぶこと • エキスパートにシステムからも学べる認識を与える • 初期のコミュニケーションコストを惜しまない
61. ( 実例 ) 管理栄養士についての社内勉強会
62. その他の裏技 • CSやtoBユーザーからフィードバックを受ける • 勉強会やインタビューの場を作る • ( 予算とって )無理やりドッグフーディングする ◦ 僕は健康診断に引っかかったテイでやりました....
63. ビジネスとUX / 技術を切り離す
64. 目先の数字を追える事情を, 不用意にユーザー体験に持ち込まない 一部の顧客やユーザーが 喜ぶ機能を作ってしまう... 他のデザインパーツやコードに 悪影響を及ぼす ステークホルダー増加による, デザイン/開発フローの複雑化
65. 機能をいつでも捨てられるようにする • 基本的には, コードやデザインは共通化しない • 汎用化を見据えた過度な一般化 / 抽象化は避ける • 捨てる / 撤退タイミングの判断基準を考えておく
66. 弊チームでの例 一部のコードがmodule間でDRYにならない( しづらい ) 個人的には, ヘンに共通化して罠にハマるくらいなら, メンテナンスするコード量が多少増えても, 影響範囲をmodule内に閉 じ込めておく方が無難なのではないかと考えます。 （※他にも, パーツデザインは類似アプリと完全に分けてます） 『特定保健指導 "フィッツプラス "事業を支えるモノリシック Rails + VIPER Swift アーキテクチャ 』 https://tech.medpeer.co.jp/entry/2020/06/22/121153
67. お金の問題は難しいが, ユーザーは無関係 • 経営状態により, 短期目標の優先は発生し得る • それをすべて否定せず, 最適解を探す • ユーザーを巻き込まないような工夫を
68. 勘所の探り方 まとめ • 手法に満足せず, 議論できる状態 / チームへ • エキスパートと支え合える工夫をし, 感覚を養う • ユーザーを巻き込まない形で経営状態と向き合う 最終的にはチームの問題に帰着する
69. 健全なUXは, 健全なチームの アウトプットにこそ宿る
70. お後がよろしいようで
71. まとめ
72. • BtoBtoCには独特の ”課題との向き合いづらさ” がある • 色んな ”勘所” を探って, 狙いを外さない工夫が必要 • “良いUX” は “良いチーム” から生まれる 全体のまとめ
73. Business Business Consumer Business Business Consumer ➤ ➤ ➤ ➤ ➤ ➤ ♥ ♥ Everyone
74. みなさん, 来年は きっとお会いしましょう
75. We’re hiring • Webデザイナー • Webディレクター • フロントエンドエンジニア • iOS / Android エンジニア • マークアップエンジニア • Rubyエンジニア
76. Thank you!! @terry_i_ MedPeer, inc. - Engineer