Tweet
Tweet

Slide 1

Slide 1 text

BtoBtoC サービスにおいて エンジニアが探るUXの ”勘所” 2020 / 09 / 13 UX MILK All Night @terry_i_ MedPeer, inc. - Engineer

Slide 2

Slide 2 text

Agenda 自己紹介 展開するサービス BtoBtoC ”あるある” UXの “勘所” を探る まとめ

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

福本 晃之 Teruhisa Fukumoto MedPeer, inc. Web Developer Gotanda.rb / .js Organizer f-teruhisa @terry_i_

Slide 5

Slide 5 text

Twitter #uxmilkallnight

Slide 6

Slide 6 text

展開するサービス (not PR)

Slide 7

Slide 7 text

特定保健指導

Slide 8

Slide 8 text

はァ

Slide 9

Slide 9 text

● 定期健診で ”引っかかった”, 40~74 歳までの方が対象 ○ いわゆる “メタボ” の方とか ● “管理栄養士” という国家資格を持つ方などが行う ● 主に食事面から, 生活習慣の改善をサポート ● 食のtoBサービスみたいなイメージ 特定保健指導って??

Slide 10

Slide 10 text

DietPlus Pro

Slide 11

Slide 11 text

● 特定保健指導のサポートの一環 ● 食事の写真に管理栄養士がアドバイス ● 個人の目標や計画に基づいた支援を行う DietPlus Pro

Slide 12

Slide 12 text

弊社BtoBtoCの流れ フィッツプラス(メドピア) Business 健康保険組合 Business 特定保健指導対象者 Consumer

Slide 13

Slide 13 text

● BtoBtoCサービス独特の難しさ ● エンジニアが特に力を入れて貢献できること ● さまざまな職種の人たちとの関わり ○ ”管理栄養士( 後述 )” “デザイナー” “エンジニア” ... アプリのUX改善で取り組んだ話をします

Slide 14

Slide 14 text

BtoBtoC ”あるある”

Slide 15

Slide 15 text

BtoBtoCとは？ 前提

Slide 16

Slide 16 text

BtoBtoC ( 諸説あり) ● BtoCを支援するビジネスモデルのこと ● サービスにお金を支払うのは企業・法人 ● 企業の顧客がエンドユーザーになる

Slide 17

Slide 17 text

サービス例 ※Googleで「BtoBtoC」で検索し出てきたサービス + 自社サービスを載せています

Slide 18

Slide 18 text

BtoBtoC “あるある” 難しさ

Slide 19

Slide 19 text

1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”

Slide 20

Slide 20 text

1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”

Slide 21

Slide 21 text

ユーザーまでの距離が遠い ユーザーから声が 直接届きづらい 自社メンバーがユーザーの 課題の当事者ではない 2 コンテンツをクライアントが 作成する( ことがある ) 3 1

Slide 22

Slide 22 text

ユーザーの本質的な ニーズや課題を掴みづらい

Slide 23

Slide 23 text

1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”

Slide 24

Slide 24 text

目先の数字を追えてしまう クライアントの 個別対応 短期的な 数値目標の優先 2 既存市場の誘惑 3 1

Slide 25

Slide 25 text

「UX」と「ビジネス目標の達成」を トレードオフの関係にしてしまう

Slide 26

Slide 26 text

1. ユーザーまでの距離が遠い 2. 目先の数字( 売上 / 利益 )を追えてしまう 3. ステークホルダー( 利害関係者 )が多い “あるある”

Slide 27

Slide 27 text

ステークホルダーが多い 直接の顧客である クライアントの存在 2 代理店などの 複雑な商流 3 1 クライアント別に 社内に”担当者”

Slide 28

Slide 28 text

「課題の原因特定」と「解決のプロセス」を 複雑化させてしまう

Slide 29

Slide 29 text

ツライ( つらい )

Slide 30

Slide 30 text

どう向き合うか?? ユーザーのニーズや課題を 掴みづらい ユーザー体験とビジネスの トレードオフ化 複雑化した 原因特定と課題解決

Slide 31

Slide 31 text

UXの ”勘所” を探る

Slide 32

Slide 32 text

勘所 物事の重要な部分。肝要なところ。急所。つぼ。 「 －をはずさぬ批評」 「 －を心得ている」 ― ”勘所” weblio辞書

Slide 33

Slide 33 text

イメージ

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

　ボウリングの”スパット” ● ピンと平行にマークされている目印 ● スパットを撃ち抜き, 延長上のピンを倒す ● 近い距離のもののほうが正確に狙いやすい （ ”スパット” って呼ぶことをはじめて知りました ...） ➤

Slide 36

Slide 36 text

Business Business Consumer Business Business Consumer ➤ ➤ ➤ ➤ ➤ ➤ ♥ ♥ Everyone

Slide 37

Slide 37 text

スパットを自分たちでマークする ( NOT KPI ) 基準となり得る 事象か？ マークする位置は 正しいか？

Slide 38

Slide 38 text

勘所を探っていく 推測するな、計測せよ ― Rob Pike( プログラミング言語Go開発者 )

Slide 39

Slide 39 text

民主化されたデータを取る

Slide 40

Slide 40 text

データ分析の民主主義状態とは 技術者 / 分析者の手を離れて インサイトを得られる システムやアプリケーションから 切り離されて分析できる 分析結果やインサイトに 容易にアクセスし議論できる 分析自体を目的にせず、全員で議論できる姿をめざす

Slide 41

Slide 41 text

● ログやDBのテーブル / モデル設計 ● データの収集 ● 分析環境の整備と布教 ➛ 文化にしていく ● インサイトや議論の提示 まずは、エンジニア主体で進める必要がある

Slide 42

Slide 42 text

実例

Slide 43

Slide 43 text

● 追うデータが不明確 ( ステークホルダーが多い→指標が多い ) ● 曖昧な影響範囲 ( toBマーケ / 営業や顧客の施策etc… ) ● データの偏在 ( パレートの法則: 一部の顧客にデータが集中 ) BtoBtoCならではの分析の難しさ

Slide 44

Slide 44 text

1. UXをフローとファネルに落とす 2. toB / toC にデータをわけて考える 3. まずは後ろから 悩んだときの工夫

Slide 45

Slide 45 text

● ユーザーがサービスを使う流れ ● フロー間での継続 / 脱落率を見る ● ユーザーの体験を整理できる ● チーム内で合意形成しやすい ○ 手法としてメジャー ○ 作成が容易で時間がかからない ○ 直感的で理解しやすい 1. UXをフローとファネルに落とす ログイン 新規登録 投稿 プラン選択 課金

Slide 46

Slide 46 text

● 複数種のユーザーを混同しない ● 誰の何を幸せにしたいのかを明確に ● 優先順位に気をつける ● 自社で解決できる範囲を意識する ● toB ➛ toCと体験が地続きの場合も ○ ex. クライアントがコンテンツを作れ ず、 　 結果ユーザーが流入しない 2. toB / toC にデータをわけて考える toB toC

Slide 47

Slide 47 text

● 優先度決めの方法 ● ファネルのボトムから改善しよう ○ バケツの穴をふさぐ ● 離脱したユーザーはまず戻らない ● アンチパターン ○ ネットワーク外部性と競合 3. まずは後ろから 会員登録 ログイン 「穴あきバケツの成長モデル」の話 : https://note.com/fladdict/n/n6ef647f5cc8b

Slide 48

Slide 48 text

DietPlus Proでの気づき... アカウントを発行して渡すので、ユーザーは新規登録しなかった...（猛省）

Slide 49

Slide 49 text

データに関するまとめ ● 分析それ自体で満足せず, 議論をしていこう ● BtoBtoC ならではの分析の難しさに注意 ● 困ったらファネルで考えると楽かも...??

Slide 50

Slide 50 text

定性的な感覚や判断の導入

Slide 51

Slide 51 text

データや指標を過信しない 数値化された指標は, ハックの可能性を内包する 論理的思考や分析の限界 前後関係や相関関係を 因果関係と混同

Slide 52

Slide 52 text

人は論理的な生き物ではない ● 人は利己的行動をとらない ○ 酒や肥満, 賭博の存在を説明できない ● 自分の嗜好を理解していない ● 複数の選択肢を比較して判断していない ● 自分の満足度や効用を測っていない ● 思考や効用は不変のものではない 友野 典男 『行動経済学 経済は「感情」で動いている』 (光文社新書)

Slide 53

Slide 53 text

人はストーリーにすがる生き物 ● “ストーリー” が人間の認知の枠組み ● 人は前後関係を因果関係と結びつけたがる ● 説明の妥当性や正確性より, その存在を重視 ○ ”公正世界仮説”の信奉 ● 因果関係に納得すると「わかって」しまう ● “報告価値” の客観性にブレ ● 人は ”なぜ？” を無くす権威を必要とする 千野 帽子『人はなぜ物語を求めるのか』 （ちくまプリマー新書）

Slide 54

Slide 54 text

分析的・論理的な思考には限界がある ● 正解の “コモディティ化” ● 不確実な世界で問題の構成因子が増加 ● 市場のステージが ”自己実現欲求” に移行 ● ロジックはコピーが容易 ● パターン認識から逃げられない ○ フレームワーク問題 山口周『世界のエリートはなぜ「美意識」を鍛えるのか？～経営における「アート」と「サイエンス」～ 』（光文社新書）

Slide 55

Slide 55 text

定性的な感覚や判断の導入 How??

Slide 56

Slide 56 text

ドメインエキスパート

Slide 57

Slide 57 text

● ある領域や分野に多くの知識をもつ ● その専門的な知識を他人に提供できる ● 設計と内容のレビュー能力に優れる ● この人物と伴走し適切な開発モデルを探求 ● ドメインエキスパートの例 ○ 金融サービスの会計 / 経理の経験者 ○ DietPlus Pro は管理栄養士さんが該当 ドメインエキスパートとは（諸説あり） 会員登録 ログイン 一部参考: エリック・エヴァンス『エリック・エヴァンスのドメイン駆動設計』 （翔泳社）

Slide 58

Slide 58 text

なぜドメインエキスパートなのか?? ● BtoBtoC はユーザーの課題の当事者になりづらい ○ 少しでも当事者と関わった方の感覚を注入 ● サービスの仮想空間と現実との乖離の防止 ● システム・デザインありきの先入観を除外

Slide 59

Slide 59 text

エキスパートとのUX向上の進め方 チーム全員で 同じ言葉を使う （ユビキタス言語） 1 機能や要件ではなく, 要望を上げてもらう 2 継続して双方向の コミュニケーションを （一方的に教えられがち） 3 共通認識の醸成･･･チーム全員で「いいね」が8割くらい共通する状態を作る

Slide 60

Slide 60 text

エキスパートとの向き合い方 ● 好奇心を持ち, 自らドメインを学ぶこと ● エキスパートにシステムからも学べる認識を与える ● 初期のコミュニケーションコストを惜しまない

Slide 61

Slide 61 text

( 実例 ) 管理栄養士についての社内勉強会

Slide 62

Slide 62 text

その他の裏技 ● CSやtoBユーザーからフィードバックを受ける ● 勉強会やインタビューの場を作る ● ( 予算とって )無理やりドッグフーディングする ○ 僕は健康診断に引っかかったテイでやりました....

Slide 63

Slide 63 text

ビジネスとUX / 技術を切り離す

Slide 64

Slide 64 text

目先の数字を追える事情を, 不用意にユーザー体験に持ち込まない 一部の顧客やユーザーが 喜ぶ機能を作ってしまう... 他のデザインパーツやコードに 悪影響を及ぼす ステークホルダー増加による, デザイン/開発フローの複雑化

Slide 65

Slide 65 text

機能をいつでも捨てられるようにする ● 基本的には, コードやデザインは共通化しない ● 汎用化を見据えた過度な一般化 / 抽象化は避ける ● 捨てる / 撤退タイミングの判断基準を考えておく

Slide 66

Slide 66 text

弊チームでの例 一部のコードがmodule間でDRYにならない( しづらい ) 個人的には, ヘンに共通化して罠にハマるくらいなら, メンテナンスするコード量が多少増えても, 影響範囲をmodule内に閉 じ込めておく方が無難なのではないかと考えます。 （※他にも, パーツデザインは類似アプリと完全に分けてます） 『特定保健指導 "フィッツプラス "事業を支えるモノリシック Rails + VIPER Swift アーキテクチャ 』 https://tech.medpeer.co.jp/entry/2020/06/22/121153

Slide 67

Slide 67 text

お金の問題は難しいが, ユーザーは無関係 ● 経営状態により, 短期目標の優先は発生し得る ● それをすべて否定せず, 最適解を探す ● ユーザーを巻き込まないような工夫を

Slide 68

Slide 68 text

勘所の探り方 まとめ ● 手法に満足せず, 議論できる状態 / チームへ ● エキスパートと支え合える工夫をし, 感覚を養う ● ユーザーを巻き込まない形で経営状態と向き合う 最終的にはチームの問題に帰着する

Slide 69

Slide 69 text

健全なUXは, 健全なチームの アウトプットにこそ宿る

Slide 70

Slide 70 text

お後がよろしいようで

Slide 71

Slide 71 text

まとめ

Slide 72

Slide 72 text

● BtoBtoCには独特の ”課題との向き合いづらさ” がある ● 色んな ”勘所” を探って, 狙いを外さない工夫が必要 ● “良いUX” は “良いチーム” から生まれる 全体のまとめ

Slide 73

Slide 73 text

Business Business Consumer Business Business Consumer ➤ ➤ ➤ ➤ ➤ ➤ ♥ ♥ Everyone

Slide 74

Slide 74 text

みなさん, 来年は きっとお会いしましょう

Slide 75

Slide 75 text

We’re hiring ● Webデザイナー ● Webディレクター ● フロントエンドエンジニア ● iOS / Android エンジニア ● マークアップエンジニア ● Rubyエンジニア

Slide 76

Slide 76 text

Thank you!! @terry_i_ MedPeer, inc. - Engineer