イノベーションは、好奇心を突き詰めた先にしか生まれない ── デザインエンジニア松田聖大が追う“その先の”可能性
打ち上げ成功が記憶に新しい次世代の大型基幹ロケット「H3」の、飛行状況をリアルタイムで可視化する「H3 Flight Status Indication System for Public (H3 FIP)」や、国土交通省が主導する日本全国の3D都市モデルのオープンデータ化プロジェクト「PLATEAU」のビューワー「PLATEAU VIEW 3.0」のプロトタイピングなど。常にわたしたちの想像を遥かに超えたアウトプットで驚きをもたらすデザインエンジニア・松田聖大。デザインエンジニアが多く集まるTakramのなかにあってもひときわ異彩を放つ松田を、ものづくりへと向かわせる衝動の源泉とは ──。
Text by Asuka Kawanabe
つくりながら考える
── 聖大さんはTakramのデザインエンジニアとして活躍していますが、小さいときからプログラミングやデザインに興味があったのですか？
そうですね。小学校のときには家にMacがあったのでIllustratorやPhotoshopを使っていました。プログラミングは中学校くらいからです。そのころは、SoundJam（Mac用音楽プレーヤーソフト）のスキンをデザインしたりOSの見た目をいじったりという、UIデザインに近いこともしていました。
── そもそもなぜ見た目をいじろうと思ったのでしょうか？
見た目が許せないという理由が大きかった気がします（笑）。エイリアシングとか。
── その衝動はいまも続いていますか？ この一連のツイートもそうですが、機能と美しさの両立はとても聖大さんらしい気がします。
このあたりの社会的な問題を解決するのはデザインエンジニアリングを掲げる Takram が果たすべきミッションかもしれませんね。
— Shota Matsuda 松田 聖大 (@shotamatsuda) May 20, 2023
衝動はありますし、今でもやってますよ。機能と美しさの両立をテーマに考えることはあまりありませんね。あのツイートは機能と美しさではなく、仕様化の話をしてたんです。ソフトウエアやビジネスの世界では、企画をして仕様化をしてからつくるという流れでものづくりが進むことがありますが、実際につくってみると予め決められた仕様がおかしいことはザラにあります。
そうではなく、つくりながら仕様化していくほうが最終的にいいものになることが多いです。仕様を考える段階では、シーズの可能性と限界や、ユーザーが求めているものが分かっていないことが多くあります。仕様を決めきってからつくるという順番だと、そもそも考えていることの筋が悪かったり、ユーザーが求めていないものになる危険性が高いということです。それらを明らかにするためにつくりながら考える必要があって、プロトタイプが必要というお話でした。仕様化してからつくり始めるという順番になってしまう事情も分かるのですが。
── エンジニアとしての自分とユーザーとしての自分の振り子を振りながらプロジェクトに取り組んでいるんですね。
そうですね。プログラムのすごいところは、実行するとすぐに結果が出ることです。ユーザーに成り代わって触ってみて感覚にフィットするかを確認して、違和感があったら修正して再実行するというサイクルがつくれる。ビジネスでこれと同じ速度の試行をするのは難しいですよね。
あと、ぼくは自分がつくったものを捨てることに慣れています。つくるなかで何回もやり直すので、その度に自分がつくったものを捨てます。過去につくって蓄積したものもすぐに古くなります。2年前に書いたコードは見られませんよ（笑）。つくったもの自体には、それをつくることができるという可能性ほどの価値はないと思っています。できたものの知覚的な気持ちよさや美しさは時間が経っても変わらないかもしれませんが、その裏側は相当古くなるし、意味が薄まります。
リアルタイムデータを可視化する
── その蓄積でいまがあるんですね。聖大さんのプロジェクトのなかでも、一般の人の目に多く触れたものとして、次世代の大型基幹ロケット「H3」の飛行状況をリアルタイムで可視化するシステム「H3 Flight Status Indication System for Public (H3 FIP)」があります。このプロジェクトでの挑戦はなんでしたか？
いくつかありますが、いちばん大きいのはリアルタイムのデータであったことです。これまで統計データや記録は多く扱ってきましたが、リアルタイムデータは次にどういうデータが来るかわからないという意味で全然違います。
例えば、飛行経路の微分をとるには連続したデータが必要になりますが、先端部分で微分をとろうと思っても今まさに動いているからまだデータがない。だから、常に半歩前の時間を「今」として扱うことになるし、どのくらい遡れば半歩前となるかも処理の種類によって変わってきます。「今」が一つではないということですね。
このプロジェクトには、ロケットの時刻と射場系の設備の時刻、H3 FIPの端末の時刻、画面に表示される時刻という計4つの異なる時刻が関係します。例えば、ロケットの中で何かが起きたとして、それが種子島宇宙センターに飛んでくるまでと、そこからさらにプログラムにデータが飛んでくるまでの時間、そしてそのデータがH3 FIPのシステムに表示されるまでの時間によって時刻にズレが起こります。普通は端末の時刻を「今」としていればいいのですが、異なる4つの時刻とそのズレを正確に扱うのが難しいところでした。加えて、空間があまり固定されていないことも課題になりました。
「H3 Flight Status Indication System for Public (H3 FIP)」
── 空間が固定されていないとは？
例えば、地球上で位置を表す場合には地表面を基準にした座標を使って、緯度・経度で正確な位置を表せます。あるいはもっと小さい空間ならば、地表面の一点を原点として固定するような直交座標で表せますよね。それはわたしたちが地球の自転と一緒に動いているからです。
ロケットの場合には最終的に慣性飛行をすることになり、その間にも地球は自転します。慣性飛行というのは推進力がないボールと同じです。それを地表面を基準にした座標系であらわすと、外力がないのに螺旋状に曲がって飛行するように見えてしまいます。これを避けるために座標の基準を慣性空間に固定するのですが、単にそうすると打ち上げ直後からリフトオフした地点が地表をすーっと移動していってしまいます（笑）。これでは正しいけど分かりやすくないので、両方の表現が必要ということですね。これが何を意味するかというと、「いつ」「何を基準にして」ロケットの飛行経路を見るかによって同じ経路でも空間表現が変わるということです。ではどうすれば基準が慣性空間に固定していると見なせるかとか、本当にそれができているかといったことは、かなり調べて検証しましたね。
── 膨大な量の勉強が必要になりますね。
そうなんですよ（笑）。プロジェクトを始めたときは、こういうことを知らない素人状態でしたので。わからないことを潰したくなるという性格もあって、かなり調べますね。
── 知らなくてもできることかもしれないけれど、そこを無視したくないんですね。
気持ちとしてもそうですし、ちゃんと理解したうえでできるものと、知らずにできるものには違いがあると思います。例えば、色を表す値が同じでも、印刷やディスプレイなどのメディア（媒体）によって色の出方が異なるのはよくありますよね。「同じデータなのに見え方が違う」と思ったとき、それが何によってどのように生じるかを知っているか知らないかで、問題の原因を把握して対処できる速度と正確さは変わってきます。
興味を突き詰めた先に生まれる可能性
── プロジェクトにおいて、クライアントとのコミュニケーションの面で気をつけていることはありますか？
何をしてほしいか、直接聞かないことですかね。「何をつくればいいですか？」「ボトルがほしいです」というコミュニケーションをしないとか、ボトルと言われたときに「なぜボトルが必要なのか」を考えて水を返すとか。もちろん、それは誰に聞くかによっても変わるのですが。
── 言われたことに対して1対1のアウトプットをしないということですね。
それだとその人の予想の範囲内に収まってしまうんですよね。『プラネテス』というアニメ化もされた漫画があるのですが、ご存じですか？
非常に簡単に説明すると木星を目指すお話です（笑）。そのなかで、主人公の星野八郎太が、実在したロシアの物理学者コンスタンチン・ツィオルコフスキーの「地球は人類にとってゆりかごだ。だがゆりかごで一生を過ごす者はいない」という言葉を引用して、宇宙に行くのは人類の使命だと語る場面があるんですね。
これに対して、主人公の父親で凄腕の宇宙船機関士でもある星野五郎はこう返すんです。「だまされてるぞ。そいつぁツィオルコフスキーのついたウソだ。20世紀初頭に宇宙旅行を夢みたロシアのおっさんがそれを叶えるために一発吹いたのさ。大先輩は頭がいいから自分の欲望を人類全体の問題にすりかえたんだ」
このやりとりは印象に残っています。いま重要だと思われていることって、おそらく誰かが自分の興味を突き詰めた結果なんだと。逆に誰かが義務感でつくったものって、僕はおもしろくないと感じることが多いです。好きだからとか、興味があるからといった理由で突き詰めたほうが圧倒的に深いところまで行けるし、気持ちいいものになってたりするんですよね。
── 義務感だと課題に対してゴールが決まっているけれど、好きだとその先が見たくなりますものね。
これは先ほどの仕様の話にもつながっていて、仕様化するとその先に行く必然性がなくなってしまうと思います。さらにそれを興味がない人が扱うと、絶対にその先にはいけない。本来、仕様を考える段階ではその先に何があるか誰もわかっていないはずで、その先にある可能性はつくって試してみないとわからない。もちろん、その可能性を突き詰めるかどうかも好きかどうかによるのですが。
── そうして突き詰めた結果が、クライアントにとってもベストというのがすごいですよね。
お互いにベストであることは基本ですよね。「ぼくがいいと思うものがあなたにとってもいいんですよ」ということを毎回つなげているわけじゃないですか。それをどうつなげるかは、常に考えています。
── ちなみに、聖大さんにとっておもしろいと思うプロジェクトの基準はなんですか？
そこはあんまり深く自分に問いただしたことがなくて、何をおもしろいと思うかはよくわかっていません。ただ、プログラムのように何度でもイテレーションを回して試行錯誤できる問題は好きですね。だから、自ずとコンピュテーションに関わるものになります。
ただ、それはソフトウエアである必要はありません。例えば、日本精工株式会社（NSK）との「＿＿with MOTION & CONTROL」というプロジェクトでは、映像をつくる前段階で何度も機構や制御システムの設計をシミュレーションをしていますよね。そうした営みは結構好きです。
── 聖大さんはデザインエンジニアとしてデザイナーの領域もエンジニアの領域も手がけているわけですが、エンジニアとしてTakramのプロジェクトの楽しさはどこに感じていますか？
ゼロイチでプロジェクトに携われることだと思います。エンジニアをしていると、自分が思う最適なアプローチをとれない場面が大量にあるはずです。過去から積み上げたものを資産として見るがゆえに、破壊的に新しいことを採用できない。でもTakramのプロジェクトはゼロイチのものが多いので、そうした制限が少ないです。そのぶん、筋のよさが問われますし、先ほどの価値の接続も必要になりますが、制限にフラストレーションを溜めている人はぐんぐん伸びる環境だと思います。
── そもそも聖大さんはひとりでも仕事が出来てしまう気がするのですが、あえて組織やチームに所属しているのはなぜですか？
自分が好きなことを突き詰められる環境であることがいちばんの理由です。手放しでそれを享受できるというわけではないですよ。そのための努力をしてるわけですが（笑）。ただ、Takramの前はフリーランスの時期もあったので、ひとりで仕事をする大変さは知ってます。プロジェクトの遂行に集中できるようにするための仕組みや認知、支えがなければ、ひとりでは実現するのが難しい環境というのはあります。
一方で、プロジェクトの中に限った話をすると、よく「チームでやったほうがいいものができる」と言う人がいますが、それについては個人的にはあまり信じていません。人が集まることによって品質が上がることは限られていると思っています。ただ、できることは増えるでしょう。規模の大きいこともできる。そこに魅力を感じる人もいるでしょうね。ぼくの場合は規模の大小にあまり興味がないので、その意味ではプロジェクトをチームでやっても個人でやってもいいという考えにはなってしまいますね。
── 自分自身の分析がしっかりできていますよね。一つひとつの分析の解像度がとても高い（笑）。
それは癖かもしれないですね。Takramに来てから、こういうことしかしていない気がします（笑）。
松田聖大｜Shota Matsuda
デザインエンジニア, ディレクター
インタフェースデザインからソフトウェアエンジニアリング、プロダクトデザインなどを手がける。1986年京都生まれ。文字の技術に興味を持ち、デジタルタイポグラフィにおいて未踏IT人材発掘・育成事業スーパークリエータ認定。慶応義塾大学環境情報学部卒業。東京大学大学院学際情報学府中退。大学研究員、ITスタートアップなどを経て、2013年よりTakramに参加。主なプロジェクトに「TAMRON New SP Series」のプロダクトデザイン、地域経済分析システム「RESAS」のプロトタイピング、freeeのリブランディング、H3ロケット飛行状況の可視化システム「H3 FIP」のデザイン・開発、受賞歴としてグッドデザイン賞金賞、Red Dot Design Award、iF Design Awardなどがある。
この記事が気に入ったらサポートをしてみませんか？