デザインシンキング導入時にバッドエンドになるケースまとめ


最近、デザインシンキングが語られるようになってきました。
ただ、必ずしも全てのケースで有効ではないため、今回は、自分のためにも有効でない場合の整理をしてみました。

先日、この記事が話題でしたが、デザインシンキングについては、記事で言及されている通り『デザイン思考は、技術的に実現可能なものやビジネス戦略を顧客価値や市場機会へと転換可能なものと、人々の要求とを一致させるために、デザイナの感覚と手法を利用する方法』と定義されています。


同僚に差をつけよう!今流行っている「デザイン思考」の全体像まとめ
http://www.kokoro-no-compass7.com/entry/2016/05/06/213258

これをみてみると、日本人のイメージする色や形の付与という「デザイン」の概念を超えて、デザイン思考における「デザイン」は問題解決やそのためのサービス開発を指すということです。

プロダクトデザインにおける方法論として、デザイン思考を有名にしたのは、デザインコンサルティングファームのIDEOですが、それらのクリエイターが行ってきた方法論が言語化されたこと、新しい開発手法の導入がポジティブになってきた背景が盛り上がってる理由の一つだと思います。

個人的に、この手の話は好きで、導入には非常に前向きな人間ですが、デザインシンキングが向いていないケースも当然あります。
手法を学んで採用してみたものの、、結果がでない…という場合も多いと思いますので、経験上のNGパターンをまとめてみました。

デザイナーの能力を生かせない日本企業の仕組みでも言及されている通り、無理に実行しようとすると不幸になるルートも世の中には存在しています。

個人より組織の論理を優先する傾向が強い日本では、個人としてのデザイナーのカラーを集団が打ち消してしまう可能性が高い。アウトプット(製品の最終的な形)が当初デザイナーが情熱を持って考えだしたコンセプトから大きくブレてしまうこともよくある。

1. ステークホルダー、方針を決める人を巻き込めていない

デザイン思考は「分析思考とは異なり、デザイン思考はアイデアの積み上げによるプロセスであり、ブレーンストーミングの段階ではアイデアの幅に制限を設けることはほとんど、あるいは全くない」という手法です。プロセス中は、経営会議など意思決定に必要な報告をするにはまだ早すぎる状況が往々にしてあります。

ニーズ調査から発散させてプロトタイプしていくため、プロセスに参加していない第三者に理解してもらえるフェーズは後半になるため、そのプロセスが理解されないまま、経営者に数値に直結する報告を求められたりすると、最悪なケースとしては、根本をひっくり返される事が起こります。

プロセスに関与してない、理解されていない状況だと、ニーズ調査ばかりしてる印象や、リアリティが低いアイディアを模索している状況として受け止められやすい場面もあります。ステークホルダーの理解が得られていない場合、プロセスを無力化できる魔法の弾丸が現場に飛んでくる場合がありますので、キチンと理解を得て進める事が必要です。

プロセスに巻き込めななくとも、権限移譲を行なってもらい、ちゃぶ台を返されないという前提のもとで実施するのがオススメです。

2. チームメンバーを適切に巻き込めず一部で盛り上がっている状態

デザインシンキングを活かすためには、開発チームのプロセスに組み込む必要があるため、メンバーの一部だけが実施している状態だろ効果は薄れます。

例えば、デザイン思考の知識を自分だけが保有している状況、知識差を誇示することで優位に立とうとする場合、違和感が生まれスムーズに進みません。前述した記事では、同僚に差をつけるというタイトルでしたが、同僚を巻き込み、相互理解をしてフェアな環境でディスカッションを積み上げていくプロセスが必要です。当然そのためには、職種をまたいだ理解や、いわゆる感覚派とロジカル派の対立を無くす努力を行う必要があります。

デザインシンキングは、イノベーションのアイディアを生み出し、実現する手段として有効と言われていますが、社内サポートやクライアントの理解が得られなかったり、経営がリスクを取れない場合は、実現に至らず机上の空論で終わってしまい、無力さに苛まれる場合がありますので、周りを巻き込んで進めるのが大切です。

3. 他の業務が忙しくて、メンバーが同時に集まれないチーム

デザインシンキングや、Google Design Sprintなどは、プロセスや議論を共通の思考として頭にインストールされている状態で進めるのが前提で、メンバー全員のスケジュールを常時押さえて進めるのは厳しい面もあります。多くのメンバーが不在の状況で進めると、共通認識の形成ができなくなり、チーム内でもそれぞれが違うモノの見方をしているため、強調して見えるポイントが異なってきます。

中には、グラフィック作業やプログラミング以外に時間を使うのはネガティブなメンバーも居るかもしれませんが、参加してもらうことでフェアな共通認識が形成されて、健全なソフトウェア開発が行えると思います。

前提条件、共通認識の形成を怠った場合、効果が期待できなくなるため、実施時は、全員参加した方が良い重要度の高いテーマで活用するのがおすすめです。

4. 結論がある程度決まってる場合

「最近イノベーションを生み出せるデザインシンキングというフレームワークがスゴイのでチャレンジしてみたい」となり、チャレンジしてみつつも、ステークホルダー、プロデューサーがゴールイメージを強く持ってる場合は、発散するコト自体が無益になるため、その場合は、プロトタイピングにフォーカスした方が有効だと思います。

デザインシンキングは、課題をあぶり出して、アンメットニーズを顕在化するアプローチなので、目指すモノのイメージが既にあればアンマッチな手法になります。現場メンバー全員のスケジュールを押さえてデザインシンキングを実施する場合、コストの大きくなるため、必然的に、重要度の高いテーマにトライする事になると思いますが、本当にそのアプローチが適切なのか、ステークホルダーを巻き込んで決めましょう。

本流開発からスピンオフさせる方法もあると思いますが、デザイナーだけが、ボトムアップで実施しても効果は得られにくいと思います。

まとめ

デザインシンキングが現場に広く普及していくのはこれからだと思うので、プロセス自体も「素早い失敗」を行うことで、チューニングして、徐々に成功へと近づいていくことが大事のではないかと思います。

今後も勉強と実践を続けていきたいと思います。

クリエイティブ・マインドセット 想像力・好奇心・勇気が目覚める驚異の思考法
デイヴィッド・ケリー トム・ケリー
日経BP社
売り上げランキング: 10,047

 

tsubotax

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です