Slide 1
Slide 1 text
Scrum Fest Fukuoka 2024
デザイナーの帽子をかぶったわたしが、
プロダクト開発するうえでスクラムチームに提供したいこと
2024.3.9
Slide 2
Slide 2 text
2
freee株式会社
プロダクトデザイナー
とある大きな製造業（2009年〜）
フロントエンド開発 / UXデザイン / アジャイル推進
freee株式会社（2021年10月〜）
HCD-Net認定 人間中心設計専門家
CSPO/A-CSPO/CAL1
最近の趣味
森川 裕美（ひろみつ）
Product Designer
Hiromi Morikawa
Slide 3
Slide 3 text
3
福岡に６年間住んでいました
わいは
芸術工学
やるんや！
昨⽇出てきた九⼯⼤と⾚本が⼀緒な、⼤橋にある芸⼯⼤に通っていた
Slide 4
Slide 4 text
4
なぜ発表することにしたの？
● Regional Scrum Gathering Tokyo 2024で「ユーザーがわからない」「役に⽴つ
かどうかわからない」というエピソードを⽿にしたこと
● 「アウトカム」や「仮説検証」、デザイナーとの協働に対する関⼼の⾼まり
● ⽇々チームでオタクの早⼝をしがち…
Slide 5
Slide 5 text
5
Youはどんなデザイナー？
RSGT2024のOSTの様⼦
Slide 6
Slide 6 text
6
Youはどんなデザイナー？
Slide 7
Slide 7 text
7
Youはどんなデザイナー？
Front-end Development
UI Design
UX
Now!
+
+
Agile
+ 社内啓蒙
プロダクトデザイン
2009〜 2021〜
Java
Slide 8
Slide 8 text
8
Youはどんなデザイナー？
● 業務のリサーチから、設計、デリバリー後の検証まで
● 新企画のための機会領域の探索やコードは書いてない
● １スクラムチーム専任
Slide 9
Slide 9 text
9
本日お話しすること
話すこと
● 検証だ！とユーザーに突撃する前に獲得できるユーザーに関する知識
● 「ユーザーの話を聞く」の解像度を⾼くするためのヒント
話さないこと
● デザイナーが開発プロセスに混ざるためのベストプラクティス
Slide 10
Slide 10 text
10
01 UXとスクラムの融合の勘違い期
02 「ユーザーに聞く」ことは劇薬？
03 toBアプリの「アウトカム」とは何？
04 よーし「ユーザー検証」だ！
ちょっと待って、ユーザに突撃する前に
05 「知らないこと」なのか「仮説」なのか
06 まとめ
⽬次
Slide 11
Slide 11 text
UXとスクラムの
融合の勘違い期
Slide 12
Slide 12 text
12
UXとスクラムチームとの出会い
● 業務系中⼼だったため、toC新規事業へ憧れる
● アジャイルのパイロットチームにUXデザイナーとしてin☺
● UXのプロセスと開発をうまく繋げたい
● デュアルトラックアジャイルだ！
https://jpattonassociates.com/dual-track-development/
Slide 13
Slide 13 text
13
UXとスクラムチームとの出会い
● ユーザの反応があって嬉しい！
● Howはトレードオフできるという発⾒
● なんだかイキイキしてきたような気がする！
Slide 14
Slide 14 text
14
UXとスクラムチームとの出会い
● …プロダクトのお墓を⽴てることになった（何度⽬か
● デリバリーとデザインは繋がっていたが…
● 仮説検証は真には⾏われていないのだった
Slide 15
Slide 15 text
15
⾒えていなかった原価と損益分岐
● 毎⽉経理に向けて報告が必要なことを知る
● 売上は？在庫は？棚卸し？…ほえ？
● フロントに気をとられて「事務作業」だと思ってしまっていた
● 運⽤するほどお⾦が流れていき投資も少なく…
● ユーザー！といってるだけではプロダクトはうまくいかないことを知った
Slide 16
Slide 16 text
16
toCとtoBの領域の特性の違いを考えはじめる
● インターフェースの設計でプロダクトに貢献できないか？
● toB領域のあるSaaSにキャリアの舵を切る（いまココ
Slide 17
Slide 17 text
今⽇の話の前提
Slide 18
Slide 18 text
18
自動化・可視化を実現する
これまでにない統合型クラウド会計ソフト
Slide 19
Slide 19 text
19
私が担当している領域
・対象ユーザー：会計士さん/税理士さん向け
・通帳や領収書を預かり、記録する「記帳」の業務
・これまでの弱みを潰す戦略のポジション
Slide 20
Slide 20 text
20
今⽇の話の前提
● …という⽂脈を前提に、N1の話として聞いてください
○ toBとtoCでも異なる
○ サービス規模や組織規模でも違う
○ 新規事業開発やグロースなどプロダクトのフェーズでも違う
○ 「デザイナー」でもカバー領域も違う
Slide 21
Slide 21 text
「ユーザーに聞く」ことは劇薬？
Slide 22
Slide 22 text
22
わたしが働いているチーム
エンジニア
＠名古屋
プロダクトマネージャー
エンジニア
デザイナー
＠東京
QA
＠⻑野
Slide 23
Slide 23 text
23
スクラムチームの最近
● 新チーム⽴ち上げから２年
○ エンジニアが半分⼊れ替わった
○ ユーザーや価値に⾼い関⼼
● スクラムを採⽤
○ アジャイル、スクラムの知識には濃淡
○ プロダクトゴール‧スプリントゴールを⽴てはじめて半年強くらい
● 現場の業務の観察経験のないメンバーも
Slide 24
Slide 24 text
24
スプリントレビューをちゃんとしたい機運の⾼まりAgain
● メンバーの⼊れ替わりで⼀時的にベロシティが落ちていた
● リズムも整い、難易度の⾼い開発部分がリリースできそう
● 「スプリントレビュー」がどんな場かという理解も深まってきた
● 今作っているものが有益なのか、⼈を呼んで確かめたいという話に
Slide 25
Slide 25 text
25
スプリントレビューをちゃんとやる？
Slide 26
Slide 26 text
「ユーザーに触ってもらおう」となったときに
気をつけると幸せになることを話すよ
Slide 27
Slide 27 text
27
スプリントのなかで良く聞く⾔葉
「とりあえずユーザーに聞いてみましょう」
Slide 28
Slide 28 text
28
スプリントのなかで良く聞く⾔葉
● 内⼼構えているわたし…
誰に聞く？
何が検証できれば
次に進めるんや？
判断をユーザーに
委ねてない？
今聞くのが
いいん？
チームで
仮説と検証観点
揃ってる…？
Slide 29
Slide 29 text
29
検証でヒアリング落とし⽳あるある
僕は使えますね。
でも、ちょっとわかりにくかったんで、
ここに説明を出すのがいいと思います。
どうですか？使えましたか？
Slide 30
Slide 30 text
30
黒い⽫問題
2006年初版
Slide 31
Slide 31 text
31
黒い⽫問題
ある食器メーカーが「次に買うとしたらどんなお皿がいいか」というテーマで
主婦５人にグループインタビューをした。
参加者はデザイン案・経験談をもとに討議を進め、最終的には「これまでと
は違う、オシャレでカッコイイ黒い四角いお皿」という意見でまとまった。
インタビュー協力のお礼に、食器サンプルの中からどれでも好きなモノを１
つだけ持って帰って良いことに。
（引用：ユーザ中心ウェブサイト戦略 p87）
Slide 32
Slide 32 text
32
黒い⽫問題
参加者全員が持って帰ったのは、結局「白い丸い皿」だった。
白い丸いお皿を持って帰ろうとした理由を尋ねると「４人家族なので、1枚
だけ黒いお皿をもらっても仕方がない」「家にあるお皿の多くは丸いお皿。
四角いお皿だと食器棚に並べることができなさそう」という現実的な理由が
得られた。
（引用：ユーザ中心ウェブサイト戦略 p87）
Slide 33
Slide 33 text
ユーザの意⾒ではなく、⾏動という事実
Slide 34
Slide 34 text
34
Slide 35
Slide 35 text
35
計画こそ命
● いちばん致命的なのは、狙っているユーザーではないこと
○ 例：リテラシーが⾼すぎる
○ 例：業務のバックグランドが違う
○ 例：めちゃくちゃ好意的なロイヤルユーザー
● リクルーティング失敗するとなかなか意図した検証ができない（設計８割）
Slide 36
Slide 36 text
36
ヒアリング落とし⽳あるある
● 「使いにくかったですか？」 ⾃分が感じた前提で誘導
● 「実はここをこうするとよくて…」 解決策としての使い⽅を案内
● 「何があればいいですか」 不⾜機能を聞いてしまう
● 「ここがこうだったらどうですか？」 機能提案して印象を聞く
Slide 37
Slide 37 text
37
ヒアリング落とし⽳あるある
● ⾃分たちが作ったものなので、使って欲しい、説明したくなる
● 使えていないとショック
● 困ったことは早く解決してあげたい
● 要望をそのまま受け取ろうとしちゃう
Slide 38
Slide 38 text
38
ユーザーを⾒ることで⽣じる副作⽤
https://www.amazon.co.jp/dp/4297119951
Slide 39
Slide 39 text
39
ユーザーを⾒ることで⽣じる副作⽤
● ユーザーの情報の鮮やかさに引っ張られる
○ ⽬の前にしたN＝1のユーザーの声をかなえてあげたくなってしまう
○ それぞれがいいと思ったものを開発したくなってしまわない？
○ 重要なものに投資できなくならない？
ユーザーの声をきき、受け⽌めるにもスキルがある、事前準備しよう
Slide 40
Slide 40 text
ユーザの意⾒ではなく、⾏動という事実
Slide 41
Slide 41 text
41
ユーザの意⾒ではなく、⾏動という事実を重視する
● いつもユーザーが⾏なっている⾏動か？
○ こちらを思って⾊々説明してくれた結果、⽇々の⾏動ではなかったり
○ ⾃らを正当化する⼈間の防衛本能が働いたり
● 発⽣頻度は？致命度は？
○ N＝3くらいの再現性ができてから優先度をあげる
Slide 42
Slide 42 text
42
「使いにくい」とはなにか？
ユーザビリティ
特定のユーザが特定の利⽤状況において、システム、製品⼜はサービスを利⽤す
る際に、効果、効率及び満⾜を伴って特定の⽬標を達成する度合い。
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Z+8521%3A2020
Slide 43
Slide 43 text
43
「使いにくい」とはなにか？
ユーザビリティ
特定のユーザが特定の利⽤状況において、システム、製品⼜はサービスを利⽤す
る際に、効果、効率及び満⾜を伴って特定の⽬標を達成する度合い。
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Z+8521%3A2020
Slide 44
Slide 44 text
44
You Are Not the User.
● ユーザビリティは特定の⽂脈におけるタスク
の達成しやすさ
● ユーザーと業務を知らない限り、
「使いにくい」が妄想になってしまう
● ⾃分がユーザーになりにくいプロダクトで
は、業務理解が使いやすさの設計のもと
https://amzn.asia/d/irPchep
Slide 45
Slide 45 text
45
You Are Not the User.
https://www.redbubble.com/i/sweatshirt/You-are-NOT-the-user-UX-by-theriskworld/51243441.0LCRC
Slide 46
Slide 46 text
46
You Are Not the User.
https://www.amazon.co.jp/dp/B0CLP39RN6
Slide 47
Slide 47 text
47
You Are Not the User.
https://www.amazon.co.jp/dp/B0CLP39RN6
Slide 48
Slide 48 text
toBアプリケーションの
「アウトカム」とは何？
Slide 49
Slide 49 text
49
出現が増えてきたような⾔葉「アウトカム」
Output vs Outcome vs Impact
Slide 50
Slide 50 text
50
出現が増えてきたような⾔葉「アウトカム」
● 製品を利⽤した結果もたらされる効果が「アウトカム」
○ 課題が解決した
○ 新たな可能性が⽣まれた
○ 顧客が適応したOR⾏動が変わった
Slide 51
Slide 51 text
51
「カスタマージャーニーマップ」を書けばいい？
● ソフトウェアを使ってもらう相⼿は「カスタマー」なのか？
● 業務アプリケーションの場合は、購⼊者と使⽤者が違う場合も
http://tech-pic.com/
Slide 52
Slide 52 text
52
「カスタマージャーニーマップ」を書けばいい？
…CJMを次のように定義していますー「顧客のプロセス、ニーズ、
認識を、対象の企業との関係全般にわたって視覚的に図示したド
キュメント」。
CJMでは通常、対象の企業の顧客として個人がもつ関係に焦点を
当てます。その上で、意思決定のプロセスにスポットライトを当てる
ケースが多いのです。
…「そうした多数のタッチポイントの関係を正確に把握して調整し、
一貫性のある全体をどう作り出すか」です。…CJMはタッチポイント
を可視化して、より効率よく管理するための戦略ツールなのです。
（マッピングエクスペリエンス p.249-252）
Slide 53
Slide 53 text
53
「業務アプリケーション」なんだから「業務」でしょ
https://dictionary.goo.ne.jp/word/%E6%A5%AD%E5%8B%99/
Slide 54
Slide 54 text
54
「業務アプリケーション」なんだから「業務」でしょ
● 達成しなければならない「業務」のためにソフトウェアを作っている
○ ※契約やプラン周りの話になると、購買シナリオに近くなる場合も
● 購買時の期待を知っておくことは必要だが、業務のコアで使うアプリケーショ
ンには業務の理解が必要
Slide 55
Slide 55 text
置かれた環境と、業務プロセスへの理解をすべし
Slide 56
Slide 56 text
56
なぜ業務を知ることが重要と思っているか
● 業務のソフトウェアは、業務の道具
● 業務を知らずして道具は作れない
● 道具を作ることは、彼らの業務を作ること
● 使い⽅を決める ＝ ユーザーの業務をコントロールできてしまう
● インターフェースを決める倫理観‧責任感が伴う
Slide 57
Slide 57 text
57
なぜ業務を知ることが重要と思っているか
7.1 情報システムは用途、ソフトウェアは道具
…ソフトウェアは、情報処理を支援する「道具」であって、情報処理
システム自体ではありません。
…一方、ソフトウェアのデータモデルはそれより間接的で、想定され
る用途向けの帳簿を作るなど、業務を支援するための素材のような
ものです。用途は狭く定義されている場合もありますが、広い場合
もあります。住所録ソフトは、住所録管理という用途に狭く特化した
道具です。スプレッドシートは、広い用途をもち、そのひとつとして住
所録管理に用いることもできる道具です。（データモデリングでドメインを駆
動する p.159）
Slide 58
Slide 58 text
58
なぜ業務を知ることが重要と思っているか
どんな「⽤途」の「道具」をつくるのか？
Slide 59
Slide 59 text
59
ソフトウェアは、業務の道具
Slide 60
Slide 60 text
60
「ペイン」「ニーズ」そのまえに
● まず達成すべきは業務が達成できること
● 実現したいこととのギャップがペイン
○ そのまま解決することがゴールではないかもしれない
○ 根っこを知れば技術や設計の⼒でもっと⼤きな価値を提供できるかも
Slide 61
Slide 61 text
61
業務のオタクになれ
● 利⽤者は誰？
○ 組織の中に複数のユーザーがいることがある
● 組織のなかで、どんな関係性で働いているのか？
○ 何の情報をやりとりしているのか？
○ 情報はどのようにやり取りされているのか？
○ どんな⼒が働いているのか？
● 個々のユーザーの仕事のゴールと⽬的、はじまりと終わりは何か？
● 何が評価されるのか？
Slide 62
Slide 62 text
よーし「ユーザー検証」だ！
ちょっと待って、
ユーザに突撃する前に
Slide 63
Slide 63 text
63
じゃあペルソナつくりましょう！あるある
名前：降井圭利
年齢：42歳
家族構成：同い年の妻、⼦供２⼈（５歳‧２歳）
埼⽟在住
⚪⚪の会社に勤めている
次の管理職候補のエース
Slide 64
Slide 64 text
64
『ゴムのユーザー』に向けて作っていないか？
…しかし、これでは設計チームメンバが自分勝手なユーザ像を思
い描くことができてしまうので、何も定義していないのと同じなので
す。このようなユーザ定義を
、アラン・クーパーは『ゴムのユーザ（elastic user）』と揶揄していま
す。設計者の都合に合わせて伸縮自在のユーザという意味です。
…当然ながら、本来は設計者が”ユーザの都合”に合わせるべき。
（情報アーキテクチャ p.6-7）
Slide 65
Slide 65 text
65
ビジネス上どのセグメントに注⼒しているか知っている？
ここのユーザーに
使って欲しい
今のプロダクトのファン
※イメージ
将来的には使って欲しい
が今じゃない
Slide 66
Slide 66 text
66
ビジネス上どのセグメントを狙っているか知っているか？
● ビジネス的に注⼒するセグメントごとに使われ⽅が違ったりもする
○ どんなユーザー層に受け⼊れられている？
○ 今開発しているプロダクトはどこを狙っている？
● 何の課題を解くことが施策の使命なのか？
○ ターゲットとするユーザーのリテラシーは？
○ そのユーザーがどうなることを望んでいる？
Slide 67
Slide 67 text
ユーザのあたりもついた、ヒアリングだ！
Slide 68
Slide 68 text
68
丸腰で突撃するリスク
ユーザーから⾒ればあなたはプロダクトのプロ
● 業務⾯
○ ⾔葉や⼀般的な流れを理解していないとそもそもを聞いてしまう
○ 全く業務を知らないと印象悪いかも…
● プロダクト⾯
○ 担当プロダクト以外の質問が⾶んでくる場合も
○ 詳しい⼈が⼀⼈いると安⼼
Slide 69
Slide 69 text
69
どこの情報を⾃分たちは知らないのか？
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
書籍で知れるような業務の⼀般知識
調べにくさ
難しい
やさしい
Slide 70
Slide 70 text
70
どこの情報を⾃分たちは知らないのか？
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
業務の⼀般知識
調べにくさ
難しい
やさしい
ここくらいまでは、
書籍や社内の有識者
から得られる可能性
Slide 71
Slide 71 text
71
どこの情報を⾃分たちは知らないのか？
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
業務の⼀般知識
調べにくさ
難しい
やさしい
社内関係者が知って
いるかも、⾏かない
と分からない領域に
Slide 72
Slide 72 text
72
どこの情報を⾃分たちは知らないのか？
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
業務の⼀般知識
調べにくさ
難しい
やさしい
新しく設計する際はこのあ
たりまで知っておきたい。
業務を分析する上での材料
Slide 73
Slide 73 text
73
どこの情報を⾃分たちは知らないのか？
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
業務の⼀般知識
調べにくさ
難しい
やさしい
プロダクトリリース後、
検証や利⽤状況を確認する
場合はここを⾒にいく
Slide 74
Slide 74 text
74
でも…「操作」だけじゃない
業務達成のためのソフトウェアの細かな操作
ユーザーの業務プロセスや⾏動‧⼯夫
会社毎の慣習や独⾃の⼯夫‧ルール
業界‧地⽅の慣習
業務の⼀般知識
操作の
「⽬的」の⼟台
→達成したい業務
Slide 75
Slide 75 text
75
業務のオタクを深めるための⽅法（ひろみつの場合）
● 業界知識
○ 業界の基礎知識本を読む
○ 簿記ドリルを解く
○ 社内の業界経験者に話を聞く
○ 業界の友達と雑談する
○ 実家に来ている会計⼠さんに話を聞く
Slide 76
Slide 76 text
76
業務のオタクを深めるための⽅法（ひろみつの場合）
● ユーザー
○ 税理⼠さんや会計⼠さんのブログを読む
○ カンファレンスやユーザー会に参加する
○ 業務の観察に⾏く
○ 会計事務所内の関係者マップをつくる
Slide 77
Slide 77 text
77
オタクを深める⽅法（チームで）
● 業務のシミュレーションをする
○ freee、他ソフトを触る会
※実際の勉強会の資料
Slide 78
Slide 78 text
78
業務を観察する
● 普段業務を行っているデスクの近くにお邪魔する
● 見せていただきたい業務を再確認する
● 普段通り業務を進めてもらって黙って見る
● ひとかたまりの業務を見せていただいた後に、気になる
行動などをインタビューする
Slide 79
Slide 79 text
79
師匠と弟子のように
https://www.amazon.co.jp/dp/4274214834
インタビュアーを弟子、ユーザーを師匠
と見立てて、師匠の体験を弟子に継承
するイメージ
Slide 80
Slide 80 text
「知らないこと」なのか
「仮説」なのか
Slide 81
Slide 81 text
81
「知らないこと」なのか「仮説」なのか
● 知らないこと
○ 知るすべがあるものは学習できる
○ 調べられないものは現場に⾏って知る
● 仮説
○ できるだけ早いうちに潰す
○ 実装だけスプリントで回していると、レビューでは遅い場合も
Slide 82
Slide 82 text
82
コスト低く早めに検証すべし
プロジェクトマネジメント知識体系ガイド（ PMBOKガイド）第7版
● ライフサイクルが進⾏するにつれ、修正作業のコストは⾼くつく
Slide 83
Slide 83 text
83
コスト低く早めに検証すべし
● 実装しなくても検証できるもの
● 実装しないと検証できないもの
● 実データが⼊らないと検証できないもの
● 業務の現場に導⼊され、⼀定期間利⽤しないと検証できないもの
ディスカバリーからバックログに載っていないと全体の仮説は⾒えない
（これをチームでやるのがデュアルトラック）
Slide 84
Slide 84 text
84
あなたの「スクラム」はどこから？
https://www.mobiusloop.com/
Slide 85
Slide 85 text
85
あなたの「スクラム」はどこから？
https://www.mobiusloop.com/
スクラムを取り⼊れよう！
という動きは、
デリバリー側から→
はじまることが多い
（主観）
Slide 86
Slide 86 text
86
検証の⽬的は様々
● 受け⼊れられそうか確認する
● UIの使い勝⼿を検証する
● 作ったものが⻑期的に仕事で使い物になるか検証する etc
Slide 87
Slide 87 text
87
たとえば画⾯設計
PR‧製品品質‧
リードタイムを含めた
サービス全体の体験
スケッチ
画⾯イメージ
プロトタイプ
検証環境 リリース後サービス
UI、レスポンスの精度
操作性など
アプリ内の体験
表⽰情報‧レイアウト
⾊使いなどの適切さ
コンセプトの受容性
表⽰情報の適切さ
コンセプトの受容性
低精度 ⾼精度
Slide 88
Slide 88 text
88
レビュー⼿段のひとつとしての、ユーザビリティテスト
ユーザビリティテスト
設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること
プロダクトデザイン
ユーザビリティ
テスト
業務観察
設計を
検証する
得たヒントを
活かす
設計を修正する
● ユーザビリティ上の仮説が⼤きかったり、使いやすさが重要な場合に有効
Slide 89
Slide 89 text
89
やりかた
● プロダクトチーム、関係者、ユーザーに近い⼈を呼ぶ
● 事前の機能説明などは⾏わず仮の状況を伝え、利⽤をシミュレーション
● メンバーは⾏動を観察
● その後操作中に気になった⾏動を深掘りしたり、発話を深掘りする
Slide 90
Slide 90 text
90
現実の環境に近いシナリオを提示してシミュレーション
Slide 91
Slide 91 text
91
Slide 92
Slide 92 text
92
チームをリサーチに巻き込む際に気をつけていること
● 現場での振る舞いのインプットをしておく
● ヒアリングの落とし⽳を共有しておく
○ できるだけ「⾏動」「発⾔」のFACTを持ち帰られるように
● とはいえその通りにはすぐには⾏動できないので、⼀度体験
○ 経験者と⼀緒に参加すると、その後の情報の吸収⼒が変わる
Slide 93
Slide 93 text
93
複数職能が検証に参加すると何がいいのか？
● 複数の⽬で観察できる効率
● 職能が違えばかけているメガネが違う
○ 違う⾓度からの情報が網羅的に集まる
○ 同じ感覚を共有していると同じ⽅向を向きやすくなる
ユーザーの業務を知ったり、ユーザーの声を受け⽌めるスキルをつけよう
Slide 94
Slide 94 text
94
複数の関係者が同じユーザーに話を聞いていないか？
● 「あれ？今度⚪⚪さんがいらっしゃいますよ」系ヒヤリハット
● そのFeatureが届くまで、様々な⼈々が関わり⽇々信頼を積み上げている
○ マーケティング
○ カスタマーサクセス
○ カスタマーサポート etc…
● 影響を受ける「ユーザー」はひとりではない
○ 相対している⼈がユーザーに詳しい場合もある
Slide 95
Slide 95 text
95
レビュー⼿段のひとつとしての、社内ヒアリング
社内担当者は、日々顧客に接しながらその特徴など分析を重ね…社内担
当者は顧客を特徴ごとに分類し、体系化して捉えているため、その知恵を
最初に借りることで、高い精度でターゲットユーザを想定できるのである。
まずは社内の人間を通して、ユーザを知る作業をスタートさせると良いだろ
う。
社内ヒアリングで獲得したいのは、既存の数値データなどには現れにくい
事実、つまり担当者の人間の感覚としての経験値である。…担当者の過
去の経験、あるいは現在の経験という”事実”を引き出すことが重要であ
り...。社内ヒアリングの基本姿勢は、担当者が感じている顧客に関する経
験則を上手に引き出すことなのである。
（引用：ユーザ中心ウェブサイト戦略）
Slide 96
Slide 96 text
まとめ
Slide 97
Slide 97 text
97
ユーザーに突撃して検証する前にできることがある
● スクラムのリズムが安定してくるとアウトカムに⽬がいくようになる
● ユーザと業務のオタクになるべし
● どこの情報を⾃分たちは知らない？解像度も分けて考えられる
● ユーザーの声をきき、受け⽌めるにもスキルがある、事前準備しよう
● ステークホルダーへの影響もある、彼らの経験則を引き出そう
Slide 98
Slide 98 text
98
わたし視点で提供できそうと思っていること
● アウトカムに意識がむき始めるタイミングで、リサーチの知識が役⽴ちそう
● デザイナーの帽⼦をかぶっている⼈がその知の⾼速道路を引けるかも
● 特に開発からスクラムの導⼊が始まっているチームは融合のチャンス！
ユーザーに当てたい！と思ったとき、今⽇の内容が参考になると嬉しいです
Slide 99
Slide 99 text
ご清聴ありがとうごさいました！