コードを書きながらデザインする––サービス開発で“禅問答”に陥らないための仕組み

コードを書きながらデザインする意味と効果

出口貴也氏（以下、出口）：こんにちは。よろしくお願いします。私からは『コードを書きながらデザインする意味と効果』というテーマでお話しします。まず自己紹介ですが、出口と申します。UXエンジニアとかプロダクトマネージャーと名乗ることが多いです。インターネット上では@dex1tというIDで、河童として活動してます。

最初にお断りです。このイベントに登壇が決まった時点ではクックパッドの人間でしたが、年末で退職しまして（笑）。

（会場笑）

今フリーターをしてます。年始からは友達のスタートアップを手伝ったり、ゆったりすごしています。クックパッドとは円満退社ですので（笑）。今日はクックパッドでどういうことをしてきたのかという話をします。

僕はクックパッドに5年半くらいいて、UXエンジニアという肩書きでした。あまり聞き慣れない肩書きだと思うんですが、ざっくり言うとプロダクトを成功させるために、UXからUIまでのデザインや、その開発まで含めて一気通貫して担当するといった働き方をしていました。去年はこういったインタビューを受けたり、クックパッドに正式にUXエンジニアというポジションを作って、採用活動を始めたりしていました。

ということで、今日はプロダクト開発においてデザインとエンジニアリングを掛け合わせるとどういったことが起こるのか。つまり事業会社でのサービス開発において、この2つを越境する意味と効果をご紹介できればと思っております。

5年半も行ってましたのでけっこう（社内では）古いほうでして、ほぼ新規のサービスを中心に行ってきました。後ほどの話にも繋がるので、まずはざっくりと、やってきたことを紹介します。

これまでやってきたこと

入社して最初に取り組んだのが、料理のコミュニティサイトの新規の立ち上げでした。このときは利用者数を伸ばすために、iOSアプリやRailsを書きつつ、SEOをやったり、キャンペーンの施策を考えたり、サービスをどういう方向に持っていくのかという企画をやったりしました。

そのあともいろいろありまして、クックパッドとぜんぜん関係ないスタートアップに出向して、企業内の情報共有を活性化するためのSaaS事業を立ち上げをしていました。このとき僕はプロダクトマネージャーとして、初期はインフラからデザインまで必要なことを全部、後期はPMからカスタマーサポートを中心に担当しました。

先ほどのSaaSが軌道に乗ったあとはまたクックパッドに復帰して、去年1年間は料理の学習アプリみたいな実験的なプロジェクトの立ち上げを担当していました。

これまでやってきたことをざっくり振り返りますと、僕は最初Railsのエンジニアだったので、ソフトウェアを作るうえでのいろいろな要素がある中で、周りは境界だらけというような状況でした。

そのあとフロントエンドエンジニアリングだとかモバイルのエンジニアリングだとか、ソフトウェア開発の領域の中で越境をし始めまして。

そのあとは新規の立ち上げもやっていたので、サービス全体に目がいくようになり、プロダクトマネジメントだとか、ユーザー数を伸ばすためにはどうしたらいいのかを考えた結果、コミュニティマネジメントだとかカスタマーサクセス・カスタマーサポートみたいなこともやってきました。

そのあとデザインの領域に入りまして、自分のサービスを成長させるためにユーザー体験を考えたりするようになりました。このあたりで肩書きを勝手にUXエンジニアというふうに名乗るようになり、最近だとUIだとかアニメーションだとか、そういったところにも手を出すようになってきました。

お聞きになっていてわかるとおり、僕はめちゃくちゃ器用貧乏で、エンジニアとしてもデザイナーとしても尖っているとは言えなくて、20代のころは、常に劣等感を感じていました。ですが、僕は器用貧乏なことに負い目は感じつつも、最近はこれでもいいかなと思って、プロダクトの成功確率を上げるために必要なことはなんでもやろうというスタンスになっています。

Wicked Problemsは禅問答に陥りやすい

話は変わるんですけど、クックパッドに3つの輪というフレームワークがありまして。

自分の「やりたいこと」と、「得意なこと」と、「やるべきこと」の3つが重なる部分をやれと社内で言われます。

ただ、この「得意なこと」が難しくて。僕は器用貧乏なので、何が得意なのかと考えるとすごく悩んでしまう。

最近気付いたのは、プロダクトを取り巻く環境がカオスであればあるほど、器用貧乏は活きるんじゃないかということです。言い換えると、何を作ったらいいのかわからない状況、つまりカオスな状況ほど、デザインと開発の越境だとか、ほかの領域への越境が効いてくるのではないかと考えています。

ここについて深掘りしてみようと思います。

Wicked Problems、厄介な問題というような意味の用語があります。

そもそも解けるかどうかもわからないし、正解はないし、解決できたかどうかが客観的に判定不可能なもの。それをこうやって呼ぶらしいんです。これを聞いて、僕はまさにクックパッドだなと思いました。

クックパッドのミッションは「毎日の料理を楽しみにする」というものです。僕らは新規のプロダクトも既存のcookpad.com も、基本的にこのミッションに基づいて作っています。

でも創業から20年経っても、「こうやったら楽しみになる」という方法はわからないし、そもそも「楽しみにする」って、目の前にいる人を客観的に見て、この人が楽しんでいるのかという判断はできないので、非常に難しい問題だなと思っています。

Wicked Problemの何が難しいかと言うと、禅問答に陥りやすいことだと思っています。答えがわからないし、答えがあるのかどうかもわかりません。

だから同じことをぐるぐる考え続けることになって、具体的なアウトプットがなかなか出せなくなったり、すごく深く深く考え込んでいるせいで、損切などの冷静な判断ができない。こういった状況に陥りやすいと思っています。

禅問答になるということは、それだけ複雑な、挑戦しがいのある問題に取り組んでいるということだと思うので、悪くはないんですけど、できれば避けたい。これについて、一昨年の秋頃にこういうクックパッドの社内ブログに『禅問答 傾向と対策』というブログを書いたりしていました。

実際にこれを書いていたときにはすごく禅問答に陥っていました。

今クックパッドは海外展開をしていて、イギリスのブリストルという街に海外本社があるんですけど、一昨年の夏ごろに創業者に呼ばれて、そこに行って創業者に言われたのが、「クックパッドのレシピを見ても料理ってぜんぜん上達しない。時短だとか簡単だとか、そういうレシピはたくさんあるけど、本当の意味で上達というのはなかなかできない。何かできないかな？」みたいなことを問いとして与えられました。

1日1つプロトタイプを作成

最初は付箋とかを使いながらそれっぽい図を描いてみたり、議論を中心にロジカルに進めていたんですけど、ぜんぜん具体的なアウトプットがでなくて、しまいには口論になったりして。けっこう暗いイギリス生活でした（笑）。でもちょっとだけ光が見えた時期があって、それが1日1つプロトタイプを作っていた時期です。そのときの1日の流れはこんな感じで、これは僕1人のタイムラインです。

まず朝起きて昨日作ったものを評価する。アイデアを出す。午前中の段階でペーパープロトでもいいので、一旦何かしらデザインをします。だいたい自分1人でやるので、伝わればいいくらいのレベルですごくラフにプロトタイプをしていました。

ここの段階で悩み出すとまた禅問答にはまっちゃうので、とにかく目に見えるかたちにすることを最優先にして、ここの段階でラフにプロトタイプを作ります。

昼過ぎには自分で実装を始めます。とにかくこの日に使えるものを作るというのが目標なので、コード自体はすごく雑に使い捨て前提で開発していきます。それを実際に生活の中で使えるような環境にデプロイをして、今度はスーパーに直行します。

なんでこんなに急ぐかと言うと、ブリストルという街にいたんですけど、だいたい18時くらいにスーパーが閉まっちゃうんですね。ということで、スーパーに行って買い物をして料理をするということを考えて逆算していくと、スーパーが閉まる18時までに何かしらデプロイしなきゃいけなくて、そのために昼までに作らなきゃいけないみたいな。そういうタイムラインでした。

Airbnbで家を借りて住んでたんですけど、そこに帰って料理をして、午前中から午後にかけて作ったプロトタイプを実際に使ってみて。

それを使いながらあーでもないこーでもないと考え、また次の日につながるみたいな。これを毎日毎日1週間2週間とやっていました。

正直めちゃくちゃハードなんですが、このように1日に何かしら1つアウトプットを作って、このままいけるのか、方向転換すべきなのかというのを毎日毎日判断していくと、すごく複雑な問題であっても多少は前に進めるという実感は得られていました。

プロトタイプのかたちはアプリとは限らなくて、目的によってはスプレッドシートによる検証で十分なこともあるし、コンセプトビデオみたいなかたちにしたこともあるし。その時間すらないときはとりあえず寸劇をしてみて、自分がユーザーとして考えたものを体験してみるとどういう気持ちになるのかを確かめたりもしていました。

プロトタイピングの方程式

このときざっくりプロトタイプの方程式みたいなものも頭の中に描いていて、こういう感じで決めてました。

まず目的は何か、プロトタイプを作る人、あとは自分の得意、自分の持っているスキル、自分の武器はなんなのか、あとは使える時間はどれくらいあるのかというのを考えていました。

これを引いて考えると、何を考えるか、何を作ったらいいのかわからない状況の中では、抽象的なものと具体的なものをいききすること、繰り返すことが大事だなと思っています。先ほど紹介した1日1プロトタイプ生活というのは、これを強制的に繰り返すフレームワークみたいなものだと思っていて。

例えば議論をしていて、口頭の議論だけだと抽象的でまとまらない話も、何かしらホワイトボードにテキストとか図とか描いてみると議論が前に進むという状況は誰しも経験があると思います。そういうふうに、議論であればテキスト、思考であればスケッチ、仮説であればプロトタイプ、企画であればそれを表すプロダクトみたいな、抽象物と具体物をぐるぐるといききすることが大事だと思っています。

この繰り返しの速度をいかに上げるかを考えると、デザインとエンジニアリングの掛け合わせが必要になるのかなと思っています。

IDEOのValuesにも「議論するより行動しよう」というものがあるんですけど、議論だけじゃなくて、何か行動する、何かものに変えてみるというのが大事だと思っています。

UXエンジニアの役割は、何を作ったらいいのかわからない状況であっても、抽象と具体をいききしながら、チームに対して「こっちをするべきだよ」と進むべき方向を示すことだと思っています。

時間がないので飛ばしますが、本当は具体的にどうやってやるのかという話するつもりでした。かいつまんでお話すると、直近の現場では「仕様はFixしないものとして考える」という前提のもとでサービス開発が進められないかという試みをしていました。

僕は、UXエンジニア的な人が何人かいたとして、その人それぞれが企画とデザイン、開発をごちゃまぜに繰り返していくということができないかと考えていました。

それを実際に自分のプロジェクトで試してみた結果、実際には従来の分業型サービス開発とハイブリッド型でやっていて。

例えば課金の機能とかけっこう重いやつはディレクター、デザイナー、開発者がバトンタッチしながら水平分割して進めていきます。逆に、動画にテロップを流すとか、学習アプリで学んだ結果ポイントがもらえるとか、そういうのはけっこう未知数なので、僕が1人で企画からデザインから開発まで全部ごちゃ混ぜで進める。こんな感じにハイブリッドで進めていました。

開発とデザインをつなげる仕組み

開発、デザインを繰り返す。越境するのが大事だと思っているので、それをやりやすくするような仕組みづくりも僕らUXエンジニアの役割だと思っています。

例えばクックパッドではCitrusというデザインシステムをデザイナーのマネージャーと協力して作りました。これはコーポレートアイデンティティとかブランドアイデンティティとか、それに紐付くそのブランドを体現するための、「タイポグラフィって何だろう」とか「カラーリングって何だろう」といったものを言語化したサイトです。

その他にはクックパッドのシンボルやアイコンなどを、エンジニアであってもデザイナーであってもそれ以外の人であっても自由に取り出しやすくするようなシンボルフォントを作っていたり。あとはクックパッドっぽいUIが誰でも再現できるような、SaraっていうCSSフレームワークが昔からあったり。こういう仕組みがいくつかあります。

最近はデザインをしたら、デザインとコードを行き来しやすいようなツールがいくつか出ています。例えばFramer Xというツールだとか、Figmaという共同編集しながらデザインするツールだとか。あとはアニメーション周りだとAirbnbがLottieというツールを出しているので、そういう新しめのツールを検証したりワークフローに組み込んだりするのも僕らの役割だと思っています。

デザインと開発をつなぐ取り組みはDesignOpsと呼ばれていて、Airbnbが先進的にいろいろ公開しているので、こういうことをウォッチしたり、デザイナー同士で集まってアイデアを膨らませるということもやっていました。

時間がないのでざっくりになってしまいますが、クックパッドは今新規サービスをいろいろ出しているので、こういった役割が求められています。もし興味があれば、いまでも紹介できますのでぜひご連絡ください。よろしくお願いします。

（会場拍手）

ユーザーからのフィードバックについて

司会者：出口さん、どうもありがとうございました。今からQ&Aを始めたいと思います。質問のある方は挙手してください。

（会場挙手）

質問者：すばらしいプレゼンテーションをありがとうございました。イギリスの生活の中で、毎日ご自分でプロトタイプを作られていたということですが。それをお一人で検証されてましたということですが、お客さまによる検証・フィードバックというのは必要ではなかったのでしょうか？　そのあたりはどうお考えですか？

出口：フェーズや目的にもよるかと思います。僕がやっていたのは本当に初期の初期のコンセプトワークだったので、一般のお客さんに使ってもらう前に、手早く今後の掘りどころを見つけ出したい、というフェーズでした。自分一人という限られたリソースのなかで、どうしたらいいのかと考えた結果、ああいうプロセスになりました。

この方程式の中で、テスト対象が一般ユーザーであれば、プロトタイプに求められる解像度も高くなってくると思うので、その場合は制作時間を増やしてみるとか、人を増やしてみるといった変数の変化があるのかなと思います。

質問者：ありがとうございます。

司会者：ほかに質問がある方はいらっしゃいますか？　大丈夫ですか？　出口さんはこのあともお時間があると思いますので、個人的にお話していただいても大丈夫だと思います。出口さん、ありがとうございました。

（会場拍手）