SlideShare a Scribd company logo
Submit Search
Upload
Login
Signup
正しいものをともに考え、正しくともにつくる
Report
toshihiro ichitani
Follow
energizer at RedJourney, devlove
Mar. 8, 2020
•
0 likes
•
17,876 views
1
of
120
正しいものをともに考え、正しくともにつくる
Mar. 8, 2020
•
0 likes
•
17,876 views
Download Now
Download to read offline
Report
Software
DevLOVE300 講演 https://devlove.doorkeeper.jp/events/102926
toshihiro ichitani
Follow
energizer at RedJourney, devlove
Recommended
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
101.9K views
•
26 slides
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
toshihiro ichitani
3.1K views
•
73 slides
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
52.4K views
•
26 slides
アジャイル開発はWhyから始まる
toshihiro ichitani
15.9K views
•
45 slides
Startup science 2018 5 Customer Problem Fit
Masa Tadokoro
129.7K views
•
245 slides
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
117.7K views
•
66 slides
More Related Content
What's hot
正しくないものをつくらない。7つの失敗パターン
toshihiro ichitani
34.6K views
•
65 slides
リーンスタートアップ本を振り返る 2018 (Lean Startup Update! 2018)
Takaaki Umada
24.9K views
•
51 slides
なぜコンピュータを学ばなければならないのか 21世紀の君主論
Tokoroten Nakayama
91.8K views
•
58 slides
正しいものを正しくつくる
toshihiro ichitani
35.3K views
•
66 slides
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
14.2K views
•
47 slides
Digitaltransformation Journey
toshihiro ichitani
6.2K views
•
88 slides
What's hot
(20)
正しくないものをつくらない。7つの失敗パターン
toshihiro ichitani
•
34.6K views
リーンスタートアップ本を振り返る 2018 (Lean Startup Update! 2018)
Takaaki Umada
•
24.9K views
なぜコンピュータを学ばなければならないのか 21世紀の君主論
Tokoroten Nakayama
•
91.8K views
正しいものを正しくつくる
toshihiro ichitani
•
35.3K views
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
•
14.2K views
Digitaltransformation Journey
toshihiro ichitani
•
6.2K views
人は一ヶ月でエンジニアになれるのか - 詳細解説
Livesense Inc.
•
394.7K views
シリコンバレーの「何が」凄いのか
Atsushi Nakada
•
183.4K views
リーンスタートアップ、アジャイル開発導入事例
Arata Fujimura
•
3.7K views
技術記事を書く&楽しむチームの作り方
Takafumi ONAKA
•
9.2K views
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
•
22.9K views
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
•
168.8K views
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
•
104.4K views
はじめてのPRD
Takuya Oikawa
•
20.7K views
LEANSTARTUPアンチパターン #devlove #leanstartup
Itsuki Kuroda
•
68K views
スタートアップの失敗を90%減らす10のポイント
Masa Tadokoro
•
39.2K views
アジャイルメトリクス実践ガイド
Hiroyuki Ito
•
22.2K views
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
•
29K views
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
•
187.9K views
見やすいプレゼン資料の作り方 - リニューアル増量版
MOCKS | Yuta Morishige
•
5.5M views
Similar to 正しいものをともに考え、正しくともにつくる
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
toshihiro ichitani
4.8K views
•
58 slides
Agile Overview In Ono
Kenji Hiranabe
1.5K views
•
57 slides
ブレークスルーキャンプ By IMJ キックオフイベント
ブレークスルーパートナーズ 赤羽雄二
2.3K views
•
75 slides
第4回「試す」applim キックオフイベント基調講演
ブレークスルーパートナーズ 赤羽雄二
1.8K views
•
58 slides
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
ブレークスルーパートナーズ 赤羽雄二
14.1K views
•
109 slides
コンピュータビジョンの今を映す-CVPR 2017 速報より- (夏のトップカンファレンス論文読み会)
cvpaper. challenge
5.3K views
•
56 slides
Similar to 正しいものをともに考え、正しくともにつくる
(20)
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
toshihiro ichitani
•
4.8K views
Agile Overview In Ono
Kenji Hiranabe
•
1.5K views
ブレークスルーキャンプ By IMJ キックオフイベント
ブレークスルーパートナーズ 赤羽雄二
•
2.3K views
第4回「試す」applim キックオフイベント基調講演
ブレークスルーパートナーズ 赤羽雄二
•
1.8K views
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
ブレークスルーパートナーズ 赤羽雄二
•
14.1K views
コンピュータビジョンの今を映す-CVPR 2017 速報より- (夏のトップカンファレンス論文読み会)
cvpaper. challenge
•
5.3K views
自分のハンドルは自分で握れ
toshihiro ichitani
•
2.8K views
11.9 bkclt
Tomokatsu Iguchi
•
378 views
A Lean UX Workshop
Masayoshi Arakawa
•
1.7K views
Social Change Starts With YOU!
Kenji Hiranabe
•
1.6K views
【デザイン思考マスター・クラス:12月23/24日】本場スタンフォード大学に学ぶ!
Takanori Kashino
•
2.1K views
時を超えた越境への道
toshihiro ichitani
•
10.7K views
リーンスタートアップをどう実践するのか
ブレークスルーパートナーズ 赤羽雄二
•
7.9K views
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
•
7.5K views
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
•
1.6K views
アジャイル基礎再考
Kanu orz
•
1.6K views
Startup Science ⑥
Masa Tadokoro
•
22.6K views
ConversionConference Feedbackその1 第1回LPO担当者交流会 101125
VOYAGE GROUP UIO strategies section
•
796 views
ソフトウェアテストの最新動向
Keizo Tatsumi
•
563 views
Let's design MVP #devlove #leanstartup
Itsuki Kuroda
•
3.3K views
More from toshihiro ichitani
アジャイル開発は世界を変える夢を見るか
toshihiro ichitani
121 views
•
84 slides
ナラティブ・プロトタイピング
toshihiro ichitani
1.6K views
•
52 slides
組織にアジャイルの構造を作る
toshihiro ichitani
400 views
•
30 slides
組織でアジャイルの ”回転” を繋ぐ
toshihiro ichitani
126 views
•
39 slides
組織アジャイルをはじめる
toshihiro ichitani
482 views
•
39 slides
デジタルトランスフォーメーション・ジャーニー・デッキ
toshihiro ichitani
355 views
•
27 slides
More from toshihiro ichitani
(20)
アジャイル開発は世界を変える夢を見るか
toshihiro ichitani
•
121 views
ナラティブ・プロトタイピング
toshihiro ichitani
•
1.6K views
組織にアジャイルの構造を作る
toshihiro ichitani
•
400 views
組織でアジャイルの ”回転” を繋ぐ
toshihiro ichitani
•
126 views
組織アジャイルをはじめる
toshihiro ichitani
•
482 views
デジタルトランスフォーメーション・ジャーニー・デッキ
toshihiro ichitani
•
355 views
Agile again
toshihiro ichitani
•
692 views
伝統的な組織で始めるアジャイル
toshihiro ichitani
•
2.9K views
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
toshihiro ichitani
•
9.3K views
私がのこすだろうたった1つの言葉
toshihiro ichitani
•
1.6K views
13年かけたら、言えること
toshihiro ichitani
•
1.4K views
チーム・ジャーニー・デッキ
toshihiro ichitani
•
859 views
ISHII SPRINT
toshihiro ichitani
•
1.1K views
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
toshihiro ichitani
•
11.3K views
正しいものを正しくつくるへ至る道
toshihiro ichitani
•
5.6K views
プロダクト開発を繋げる
toshihiro ichitani
•
4.8K views
見えないものを見ようとして僕らは何をのぞきこむか
toshihiro ichitani
•
2.3K views
分からないものを分かるようにする
toshihiro ichitani
•
1.9K views
プロダクトプレナーシップ
toshihiro ichitani
•
2.6K views
プロダクトオーナー2.0
toshihiro ichitani
•
6.7K views
正しいものをともに考え、正しくともにつくる
1.
正しいものを ともに考え 正しく ともにつくる Ichitani
Toshihiro 市⾕聡啓 The end of the journey is the beginning of a new journey
2.
第1部 正しいものを正しくつくる
3.
市⾕ 聡啓 Ichitani Toshihiro https://ichitani.com/ Profile
Twitter https://twitter.com/papanda “越境をエナジャイズするジャーニー” What Doing
4.
講演、研修、執筆 仮説検証型アジャイル開発 によるプロダクトづくり 仮説検証、アジャイル開発の 実践⽀援 (メンタリング) DX (Digital
Transformation) ⽀援
5.
https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM
6.
ともに考え、ともにつくるプロダクト開発の実践 「チーム・ジャーニー」 2020年2⽉17⽇発刊 https://amzn.to/32Wuklp
7.
われわれが挑戦していること 不確実性の⾼いプロダクト開発 …は領域を選ばない Photo on VisualHunt.com
8.
“誰かのために作る” という時点で不確実性と向き合う ことは不可避 (“誰か" is ユーザー、顧客) Photo
on VisualHunt.com
9.
“SoE だから不確実性が⾼い” “SoR だから不確実性が⾼くない” という2元論で説明する時代は終わった Photo
credit: Ravi_Shah on Visual hunt / CC BY
10.
10年あるいは20年近い、 “知る⼈ぞ知る” な基幹システム (なおそれを知る者はほぼいない) バックエンドにフタをして フロントの世界だけで新しい 価値を⽣み出そう の限界 (フロント(SoE)で”デキない制約”が強すぎる) Photo
credit: v923z on Visual hunt / CC BY
11.
⼈知れず動くSoRを巡る調査は まさに(価値)探索 ひとりでいくな危険 Photo credit: Kylie_Jaxxon
on Visual Hunt / CC BY-SA
12.
今われわれが直⾯していることは ⼈間が普段やっている⾏為を デジタルに置き換えよう ではなくて あらゆる⼿段を使って どのようにトランスフォーミング できるのかという検証そのもの Photo credit: Kevin
M. Gill on Visualhunt / CC BY
13.
Photo on VisualHunt.com 保険業務 SoE SoR 本⼈認証 ⼦供写真共有アプリ MaaS RPA従業員満⾜度 婚活 介護ロボット 決済 VR
D2C
14.
Photo on VisualHunt.com 保険業務 SoE SoR 本⼈認証 ⼦供写真共有アプリ MaaS RPA従業員満⾜度 婚活 介護ロボット 決済 VR
D2Cエクスペリエンスの再定義
15.
“タダシイ筋道も筋書き”もない中で それでも前に進むためには?
16.
対象となる状況や問題についての 仮説を⽴て、検証し、分かったこと (学習)に基づいて、プロダクトを 実装するあり⽅が求められる
17.
Photo on VisualHunt 仮説検証型 アジャイル開発
18.
仮説とは? 仮説 = 前提
+ 仮定 + 期待結果 前提:昨年はある商品の売上が10%伸びた 仮定:リーチしていない顧客はまだまだいるはずで さらに広告投資を50%増やすため 期待結果:今年の売上は20%の伸びは期待できる
19.
前提(事実)が少ないほど、 仮定の部分が多い(不確実) ゆえに仮説検証で仮定(想像)を 減らし、前提(事実)を増やす 前提 仮定 期待結果 前提 仮定 期待結果 仮説 検証
20.
前提 仮定 期待結果 データ 知⾒ 前提(事実)を作るための根拠が データ (定量/定性)
であり、 知⾒ (経験知) ゆえにデータによる理由付けが 不可⽋であり、データを補う 知⾒(既知の事実)が全体の速度 を上げる
21.
仮説検証で「事実を増やす」とは? 「情報」を増やして、「理解」を得ること (“分かった”を増やす) 前提 仮定 期待結果 データ 知⾒ 情報 解釈 理解 ☓
22.
だからといって検証や調査で情報だけ増やしても、 解釈を難しくて、誤った理解になりえる 前提 仮定 期待結果 データ 知⾒ 情報 解釈 理解 ☓
23.
前提 仮定 データ 知⾒ 情報 解釈 理解 ☓ ゆえに、正しい理解を得るためには、「解釈」を 鍛える必要がある(すなわち学習結果を積み重ねる) 期待結果 これまで 獲得した知識 検証結果 による学び
24.
検証結果 による学び 前提 仮定 データ 知⾒ 情報 解釈 ☓ 期待結果 これまで 獲得した知識 理解 仮説 合意形成 意思決定 その上で、⽴てた仮説に基づいて 意思決定のための合意形成を⾏う
25.
検証結果 による学び 前提 仮定 データ 知⾒ 情報 解釈 ☓ 期待結果 これまで 獲得した知識 理解 仮説 合意形成 意思決定 さらに⽴てた仮説に基づいて 意思決定のための合意形成を⾏う すべての箇所で誤る可能性がある ゆえに仮説の⽴て⽅、検証の⽅法、学習の蓄積 チーム内だけではなく関係者との合意形成 について学び、練度を⾼めていきたい
26.
選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 (正しいものを探す) MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 (正しくつくる) 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ (ポイントベース) 仮説検証型アジャイル開発
27.
仮説検証の「例」
28.
仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正 仮説検証1周⽬ (target :
PSfit)
29.
仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正 仮説検証1周⽬ (target :
PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正
30.
仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正 仮説検証1周⽬ (target :
PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正 仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正
31.
仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正 仮説検証1周⽬ (target :
PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正 仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正 仮説検証4周⽬ (target : PSfit (被験者に利⽤体験してもらい評価する)) MVP特定と開発 (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) 仮説の修正
32.
仮説には「構造」がある 課題仮説 機能仮説 形態仮説 本質的な課題 課題の解決⼿段 ⼿段を利⽤可能にする か かた かたち まず解くべき問いがあり、問いに答える⼿段があり、 ⼿段を扱えるようにするための形がある = = = = = =
33.
仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正 仮説検証1周⽬ (target :
PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正 仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正 仮説検証4周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) MVP特定と開発 (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) 仮説の修正 課題仮説 課題仮説 機能仮説 課題仮説 機能仮説 課題仮説 機能仮説 形態仮説 検証⽬的の度合いが異なる
34.
仮説検証5周⽬ (target :
PMfit) UXの推敲 課題仮説 機能仮説 形態仮説 ・5周⽬以降に必要となるものは4周⽬の結果に依るが、 アーリーなユーザー(課題が切実なため多少の瑕疵を⼤⽬にみれる) から、ユーザーの裾野を広げる⽅向に進む必要がある。 ・より「伝える」ことを丁寧に⾏う必要がある。それはPRだけでは なく、プロダクトの表現そのものの磨き込みである。 ・ユーザーを⾃分たちに宿し、利⽤体験を頭から何度も繰り返し テストし、つっかかりのない「つるつる」を⽬指す(UXの推敲)
35.
分からないことを分かるようにする 分かったことに基づいて、つくる 仮説検証型アジャイル開発の戦略 Photo credit: ilovepics11
on Visualhunt.com / CC BY-NC-ND
36.
問われるのは われわれは、どこまで変化に適応できるか? 早く形が⾒える、触れられる 想像⼒頼みから体が使える だから、圧倒的に学びが増える Photo credit: Ale
Art on Visualhunt / CC BY-ND
37.
学びが次の不確実性を 連れてくる。 Photo on VisualHunt
38.
変化を受け⽌められる 余⽩をつくりながら、 短いタイムボックスの中での 確実性は⾼める。 余⽩が無ければ変化を受け⼊れられない。 いかにして無いところに余⽩を作り出すか? ⻑い距離で確実なことは⾔えない。 でも、短い距離でなら?成果の確度を⾼められる。 Photo credit: Arenamontanus
on Visualhunt.com / CC BY
39.
余⽩の戦略 全体への 共通理解を統べる作戦 スプリント強度を⾼める戦術 プロジェクトレベル 複数スプリントレベル スプリントレベル ・調整の余⽩ ・期間の余⽩ ・受け⼊れの余⽩ ・背⾻駆動開発 ・状況をクリーンに保つ5つの条件 1. 受け⼊れ条件を定義している 2. ベロシティを計測し安定させている 3.
受け⼊れテストを実施している 4. 振り返りを実施しカイゼン継続 5. 実運⽤相当のデータが揃っている
40.
余⽩の戦略 ・調整の余⽩ ユーザー⾏動フローのうち「広さをコミット深さで調整」 全体の必要最⼩限の実現を⾒⽴てつつ、実際の折々では 状況を踏まえて実現内容を調整する。 ・期間の余⽩ バッファの確保。個⼈・局所のバッファではなく、 プロジェクトやテーマ単位でバッファを設ける。 ・受け⼊れの余⽩ ICEBOXの運⽤。学びを蓄積(凍結)し、状況を⾒て棚卸 (解凍)し、PBLとの順序付けを⾏う。
41.
スプリント強度を⾼める戦術 ・背⾻駆動開発 PBLを背⾻(利⽤体験上必要不可⽋、前提となる基本機能) とお⾁に分けて、背⾻の開発を先⾏し、開発の前提を作る
42.
スプリント強度を⾼める戦術 ・状況をクリーンに保つ5つの条件 1. 受け⼊れ条件を定義している 条件を定義しようとしてみることが⼤事。実際にはできない 場合もある。どこまではっきりしていて、どこからは作って⾒て なのかの理解をチーム、関係者で揃える 2. ベロシティを計測し安定させている 低すぎず、過熱しすぎず。ボトルネック事案の早期検出をチーム で⾏えるようになるために、ベロシティに関⼼を持つ。 3.
受け⼊れテストを実施している 条件と呼応するもの(場合によって条件そのもの)。スプリント毎 の確実な実施が安定度を格段に⾼めることになる。 4. 振り返りを実施しカイゼン継続 5. 実運⽤相当のデータが揃っている
43.
全体への共通理解を統べる作戦 ・⾃分たちの活動に”作戦名”をつける 活動 = まとまった機能群の開発、カイゼン… 距離感としては プロジェクト
> 複数スプリント > スプリント 象徴的な名前付けで⽅針を分かりやすくする (“背⾻バックログを倒し切る作戦”) 「この期間」のミッションが明確になり、何をやれば 良いかが⾃明になり、優先基準もわかりやすくなる。 チームの⾃律的な動きへと繋がる。
44.
全体への共通理解を統べる作戦 ・⾃分たちの活動に”作戦名”をつける 活動 = まとまった機能群の開発、カイゼン… 距離感としては プロジェクト
> 複数スプリント > スプリント 象徴的な名前付けで⽅針を分かりやすくする (“背⾻バックログを倒し切る作戦”) 「この期間」のミッションが明確になり、何をやれば 良いかが⾃明になり、優先基準もわかりやすくなる。 チームの⾃律的な動きへと繋がる。 このタイムボックスのことを “ジャーニー” と呼ぶ
45.
ゼロからのプロダクトづくりではなく 既にあるプロダクトでの仮説検証に どんな特徴があるか?
46.
デュアルトラック・アジャイル 検証BBB スプリント11 スプリント13 検証CCC スプリント 開発スプリントと仮説検証の活動が並⾏して進む 開発→検証→学習結果を開発へとサイクルさせる 並⾏する2つの活動間での同期ポイント設定が必要。 同期の距離が空きすぎると、プロダクトに「学習不全の 負債」がたまる スプリント12スプリント10 (プロダクト) (プロダクト)
(学習結果)
47.
仮説検証リードを置く 仮説⽴案のリードや、検証の計画づくり、検証⼿段や 環境の準備などを中⼼となって進める役割。 仮説検証実施の経験が問われる。適切な練度を備えた メンターを組織内外から招聘する。 チームで学ぶ機会を段階的につくる まずは仮説検証とは何かという理解からはじめて、 イベントベースの検証を⾏う(いきなり定常的に、組織 的に⾏うのはハードルが⾼い) 例えば、“ユーザーテスト” や ”プロダクトレビュー”
を イベントとして実施する。
48.
“タダシイ筋道も筋書き”もない中で それでも前に進むためには?
49.
Toshihiro Ichitani All
Rights Reserved. Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC ⾃らに問い続ける
50.
問い続けることで⾃分たちに傾向を与える プロダクトづくりにおいて最も誤りをおかす箇所とは ⾃分たち⾃⾝の意思決定や⾏動。 Photo credit: Shandi-lee
on Visualhunt.com / CC BY-NC-ND
52.
第1部 完
53.
https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM https://amzn.to/32Wuklp https://ichitani.com/
https://enagile.jp/
54.
第2部 ともに考え、ともにつくる
55.
不確実性との戦い 必要なのは「誰にも分からない」という 状況下で前に進んでいくあり⽅ Photo credit: Kylie_Jaxxon
on Visualhunt / CC BY-SA
56.
不確実性とは 回避するべきもの なのか?
57.
混沌を引き寄せるものであり、 プロダクトの未来を変える可能性でもある 不確実性とは、 明⽇の予定調和が常に明るい未来なわけではない 未来を変えるためにはシナリオ(台本)を変えられる 必要がある Photo credit: occhiovivo
on Visual Hunt / CC BY-NC-ND
58.
つまり、不確実性を⾃ら招き寄せる 分からないことを増やす Photo on VisualHunt.com
59.
不確実性を招き寄せるために 多様性を⾼める Photo on VisualHunt
60.
検証結果 による学び 前提 仮定 データ 知⾒ 情報 解釈 ☓ 期待結果 これまで 獲得した知識 理解 仮説 合意形成 意思決定 多様性 多様性が解釈に幅をもたらす
61.
重奏型仮説検証
62.
重奏的仮説検証 仮説の外在化 第1段階 プロダクトオーナー1⼈の 解釈を⼀⽅的に伝える 仮説キャンバスで仮説を外在化 (誰でも表明が出来る) (解釈を頭から取り出す) 仮説検証
63.
われわれはなぜこの事業をやるのか? ⽬的 ビジョン 実現⼿段 優位性 評価指標 提案価値
顕在課題 潜在課題 代替⼿段 チャネル 状況 収益モデル 市場規模 中⻑期的に顧客にどういう状況に なってもらいたいか? 提案価値を 実現するの に必要な⼿ 段とは何か? 提案価値や実現 ⼿段の提供に貢 献するリソース (資産)が何かあ るか? どうなればこ の事業が進捗 していると判 断できるのか? (指標と基準値) われわれは 顧客をどん な解決状態 にするのか? (何ができる ようになる のか) 顧客が気づいて いる課題に何が あるか? 多くの顧客が気 づけていない課 題、解決を諦め ている課題に何 があるか? 課題を解決するた めに顧客が現状取っ ている⼿段に何が あるか?(さらに 現状⼿段への不満 はあるか) 状況にあげたひ とたちに出会う ための⼿段は何 か? どのような状 況にある顧客 が対象なのか (課題が最も発 ⽣する状況と は?) どうやって儲けるのか? 対象となる市場の規模感は? 傾向 同じ状況にある ⼈が⼀致して⾏ うことはあるか? 仮説キャンバス (1.0)
64.
Toshihiro Ichitani All
Rights Reserved. Photo credit: somenice on VisualHunt / CC BY-NC プロダクトオーナーの視座を プロダクトの上限(ボトルネック)にしない
65.
Photo credit: Wendelin
Jacober on Visual Hunt / CC BY "プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野から チームの視座、視野へ
66.
重奏的仮説検証 仮説検証の重奏化 第2段階 それぞれの中に仮説を持ち、 共通の理解に対して掛け合わせる ・多様なメンバー=多様な解釈への期待 ・検証を通じての仮説⽴案が前提 ・仮説検証の実施リードや解釈の メンター役は必要(仮説検証リード) 仮説検証
67.
重奏的仮説検証 チーム or PO
を仮説検証にどうやって巻き込むか 最初は誰もが半信半疑。実践していく 中で、意義を⾒出して⾏く。 仮説検証についてのゴールデンサークル を確認した後、段階的な取り込みを設計 する。 第1ジャーニー:事前学習 第2ジャーニー:イベントベースの検証 第3ジャーニー:継続的な検証活動
68.
Photo credit: Wendelin
Jacober on Visual Hunt / CC BY 意味あるものを作り出したい という意思に POや開発者という分け隔ては無い
69.
相⼿のナラティブを知ろうとする Photo credit: zxjbfcindy2019
on Visual Hunt / CC BY-NC-SA
70.
どれだけ多様な⾒⽅が 出せたとしても チームが進む為には ⼀つのことに合意 しなければならない?
71.
合意形成とは 唯⼀の解釈のみ残し その他の全て⼀切を捨て去る ことを強要するものではない
72.
検証結果 による学び 前提 仮定 データ 知⾒ 情報 解釈 ☓ 期待結果 これまで 獲得した知識 理解 仮説 合意形成 意思決定 多様性 ばらばらのままの 合意形成チームの 合意形成 個々の仮説
73.
検証結果 による学び 前提 仮定 データ 知⾒ 情報 解釈 ☓ 期待結果 これまで 獲得した知識 理解 仮説 合意形成 意思決定 多様性 チームの 共通合意 個々の仮説 ばらばらのままの 合意形成 (それぞれが仮説を持つ) 仮説を⽴てるのにハードルがあるならば まずはワンライナーから始める https://ichitani.com/2019/oneliner-canvas/
74.
多様性 ☓ 機動性 プロダクトづくりに多様性を取り込む、では次に⽬指すことは? 多様性によって広がる選択に最⼤限適応していく
75.
Photo credit: U.S.
Pacific Fleet on VisualHunt.com / CC BY-NC チームの機動性を上げるとは? インプット(変化)に対して即応性をあげる ただし、全体性を⾒失わずに。 誰かが与えた全体性のもとに、端っこから 作っていくのではなく、⾃分たち⾃⾝で舵を取る
76.
「段階」 の概念を取り⼊れる (全体と微細の両⽴)
77.
「段階の設計」とは ⾃分たちが到達したい地点(⽬的地)を⾒⽴て、そこに たどり着くために必要となる状態を構想すること。 現実を進めた結果から分かったことに基づき、構想⾃体を 変化させる (現実を構想に合わせることが⽬的ではない)。 ⽬的地⾃体も通過点に過ぎない。変えていく。 段階の⻘写真は、当事者に⽅向性を与える。 不確実性の⾼い状況では、チーム、ステークホルダーと ともに「理解」と「意思決定」を共通にして歩み進むこと が唯⼀の頼り。
78.
※チームの活動単位であるスプリントの⻑さは チームのリズムを作るために固定 ※多様なミッションを捉えるため ジャーニーの⻑さ(スプリントの数)は可変 段階(ジャーニー)を経てアウトプット されるのは、チームとプロダクトの2つ
79.
Photo credit: mikecohen1872
on Visualhunt.com / CC BY チームもプロダクトも最初から 完成型(理想)が⾒えるわけではない
80.
ジャーニー = 段階的発展
= 進化 当事者として 「意思のある進化」を仕組み、 その上で変化に適応していくこと
81.
どのようにして ジャーニーを運⽤ するのか?
82.
リーン・ジャーニー・スタイル
83.
リーン・ジャーニー・スタイル セットベースで選択肢を広げ、ポイントベースで アウトプットを結実させる 選択肢を広げるために多様性を利⽤する 段階の設計によって、経験による学びを踏まえた 当事者の意思決定を着実に形にしていく 変化への適応性を確保するために、ミッション、 フォーメーション、チームの主義を動的に選択する
84.
⽬的地を⾒定める ジャーニー(段階)を 設計する ジャーニーの ミッション定義 チームの フォーメーションを変更 ジャーニーバックログ プランニング チームの ファースト選択 ジャーニーの 遂⾏ ジャーニーのふりかえり とむきなおり (ジャーニーごとの回転)
85.
少しずつ繰り返しながら 形づくる (agile)
86.
繰り返し = イテレーティブ
87.
少しずつ = インクリメンタル (チームもプロダクトも)
88.
段階的に = ジャーニー 最初の旅(仮説検証) 次の旅(プロトタイプ) さらに次の旅(MVP)
90.
少しずつ = インクリメンタル 繰り返し
= イテレーティブ 段階的に = ジャーニー 形作る
91.
リーン・ジャーニー・スタイル 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説検証 プロセス チーム アーキ
92.
※第1ジャーニーで検証結果が期待するものでは 無かったら当然、全体のジャーニーを⾒直す プロダクト・ジャーニー
93.
選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 (正しいものを探す) MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 (正しくつくる) 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ (ポイントベース) 仮説検証型アジャイル開発 不確実性が⾼いプロダクトづくりでのパターン 仮説検証ジャーニー MVP開発ジャーニー MVP検証 ジャーニー
94.
「傾き」の問題 Photo on VisualHunt.com
95.
理想的な変化量と現実の乖離イメージ
96.
「これまで」が引き寄せる 重⼒を突破できない Photo credit: Miles
Cave on Visualhunt / CC BY-NC-ND
97.
厳然と存在する「変化格差」
98.
「段階」によって「なめらか」にする
99.
チーム・ジャーニー ※チームの成⻑戦略を描く。⾃分たちの出発点を⾒定め、ひとたび⽬指す ⽬的地までの「傾き」が急勾配にならないよう設計する。実際のところ 歩みはじめてみて、傾きを調整する。⽬的地⾃体を捉え直す。
100.
「過去」をふりかえり、現在を捉え直す 「未来」にむきなおり、現在を捉え直す ジャーニーにむきなおりは前提
101.
プロダクトやチームを 越えた、⼤きな段階を 迎えている
102.
Digital Transformation
103.
DXは、現場と経営の変⾰意思が 噛み合う惑星直列的なチャンス 現場でいくらアジャイルを⾔っても通じなかった時代 “トップダウンによる変⾰”が空を切り続けた時代 を経て、われわれは共通の危機感の下に辿り着いた Photo credit: NASA
Goddard Photo and Video on Visual hunt / CC BY
104.
チーム・ジャーニー 現状の全てを⼀気呵成に Transformationするのは チームも練度も⾜りない。 現状の⽂脈から分断した環境を作る (たいていの場合SoEが成熟していないからできる) SoE開発を通じてチーム作りに注⼒ 然る後に本丸(SoR)に切り込む (「逆2項対⽴」作戦)
105.
※DXのミッションとして技術・プロセスのモダン化、新たなビジネス モデル構築全てに⼀気呵成に取り組むのではなく、局所的なSoE 構築を先⾏させて学びの⼟台作りを⾏う。 DX・ジャーニー (狙いは、ジャーニーを通じたチーム、組織の成⻑)
106.
ジャーニーは重なり合う
107.
このあり⽅の先に あるものとは? 「われわれはどこに向かうのか」
108.
ともに考え、ともにつくる 固定的な役割を中⼼とした「調整」から 仮説検証による学びを中⼼とした「ともに」へ Photo on VisualHunt.com
109.
ともに考え、ともにつくり 続けるためには?
110.
お互いの関係性に意味を⾒つける 「われわれはなぜここにいるのか?」 Photo on VisualHunt.com
111.
⾃分⾃⾝のミッションと 役割を問い直し続ける 必要がある “⾃分のナラティブを脇に置く” 『他者と働く』 Photo on VisualHunt.com
112.
私⾃⾝のジャーニー ゆえに。さいごに、
113.
地⽅アトツギ国・⾃治体 ⼤いなる組織 (⼤企業)
114.
Photo via Mars
Williams via Visual hunt これまで⽇本の社会インフラを つくってきたプレイヤーこそ 逆境にある
116.
Toshihiro Ichitani All
Rights Reserved. Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC 逆境からの越境
117.
つまり、不確実性を⾃ら招き寄せる 分からないことを増やす Photo on VisualHunt.com
118.
Toshihiro Ichitani All
Rights Reserved. 20代、30代ではなく 今の⾃分だからできること、 やるべきことがある
119.
このジャーニーは、 ⾃分⾃⾝の再定義の旅 Redesign Journey
120.
新たな境界でまた。会えることを。 Photo credit: digitalpimp.
on Visualhunt.com / CC BY-ND