UX Cafe: B2BサービスのUXデザインを語ろう(2017/09/27)登壇スライドです

1. UXデザイナーがPOとして
開発チームと”握る”ために
やっていること
株式会社ヴァル研究所 伊藤英明
UX Cafe: B2BサービスのUXデザインを語ろう 2017/9/27

2. アジェンダ
• 自己紹介
• UXデザイナー兼、POとして関わっている
サービス「RODEM」について
• 開発の中での課題
• スクラム開発でやっていること
• まとめ

3. 自己紹介
• 株式会社ヴァル研究所
Business Development Dept. UXデザイナー
• 自社のメイン商材である の技術をベースにし
た新規事業開発の仕事をしています
• RODEMのPO(プロダクトオーナー)
• 経歴的には、デザイナー(プロダクト、UI) →
ユーザビリティエンジニア → UXデザイナー

4. 自分のスキル構造
プロダクト
デザイナー
ユーザビリティ
エンジニア
UIデザイナー
リサーチャー
エンジニアではない…
UXデザイナー

5. 担当サービス「RODEM」

6. アポイントメント時
どのくらい移動時間がかかる
か
知るため、カレンダーに移動
の
予定を入れるために検索
業務で外出するたびに何度も経路検索
を
していませんか？

7. アポイントメント当日
具体的に何時に出発するかを
決めるために検索
業務で外出するたびに何度も経路検索
を
していませんか？

8. 交通費精算時
いつどこに打合せに行った
か、
どのくらいの運賃がかかっ
た
のか、その日のことを思い
出しながら改めて検索
業務で外出するたびに何度も経路検索
を
していませんか？

9. あなたの交通費精算は各駅停車では
ありませんか？

10. • ユーザーはカレンダーに予定を入れるだけ
普段と同じように打合せの予定を
カレンダーに登録
担当サービス「RODEM」

11. 普段と同じように打合せの予定を
カレンダーに登録
目的地までの経路や出発時刻を計算
移動予定をスケジュールに追加登録する
• システムが移動予定が算出して登録
担当サービス「RODEM」

12. • 算出されたデータを使って交通費精算ができる
担当サービス「RODEM」

13. あなたの交通費精算を各駅停車から超特急
に！
８７％の工数削減!!

14. UXデザイナー兼、POという立場
• UXデザイナーとして
ユーザー目線に立った機能、仕様等の検討
ユーザーへの価値提供に責任を持つ
• PO(プロダクトオーナー)として
サービス開発の舵取り
チームへの説明責任
サービスのスケールに責任を持つ

15. 開発中の課題
• 新機能や機能改善のリリースとフィードバックの
サイクルを可能な限り早く回したい
• 小さく早く回したいが、何を作って何を確認したい
のか、何ができていることが求められるのかを明
確にしないと作ったものがムダになる
→POが求めているものと開発チームが作ろうとす
るもののズレが開発の遅れにつながる

16. POと開発チームとの間での
“握り”が大事

17. 何を握るの？

18. 【握る】
握る（にぎる）とは、合意するという意味
この場合、文章で正式に交わされた合意というよりは、
信頼関係をもとに人対人で合意することを意味する。
立ち話や口頭でのやり取りなどの根回しも含む。
※出展：大Misoca百科

19. なにを握るの？
POと開発チームの間で、
「それは何のために作るのか」
「ユーザーがどうなることを目指すのか」
「どういう効果やメリットを狙っているのか」
「どうやって実現するのか」
「どういう結果が得られたのか(後から共有)」
を共有し、合意の上で開発を進めたい。

20. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/

21. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクト
バックログ
スプリント
バックログ
2週間の
スプリント期間
デイリースクラム
リリース
可能な状態

22. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクト
バックログ
・開発項目、機能、要求をまとめたもの
・POとPMで事業戦略含め内容を検討
して作成
・PBIをリストにしてすべてに優先順位を
つける
・PBIの追加、変更、優先順変更は随時
行われる

23. PBIの作成
• MVPキャンバスの作成
• why、what、how、受け入れ条件を設定
why：なぜその開発をする必要があるのかという目的
what：何を作るのか、実現のためのソリューション
how：どうやって作るのか、具体的な開発タスク
受け入れ条件：リリースOKの基準となる機能や仕様

24. MVPとは
Build-Measure-Learnのフィードバックループ１周を回せる『必要最
低限の労力』＋『最低限の実装時間』バージョンの製品」

25. MVPキャンバス
https://www.slideshare.net/aerodynamic/mvp-canvas

26. MVPキャンバス
https://www.slideshare.net/aerodynamic/mvp-canvas
仮説
何を学ぶのか、期待値
MVPのタイプ 何を作るのか、仮説をどうやって
MVPで実証するのか
実証に必要な
データ、条件
MVP構築に
必要なコスト
実証に
必要な時間
回避/発生する
将来のリスク
結果と、得た学び

27. PBIの管理

28. スプリント内
で
開発対象と
するPBI
スプリントの
各回
次の次の回くらい
までのPBIは
作成しておく
PBIの管理

29. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
スプリント
バックログ
・各PBIに対して、開発に必要なタスク(調査
等も含む)を書き出したもの
・開発チームが作成する
・各SBIは想定する工数見積がされており、
開発の進捗をバーンダウンチャートでも
管理する
・Sprint開発期間に入ってから追加される
SBIもある

30. SBIの作成と管理

31. PBI SBI
SBIの作成と管理

32. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
2週間の
スプリント期間
デイリースクラム
・毎日の朝会で進捗を確認
リリース
可能な状態
・2週間でリリース可能な状態にする

33. ToDo
Doing
Done
レビュー可能になったPBI
PBI
SBIの作成と管理

34. スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクト
バックログ
スプリント
バックログ
2週間の
スプリント期間
デイリースクラム
リリース
可能な状態

35. Sprint内のサイクル
• 前々週の後半：
次SprintのPBI説明(POから開発チームへ、MVPキャンバス、
why、what、受け入れ条件の共有)
• 前週中：
PBIリファインメント(開発チームからPOへ、疑問点の確認、
howを詰める)
• スクラムイベント：
前SprintのPBIレビュー、次Sprintで取り組むPBIの決定、PBI
をSBIに細分化
• 開発Sprint：
実質9稼働日の開発期間

36. Sprint内のサイクル
week1 week2 week3 week4 week5 week6
前Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
今Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
次Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint

37. Sprint内のサイクル
week1 week2 week3 week4 week5 week6
前Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
今Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
次Sprint
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
・実質的な開発期間
・Sprint前から共有、
調整を始める

38. まとめ
UXデザイナーがPOとして開発チームと”握る”
ためにやっていること
「何のために握っている？」
→新機能や機能改善のリリースとフィードバックの
サイクルを可能な限り早く回すため
「何を握っている？」
→何を作って何を確認したいのか、何ができていること
が求められるのか
「握るために何をやっている？」
→PBIの作成と共有、リファインメントによる調整

39. ご静聴ありがとうございました。