エンジニアがデザイン思考を学ぶ際に苦戦するポイント

posted in: Design | 0
はてなブックマーク

今回の記事ではエンジニアの視点から実際にデザイン思考(プロセス)を学ぶ際に苦戦すると感じたポイントを紹介していきたいと思います。

デザイン思考について興味の有る方は下のページ等をご参照下さい。

デザイン思考の概要を15分で学ぶページ

デザイン思考が近年注目されている理由

はじめに、少しだけ私自身の事について紹介します。私は、元々企業のエンジニア(研究職)です。学生時代の研究室での活動を含めると約10年間、材料やデバイスの研究開発活動に関わってきました。

そのため、これまで学んできたプロセスは自然科学や数学が支配するロジカルなアプローチがばかりでした。

一方で現在、学んでいるデザインの手法は定性的な情報を取り扱ったり、各要素間の関連性をみたりとこれまでとは異なる頭の使い方を要求されています。

この左脳的なアプローチと右脳的なアプローチの違いは、しばし学習時の課題になると感じました。エンジニアとデザイナーがより効果的に働くために、知っておいた方がよいと思った心構えについて私の経験を一部シェアしたいと思います。

Discipline brain

(Illustration by SN)

エンジニアリングプロセス vs デザインプロセス

企業における一般的な研究開発(特にデバイス等)では、一般に商品購入者の声を元に目指すべき指標(スペック)が決まります。

また、この一次情報に競合他社や技術のベンチマーキング、特許分析等の情報を組み合わせながら、開発要素の優先順位をつけて進めていきます。

一方でデザイン思考をベースとしたアプローチにおいては開始の期初においては解決するべき課題が明確には定義されていない事が多く、問題を探す事自体からプロセスが始まります。

人間中心設計のプロセスでは、人間という複雑な対象が現実の空間や状況で、どの様に振る舞うかを理解する事から始まります。

そのため、エンジニアリングの手法やビジネス分野で使われているロジカルなアプローチに加えて共感といった人間的なスキルセットや関連付け思考といった右脳的なアプローチも必要になってきます。

この異なるDisplineの融合が非デザイン分野から新たに学ぶ人にとっては大きなチャレンジになります。

また、すでにデザインを学んだ人にとっても、クライアント等が異なるメンタルモデルを持っていた場合に、いかにコミュニケーションをとっていくかは、1つのポイントになるでしょう。


エンジニアとデザイナーのメンタルモデルの違い

メンタルモデル


目標設定に対する考え方

新商品やサービスを開発したい時に、皆さんは次の行動をどうやって決めていくでしょうか

おそらくケースによるという回答が多いのではないでしょうか。ここではエンジニアリング案件とデザイン案件の一般的なケースを例に考えていきたいと思います。

エンジニアリングの案件、例えば”より低コストで透明度の高いガラスの開発”では定量指標(価格、ガラスの透過度等)を定めて、プロジェクトのリソースと照らし合わせながら具体的なアクション・プランを定めていくケースが多いです。

この過程では、マーケット情報や技術ベンチマーク等も活用しながら、ある程度「何」を行うかは明確になります。そして、一人ひとりの具体的な活動内容が明確になり、役割分担がされていきます。(ものすごく基礎の探索テーマ等はまた別です。)

一方で、いわゆるデザインファーム等で請け負う案件の多くは、定量的な答えを期初では定義できないものが多いです。

例えば”モバイル近接通信技術を活用した、都市部のカフェ向けのサービスの提案”といった形で、より大きな枠組で捉えなくてはならないケースも多いです。

この様な案件では、お客様にとって何が重要か、それを実現するにはどうすればよいかといった、大枠の構成を把握する必要があります。

しかし、当然これらはロジカルに単一の解に収束させる事は難しいです。そのため通常は決め打ちするのではなく、仮説・検証を繰り返しながら確度を上げていくというアプローチになります。


思考の見える化問題

この様にこれまで体験してきたプロジェクトや考え方の違いがあるので、エンジニア畑の人の視点からみると、プロジェクト初期段階のデザイナーの動きは奇怪なものに見えます。

例えば、なぜベストな仮説構築を行うのに、このサンプル数でよいとするのかとか。発言の内容の優先度をどうやって評価するのか、何故プロトタイプのこの部分の形にこだわるのか(定量評価関連)、といった様々な場面で「?」が現れてきます。

そんなエンジニアを傍目に、経験豊富なデザイナーの方はどんどんインタビューや観察、ワークショップを行い、机の周りに沢山付箋をはりつけながらどんどん、仮説構築を進めていきます。

ヨーロッパの特徴かもしれませんが、これらのプロセスはかなり分業が進んでおり、私のいるデザインファームでは、かなりの裁量権がプロジェクト責任者に委任されていました。

実際のコンサル案件の場合では、有る一定の段階でクライアントに対してこれらのデザインの成果を報告する事になります。(フェイズに合わせて何回も行われる)

デザイナーはこの発表の段階まではかなりの裁量権が与えられており、この報告会の場で、自信のアイディア(仮説)を売り込んでいくことになります。

デザイナーは、「何をやるか」、「何故重要なのか」の2つを中心に、提案内容のストーリーを構築し、時にはビデオ表現、簡単な紙の試作等を用いてアイディアを売り込んでいきます。

この時にクライアント側とデザイナー側のメンタル・モデルが近いと話はすんなり進むのですが、私はこの過程が中々しっくりこない部分があり、苦労しました。

例えば、提案内容が良いアイディアであると納得しても、「何故その回答に落ちてきたのか」、「どういう判断ポイントがあったのか」、「全体を俯瞰できているのか」といった提案のストーリー自体以外の見えない情報も気になってしまうのです(VCの人とかは私と近い考え方をする人が多かった様に思います。エンジェル投資家の様な人は別ですが・・・・)。

これは全体を把握し、できるだけ多くの情報から定量的に判断するという行動を繰り返してきた過去の経験によるものかと思います。

そのためデザイナー視点に立つと、エンジニアリング色の強いクライアントを相手にするときには、提案自体のストーリーは勿論ですが、思考プロセスの見える化をいかにきちんと行えるかどうかが重要なチャレンジになると思います。

クライアントによっては提案内容のみで判断する事もあるので、その見極めが重要になるでしょう(クライアントの種類やプロジェクトのフェイズによっては細かい全体観の議論よりコンセプトにフォーカスして議論したいというケースも多いため)。

経験豊富なデザインファームのメンバーは、あらかじめクライアントがどのような特性を持っているかを把握することに、それなりの力を割いています。これは恐らく事業戦略のコンサルティングファーム等と近いかと思います。

彼らはクライアントのメンタルモデルに合わせて説得の仕方も変えています。この部分がエンジニアリングの業務プロセスの様に、デザインファームの見えにくい競争力の源泉になっている様におもいます。

彼らは下の書籍の様なツールキットやコンセプト表現方法を有しており、上手くこれらを案件に合わせて使い分けて説得をしています。

逆にエンジニア視点から言うと、デザイン案件をデザイナーと協業してすすめるときには、権限委譲を事前に認めるか、もし思考プロセスを共有したい場合には、事前にその様な旨をしっかり伝えるといったコミュニケーションが肝になるでしょう。

デザイナーはプレゼン等では、提案自体のストーリーを重視して話す傾向があります。そのためこのようなすり合わせをしないと、良いアイディアが得られても、次の段階に進む意思決定ができないというジレンマに陥るケースもでてきます。

またエンジニア側は曖昧さを許容するという心構えを持つ必要があります。もちろんデザインする人にある程度の説明責任(決定理由)は生じますが、全てを定量指標で評価する事は難しいです。

デザイン案件の場合はその対象(スコープ)が広いのでエンジニアリング案件と同じレベルでの明確さを求めるのは、ナンセンスかと思います。

組織の中でデザイン思考(プロセス)を取り入れていくには、こうした相互理解を少しずつ深めていくことが大切かと思います。

今後企業の競争力をより高めるためにも、エンジニアリングとデザインの世界が近づいていくと良いなと思っています。

マニアックなトピックですが最後までお読みいただきありがとうございました。

記事の更新をFacebookでチェック!


はてなブックマーク

Leave a Reply