TakramCast「Design Engineeringとは #2」
Takramの中軸を成すDesign Engineeringについて語るシリーズの第２回です。デザインエンジニアはデザイナーやエンジニアと何が違うのか、プロトタイピングの意味と手法、デザインエンジニアになるには、などTakramが日々取り組んでいる実践のプロセスやその背景にある考え方について、Takramの田川と緒方が語ります。
( トークの導入部分は省略して、佳境に入ったあたりから抜粋 )
緒方 そんな経緯が歴史的にもあるっていうところと、そもそもデザイナーにできなくてデザインエンジニアにできること、エンジニアにできなくてデザインエンジニアにはできることって何なのかっていうことがあると思うんですけど。一つはすごくプロトタイピングっていうのを、その両方を行き来することをやっていくっていうところがすごい大きいのかなっていうのがありますね。
田川 ちょっと僕とか緒方くんとかが、日々のプロジェクトの中で、例えば3ヵ月ぐらいのプロジェクトだったときに、どういうプロセスで仕事に入って、3ヵ月目ぐらいに何ができてるのかっていうのがちょっと。だいたいお互い緒方くん的なアプローチと俺的なアプローチで差はあるにせよ、ただ大きなフレームでいくと、似たような流れで多分やってるんじゃないかなとは思うんだけど。まず最初、ヒアリングとかリサーチとかから入るよね。
緒方 そうですね。
田川 調べるところからね。
緒方 まず、その分野のことを知るというか、いろんな分野の職能を追って、それをリサーチして、専門家とか内部の人たちに話をきく。それでまず最初の、いわゆる仮説ですよね、仮説を立てる。仮説を立てたらまずもう作ってみるっていうのが1番大きいところですね。
田川 最初に調べるところでやるのは、とにかく最近たくさんインタビューやるよね。例えば競合関係を知るとか、その技術がテーマの話だったら、技術の根っこの話を、クライアントの結構コアなサイエンティストとかエンジニアの人にきくのはあるし。経営者に将来目指している大きなビジョンの話をきいたりもするし。とにかくたくさん話をきくっていうのは、Takram的カルチャーとしてすごいあるよね。
そこらへんからスタートして、その仮説、コンセプトを作る段になったところから質的な違いが多分出てきて。デザインエンジニアたちは多分、最初の初期仮説ができてからのプロトタイプまでもっていくスピードが多分、スピードっていうか腰の軽さというか、仮説考えているところから手を動かしてもう、プロトタイプに取り組みはじめるっていうあたりは、少しそこは質的な特徴だよね。
緒方 多分、ラーニングカーブ的に最初のリサーチでガーッと学習していって、それがさちりはじめたところで、作りはじめるので。そこでまた新たなアイディアとか気づきみないなところを得ていくっていうから。考えるスピードがはじめインプットを大量にして、そこでいろんなことに気づいて、初期コンセプトが出てきたタイミングで、それを頭の中だけでとどめておかずに、1回かたちにしながら次のステップを目指していくっていうところがすごい大きい。
田川 多分、やってる仕事が前例がないタイプの仕事が多いので、デスクトップでペーパーの上で、仮説を文字とダイヤグラムとかスケッチとかで書いてても、それがいいんだか悪いんだかよくわからないというか。だから少なくとも体験できるものを作ってみて、それを見ながら議論するっていう。
緒方 そうですね。黒本にも書いたんですけど、プロトタイピング3つの機能というか。だから、いわゆる従来的な意味でのPDCAみたいな話から、やって、作ってみて、テストして、改善して、どんどんクオリティが上がっていくっていうのは、もちろんあるんですけど。頭と手を同時に動かしてっていう創造のためのプロセスとしてプロトタイピングを使うっていうことと、もう一つコミュニケーションのツールっていうのは大きいですよね、クライアントワークは特に。
田川 俺、最近やっぱり、プロトタイプをできるだけプロジェクトの早い段階で作ることの一つの意味が、どこらへんにあるのかなって思うときに、さっきのラーニングカーブの話あるじゃない。結局のところやっぱり、どれだけ自分たちが知らない情報を集めてくるかとかっていうところとか、僕らのクライアントってだいたい10年選手とか20年選手が多い中で、自分たちが入っていくときはある程度新参者的に入っていくところがあるので、どれだけその周辺のプロの人たちから、彼らの暗黙知も含めて、情報を引き出してくるか。それをインテグレーションするかっていうところがやっぱり一つポイントになってくる。
コミュニケーションのツールとしてのプロトタイプっていう中の多分、柱の一つになってくるんだけど、面白いと思うのは、プロの人たちに対して、俺たちが最初作る初期仮説のプロトタイプってある意味、穴ぼこだらけっていうかさ。完成された仮説じゃないから、プロの人たちから見ると、間違っているところも結構あるじゃない。もう最近、俺もだいぶん開き直ってるから、今日見せるものは本当に最初のプロトタイプだから、まあ間違い半分、合ってるところ半分ぐらいの感じで見てくださいねとかって言うと、プロの人たちって、間違い探しというか、間違っているところの指摘能力ってめちゃくちゃ高くて。
この技術のコアな部分を教えてくださいとか言っても、結構とおり一遍の説明しか出てこないんだけど、こちらから出したプロトタイプは、ちらっとでも間違っていると、「ここはプロじゃない人にはこういうところわからないよねみたいな」、そういうことも含めてなんだけど、ここは実はそういうことじゃなくて、みたいなことを、たくさんしゃべってくれる傾向があって。間違いを指摘してもらうモードになってもらえると、オープン・クエスチョンでいろいろきくのの2、3倍のコアな情報が結構、相手方から出てくるっていう傾向があって。
それは自分たちの頭の中とかで考えているよりも、アイディア・ジェネレーションのプロセスでいくと、とてもコレクティブっていうか。たくさんの人の頭から、こんこんといろんな情報が出て。まあ、プロトタイプが媒介になってる。それをプロジェクトがはじまって2週間目とか3週間目とかで作っていくから。そうするとプロジェクトの折り返し地点ぐらいまでなっていると、相当量の情報がテーブルの上に自動的に出てくるっていう。
緒方 そこの課題が出てくるっていうか。課題を見つけてもらうところを、相手のプロの人たちに入ってもらうっていう感じなのかもしれないですね。
田川 そうだね。
緒方 それに対して、クリエイティブな解決方法をそこにまた提示していくっていうところが、デザイナー的な部分に今度またなっていくっていう。
田川 そうだね。それで出しておいて、それをまたプロトにやろうとすると、そこでエンジニアリングが必要になってくるので、っていうのの繰り返しだよね。デザインエンジニアリングの一つの面白いところっていうか、旨味の部分って、このプロトタイピングのスピンの速度が、普通のデザイナープラスエンジニアのチームよりも多分速くて。仮に10％でも20％でもいいんだけど、仮に倍ぐらい速いとすると、普通のチームだと2週間かけてワンスピン回すところを、デザインエンジニアの入ってるチームだと1週間ぐらいのスパンでこれを回せるようになるので。
そうすると2、3ヵ月のプロジェクト中で回せるプロトタイプの数が倍とかになると、だいたいそのクオリティの上がっていき方って、間違いが1回プロトタイプを回すと半分になって、もう1回、回すと更に半分になって。だいたい乗数で効いてくる感じがあって。だからプロトタイピングの回す回数を稼げること、イコールスピードが上がる。スピードが上がると、クオリティが自動的に上がっていくっていうようなパターン。
Takramのデザインエンジニアでも経験値の高いデザインエンジニアたちって、とにかくプロトタイピングが速いよね。しかもハードウェアもソフトウェアもある程度頭の中に入っていて、どの手のやつを作んなきゃいけないのかっていうことについても、最短距離で今、議論しなきゃならないポイントに絞ったプロトタイプを、最小の時間で作ってしまうっていうところの引き出しの多さっていうか。
緒方 本当そこに尽きる。
田川 そこだよね。
緒方 その作りながら、何を、ここは省略していいとか、これはでもすごい大事なファクターだとかっていうののセンスっていうか。
田川 見極めがね。
緒方 見極めが。そこ経験だと思うんですけど。
田川 プロトタイプを作るってことが自己目的化しないように、今、何を自分たちが突き詰めなきゃいけないのかっていうことを、毎週毎週その切り替えながら、そこに対してプロトタイプをあてていくような感覚が、非常に研ぎ澄まされているというか。だから、デザインエンジニアリングってそういう意味だとやっぱり、プロセス重視だよね。俺も緒方くんも、すごい優秀なデザイナーたちと仕事しているときに、やっぱり感じるのはアウトプットの質の最終的な高さに、みんなすごくこだわって仕事している人が多いと思うんだけど。デザインエンジニアの場合は結構、プロセス、プロトタイピングをいかに高速に回すかとかっていうところって、アウトプットのクオリティもおそらくこだわってはいくんだと思うんだけど、その途中の回し方のところをすごく、そこに着眼、結構してるなっていうのはあるよね。
緒方 プロトタイピングって一言で言っても、何を作るのかっていうところもあると思うんですけど、1番簡単なものでいうと、スケッチみたいなものも、頭の中にあるものを外に出すっていう意味ではプロトタイピングの役割があって。コミュニケーションツールとして。で、別にいわゆるデザインモックアップって言われるような、最終製品にしか見えないようなものだけがプロトタイプかっていうと全然そうではなくて。いわゆるダーティ・プロトタイプって言われるような、そのへんにあるもので、とにかくその場で作るみたいなものもあるし。実際どうやって作るのかっていうところを試す機能的な試作みたいな、テクニカルなプロトタイプっていうのもあるし。見た目をそれこそモックアップとして、見た目の印象みたいなものを確かめるっていうものもあるし。その粒度に応じて、いろんな引き出しを使って、そのときに最適なプロトタイプを作っていくっていうところがすごく大事になってくる。
田川 そうだね。一方で、エンジニアと比べたときのデザインエンジニアのいわゆる動きの質の違いっていうのも、今、デザイナーに対する質の違いのようなところでプロトタイプって、結構際立ってるなとは思うんだけど。一方でエンジニアでプロトタイプの理論で、普通にソフトウェア開発やってる人たちもわんさかいて。それとの差、というか動き方の質の違いでいくとどうなんだろうね。
緒方 一つは多分、目線が複眼的にその課題を捉えていくっていうところかなと思うんですよ。エンジニアリング的に解決できるところと、エンジニアリング的には解決が難しいんだけど、それってデザイン的にはこんなふうにすれば簡単に解決できるんじゃないかみたいなことに気づけるか。違う方向から見たらすごい簡単な問題とか。それがこうビジネスみたいなところ、視点として入ってくると、より俯瞰して、仕組みを変えていこうとかっていうことに気づける。細かいミクロな課題を解決するところから、いかにジャンプできるかみたいなところが、PDCA的なプロセスとの違いなんじゃないかなっていう気がしますけどね。
田川 あとは最終商品との、いわゆるプロトタイプの差っていうのも結構あるなと。優秀なエンジニアの人たちが作るプロトタイプで、ファンクショナルなプロトタイプなんだけど、それが店頭に並んでる感じがしないとか。ソフトウェアの場合だと、ワイヤーとか画面遷移はすごくよくできてるんだけど、ユーザーテストしようとするとそのクオリティに達してなくて、みたいな話ってあるじゃない。
そうするとまたその時点で、デザイナーにその意匠の部分をお願いして、っていうような人も結構いるんじゃないかと思うんだけど。デザインエンジニアの場合は、かなり最終商品を知ってるからね、ある程度。ハードウェアであれば、外側の意匠まで作り込むし。ユー・アイとかだと、画面のデザインのところまできっちり作り切るっていうか。っていうことで、いわゆるそれを見た人から返ってくるフィードバックも、これ試作でしょ、みたいな、いうようなことじゃなくて、どっちかと言うと、こういう商品なんですね、っていうようなレベルでのフィードバックが返ってくるというところは、デザインのエクスパティーズをもってるから、引き出せることなのかなと思ったりもする。
緒方 そうですね。だから、そこの本当に外しちゃいけないディテールは何なのか。全部作ったら、全部プロダクツ作ることになるので。そうじゃないんだけど、ここはプロトタイプだからいいよねって外しちゃったディテールが、実はすごく重要なファクターになっていたっていう可能性もあって。そこの見極めみたいなところが、単純な機能性とかで測れない。スクロールが気持ちいいかどうかとか。そういうことがすごく体験としては影響するような場合もあるし。そのときはそこの部分はすごく丁寧に作るような気持ちとか、そういうことが大事だなと。その両方にちゃんと目が行き届くっていうのが、優れたデザインエンジニアなのかなっていう。
（トークの全テキストは↓からどうぞ）
Takram Castは、Takramのメンバーがデザイン・テクノロジー・ビジネス・文学などの話題を幅広く展開する無料のポッドキャストです。毎週月曜日に2本のペースで公開しています。iTunesでの登録はコチラ↓
SoundCloudでの登録はコチラ↓
Takramは、東京・ロンドン・ニューヨークをベースに、さまざまなプロジェクトに取り組んでいます。 Takramには、デザインとエンジニアリングの両分野に精通するデザインエンジニアを中核に、プロダクトデザイナー・グラフィックデザイナー・ビジネスデザイナー・マーケッター・教育者といった多様なプロフェッショナルが集っています。
この記事が気に入ったらサポートをしてみませんか？