「理屈は分かった。でも実際に取り組むのは不安だ」 そんなあなたに事例を紹介：脱「丸投げDX」のための「デザイン思考」の使い方（4）（1/2 ページ）

DX推進の場面で有効とされる「デザイン思考」。そこで用いられる手法は日々の業務にも役立つものだ。本稿は具体例な応用・実践方法を事例で紹介する。

[小原 誠，ITmedia]

　本連載では「DX」（デジタルトランスフォーメーション）を自分事として推進するために「デザイン思考」を紹介してきました。

　連載第1回は「変革を『自分ごと』として考えて小さな成功体験を積み重ね、『より大きな変革の流れ』を作る場面」でデザイン思考が有用な対話手法になると紹介しました。連載第2回は基礎知識としてデザイン思考で議論を進めるときの基本的な流れを、連載第3回は具体的な議論手法を解説しました。

　連載最終回となる第4回は、筆者がこれまで行ってきたコンサルティングプロジェクトやワークショップなどの事例を紹介し、デザイン思考がどのように日々の業務で活躍するのかを紹介します。

この連載について

　昨今、DXの文脈でも耳にすることが増えてきた「デザイン思考」という考え方。一方で、「新たな事業アイデアの発想やユーザー体験（UX）を設計する人たちが使う特殊な考え方」として捉えられがちです。本連載は、筆者が元コンサルタントとして得た経験をふまえながら、デザイン思考（Design Thinking）を身近な思考法として紹介します。

筆者紹介：小原 誠（ネットアップ合同会社　シニアソリューションアーキテクト）

国内メーカーにおけるストレージ要素技術の研究開発に始まり、外資系コンサルティングファームにおけるITインフラ戦略立案からトランスフォーメーション（要件定義、設計構築、運用改善、PMO等）まで、計20年以上従事。ネットアップではソリューションアーキテクトとして、特にCloudOps、FinOps領域を中心にソリューション開発やマーケティング活動、導入支援等に従事。FinOps認定プラクティショナー（FOCP）。国立大学法人山口大学 客員准教授。

事例1：製造業A社におけるクラウド化推進チームの構想検討

　国内大手の製造業A社では、本社が情報システムの企画管理を、情報システム子会社が開発と運用保守を担っており、最高情報責任者（CIO）の号令の下、情報システムをパブリッククラウドで刷新することになりました。クラウド化の推進には、情報システムのアーキテクチャだけではなく各種規定や手続き、役割分担なども変革する必要があり、社内で動揺や反発が起こりました。

　そこでA社は、クラウド化を推進する組織横断的なチーム「クラウドCoE」（CCoE：Cloud Center of Excellence）を立ち上げ、筆者はコンサルタントとして構想検討を支援しました。このプロジェクトで筆者は、議論と合意形成の進め方にデザイン思考を取り入れました。このときの進め方の特徴を3つ紹介します。

特徴1：顧客が主役　コンサルタントは脇役

　一般的にコンサルタントが構想検討を支援すると、コンサルタントを中心に仮説思考で論点を整理し、現状把握や問題整理、将来像とそこに向けた施策提言を行います。そこでは「論理的な正しさ」が重視され、週次の会議などでコンサルタントが考えを顧客に提示し議論を重ね、合意形成します。その後、ステアリングコミッティや最終報告会の場でエグゼクティブ向けに報告し、意思決定を得ます。

　この過程でありがちなのは「顧客が合意しているが腹落ちしていない」というもので、最終報告会で合意がひっくり返ったり、実行段階になって物事が進まなくなったりします。

　どれだけコンサルタントが論理的に正しい（と思える）構想を立てても、実行に結び付かなければ意味がありません。事業を担う人たちが「やりたい」と思えなければ、自走して変革を回すことは困難です。

　筆者には「今後CCoEを担っていく顧客自身が議論や意思決定を積み重ねていけるようにしたい」という気持ちがあり、このプロジェクトでデザイン思考を使いました。

　数カ月に渡る議論では、連載第3回にご紹介した「Rose, Thorn, Bud」によるクラウド化に向けた「期待」「懸念」「不安」といった思いの共有に加え、「How Might We」形式での問題定義と「Abstraction Laddering」による問題定義の見直し、「Round Robin」による具体的な施策の発想などさまざまな手法を用いました。

　コンサルタントは複数回からなる議論の落とし所を想定し、デザイン思考のどの手法をどのように使うかを設計します。各回の議論に必要な入力情報、例えばCCoEの事例や議論の取っ掛かりとなる論点などを事前に整理し、議論ではファシリテーター（進行役）として「気付き」を与える問いかけを行います。各回の最後には認識のすり合わせやアクションアイテムの整理などを行い、付箋紙などに書き出された意見を次の会議で素早く参照できるように構造化しながら整理します。

　デザイン思考を用いて顧客が中心となり議論と合意形成を進める中で、顧客側にも一体感が生まれ議論が「自分事化」します。また、スピード感を持って物事を議論し決定していく繰り返しが「自信」にもつながりました。

特徴2：仲間の輪を広げる

　構想検討の議論はCCoEの担当者数人と数カ月にわたって行い、締めくくりにはCCoE主催でアプリケーション部門やインフラ部門から数十名を集めてデザイン思考を用いたワークショップを行いました。

　ワークショップではCCoEの担当者が各テーブルのファシリテーターとして議論をリードします。このようなアプローチを採用した理由は2つあり、1つ目は「CCoEとアプリケーション部門、インフラ部門で思いを共有し、同じ目標に向かって進んでいく雰囲気を醸成するため」、2つ目は「コンサルタントが離れた後もCCoEの担当者が自走して仲間の輪を広げられるようにスキルトランスファーを行うため」です。

特徴3：顧客が報告

　エグゼクティブ向けの最終報告会もCCoEの担当者が行い、筆者はコンサルタントとして準備を支援しました。ここまで自分たちが議論した内容を自分の言葉として説明することで“覚悟”が決まり、エグゼクティブとの対話を通じて理解や協力を得ます。その結果、コンサルタントが去ったあとの実行段階にスムーズに移行できます。

　このプロジェクトでは「施策の論理的な正しさ」よりも、「手作りで顧客が納得、自分事化でき、それが変革につながっていく」ことを重視しました。道具は適材適所で使うべきで、このような局面でデザイン思考は有用です。