uxデザイナーがpoとして開発チームと”握る”ためにやっていること...
TRANSCRIPT
UXデザイナーがPOとして開発チームと”握る”ために
やっていること株式会社ヴァル研究所 伊藤英明
UX Cafe: B2BサービスのUXデザインを語ろう 2017/9/27
アジェンダ
• 自己紹介
• UXデザイナー兼、POとして関わっているサービス「RODEM」について
• 開発の中での課題
• スクラム開発でやっていること
• まとめ
自己紹介
• 株式会社ヴァル研究所Business Development Dept. UXデザイナー
• 自社のメイン商材である の技術をベースにした新規事業開発の仕事をしています
• RODEMのPO(プロダクトオーナー)
• 経歴的には、デザイナー(プロダクト、UI) →ユーザビリティエンジニア → UXデザイナー
自分のスキル構造
プロダクトデザイナー
ユーザビリティエンジニア
UIデザイナー
リサーチャー
エンジニアではない…
UXデザイナー
担当サービス「RODEM」
アポイントメント時
どのくらい移動時間がかかる
か
知るため、カレンダーに移動
の
予定を入れるために検索
業務で外出するたびに何度も経路検索をしていませんか?
アポイントメント当日
具体的に何時に出発するかを
決めるために検索
業務で外出するたびに何度も経路検索をしていませんか?
交通費精算時
いつどこに打合せに行った
か、
どのくらいの運賃がかかっ
た
のか、その日のことを思い
出しながら改めて検索
業務で外出するたびに何度も経路検索をしていませんか?
あなたの交通費精算は各駅停車ではありませんか?
• ユーザーはカレンダーに予定を入れるだけ
普段と同じように打合せの予定をカレンダーに登録
担当サービス「RODEM」
普段と同じように打合せの予定をカレンダーに登録
目的地までの経路や出発時刻を計算移動予定をスケジュールに追加登録する
• システムが移動予定が算出して登録
担当サービス「RODEM」
• 算出されたデータを使って交通費精算ができる
担当サービス「RODEM」
あなたの交通費精算を各駅停車から超特急に!
87%の工数削減!!
UXデザイナー兼、POという立場
• UXデザイナーとして
ユーザー目線に立った機能、仕様等の検討ユーザーへの価値提供に責任を持つ
• PO(プロダクトオーナー)として
サービス開発の舵取りチームへの説明責任サービスのスケールに責任を持つ
開発中の課題
• 新機能や機能改善のリリースとフィードバックのサイクルを可能な限り早く回したい
• 小さく早く回したいが、何を作って何を確認したいのか、何ができていることが求められるのかを明確にしないと作ったものがムダになる
→POが求めているものと開発チームが作ろうとするもののズレが開発の遅れにつながる
POと開発チームとの間での“握り”が大事
何を握るの?
【握る】
握る(にぎる)とは、合意するという意味
この場合、文章で正式に交わされた合意というよりは、信頼関係をもとに人対人で合意することを意味する。
立ち話や口頭でのやり取りなどの根回しも含む。
※出展:大Misoca百科
なにを握るの?
POと開発チームの間で、
「それは何のために作るのか」「ユーザーがどうなることを目指すのか」「どういう効果やメリットを狙っているのか」「どうやって実現するのか」「どういう結果が得られたのか(後から共有)」
を共有し、合意の上で開発を進めたい。
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクトバックログ
スプリントバックログ
2週間のスプリント期間
デイリースクラム
リリース可能な状態
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクトバックログ
・開発項目、機能、要求をまとめたもの
・POとPMで事業戦略含め内容を検討して作成
・PBIをリストにしてすべてに優先順位をつける
・PBIの追加、変更、優先順変更は随時行われる
PBIの作成
• MVPキャンバスの作成
• why、what、how、受け入れ条件を設定
why:なぜその開発をする必要があるのかという目的
what:何を作るのか、実現のためのソリューション
how:どうやって作るのか、具体的な開発タスク
受け入れ条件:リリースOKの基準となる機能や仕様
MVPとは
Build-Measure-Learnのフィードバックループ1周を回せる『必要最低限の労力』+『最低限の実装時間』バージョンの製品」
MVPキャンバス
https://www.slideshare.net/aerodynamic/mvp-canvas
MVPキャンバス
https://www.slideshare.net/aerodynamic/mvp-canvas
仮説
何を学ぶのか、期待値
MVPのタイプ 何を作るのか、仮説をどうやってMVPで実証するのか
実証に必要なデータ、条件
MVP構築に必要なコスト
実証に必要な時間
回避/発生する将来のリスク
結果と、得た学び
PBIの管理
スプリント内で
開発対象とするPBI
スプリントの各回
次の次の回くらいまでのPBIは作成しておく
PBIの管理
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
スプリントバックログ
・各PBIに対して、開発に必要なタスク(調査等も含む)を書き出したもの
・開発チームが作成する
・各SBIは想定する工数見積がされており、開発の進捗をバーンダウンチャートでも管理する
・Sprint開発期間に入ってから追加されるSBIもある
SBIの作成と管理
PBI SBI
SBIの作成と管理
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
2週間のスプリント期間
デイリースクラム
・毎日の朝会で進捗を確認
リリース可能な状態
・2週間でリリース可能な状態にする
ToDo
Doing Done
レビュー可能になった
PB
I
PBI
SBIの作成と管理
スクラム開発
http://www.derekhuether.com/2011/02/19/free-intro-to-scrum-wallpaper/
プロダクトバックログ
スプリントバックログ
2週間のスプリント期間
デイリースクラム
リリース可能な状態
Sprint内のサイクル
• 前々週の後半:次SprintのPBI説明(POから開発チームへ、MVPキャンバス、why、what、受け入れ条件の共有)
• 前週中:PBIリファインメント(開発チームからPOへ、疑問点の確認、howを詰める)
• スクラムイベント:前SprintのPBIレビュー、次Sprintで取り組むPBIの決定、PBIをSBIに細分化
• 開発Sprint:実質9稼働日の開発期間
Sprint内のサイクル
week1 week2 week3 week4 week5 week6
前Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
今Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
次Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
Sprint内のサイクル
week1 week2 week3 week4 week5 week6
前Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
今Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
次Sprin
t
次SprintのPBI説明
PBIリファインメント
スクラムイベント
開発Sprint
・実質的な開発期間
・Sprint前から共有、調整を始める
まとめ
UXデザイナーがPOとして開発チームと”握る”ためにやっていること
「何のために握っている?」→新機能や機能改善のリリースとフィードバックのサイクルを可能な限り早く回すため
「何を握っている?」→何を作って何を確認したいのか、何ができていることが求められるのか
「握るために何をやっている?」→PBIの作成と共有、リファインメントによる調整
ご静聴ありがとうございました。