はじめに

イノベーションに関するイベントのタイムテーブルに目を通すと、約9割くらいの確率でデザイン思考という言葉を目にするようになりました。現在半額セール中の amazon のカテゴリ別(ビジネススキル)1位も、デザイン思考関連の書籍です。(2020年5月4日時点)

なぜ、このようにデザイン思考が注目されるようになったのでしょうか。歴史を振り返ってみると、IDEO と言う企業の存在は欠かせません。IDEO は、世の中への影響や貢献度の高い企業の内の一つとして知られています。

先ず、約20年前(もうそんなに経ったのか…)に発売された書籍『発送する会社!ー世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法』でその名を社会に広げ、『デザイン思考が世界を変える―イノベーションを導く新しい考え方』でデザイン思考がイノベーションを起こす起爆剤になり得るという風潮を作ったことが背景にあります。

今、改めて IDEO のサイトを見ているのですが、デザイン思考の専門サイトが開設されており、デザイン思考を学ぶための教育コンテンツが盛り沢山で驚いています。

Resources

Design thinking simultaneously considers what is desirable from a human point of view, what is technologically feasible, and what is economically viable. It also allows people who aren’t trained as designers to use creative tools to address a vast range of challenges.

私も実は、この中で紹介されている IDEO U というビジネスマン向けのオンラインコースを受講したことがあります。IDEO の中の人がメンターとしてサポートしてくれるので、心強かったです。オススメ。

さて、デザイン思考というと、下記のような図を一度は見たことがあると思います。これは、IDEO の創設者であるデビッド・ケリー氏が創設した Standford 大学の d.school が提唱する5つのステップであり、デザイン思考を説明する際に最も参照されている図と言っても過言ではありません。

このように、デザインのプロセスが公式化されたことで、結果として非デザイナーをプロセスに迎え入れることができるようになりました。この功績は、非常に大きいと思います。デザイン思考は、普遍的なプロセスとしてイノベーションを実現するための鍵となる問題発見&問題解決に適用できると今日まで考えられてきました。

ただし、実際のところ蓋を開けてみると、デザイン思考で説明される言葉と、実際にデザイナーが用いる言葉を並べてみると、そこにギャップがあることが伺えます。

例)予算、社内政治、マイルストーン、工数、組織文化など

「Design Thinking is Bullshit」という衝撃的なトークをぜひ見てください。デザイン思考に対する彼女の批判はこれからのデザイン思考を語る上では欠かせないはずです。

ここで言うギャップは、私は「デザイン思考の実践で陥りやすい誤解」と理解しています。この記事では、デザイン思考の如く取り組む際の誤解を紹介するとともに、回避策についても述べたいと思います。

デザイン思考で陥りやすい3つの誤解

誤解その壱:ユーザーの声を反映すれば、うまくいく

単純過ぎますが、ここで注意すべきは、誰の声(WHO)か、何を(WHAT)拾うか、そしてどのように(HOW)ユーザーの声を拾うのか、と言う問いに対する答えを持ち合わせているかどうかです。

一言にユーザーの声と言っても、ユーザーは大勢いるが?どうすればユーザーの声を拾えるのだろうか?そして、どのような形式を採用すれば的確なニーズを抽出できるのだろうか?この答え無くして、ユーザーの意見を反映すれば失敗はしないという保証はできないはずです。なぜなら、ユーザーリサーチで大切なのは、優先度付けだからです。それでは、それぞれの問いを詳しく見ていきます。

誰の声を拾うか(WHO):ユーザー像を明確にする際には、ターゲットとなるセグメントの中でも、特に集中したい人物像のペルソナを設定する必要があります。そうすることで、従来のセグメンテーションとは異なり、より深く、そしてより実感が湧くようになります。

ペルソナで思い出したのですが、atama+ という企業ではペルソナの擬人化を徹底するあまりに、3D 化してしまったのだとか。ここまでする必要はないと思いますが、一度オフィスに遊びに行かせていただいたときに、大変興味深い光景を見ました。打ち合わせ中の社員が、ユーザーを名前で呼びながら、会話をしていたのです。ここまで浸透していると、効果は絶大です。

AI先生『atama+』開発におけるユーザー像「ペルソナ」を公開

atama plusは、「教育に、人に、社会に、次の可能性を。」というMissionのもと、生徒が「基礎学力を最短で身につける」ことを目指してAI先生『atama+』を全国の塾・予備校に提供しています。 プロダクト開発において、Valuesとして掲げている「Wow students …

何を拾うか(WHAT):リサーチの中身のことです。ここからは、イメージがしやすいインタビューに話を絞っていきたいと思います。この記事を読んでいるみなさんは、普段のインタビューではどのようなことを聞いていますか?また、インタビューに至るまでどのような過程を得ていますか?

インタビューは、学びを得る場です。そのようにインタビューを位置付けることで、チームで次のインタビューに向けて話し合う場で、学びを最大化するための質問内容が自然と絞られていきます。発散し過ぎてしまうと、あれもこれも聞きたい内容が多すぎで、インタビュー時間が超過してしまったりします。また、急ぎすぎて試合終了後の選手インタビューのようなテンポの Q&A になってしまいがちです。ユーザーインタビューは、時間が限られている。そうならないようにするためには、優先度をつけることです。優先度付けは、インタビュー設計の時から始まっています。

どのように拾うか(HOW):ユーザーの声を抽出するための方法は様々です。そのため、どれが一番ベストな選択なのか、悩んでいる人も多いはず。そこで推奨したいのは、2軸を用いた整理です。以前、2軸を使ったプロダクトデザインにおける意思決定の方法「2×2」について紹介しましたが、今回も同様な取り組みが可能です。私が過去に取り入れた軸に以下があります:

  • コスト
  • 時間
  • 母数

この軸で整理することができれば、どの手法が今の状況におけるベストな選択肢なのか自信を持って判断することができます。ユーザーの声を可能な限り、なるべく取りこぼさないようにしたいから、と言う理由で安易に母数が多い手法を選択しても、プロダクトのためにならないこともあるため、注意が必要です。

誤解その弐: アイディアは多数決で決めたほうが、失敗するリスクは下がる

デザイン思考といえば、ポストイットが壁一面に貼られていて、その前に大勢の人が集まっているシーンを思い浮かべる人が多いと思います。

これは、参加しているメンバーのアイディアを発散し、収束させる過程の内のひとつですが、ここので注意すべきは、「お任せ民主主義状態」にならないことです。自身の書籍『サル化する世界』で内田樹氏はこう述べています。

民主主義は多数決ではなく、多様な意見に対する合意形成の上で成り立つもの。できるだけ多様な立場の人を合意形成の当事者に組み込む必要がある。

大切なのは、公正性です。それはつまり、全てのアイディアにチャンスを与えることです。誰が発言したか、誰のアイディアかで判断を任せるのではなく、アイディアが優れているかどうかで判断するための発想です。公正なプロセスとは、お互いの意見を尊重し、一人が主張するものであれば、多数が主張するものであれ、最高のアイディアを求め続けること。もう一度言いますが、この人が言ったから、とか少数の意見だから、と言う不公平な扱いをしないことです。それでは、「自分の意見が受け入れられる、または受け入れてもらえる」と言う心理的安全性の環境を作り出すことができません。

アドバイスの一つは、その場で改善案を出さないようにすることです。最初に、理解のための質問をします。アイディアの一つ一つに目を通し、全員の理解が揃っている前提を作ってください。決して価値観を押し付けない、いいところも指摘してください。その後、上でも紹介したような2軸の意思決定方法を用いることができれば理想的です。

誤解その参:プロトタイプで問題がなければ、使ってもらえる

プロトタイピングツールはここ数年で劇的な進化を遂げました。過去の記事「最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ」でも述べた通り、リモート環境下でも円滑にプロトタイプを使ってインタビューすることができる時代にいます。昔は紙芝居程度ではあったのに比べて、あたかも本番稼働しているかのようなインタラクションや画面遷移を実現できたりします。本当に凄い。

最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ | mariosakata.com

本記事は、ユーザーリサーチを批判することを目的に書いた記事ではないことをご理解ください。私自身の経験をもとに、ユーザーリサーチの可能性を広げるためのアプローチをご紹介し、リモートでユーザーリサーチを行っている、またはこれから行う人にとってお役に立てればと思っている。 …

だた、ここで注意すべきはアイディアを忠実に再現することができるが故の甘えです。プロトタイプの目的は、上で述べた「何を」が明確にならなければ、ただ単に確認のためのチェックになってしまいます。ユーザーのニーズを無視してしまいがちです。この機能はあったら使いたいと思うか?使いやすいか?このような誘導的な質問をする場を何度も目撃したことがあります。こちら側が求めている答えをユーザーから引き出す、なんとも都合がいいインタビューなのでしょう。

その場で問題がなく、期待通りの回答がユーザーが得られたなら、リリースしても問題はさほどないだろうという甘い考えは、捨てた方がいいと思います。将来のことはユーザーにだってわかりません。現時点で例え「欲しい」と言及していたとしても、実際のところはその場にいないとわからないもの。成功の確率はもしかしたら上がるかもしれないが、決して保証するものではありません。

最後にもう一つ

もう一つ誤解を招きやすいのが、デザイン思考は順を追って進めていく段階的なアプローチで、リリースしたらプロセスは終了、と考えてしまいがちなところです。しかし、ソフトウェアはずっと生き続けます。ユーザーも、使い続けます。では、作り手は手を休めていいのでしょうか?

リリースした後も、その壱で挙げたように何を学びたいか、何を検証したいのかを再度整理することで、その先につなげることができます。仮説も、よりシャープになっていきます。向かうべきプロダクトの方向性も明確になっていきます。チームの自信につながっていきます。イノベーションにグッと近づいていきます。直ぐに答えを求めてしまいがちな我々ですが、一度のサイクルでうまく行ったのなら、こんなに苦労はしないでしょう。

そういえば、この記事では「デザイン思考」と言う言葉を20回以上も使いました。くどい記事になってしまいました。最後まで読んでいただき、感謝です。