読者です 読者をやめる 読者になる 読者になる

デザインイノベーションの振り子を読んだ

Book Design Product

ひさびさのブログ。

少し前だけどtakram design engineeringのデザイン・イノベーションの振り子を読んだ。 内容的には企業のPR本だけど、普段サービス作りをエンジニア(もしくはPM)という立場で関わる自分が、最近もやもや考えていたことがバシッと言語化されていて面白かった。

『takram design engineering|デザイン・イノベーションの振り子』 (現代建築家コンセプト・シリーズ18)

『takram design engineering|デザイン・イノベーションの振り子』 (現代建築家コンセプト・シリーズ18)

デザインエンジニア

エンジニアリングとデザインの両方の専門的知識や経験を経て、2つの専門性を経た状態を指すらしい。デザインエンジニアが求められるのは、前例がなく過去の経験が生きづらい0→1を生み出すような環境。まさにサービス開発って、前例が当てにならず不確実な状況下であることが多い。(リーンスタートアップもこの環境下での方法論だし)

またBusiness、Technology、Creativity (Design) の三要素を調和的につくり上げることが、新しい物事を起こす上で重要とされていた。BTCの調和がとれた状態に対して、デザインエンジニアは特にTechnologyとCreativityから担っていく存在らしい。

越境と複眼性

takramのデザインエンジニアは、ハードウェア (Tangible) とソフトウェア (Intangible) 、デザインとエンジニアリングの4象限を、自由に行き来するように経験を積んでいくらしい。最初から全てができる人は居ないので、ソフトウェアに専門性を持つエンジニアであれば、その隣の領域であるソフトウェアデザインの経験を積む。そうすことでソフトウェア領域でのデザインエンジニアとなる。

ここでいう専門性って、どのレベルを指すんだろうってのは疑問。複数の分野をこなすと、どうしても浅く広くになりがち。まさに今の自分がそうだけど、器用貧乏になってしまう。この本の中では、各分野の専門家と専門用語を使って対等に会話できる状態と軽くふれてあった。

話を本の内容に戻すと、複数の専門性を持つことで、ある分野から別の分野に越境する感覚が身につく。この越境を繰り返すことで、物事を立体的に捉えられる。この本のなかではそれを複眼性とも呼んでいた。

技術的に難しい問題でも、実はデザイン上の工夫によって問題が簡易化できる感覚は、サービス開発をやっていてよく感じる。逆に、技術的な可能性を知らないと、デザイン自体に制約ができてしまったり、または現実味の無いものをデザインしてしまったりするのも、あるあるだと思う。ここでのデザインは、単にUIデザインもそうだし、ユーザー体験の設計とか、サービス企画とかでもそう。

デザインとエンジニアリングだけの話ではなく、どんな分野でもいいから越境性を持つのは大事だと思う。Webサービスでいえば、マーケティングやコミュニティマネジメントも重要な要素だし、サポートや営業、編集だって関わりのある領域。そして一度越境を体験すると、別の分野に越境することも苦ではなくなる。

越境性を持つことで、問題を立体的に捉えて、かつ問題を変に単純化せずに進められるので、重要な情報が抜け落ちることもない。そして越境を何度も繰り返すことを、振り子思考とtakramでは呼んでるらしい。 サービスを作る上では、デザインとエンジニアリングは欠かせないし、密接に関わる分野なので、この2つを振り子思考することはやっぱり重要だよなと再認識した。

超越性

越境が水平方向なら、超越は垂直に視点を動かす感覚。ある問題に対して、虫の目(現場感覚)だけで捉えるのではなく、鳥の目(経営感覚)でも捉えることを、この本では超越性と呼んでいた。

ちょっと文章にするのが難しいけど、「それやる必要あるんだっけ?」っていうそもそもの目的から考えましょうっていう話だと自分は感じた。サービスを作っていると、考えても考えてもいい解決策が浮かばない「どん詰まり」に陥る感覚がよくある。そしてそれが続くと最悪「誰も欲しがらないものを作っている」状態になると思う。そんなときに、一歩目線をひいて考えてみて、問題を再定義(リフレーミング)してみる。すると、そもそも問題と考えていたことは問題ではなかったと分かる。

これもサービス開発やってて、あるあるだなーと思った。虫の目と鳥の目を意識的に使い分けていく。それがtakramが考える超越性なのかなと感じた。

越境と超越のタイミング

ここからはこの本を読んで自分がもやもや考えていたこと。

越境はある問題を解く上で、短いスパンで自由に行き来するのが良いと思う。逆に、ある期間は「デザイン」をする期間、次は「エンジニアリング」をする期間のように区切ってしまうのは、手戻りが大きくなる原因になると思う。まさにウォーターフォール型の開発がそれなのかな。短いスパンで越境を繰り返し、むしろいまデザインをしているのか、エンジニアリングをしているのか、それすら区別つかない状態が理想なんだろう。

ただ逆に、超越をするタイミングは注意したほうがいいと思った。越境が問題を解決する方法なら、超越は問題を定義する方法だと思う。これを短いスパンで繰り返す、特に複数人が関わるプロジェクトでやると迷走の原因になると思う。

Inspired: 顧客の心を捉える製品の創り方 のなかで、「何を作るべきかを決める」時期と、「決めたものをうまく作る」時期は、分けたほうが良いという話があったが、これと同じなのかなと思う。自由に行き来するのか、時間的な制約を作るのか、この違いは大きそう。

ただtakramでは、ストーリーウィービングと呼ばれる手法として、むしろこの具体と抽象の行き来を自由にすることを推奨しているみたい。takramという組織全体が、越境性と超越性を持っているからこそできる技なのかなと感じた。個人でやるのはまだしも、組織全体でそれをやれるのは凄いな。。。

おわり

その他にもプロトタイピングに対するtakramの考え方や、プロダクト・リフレーミング、ストーリーウィービングと呼ばれる手法、それらを実際のクライアントワークで適用した事例がでてきて面白い本でした。takram自体に凄く興味が湧いた。

分量的にさくっと読めるので、モノづくりに関わる人にはおすすめしたいです。