組織を芯からアジャイルにする

Ichitani Toshihiro

Photo credit: Onasill ~ Bill - 72.7M on Visual Hunt / CC BY-NC-SA

Toshihiro Ichitani All Rights Reserved.

市⾕聡啓

2020年COVID-19

DX

「顧客体験」の再定義によって「新たな価値」を⽣み出し続けられる組織となること
外部環境の変化

テクノロジーを活⽤した新しいサービス・事業の創出

内部環境の変⾰

顧客体験の再定義

DXとは、誰にとっても探索の旅（ジャーニー）探索が不要なら、それはトランスフォーメーションとは呼ばないかもしれない（通常業務！）

Toshihiro Ichitani All Rights Reserved.

Photo via Austin Ban via VisualHunt.com

DXを進める上での課題とは何か？

(新たな取り組みに必ず伴う困難)「整っている状態」から始まることなど無い「新たな取り組み(企画)」とは、イマココの延⻑線には無いからこそ「新た」と呼ぶ。ゆえにその始まりは常に「混沌」から始まる (体制がない、分からないことだらけ、あいまい)。
新たな取り組みの本質的な難しさとは、これまで前提に置いてきたこと、理解してきたことでは前に進まない、「不確実性」の⾼い状況下で、「分かった」を⼀つ⼀つ積み重ねることで突破しようと挑むところにある。

(DX / デジタルトランスフォーメーションに伴う困難)

向き合うべき制約が増えるDXの⼀貫として取り組まれるプロダクト開発。
エンドユーザー向けの事業開発にせよ、業務の再定義に伴う業務システムの開発にせよ、「逆境」でのプロダクト開発となる。
未来に向かって進むために始めたプロダクト作りのはずが過去の歴史の中で積み上がってきた負債によって、その⾏く⼿を⼤きく遮られることになる。それはシステムの負債だけではない。環境は⼈の考え⽅をも規定してしまう(リモートワーク・コロナに伴う困難)

ただでさえ難しい事業作りがより難しくなる
物理的な分断が、チームや組織の相互理解も分断する。
何を⽬指すのか？イマは何をするべきなのか？
⾃分は何をするべきか？相⼿の期待とは何？
そもそもイマ、皆はどうしているの？
われわれは、想像以上に「気持ち悪さ」への対応を⾃然と⾏っている。何となく気持ち悪ければ、話してみる、確認してみる、ということをやっている。
それが出来なくなった時。協働がとてつもなく難しくなる

対象となる状況や問題についての仮説を⽴て、検証し、分かったこと(学習)に基づいて、仕事を進めていくあり⽅が求められる

何を変えて、どこに踏み出すのか？

三井不動産DX本部古⽥⽒と語る、推進を加速させた「全社巡業」と「DX2周⽬の課題」とはhttps://bizzine.jp/article/detail/5861

越境を⽀える技術
異なる領域へと⽴ち向かうには、確からしいことが何も無い中でも進むための技や姿勢が必要。

Toshihiro Ichitani All Rights Reserved.

実験と、フィードバックによる調整

Toshihiro Ichitani All Rights Reserved.

仮説検証とアジャイル
Photo on VisualHunt

仮説とは？
仮説 = 前提 + 仮定 + 期待結果
前提：昨年はある商品の売上が10%伸びた
仮定：リーチしていない顧客はまだまだいるはずでさらに広告投資を50%増やすため
期待結果：今年の売上は20%の伸びは期待できる前提(事実)が少ないほど、仮定の部分が多い(不確実)
前提

仮定

期待結果

前提
仮説
検証

仮定

期待結果

ゆえに仮説検証で仮定(想像)を減らし、前提(事実)を増やす

仮説検証型アジャイル開発
選択の幅最⼤（セットベース）

検証
計画

仮説⽴案
(モデル化)

価値探索（正しいものを探す）

評価

スプリントプ
ランニング

検証

MVP特定

開発計画
(リリースプランニング)

選択の振れ幅最⼩（ポイントベース）

スプリント
開発

アジャイル開発（正しくつくる）
スプリント
レトロスペク
ティブ

MVP検証

スプリント
レビュー

次の検証計画(価値探索)へベースは「リーン製品開発」
リーン製品開発とは、トヨタ製品開発(⽣産⽅式ではない)を源流とする、海外におけるプロダクト開発の⽅法論。
選択肢を広くとり、段階的に絞り込んでいくことで「当たり」を引こうとする考え⽅(セットベース／集合ベース)。
(逆に、最初から決め打ちで⼀点集中する考え⽅をポイントベースと呼ぶ)MVP検証
課題仮説

機能・形態仮説※ 漏⽃が選択肢の幅をイメージしている

MVP特定仮説検証とは働きかける→反応を得る→理解を正す(学ぶ)

働きかける

反応を得る
理解を正す

Copyright Toshihiro Ichitani仮説検証とは働きかける→反応を得る→理解を正す(学ぶ)
具体的に働きかける内容は局⾯や何を得たいかによって決まる。例えば、プロダクトを世の中に提供するユーザーの欲求をユーザーからフィードバック得る

理解し機能を⾒直す

この「⾏って帰って」がターンアラウンド
Copyright Toshihiro Ichitani

何をどのくらい働きかけるのか？
働きかける
反応を得る
理解を正す

ターンアラウンドが⻑いほど、その間プロダクトを間違え続けている可能性がある
その期間中、ムダを積み上げている恐れだからこそターンアラウンドを短くする必要がある
Copyright Toshihiro Ichitani

1段階⽬

ユーザーインタビュー
Probelm-Solutiontの度合いを確かめる

2段階⽬

3段階⽬

プロトタイプを作って検証する
Probelm-Solutiontの度合いを確かめる
MVPを作って検証する
PS tおよびUX tを確かめる

fi

Copyright Toshihiro Ichitani
fififi

段階的なターンアラウンドで早く学びを回収する
ユーザーから反応を得る

ユーザーから反応を得る

ユーザーから反応を得る

段階にすると機動的な判断ができる

ここまでかけないと良し悪しが判断できない
この段階で損切り判断。次の⾏動を最適化「MVPの特定」はターンアラウンド
短縮化の為に⾏う

丸ごと開発

MVP開発
Copyright Toshihiro Ichitani

最も知りたいことにフォーカスするアジャイルは開発内のターンアラウンドを短くするもの
MVP開発

Sprint1

プロダクトバックログを実装する得られたFBへの適応

Sprint2

POや関係者の反応を得る

Sprint3

Sprint4

Sprint5

つまり、全体の段階設計とスクラムによってターンアラウンドが構造化されている
選択と意思決定の可変領域を増やすことで学習への適応⼒を⾼める
Copyright Toshihiro Ichitani仮説検証型アジャイル開発の戦略

分からないことを分かるようにする
分かったことに基づいて、つくる

Photo credit: ilovepics11 on Visualhunt.com / CC BY-NC-ND

仮説検証1周⽬ (target : PS t)
仮定⽴案(仮説キャンバス)

探索的検証(顧客インタビュー)

仮説の修正

仮説検証2周⽬ (target : PS t (被験者にイメージを深めてもらう))
イメージ制作(ストーリーボード等)

イメージを伴う検証(顧客インタビュー)

仮説の修正

仮説検証3周⽬ (target : PS t (被験者に操作関与でイメージを深めてもらう))
操作を伴う検証

プロトタイプ制作(プロトタイプ検証)(No Code Prototyping)

仮説の修正

仮説検証4周⽬ (target : PS t (被験者に利⽤体験してもらい評価する))MVP特定と開発(ユーザー⾏動フロー)

利⽤体験を伴う検証

fifi

fifi

(MVP検証)仮説の修正

仮説には「構造」がある
まず解くべき問いがあり、問いに答える⼿段があり、⼿段を扱えるようにするための形があるか=

本質的な課題=

課題仮説

かた=課題の解決⼿段

=

機能仮説

かたち=⼿段を利⽤可能にする

=

形態仮説

検証⽬的の度合いが異なる

仮説検証1周⽬ (target : PS t)
仮定⽴案(仮説キャンバス)

探索的検証(顧客インタビュー)

仮説の修正

課題仮説

仮説検証2周⽬ (target : PS t (被験者にイメージを深めてもらう))
イメージ制作(ストーリーボード等)

イメージを伴う検証

仮説の修正(顧客インタビュー)

機能仮説

課題仮説

仮説検証3周⽬ (target : PS t (被験者に操作関与でイメージを深めてもらう))
操作を伴う検証

プロトタイプ制作

仮説の修正(プロトタイプ検証)(No Code Prototyping)

機能仮説

課題仮説

仮説検証4周⽬ (target : PS t (被験者に操作関与でイメージを深めてもらう))
MVP特定と開発(ユーザー⾏動フロー)(MVP検証)fififi

機能仮説
fi

課題仮説

利⽤体験を伴う検証

仮説の修正
形態仮説

仮説検証5周⽬ (target : PM t)
UXの推敲
課題仮説

機能仮説

形態仮説

fi

・5周⽬以降に必要となるものは4周⽬の結果に依るが、アーリーなユーザー(課題が切実なため多少の瑕疵を⼤⽬にみれる)から、ユーザーの裾野を広げる⽅向に進む必要がある。
・より「伝える」ことを丁寧に⾏う必要がある。それはPRだけではなく、プロダクトの表現そのものの磨き込みである。
・ユーザーを⾃分たちに宿し、利⽤体験を頭から何度も繰り返しテストし、つっかかりのない「つるつる」を⽬指す（UXの推敲）検証⽬的の度合いが異なる

仮説検証1周⽬ (target : PS t)
仮定⽴案(仮説キャンバス)

探索的検証(顧客インタビュー)

仮説の修正

課題仮説

仮説検証2周⽬ (target : PS t (被験者にイメージを深めてもらう))
イメージ制作(ストーリーボード等)

イメージを伴う検証

仮説の修正(顧客インタビュー)

この繰り返しの中で獲得したい
仮説検証3周⽬ (target : PS t (被験者に操作関与でイメージを深めてもらう))
ものとは何？
機能仮説

課題仮説

操作を伴う検証プロトタイプ制作

仮説の修正(プロトタイプ検証)(No Code Prototyping)

機能仮説

課題仮説

仮説検証4周⽬ (target : PS t (被験者に操作関与でイメージを深めてもらう))
MVP特定と開発(ユーザー⾏動フロー)(MVP検証)

fi

fi

fi

機能仮説
fi

課題仮説

利⽤体験を伴う検証

仮説の修正
形態仮説

構造が tすることによって「価値」が確⽴する
課題
仮説

価値
形態

機能仮説

仮説

この構造が噛み合うパターンをfi仮説検証で確かめにいくユーザーの「反応」で確かめる
ユーザー⾃⾝が事象や状況について確かな理解、⾃覚をしているわけではないので、聞けば分かるものではない。

ゆえに、ユーザーに対する様々な働きかけ(インタビュー、プロトタイプ、MVP)によって、ユーザーのリアルな反応を獲得し、構造を確からしさを得ていく。

②仮説構造を表現する
⼿段を構築（プロトタイプ、MVP)

プロダクトチーム

課題
仮説

形態

機能仮説

仮説

想定ユーザー③検証する（インタビュー、テスト等)

課題？

①仮説⽴てる仮説（仮説キャンバスを使おう)
形態

機能仮説

仮説？

？

④検証結果で仮説構造をアップデートする

課題
仮説（仮説キャンバス)

プロダクトチーム

形態

機能

仮説

仮説

想定ユーザー

課題

？

仮説

形態

機能

仮説

仮説？

？

想定ユーザー

想定ユーザー⑤仮説検証の繰り返しによって確かにしていく(仮説構造→価値構造)

？

？

課題

？

仮説？

？

価

プロダクトチーム

値
形態

機能

仮説

仮説

想定ユーザー

？

課題

？
形態？

機能想定ユーザー

？

？

？

？

仮説検証の繰り返しによって想定ユーザーユーザーの視点(仮説構造)を作り⼿に宿す
課題
仮説

検証によって仮説構造を外在化
形態

機能

仮説

仮説？

課題

プロダクトチーム？

？

プロダクトチーム形態

機能問われるのは

われわれは、どこまで変化に適応できるか？
早く形が⾒える、触れられる
想像⼒頼みから体が使えるだから、圧倒的に学びが増える

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. 実運⽤相当のデータが揃っている

不確実性とは回避するべきものなのか？

不確実性とは、混沌を引き寄せるものであり、プロダクトの未来を変える可能性でもある
明⽇の予定調和が常に明るい未来なわけではない
未来を変えるためにはシナリオ(台本)を変えられる必要がある

Photo credit: occhiovivo on Visual Hunt / CC BY-NC-ND

DXとは、誰にとっても探索の旅（ジャーニー）探索が不要なら、それはトランスフォーメーションとは呼ばないかもしれない（通常業務！）

Toshihiro Ichitani All Rights Reserved.

Photo via Austin Ban via VisualHunt.com

DX 1周⽬
DX 2周⽬

「⼀休さんの屏⾵のトラ」DX
Photo on Visual hunt

「⼀休さんの屏⾵のトラ」DX
⼀周⽬のDXは、「⼀休さんの屏⾵のトラ」で失敗に終わる(1)“DX戦略” が実⾏に繋がらない
密度の⾼い絵とロードマップはあるが、それを実⾏に移す体制・運営（=“作戦”）が存在しない(外部⽀援者に「お絵かき」だけされて逃げられている)(2)DXプロジェクトを⽴ち上げるが遂⾏で失敗する
プロジェクトまでは⽴ち上げるが、狙いも作戦も弱く(⼿ぶらで始める)、「とにかく最初に⽴てた⽅針を達成する」が⽬的となり、次に繋がることがない失敗へと⾄る。
Photo on Visual hunt

探索的な取り組みにおける最⼤の失敗とは何も学べていないこと
Photo credit: Richard Walker Photography on VisualHunt.com / CC BY-NC-ND

DXで直⾯する
困難の本質とは何か？

Photo credit: The Library of Congress on Visualhunt / No known copyright restrictions

本当の困難とは「意識していないこと」への意識
技術適応、アジャイル開発、プロダクトマネジメント、仮説検証、機能するチーム、組織開発、… 必要する⼿⽴ては枚挙にいとまがないだが、それ以上に本質的な困難とは「これまでの組織、事業を⽀えてきた価値判断」そのものへの対峙である。
今まで信じて疑わなかったもの、現に利益を⽣み出す⽅法、考え⽅⾃体を問い直すことへの⾃然な抵抗。
Photo on Visual hunt

変⾰への果敢な取り組みが際⽴たせるもの、それは分断「これまで」と「これから」「既存事業」と「新規事業」「全体」と「詳細」「経営」と「現場」「役割」「職位」「職能」「世代」
Photo credit: aka Quique on VisualHunt.com / CC BY-NC-ND

「これまで」と「これから」の「戦い」にしているうちは、変われない

Photo on Visual Hunt

「アップデート」という概念を⼿放す
これまでの事業、組織 = 1.0
これからの事業、組織 = 2.0
DXとは、1.0から2.0へのアップデートを⾏う活動？
「アップデート」という概念が対⽴を前提としてしまう「これまで」にとって「これから」が「脅威」となり「これから」にとって「これまで」が「仮想敵」になる「アップデート」(更新)ではなく「アライアンス」(提携)
Photo on Visual hunt

⼆項対⽴ではなく⼆項動態(あれかこれか→あれもこれも)

野中郁次郎 ⽒

概念と役割、組織それぞれの独⽴性を保ちながら、繋ぐ「全体」と「詳細」の「同期」「経営」と「現場」の「⼀致」「既存事業」と「新規事業」の「協働」(統合しない、排斥しない、更新対象にしない)
Photo credit: aka Quique on VisualHunt.com / CC BY-NC-ND

DX 1周⽬
DX 2周⽬

DX2周⽬にあたり向き合うべき分断・垂直上の分断・⽔平上の分断

Photo credit: aka Quique on VisualHunt.com / CC BY-NC-ND

垂直上の分断
・経営と現場の⽅向性は⼀致しているが、その間での状況同期が出来ていない
DX推進
プロジェクト(情報の解像度に⼤きな差があり頻度⾼めるには運⽤困難)

・経営と現場を繋ぐのがミドル。
そのMiddleと他との⽅向性が合っていない(結果的にミドルが抵抗勢⼒化している)総論DXで⼀致していたとしても、個別⽬の前のPJとしては従来どおりの判断をしてしまう問題 (現在指向バイアス)

個別PJで解決できない全社課題をCoEに集める
個別PJから全社⽅針に影響を与える課題を切り離す。
例えば、採⽤する技術、リソースマネジメント、プロセス変更、新たなスキルを獲得するための教育プラン等。
組織やチーム横断のメタ的なチーム(CoE/Center of Excellence)を結成する。

経営課題
CoE (Center of Excellence)
プロジェクト

既存組織

全社課題
バックログ

経営⼈材 ミドル現場

CoEを外部に丸ごと任せる…絶対にヤメル
良くわからないので、CoEをほぼ丸ごと外部の指⽰のもと作る、あるいは、外部に丸ごと預けてしまう⾸根っこを外部に渡すようなもの。

「⼀休さんの屏⾵のトラ」DXへまっしぐら

Photo on Visual hunt

⽔平上の分断・DX推進と既存事業の戦略や状況同期、資源 (⼈、ノウハウ、データ等) 共有に関する分断・当然「戦略の重複」や「資源の部分最適」といった組織の経営課題に転じる

変⾰(DX推進)を部分(出島)で切り離せば離すほど、既存との分断は深まる。結果的に孤⽴し成果に結実しない新規と既存の間を⾏き来する機動性を確保する
新規と既存の分断も全社課題。メタチーム(CoE)にて扱う。
具体的には、CoEに専⾨⼈材を集め、適宜両事業への働きかけを⾏う。
両者に関わることで、その間での資源・情報の共有化を橋渡しする。
求められる⼈材は希少性が⾼いため、部分配置ではなく結集させる。
(新規と既存の両⽅に関わる「CoEの両利き化」)
本⼟
既存事業

出島DX推進経営⼈材

両利きのチーム両利きのチームをアジャイルに運営する
・両利きチーム(CoE)と各現場・プロジェクトのバックログを分ける。
- 「プロジェクト・プロダクトのバックログ」と「全社課題」
・両利きチーム(CoE)⾃体を「スプリント」で運営する。
プロジェクト(新規）フィードバック

両利きのチーム(CoE)

施策と⼈材
全社課題
バックログ

(既存）

(…）

両利きのチーム + アジャイルな運営

アジャイル ブリゲード
対⽴する⼆項を組織の構造と仕組みによって繋ぐ

Photo credit: Israel Defense Forces on Visual hunt / CC BY-NC

アジャイル ブリゲードの構成
内部と外部の専⾨⼈材で混成チームを⽴ち上げる
アジャイル ブリゲード

全社課題
バックログ
(DX戦略)(経営と現場の⼀致)

・必要で不⾜する専⾨性は外部から取り込む- 仮説検証経営⼈材(CDO)(全体と詳細の同期)

段階と断⾯によるマネジメント（フラクタルなアジャイル）

to credit: Israel Defense Forces on Visual hunt / CC BY-NC

ミドル

現場領域A

領域B

専⾨⼈材 専⾨⼈材(新規と既存の協働)

新規事業への専⾨性提供
既存事業への専⾨性提供- プロダクトマネジメント- アジャイル開発- クラウド / IoT / AI /BC etc

・運営の舵取りは内部⼈材がコミットしてあたる※ただし運営⾃体がアジャイルな為適切な専⾨⼈材とともに取り組む

「専⾨性」が組織の分断を繋ぐ
なぜアジャイルブリゲードが成り⽴つのか？
・コロナ禍によって既存事業の業務⾃体が再定義されている(DX)・技術、プロセス、マインドなど、DXに必要な専⾨性は数多くある→ 新たな専⾨性獲得・利⽤へのニーズは新規・既存問わず⾼い

アジャイルブリゲードがニーズに応える形で組織内を⾏き来することで専⾨性とともに、事業間の意思や意図も伝播させる(だからこそ専⾨⼈材だけではなく、戦略を動かす為に経営⼈材の関与が不可⽋)越境

組織を越えること、これまでに囚われないこと

Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC

Toshihiro Ichitani All Rights Reserved.

「ともに取り組む」ことで新たな「WHY」「HOW」が伝播する
新たな「WHY」
・不確実な状況に取り組む際のスタイルとして「探索」
・正解が無い = ⾃分たち⾃⾝で問い続けるしかない「われわれはなぜここにいるのか？」「われわれは何者なのか？」「正しいものを正しくつくれているか？」
新たな「HOW」
・仮説検証型アジャイル開発をともに辿ることで学ぶ・状況によっては「チーム開発」「仕事のやり⽅のモダン化」からともに取り組むとは、同じ⽅向をともに⾒ているということ
Photo credit: lensnmatter on VisualHunt.com / CC BY-SA

Start with Why

⾏為から学ぶ

価値観

価値観

原則

原則

⾏動

⾏動

何のために(価値観)、どうやって(原則)、やるか(⾏動)型から⼊って、実際にやってみるやってみる(⾏動)過程と結果から、だから、価値観をあわせるのが⼤事！
…⼤事だけど、容易ではない。

何が⼤事なのかを学び直す(原則)
その学びをより良くするためには？(価値観)「伴⾛」の存在によって「学び直し」を逃さない

ふりかえり
むきなおり
⼩さな型

伴⾛の必要なところ

アジャイルによってアジャイルになる
Be agile by Agile

Photo on VisualHunt⼤企業、地域企業、そして国におけるトランスフォーメーションは２周⽬のこれからが勝負のトラック

Photo credit: Israel Defense Forces on Visualhunt.com / CC BY-NC

Toshihiro Ichitani All Rights Reserved.

Transformの課題は尽きない

Photo on Visual hunt

⼤企業、伝統的な組織ほど求められる変⾰の「求⼼⼒」
多くの⼈々が変⾰の⽅向性をあわせながら進むにはハコ（組織）さえあれば良いわけではない。
中⾝(⼈)は変わっていないのだから。
迷わず活動を続けるための「⽬印」がいる。すなわち求⼼⼒。
では、求⼼⼒とは？
カリスマの存在？（いるの？）
⽂化？（いますぐ？）ルール？（まさか！）Photo on Visual huntDXを必要としない組織は既にDXだ

Photo credit: RaSeLaSeD - Il Pinguino on Visualhunt / CC BY-SA

Startup
つまり、中⼼にProductとTeamがある組織

Photo credit: startupphotos on VisualHunt.com / CC BY

プロダクトファーストで組織変⾰を牽引する「顧客体験を変えるためのプロダクト作り」
﹅﹅﹅﹅﹅

﹅

だけではなく「⾃分たち⾃⾝を変えるためのプロダクト作り」へ

Photo credit: [-ChristiaN-] on VisualHunt.com / CC BY-NC-ND

DX (組織変⾰) を巡る旅は「プロダクトを作り、中⼼に据えよ」というシンプルな教えにたどり着いた

Photo credit: myfrozenlife on VisualHunt / CC BY-NC-ND

…これってさ、われわれがこれまでも追い求めたことじゃないかプロダクトを作り、世に問おう。

Photo credit: [-ChristiaN-] on VisualHunt.com / CC BY-NC-ND

⼿を動かそう。
それが「組織」を変えるすべになる。

Photo credit: nunodantas on Visualhunt.com / CC BY-NC-SA⼿を動かそう。
窺うのは組織の中の顔⾊ではなく伺うのはプロダクトを届ける相⼿だ

Photo on Visual hunt

⼿を動かそう。
「未来」を変える可能性は、その指先にかかっている。

Photo credit: Leo P. Hidalgo (@yompyz) on VisualHunt / CC BY-NC-SA「プロダクト」を作り、世に問おう。

flPhoto credit: In Memoriam: saschapoh epp on VisualHunt / CC BY

ともに、ジャーニーにしませんか
Photo on Visual hunt