非デザイン話のデザインシンキングとダブルダイヤモンドモデルの運用例について

今回は一側面からビジネスにおけるデザインシンキングについてお話ししたいと思う。質問式で進んでいくつもりで、まずこの質問から一緒に見てみよう：

クライアントのご要望を100%対応したのに、なぜリリース後に多くのエンドユーザーに使ってもらえないんだろう？

　よく見かけるケースだが、いまだになくならないメインの理由はとてもシンプル ーー 根本的なニーズは提示し切れていなかったため、それらに応えようもなかったからだ。もう一歩踏み込んで言うと、① 特にソフトウェアの場合、一部マイクロ型のものを除いて、製品やサービスが出来上がっていない状態の時、特に要求を定義する段階では、クライアントも誰も最終的な形をはっきりとイメージすることは難しい；② 製品/サービスを作る元々の一番の動機と言える「ある問題を解決する、あるニーズを満たさせる」の中の「ある問題」や「あるニーズ」は、発足側としても最初から完全に把握し切れていないケースが多い、の二つの原因がまず考えられると思う。

　個人ユーザーも上述のクライアントと同然。ーー 13年前、ジョブスがiPhoneを世の中の人々に届けるまでは、恐らくほとんどの人が「こういう製品が欲しかった」と意識する機会さえもなかったのだろう。 

　クライアントの要望は、製品作りのためのインプットの一部でしかなく、その他の必要なインプットは共創思想を基にして一緒に定義していかなければならない。それに必要なのは、今回ご紹介するデザインシンキングである。 特に冒頭の質問のような悩みを抱えている方は、この文章を最後まで読んでいってほしい。

デザインシンキングは何の価値を我々に提供してくれるのか？

　上述の続きとして、まず受託開発の現場をこれから展開する話の背景として設定しておくことにしよう。発注側のクライアントから要求をもらった後、いかに早くその要求を満たすためのソリューションを提供できるのかではなく、そもそもその要求は正しいものかどうか、要求の裏にある背景から潜在的な別の問題点やニーズが考えられないのか、と考えることが大事。デザインシンキングはまさに、ソリューションを考える前に、まず問題を正しく定義することから問題解決のアプローチを導いてくれる考え方なのである。

そもそもデザインシンキングとは？

　デザインシンキングはデザイン思考とも言い、元々はデザイナーがデザインを行う過程で用いる特有の認知的活動のことを指している(注1)が、一意的な定義を有する方法論というより、人間中心思考(下述あり)をベースにした実践的且つ創造的な、問題解決を目的とする一種のマインドセットとも言えるのだろう。ただし、デザイン分野の思考法だと断言しようとしたら、実はそうでもないということをまず覚えておこう。そして、タイトル通りに、今回お話しするデザインシンキングはデザイン分野の話というより、クライアントが抱えている問題や課題の解決に導くためのデザインシンキングなのだ。

なぜ「デザイン」シンキングと言いながら非デザインの話しができるのか？

　「デザイン」といえば、普遍的な意味では視覚的というイメージが強く、実際にデザインシンキングの起源を探求してみると、確かに「視覚的思考の経験（Experiences in Visual Thinking）」というデザイン工学分野の著作の中の「表現 - テスト - サイクル」というデザイン過程でよく用いられているコア的な手法が挙げられ(注2)、この手法が視覚的思考の経験から生み出されたということから、デザイン思考の先駆的考え方の大元の一つは視覚的思考だと言っても過言ではない。そこから十数年経って更に進化して生み出されたのはデザインシンキングというわけだ。

　では、なぜこの視覚要素に富んだデザイン分野から生み出されたデザインシンキングは非デザインの分野でも多く活用されているのだろうか？ ーー もう一度大元の一つである「表現 - テスト - サイクル」というプロセス（一説によると「観察 - 表現 - テスト - 改善サイクル」ともされる）を振り返ってみよう。デザイナーは言語化しづらい大まかな元要求に対して、まず要求者その人になりすまして(共感)、客観的に要求の背景に対して観察を行い、そして非言語化/符号化のメモやスケッチなどの表現を繰り返すことで、顕在的な問題はもちろん、潜在的な問題や要求も発見し、ソリューションズを考え、プロトタイプに起こし、要求者や対象ユーザーに提示した上で、元の要求と潜在的な要求を基に評価が行われ、その評価結果に基づいて改善のサイクルを回す、という流儀が存在していて、この中から、三つのポイントを取り上げられると思う：

・人間中心思考
・プロトタイプ
・改善サイクル

　人間中心思考とは、投げられてきた元要求そのものに焦点を当てずに、代わりに要求者という人間に焦点を当てることで、要求者の立場に立って要求の背景を観察することによって得られた共感を活かし、元要求をより深く理解する、そして要求者が発見できていなかった潜在的な問題やソリューションを発見するという思考法のことを指す。同思考法をベースにしたHCD(人間中心設計)という学びは世界中に広められている(注3)。強い共感力が求められる中、クリティカルシンキング(注4)の考え方も含まれていると筆者は考える。

（図1: HCDのプロセス）

　プロトタイプとは、問題定義仮説を基に設計されたソリューション仮説の集合のことであり、検証(= 評価テスト)を経った上、その中の一部もしくは全部が、成立したソリューションとして認められ、製品化へと進化するというふうに定義できるのであろう。

　改善サイクルとは、プロトタイプに対する評価テストの結果を基に、プロトタイプを作り出すための各段階の中のどの段階を見直す必要なのかを分析し、その段階まで遡ってプロトタイプの再作成を、評価テストをパスするまで繰り返すというサイクルのことを指す。

　上記三つそれぞれを見て、デザイン分野に限られるような考え方でもないことにお気づきだろうか。つまり、上記の特性を継承したデザインシンキングはデザイン分野以外においても活躍できる場がたくさんあるはず。

デザインシンキングは具体的にどのように運用するのか？

　元々デザインシンキングはデザイナー達の脳内で行われている認知活動だったのだが、その考え方の発展や普及につれて、特に非デザイン分野へ浸透していくために、より具現化且つ可視化されるようになってきた。その中で、「ダブルダイヤモンドモデル」と「デザイン思考の5つのステップ(注5)」が一番有名で、ここでは「ダブルダイヤモンドモデル」に焦点を当て、受託事業においての共創思想を基に、前述の更なる展開として実際の運用例について少しご紹介できればと思う。

（図2: ダブルダイヤモンドモデル）

　一般的な流れとして、発注側から要求を提示することから始まるのだが、受託側としてすぐにソリューションプランを始めるのがありがちなパターン。どこが問題？ ーー 簡単に言うと、このパターンで成功できる大前提の一つは、発注側から提示された要求自体が有効な問題定義を起点にした要求定義であることで、この条件が満たされていなければ、最後に提供できたソリューションは不完全なもしくは間違った問題を解決するためのソリューションになってしまうのだ。そして冒頭でご説明したように、残念なことに最初からもらった元要求の中、上の条件を満たしているものは少数に過ぎないのが事実である。更に、厄介なことに、たとえ有効な問題定義を起点とした要求だったとしても、その要求の裏には、元問題から生まれるまだ発見できていない潜在的な別要求も存在したりするため、それらの要求事項も同時に視野に入れておかないと、ソリューションデザインは偏ったものになってしまうことも考えられる。言い換えれば、有効な問題定義イコール正しい問題定義というわけでもないことを意識しておくのが良いだろう。

（図3: ありがちなパターン）

　そこで、デザインシンキンングを念頭に置き、少し考え方を変えると、上述の問題は解決できるのかもしれない、と考えた。ダブルダイヤモンドモデルを基に、実運用のための変形を以下の2パターンに分けて図で簡単にご説明したい。

パターン①　有効ただ不完全な問題定義を起点にした要求提示の場合

（図4: パターン①）

　図の中の「元問題」は発注側のクライアントが想定した問題定義のことで、「潜在要求」は受託側が元要求をベースにその背景にある問題定義を咀嚼した上発見できた潜在的なニーズのことを指している。図に書いた通りだが、潜在要求が発見できていない状態で、単純に元要求から考えた一見正しいソリューションAは、結局ベストチョイスではなかったことが明らかだ。

パターン②　有効でない問題定義を起点にした要求提示の場合

（図5: パターン②）

　図の中の「根本問題」というのは、発注側のクライアントが想定していた問題定義より更に根本的な実在問題のことを指す。その問題を解決しない限り「元問題」の解決はできないということになるため、ソリューションデザインをする際、「元問題」だけでなく、この新しく発見できた「根本問題」とそこから生み出される潜在的な要求も対象として定義する必要がある。

以上、有効ただ不完全な問題定義と有効でない問題定義それぞれを起点にした要求が提示されてきた場合の運用についてご説明したが、デザインシンキングの意義を改めて認識いただけるようになったら幸いだ。

当然、デザイン分野以外においてのデザインシンキングの運用事例は他にもたくさん存在しているが、今回は一側面からのご紹介として一旦ここまで。

Tetsu. ／2021 Sep.

注1：Wikipedia > デザイン思考
注2：Wikipedia > デザイン思考 > 問題解決プロセスとしてのデザイン思考
注3：HCDにおいては、ユーザーからの要求事項を実現させるために、調査 - 分析 - 作成 - 評価 というサイクルを回すというプロセスを提唱する。
注4：Wikipedia > 批判的思考
注5：デザイン思考の5つのステップ：  共感 - 問題定義 - アイディア創造 - プロトタイプ作成 - テスト