及川卓也氏がグッドパッチのアドバイザリーボード就任―エンジニアリングとデザインの垣根を越える

グッドパッチのプロダクト&テクノロジーのアドバイザリーボードメンバーに、及川卓也氏が就任することになった。
及川氏はグッドパッチのミッション「デザインの力を証明する」と、「デザインと技術をつなぐ」というエンジニアのミッション・ステートメントに、以前から注目していたという。
アドバイザー就任を機に、グッドパッチCTOひらいさだあき氏と、デザインとエンジニアのこれからを語ってもらった。

デザインに興味を持ったきっかけ
エンジニアとデザイナーの間にもっと共有言語を
「デザインを科学する」という視点
クライアントワークと自社プロダクト開発のシナジーを発揮する

あなたの知らない自分を発見できる。「グッドポイント診断」（無料）

デザインに興味を持ったきっかけ

ひらい：私は大学生のときからJavaを使っていて、新卒で入社したSIerで、JavaやLinuxを使った業務システムやインフラの構築をしていました。ずっとエンジニアをやっていたのですが、美術館巡りをしたりフォントについて調べたり、アートやデザインは好きでした。

ただ、SIerにいると周りにデザインを専門に担当する職種の人はいないし、デザインの価値を強く意識することはあまりなかったんですね。

その後、カカクコムに転職して「食べログ」の開発を担当するようになると、デザイナーとディスカッションしながらWebを設計して実装するというのが当たり前になりました。そこで、デザインへの興味がより明確になってきたんです。

例えば、エンジニアとしてはデータベースをどのように設計すると、システムにとって最適な構造になるかといったことを考えていました。そこから情報をわかりやすく伝え、受け手が情報を探しやすくするための情報設計、インフォメーション・アーキテクチャ（IA）にも関心を持つようになりました。

▲株式会社グッドパッチ　執行役員 CTO ひらいさだあき氏

及川：ちょうどWebの世界ではHTML5の規格策定が進んでいたころですよね。HTML5が正式に勧告されるのが2014年10月のことですから。

ひらい：そうなんです。モバイルファーストとかレスポンシブウェブデザインという言葉もよく耳にするようになり、Webやスマホの世界が大きく変わる予兆を感じていました。だったら、いっそのこと、これまでの経験を踏まえ、エンジニアだけれど、もっとデザインに関われる環境に行きたいなと思って、2015年1月にグッドパッチに転職することになります。

及川：私はひらいさんがグッドパッチに転職されることは存じ上げていて、グッドパッチでどんな仕事をされるんだろうとウォッチしていたら、入社1年後にはCTOに就任された。

ひらい：CTOになって初めて取り組んだのは、グッドパッチのエンジニアは何をする仕事なのかを定義すること、つまりミッション・ステートメントを策定することでした。社内のエンジニアとたちと議論し、それをワーディングしていきました。

グッドパッチにはビジョンとして「ハートを揺さぶるデザインで世界を前進させる」というのがあります。そのビジョン実現のために、エンジニアは何ができるのか。一言でいえば、「エンジニアはデザインと技術をつなぐ仕事だ」ということ。

その言葉には単に技術が高いだけでなく、技術を使ってどういうデザインにつなげていくかまで考えてほしいという思いが込められています。データとユーザーの間に立って、かつ技術の力でよりよいユーザー体験を作り出すのが、グッドパッチのエンジニアだと思ってるんです。

最近は、会社全体で「OKR（Objective and Key Result）」を導入しています。

例えば、一人のエンジニアがSketchのプラグインを開発するという目標を立てたとします。単にエンジニアとして面白そうだからそれを作るというだけでなく、そのプラグイン開発が「デザインの力を証明する」という会社全体のミッションにどういう成果をもたらすかが、OKR導入後はより意識されやすくなったと思います。

エンジニアとデザイナーの間にもっと共有言語を

及川：私はこれまでの経歴の中で、エンジニアとプロダクトマネージャーの両方をやってきました。とりわけプロダクトマネージャーの仕事はUXデザインと密接にからむものです。

プロダクトが成功するためには、多くのユーザーに使ってもらうことが欠かせない。ユーザーの目的をいかに達成できたかも成功の条件です。その意味ではプロダクトとユーザー体験は決して切り離すことができないもの。決してデザインの専門家ではないけれども、プロダクトのデザインは常に意識していました。

例えば、プロダクトの方向性をペーパープロトタイプなどでデザイナーに伝えたり、時にはユーザーインタビューをデザイナーと一緒にやったり、バリュープロポジションキャンバスを使って、顧客に提供すべき価値を見いだしたり、というようなこと。

こうしたデザインへの意識は、業務や職種としてのプロダクトマネジメント（マネージャー）に限った話ではなく、実はプロダクト開発に関わるすべての人、もちろんエンジニアにも求められるものではないかと常々考えてきました。

▲プロダクト & テクノロジーアドバイザリーボード　及川卓也氏

もともとコンピューターというのは、最初の頃はその複雑な操作体系にユーザーが合わせるものでした。コマンドを伝えるためには、キーボードなどから文字列を打ち込まなければならなかった。

しかし、WindowsやMacintoshの登場と共によりグラフィカルなインターフェイスが普及していきます。単にコンピュータは命令に応じて仕事をすればいいというのではなく、その操作体験をいかに快適なものにするか。ユーザーにとっての使いやすさの価値が重視されていくようになるのです。

コンピューターのUIが、CUIからGUIへ変化してきたように、Webもよりユーザー体験をリッチにする方向に進化してきたと思います。

特にWeb2.0以降は、さまざまな情報を動的にかつインタラクティブに扱えるようになってきた。その背景には、HTMLとスタイルシートの分離やJavaScriptのめざましい拡張があります。

こうした時代に、プロダクトにおけるUXデザインの重要性はますます重要になる一方です。エンジニアはたしかにプロダクトの背後で動くコードを書く人たちですが、そのプロダクトがどういう製品であって、ユーザーにどういう体験をもたらすかは、エンジニア全員が強く意識していないといけません。

ユーザー体験をよくするためには、どういうコードを書くべきか、というところまで落とし込んで開発をすることが大切だと思うんです。

ひらい：Webやモバイルアプリを支える技術は複雑になってきましたが、同時に標準化も進んできました。Webの仕様策定は進み、iOSにはヒューマンインターフェイスガイドライン、Androidにもマテリアルデザインガイドラインが整備されています。だからある意味では作りやすくなったとも言えるのです。

ただ、サービスの独自性を出すためには、単にガイドラインに準拠していればいいというものでもない。ガイドラインを理解した上で、どう使いこなすか、どう外すかというところにこそ開発の面白みがあると思います。

技術が発展すると、職種の分化も起こると思います。普段はアプリを書いているエンジニアでも、よりデザインに詳しい人を、「デザインエンジニア」とか「UXエンジニア」という呼び方で区別する動きが海外では顕著です。

以前からあるUXデザイナーとUXエンジニアの違いは、後者がコードを書けるということだと思いますが、その境界は限りなく曖昧になってきました。

職種の分化と同時に融合も起こると思います。デザイナーからは簡単なコードなら自分で書いて直したいという欲求は増えているだろうし、JavaScriptやCSSだけでできることも増えてきて、それを可能にするツールもあります。

一方でエンジニアからも、デザインを自分でもやってみたいという人が出てきている。垣根を越えようとする人が増えていくのは面白いですね。

及川：その場合、向かっている方向をちゃんと共有できているかは重要ですね。目標に向かって進んでいくときのコンテキストが共有できているか。デザイナーとエンジニアの間でどれだけの言葉が共有言語化されているか。その共有言語の厚みがあればあるほど、組織は強くなりますから。

ひらい：もともとグッドパッチのエンジニアって、デザインが好きな人ばかりです。エンジニアがパフォーマンスチューニングしてサイト表示を速くするのは、それがユーザー体験を向上させるためだと意識してくれています。それを意識するかしないかは全然違いますからね。

また、僕自身がIAの専門家ではないけれど、IAの知識を多少でも身につけると、なぜここにそのボタンがあるのか、このタグにはどういう意味があるのかなどを、デザイナーと共有の言語で議論することができるようになります。そうした議論を経ることで、意味のあるデザイン、意味のある実装ができるようになります。

「デザインを科学する」という視点

及川：私がグッドパッチという会社に興味を持ったのもそこなんですよ。2017年6月に独立していろいろな会社とのお付き合いが増えてきましたが、多くの企業がグッドパッチからデザイン開発にあたって支援を受けていることを知りました。

Webサイトやモバイルアプリのプロトタイピングツール「Prott」も正直、最初はグッドパッチのプロダクトであるとは知らなかったんですが、これを使っている企業が多いことは知っていました。若い人たちのハッカソンの審査員をしていても、これでプロトタイプを作ったという人が多かったですからねえ。

さらに、グッドパッチのエンジニアのミッション・ステートメントである、「デザインと技術をつなぐ、そしてデザインを科学する」という視点は、私の考え方と近いものがありました。

デザインというと感性だけで語られがちですが、その背景にはサイエンスやデータがあるべきです。Googleでも、2つのデザインのうちどちらかを選ぶのかというときには、きちんとしたデータを背景に議論する風土がありました。

デザインを科学するという考え方は、Googleにかぎらず、AppleやMicrosoftなどのグローバルテック企業がみな持っている文化なんです。

私はGoogleではChromeを開発していたわけですが、Chromeが起動すると、瞬間的にユーザーは操作できるようになっていますが、実は他の機能の読み込みはまだ終わっていない。いくつかのモジュールがメモリにロードされている間も、多くのユーザーがやりたい仕事はできるわけで、ユーザーはそこに遅延を感じないで済みます。

また、他の例としては、Googleの検索をChromeから使うと、裏側ではトップの検索結果を先読みして、レンダリングしています。いわゆる仕事が確実に必要とされるかどうかを知る「前」に実行するというもので、それによってその仕事が必要だとわかった「後」でその仕事をしたときに生じる遅延を防ぐ。

コンピュータ用語で「投機的実行」と呼ばれるものですが、これもユーザー体験を向上させるためのエンジニアリングの一つの方法です。こうしたパフォーマンスチューニングのマイクロセカンド単位の積み重ねが、集合して秒単位での変化を生み、ユーザーに「速い」と思わせるわけですね。

ひらい：デザインを科学するというのはあくまでも私たちの願いで、現時点でそれが完全にできているわけではありません。

これまではユーザーインタビューやヒアリングなどのデータをプロダクト開発に活かしてきましたが、今後はより科学的・定量的なアプローチを強めていきたい。そこでぜひ及川さんの経験からアドバイスをいただきたいと考えています。

具体的には、エンジニアリング組織のマネジメントとプロダクトマネジメントの両面でのアドバイスということになると思います。

実はアドバイザリーボードメンバーに就任していただく前に、半年ほどアドバイスを受けていました。エンジニア向けの評価制度、会議体のあり方、OKR導入のポイントなどについて相談相手になってもらっていました。

クライアントワークと自社プロダクト開発のシナジーを発揮する

及川：CTOの役割とか、技術戦略についても話をしましたね。

ひらい：いま多くのスタートアップにもCTOがいる時代ですが、技術に責任をもつスタッフがCTOだけでは、だんだん辛くなっているのも事実。VPoE（Vice President of Engineering）やチーフプロダクトオフィサーを含めて、二頭、三頭体制で技術開発に臨むべきだという考え方も出てきました。そこで当社の体制はどうあるべきか、というようなお話をさせていただきました。

この半年の経験は得がたいもので、そこでお互いに楽しくやっていけそうだという感触をつかんだので、正式にアドバイザリーボード就任をお願いしたという経緯があります。今後は、個々のプロダクトマネジメントや、データの活用などについてもアドバイスをお願いしたいです。