情シスが始める価値創出

16.8K Views

April 10, 23

スライド概要

なぜ情シスから価値創出を始めるのか?をお話しました

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

“情シス” が始める価値創出 Ichitani Toshihiro 市⾕聡啓 Toshihiro Ichitani All Rights Reserved.

2.

市⾕ 聡啓 Ichitani Toshihiro 「正しいものを正しくつくる」⽀援、 「組織を芯からアジャイルにする」⽀援 (株式会社レッドジャーニー) 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 https://ichitani.com/ Toshihiro Ichitani All Rights Reserved. 2

3.

https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf Toshihiro Ichitani All Rights Reserved. 3

4.

DX = “シン・価値創出シフト” デジタイ・デジタライは⼀定の到達点 “新たな価値創出” はこれから︕ https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf Toshihiro Ichitani All Rights Reserved. 4

5.

デジタルトランスフォーメーション・ジャーニー (DXの4つの段階設計) ④組織の トランスフォーメーション ③ビジネスの トランスフォーメーション ②スキルの トランスフォーメーション ①業務のデジタル化 (特にコミュニケーション) 変化を広げる DXを特別にしない、組織内に例外なく広げる 価値を創る 既存事業の質的向上や新規事業の創出 武器を得る 新たな価値創りに向かうためのすべを⼈材に備える ⾜場を作る ⼿元⾜元の効率化によって変⾰の⼟台を作る Toshihiro Ichitani All Rights Reserved. 5

6.

“探索適応” のケイパビリティを獲得せよ これまで踏み込んでいなかった領域、実現できなかった領域に向き合うには、 そのための組織能⼒、組織機能が必要 = “探索適応” 反復的な仮説検証 探索 さがす 状況をよくみる 仮説を⽴てる 試⾏や検証する 定期的な再探索 適応 かえる 結果から学びを得る 次に向けた判断と ⾏動を変える Toshihiro Ichitani All Rights Reserved. 最適化 みがく 勝ち筋を固める (効率性を⾼める) 6

7.

“アジャイル” Photo on VisualHunt

8.

“アジャイル” の組織的取り込み アジャイルの原則とアプローチを組織のガバナンスに取⼊れているか︖ https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf Toshihiro Ichitani All Rights Reserved. 8

9.

“適応” の差が 価値提供における 顕著な差を⽣み出す https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf Toshihiro Ichitani All Rights Reserved. 9

10.

現代組織に共通する組織課題 Toshihiro Ichitani All Rights Reserved. 10

11.

すべての組織レベルで ”探索適応” が必要 経営・戦略 マネジメント 現場 Toshihiro Ichitani All Rights Reserved. 11

12.

…ということで “アジャイル” を組織に取り⼊よう︕ Toshihiro Ichitani All Rights Reserved. 12

13.

…ということで “アジャイル” を組織に取り⼊よう︕ 的外れのアジャイル問題 Toshihiro Ichitani All Rights Reserved. 13

14.

⽇常業務︖ プロダクト 開発︖ ︖︖︖ 組織の運営︖ マインドセット︖ “アジャイル” (整合元) (整合先) その “アジャイル” はどこに向けて 何を狙ったものなのか︖ Toshihiro Ichitani All Rights Reserved. 14

15.

アジャイルを、プロセス(⼿順) としてのみ捉えている限りは 的を外し続ける Toshihiro Ichitani All Rights Reserved. Photo credit: ChrisL_AK on VisualHunt.com 15

16.

抽象 “アジャイル開発” 背景、制約条件が 違いすぎる 具体 “アジャイル開発” の実践 “アジャイル” の業務適⽤ “アジャイル開発” の実践経験をそのまま 展開する (⼿順の移転) = 適⽤できない Toshihiro Ichitani All Rights Reserved. 16

17.

抽象 “アジャイル開発” 具体 “アジャイル開発” の実践 背景、制約条件が 違いすぎる (何の勘所もない) “アジャイル” の業務適⽤ もちろん未経験のまま、”アジャイル開発”を いきなりそのまま当てはめるのは、尚悪⼿ Toshihiro Ichitani All Rights Reserved. 17

18.

抽象 適応の あり⽅とやりよう “アジャイル開発” 探索適応の勘所がなく ⼿順の劣化コピーの危険 具体 “アジャイル開発” の実践 “アジャイル” の業務適⽤ 実践経験なく、開発に依らない概念を 作ろうとしても合っているかどうか分からない Toshihiro Ichitani All Rights Reserved. 18

19.

抽象 適応の あり⽅とやりよう “アジャイル開発” 経験からの 抽象化 具体 “アジャイル開発” の実践 “アジャイル” の業務適⽤ “アジャイル” を⼿順として適⽤するのではない “アジャイル” から概念を取り出すのだ Toshihiro Ichitani All Rights Reserved. 19

20.

抽象 具体 PDCA ソフトウェア開発 でのPDCA ⼈事施策での PDCA どんな仕事にも適⽤できる ”⼿順” は無い (PDCAも結局個別に具体化している) Toshihiro Ichitani All Rights Reserved. 20

21.

抽象 探索適応の あり⽅とやりよう ⼿がかりとなる 抽象的概念 経験からの 抽象化 具体 探索適応の 業務適⽤ 具体的経験 まとめると、探索適応ケイパビリティを獲得 するために具体経験、そのための⼿がかりを得る Toshihiro Ichitani All Rights Reserved. 21

22.

抽象 “仮説検証型 探索適応の あり⽅とやりよう アジャイル開発” 経験からの 抽象化 具体 “仮説検証型 アジャイル開発” の実践 探索適応の 業務適⽤ 最初の⼿がかりに、探索と適応を両輪とする 「仮説検証型アジャイル開発」を置く Toshihiro Ichitani All Rights Reserved. 22

23.

探索と適応を重ね合わせる 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 MVP検証 スプリント レビュー 次の価値探索へ アジャイル 構想を早く形にして フィードバックを得る Toshihiro Ichitani All Rights Reserved. 23

24.

“探索適応” のケイパビリティを獲得せよ これまで踏み込んでいなかった領域、実現できなかった領域に向き合うには、 そのための組織能⼒、組織機能が必要 = “探索適応” 反復的な仮説検証 探索 さがす 状況をよくみる 仮説を⽴てる 試⾏や検証する 定期的な再探索 適応 かえる 結果から学びを得る 次に向けた判断と ⾏動を変える Toshihiro Ichitani All Rights Reserved. 最適化 みがく 勝ち筋を固める (効率性を⾼める) 24

25.

これまでにない視座、視野を得る どこから(視座)、どの範囲(視野)を⾒るか 組織 によって、獲得できる知⾒は異なる ⾃分が今まで居た場所から、 事業 視座を変える、視野を変える = 「越境」 プロダクト プロジェクト ⾃分 チーム 部⾨ Toshihiro Ichitani All Rights Reserved. 顧客 社会 25

26.

“越境” = シンの探索適応の「前提」 これまで踏み込んでいなかった領域、実現できなかった領域に向き合うには、 これまでの前提や役割、領域を越えることが不可⽋ 越境 こえる これまでの前提 や役割、領域を 意図的に越える Toshihiro Ichitani All Rights Reserved. 26

27.

「探索適応」がより機能するためには、3つの留意点がある ①ルーチンワーク or 未知の探検 ②あえての「制約」を置く ③実経験に基づく「⽅針」の選択 Toshihiro Ichitani All Rights Reserved. 27

28.

①ルーチンワーク or 未知の探検 ルーチンワーク 未知の探検 ・⽬標、⼿順が明確に定義 されている (WHY-HOW-WHAT固定) ・あらかじめゴールまでの 明確な計画を⽴てるのが 困難 (場合によってゴールも変える) ・定義通りに実施できること が重要 ・探索から何を学びとして 得られたかが重要 ・期待されるのは正確性、 ・期待されるのは仮説の発⾒、 効率性 検証による学習 Toshihiro Ichitani All Rights Reserved. 28

29.

「未知の探検」とは︖ 「ルーチンワーク」そのもので探索を取り⼊れるというのは考えにくい。 ⽇常の業務・運⽤の多くはルーチン化しているため、いきなり探索適応の 仕組みを適⽤しようとしても機能しにくい ゆえに、まず「これまで踏み込んでいなかった領域」「実現できなかった領域」 に⽬を向けることから始めたい。実はそんな領域は⼭ほどある。 より不確実 新規事業・プロダクト開発 もっとも探索適応をイメージしやすい領域 仮説検証型アジャイル開発そのまま適⽤ 既存事業の質的向上 既存の提案価値をデジタル、データ利活⽤等に よって向上させる取り組み ルーチンの改善・ツール導⼊ ルーチンワークそのものではなく、その改善は 探索的となって然るべき ⼈材育成のための施策 ⼈材育成に関する施策もわかりやすい正解が あるわけではない。検証が必要。 Toshihiro Ichitani All Rights Reserved. 29

30.

②あえての「制約」を置く 「探索適応なのだから、とにかくやってみよう」というのは スタンスとしては必要だが、何の与件も置かずにただ突き進めて いくことが望ましいわけではない ⾃由度 不可動領域 =前提条件 探索の⾃由度 (どこで、どのくらい探索できるか) 制約弱 / 無 ⾃由度が⾼い分、 選択の幅が広く、 難易度は⾼まる 制約強 (コスト / 期間 / リソース等) ゆえに「制約」を意図的に置くことで取り組みの難易度を かえって下げられる可能性がある(勿論最初から強め過ぎると探索に ならない。”無理ゲー”化する可能性もある) Toshihiro Ichitani All Rights Reserved. 30

31.

制約のチューニングを意図的に⾏う 探索適応への振り切り 既存のメンタリティでは 探索ができない。 最初は振り切りが必要 現実解の絞り込み 探索の進みに応じて 制約条件を調整していく (選択肢を絞る=与件を置く) Toshihiro Ichitani All Rights Reserved. 31

32.

③実経験に基づく「⽅針」の選択 探索適応の経験と適⽤領域の知⾒有り無しに応じて 「⽅針」を変える。 探索適応の 経験あり 探検度合いが強いため 制約チューニング = ⼩さく始める 探索適応の 作戦無しは無謀 経験なし = 他領域を選択する 意図的に “越境” の 度合いを⾼める = 反復による探索適応 “⼿順の適⽤” からになる = 学習前提で取り組む (失敗上等) 適⽤領域での 適⽤領域での 知⾒なし 知⾒あり Toshihiro Ichitani All Rights Reserved. 32

33.

探索適応の実経験を他領域に適⽤可能にするための 「経験からの抽象化」とは︖ Toshihiro Ichitani All Rights Reserved. 33

34.

“動きかた” を決める「軸」を⾒出す 価値 原則 あり⽅、やり⽅を決めるもの 判断の基準となるもの “動きかた” (プロセス) プロセスを「⼿順」として 決めると固定的になる プロセスを決める「軸」を 捉えることで動的にできる 信頼すべき活動の指針 価値とプラクティス(価値を 実現する⽅法)を繋ぐ プラクティス Toshihiro Ichitani All Rights Reserved. 実践のための 知⾒、習慣、パターン 34

35.

具体的経験から「軸」を取り出し 「実践」から再び具体的経験を得る 「探索適応」に適した「価値」、必要な「原則」、 実践を具体的に⽀える「プラクティス」を得る 具体的経験 探索適応の「実践」から具体的経験を得る Toshihiro Ichitani All Rights Reserved. 35

36.

抽象 “仮説検証型 探索適応の あり⽅とやりよう アジャイル開発” 経験からの 抽象化 具体 “仮説検証型 アジャイル開発” の実践 探索適応の 業務適⽤ 最初の⼿がかりに、探索と適応を両輪とする 「仮説検証型アジャイル開発」を置き その具体的経験から組織に探索適応を広げる Toshihiro Ichitani All Rights Reserved. 36

37.

正しいものを 正しくつくる 組織を芯から アジャイルにする だから、”プロダクト作り” から始める Toshihiro Ichitani All Rights Reserved. 37

38.

“プロダクト作り” を選択する理由 “アジャイル” との 親和性が⾼い “新たな取り組み” の⽂脈を作りやすい 具体的なアウトプット を伴うため、狙いを 合わせやすい 探索適応的な開発のために アジャイルという概念が作り 育てられてきている 既存のしがらみを減らすには、 “新たな取り組み” として始めたい ”DX” という機運も利⽤する アウトプットが具体的にある ことで何を狙い、どういう状態 にあるのか認識をあわせられる プロダクト作りその もののナレッジが、 流布している チームで取り組む 仕事になる 制約のチューニング を⾃分たちで⾏える プロダクト作り、プロダクト マネジメントのナレッジが広く 流布しているため取得しやすい 探索適応の複雑性を「チーム」 という活動単位で補い、乗り越 えることになる “⾃分たちのプロダクト” という 状況が制約チューニング⾃体に ⾃由度を与える Toshihiro Ichitani All Rights Reserved. 38

39.

プロダクト・事業開発のための型として 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 MVP検証 スプリント レビュー 次の価値探索へ アジャイル 構想を早く形にして フィードバックを得る Toshihiro Ichitani All Rights Reserved. 39

40.

誰がやるのか︖ Toshihiro Ichitani All Rightscredit: Reserved. Photo James Marvin Phelps via Visualhunt.com / CC BY-NC

41.

“DX” を被せるとすると︖ デジタル・トランスフォーメーション推進⼈材の 機能と役割のあり⽅に関する調査(IPA) https://www.ipa.go.jp/jinzai/chousa/qv6pgp000000buyg-att/000073700.pdf Toshihiro Ichitani All Rights Reserved. 41

42.

“DX” を被せるとすると︖ デジタル・トランスフォーメーション推進⼈材の 機能と役割のあり⽅に関する調査(IPA) https://www.ipa.go.jp/jinzai/chousa/qv6pgp000000buyg-att/000073700.pdf 42 Toshihiro Ichitani All Rights Reserved.

43.

“情シス” or “新設部署” “情シス” で探索適応 ・”ソフトウェア” 作りとの距離感 が近い⼈材がいる “新設部署” で探索適応 ・新たに⼈材確保から始める必要 がある(難易度は極めて⾼い) ・その分既存業務との距離も近く ・既存業務のしがらみが無い 意図的に距離を取る⽅針が必要 ・これまでの業務を通じて、社内 事情、制約に詳しい ・新設ゆえに社内事業部⾨との 関係性構築から必要になる “作る”への距離は近いが 制約も強い 理想は描けるが 実現上の障壁あり Toshihiro Ichitani All Rights Reserved. 43

44.

「From - To」の2軸で望む変化を捉えること From 現状 Gap = “必要な変化量” “From” が分かっているからこそ “To” に向かうためのGapが測れる To ありたい Gapが分かるからこそ作戦が⽴つ ︖︖︖ To ありたい “To” だけ描いて、外から「やり⽅」 だけ輸⼊してもハレーションは強い Toshihiro Ichitani All Rights Reserved. 44

45.

“情シス” or “新設部署” “情シス” で探索適応 ・”ソフトウェア” 作りとの距離感 が近い⼈材がいる “新設部署” で探索適応 ・新たに⼈材確保から始める必要 がある(難易度は極めて⾼い) “既存のしがらみ” = 変化を阻む重⼒であり、 同時に変化に向けた出発点を決めるもの 意図的に距離を取る⽅針が必要 ・その分既存業務との距離も近く ・既存業務のしがらみが無い ただし、しがらみ (From) は ・これまでの業務を通じて、社内 ・新設ゆえに社内事業部⾨との 事情、制約に詳しい 関係性構築から必要になる 「理解の対象」であって「不変の前提」ではない 作るへの距離は近いが 制約も強い 理想は描けるが 実現上の障壁あり Toshihiro Ichitani All Rights Reserved. 45

46.

“情シス” によるプロダクト作りは “情シス” で探索適応 ・”ソフトウェア” 作りとの距離感 が近い⼈材がいる ・その分既存業務との距離も近く 意図的に距離を取る⽅針が必要 ・これまでの業務を通じて、社内 事情、制約に詳しい “作る”への距離は近いが 制約も強い 最⼤2回 間違える ① “探索適応” のはずが ”計画駆動” 綿密な計画⽴案を始めてしまう ② “プロダクト作り” のはずが ”ソフトウェア開発” 要件通りの開発を始めてしまう Toshihiro Ichitani All Rights Reserved. 46

47.

「ソフトウェア開発」と「プロダクト開発」は違う “ 業務システムの受託開発では、要件定義で必要な ものを決めてから作る。業務上必要なものを⾒定め て、ソフトウェア作りを進めていくため考慮すべき前 提や制約も多い。開発は「作る側」が担うところが⼤ きく、「ソフトウェア」という⾔葉は「作る側」の⾔ 葉として育まれてきたところがある。 ⼀⽅、プロダクト開発は⽬的に⽴ち返ると「利⽤価 値があるかどうか」を念頭に置く必要がある。ゆえ に、「プロダクト」という⾔葉は、「作る側」と「使 う側」の両者の共有の⾔葉としてそもそも成り⽴って いる。 https://note.com/papanda0806/n/n307d70cdf415 以上を踏まえると、「経験深いソフトウェア開発者 を集めたのに、プロダクト開発がうまくいかない(期 待されたリリースまで辿り着かない)」という問題が 起きるのも合点が⾏く。「プロダクト作り」でありな がら、「ソフトウェア作り」に固執するとコミットメ ントの対象が噛み合っておらず、ちぐはぐになる。” Toshihiro Ichitani All Rights Reserved. 47

48.

「ソフトウェア開発」と「プロダクト開発」は違う ソフトウェア開発 プロダクト作り ・狙いは期待 (仕様) 通りに 動くこと ・狙いは利⽤者の⽬的を果たし 価値をもたらすこと ・期待がはっきりしてるから ・そもそも何と整合取れば 要件も仕様もあらかじめ どんな価値があるか 決められる はっきりとはしていない ・前提として必要なのは、 要件定義であり仕様決定 ・前提として必要なのは、 価値とは何か︖の仮説検証 ・「作る」→「使える」 ・「使う(試す)」→「作る」 ・担い⼿は、 ソフトウェア開発チーム ・担い⼿は、 プロダクトチーム Toshihiro Ichitani All Rights Reserved. 48

49.

「⼿持ちの武器による誤謬」が起きやすい プロダクト作り ソフトウェア開発 要件定義 満たすべき要件仕様を 明らかにするために ⼿持ちの武器 による誤謬 ⽬的から捉えると⽅法が適切ではないという ことが⾒えるが、”近そうな⼿持ちの武器” で 間に合わせてしまう誤謬 Toshihiro Ichitani All Rights Reserved. 仮説検証 実現するべき価値とは何か を確かめるために 要件定義︖ 価値仮説を確かめるために︖ 49

50.

「仮説検証型アジャイル開発」を前提にする “従来の開発にアジャイルを取り⼊れる” ではない 従来の計画駆動型 ソフトウェア開発 + ・スプリント ・プロダクトバックログ ・スクラムイベント ・PO、SM .... (スクラムノガイネン) = アジャイル⾵ ソフトウェア開発 ⼿持ちの武器による誤謬 が起きやすい “仮説検証型アジャイル開発” (を前提) にやることを合わせる 最初に試すべき 不確実性の⾼い 領域、テーマ MVP (実⽤的で最⼩限の製品) Toshihiro Ichitani All Rights Reserved. 50

51.

プロダクト・事業開発のための型として 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 MVP検証 スプリント レビュー 次の価値探索へ アジャイル 構想を早く形にして フィードバックを得る Toshihiro Ichitani All Rights Reserved. 51 51

52.

“選択肢” を広げて、絞り込む あらかじめ正解が⾒えているわけではない領域、テーマにおいては、 「正解 (価値がある、意味がある)」になりうる選択肢を出来る限り挙げた上で 検証によって絞り込み(ハズレを除外)を⾏うアプローチを取る (= 探索適応) 解くべき問題設定 の段階 問題を解決する⼿段特定 の段階 課題やニーズの幅 実現⼿段の幅 実現の段階 最初に作るべき製品 選択肢に幅があるからこそ正解の可能性がありえる この選択肢を仮説と呼び、検証によって絞り込みを⾏う Toshihiro Ichitani All Rights Reserved. 52

53.

2つの時間帯(探索とフォーカス)を使い分ける プロダクト作りは「探索する時間帯」と、ひとたび焦点(フォーカス)を定めて 「⼀点集中する時間帯」の2つの使い分けが必要になる 完全なる探索の時間帯 ⼀点集中する時間帯 ✗ MVP ✗ ✗ 特定 探索の結果から、次に何をするべきか、あるいはどんな 状態になりたいかの仮説を⽴てる。この仮説がひとまず 辿り着きたい⽬標となる。この⽬標に向かって必要な どこに向かってどこまで辿り着けば次に何が分かるのか。 ヒト、モノ、コト、カネなどを整えて、臨む。 ほとんど⾒当もついていなくて、とにかくまずはやって みようという段階。この状況下では探検さながら、 けもの道を分け⼊るつもりで⾏くよりほかない。 Toshihiro Ichitani All Rights Reserved. 53 53

54.

2つの時間帯(探索とフォーカス)を使い分ける プロダクト作りは「探索する時間帯」と、ひとたび焦点(フォーカス)を定めて 「⼀点集中する時間帯」の2つの使い分けが必要になる 完全なる探索の時間帯 ⼀点集中する時間帯 ✗ MVP ✗ ✗ 特定 まず、MVPの特定を⽬指すことを⽬標にする 探索の結果から、次に何をするべきか、あるいはどんな 状態になりたいかの仮説を⽴てる。この仮説がひとまず 辿り着きたい⽬標となる。この⽬標に向かって必要な どこに向かってどこまで辿り着けば次に何が分かるのか。 ヒト、モノ、コト、カネなどを整えて、臨む。 ほとんど⾒当もついていなくて、とにかくまずはやって みようという段階。この状況下では探検さながら、 けもの道を分け⼊るつもりで⾏くよりほかない。 Toshihiro Ichitani All Rights Reserved. 「MVP特定」まで価値探索 (仮説検証) のサイクルを回し続ける 54

55.

“仮説探索” の段階で⽬指すこと 「か - かた - かたち」の整合で「かち」を導く どんな課題やニーズを扱うか それは誰にとってのことか 課題 か 利⽤から新たな 課題を検出する 課題と機能は 整合するか 価値 かち 形態 機能を扱える様にするのに 適した利⽤形態とは何か 機能 かたち かた 機能と形態は 整合するか Toshihiro Ichitani All Rights Reserved. どのように課題やニーズを 具体的に充⾜させるのか 55

56.

プロダクト、事業に関して最⼩限⽴てるべき仮説の観点 「仮説キャンバス」 ⽬的 われわれはなぜこの事業をやるのか︖ 実現⼿段 提案価値を 実現するのに 必要な⼿段と は何か︖ ビジョン 中⻑期的に顧客にどういう状況に なってもらいたいか︖ 優位性 提案価値 顕在課題 代替⼿段 状況 提案価値や 実現⼿段の提供 に貢献する リソースが何か あるか われわれは 顧客をどんな 解決状態に するのか︖ (何ができるよ うになるのか) 顧客が気づいて いる課題やニー ズに何があるか 課題を解決する為 どのような状況 にある顧客が 対象なのか (課題が最も 発⽣する状況 とは) 評価指標 どうなればこの 事業が進捗して いると判断でき るのか︖ (指標と基準値) 収益モデル どうやって儲けるのか︖ に顧客が現状、 取っている⼿段に 何があるか︖ (さらに現状⼿段へ の不満はあるか) 潜在課題 多くの顧客が 気づけていない 課題、解決を 諦めている課題 に何があるか チャネル 状況にあげた⼈ たちに出会うた めの⼿段は何か 傾向 同じ状況にある ⼈が⼀致して ⾏うことはある か 市場規模 対象となる市場の規模感は︖ Toshihiro Ichitani All Rights Reserved. 56

57.

「仮説キャンバス」で 「か - かた - かたち」の整合を観る ⽬的 われわれはなぜこの事業をやるのか︖ 実現⼿段 かた 提案価値を 実現するのに 必要な⼿段と は何か︖ 中⻑期的に顧客にどういう状況に なってもらいたいか︖ 優位性 提案価値 顕在課題 代替⼿段 状況 提案価値や 実現⼿段の提供 に貢献する リソースが何か あるか われわれは 顧客をどんな 解決状態に するのか︖ (何ができるよ うになるのか) かち 顧客が気づいて いる課題やニー ズに何があるか 課題を解決する為 どのような状況 にある顧客が 対象なのか (課題が最も 発⽣する状況 とは) (機能) かたち ビジョン (価値) 評価指標 どうなればこの 事業が進捗して いると判断でき るのか︖ (指標と基準値) (形態) 収益モデル どうやって儲けるのか︖ か(課題) に顧客が現状、 取っている⼿段に 何があるか︖ (さらに現状⼿段へ の不満はあるか) 潜在課題 多くの顧客が 気づけていない 課題、解決を 諦めている課題 に何があるか チャネル 状況にあげた⼈ たちに出会うた めの⼿段は何か 傾向 同じ状況にある ⼈が⼀致して ⾏うことはある か 市場規模 対象となる市場の規模感は︖ Toshihiro Ichitani All Rights Reserved. 57

58.

価値探索 (仮説検証) は 少なくとも3回以上回す 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 MVP検証 スプリント レビュー 次の価値探索へ アジャイル 構想を早く形にして フィードバックを得る Toshihiro Ichitani All Rights Reserved. 58

59.

段階的な検証によって価値を特定する PSF PMF No t 不確実性⾼ 解決するべき課題、 課題に対して提供する そのアーリアダプター ソリューションの の特定もできていない 有⽤性、有意性を ため、確からしさが インタビューレベルで 何もない段階。 確かめる段階。PSFの インタビュー検証を 第⼀段階を得るための 繰り返し実施する。 活動であり、速度が 数が求められる。 期待される インタビュー検証 fi fi fi 課題探索 インタビュー検証 PSF向け プロトタイプを⽤いて 疑似体験が伴う検証に PS t実現 よってPSFのリアリティ 不確実性中 を⾼める段階。 形態も検証の対象に⼊り 始める 実体験が可能な検証によって PSFを確認する最終段階 プロトタイプ検証 Toshihiro Ichitani All Rights Reserved. MVP検証 PM t実現 不確実性低 チャネル検証

60.

選択を”段階”に⾏うことで不確実性を対処する 選択の幅最⼤ (セットベー ス) 検証 計画 仮説⽴案 スプリントプ (モデル化) 価値探索 ランニング 検証 開発計画 (リリースプラ MVP特定 ンニング) (正しいものを探す) 選択の振れ幅最⼩ 評価 (ポイントベー スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ スプリント レビュー ス) ⽬的選択の 段階 何を価値と置くのか︖ を特定するための段階 PSFにたどり着くまで MVP検証 次の検証計画 (価値探索)へ 実体選択の ⼿段選択の 順序選択の 段階 段階 段階 価値仮説を 最も適切に 実現する MVP実現に 作るべきものの 必要な⼿段 順序を選択し の設計と 形にする 回転し続ける(3回以上) MVPを特定 計画作りを する ⾏う Toshihiro Ichitani All Rights Reserved. 例えば、⼿段選択の段階でコンセプトを 変える決定の影響の⼤きさは明らか 60

61.

「仮説検証型アジャイル開発」を どのようにして始めるか︖ Toshihiro Ichitani All Rights Reserved. Photo credit: fourbrickstall on Visualhunt.com

62.

仮説検証︖ アジャイル開発︖ Toshihiro Ichitani All Rights Reserved. 62

63.

それ以前に 仮説検証︖ “チームで動く” を⽬指す アジャイル開発︖ Toshihiro Ichitani All Rights Reserved. 63

64.

理想は仮説検証もアジャイルも “⼀つのチーム”として取り組むこと 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー アジャイル 構想を早く形にして フィードバックを得る 次の価値探索へ

65.

ゼロからプロダクト作りを 始めるならまず「左側」から 仮説検証チーム 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー アジャイル 構想を早く形にして フィードバックを得る 次の価値探索へ

66.

次の段階として、 仮説検証の結果をアジャイルに繋げる 仮説検証チーム 選択の幅最⼤ (セットベース) 検証 計画 アジャイル開発チーム 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー アジャイル 構想を早く形にして フィードバックを得る 次の価値探索へ

67.

注⽬するべきは What(何をやるか)以上に 探索適応とは、プロセス (⼿順) ではなく How(どうやるか) 終わりなきジャーニー (旅) Photo credit: sama093 on Visualhunt

68.

何を⽬指したいのか︖ ありたさ、Toさえも 探索の対象となりえる Photo credit: Martin_Heigan on VisualHunt.com

69.

チーム、組織に探索適応し続けられる “仕組み” こそを宿そう (オートノミー) Toshihiro Ichitani All Rights Reserved. 69

70.

「仮説検証型アジャイル開発」から始めよう Toshihiro Ichitani All Rights Reserved. 70

71.

正しいものを正しくつくれているか︖ Toshihiro Ichitani All Rights Reserved.

72.

参考図書 Toshihiro Ichitani All Rights Reserved. 72

73.

「仮説検証型アジャイル開発」 の原典 チームで仮説検証とアジャイル 開発を⾏うための指南書 Toshihiro Ichitani All Rights Reserved. 仮説検証型アジャイル開発の 各段階を詳しく解説 73

74.

「正しいものを正しくつくる」を さらに詳しく掘り下げたい⽅に https://www.docswell.com/s/papanda/Z4Q3NJ-shin-drr Toshihiro Ichitani All Rights Reserved. 74