デザイン思考を初めてクライアントに使った成功と失敗

もし皆さんがデザイン思考に興味があったり、社内でやってみようかなと思っていたら、ぜひ読んで欲しいと思う。綺麗事ではないデザイン思考の体験（教える側として）と身を削りながら起こした失敗が役立ちます。

手法やフレームワークは他の記事を参照してください。この記事で最も伝えたいことは「ツールの習熟度が成功の鍵であること」です。

時間がない方用のサクッとサマリー
・「このチームであれば、本音を言える」環境作りが一番大切
・ワークショップには「静」と「動」のリズムがある
・事例は用意する＝メンバーの理解度が深まる
・1つ1つのワークは時間を設定する、そして守る
・先の見えない不安に耐える
・フェーズごと、ワークごとにマインドセットを伝える

話は昨年の秋に遡る。約1ヶ月半を使って毎週デザイン思考のワークショップを運営した。体験した成功と失敗を振り返る。

今回はプロジェクトの途中から参加し、各チームのファシリテーターとしてクライアントにデザイン思考のフレームワークを教えていく。

意図を持ったアイスブレイク

多様性を取り入れるため新入社員から役員クラスまで部署横断し、チームが組まれている。

チームメンバーは初対面が多く、普段仕事では接点がないため、毎回アイスブレイクをワークショップの最初に行う。

アイスブレイクはその日行うワークに合わせて、きちんと意図を持つ。緊張がほぐれるのが本来の目的だが、同時にその日のマインドセットも伝えることが出来る。アイスブレイク後に意図を伝えると納得してもらえることが多かった。

「知っている」から「使える」フレームワークへ

次に実際に行うフレームワークを紹介する。共感マップやカスタマージャーニーマップ、アイディア発想法やユーザーインタビューの仕方、プロトタイピングの種類、番外編としてピッチのコツまで。

さらに、具体的な事例があるとより理解が進む。特に役員レベルのメンバーには効いた。事前に準備しておけば自分を助ける武器になる

ここでの失敗は各フレームワークを「なぜこのタイミングで、どのように、どんな心構えで行えばいいか」具体的に伝えられなかったこと。

この失敗がメンバーを襲うこれまでにない不安と違和感を作り出してしまった。ユーザーの課題がぼんやりしていたり、はじめてのフレームワークに困惑し、先の見えない状態に彼らは耐えきれなかった。

デザイン思考では普段と全く違う考え方をすることを前提として、毎回必ず伝えたほうが良い。

言われたからフレームワークをこなすのと「何のために」を理解して進めるフレームワークとではメンバーのやる気と書き出すポストイットの質が違う。

プロセスを進めることの大切さ

少しワークショップ中のテクニック的な話をすると、ファシリテーターは「静」と「動」をコントロールする必要がある。

個人ワークさせる時間、書いたポストイットを全員でシェアする時間、座った状態なのか、立った状態なのかでもグループダイナミクスを変えることができる。こういったメリハリがワークの質をあげていく。

同時にタイムマネジメントも大事だ。自分の場合、下手過ぎて自分のチームが他のチームに比べて、1フェーズ以上遅れた。これがメンバーにとって心理的に焦ることにつながるし、より不安を煽ることにもなった。

ワークごとに時間を区切って、アイディアを出す→シェアする→決めるの順で進めていく必要がある。

アイディアを発散させるより、収束させる方が難しい。まだ十分に検討していない、別の視点から考えられるのではないか？そんな意見が飛び交い、すぐに決めることに抵抗をするメンバーが多い。

それでも前に進める、デザイン思考のプロセスを先に進めることで見えてくることがあるからだ。

頭で考えるのではなく、直感で感じたことを大切にするのがデザイン思考だとしたら、短い時間で強制的にアイディアに投票させるのをオススメする。

メンバーが選んだアイディアに納得していない場合、もやもやを抱えながら進めることになる。自分のチームは実際そうなった。というか毎回そうなった。

それでも、ユーザーテストしたり、他の人からレビューを受けることでアイディアがブラッシュアップされたり、別のアイディアに転嫁したりすることがあった。

決めるということに恐れを抱く人も多いが、一度決めてダメだったら、もう一度やればいいと伝えるのがコツ。

試してみたり、誰かに話してみないと真の価値は分からないものだ。

そこに「ユーザー」はいるのか？

ほぼ毎回数分のピッチを各チームがワークショップの終わりに行う。この目的は作ろうとするプロダクトの絶対に外せない機能（クリティカルファンクション）を明確にする効果がある。

デザイン思考のベースはユーザー中心に考えることにある。プロダクトのアイディアや機能を考えているうちにどうしても忘れてしまうユーザーの事を思い出させることができる。

ペーパープロトタイプを必死で作っているメンバーに「この機能はユーザーの課題を解決するために絶対に必要ですか？」と問い続けた。

クライアントはその業界のプロであることは間違いない。プロダクトの細かい仕様や業界のトレンドを知らなくても大丈夫。

やるべきことはデザイン思考のプロセスにフォーカスし続けることだ。先頭を切るのはあくまでメンバー。目的地だけはしっかりと定めておこう。

つまり、デザイン思考は使えるのか？

このプロジェクト中にこんな記事がTwitterで話題になった。

この補足として

これに対してIDEOがコメントを出している。

別の視点でTakramの佐々木さんも反応。

水泳の教科書を読んだり、プールに行って見ているだけでは絶対に泳げる様になることがないのと一緒で、実際にデザイン思考のプロセスとツールを使ってみて、失敗してみて初めて少し分かるようなる。

ユーザーから興味深い話が聞けない、インサイトが見つからない、どんなフレームワークを使えばいいか分からない。

悩みの大半はツールとフレームワークの本質を理解していないことが原因だ。

デザイン思考のプロセスを実際にリードしてみて深く感じたのは「不安と混沌」しかない。

真っ暗な洞窟を手探りで進むより、松明があれば心強い。それが懐中電灯ならもっと心強い。

真っ暗な洞窟を他人と進むより、知人であれば心強い。それが相棒であればもっと心強い。

デザイン思考は強力なツールだ。
信頼できる仲間とそのツールを知り尽くし、使いこなせていればだが。

こちらも参考になるのでどうぞ。

デザイン思考の本質とは？—新米ファシリテーターの経験を通して気づいたこと

※投げ銭は子供支援団体に寄付予定です。