田川 欣哉
takram design engineering 代表

なぜtakramを作ったかというと、僕は、エンジニアリングとデザインのちょうど真ん中を行ってみたいと思っているからです。そしてデザインとエンジニアリングの両方をやることを、「デザインエンジニアリング」と呼ぶことにしました。この言葉は、社名の中に入っています。
学生時代からの思いでした。インターンをしていたメーカーで、デザインとエンジニアリングの両方をやりたいと相談したのです。すると「悪いこと言わないから、エンジニアになりなさい」と言われました。そのひとことに反抗することを、今でもやっているのかなぁ。それは僕の個人的な、今の仕事を選択しているモチベーションなんですけど。

最近よく「wicked problem」という言葉を言う人が増えています。
wickedは「いやらしい」とか「いらいらする」なんですが、wicked problemというのは、解答がそもそも存在しない問題。解決には至らなくてもbetterな状況にしていくのが、現代的な話だよねって言われています。
「solution」という言葉には、なにごとにも解答があるというニュアンスがありますが、現代的な問題はそんなにシンプルではなくなっています。

そういうことに対する、takramのやりかたは？

エンジニアとデザイナーが衝突して、仕事が先に進まないことがあります。もう少しお互いが理解できると、よりスムーズにもっと高い次元に到達できるはずなのに。

磨き合いとかならあっていいと思います。ですが、お互いの不理解や誤解によるレベルの話で時間が浪費されるのはよくないです。
レベルの低い話と高尚な話がごっちゃになっているときがあります。
不理解や誤解っていう部分は、リテラシーのレベルの話でもあるから、例えば3年とか5年とかでなんとかなる。ですが、通訳役として僕らのようなタイプがいたほうがラクかもしれないです。
とはいえ、プロフェッショナル同士が協力をしあって高めあっていくスタイルも、うまく機能すればとても高いレベルまで行けます。僕らはたまたまハイブリッドだったので、ハイブリッド性をうまく活かすカタチで仕事をしています。

エンジニアリングサイドの人が、デザインのほうにも入っていくのと、デザインサイドの人が、エンジニアリングのほうに入っていくのでは、どちらが向いていると思いますか。

takramには最初、エンジニアリングサイドからの人しかいなかったのですが、現在はエンジニアリングサイドからの人が7割ぐらい、デザインサイドからの人が3割ぐらいです。デザインサイドから入ってきた人でも時間をかければ大丈夫、というのがここ2、3年の手応えです。

僕はエンジニアリングからデザインに入るほうが入りやすいかな、と思います。 エンジニアの人はスキルを覚えること自体に興味があるから、デザインの勉強をするときでも、ひとつひとつ積み重ねていくことが平気なタイプが多い。
一方、デザインからエンジニアリングに入る場合は、作りたいモノが明確にあるけどそこに行くまでにものすごく技術の壁がある。そこに行くまでに、たくさん辛いことを乗りこえないといけない。

デザイナーから入る場合のパターンは例えばこんな感じです。まず、ソフトウェアのデザインから入ったら次にソフトウェアのエンジニアリングに進み、その次に、エレクトロニクスのエンジニアリングに飛んでもらいます。そしてさらに、エレクトロニクスのエンジニアリングからメカ設計に行って最後にプロダクトデザインに行く。道のりが長いんですけど。

クライアントワークのときは、ビジネス面とクリエイティブ面の両立が難しいですよね。

Business – Technology – Creativity。この3要素の統合をいかに美しくまとめ上げるか、が重要という話が最近特に多くて。
サービスのデザインは、イコールほとんどビジネスデザイン。で、ビジネスデザインのちょっと先に事業計画があって、事業計画のちょっと先には経営計画があるっていう。だから、ビジネスを無視してモノを作るっていう時代はもうほとんど終わっていると思います。

では、どうやってビジネスのマネジメントを。

打合せやプレゼンのとき、最初にクライアントに申し上げるんです。ここで僕らが話す仮説は半分は正しいかもしれませんが、半分は大間違いだと思います、と。
仮説を作るとき、それが、いい仮説か悪い仮説かを考える部分で、スタックしてしまわないように気を付けています。クライアントにぶつけたとき、どういう反応が返ってくるか。それを聞いて次の仮説を作る。それを何回も何回もやってみます。
そうするとクライアント側も、自分たちが思ってもなかったようなことが口から出てくるタイミングがあって…。
それをどんどんやっていくなかで、仮説の確からしさ、輪郭がつかめてきます。

クライアントは、仮説が間違っているという判断をユーザーテストで出してきませんか。

ユーザーテストは、プロジェクトのプロセスの前半と後半できれいに２つに分けられると思っています。
前半は、アイデアを作るためのユーザーテスト。
後半は、アイデアを確認するためのユーザーテスト。
A/Bテストや簡単なグループインタビュー、n数が入ってくるような調査は、かなり後半の最適化に入ってくるところでやらないと、ほとんど結果が出ないです。
前半では、ユーザーから見たプロダクトの魅力が、不快から満足の間でモヤっと幅のある状態だからではないでしょうか。
広く使われるようなモノを作ろうと思ったら不満な点はひとつでもあってはならない。これは確実にやらなくてはいけなくて、商品の魅力の、下のレベルを決めます。
商品の魅力のアップサイドは、ユーザーテストやマーケティングから自動的に出てくるようなものではない。これは誰かが、独特の視点で作るしかない。これが商品の多様性とかユニークネスを形作ることになります。
後半のフェーズで間違うパターンもあって、ユーザーテストをしながら改善をするつもりが、アップサイドの魅力の部分まで消してしまうような方向で修正をしてしまう場合があるんですね。 このときはデザイナーもエンジニアも、ガンとして反抗する必要があります。だから、後半の調整も、もともとの魅力を考えている人たちが関わったほうが良いと思います。

NDCになにか聞きたいことはありますか。

どうやって人を育てているのですか？ 原さん。

問題意識の共有につきますね。やっぱり一緒に仕事をするしかないと思っています。みんなの仕事の価値をみんなが知る。それぞれの仕事が何に向かおうとしているか、何のためにやっているのか。常にフィロソフィーの共有をやっています。
そして、できるようになったら外に出しますが、NDCの場合、例えば原デザイン研究所の外に出ても、NDCの内側にいられるような仕組みがあります。今の時代、フリーになることは…。

僕らも近いところがあって、できるだけ、独立しないで済むような会社にしたいです。 ゼロから会社を始めてたいへんだったので、人にはすすめられない。優秀な人が、takramの中にいながらも、きちんと自分のフィールドを作れるか。この部分については、すごく時間を使って考えています。