今年4月に行われた『UI Crunch #8』のレポートでも触れた通り、これまで業務内容的にも文化的な意味でもやや断然している感のあった【デザイン】と【エンジニアリング】という2つの領域は、ここへ来て互いの距離を縮める必要性が議論されてきている。

サイバーエージェントが掲げた「テクニカルクリエイター」のように、領域横断的な新職種も登場しており、他にも両者の間を有機的につなぐために各社が取り組みを進めている。

こうした動きが活発化した背景には、ユーザー体験の質が競合優位性になる時代が来たことなどとともに、新たに登場したツールが果たしている役割も見逃せない。

グッドパッチのプロトタイピングツール『Prott』はその代表的な例であり、スタートアップ界隈でその名を耳にする機会が急速に増えた印象だ。「UIデザインカンパニー」を自称する同社は、今ある業界の流れを先導してきた1社と見ることができるだろう。

では、そんなグッドパッチにいるエンジニアとデザイナーは、実際にどのようにして仕事を進めているのだろうか。こうした文脈で今回取り上げるのが、同社の自社プロダクト第2弾となる『Balto（バルト）』のAndroid版開発チームである。

文字どおり机を並べて没頭した14日間のキャッチボール

『Balto』は、アプリ開発時に見つかった改善ポイントを素早くチーム内で共有するためのフィードバックツール。SDKを入れてワンアクションするだけで、アプリに直接コメントを残すことができるため、レビューからの改善サイクルを高速で回すことが可能になる。

プロジェクトが立ち上がったのは昨年9月。発案者であるプロダクトマネジャーの竹田哲也氏の下、iOSとWebのプロダクトが先行して開発されたが、Androidの開発が始まったのは最近で、β版の公開までは実働14営業日に満たなかったという。

スタートアップならではのスピーディな開発スケジュールの下でこの開発を担ったのは、デザイナーのカワマタさとし氏と、エンジニアの荒武祐一郎氏だ。

彼らにはなぜ、このような「超爆速」（カワマタ氏）の開発が可能だったのか。ここに、デザイナーとエンジニアのあるべき関係性を紐解くヒントがある。

「まるでデザインのキャッチボールをしているような感覚だった」。濃密な2週間を2人はそう表現する。その仕事ぶりはこうだ。

早く来た分早く帰ることができるフレックス制度を活用して毎朝8時に出社すると、2人は決まって隣り合った席に座る。やり取りは1画面ごと。カワマタ氏は自らのイメージをデータに落とし込むと、すぐに荒武氏に手渡し、荒武氏が実装している間に次の画面に着手する。一方の荒武氏も実装が終わるとすぐにカワマタ氏の意見を求め、そこで生まれた新たなアイデアがまた、即座に次の画面に反映される……。退社する午後5時まで、こうしたやり取りが毎日延々と繰り返された。

グッドパッチでは、普段は『Asana』や『Trello』といったタスク管理ツールを用いることが多いというが、阿吽の呼吸を伴った最小単位のチームにそうしたツールは必要なかった。2人の席の間に次々と貼られては剥がされる付箋の山が、十分にそれらの役目を果たした。

デザイナーはエンジニアが自分のイメージをしっかりと形にしてくれることに喜びを感じ、エンジニアはデザイナーの喜ぶ様子を見ることでさらにモチベーションを上げる。そのことが2人のやり取りをより加速させ、アイデアの質を向上させたという。

「野球のキャッチボールを長く続けていると、次第に上達して捕って投げるのサイクルが早くなるじゃないですか。デザインのキャッチボールもそれと同じ。繰り返すほどにその速度は上がっていきました」（荒武氏）

「モチベーションが高いからアイデアも次々と生まれる。その度にスポーツのチームのようにハイタッチを繰り返しました。ものをデザインする上での理想的な状態だったと思います」（カワマタ氏）

大企業であれば顧客や社内事情もあり、より大きなチームで動く必要も出てくる。しかし受託事業も自社事業も小さなチームで開発を行うのが、グッドパッチのスタンダードだ。デザイナーとエンジニアが物理的な意味で「近くに身を置く」ことは、良いプロダクトを生み出す上で、重要なポイントの一つであると考えられている。

デザイナーとエンジニアが自然と歩み寄る社内文化

2人が阿吽の呼吸で仕事を進められたのには当然、前提がある。「デザイナーがエンジニアを理解し、エンジニアがデザイナーを理解しているグッドパッチだからできたこと」とカワマタ氏は言う。

「グッドパッチはデザインの会社なので、デザインの力を信じていて、デザインの重要性を理解しているエンジニアしかいません。実際、ビジュアルデザインはできなくても、情報設計は分かるしデザインの“勘所”も分かるというエンジニアがほとんど。だから今回も、こちらが『こういうモノを作ってください』と言うのではなく、一緒になってデザインしているような感覚でした」（カワマタ氏）

グッドパッチには、世に言う「デザインエンジニア」のような人材がそろっている。しかし、デザイナーがエンジニアリングを理解し、エンジニアがデザインを理解するための仕組み化された研修のようなものは現状、存在しないという。

エンジニアが技術の勉強会を開くと言えば、自然とデザイナーも参加する。それとは逆に、エンジニアがデザインツールの使い方やデザインの基本的な考え方をデザイナーに尋ねることも、自然と行われている。

さらに、話題のアプリや気になるサービスのUIについて、エンジニアもデザイナーもそれぞれの立場から井戸端的に語り合う「UI談義」は、グッドパッチにおける日常の風景なのだという。

仕組み化されたものがないとすれば、こうした文化はどのようにして醸成されていったのか。竹田氏は、「昨日今日にできたものじゃない。そもそもデザインが好きという人に入ってもらっていることが大きい」と、採用にその要因があると見ている。

実際、荒武氏もレガシーな業務システムを扱うことが多かった前職からグッドパッチへと転職した動機について、「もっと良いもの、ユーザーに喜ばれるものを作りたいという思いが強かった」と語っている。そんな彼が「『Sketch』や『Photoshop』といったデザインツールを扱うのが好きで、触っているうちにいろいろと身に付けてしまった」というのは、確かにどんな研修よりも強力な推進力のように感じる。

重視したのは「まろみ」。言語化したコンセプトがイメージ共有を強固にする

今回のAndroid版開発に際して、プロダクトマネジャーの竹田氏はリリース直前のタイミングで幾つかの軌道修正をリクエストした他は、基本的にカワマタ氏と荒武氏がリードして開発を進めていたという。

それが可能だったのは、機能的にはiOSが先行していたからというのもあるが、同時に「どんなものを何のために作るのか」という点についてチーム内でしっかりと共通認識を築いた上でスタートできていたからだ。

具体的に言えば、『Balto』にはチーム内で共有している「まろみ」というデザインコンセプトがあった。一般的には味覚を表現する際に使われるこの言葉は、ある穏やかな朝のやり取りの中で生まれたという。

カワマタ氏は『Balto』のデザインコンセプトを考えるにあたり、まずこのサービスが提供する価値について考えた。それは究極的には、「より多くのフィードバックが行われることにより、プロダクトの品質を高める」ことにある。

「一つの行為が日常的にたくさん発生する、つまり習慣化するためには、その行為が行為者にとって心地よいものでなければならない。僕の場合で言えばそれは、奥さんが作ってくれる毎日の朝ごはんであり、出社後に荒武さんが淹れてくれるコーヒーのようなものでした」（カワマタ氏）

そう、コーヒー。コンセプトについてのアイデアを交換していたその日の朝も、手元には荒武氏の淹れた「まろやかな」コーヒーがあった。イメージはそこから広がり、そのまま「まろみ」というデザインコンセプトにつながった。

「まろみ」のあるデザインとは、インタラクションで言えば曲線的なもの、ビジュアルデザインで言えば角が取れていて柔らかみのある色味のものを自然と連想させる。その点でも、「まろみ」はデザインの言語として最適と言えた。

こうしてチーム内でブレのないデザインコンセプトを共有できたことが、作業も意思決定も速い「超爆速」の開発を実現する礎になった。特定の言葉に落とし込むことでイメージの共有を図るのは、カワマタ氏の常套手段という。

結果として『Balto』は、広い意味で言えば業務システムに分類されるサービスでありながら、業務システムという言葉が持つ堅いイメージからはかけ離れたプロダクトになった。

実は、カワマタ氏も荒武氏同様、前職では比較的レガシーなシステムを扱っていた。デザインコンセプトが味覚由来というと突拍子のないことのようにも聞こえるが、業務システムを「デザイン中心」に開発するとどうなるかということを、2人は肌感覚として知っていたのだ。

コードの書けないデザイナーに未来はあるか？

冒頭でも触れたように、領域横断的な職種や人材の重要性が叫ばれるのは、一つの時代の要請のように見える。一方で、エンジニアにおけるフルスタック論争のように、1人ですべてをまかなうのは現実にそぐわないとして、たびたび物議をかもすことも確かだ。

この点について、2人はどのように考えているのだろうか。

「グッドパッチにおいてはデザイナーが主役なので、個人的なKPIは『デザイナーと一緒に心地よくプロダクトを生み出せるか？』に置いている」と話す荒武氏は、「エンジニアがデザインを、デザイナーがエンジニアリングを全く理解していないのは論外」としながらも、1人で何でもできなければいけないという風潮には首をかしげる。

「今回、自分は実装に専念できたし、カワマタさんにはデザインに専念してもらうことができました。それで何の問題もなかったんです。デザイナーがエンジニアリングをしなければならなくなるというのは、もしかしたらエンジニアに、デザインを正しく理解した上で実装する力が不足していることが原因なのかもしれません」（荒武氏）

カワマタ氏もまた、「コードが書ける必要性はない」という意見を持っている。

「コードを書かないデザイナーは、今、とても焦っていると思います。でも、だからと言って自分でコードを書こう、というのは一種の思考停止ではないでしょうか。リソースは限られているのだから、自分が興味のあるところ、伸ばしたいところに向けた方がいいというのが持論です」（カワマタ氏）

エンジニアが自らデザインをする、デザイナーが自らコードを書くことの代案を挙げるなら、やはりチームで仕事をするということになるだろう。

自分にできないことがあるのなら、それができて、かつ自分の世界観や価値観に共感する人を探して組めばいい。普段から考えていることを言語化して発信していれば、自然とそういう人が集まるはず。これが彼らに共通する考え方だ（カワマタ氏にはまさに、デザイナーが自らコードを書くことの是非を論じたブログエントリがある）。

カワマタ氏は、エンジニアとの阿吽の呼吸で進められた今回のプロジェクトを、デザイナーである自分の書く「◯」と、エンジニアである荒武氏の書く「◯」とがシンクロしているような感覚だったとも表現していた。

「でも、お互いが書く『◯』は異なるレイヤーで重なり合っているのであって、決して同じ『◯』を書いているわけではありません。お互いの役割が異なるからこそ、デザインとエンジニアリングがつながり、良い仕事ができるのではないかと思います」（カワマタ氏）

取材・文／鈴木陸夫　撮影／桑原美樹