デザイン思考の授業内容を読んでデザイン思考を3分で分かった気になれる(...はずがない)
デザイン思考の素人が9ヵ月間の授業で学んだことを元に、何も知らない人に「デザイン思考とは何か」を分かった気にさせようという無謀な試みです。
真面目に知りたい人は、 IDEOの本 や イマドキのデザイン思考事情 などを読んでください。
授業の前提
チーム
各チーム概ね次のようなチーム構成だったと思います。
- 東工大の学生: 2～3人
- 美術の専門家(美大、藝大、プロのアーティスト): 1人
- ソフトウェアエンジニア(社会人): 1人
テーマ
いくつかテーマがあり、その中からチームでやりたいものを選びます。自分たちは、次のテーマを選びました。
富士スピードウェイへ向かう自動車愛好家の旅行体験を再デザインせよ
こんなバクッとした課題で、とにかく何かを新しいものを作れというものでした。
デザイン思考のプロセスの概観
デザイン思考のプロセスは、 6角形の5つのブロックでよく説明されます。順序は一応ありますが、違和感があれば、いつでもどこまでも戻ってやり直します。
- 共感(Empathize)
- 問題定義(Define)
- 発想(Ideate)
- プロトタイプ(Prototype)
- テスト(Test)
共感(Empathize)
「ユーザのこと知らずしてユーザの課題を解決できるはずがない」、と正論を言われ、否応なしにユーザに聞きに行きます。2週間でチームで10～15人に聞くという課題を出されました。
そこでまず、身近にいる車好きな人(出来ればサーキットに行ったことがある人)、旅行好きの人に話を聞きました。インタビューは、聞く人、観察する人、メモを取る人と分担できるように、複数人で行うのが望ましいのですが、自チームでは時間的な制約のため、各々が1人で3人程度に聞きました。
その後、テーマにある富士スピードウェイにも行き、ドリフトをしに来ている人たちに話も聞きました。
自分は車の知識も興味もなかったので、車好きな人の考えることを色々聞けて楽しかったのですが、その程度であるため「インサイト」と呼ばれる「ユーザすら気づいていないこと」に気づけるわけもなく、結果的に苦労をしました。
問題定義(Define)
「ユーザすら気づかなかったこと」を見出す、「ここがデザイン思考におけるポイント」と勝手に思っているステップです。
KJ法 や カスタマージャーニーマップ やタテマエメソッド を駆使して、「インサイト」ならびに「Point of View(PoV)」を探ります。
Point of View(タテマエメソッド)のテンプレートは次のようなものです。
［状況］にある［ユーザー］は、
［行動］をしている or する必要がある。
なぜなら［タテマエ］だからだ。
とはいえ、本当は［インサイト］である。
我々のPoint of Viewは、次のようなものとなりました。
自動車愛好家は、
自分一人で運転に没頭したい。
車をこよなく愛しているからだ。
とはいえ、仲間とも走りたい。
一言で言えば、「自動車愛好家は、寂しがり屋の一人好き」なんだ、と定義しました。矛盾を帯びているのがポイントです。
実のところ、サーキットで聞いた人たちは全員「一人で来る」と言っていました。自分で運転したい、サーキットに興味を持つ人が身近にいない、一般の人が同乗するのに快適とは言えない(例. エンジン音が大きい、シートが狭い)、自動車愛好家の住んでいる場所がバラバラ、などの理由からです。
それにも関わらず、「本当はみんなで行きたいはずだ」とユーザすら思っていなさそうなことを多少強引に見つけました。正確には「見つけたことにしました」。
実際にヒアリングしたユーザがそう思っているかは、プロトタイプを持っていって確かめれば良いので、重要ではないのです。
発想(Ideate)
ここでは、How Might We Question（HMW） と呼ばれる
我々はどうすれば、… をできるだろうか?
という問いを考え、それに対する解決策を考えます。
我々のグループでは、
どうすれば、「簡潔」に自動車愛好家同士のコミュニケーションを実現できるだろうか?
という問いを考えました。
「自動車愛好家は、走りに没頭したいけど、時にはコミュニケーションをとりたい(はずだ)。そういう時に使いたいと思うソリューションは何か?」という疑問から来たものです。
これに対して、次のようなソリューション「pit」を考え、プロトタイプを作成しました。
プロトタイプ(Prototype)
pitは「グループで話したい時に、ボタンを押しながら話すと、その声がグループ全員に伝わる」というソリューションです。無線トランシーバーと同じ機能ですが、ボタンとスマートフォンというシンプルな構成で実現しています。
実際は、pitボタン、スマートフォン上で動作するpitアプリケーションの他に、裏でインターネット上の通知サービスを使っています。
ボタンを押すとpitアプリケーションが声の録音を始め、ボタンを離すと録音した声を通知サービスに飛ばします。通知サービスは、登録された音声を他の人のpitアプリケーションへ送り、スマートフォンから音声が再生されます。
結果として次のとおり「簡潔」に自動車愛好家同士のコミュニケーションを実現しています。
- 車の運転中を考慮した「操作の簡単さ」: ボタンを押して話すという簡単な操作
- 自動車愛好家の車装備に対するこだわりを満たす「デザインのシンプルさ」:ボタン一つをハンドルにつけるだけのシンプルさ
- コミュニケーション対象者が全員装備する必要があるので、多くの人が「簡単に試せる」こと: 比較的安価なボタン(flic.io)や、既存のスマートフォンの機能（マイク、スピーカー、インターネット通信機能）、既存の通知サービス(firebase)を使うことで、安価でユーザに提供可能
テスト(Test)
作ったプロトタイプを実際に車につけて試し、運転中にグループの声が聞こえることを確認しました。次はユーザテストです。
次のような、急な意思決定を要するユースケースで有用だと考えていました。
- 渋滞時の進路変更
- ガス欠
- トイレ
残念ながら、時間の都合上、自動車愛好家に実際に使ってもらい、有用性を確かめたり、我々が考えもしなかった新たな使い道などのフィードバックをもらうまでには至りませんでした。
本来は、フィードバックから、新たなインサイトを見い出し、さらに改良(もしくは捨てる)を続けて行きます。
実際のところは...
と、ここまで書いてみると、教科書に書いてあるような流れで、完成したかのように見えますが、実際は正反対です。授業終盤では、思いついたソリューションからPoVやHMWを考えたりすることが多々あります。慣れから、ソリューション、PoV、HMWの間を自由に動ける(どこから始めても他を埋められる)ようになります。どの順番で始めようと問題ではありません。結局は、ユーザに対して、そのソリューションが機能(work)するかが全てだからです。
半年間の授業で、pitのアイデアからプロトタイプ完成までに要した期間はわずか2週間でした。それ以外の期間、長い紆余曲折を経てこのソリューションにたどり着いたのです。その話は、 デザイン思考の授業で踊り続けた「あいまいさとのダンス」に続きます。
