受託の常識は「クライアントから要件を聞いてつくる」。けれどクリエイティブな開発パートナーTAMの中村颯介さんは、その順番に強烈な違和感を抱いてきました。
「先につくって見せるほうがいろんな良いことがある」。そうしたAIを取り入れた個人の仕事の進め方が、いまや全社を巻き込む取り組み「PlayGround」として広がっています。
クリエイター自身が営業でき、クライアントにとってもプロジェクトにとっても、「三方よし」となる「先につくる」文化とはなにか。1時間超のインタビューから、その思想と実践をお届けします。
ーー「先につくる」とは？
TAMTO プロジェクトマネジャー／ディレクター 中村颯介
1993年生まれ。ソフトウェア開発／教育会社、サッカークラブフロントスタッフのキャリアを経てTAMにWebディレクターとして入社。現在はUX／UIプランニングを強みに、コーポレート／サービスサイト、ブラウザゲーム、SNSなど幅広いプロジェクトに従事
中村：お仕事のご相談をいただいたとき、もちろん要件通りの真面目なソリューションは考えるんですが、どうせなら「ちょっと寄り道したい」という気持ちもあって。なので、真面目な提案も、一見変わった提案も、両方やっています。
例えば、お客さんからオリエンテーションで要件を聞くとして、誤解を恐れずに言えば、初めは「話半分」で聞いて寄り道の企画を考えて、その後に今度はしっかり資料を読み込んで、真面目な提案を考える。こんな感じ。
僕、たぶん人より理解力が低いんですよね。一回聞いただけでちゃんと理解できる人はオリエンを聞いたら要件が全部頭に入るんでしょうが、僕はそんなに頭に入ってこないんですよ。もしかしたら、この真面目に聞いても理解できないことが、プラスに働いているかもしれないです。
ーーその「寄り道」や「話半分」の背景に、受託フローへの違和感もあったのでしょうか。
中村：例えば、提案がいかに要件にすべて応えたものだったとしても、「要件がズレていたら解決に至らないんじゃないか」みたいな思いもあって。
「PlayGround」の話にもつながるんですが…僕、このTAMがWeb制作業界の会社は初めてなんですが、入社した時に最初に思ったことがあって。
入社前にいろいろ見ていたすごい業界の事例がいっぱいあって、一方で入社して学んだ通常の手順ーーオリエンを聞いて、要件を整理して、ワイヤーフレームを書いて、デザインして、コーディングして。その合間に一個ずつチェックのタイミングがあって、お客さんと確認してーーという、要件に1つずつ応えていく教科書どおりの進め方。
それを見て体験したときに、「このとおりに進めていたら、あの憧れていたレベルのアウトプットにはならないんじゃないか」と思ったんです。
それに、「要件→構成→デザイン→開発」の順番で進めるのでは、要件の点をなぞることになるので、お手本通りの解答しか出てこない。それ自体は悪いわけではないんですが、つくる人がもっと前の段階から試せたら、もっと広い選択肢を持って考えられるんじゃないかとも思っていました。
クリエイターは作るのが好きで、作りたいものがたくさんある。「要件を少し“ズラしてほしい”お客さんと、自発的になにかを作りたいクリエイターは、実は噛み合うのでは？」と考えました。
ーー具体的に「教科書どおりでは届かない」と気づくきっかけはなんでしたか。
中村：例としてちょっとズレるかもしれないんですが、東京都の立川市に、手塚貴晴さんという有名な建築家の方が手掛けた「ふじようちえん」という幼稚園があるんです。
なにがすごいって、屋上に万博の大屋根リングみたいのがあって、グルグル無限に走れるんですよ。屋上から下を見下ろして子どもたちが危ないんじゃないか、とかいろいろあるんですが、とにかく型破りな幼稚園なんです。
こんなの、安全性を担保して、みたいな要件から出発していたら生まれなくって。だけど、「仕切りをなくしてみたらどうなるだろう？」という問いから考え始めたら、実は子どもたちは一周走って戻ってくるだけだから大丈夫、と要件まで解決していたりして。
幼稚園づくりの要件を1つずつ解決していくアプローチではこんな解決策は出ないと思うんですが、寄り道したり、「こうなっていたら面白いのでは？」というアイデアから課題を捉え直したときに、「実はあれもこれも解決するよね」みたいな事例が世の中にはたくさんあって。そのことに感動した経験が、今のきっかけになっているのかもしれません。
ーーとはいえ、いきなり “反教科書” に振り切ったわけではなかった。
中村：そうです。教科書どおりのやり方を、まず半年から一年ぐらいはちゃんとやっていました。
一社目の上司に「自分が言いたいことがあるなら、まず相手の話を、相手が『理解された』と思うまで聞け」と言われたのを覚えています。違和感はあっても、この業界は初めて。それに、なぜそうなっているかを理解する時間は、ハックするためのヒントになる。
奇をてらって案件自体を落とすのは嫌なので、真面目な案も必ずセットで持っていく。それから自分にお客さんがついて、いろいろ試してやっていいよって言われてからは、「先につくる」ってことは、PlayGroundの前から普通にやっていたんですよね。
中村さんのNotion
Notionにプロトタイプをまとめて、お客さんに持っていく。例えば、「会社のロゴを3Dやアニメーションにしたらこうなる」と、絵にして動くものを作って持っていくと、お客さんも「もうできてるじゃん！」ってなる。エンジニアとも実装の会話ができる。
遠回りをしているようで、お互いに “本当の要件” について会話ができるようになり、セットでつくるものが見えてくるんです。
だから、教科書どおりのやり方には最初から違和感があって、代表の爲廣さんに「アイデアから課題を見つける」っていう僕の仕事の仕方を話したら、「それいいやん、全社でやろうや」ってなったんです。
ーーだけどこれまで、「先につくる」は難しかった。
中村：受託で「先につくる」が難しいのは、単純にお金と時間がかかるから。クリエイターが面白いアイデアを思いついても、「まだやるか分からないものにそこまでコストはかけられない」となってしまうのは、まあ当然なんですよね。一方で、クリエイターは「自分でお金を出してもいいからつくらせて」と思っていたりもする。
大きく風向きが変わったのがAIで、「つくる」コストの前提が崩れたんです。開発スピードがめっちゃ上がった。
僕にとってAIは「めっちゃ早い手」。頭の中に設計図があってアウトプットに時間がかかっていたものが、速くなる。美容室でパーマを当てている間にスマホでWebアプリがつくれる、みたいな世界になると、偉い人たちも「そんなに早くできるならつくっちゃいなよ」と言いやすくなる。爲廣さんも、AIで素早くつくれる前提がなければここまで大きな動きにはならなかったかもしれません。
ーー「先につくる」ことで、クライアントにはどんな変化があるのでしょうか。
中村：まず、つくりたいものを手に取れることがあります。社内に持ち帰っても話を通しやすいですし、なによりワクワクしてくれる。例えば、ちょっとしたカードをつくって持って行ったら、「めっちゃいいですね！」ってリアクションになる。要件を満たすかどうかの議論より、「これならいける」という空気が早く生まれるんですよね。
あと、要件定義の解像度が上がります。形があるから「ここは違う」「こっちはこうしたい」が具体的に出てくる。結果的につくるものがブレず、プロジェクトの安定感につながる。前は「言葉の解釈違い」で後工程が崩れることが多かったんですが、先につくってしまえばそのズレを早く修正できます。
そして、クリエイターにとっても自分の力を営業に使えるようになるんです。企画書や言葉では定義できなかった要件を、つくったものベースで見せられる。しかも、「コストやスケジュール」を理由につくれなかった「実はつくりたかったもの」を試せる口実にもなる。
実際、ちょっとズレた提案をしても「真面目な案」も一緒に用意しているので安心されますし、そのズレから新しいものが生まれることも多いです。
ーー実際に「先につくった」ものが広がった事例を教えてください。
中村：オフィス家具メーカーのオカムラさんと一緒に取り組んだ案件が分かりやすいと思います。
最初の依頼は、オフィスのスタイルを診断する診断ツールでした。自社に合ったオフィスのタイプを選べるようにするものです。でもつくっていく過程で、「オフィスを設計するって実は社内調整が大変で、特にオフィスの課題を共有するのが難しい」と気づいたんです。
そこで、オフィスについての会話ができるよう、物理的なコミュニケーションカードをつくりました。トランプのように配って、会議で回したりできる。プロジェクト後の打ち上げで渡した瞬間に「これ、めっちゃいいですね！」という反応が返ってきました。
カードの使い方が広がっていく中で、「イベントでも使えるのでは？」という話になりました。オカムラさんが開催するイベントで実際に導入され、参加者はオフィスについて考えつつ場を温めるためのブレストツールとして使ったり、イベントの参加特典として渡されたりしました。
さらに、このカードをAIツールを使ってWebアプリ化しました。これでオンラインでの会議でも利用しやすくなります。実際、オカムラさんとの会議のブレストに使ったり、エンドクライアントとのオンラインミーティングなどで利用したりすることで、オフィスに関するインサイトを得たり、プロジェクトを円滑にするための場づくりに利用したり、みたいなことも実施しました。
本来の要件は「診断ツールをつくる」だけだったのに、カードやイベント、プロジェクト進行ツールアプリ広がっていった。これはまさに、アイデアを先にかたちにすることで広がっていった事例です。
ーーお客さんとの間ではどんな変化が起きていますか？
中村：「つくりながら考える」が共通言語になりつつある気がします。以前は「診断ツールをつくってください」という要望だったのに、カードやイベントに発展した。お客さんも初めからそういう動きを期待していたわけじゃないですが、実際にモノが出てくると「あ、そうそう、これがほしかった！」となる。
従来は、お客さんが「言っていること」しか見ていなかったけれど、「やっていること」までよくよく観察すると、本当に必要なものが見えてくる。だから僕は顧客インタビューでも「言っていることじゃなくて、やっていることを見ろ」という教えを大事にしています。
ーー「PlayGround」という名前は、どんなイメージから生まれたのでしょうか。
中村：モノを作るときに、もっと自由であっていいと思っているんです。これまで「言葉」や「会議室」でしかプロジェクトは始まらなかった。でも本来、散歩しながらでも、手を動かしながらでも考えられるはずです。PlayGroundは、そういう「遊びながら考える場」のイメージです。
PlayGroundでは、仕組みがあることでクリエイターが動きやすくすることを狙っています。例えば「四つの遊具」として、
こうした「遊具」を置くことで、公園のように人が集まり、自然にアイデアが出てくる。「まず、つくってみる」を後押しする場があることで、「本当はこんな動きをしたかった」と思っている人たちの背中を押すことが目的です。
ーー実際に仕組みがあることで、どんな変化が起きていますか？
中村： 大きいのは、クリエイターが「つくってみてもいいですか？」と言いやすくなったことです。従来の順番だと「企画書にして承認を得る」が前提になりますよね。でも企画書にすると逆に伝わらないこともある。
PlayGroundがあると、エンジニアが「試作したんですが営業で使えますか？」と出せる。営業も「いいじゃん、それ持っていこう！」となる。役割の壁を越えて、クリエイター発の提案が走り出すようになります。
「事務所から公園へ」。制約の中だけでなく、開かれた場でつくって試すことで、順番を入れ替えても大丈夫な雰囲気をつくっていきたいと思っています。
ーー最後に、PlayGroundを通じてなにを目指していますか？
中村： 僕自身は「なにかを変えてやろう」という気持ちより、自分がやっていたことを仕組みにしたという感覚に近いです。昔から家族みんなが「つくるのが好きな人」で、今年の夏休み帰省でも、なぜか母親が粘土を買っていてみんなでいろいろつくりました（笑）。
そして今年、子どもが生まれました。親として思うのは、だれかがつくったもので遊ぶのもいいけれど、自分で遊び方を発明して遊べるようになってほしいということです。砂場のある園庭のように、環境さえあれば子どもは自然に遊びを見つける。PlayGroundも同じで、遊び方を見つけられる場になればいいなと思っています。
クリエイターが手を動かして営業できる。クライアントも、プロジェクトも、クリエイターもみんなワクワクできる。そういう“公園”を、ディレクターとして、父として、作りたいんです。
[取材・文] 岡徳之 [撮影] 蔡昀儒
/assets/images/5818/original/27855b33-34d8-4fc8-986d-891836dcb7fb.jpeg?1495011949)
/assets/images/20732476/original/475326ac-a9e7-44b6-a801-ec28a3d4793d?1742891631)
/assets/images/3478188/original/27855b33-34d8-4fc8-986d-891836dcb7fb.jpeg?1549953460)
