プロダクト開発の分断をGuildHubで繋げる

1. Toshihiro Ichitani All Rights Reserved.
プロダクト開発を”繋げる”
Ichitani Toshihiro
市⾕聡啓
仮説から機能、そして検証からの仮説再定義へ
プロダクト開発の分断をGuildHubで繋げる

2. (My KeyWord)
市⾕ 聡啓
仮説検証型アジャイル開発
正しいものを正しくつくる
越境
Ichitani Toshihiro

3. https://ichitani.com/
Profile

4. 4刷
https://www.amazon.co.jp/dp/4798153346/

5. https://www.amazon.co.jp/dp/4802511191/
6⽉14⽇発刊

6. 正しいものを正しくつくる
https://lp.guildhub.jp/
GuildHub
https://qiita.com/navitime_tech/items/2cb0d674c8d3a5f8a6a6
ベータ版が公開されたGuildHubを使って仮説キャンバスを作ってみる
何の⼿がかりも無いプロダクトーナーに

7. プロダクト開発で直⾯する分断問題とは？

8. プロダクトオーナー
開発チーム
ステークホルダー
プロダクトとして
どうあるべきって
どう考えるべき…
どこまで整理した
ら開発可能になる
のか分からない
何でそれをつくる
のかのWhyが⾒
えない
リリースして、
それからどうする
の？
検証やテストをし
てもそこで分かっ
たことが消えてい
く…
仮説から開発、検
証まで全体にかか
るリードタイムが
全く不明。

9. プロダクト開発で直⾯する”分断問題”
① プロダクトオーナーとして、どのような観点でプロダクトの
構想を練れば良いのか。
② プロダクトオーナーとして、仮説から機能へどのようにして
落とし込めば良いのか。(どうなれば開発レディ？)
③ 開発チームからすると、開発機能のWhyが⾒えない。
④ それなりの開発期間を経るため、何のために作っていたのか
分からなくなる。
⑤ 検証結果とその学びが蓄積できていない。
⑥ 仮説⽴案〜機能開発〜検証までのリードタイムが全く⾒えない
PO
PO
開発チーム
全員
全員(+組織)
全員

10. ①どのような観点でプロダクト
の構想を練れば良いのか。
②仮説から機能へどのようにし
て落とし込めば良いのか。
③開発機能のWhyが⾒えない
④何のために作っていたのか分
からなくなる。
⑤検証結果とその学びが蓄積で
きていない。
⑥仮説⽴案〜機能開発〜検証まで
のリードタイムが全く⾒えない
構想が的外れでつくってもムダ
開発チームのアウトプットがブレる
(やりなおしが増える、時間がかかる)
余計な質を作り込んでしまう
（プロダクトの⽅向性がぶれる）
失敗や学びを次に⾏かせない
カイゼンが全く無い
プロダクト開発で直⾯する”分断問題”

11. どのような観点でプロダクトの構想を練れば良いのか
PO
構想が的外れでつくってもムダ良くある現象
⽅法としての知識獲得 → 「仮説検証型アジャイル開発」
プロダクトの構想づくり(仮説検証)から開発へと繋ぎ、また構想
へと戻していく、まとまった⽅法が無かったのでまとめた。
(特に開発への繋ぎに関する情報がほとんど無い)

12. 選択の幅最⼤
（セットベース）
検証
計画
仮説⽴案
(モデル化)
検証
評価
価値探索
（正しいものを探す）
MVP特定
開発計画
(リリースプラ
ンニング)
スプリントプ
ランニング
スプリント
開発
スプリント
レビュー
スプリント
レトロスペクティ
ブ
MVP検証
アジャイル開発
（正しくつくる）
次の検証計画
(価値探索)へ
選択の振れ幅最⼩
（ポイントベース）
仮説検証型アジャイル開発
…最初に取り掛かるのは「仮説の⽴案」=仮説キャンバスづくり

13. 「仮説」の⾒える化 仮説キャンバス
・「仮説」を明らかにする観点はいくらでも考えられる。初期段階で状態を
分かるようにしておきたいのが仮説キャンバスの14の観点。
・14の観点 = 14の問い。例「どういう状況の⼈たちが対象の話なのか？」

14. キャンバスワークの問題
ホワイトボードまたはプレゼンテーションツールでつくることが
多いが、その後の更新、共有がやりづらい。
情報の共有、最新化が⾏き届かず、チームの共通理解が深まらない。
デジタル的にチームで共有、共同できる⼿段が欲しい。
仮説キャンバスをオンラインで作成して
共有(招待)、共同編集、コメントできる。
(GuildHub - 仮説キャンバス)
構想を練るのは⼀⼈になりがち。
早い段階から編集可能なモノを共有し、
他者からフィードバックを得るようにする

15. 仮説から機能へどのように落とし込めば良いのか
PO
良くある現象
情報の粒度、詳細度を段階的に整えていく
→ 「ユーザー⾏動フロー」
ユーザーストーリーマッピング等、ユーザーの⾏動フローを
ベースに、⾏動に伴う課題の可視化、課題解決のための機能性を
抽出する。
PO、開発チーム、関係者で集まってワークショップ形式で
ホワイトボードや模造紙+付箋を使って、ユーザー⾏動フローを
表現する。その作成過程で、ユーザーの状況や必要な機能性に
ついての共通理解を得る。
開発チームのアウトプットがブレる
(やりなおしが増える、時間がかかる)

16. ・検証の結果から分かってきた想定ユーザーの⾏動を明らかにする。
⾏動から⽣まれる課題、課題に対して必要な機能性を導き出す。
・明らかにする⾏為をチームで⾏い、多様な⾒⽅から総体としての発⾒を増やす。
「ユーザー⾏動」の⾒える化 ユーザー⾏動フロー

17. ユーザー⾏動フローづくりでの問題
ホワイトボードまたはプレゼンテーションツールでつくることが
多いが、その後の更新、共有がやりづらい。(キャンバス同様)
情報の共有、最新化が⾏き届かず、チームの共通理解が深まらない。
デジタル的にチームで共有、共同できる⼿段が欲しい。
ユーザー⾏動フローをオンラインで作成
して共有、共同編集できる。
(GuildHub -ユーザーストーリーマッピング)
ユーザー⾏動フローは要素が多く、全体像
にあたるため変更可能性が⾼く、キャンバ
ス以上に途中で捨てられる可能性が⾼い。
2019/8予定

18. 「ユーザー⾏動フロー」→「ストーリーリスト」
「フロー」から「リスト」に移⾏するところで、開発レディとなる
よう、より情報の粒度を細かくし、詳細度を上げるようにする。
ユーザーのざっくりとした
⾏動、課題、必要な機能の⾒⽴て
いわゆるプロダクトバックログに
あたるリスト
(開発チームと共有し、詳細化を⽀援
してもらう)
2019/9予定

19. GuildHubでこれから実現すること
③開発機能のWhyが⾒えない
④何のために作っていたのか分か
らなくなる。
⑤検証結果とその学びが蓄積でき
ていない。
⑥仮説⽴案〜機能開発〜検証まで
のリードタイムが全く⾒えない
仮説〜USM〜ストーリーリストの
間での関連を維持できるようにして
関係性とリードタイムを可視化する
(ex 仮説紐付かない機能の特定、その逆の可視化)
仮説キャンバスと対になる
検証キャンバスの⽤意とその履歴管理

20. ・どのように何をどうやっていつ検証するのかという「検証計画」を⽴てるために。
これからの計画についてチーム共通の理解をつくる。「何やるんだっけ？」無くす
・踏まえて、検証結果(事実)から何が分かるか(学び)を記録する。
「検証計画」の⾒える化 検証キャンバス
検証するべき仮説
指標と事前期待
MVPのタイプ MVPの機能性、特徴
検証⽅法 検証環境 スケジュール
検証結果(事実の記録) 結果から学んだこと
次にやること

21. GuildHubで"繋げるプロダクト開発”
仮説？ ⾏動/課題？
ストーリー
(機能)
MVP
(機能群)
タスク
検証計画？

22. GuildHubで"繋げるプロダクト開発”
仮説 ⾏動/課題
ストーリー
(機能)
MVP
(機能群)
仮説キャンバス ユーザー⾏動フロー ストーリーリスト
GuildHub
タスク
検証キャンバス
検証計画
検証対象となる機能群

23. GuildHubで"繋げるプロダクト開発”
仮説 ⾏動/課題
ストーリー
(機能)
MVP
(機能群)
仮説キャンバス ユーザー⾏動フロー ストーリーリスト
GuildHub
タスク
検証キャンバス
検証計画
検証対象となる機能群
2019/8予定 2019/9予定
2019/10〜

24. GuildHubの⽬指す世界観

25. POの⼿元で練ったアイデアを
すぐに検証や開発へと繋げることができる。
結果、学習までの距離が短い。
「もっと⼩さく早く試せる世界(“マイクロ仮説検証”)」

26. アイデアを仮説にし、機能に落とし込む流れを
チーム共有するため、誰もがPOになり得る。
チームで基準(共通理解)をつくり、共同する。
「プロダクトオーナーの⺠主化」

27. プロダクトの背景、Whyが⾒える化される為
チーム内、参画先後のメンバーの間での
⽂脈共有コスト(参加障壁)を下げられる
「”チーム”の境界の透明化」

28. 新しい開発ツールではなく
新たなプロダクト開発のあり⽅をつくる
https://lp.guildhub.jp/