Cookpadデザイナーが教える、“チームで考える”サービス開発

クックパッドのサービス開発体制について

辻朝也氏：「クックパッド　クリエイティブワークフロー」と題して発表させていただきます。よろしくお願いします。

簡単に自己紹介させていただきます。辻朝也と申します。今回のTechConfで、たぶん唯一デザイナーで参加しております。

今はデザイナーとディレクターを兼務しておりまして、現在はクックパッドのiOS／Androidのアプリデザイン全般を見ています。あわせてクックパッドアプリリリースマネージャーという、リリースに責任を持っているところもやっています。並行して、チームのプロジェクトのディレクションも行っています。

経歴は短いんですけれども、2016年にクックパッドに新入社員として入社しました。配属後はずっとクックパッドのサービスを開発していて、投稿領域から記録領域ときて、今は会員事業部というところで有料会員向けのコンテンツや収益面を見ています。

昨年度は、主にこの「料理きろく」という、機械学習を使った料理判定機能のアプリ開発をやっていました。

今日お話する内容はこちらになります。「チーム・組織全員でユーザーを考え、素早く価値を届けるクックパッドのサービス開発とは」と題して、これを達成するためにふだん、デザイナー含めチームがどのような工夫やワークフローを実践しているのか、というお話をしたいと思っています。

アジェンダは、まずクックパッドのサービス開発がどのような体制になっているのかを簡単にご紹介したあとに、僕が実際に所属していたチームで意識してやっていた開発事例をいくつかご紹介します。最後に、デザイナーの役割と取り組みについてお話できればな、と思っています。

ではさっそく、クックパッドのサービス開発体制についてお話します。現在クックパッドは、1サービスを作るのに約140名の開発者と共に、日々サービス開発を行っています。けっこうな人数なんですけれども、この大人数で素早く開発を行うために、クックパッドでは、ユーザーの利用シーン別にグループを区切っています。

例えばレシピを投稿する「投稿」のグループ、レシピを検索する「検索」のグループ、というかたちです。そのグループの中にチームA、チームB……といくつかチームが存在しているという組織体制になっています。

各グループの1チームは、だいたい少ないところで3名。多いところで5名くらいで構成されていて、それぞれオーナーとデザイナーとエンジニア、ディレクターがいます。

このようなチーム体制の中、どのようにしてユーザーに価値を届けていくのか。また、チーム間同士の連携について、僕が実際に所属したチームのご紹介をします。

チーム体制とワークフロー

今回ご紹介するのは、先ほど自己紹介のときにもご紹介しました、「料理きろく」のアプリ側の開発を行っていたチームの話です。チーム体制は、僕含め4人です。ミッションオーナーと、デザイナーの僕、あとはiOS／Androidのネイティブエンジニアが2人です。

ミッションオーナーは「目標責任」、デザイナーとディレクターは「ユーザー体験の責任」、エンジニアはそのままなんですけど「エンジニアリングの責任」、とそれぞれの役割を持っています。チームメンバーは、全員異なったバックグラウンドや得意領域を持っているので、お互いの得意・不得意を補完し合う関係になっています。

例えば、デザイナー兼ディレクターである僕であれば、複数部署とのコミュニケーションであったり、あとユーザーの立場に立った利用者目線で開発するというところは得意なので、そこはエンジニアよりも「任せてね」という関係でやっています。

逆に僕は技術的な判断というところがかなりできないので、その点はエンジニアの方に頼って、お互いの苦手な部分や得意な部分を補完し合ってやっている、という関係になっています。

チーム内のワークフローは、（スライドを指して）だいたいこのような流れになっています。

施策を決めてからリリースした後の分析が終わるまで、小さいものでだいたい2週間。大きいものだと1ヶ月くらいかけてサイクルを回していっています。今回はこの中でも、「施策決め」「デザインレビュー」「指標とログ」を決めるところ、最後に「テスト」と「リリース後の分析」。この5つについて、より詳しくご紹介できればな、と思います。

横串でデザインを評価するための「デザインレビュー」

ではまず1つ目、「施策と体験を考える」という話です。自明ではあるんですけれども、まずどんな施策をやるのかを決める前に、「その施策をなんのためにやるのか」という目的と、その目的を達成するための仮説を最初に明確にする、というところがとても大事になってきます。

目的と仮説を明確にしていると、常に「なんのためにやっているのか」というところが意識できますし、また全員が同じ方向を向いて開発ができる。よくあるんですけど、途中で「これ、なんのためにやってるんだっけ？」と立ち止まってしまう場合があるんですね。そのときにも、この目的と仮説が明確になっていると、すぐに立ち戻れるというメリットがあります。

また僕のチームでは、アイデアを全部GitHub issue上で発散するようにしています。よくあるのがブレストという方法だと思うんですけれども、このGitHub issueを使ってアイデアを出すメリットの1つとしては、自分のチームだけではなくてそのリポジトリ、issueが見れるほかのメンバーも、アイデアを出せる環境。オープンにする、というところを1つの目的としてやっています。

アイデアを出したあとは再びみんなで集まって、先ほど立てた目的に沿ったものであるかを基準に「じゃあこれをやっていこうね」という施策を決めていく、という流れになっています。

2つ目が「デザインレビュー」。先ほどの施策を決めたあとに、プロトタイピングをいくつか作ったりするんですが、プロトタイプを作って「良さそうだね」というものをすぐ実装するのではなくて、クックパッドではまず「デザインレビュー」を通すようにしています。

デザインレビューとは、目的と背景、「なんでそういうデザインにしたのか」というデザインの意図を明確にした上で、これをまたGitHub issue上で、チーム内外のデザイナー・エンジニアからレビューを受けられる体制です。

デザインレビューは、職種・部署関係なく横串でデザインを評価するための仕組みで、レビューを受けることによって品質の向上や維持にもつながります。またGitHub issue上でやるというところで、デザインの変更の経緯がどんどん蓄積していくので、そのへんをあとで参照できるというメリットもあります。

デザイナー・エンジニア関係なく行うので、議論による新たな発見もこのレビューを通して出てくることがあります。

3つ目が、施策の指標とログを決めるところの話です。自分たちがやろうとしていることが、しっかりユーザーに届いているかを評価する必要があります。そのためにデザイナーとディレクターを含めてチーム全体で、実装前にどういうログを仕込むかとか、どういう評価をしようか、という話をみんなで集まって、漏れがないように確認しています。

デザイナーやディレクターも、「ログの命名はこのほうがいいんじゃないか」って言ったりもするんですけど、そういったところもクックパッドならではなのかな、と思います。

指標が決まったら、すぐに数値が目に見えるかたちにします。まずダッシュボード化できるものはどんどんやっていきます。僕のチームでは、だいたいRe:dashを使ってました。その作ったダッシュボードも放置するのではなくて、プロジェクトもしくはチームのリポジトリ……（スライドを指して）右側の感じですね。

READMEとかにリンクしておいて、いつでもすぐ「あの施策の数値はここだよ」と見れる状態を作っています。

考慮漏れを未然に防ぐフレームワーク

実装したあとにすぐリリースするのではなくて、まずテストをチーム内で実行しています。その、チーム内で手動テストを実行するお話です。機能変更とか、ユーザーのステータスによって見た目の仕分けが必要となってくる場合に関しては、チーム内でエッジケースを含めたテストケースというものを作って、確認するようにしています。

テストケースはもちろん、そのアプリの利用シーンや利用ユーザーを考えて、シナリオを描きながら作っています。リリース前にもアプリ開発者全体で確かめる機会はあるんですけれども、できるだけ事前にチーム内で確かめて問題がないかを洗い出し、チーム内で解決することを目標にやっています。

テスト上で問題が出たら、すぐに箇条書きにしてissueに溜めておきます。よくチームでは、「問題が出たら書くスレ」と呼んでいますね。そこで対応すべき優先順位と施策をセットで溜めていって、どの問題から対応していくかもチーム内で話し合っています。

そんな手動テストですが、エンジニアだけでなく僕のようなデザイナーもよくテストケースを作ってやるんですけど、実際にテストしてみるとデザイン上の考慮すべきポイントがかなり抜けている、ということに気付くんですね。

例えばエラーのときにどういうバリデーションを出すかとか、読み込み中にどういうプレースホルダーを出すかとか。あと小さい端末やタブレットの考慮漏れがあるよ、というような問題ですね。

こういうデザイン上の細かい漏れを事前に防ぐ工夫が、クックパッドには存在しています。それが、社内では「つよいUI」と言われているフレームワークです。

この「つよいUI」とは、よくある考慮漏れとか、あとで見つめ直すべきポイントをまとめたもので、issueを立てたらissueのテンプレートで勝手に出力されるように設定しています。

デザイナーはデザインを作ったあとに、これらのチェックシートを上からなぞっていって、例えば「iPadとiPhoneをちゃんと考慮したデザインを作ったか」とか、「エラーのときの表示をちゃんと考えましたか」というところを上から順番に見直していって、未然に防ぐという工夫をしています。

実際にこの「つよいUI」を導入してからは、実装後に「改行のときどうするんだっけ？」とか「データ0件のときどうする？」といった、先ほどのような考慮漏れが圧倒的に減ったと思っています。

リリース後の分析の型「Report.md」

最後に、リリースをしたあとの分析の話です。今までは分析をするときに、（スライドを指して）左のように施策を振り返ってみたものの、その施策を振り返っている「人」によって、分析の精度がけっこうまちまちで。あとでほかの人が見ても「これどういう結果なんだっけ？」とか、キャッチアップに時間がかかったり、そういう問題があったんですね。

また、いろんなチームで施策を走らせて分析を行っていたりするんですけども、「ほかのチームのあの施策がどういう結果だったのか」というところに、すぐアクセスできないという問題がありました。そこで、誰が分析してもあとで見返したときに、必要な情報がそこにまとまっていて、「チーム内外の共有がすぐできるよ」という状態を作りたいね、という話が出てきて。

そこで生まれたのが、先ほどの発表にもありました「Report.md」です。

「Report.md」とは、施策の実施後、分析するときに利用する「型」で、基本は仮説・試算・実数・考察・次のアクション、の5項目について振り返っていきます。これもGitHubのリポジトリで管理しているので、チーム内外を問わず誰でも見れる状態になっています。

分析をデザイナーやディレクターも行うことがあるんですけども、そのとき、中には自らSQLを書く人もいます。書いたらプルリクエストを出して、チーム内でレビューし合って、「それ良いね」とか「ここ直したほうが良いよ」というかたちで、どんどん分析のクオリティをチーム内で高めていく、というフローになっています。

この「Report.md」を導入したあとは、チームの外の人が施策の内容を確認しても、このように「初見で理解できてわかりやすかった」という声が出てくるようになりました。

以上が、あるチームのワークフローになります。今紹介したようなワークフローを、ほかのグループのほかのチームも並行していくつか走らせています。チームは分かれているんですけど、クックパッドというサービスは1つですよね。「全体のストーリーがちゃんと正しく設計されているか」とか、「ユーザー目線に立った判断や取り組みができているか」というところが、すごく大事になってきます。

デザイナーがサービスを横断的に見るための2つの取り組み

そんなクックパッド全体のサービスを、横断的かつ俯瞰的に捉える役割と取り組みが存在しています。最後に、そんなクックパッドのサービスを横断的に見るデザイナーの取り組みについて、2つご紹介したいと思っています。

まず1つ目が、「デザインリリースマネージャ」という話です。デザインリリースマネージャとは、アプリをリリースする際に、ユーザーの体験やUIに変更がある場所を把握して、リリースするバージョン単位で開発をサポートする人を指しています。

デザインリリースマネージャは誰か1人に固定するのではなくて、デザイナー間で交代して、バージョン単位でコロコロ変えていく、という担当になっています。開発開始からリリースするまでの間ずっと見守るので、途中で体験を阻害するような変更があった場合には、「これはなんのためにやるんですか」とか、「どういう目的でやるんですか」ということを1個1個聞いていって、徐々に修正していくと。

場合によっては、次のリリースに見送って「もう1回ちゃんと考え直しましょうね」という判断をするような役割も持っています。

開発が終わってリリースするまでの間に、アプリに関わるデザイナー全員が集まって、できあがった機能と全体の体験を触って確かめる「デザイン確認会」というものがあります。そのデザイン確認会を主導するのも、デザインリリースマネージャの役割となっています。

デザインリリースマネージャは、開発開始からリリースするまでの間つねに、一貫して体験を見続ける、という役割です。

2つ目が、「デザイン会」というデザイナーだけの横断会です。

デザイン確認会は、週1回、1時間くらいですね。クックパッドのアプリに関わるデザイナーはもちろんですけど、クックパッドという会社の、レシピサービス以外のプロダクトにも関わっているデザイナー全体で参加する会です。

ここでは主に、LTによる個々の知見共有であったりとか、サービス全体の課題共有を行っています。例えば「今こういうことを考えてるんだけど、ほかのデザイナーはどう思いますか」っていう話や「こういうプロトタイプを作ってみたんですけど意見聞かせてください」とか。

そういうふうに、サービスや組織で行っている取り組みを共有し合って、意見交換を行う場になっています。

チーム・組織の全体でユーザーを考えられる仕組みを作る

ここまで「素早くユーザーに価値を届けるための、クックパッドのワークフロー」をご紹介してきました。少し早いんですけど、最後に簡単にまとめます。

クックパッドでは素早くユーザーに価値を届けるために、途中で立ち止まって戻ることがないように、目的や仮説を明確にして最後までブレないようにしています。また、「つよいUI」や「Report.md」といった、誰が取り組んでも考慮漏れが発生しなかったり、意思疎通が図れるような工夫を、フローの随所に取り入れています。

また、個々のチームがばらばらに自走しているだけではやっぱりダメで、1つのサービスとして、「ユーザー」を主語にストーリー横断的に見る、という取り組みを行っています。

最後に僕からひと言なんですが、デザイナーは「ユーザー」を主語に、できるだけ早く最高の価値を届けるのが仕事だと思うんですけれども、ユーザーを考えるということはデザイナーだけではダメで、またほかの人に任せるということでもぜんぜんダメです。

サービスに関わるチーム・組織の全体でユーザーを考えることがすごく大切になってきて、今回ご紹介したように、誰でもユーザーを意識できる・考えられる仕組みを作ることもまたデザイナーの役割の1つかなと思っています。

以上、ご清聴ありがとうございました。

（会場拍手）