トランスフォーメーションを阻む3つの壁

巷ではさまざまな“トランスフォーメーション”が言われている。

DX（デジタル・トランスフォーメーション）から、CX（コーポレート・トランスフォーメーション）さらにはSX（サステナビリティ・トランスフォーメーション）まで、ちょっと前まで「X」といえば“エクスペリエンス”だったはずなのに。

さておき、日本において、それらトランスフォーメーションの取り組みが遅れていると言われつつも、様々な企業や組織、団体のお手伝いをさせていただく機会は増えている。

デザインコンサルティングチームの一員として、Design Strategistを名乗り、Innovation Catalystとして果たすべき役割をまっとうすべく、日々もがく人間の頭の整理を、自己や自組織の批判的視点も交えて考えていきたい。
今回はそのプロローグとしての概要エントリとなる。

3つの壁

様々な企業や組織の方々とともにトランスフォーメーションを進めるにあたって、タイトルにあるとおり大きく3つの壁を実感している。

（トランスフォーメーションを阻む3つの壁）

最初の壁は、「問題意識（危機感）」である。
たとえ「どこもかしこもDXって言っているからやらねば」というフワフワしたキッカケであれ取り組もうとすることが重要だと思う。全社的なバックアップのもと正規軍としてスタートできなかったとしても、組織内個人としてでも行動を起こすことは最初の第一歩といえる。キッカケはどうであれ、内発的な動機として高めていける機会と環境作りが求められる。この壁は、すでに多くの組織内で共有され、様々なプログラムや学習機会が提供されており、乗り越えやすい（乗り越えている）のではないかと思う。

どの方向にどうやって踏み出すかというHOWに悩まれるケースが多いので、まずはなぜ取り組むのかというWHYまで突き詰めて共有可能なカタチにする必要がある。

次の壁は「日常回帰」である。
たとえ一人でも問題意識を持って、内発的動機を高められたとしても、日々の仕事において（たとえ少しでも）実践することができなければ、“お勉強”で終わってしまう。実践する場を作り、持続的に運用する必要がある。その“持続的な運用”を実現するひとつのアプローチとして「DesignOps」が注目され、（デザイン経営に取り組む）様々な企業で実践されている。これは、ソフトウェア開発と運用をフレキシブルに連携する手法のひとつであるDevOpsのデザイナー版である。

Invisionというデザイン会社が「Design Ops Handbook」としてベストプラクティスを紹介しており、著者のひとりであるDave Maloufさん曰く

デザイナーの思考をこれまでのCraft（職人的）からOperations（運用）の思考へ変えなくてはいけない

とインタビューで答えている。

その中身としては「ワークフロー」「人材」「ガバナンス」「ツール／インフラ」の4つの要素で構成されている。詳しくは検索いただきつつ、このシリーズでも自分なりに解釈していきたい。

最後の壁は「事業化」である。
キッカケはさておき内発的動機から事業デザインを経て、評価（収益）を得るステップである。この壁へのチャレンジについては、正直なところ、現在の我々には直接的で有効なケイパビリティはほぼないといえる。実際の現場では、このステップに至ったプロジェクトは事業会社内での活動として巻き取られる。スムーズに進むような質の高いアウトプット（事業サイドにとってはインプットとなる）を出すことは当然として、継続的にコミットして価値を出すことがままならないのが現実であり、非常に歯がゆい。

意味のイノベーション

さておき、この3つの壁を超えていくプロセスとして、イタリア・ミラノ工科大のロベルト・ベルガンティ教授が提唱する「意味のイノベーション」（課題解決HOWから始めるのではなく、その意味WHYから始めること）のプロセスを重ねると以下のようになる。

（意味のイノベーションプロセスを追加した図）

最初の壁は、内発を促す学習とスパーリング相手によって、次は社外のラディカルサークルのみならず、社内の仲間作りによって、最後の壁は様々な解釈者を経て、人々（この場合にはユーザーとしての人々のみならず、事業部門や製造など企業内の人々も含まれるだろう）に届けることによって超えていくのだろう。

我々が考えるデザインプロセス

我々デザインチームでは、問いの立て直しを繰り返して深化させ、蓄積されたツールやメソッドによって変化（アウトカム）を得るという3つのレイヤーでプロセスを整理し、日々実践している。

（Design as R&D スパイラル）

ビジョンメイキング（Proof of Vision）から、何らかのカタチにするPoCを経て、事業化につなげるという上記のようなプロセスを「Design as R&Dスパイラル」と称して、実践知として得られたナレッジを、ツールやプログラムとして形式知に還元するべく取り組んでいる。

#ご興味おありの方はコチラから資料をダウンロード（要フォーム入力）いただけます。

紺屋の白袴、ならば好きな色に染めちゃおう

デザインチームとして、Design Strategistとして、まだまだ取り組めていないことは多く、偉そうなことをいえた立場ではない。とくにDesignOpsについては入り口に立った程度である。その歩みを進めるためにも、リサーチと解釈、その実践をするとともに、さらに研鑽すべく自己批判する意味合いも込めて、エントリを続けていきたいと思う。