2. Design Thinking
はじめに
今回は、Design Thinking を取り上げます。
日本語では、”デザイン思考”と呼ばれているものです。言葉と概要はなんとなく知っていたのですが、今回は、ちゃんとその本質を知りたくて、
の二冊を読んでみました。読んだのもこの順番。偶々一冊目を見つけて読んで、一冊目のタイトルに”2.0”がついているので、ってことは、「そもそもの”デザイン思考”って何？」ということで、二冊目も購入した次第。
何故 Design Thinking ？
そもそもなんで”Design Thinking”に興味を持ったかというと、
という公開記事、これは、日曜大工的な IoT ではなく、エンタープライズレベルの IoT・Digital Twins ソリューションの構築に当たって押さえておくべきポイントをまとめた記事なのですが、その中で、
こんな問いかけの話をしていて、何故、こんな問いかけをしているかというと、
と、IoT・Digital Twins（それらが実現できたうえでの DX）の位置付けを説明していて、しかし、それだと、”目指す姿”と”現在の姿”が、先ず、明確になっている必要があり、後者は、IoT・Digital Twins で何とかなるにしても（ここも実際は結構色々と考えないといけないのだが）、前者を明確化する手段が別に必要になる訳です。
先ず、IoT・Digital Twins を導入する組織がトップダウン的に”目指す姿”を設定する場合を考えてみます。
実際の話、そのレベルでの”目指す姿”は抽象的だったり雰囲気的だったり、組織のトップが実のあるビジネス上の”目指す姿”を定義するのも、今の時代、実は大変で、そもそもの ”Design Thinking” の活用どころはここだったりするわけですね。
幸運にも明確に記述された”目指す姿”が描かれたとしても、それはそれで、ビジネスの話なので、IoT・Digital Twins の実装を行うレベルの現場のコンテキストとは意味的に乖離しているのが普通なので、案外、抽象的だったり雰囲気的だったりする上位の”目指す姿”の場合と、状況はそれほど変わらないでしょう。明確・不明確にかかわらず、IoT・Digital Twins ソリューションの構築をはじめるにあたっては、IoT・Digital Twins の提供対象に即した”目指す姿”の定義が必要です。
次に、組織内の現場部門の意思で IoT・Digital Twins を導入する場合を考えてみます。
このケースでは、問題意識の高い個人が自らネット上の記事や書籍、外部のイベントなどで得た知識を実践してみたいというのがきっかけにはじまる事が多い印象です。他には、問題意識を持った部門長から改善タスクを仰せつかった担当者（あるいは担当チーム）が、あれこれ調べて、新規技術の導入活動を開始する場合ももちろんあるでしょう。どちらにしろ、新規技術導入推進担当者はｍ、組織内の他のメンバー達の理解と、上位層の活動に対する承認と活動予算を得ることが必須です。そのためには、実践の結果（実践の内容ではないことに注意）得られる成果を指標化し、現場部門、もしくは、組織全体の目指す姿にアラインするものであることを明示しなければなりません。
自分がやりたいことと組織の活動方針がぶつかることは、よくある事ではないでしょうか。
組織の一員としての活動である以上、各個人のやりたいことが、組織全体の目的にアラインしている事を「その人自身が説明できること」はとても重要です。もし、説明できない、あるいは説明しないなら、そのやりたいことを実現する為の活動の中身がどんなに素晴らしくても、事情をよく知らない他者からは、組織が別に使うべきリソースを浪費しているとしか思われません。
私の経験によれば、よほどの特殊なやり方でない限り、アラインさせる方便は、色々と考えつくものです。考えつかなければ、転職や起業を考えるべきでしょう。
各個人がやりたいことを上位の”目指す姿”にアラインさせる過程で、組織の上位層の”目指す姿”に対する、現場部門のコンテキストからの指標の明確化も同時に行うことになります。この作業では、ある程度明確な数字の指標があれば、それを元にした”Logical Thinking”と明示化されていない潜在的な欲求を掘り起こす”Design Thinking”の組合せが役立つのではないでしょうか。
組織のトップ層からのトップダウンと、現場部門からのボトムアップ、どちらについても、結局のところ、新規技術導入を実践する現場部門から見た、”目指す姿”の明確化と指標化が必要になる訳です。
著者が過去に行った組込み制御ソフトウェア開発の開発プロセス改善や、IoT・Digital Twins の導入支援の経験から、この「現場部門から見た、”目指す姿”の明確化と指標化」は、実際にやろうとすると、色々な理由で難しい作業であるなと、ずっと思っていて、何かいいやり方は無いものか、模索を続けてきました。
ちょっと長くなりましたが、この作業にも、”Design Thinking” が役に立つのではないか、と今回考えたわけです。
”Design Thinking”というと、企業など組織が外部に提供する新しい商品やサービスの立案で使われると思っている読者も多いのかなとは思いますが、組織内でも、各個人の仕事の成果は、組織内外の他者に提供するので、”Design Thinking”の本質的な特徴を考えれば、十分役立ち、むしろ、1を1.x になりがちな”Logical Thinking”よりも、0を1に、あるいは、1を100にする ”Design Thinking”の方が、折角試すなら、より効果の高い方が試し甲斐があるんじゃないかと、思った次第。
さらに言えば、”現在の姿”も、組織内の個人・個人がいろいろ思うところはあっても、案外正確に把握している人がそんなに多くいるとは、私の経験上思えません。今手元にあるデータを基にした”Logical Thinking” も大事ですが、現場の潜在的なニーズを可視化するという ”Design Thinking” により潜在意識で感じている事の表層化と、IoT による現実世界から収集した客観的なデータを併せての”現状の姿”の可視化で有効なんじゃないかなと。
Design Thinking 概要
「デザイン思考2.0」は、2.0 とついていて、一般的な”Design Thinking”の改良版という位置づけで、何が改良なのかは、皆さんに読んでもらう事にします。
この本の P34 ～38に、”Design Thinking”のステップが書かれています。抜き出すと、
※（）は、「デザイン、アート、イノベーション」のP8 図表1-1の用語
共感（共感/理解） ⇒ 相手の立場になりきる
問題定義（定義/明確化） ⇒ インサイト（本音）を発見する
創造（アイデア造り） ⇒ 問題解決のアイデアを出す
プロトタイプ ⇒ イメージ、認識を共有できるものを作る
テスト ⇒ フィードバックを受ける
このステップは、一回回したら終わりではなく、このサイクルを何度も回していく事になります。それぞれの詳細は、「デザイン思考2.0」を読んでもらう事にします。
「デザイン、アート、イノベーション」のP13によれば、”Design Thinking”で重要なのは、ユーザーも自社も気づいていない”未知の窓”を見つけること（「デザイン思考2.0」では”潜在ニーズ”）だそうです。そのための共感であり、インサイトの発見であり、プロトタイピングによるお試しなわけですね。繰り返しになりますが、”Design Thinking” は、ユーザーすらも明確には認識していない新しい商品、サービスを考案することが目的なので、ユーザーへの一般的なアンケート調査は機能せず、加えて過去の事例がないことからそれに関するデータも無いので、”Logical Thinking” も機能しないということで、ユーザーになり（共感）きって、プロトタイプを作って実際に使ってもらってフィードバックを得ることがポイントであるというわけですね。
私が公開している「IoT・Digital Twins 最初の一歩」でも、IoT・Digital Twins の導入は、一回ソリューションを作ってお終いではなく、一回目の実装による結果が、その時点での”現在の姿”になり、その時点では”目指す姿”は変わっているはずなので、継続的な改善が続くと説明していて、単に、”目指す姿”を明確化するステップだけでなく、全体が ”Design Thinking”のステップと似た感じになっていました。
そういう意味では、前述の ”Design Thinking”の1～3のステップが IoT・Digital Twins のソリューション構築の前段階で、4. の”プロトタイプ”が、IoT・Digital Twins ソリューションの実装、5. の”テスト”が実装したソリューションの運用にあたると考えるといいのではないでしょうか。
”Design Thinking”を IoT・Digital Twins の様な IT ソリューションに適用する場合には注意が必要と思っています。前述の 1.～5. のステップを単純に回して一貫性なく機能を実装していってしまうと、IT ソリューションがオンボロ煙突化してしまうのは容易に想像がつきます。
この事態を避ける有効な手段として、「IoT・Digital Twins 最初の一歩」で解説している、”アーキテクチャ駆動型開発”が有効です。最初の数回のラウンドは、潜在ニーズの発掘から想定されるユーザー数やデータ量（IoT・Digital Twins の場合はそもそもがビッグデータ系のソリューション）を元にしたソリューションのアーキテクチャの確立に力を注ぎ、以降のラウンドで表出する潜在ニーズを、そのアーキテクチャ基盤上にシナリオとして実装していくスタイルがおすすめです。このやり方は、大きなシステムを造る際の鉄則の”小さく始めて大きく育てる”にも適っています。
Design Thinking を使いこなすために
IoT・Digital Twins ソリューションの開発に限らず、新しい商品・サービスの構築では、様々な手法が適用されるのが常でしょう。いくら、”Design Thinking”が良いやり方らしいからと言って、教条主義的に ”Design Thinking”だけを厳格に適用したところで、うまくいくとは限りません。
”Design Thinking” に限らず、多くのビジネス書に載っている様々なやり方の例は、大抵の場合、外部の人間が観察した結果の後付けです。
「デザイン、アート、イノベーション」では、”Design Thinking”が生まれてきた過去の経緯と各ステップに対する批判的見解、それに対する回答が解説されているので非常に参考になります。
この本では、”Design Thinking” の一番手として、”DDI（Design Driven Inovation”が、多くの事例と共に紹介されています。
例として面白かったのが、”Design Thinking”の実例としてよく取り上げられるスティーブジョブスのiPhone開発のプロセスが、実は、マイクロソフトのビジネス戦略に影響を受けた”Logical Thinking”に近いものだった、という例です。もちろん、スティーブジョブスの ”Design Thinking”的な発想もあったのでしょうが、ビジネス書に載っている事例に対する解釈と実際が異なるのが普通であり、読者は、そこからエッセンスを抜き出して自分の頭で何がキーポイントだったのかを考えることが重要なんでしょうね。
共感を得るにも問題を定義するにも、対象の観察が重要。観察では、以下の試行の流れを行ったり来たりを繰り返す。
デザインとは、”デザイナー”が行うものとすれば、元々”デザイナー”が暗黙的・明示的に行っていた活動が”Design Thinking”に反映されている？
DDI と従来型の改革は、下図のような関係にあるとのこと。
”Design Thinking”も含め、何かの手法を組織として実践する場合は、実践する個人のスキル（技法だけでなく、態度、心構えも含め）獲得だけでなく、組織として新しい手法を有効に実践する為のマネジメントも必要になります。
「デザイン、アート、イノベーション」では、その辺の解説もあるので参考になりました。
個人的熱意から始まった改善・改革活動を運よく始められて一定の効果が出たとしても、組織全体にそれを波及して定着させるのって、滅茶苦茶大変なんだよね…組織のカラーにもよるんだろうけどね…
Design Thinking に対する不満
”Design Thinking” に限った話ではないのですが、大抵のこの手の手法は、やるべき事とその順序は説明されていても、各ステップで表出させる成果物の表記法に関する説明はほとんどないのが、私が常々抱いている不満です。
複数人で作業を行っている場合には、その成果を共有する為の”記述”が必要です。”記述”には、何らかの”記法”が必要なはず。さらに言えば、複雑怪奇な現実世界を”分離”する手段（ガイド？）も必要。そんなことを、「Art of Conceptual Modeling」の体得者である著者は自然に思ってしまうんですよ。ちなみに、”記述”という言葉は、”言語化”と同義で使っています。”言語化”を等して潜在ニーズは顕在化する訳ですが、普通のテキスト文は曖昧性を含んでいるので、テキスト化する場合でも、曖昧さを排除したい場合は、何らかの”形式”が必要です。
…だってさ、記法が揃ってなかったら、それを見たい人それぞれの解釈がうまれてしまうんじゃない？ん？”Design Thinking”ならそれもまた良いことなのか？記述した本人も気づいていない潜在意識に気がつくという意味では…
まあね、私は原理主義者ではないので、どの記法がベストかは生み出すそれぞれの特性に拠るので、記法を限定しない事で、その手法の適用範囲が広がるという事は重々理解した上での話なのですが。
このあたりのトピックは、「デザイン、アート、イノベーション」の P59「Ⅱ意味への注目について」と P85「補題③記号論について」が参考になりました。
いずれ、この辺りのトピックについては、圏論（Category Theory）で数学的に記述・理解できるのではないかという目星はついているのですが。「Art of Conceptual Modeling」で解説している概念モデルの意味論が、それぞれのケースで最適な記法の意味論と同型ならば、概念モデリングがいかなる問題の記述にも有効ではないかというのが今の私の見解。
最後に
不満も含め色々と書いてきましたが、”Design Thinking”そのものの詳細は、各自、ここで紹介した2冊を含め、色々と探して読んで理解を深めて呉れれば幸いです。
「デザイン思考2.0」に出てくる、UX：User Experience の話、2010年近辺にやっていた、WPF や、 Windows Phone、Windows 8 の Store Appの普及啓発活動を思い出しました。私の屋号にも使っている Experience、日本語では、”体験”という言葉を使っていて、単なる機能ではなく、”Experience”が重要なんだと、耳にタコができるくらい聞いたし、口にタコができるくらい言ったなぁ…と同時に、その後、上司からは”Story”で語る事が重要だと何度も何度も教えを受けました。ユーザーの潜在ニーズを探る時に必要な”共感”と”問題定義”、担当者がそれを行った後の具現化では、当然、第三者に対して、”共感”してもらうことと定義した”問題”を理解してもらわなければ先に進めません。”Story”で考えて”共感”を深め”問題”を定義する、”Story”で第三者に”共感”してもらって”問題”を理解してもらう、”Story”って大事だよなと、改めて思った次第。
個人的には、”Design Thinking”、結構便利そうなので、先ずは、内省的に適用を進めて、実践レベルになったら、プロっぽい顔して、こうやればいいんだよ的なコンテンツを作ってみようと思ってます。
この記事が気に入ったらサポートをしてみませんか？