作る、試す、正す。

聡啓 Ichitani Toshihiro チーム、部署、事業、組織でのアジャイル適応（株式会社レッドジャーニー）特に専援は「仮説検証、アジャイル開発、組織アジャイル」企業DX・組織変 (製造・製薬ほか多数) 支大谷政でのアジャイル、地域DX 革この数年の取り組み門行市

3.

組織にアジャイルを宿すための指針「アジャイルハウス」組織で動くための「アジャイル」 3F 2F 1F 基礎（組織自体で探索適応が可能となるために）事業創出のための「アジャイル」（既存事業の価値向上、新たな事業の創出のために）チームで仕事するための「アジャイル」（状況を見えるようにして、一緒に取り組めるように）アジャイルマインドの共通理解 Toshihiro Ichitani All Rights Reserved. 3

4.

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

5.

6.

https://www.amazon.co.jp/dp/4802513291/

7.

8.

9.

10.

11.

12.

13.

14.

品質の均化、効率性の向上のためにルールや規程によって業務を制約する (ムダ、ムリ、ムラをなくす=想定外をなくす) もっと最適化あらゆる組織活動あらゆる組織活動組織を取り巻く環境組織を取り巻く環境組織のあらゆる活動を環境と営みが合致し取り巻く環境に結果が出るほどに適応させる=最適化最適化路線は強化される (顧客の要求、期待品質) (顧客の要求、期待品質) 一 Toshihiro Ichitani All Rights Reserved.

15.

「前提」(環境) が変わったときに組織活動の「それまで」が tしないあらゆる組織活動もっと最適化あらゆる組織活動もっと最適化あらゆる組織活動組織を取り巻く環境組織を取り巻く環境組織を取り巻く環境 (顧客の要求、期待品質) (価値観変容、の減少技術の進化) 組織のあらゆる活動を環境と営みが合致し前提が変わっている取り巻く環境に結果が出るほどにことに気づけない適応させる=最適化最適化路線は強化されるあるいは気づいても (顧客の要求、期待品質) ﹅﹅ fi 口！人 Toshihiro Ichitani All Rights Reserved. ﹅﹅﹅﹅﹅﹅﹅﹅変えられない﹅

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

システムの起源は、2つ “サイバネティクス” と “ 問どうやってモノや般システム理論” 物は安定して動き続けるのかウィーナーベルタランフィー・サイバネティクス・制御とフィードバック・システムを「 →処理→ 出 →フィードバック」という情報循環として理解・般システム理論・全体性、相互作・システムを「部分の単なる合計以上のもの」と捉えるどう動くかどう成り “システム思考” 28 ？一生用力入立力： Toshihiro Ichitani All Rights Reserved. 一つか

29.

システム思考で問題を捉える問題解決のツールとしてシステムが https://www.amazon.co.jp/dp/B00ENSKOQK https://www.amazon.co.jp/dp/4862761801/ いられる https://www.amazon.co.jp/dp/4862761011/ 好循環、悪循環の因果関係をえるようにして複雑な問題にも向き合えるようにする 29 用見 Toshihiro Ichitani All Rights Reserved.

30.

系譜はリーンやアジャイルにも因果関係図で現場課題の真因を捉える https://scrumguides.org/docs/scrumguide/ v2020/2020-Scrum-Guide-Japanese.pdf 「透明性、検査、適応」 ≒ 制御とフィードバック https://www.docswell.com/s/papanda/KY8MLK-ss-30130669#p14 Toshihiro Ichitani All Rights Reserved. 30

31.

32.

未来を “共につくる” システム (全体性) とデザイン (未来共創) の邂逅 → システミックデザイン全体をえるようにして、より望ましい未来をともに描き、実現に向けていく・地域デザイン（まちづくり）・サービスデザイン（体験づくり）・サステナビリティ（環境・社会の仕組み） https://www.amazon.co.jp/dp/4802512708 ：見 Toshihiro Ichitani All Rights Reserved. 32

https://www.amazon.co.jp/dp/4802512708

33.

34.

35.

あえて “ソフトウェア” を分けて捉えよう。 35

36.

37.

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

38.

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

39.

40.

41.

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

42.

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

43.

44.

45.

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

46.

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

47.

セオリー通りでありながら直する “デッドエンド” 面 Photo credit: Kylie_Jaxxon on Visual Hunt / CC BY-SA

48.

49.

50.

51.

52.

53.

技術的課題どのようにするかの課題。専知識で解ける ①技術的負債を抑する設計とは ②MVPアプローチの取り組みとは ③組織で規模アジャイルやるには ①ビジネス側と開発の関の不致 ②既存事業の基準ですべてを評価 ③強固な現状維持バイアス適応課題価値観や前提を通じ合わせなければ解決できない https://www.amazon.co.jp/dp/4910063013 一方心門止大 Toshihiro Ichitani All Rights Reserved. 53

https://www.amazon.co.jp/dp/4910063013

54.

55.

56.

57.

https://www.amazon.co.jp/dp/4822281930/

58.

59.

60.

61.

62.

63.

64.

提案価値の連鎖 = “仮説展開"の仮説三対象顧客は… 実現段として…が必要解決対象の課題に…を加えてサービスを拡充対象顧客を…まで広げる獲得できる優位性顧客の…なデータを蓄積する …に関するデータを蓄積するサービスのブランド想定するビジネス規模収益性ほぼ無し単年想定収益… 3年想定収益… 単年想定収益… 3年想定収益… 仮説の前提仮説モデル目目目目目手手手 Toshihiro Ichitani All Rights Reserved. 手二一 2周、3周で勝負する「仮説展開ストーリー」を描く 64

65.

体を「ジャーニー」化するの事業から圧倒的な勝利を垂直的に得ることは難しい。むしろ、それほど分かりやすい「きなニーズ」にたどり着けることなるかの「前提」を仮説り事業を作り、辿る作戦本丸の事業展開の事業仮説の前提仮説の前提仮説の前提仮説モデル仮説モデル仮説モデル獲得できる獲得できる獲得できる口優位性入立自立優位性優位性大つようなの事業り口体が希少と思う。どのようにして価値にて、その前提が成り自初手入事業展開

66.

67.

68.

69.

70.

71.

72.

73.

現状のシステムの From と To を取ろう To To - From = Gap (課題) 状態(データ)が分かることで新たなコミュニケーションを創出し健康で安な常を作り出す Gap From ろくに由に・データの可視化、保全ができていない・ステークホルダー間のコミュニケーションが構築できていない … 分や家族のデータをることもできない？日見自 Toshihiro Ichitani All Rights Reserved. 心自システムに対してどう向きあうか 73

74.

75.

76.

77.

78.

79.

80.

考えることと動くことの間の距離を縮めるキャンバスの中は「仮説」でしかない蓋然性を確かめるには検証するより他ないつまり、キャンバスを作ったら、さっさと「動く」ことが前提になる顧客候補に会いにいくことかもしれない成AIでプロトタイプを表現することかもしれない MVPで検証することかもしれない Toshihiro Ichitani All Rights Reserved. 身生「キャンバス」で捉える意味 80

81.

82.

もう少し補エナクティヴィズム（為的認知）エナクティヴィズムとは、「は、動くことで世界を知る」という考え。知ることは、頭の中で考えるだけではなく、実際にを動かし、世界と関わり、その反応から学ぶこと。つまり、る → わかるではなく、関わる → わかる。（例えば転とかの運転）行手車車方足見自人 Toshihiro Ichitani All Rights Reserved. https://www.amazon.co.jp/dp/4791777158 82

https://www.amazon.co.jp/dp/4791777158

83.

84.

85.

86.

87.

キャンバスのベースを作る際にいに活するキャンバスを作るのには定の労がかかる、何種類も何回も作ることに躊躇する。たたき台づくりや情報補完にAIを活する「動成」はベース部分ではありただ、メインは「為の中で知る」こと間がAIの助けを借りながらやることはここ（しか残らないだろうな）それでも劇的にかける労は減らせるむしろだからこそ「システムを捉える」ことが現実的になった 87 用大？力用力行一生 Toshihiro Ichitani All Rights Reserved. 自人ところでAIとの絡みは

88.

システムズエンジニアリングシステムとえば “SE” との絡みは「システムを知る」ための法として、 SEや語としてUML、Sysmlが存在する現状構造を書き出す、という点では当然ながら法として整備されており、かつ AIを活することで「労問題」も回避 …が、「為の中で知る」がメインとすると、その構造の「意味」を捉えることに重きを置きたく、結果的にキャンバス類を選択するにった https://www.amazon.co.jp/gp/product/4621304054/ (なのでシステムをUML的な絵で表現していないわけです) 88 ？方力言至行用方言 Toshihiro Ichitani All Rights Reserved.

https://www.amazon.co.jp/gp/product/4621304054/

89.

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

100.

101.

102.

103.

104.

105.

規模アジャイルはまあ ”型時間”がスクラムこの辺としたら… くなるちなみに従来の標準やプロセスはこのイメージ慣れているから “やっている体感” は相対的に低い型の重さ (型と向き合う時間のイメージ) 「アジャイルやるぞ」の時間がくなるスクラムにさえ向き合えないのに、さらなる型に向き合えるのか「そのためのトップダウンだ」はそうなのだけど、「やる」のは各だから。皆耐えられるのかは変わらない？？長！自 Toshihiro Ichitani All Rights Reserved. 長大 “やっている感” のある時間

106.

107.

108.

【次】第1章ソフトウェアづくりをアジャイルにする仮説キャンバスで「期待」を捉える 1-1 ソフトウェアづくりを間違う理由 1-2 仮説キャンバスで期待を捉える 1-3 作る、試す、正す第2章ソフトウェアからプロダクトへ仮説キャンバスで「価値」を捉える 2-1 解くべき「問題」が存在しない 2-2 仮説キャンバスで価値を捉える 2-3 仮説検証型アジャイル開発によるプロダクトづくり第3章プロダクトからシステムへ仮説展開ストーリーで「変化」を捉える 3-1 き詰まる「プロダクトづくり」 3-2 「システム」の仮説をてる 3-3 「システム」の仮説検証第4章システムをシステムでつくる From-Toキャンバスでチームに「アジャイル」を宿す 4-1 最もさな動くシステム（ＭＶＳ） 4-2 「プロダクトチーム」から「システムチーム」へ 4-3 中間的成的組織第5章アジャイルなシステムをアジャイルにつくる「作るモノ」と「モノづくり」の体化へ 5-1 システムをアジャイルにつくる 5-2 システムをアジャイルにする 5-3 システムに「内包」されたモノづくり 108 一：：：：：立生小行目 Toshihiro Ichitani All Rights Reserved.

109.

【次】第1章ソフトウェアづくりをアジャイルにする仮説キャンバスで「期待」を捉える 1-1 ソフトウェアづくりを間違う理由 1-2 仮説キャンバスで期待を捉える 1-3 作る、試す、正す第2章ソフトウェアからプロダクトへ仮説キャンバスで「価値」を捉える 2-1 解くべき「問題」が存在しない 2-2 仮説キャンバスで価値を捉える 2-3 仮説検証型アジャイル開発によるプロダクトづくり第3章プロダクトからシステムへ仮説展開ストーリーで「変化」を捉える 3-1 き詰まる「プロダクトづくり」 3-2 「システム」の仮説をてる 3-3 「システム」の仮説検証第4章システムをシステムでつくる From-Toキャンバスでチームに「アジャイル」を宿す 4-1 最もさな動くシステム（ＭＶＳ） 4-2 「プロダクトチーム」から「システムチーム」へ 4-3 中間的成的組織第5章アジャイルなシステムをアジャイルにつくる「作るモノ」と「モノづくり」の体化へ 5-1 システムをアジャイルにつくる 5-2 システムをアジャイルにする 5-3 システムに「内包」されたモノづくり 109 一：：：：：立生小行目 Toshihiro Ichitani All Rights Reserved.

110.