Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Uxデザイナーがpoとして開発チームと”握る”ためにやっていること 170927

1,336 views

Published on

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

Published in: Design
  • Be the first to comment

Uxデザイナーがpoとして開発チームと”握る”ためにやっていること 170927

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

×