クックパッドデザイナーが語る、新規サービス開発を加速させるためにやったこと––技術を使ってエンジニアをサポートする

新規サービス開発を加速させる技術とデザイン

藤井謙士朗氏（以下、藤井）：それでは、「新規サービス開発を加速させる技術とデザイン」というタイトルで発表させていただきます。よろしくお願いします。

軽く自己紹介させてください。

クックパッドの藤井といいます。Komerco事業部でデザイナーを担当しておりまして、2017年に新卒で入社しました。だいたい社会人2年目が終わるくらいです。Twitterではこのヒヨコっぽいアイコンでたまに情報発信したりしています。

Komerco事業部でデザイナーとして働いているんですが、Komercoというサービス、みなさんご存知ですか？

（会場挙手）

おー、やったー！　けっこういますね（笑）。ありがとうございます。

Komercoは「料理が楽しくなるマルシェアプリ」というコンセプトのサービスです。例えば料理に使う器や、食材を買えるサービスです。一般的に売ってる器ではなくて、全国各地にいるクリエイターさんが手作りで作ったものを取り集めて、販売しているサービスです。

Komerco自体は2018年6月にリリースされました。リリースしてからだいたい8ヶ月ぐらい経っています。先ほど言ったように、料理が楽しくなる食材だったり器だったり、料理道具が買えるサービスを提供していて、現在はiOSアプリのみサービスを行っています。

右側にあるアイコンなんですが、緑色のほうが食材や器を買える購入用のアプリになっていて、茶色いほうがクリエイターさんが出品する出品用のアプリになっています。現在はこの2つのアプリを提供しています。

Komercoは、リリースしてから順調にサービスを成長させるフェーズに入っていて、Appストアの評価は4.4で、まあ、悪くない数字かなと思っています。ちょうど1ヶ月前ぐらいにAppストアの「今日のAPP」にも取り上げられたりして、リリースしてから致命的なバグもなく、順調にサービスを成長させているフェーズになっています。

そんなKomercoという新規事業のなかで、デザイナーはどんなことをやっているかお話しさせていただきます。今日話す内容なんですけど、立ち上げしてからリリースするまでの間の、開発で取り組んだことについてお話させていただきます。

Komercoのサービス開発

Komercoのサービス開発について。立ち上げ当時の開発メンバーはこんな感じでやっていました。

iOSエンジニアが4人、デザイナーが1人、ディレクターが1人という体制です。サーバーサイドのエンジニアはいないんですが、バックエンドにFirebaseというmBaaSのサービスを使っているので、ちょっと偏ってるんですけど、こういった編成でやっています。

新規事業なので、基本的にゼロからサービスを作るので、求められていることはだいたいスピードです。というのも、ミニマムでサービスを作って、とにかく早くユーザーさんに当てたいので、なるべくミニマムで作ることをチームとしては意識していました。

そのため、全体の体験設計ができてないと仕様を決められないということがありました。デザインがないと仕様が決められないんですよね。そうなってくると、基本的にきれいなUIは全部後回しにして、いまあるリソースを使ってすばやく作ることが求められます。

これは立ち上げ当初のUIです。基本的に色がほとんど当たっていなかったり、内容も簡素になっています。例えば色もクックパッドのメインカラーで代用したり、クックパッドのレシピサービスで使われているアイコンをお借りして作ったりしていました。

全体の設計の仕様も、こういった感じで簡単に動線を用意しておいて、エンジニアと「これなら、ここの部分の設計はこんな感じで作れるよね」みたいな話をしてから、細かい商品のページなど、後からUIを詰めていきました。基本的に正常系の部分だけやっているので、エラー処理などの部分は全部後回しでやっています。

エンジニアとの共有はこんな感じでやってたんですが、UIを作るときの課題がありました。UIのデザインをするのはそれほど大変ではないんですが、エンジニアと共有するところで面倒くさいところがありました。

というのも、例えば「デザインを変更しました」となったときに、デザインの履歴を残しつつ、実際にどう動くのかというプロトタイプも更新して、「実際に何ピクセルずれたの？」とか、「色はどんなのなの？」と変更箇所も共有する必要がありました。

その結果、デザインする時間よりも共有する時間にどんどん取られてしまって、デザインが実装スピードにぜんぜん間に合っていない、ろいうことが起きました。iOSエンジニアが4人いて、アプリが2つあるので、新規サービスを2つ作っているような状況になってしまいました。エンジニアがどんどん「デザインくれ」と言うことが多かったことを覚えています。

実装スピードに追いつくためにやったこと

実装スピードに追いつくためにいろいろ取り組んだんですが、今回は2つだけお話します。1つは使ってるデザインツールを変えるということ、もう1つはコンポーネントに関する話です。

デザインツールは、立ち上げしてからSketchを使ってデザインをしてました。そしてSketchで作ったデザインを、Abstractという他のサービスを使って、GitHubみたいな感じでバージョンを管理しつつ、エンジニアにはZeplinを使って共有して、プロトタイプも別のサービスを使って、という感じでやっていたんですね。

そうなってくると、Sketchでデザインしたら、この3つのアプリケーションに対して変更を適用しないといけない。アプリは2つあるから、それぞれやらなければいけない。エンジニアは4人いるので4人分更新しなきゃいという感じですごいつらかったので、「やめたいな」と思ってたときに見つけたのが、このFigmaというサービスです。

Figmaはめちゃくちゃ便利で、オンライン上で同時にUIデザインを編集できるんですね。Sketchって、Sketchのファイルを1つ持っていて、他のデザイナーと共有したいときには、そのファイルをあげなきゃいけないんですが、Figmaだとそれがなくて、例えばGoogleスプレッドシートみたいに、同時にオンライン上で編集できます。

そうなってくると、エンジニアもその画面を見ながら共有できるので、すごく楽になりました。かつ、Figma上にバージョンを区切って、「ここまでのデザインはバージョン0.1ね」みたいな感じで、デザインの履歴もしっかり切れますし、プロトタイプも簡単に作れるので、一気に移行しました。

AtomicDesignを導入

2つ目にコンポーネントに関する話なんですが、これに関してはAtomicDesignを導入して解決しました。

AtomicDesignに関して話すと、例えばヘッダーというコンポーネントがあって、ヘッダーにロゴと検索フォームがあったとして、「ヘッダーはその2つに分かれるよね。じゃあ、検索フォームもインプットのフォームとボタンに分かれるよね」みたいな感じで、コンポーネントを最小単位に区切って、再利用性を上げてどんどんやっていくという考え方です。

メリットとしては、管理しやすくてメンテナンスもしやすいです。あとはくっつけたりはがしたりが簡単にできるので、安心してコンポーネントをいじることができます。

Figmaに移行してすごいやりやすくなった部分もあります。

というのも、Sketchで取り組んでいたときは、このSketchのファイルをLibrariesというファイルに変換して、そのAtomicDesignに沿ったコンポーネントを全部ぶち込んで、購入用と出品用のアプリにインポートしてたんですけど、そうすると1つのファイルがどんどん大きくなってくるので、すごく動作が重くなったりしてました。

それを解決するために、「さらにライブラリを分けよう」という話になって、こういう感じでコンポーネントの粒度に合わせてSketchを作っていたんですが、そうするとSketchファイルが5個になって管理が大変ですし、1個1個反映していたら、Atomsを変更してどんどん右に流れるというのが、時間がかかってつらかったんです。

ですがFigmaで取り組むと、1つのアプリケーション内でこれを全部管理してやれるので、管理が非常に楽になりました。あと、タブで見やすいというちょっとしたメリットがありました。

これは、実際にFigmaで使っているツールの画面なんですが、この左上にあるタブの部分で、簡単に使っているコンポーネントの部分をウインドウで開けて、それが見られるんですよね。こうなってると、例えばファイルを間違えて削除したとしても、簡単にアプリケーションから開いてもう1回見直すことができて、精神的にかなり楽になりました。

実装スピードに追いつくために変えたことのまとめです。

使ってるデザインツールをSketchからFigmaに変えて、実際にエンジニアとの共有が楽になって、開発スピードがかなり上がりました。

2つ目は、デザインコンポーネントをちゃんとコンポーネントとして管理する手法があまりなかったので、AtomicDesignを導入して解決しました。

結果として、スピードは上がって、コンポーネントをどんどんぶっ壊すということができるようになったので、精神的な負担も減ったんですが、AtomicDesignの考え方を自分のなかに入れて、デザインデータをうまくやりとりするのは、最初の構築に時間がかかるので、「これはタイミングを見てやるべきかな」と思いました。

さらに開発スピードを上げるためにやったこと

ここからは、さらに開発スピードがどうやったら上がるかということについて、お話させていただきます。

1つは、UIガイドラインを作った話です。これはみなさんのサービスもおそらくやっていると思いますが、共通で使われているルール、例えば色であったり、マージンであったり、レイアウトのルールを、全部可視化して、エンジニアとやりとりするようにしています。

このUIガイドラインはFigma上に全部置いて、エンジニアが全部見られるようにしています。なんで作っているかというと、例えば「この色ってこのカラーコードで合ってるよね？」みたいな確認をするコミュニケーションを減らして、お互いが作業できる時間を増やすことによって開発スピードを上げることを目的にしています。

作っているUIガイドラインは、こんな感じです。

例えば左側がスペースというかマージンに関する話だったり、iOSなのでiOSの共通のルールを書いてあったり。

色もこんな感じで、「この色を使ってください。カラーコードはこんな感じで、変数名はこんな感じです」というようにエンジニアとやりとりしています。

アイコンフォントの作成

次に、アイコンフォントの作成に関する話です。Komercoはアイコンをこれからどんどん増やす予定です。というのも、食材とかを販売するとアレルゲンに関する表記が必要になってきて、「文字だけだとわかりづらいから、アイコン必要だよね」という事になりました。まだまだ食材も集めている最中なので、これからどんどんアイコンが増える予定になっています。

アイコンを作るのはいいんですが、じゃあ、実装するときにどんな問題があるかというと、iOSは端末に合わせて写真や画像の解像度を変える必要があって、1つのアイコンを実装するのに、@2x、@3xみたいな感じで複数必要になってきます。

バージョンごとに画像を保存するとなると容量も当然厳しいですし、例えばホーム画面のアイコン変えたら、変更前と変更後がどんなものかを管理しなきゃいけなくて、画像を作るのがけっこうつらいと感じていました。

このときは、管理画面をWebでも開発していて、そちらにも変更を適用しなければいけなかったので、「なるべく共通のリソース1つにして、それを使えるようにしたいな」という話をしていました。

管理画面はこんな感じです。見せられる情報がほとんどないんですが、「ちゃんと作ってるぞ」というのをアピールするために書いています（笑）。

（会場笑）

どうしてアイコンフォントを作ることになったかというと、フォントファイルにすることによって、例えばフォームの画像、検索の画像みたいな感じで、アイコンを1個1個作る必要がないので、WebとiOS共通で1個のリソースになって、使い回せるので便利でした。

フォントのバージョンに関しては、GitHubを使って管理していて、かつ、GitHubにGitHub Pagesというものがあるので、そこに利用可能なアイコンを確認できるようにしています。

そのGitHub Pagesの画像は、ページはこんな感じで、下のほうに使えるアイコンが並んでいて、, 上のほうに検索フォームがあります。例えば卵とかエビのアイコンが出ているんですが、これは実際に「egg」とか「shrimp」と打つと、変換されるようにしています。

これはクックパッドのレシピサービスでも使われているものをお借りして、独自にアレンジしたものになっています。

アニメーションの導入

次に、アニメーションの導入に関する話です。Komercoはリリースするまでゼロから立ち上げてやっていたので、なるべくミニマムで設計してリリースしました。そうなってくると、一部もっとこだわりたい部分が出てきました。例えばKomercoでは商品をお気に入りみたいな感じで、ハートマークを押すと「好き」というのができて、後で「好き」した商品を見られるようになっています。

リリースした当初は、「好き」してもとくにアニメーションもなにもなく、色が変わるぐらいになっていたのですが、「もっとユーザーさんに『好き』してもらえるようなインタラクションを付けたいよね」という話になりました。

ただ、気持ちのいい、ユーザーさんが「もっとやりたい」って思えるようなインタラクションと開発の工数は、基本的にトレードオフの関係にあります。じゃあ、「このアニメーションを入れたいです」となったときに、実装に8ヶ月かかったら、当然優先順位は下がってしまいますので、その実現可能性に関して、開発工数はどのくらいかかるのかという部分も含めて、デザイナーが調査しています。

「アニメーションを導入したい」という話があったときに、導入までどうやってやったかについてお話します。

まず1つは、「アニメーションの作成コスト自体がそもそも低いのか？」という話と、「簡単に導入して実装できるか？」という話、「iOSとWebでも同一のインタラクションが作れるか？」ということについて見てきました。調査はいろいろやったんですが、最終的にはLottieを導入することによって解決しました。

LottieはAirbnbが開発しているオープンソースのライブラリです。アニメーションを動画やgifファイルからではなく、jsonファイルから実行することができます。アニメーションをjsonファイルに変えるのはAfterEffects上でできます。アニメーションはもともとAfterEffectsで作っていたので、「これなら作成のコストは低いから大丈夫だろう」ということがわかりました。

かつ、Lottie自体はiOSとWeb両方のライブラリーを用意しているので、1つのjsonファイルから、iOSとWebの両方でも使えるｋとががわかっていました。

論理的にはできたので、「まあ、いけるでしょ」と思っていたんですが、実際に手元で簡単なプロジェクトを作って、「本当に動くのか？」の検証だけやってエンジニアと話して、「いけるかどうか？」という話をしようと考えていました。

そこで、簡単なプロジェクトを自分で作ってみて、Lottieを入れた後に、Lottieが提供してるこのLOTAnimationViewで、作ったjsonのファイルを指定してあげて、それを読み込ませて、再生させるということを、こんな感じの簡単なコードで実装することができました。

そしてきちんと動くことがわかったので、「これならiOSのほうでもいけそうだよね」という話をエンジニアとしました。

次にWebについてです。WebはReactで作っていて、「Reactでもきちんと動くか？」というところを検証しました。

こちらもreact-lottieをnpmでインストールした後に、LottieのコンポーネントにあるこのoptionsというところのPropsに、optionで作ったjsonファイルを読み込ませて渡してあげると、アニメーションを実行させる仕組みになっています。

今回はローディングのアニメーションを作ったんですが、このように数行のコードでアニメーションを実行できたので、あとは情報というか、データを設置したタイミングでアニメーションを実行させて、データを全部取り終わったらこれを外す処理を書けば、ローディングっぽいものが作れるというのがわかりました。

デザイナーも「iOSとWeb両方いけそうだよね」ということがわかったので、あとはエンジニアと相談しながら、「どんな処理を書いていくか？」相談しつつ実装するだけ、という感じで実装しました。

ここまでやると、今後エンジニアに「こういうアニメーション入れたいんですけど」という話をしたとしても、「ちょっと技術的に難しいから」という話はほとんどなくて、エンジニアは基本的にコードレビューと、実際に動作している実行結果の確認のみになるので、負担をかなり減らすことができます。

かつ、デザイナーがアニメーション入れたくて、デザインを作って実装して、「こんなのを作ったんですけど、どうですかね？」という話まで持っていけるような仕組みを用意した、というのもあります。

コンポーネントについて

次に、コンポーネントに関する話です。先ほどのAtomicDesignの話にも絡んできますが、デザインで作ったコンポーネントをなるべくコードに変える、ということに取り組んでいます。

デザインのデータは、いまのところReactのコンポーネントに落とし込むようにしています。というのも、例えばボタンがあったとして、ボタンを押したときの色が変わるということは、デザイン上ではわかるんですが、実際にボタンを押したときの色が変わる速度などは、実際に挙動を確認しないかぎりわかりません。ですので、そういったことも含めて作るようにしています。なので、タップ時の挙動などを、実際にWeb上で確認できるようにしています。

こうすることによって、デザインのコンポーネントをエンジニアが貼り付けるだけにできるので、デザインに関する負担をなるべく減らして、すぐに実装できるようにしています。

あとは細かいところですが、仕様に関することもコード上で見られるので、「あ、ここの処理ってこういうふうにできるんだ」ということもわかるようになっています。

実際に作っているこのコンポーネントはWebで見られるんですが、見える画面はこんな感じになっています。上に作ったコンポーネントが実際に表示されていて、下には「それを実装するにはどういったコードになっているのか？」を確認できるようになっています。

これは、Doczというオープンソースを使ってやっています。なぜDoczを採用したかというと、mdxというファイルを作るだけで簡単に作れるからです。

mdxというのはmarkdownとjsxの組み合わせのようなものなんですが、基本的にmarkdownで簡単に書けるので、メンテナンスコストが低いことがわかっていました。かつ、Propsでどんなデータを受け取れるのか、仕様の細かい部分まで確認できます。

これはこのmdxファイルなんですが、例えば作ったコンポーネントのボタンを持ってきて、Doczが提供しているPropsTableに作ったボタンのコンポーネントを直接投げ込むと、このようにボタンが使えるPropsの仕様が出てきます。

例えばcolorであれば「primaryとsecondaryの2つしか受け取れませんよ」みたいな感じで、たったこれだけでここまで出してくれるということがわかっていたので、こちらを採用して、エンジニアにコンポーネントの仕様を共有するようにしています。

デザインをコード化する理由

なぜデザインをコード化するかという部分に関しては、実際に使われる環境で動作確認ができるようにするだけでなく、デザイン変更が発生した場合には、できるだけ実装をデザイナーが負担するようにしています。ちょっとの変更とはいえ、iOSであれば1ピクセルずらしてビルドするのにも、何十秒とかかってしまうので、そこはなるべくデザイナーが巻き取るようにしています。

そうすることによって、エンジニアは機能開発に集中したりだったり、自分たちのプロダクトをもう1回見直したときに、「この体験って良いよね」という体験の改善に時間を割けるようにしています。

目標としては、コンポーネントをデザイナーチームで作って、それをエンジニアがくっ付けるだけでいい感じにデザインされる世界を目指しています。

これは余談なんですが、そういったことをやっていたら、エンジニアから「iOSっぽいかっこいいアニメーションをするToggle Switchがほしいです」みたいな雑なissueが投げられて。