正しいものを ともに考え
正しく ともにつくる
Ichitani Toshihiro
市⾕聡啓
The end of the journey is the beginning of a new journey
第1部
正しいものを正しくつくる
市⾕ 聡啓
Ichitani Toshihiro
https://ichitani.com/
Profile Twitter
https://twitter.com/papanda
“越境をエナジャイズするジャーニー”
What Doing
講演、研修、執筆
仮説検証型アジャイル開発
によるプロダクトづくり
仮説検証、アジャイル開発の
実践⽀援 (メンタリング)
DX (Digital Transformation) ⽀援
https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM
ともに考え、ともにつくるプロダクト開発の実践
「チーム・ジャーニー」
2020年2⽉17⽇発刊
https://amzn.to/32Wuklp
われわれが挑戦していること
不確実性の⾼いプロダクト開発
…は領域を選ばない
Photo on VisualHunt.com
“誰かのために作る”
という時点で不確実性と向き合う
ことは不可避
(“誰か" is ユーザー、顧客)
Photo on VisualHunt.com
“SoE だから不確実性が⾼い”
“SoR だから不確実性が⾼くない”
という2元論で説明する時代は終わった
Photo credit: Ravi_Shah on Visual hunt / CC BY
10年あるいは20年近い、
“知る⼈ぞ知る” な基幹システム
(なおそれを知る者はほぼいない)
バックエンドにフタをして
フロントの世界だけで新しい
価値を⽣み出そう の限界
(フロント(SoE)で”デキない制約”が強すぎる)
Photo credit: v923z on Visual hunt / CC BY
⼈知れず動くSoRを巡る調査は
まさに(価値)探索
ひとりでいくな危険
Photo credit: Kylie_Jaxxon on Visual Hunt / CC BY-SA
今われわれが直⾯していることは
⼈間が普段やっている⾏為を
デジタルに置き換えよう
ではなくて
あらゆる⼿段を使って
どのようにトランスフォーミング
できるのかという検証そのもの
Photo credit: Kevin M. Gill on Visualhunt / CC BY
Photo on VisualHunt.com
保険業務
SoE
SoR
本⼈認証
⼦供写真共有アプリ
MaaS
RPA従業員満⾜度
婚活
介護ロボット
決済
VR D2C
Photo on VisualHunt.com
保険業務
SoE
SoR
本⼈認証
⼦供写真共有アプリ
MaaS
RPA従業員満⾜度
婚活
介護ロボット
決済
VR D2Cエクスペリエンスの再定義
“タダシイ筋道も筋書き”もない中で
それでも前に進むためには?
対象となる状況や問題についての
仮説を⽴て、検証し、分かったこと
(学習)に基づいて、プロダクトを
実装するあり⽅が求められる
Photo on VisualHunt
仮説検証型
アジャイル開発
仮説とは?
仮説 = 前提 + 仮定 + 期待結果
  前提:昨年はある商品の売上が10%伸びた
  仮定:リーチしていない顧客はまだまだいるはずで
     さらに広告投資を50%増やすため
期待結果:今年の売上は20%の伸びは期待できる
前提(事実)が少ないほど、
仮定の部分が多い(不確実)
ゆえに仮説検証で仮定(想像)を
減らし、前提(事実)を増やす
前提
仮定
期待結果
前提
仮定
期待結果
仮説
検証
前提
仮定
期待結果
データ 知⾒
前提(事実)を作るための根拠が
データ (定量/定性) であり、
知⾒ (経験知)
ゆえにデータによる理由付けが
不可⽋であり、データを補う
知⾒(既知の事実)が全体の速度
を上げる
仮説検証で「事実を増やす」とは?
「情報」を増やして、「理解」を得ること
            (“分かった”を増やす)
前提
仮定
期待結果
データ 知⾒
情報
解釈
理解
☓
だからといって検証や調査で情報だけ増やしても、
解釈を難しくて、誤った理解になりえる
前提
仮定
期待結果
データ 知⾒
情報
解釈
理解
☓
前提
仮定
データ 知⾒
情報
解釈
理解
☓
ゆえに、正しい理解を得るためには、「解釈」を
鍛える必要がある(すなわち学習結果を積み重ねる)
期待結果
これまで
獲得した知識
検証結果
による学び
検証結果
による学び
前提
仮定
データ 知⾒
情報
解釈
☓
期待結果
これまで
獲得した知識
理解
仮説
合意形成
意思決定
その上で、⽴てた仮説に基づいて
意思決定のための合意形成を⾏う
検証結果
による学び
前提
仮定
データ 知⾒
情報
解釈
☓
期待結果
これまで
獲得した知識
理解
仮説
合意形成
意思決定
さらに⽴てた仮説に基づいて
意思決定のための合意形成を⾏う
すべての箇所で誤る可能性がある
ゆえに仮説の⽴て⽅、検証の⽅法、学習の蓄積
チーム内だけではなく関係者との合意形成
について学び、練度を⾼めていきたい
選択の幅最⼤
(セットベース)
検証
計画
仮説⽴案
(モデル化)
検証
評価
価値探索
(正しいものを探す)
MVP特定
開発計画
(リリースプラ
ンニング)
スプリントプ
ランニング
スプリント
開発
スプリント
レビュー
スプリント
レトロスペクティ
ブ
MVP検証
アジャイル開発
(正しくつくる)
次の検証計画
(価値探索)へ
選択の振れ幅最⼩
(ポイントベース)
仮説検証型アジャイル開発
仮説検証の「例」
仮定⽴案
(仮説キャンバス)
探索的検証
(顧客インタビュー)
仮説の修正
仮説検証1周⽬ (target : PSfit)
仮定⽴案
(仮説キャンバス)
探索的検証
(顧客インタビュー)
仮説の修正
仮説検証1周⽬ (target : PSfit)
仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう))
イメージ制作
(ストーリーボード等)
イメージを伴う検証
(顧客インタビュー)
仮説の修正
仮定⽴案
(仮説キャンバス)
探索的検証
(顧客インタビュー)
仮説の修正
仮説検証1周⽬ (target : PSfit)
仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう))
イメージ制作
(ストーリーボード等)
イメージを伴う検証
(顧客インタビュー)
仮説の修正
仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう))
プロトタイプ制作
(No Code Prototyping)
操作を伴う検証
(プロトタイプ検証)
仮説の修正
仮定⽴案
(仮説キャンバス)
探索的検証
(顧客インタビュー)
仮説の修正
仮説検証1周⽬ (target : PSfit)
仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう))
イメージ制作
(ストーリーボード等)
イメージを伴う検証
(顧客インタビュー)
仮説の修正
仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう))
プロトタイプ制作
(No Code Prototyping)
操作を伴う検証
(プロトタイプ検証)
仮説の修正
仮説検証4周⽬ (target : PSfit (被験者に利⽤体験してもらい評価する))
MVP特定と開発
(ユーザー⾏動フロー)
利⽤体験を伴う検証
(MVP検証)
仮説の修正
仮説には「構造」がある
課題仮説
機能仮説
形態仮説
本質的な課題
課題の解決⼿段
⼿段を利⽤可能にする
か
かた
かたち
まず解くべき問いがあり、問いに答える⼿段があり、
⼿段を扱えるようにするための形がある
=
=
=
=
=
=
仮定⽴案
(仮説キャンバス)
探索的検証
(顧客インタビュー)
仮説の修正
仮説検証1周⽬ (target : PSfit)
仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう))
イメージ制作
(ストーリーボード等)
イメージを伴う検証
(顧客インタビュー)
仮説の修正
仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう))
プロトタイプ制作
(No Code Prototyping)
操作を伴う検証
(プロトタイプ検証)
仮説の修正
仮説検証4周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう))
MVP特定と開発
(ユーザー⾏動フロー)
利⽤体験を伴う検証
(MVP検証)
仮説の修正
課題仮説
課題仮説 機能仮説
課題仮説 機能仮説
課題仮説 機能仮説 形態仮説
検証⽬的の度合いが異なる
仮説検証5周⽬ (target : PMfit)
UXの推敲
課題仮説 機能仮説 形態仮説
・5周⽬以降に必要となるものは4周⽬の結果に依るが、
 アーリーなユーザー(課題が切実なため多少の瑕疵を⼤⽬にみれる)
 から、ユーザーの裾野を広げる⽅向に進む必要がある。
・より「伝える」ことを丁寧に⾏う必要がある。それはPRだけでは
 なく、プロダクトの表現そのものの磨き込みである。
・ユーザーを⾃分たちに宿し、利⽤体験を頭から何度も繰り返し
 テストし、つっかかりのない「つるつる」を⽬指す(UXの推敲)
分からないことを分かるようにする
分かったことに基づいて、つくる
仮説検証型アジャイル開発の戦略
Photo credit: ilovepics11 on Visualhunt.com / CC BY-NC-ND
 問われるのは
われわれは、どこまで変化に適応できるか?
早く形が⾒える、触れられる
想像⼒頼みから体が使える
だから、圧倒的に学びが増える
Photo credit: Ale Art on Visualhunt / CC BY-ND
学びが次の不確実性を
連れてくる。
Photo on VisualHunt
変化を受け⽌められる
余⽩をつくりながら、
短いタイムボックスの中での
確実性は⾼める。
余⽩が無ければ変化を受け⼊れられない。
いかにして無いところに余⽩を作り出すか?
⻑い距離で確実なことは⾔えない。
でも、短い距離でなら?成果の確度を⾼められる。
Photo credit: Arenamontanus on Visualhunt.com / CC BY
余⽩の戦略
全体への
共通理解を統べる作戦
スプリント強度を⾼める戦術
プロジェクトレベル
複数スプリントレベル
スプリントレベル
・調整の余⽩
・期間の余⽩
・受け⼊れの余⽩
・背⾻駆動開発
・状況をクリーンに保つ5つの条件
1. 受け⼊れ条件を定義している
2. ベロシティを計測し安定させている
3. 受け⼊れテストを実施している
4. 振り返りを実施しカイゼン継続
5. 実運⽤相当のデータが揃っている
余⽩の戦略
・調整の余⽩
 ユーザー⾏動フローのうち「広さをコミット深さで調整」
 全体の必要最⼩限の実現を⾒⽴てつつ、実際の折々では
 状況を踏まえて実現内容を調整する。
・期間の余⽩
 バッファの確保。個⼈・局所のバッファではなく、
 プロジェクトやテーマ単位でバッファを設ける。
・受け⼊れの余⽩
 ICEBOXの運⽤。学びを蓄積(凍結)し、状況を⾒て棚卸
 (解凍)し、PBLとの順序付けを⾏う。
スプリント強度を⾼める戦術
・背⾻駆動開発
 PBLを背⾻(利⽤体験上必要不可⽋、前提となる基本機能)
 とお⾁に分けて、背⾻の開発を先⾏し、開発の前提を作る
スプリント強度を⾼める戦術
・状況をクリーンに保つ5つの条件
 1. 受け⼊れ条件を定義している
   条件を定義しようとしてみることが⼤事。実際にはできない
   場合もある。どこまではっきりしていて、どこからは作って⾒て
   なのかの理解をチーム、関係者で揃える
 2. ベロシティを計測し安定させている
   低すぎず、過熱しすぎず。ボトルネック事案の早期検出をチーム
   で⾏えるようになるために、ベロシティに関⼼を持つ。
 3. 受け⼊れテストを実施している
   条件と呼応するもの(場合によって条件そのもの)。スプリント毎
   の確実な実施が安定度を格段に⾼めることになる。
 4. 振り返りを実施しカイゼン継続
 5. 実運⽤相当のデータが揃っている
全体への共通理解を統べる作戦
・⾃分たちの活動に”作戦名”をつける
活動 = まとまった機能群の開発、カイゼン…
距離感としては
プロジェクト > 複数スプリント > スプリント
象徴的な名前付けで⽅針を分かりやすくする
(“背⾻バックログを倒し切る作戦”)
「この期間」のミッションが明確になり、何をやれば
良いかが⾃明になり、優先基準もわかりやすくなる。
チームの⾃律的な動きへと繋がる。
全体への共通理解を統べる作戦
・⾃分たちの活動に”作戦名”をつける
活動 = まとまった機能群の開発、カイゼン…
距離感としては
プロジェクト > 複数スプリント > スプリント
象徴的な名前付けで⽅針を分かりやすくする
(“背⾻バックログを倒し切る作戦”)
「この期間」のミッションが明確になり、何をやれば
良いかが⾃明になり、優先基準もわかりやすくなる。
チームの⾃律的な動きへと繋がる。
このタイムボックスのことを
“ジャーニー” と呼ぶ
ゼロからのプロダクトづくりではなく
既にあるプロダクトでの仮説検証に
どんな特徴があるか?
デュアルトラック・アジャイル
検証BBB
スプリント11 スプリント13
検証CCC
スプリント
開発スプリントと仮説検証の活動が並⾏して進む
開発→検証→学習結果を開発へとサイクルさせる
並⾏する2つの活動間での同期ポイント設定が必要。
同期の距離が空きすぎると、プロダクトに「学習不全の
負債」がたまる
スプリント12スプリント10
(プロダクト) (プロダクト) (学習結果)
仮説検証リードを置く
仮説⽴案のリードや、検証の計画づくり、検証⼿段や
環境の準備などを中⼼となって進める役割。
仮説検証実施の経験が問われる。適切な練度を備えた
メンターを組織内外から招聘する。
チームで学ぶ機会を段階的につくる
まずは仮説検証とは何かという理解からはじめて、
イベントベースの検証を⾏う(いきなり定常的に、組織
的に⾏うのはハードルが⾼い)
例えば、“ユーザーテスト” や ”プロダクトレビュー” を
イベントとして実施する。
“タダシイ筋道も筋書き”もない中で
それでも前に進むためには?
Toshihiro Ichitani All Rights Reserved.
Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC
⾃らに問い続ける
問い続けることで⾃分たちに傾向を与える
プロダクトづくりにおいて最も誤りをおかす箇所とは
⾃分たち⾃⾝の意思決定や⾏動。
Photo credit: Shandi-lee on Visualhunt.com / CC BY-NC-ND
第1部
完
https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM https://amzn.to/32Wuklp
https://ichitani.com/ https://enagile.jp/
第2部
ともに考え、ともにつくる
不確実性との戦い
必要なのは「誰にも分からない」という
状況下で前に進んでいくあり⽅
Photo credit: Kylie_Jaxxon on Visualhunt / CC BY-SA
不確実性とは
回避するべきもの
なのか?
混沌を引き寄せるものであり、
プロダクトの未来を変える可能性でもある
不確実性とは、
明⽇の予定調和が常に明るい未来なわけではない
未来を変えるためにはシナリオ(台本)を変えられる
必要がある
Photo credit: occhiovivo on Visual Hunt / CC BY-NC-ND
つまり、不確実性を⾃ら招き寄せる
分からないことを増やす
Photo on VisualHunt.com
不確実性を招き寄せるために
多様性を⾼める
Photo on VisualHunt
検証結果
による学び
前提
仮定
データ 知⾒
情報
解釈
☓
期待結果
これまで
獲得した知識
理解
仮説
合意形成
意思決定
多様性
多様性が解釈に幅をもたらす
重奏型仮説検証
重奏的仮説検証
仮説の外在化
第1段階
プロダクトオーナー1⼈の
解釈を⼀⽅的に伝える
仮説キャンバスで仮説を外在化
(誰でも表明が出来る)
(解釈を頭から取り出す)
仮説検証
われわれはなぜこの事業をやるのか?
⽬的 ビジョン
実現⼿段 優位性
評価指標
提案価値 顕在課題
潜在課題
代替⼿段
チャネル
状況
収益モデル 市場規模
中⻑期的に顧客にどういう状況に
なってもらいたいか?
提案価値を
実現するの
に必要な⼿
段とは何か?
提案価値や実現
⼿段の提供に貢
献するリソース
(資産)が何かあ
るか?
どうなればこ
の事業が進捗
していると判
断できるのか?
(指標と基準値)
われわれは
顧客をどん
な解決状態
にするのか?
(何ができる
ようになる
のか)
顧客が気づいて
いる課題に何が
あるか?
多くの顧客が気
づけていない課
題、解決を諦め
ている課題に何
があるか?
課題を解決するた
めに顧客が現状取っ
ている⼿段に何が
あるか?(さらに
現状⼿段への不満
はあるか)
状況にあげたひ
とたちに出会う
ための⼿段は何
か?
どのような状
況にある顧客
が対象なのか
(課題が最も発
⽣する状況と
は?)
どうやって儲けるのか? 対象となる市場の規模感は?
傾向
同じ状況にある
⼈が⼀致して⾏
うことはあるか?
仮説キャンバス (1.0)
Toshihiro Ichitani All Rights Reserved. Photo credit: somenice on VisualHunt / CC BY-NC
プロダクトオーナーの視座を
プロダクトの上限(ボトルネック)にしない
Photo credit: Wendelin Jacober on Visual Hunt / CC BY
"プロダクトオーナー”の⺠主化
PO⼀⼈の視座、視野から
チームの視座、視野へ
重奏的仮説検証
仮説検証の重奏化
第2段階
それぞれの中に仮説を持ち、
共通の理解に対して掛け合わせる
・多様なメンバー=多様な解釈への期待
・検証を通じての仮説⽴案が前提
・仮説検証の実施リードや解釈の
 メンター役は必要(仮説検証リード)
仮説検証
重奏的仮説検証
チーム or PO を仮説検証にどうやって巻き込むか
最初は誰もが半信半疑。実践していく
中で、意義を⾒出して⾏く。
仮説検証についてのゴールデンサークル
を確認した後、段階的な取り込みを設計
する。
第1ジャーニー:事前学習
第2ジャーニー:イベントベースの検証
第3ジャーニー:継続的な検証活動
Photo credit: Wendelin Jacober on Visual Hunt / CC BY
意味あるものを作り出したい
という意思に
POや開発者という分け隔ては無い
相⼿のナラティブを知ろうとする
Photo credit: zxjbfcindy2019 on Visual Hunt / CC BY-NC-SA
どれだけ多様な⾒⽅が
出せたとしても
チームが進む為には
⼀つのことに合意
しなければならない?
合意形成とは
唯⼀の解釈のみ残し
その他の全て⼀切を捨て去る
ことを強要するものではない
検証結果
による学び
前提
仮定
データ 知⾒
情報
解釈
☓
期待結果
これまで
獲得した知識
理解
仮説
合意形成
意思決定
多様性
ばらばらのままの
合意形成チームの
合意形成 個々の仮説
検証結果
による学び
前提
仮定
データ 知⾒
情報
解釈
☓
期待結果
これまで
獲得した知識
理解
仮説
合意形成
意思決定
多様性
チームの
共通合意 個々の仮説
ばらばらのままの
合意形成
(それぞれが仮説を持つ)
仮説を⽴てるのにハードルがあるならば
まずはワンライナーから始める
https://ichitani.com/2019/oneliner-canvas/
多様性 ☓ 機動性
プロダクトづくりに多様性を取り込む、では次に⽬指すことは?
多様性によって広がる選択に最⼤限適応していく
Photo credit: U.S. Pacific Fleet on VisualHunt.com / CC BY-NC
チームの機動性を上げるとは?
インプット(変化)に対して即応性をあげる
ただし、全体性を⾒失わずに。
誰かが与えた全体性のもとに、端っこから
作っていくのではなく、⾃分たち⾃⾝で舵を取る
「段階」
の概念を取り⼊れる
(全体と微細の両⽴)
「段階の設計」とは
⾃分たちが到達したい地点(⽬的地)を⾒⽴て、そこに
たどり着くために必要となる状態を構想すること。
現実を進めた結果から分かったことに基づき、構想⾃体を
変化させる (現実を構想に合わせることが⽬的ではない)。
⽬的地⾃体も通過点に過ぎない。変えていく。
段階の⻘写真は、当事者に⽅向性を与える。
不確実性の⾼い状況では、チーム、ステークホルダーと
ともに「理解」と「意思決定」を共通にして歩み進むこと
が唯⼀の頼り。
※チームの活動単位であるスプリントの⻑さは
 チームのリズムを作るために固定
※多様なミッションを捉えるため
 ジャーニーの⻑さ(スプリントの数)は可変
段階(ジャーニー)を経てアウトプット
されるのは、チームとプロダクトの2つ
Photo credit: mikecohen1872 on Visualhunt.com / CC BY
チームもプロダクトも最初から
完成型(理想)が⾒えるわけではない
ジャーニー = 段階的発展 = 進化
当事者として
「意思のある進化」を仕組み、
その上で変化に適応していくこと
どのようにして
ジャーニーを運⽤
するのか?
リーン・ジャーニー・スタイル
リーン・ジャーニー・スタイル
セットベースで選択肢を広げ、ポイントベースで
アウトプットを結実させる
選択肢を広げるために多様性を利⽤する
段階の設計によって、経験による学びを踏まえた
当事者の意思決定を着実に形にしていく
変化への適応性を確保するために、ミッション、
フォーメーション、チームの主義を動的に選択する
⽬的地を⾒定める
ジャーニー(段階)を
設計する
ジャーニーの
ミッション定義
チームの
フォーメーションを変更
ジャーニーバックログ
プランニング
チームの
ファースト選択
ジャーニーの
遂⾏
ジャーニーのふりかえり
とむきなおり
(ジャーニーごとの回転)
少しずつ繰り返しながら
形づくる (agile)
繰り返し = イテレーティブ
少しずつ = インクリメンタル
(チームもプロダクトも)
段階的に = ジャーニー
最初の旅(仮説検証)
次の旅(プロトタイプ)
さらに次の旅(MVP)
少しずつ = インクリメンタル
繰り返し = イテレーティブ
段階的に = ジャーニー
形作る
リーン・ジャーニー・スタイル
重奏的仮説検証
ジャーニースタイル
フォーメーション・パターン
適者⽣存型アーキテクチャ
仮説検証
プロセス
チーム
アーキ
※第1ジャーニーで検証結果が期待するものでは
 無かったら当然、全体のジャーニーを⾒直す
プロダクト・ジャーニー
選択の幅最⼤
(セットベース)
検証
計画
仮説⽴案
(モデル化)
検証
評価
価値探索
(正しいものを探す)
MVP特定
開発計画
(リリースプラ
ンニング)
スプリントプ
ランニング
スプリント
開発
スプリント
レビュー
スプリント
レトロスペクティ
ブ
MVP検証
アジャイル開発
(正しくつくる)
次の検証計画
(価値探索)へ
選択の振れ幅最⼩
(ポイントベース)
仮説検証型アジャイル開発
不確実性が⾼いプロダクトづくりでのパターン
仮説検証ジャーニー MVP開発ジャーニー MVP検証
ジャーニー
「傾き」の問題
Photo on VisualHunt.com
理想的な変化量と現実の乖離イメージ
「これまで」が引き寄せる
重⼒を突破できない
Photo credit: Miles Cave on Visualhunt / CC BY-NC-ND
厳然と存在する「変化格差」
「段階」によって「なめらか」にする
チーム・ジャーニー
※チームの成⻑戦略を描く。⾃分たちの出発点を⾒定め、ひとたび⽬指す
 ⽬的地までの「傾き」が急勾配にならないよう設計する。実際のところ
 歩みはじめてみて、傾きを調整する。⽬的地⾃体を捉え直す。
「過去」をふりかえり、現在を捉え直す
「未来」にむきなおり、現在を捉え直す
ジャーニーにむきなおりは前提
プロダクトやチームを
越えた、⼤きな段階を
迎えている
Digital Transformation
DXは、現場と経営の変⾰意思が
噛み合う惑星直列的なチャンス
現場でいくらアジャイルを⾔っても通じなかった時代
“トップダウンによる変⾰”が空を切り続けた時代
を経て、われわれは共通の危機感の下に辿り着いた
Photo credit: NASA Goddard Photo and Video on Visual hunt / CC BY
チーム・ジャーニー
現状の全てを⼀気呵成に
Transformationするのは
チームも練度も⾜りない。
現状の⽂脈から分断した環境を作る
(たいていの場合SoEが成熟していないからできる)
SoE開発を通じてチーム作りに注⼒
然る後に本丸(SoR)に切り込む
(「逆2項対⽴」作戦)
※DXのミッションとして技術・プロセスのモダン化、新たなビジネス 
 モデル構築全てに⼀気呵成に取り組むのではなく、局所的なSoE
 構築を先⾏させて学びの⼟台作りを⾏う。
DX・ジャーニー
(狙いは、ジャーニーを通じたチーム、組織の成⻑)
ジャーニーは重なり合う
このあり⽅の先に
あるものとは?
「われわれはどこに向かうのか」
ともに考え、ともにつくる
固定的な役割を中⼼とした「調整」から
仮説検証による学びを中⼼とした「ともに」へ
Photo on VisualHunt.com
ともに考え、ともにつくり
続けるためには?
お互いの関係性に意味を⾒つける
「われわれはなぜここにいるのか?」
Photo on VisualHunt.com
⾃分⾃⾝のミッションと
役割を問い直し続ける
必要がある
“⾃分のナラティブを脇に置く”
『他者と働く』
Photo on VisualHunt.com
私⾃⾝のジャーニー
ゆえに。さいごに、
地⽅アトツギ国・⾃治体
⼤いなる組織 (⼤企業)
Photo via Mars Williams via Visual hunt
これまで⽇本の社会インフラを
つくってきたプレイヤーこそ
逆境にある
Toshihiro Ichitani All Rights Reserved.
Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC
逆境からの越境
つまり、不確実性を⾃ら招き寄せる
分からないことを増やす
Photo on VisualHunt.com
Toshihiro Ichitani All Rights Reserved.
20代、30代ではなく
今の⾃分だからできること、
やるべきことがある
このジャーニーは、
⾃分⾃⾝の再定義の旅
Redesign Journey
新たな境界でまた。会えることを。
Photo credit: digitalpimp. on Visualhunt.com / CC BY-ND

正しいものをともに考え、正しくともにつくる