プロダクト開発を繋げる
0.9K Views
July 31, 19
スライド概要
プロダクト開発の分断をGuildHubで繋げる
関連スライド
各ページのテキスト
プロダクト開発を”繋げる” 仮説から機能、そして検証からの仮説再定義へ プロダクト開発の分断をGuildHubで繋げる Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓
市⾕ 聡啓 Ichitani Toshihiro (My KeyWord) 越境 正しいものを正しくつくる 仮説検証型アジャイル開発
Profile https://ichitani.com/
4刷 https://www.amazon.co.jp/dp/4798153346/
6⽉14⽇発刊 https://www.amazon.co.jp/dp/4802511191/
GuildHub 何の⼿がかりも無いプロダクトーナーに 正しいものを正しくつくる https://lp.guildhub.jp/ ベータ版が公開されたGuildHubを使って仮説キャンバスを作ってみる https://qiita.com/navitime_tech/items/2cb0d674c8d3a5f8a6a6
プロダクト開発で直⾯する分断問題とは？
プロダクトオーナー プロダクトとして どうあるべきって どう考えるべき… 仮説から開発、検 証まで全体にかか るリードタイムが 全く不明。 検証やテストをし てもそこで分かっ たことが消えてい く… どこまで整理した ら開発可能になる のか分からない 開発チーム 何でそれをつくる のかのWhyが⾒ えない リリースして、 それからどうする の？ ステークホルダー
プロダクト開発で直⾯する”分断問題” ① プロダクトオーナーとして、どのような観点でプロダクトの PO 構想を練れば良いのか。 ② プロダクトオーナーとして、仮説から機能へどのようにして 落とし込めば良いのか。(どうなれば開発レディ？) PO ③ 開発チームからすると、開発機能のWhyが⾒えない。 開発チーム ④ それなりの開発期間を経るため、何のために作っていたのか 全員 分からなくなる。 ⑤ 検証結果とその学びが蓄積できていない。 全員(+組織) ⑥ 仮説⽴案〜機能開発〜検証までのリードタイムが全く⾒えない 全員
プロダクト開発で直⾯する”分断問題” ①どのような観点でプロダクト の構想を練れば良いのか。 構想が的外れでつくってもムダ ②仮説から機能へどのようにし て落とし込めば良いのか。 開発チームのアウトプットがブレる (やりなおしが増える、時間がかかる) ③開発機能のWhyが⾒えない ④何のために作っていたのか分 からなくなる。 ⑤検証結果とその学びが蓄積で きていない。 ⑥仮説⽴案〜機能開発〜検証まで のリードタイムが全く⾒えない 余計な質を作り込んでしまう （プロダクトの⽅向性がぶれる） 失敗や学びを次に⾏かせない カイゼンが全く無い
どのような観点でプロダクトの構想を練れば良いのか PO 良くある現象 構想が的外れでつくってもムダ ⽅法としての知識獲得 → 「仮説検証型アジャイル開発」 プロダクトの構想づくり(仮説検証)から開発へと繋ぎ、また構想 へと戻していく、まとまった⽅法が無かったのでまとめた。 (特に開発への繋ぎに関する情報がほとんど無い)
仮説検証型アジャイル開発 選択の幅最⼤ 仮説⽴案 （セットベース） (モデル化) 検証 計画 価値探索 （正しいものを探す） 評価 スプリントプ ランニング 検証 開発計画 MVP特定 (リリースプラ ンニング) 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 アジャイル開発 （正しくつくる） スプリント レトロスペクティ ブ MVP検証 スプリント レビュー 次の検証計画 (価値探索)へ …最初に取り掛かるのは「仮説の⽴案」=仮説キャンバスづくり
「仮説」の⾒える化 仮説キャンバス ・「仮説」を明らかにする観点はいくらでも考えられる。初期段階で状態を 分かるようにしておきたいのが仮説キャンバスの14の観点。 ・14の観点 = 14の問い。例「どういう状況の⼈たちが対象の話なのか？」
キャンバスワークの問題 ホワイトボードまたはプレゼンテーションツールでつくることが 多いが、その後の更新、共有がやりづらい。 情報の共有、最新化が⾏き届かず、チームの共通理解が深まらない。 デジタル的にチームで共有、共同できる⼿段が欲しい。 仮説キャンバスをオンラインで作成して 共有(招待)、共同編集、コメントできる。 (GuildHub - 仮説キャンバス) 構想を練るのは⼀⼈になりがち。 早い段階から編集可能なモノを共有し、 他者からフィードバックを得るようにする
仮説から機能へどのように落とし込めば良いのか 良くある現象 開発チームのアウトプットがブレる (やりなおしが増える、時間がかかる) PO 情報の粒度、詳細度を段階的に整えていく → 「ユーザー⾏動フロー」 ユーザーストーリーマッピング等、ユーザーの⾏動フローを ベースに、⾏動に伴う課題の可視化、課題解決のための機能性を 抽出する。 PO、開発チーム、関係者で集まってワークショップ形式で ホワイトボードや模造紙+付箋を使って、ユーザー⾏動フローを 表現する。その作成過程で、ユーザーの状況や必要な機能性に ついての共通理解を得る。
「ユーザー⾏動」の⾒える化 ユーザー⾏動フロー ・検証の結果から分かってきた想定ユーザーの⾏動を明らかにする。 ⾏動から⽣まれる課題、課題に対して必要な機能性を導き出す。 ・明らかにする⾏為をチームで⾏い、多様な⾒⽅から総体としての発⾒を増やす。
ユーザー⾏動フローづくりでの問題 ホワイトボードまたはプレゼンテーションツールでつくることが 多いが、その後の更新、共有がやりづらい。(キャンバス同様) 情報の共有、最新化が⾏き届かず、チームの共通理解が深まらない。 デジタル的にチームで共有、共同できる⼿段が欲しい。 ユーザー⾏動フローをオンラインで作成 して共有、共同編集できる。 (GuildHub -ユーザーストーリーマッピング) 2019/8予定 ユーザー⾏動フローは要素が多く、全体像 にあたるため変更可能性が⾼く、キャンバ ス以上に途中で捨てられる可能性が⾼い。
「ユーザー⾏動フロー」→「ストーリーリスト」 「フロー」から「リスト」に移⾏するところで、開発レディとなる よう、より情報の粒度を細かくし、詳細度を上げるようにする。 2019/9予定 ユーザーのざっくりとした いわゆるプロダクトバックログに ⾏動、課題、必要な機能の⾒⽴て あたるリスト (開発チームと共有し、詳細化を⽀援 してもらう)
GuildHubでこれから実現すること ③開発機能のWhyが⾒えない ④何のために作っていたのか分か 仮説〜USM〜ストーリーリストの 間での関連を維持できるようにして 関係性とリードタイムを可視化する (ex 仮説紐付かない機能の特定、その逆の可視化) らなくなる。 ⑤検証結果とその学びが蓄積でき ていない。 ⑥仮説⽴案〜機能開発〜検証まで のリードタイムが全く⾒えない 仮説キャンバスと対になる 検証キャンバスの⽤意とその履歴管理
「検証計画」の⾒える化 検証キャンバス 検証するべき仮説 指標と事前期待 MVPのタイプ MVPの機能性、特徴 検証⽅法 検証環境 検証結果(事実の記録) スケジュール 結果から学んだこと 次にやること ・どのように何をどうやっていつ検証するのかという「検証計画」を⽴てるために。 これからの計画についてチーム共通の理解をつくる。「何やるんだっけ？」無くす ・踏まえて、検証結果(事実)から何が分かるか(学び)を記録する。
GuildHubで"繋げるプロダクト開発” 仮説？ ⾏動/課題？ ストーリー (機能) MVP (機能群) タスク 検証計画？
GuildHubで"繋げるプロダクト開発” GuildHub 仮説キャンバス 仮説 ユーザー⾏動フロー ストーリーリスト ⾏動/課題 ストーリー (機能) MVP (機能群) タスク 検証キャンバス 検証計画 検証対象となる機能群
GuildHubで"繋げるプロダクト開発” GuildHub 仮説キャンバス 仮説 ユーザー⾏動フロー ストーリーリスト ⾏動/課題 ストーリー (機能) 2019/8予定 2019/9予定 MVP (機能群) タスク 検証キャンバス 検証計画 2019/10〜 検証対象となる機能群
GuildHubの⽬指す世界観
POの⼿元で練ったアイデアを すぐに検証や開発へと繋げることができる。 結果、学習までの距離が短い。 「もっと⼩さく早く試せる世界(“マイクロ仮説検証”)」
アイデアを仮説にし、機能に落とし込む流れを チーム共有するため、誰もがPOになり得る。 チームで基準(共通理解)をつくり、共同する。 「プロダクトオーナーの⺠主化」
プロダクトの背景、Whyが⾒える化される為 チーム内、参画先後のメンバーの間での ⽂脈共有コスト(参加障壁)を下げられる 「”チーム”の境界の透明化」
新しい開発ツールではなく 新たなプロダクト開発のあり⽅をつくる https://lp.guildhub.jp/