池田 拓司
クックパッド株式会社

クックパッドのさまざまなサービス開発について、その特徴など、さらにお聞きしたいのですが。

サービスを開発するときには「サービス企画シート」というものを使って、一体どんなサービスなのか、最初によく考えます。コアな機能やユースケースの他に「この機能はやめておきましょう」と、諦めることもシートに書きます。これらをまずやっておかないと、あとでブレたり、サービス自体がよくわからないものになってしまいがちです。
 
また、毎日の仕事ではGitHubのissue機能を利用して全デザイナーがお互いに何をしているか把握しています。オンラインでスタッフがやりとりできるため「このアプリの問題点はここにあります」とか、「ちょっと補足します」などと言って、開発に関する議論が起こることも日常的にあります。開発というものは「できたら終わり」ではないので、話しあっていいものにしていくというプロセスをワークフローに入れています。

サービス企画シートや話しあいのプロセスなど、非常に興味深いです。池田さんが部長をお務めになっているユーザーファースト推進部は、そうしたサービス開発においてどのような役割を担っているのでしょうか。

ユーザーファースト推進部は、クックパッドのユーザー体験の責任を負っています。そのため、本体アプリの方向性などの判断を行っているのは、基本的には私たちの部署です。また、「ユーザーの代表としての感覚を狂わせない」という大事な役目も私たちにはあります。ユーザーの目線で「これは不必要だ」と言うこともあるんですが、そのときには最終的には理由はなくてもいいことにして頂いていまして。「感覚で決めることも必要」と言われているので、（理由を言語化できないときでも）安心して意見を言うことができます。
 
このような立場で他部署とともにサービスをつくっていくんですが、ユーザーファースト推進部ではデザイナーがコーディングもしますし、エンジニアがデザインすることもあります。ユーザーとの接点に関しては、デザインだとかエンジニアリングだとか、そういう垣根は意識していません。そもそもエンジニアリングを通らなければユーザーにサービスは届けられませんし、技術を知っているからこそ、サービスを届ける責任を果たすことができると思っています。

クックパッドの場合、サービスを届けるユーザー数が圧倒的に多いですよね。しかも生活に近いサービスのため、ユーザーが求めるものも多種多様だと思います。そんな状況のもとでベストなサービスを届けるのには苦労しそうですが、そのあたりはいかがでしょうか。

難しいのは、あまり使われていない機能をどうするか、ということです。もともとのユーザー数が多いので、「あまり使われていない」と言っても、たとえば毎日3万人のユーザーが使っている機能だったりすると…。

仮にユーザーが1000万人いるとして、そのうち3万人しか使わない機能だとしても、それを消してしまうことで3万通の苦情が来たら驚きますよね（笑）。

ただ、そうなってくるとどの機能も削れなくなってしまいませんか。

それについてよく考えているのは、なくしたいと思っている機能を別の形で届けられないか、ということです。違う形でその機能を届けることで、今まで使っていなかった人も使いたくなるようなコアな機能へと変わっていくんじゃないかな、と。

使われていない機能のお話がありましたが、ユーザー体験をよいものにするには、他にもさまざまな工夫が必要そうです。

クックパッドでは、新規ユーザーにもわかりやすいようにオリジナル性の高い内輪向けの言葉はできるだけ減らすといった工夫もしています。

大切なことですよね。ただ、既存ユーザーに向けて最適化していくこともサービス開発では必要だと言われています。そのあたりのバランス、どうされているのかお聞きしたいです。

多くの人が見ると考えられるページでは内輪向けの言葉を言い換えたりしながら、一方で、サービスの名前には（クックパッドという）コミュニティー独特の雰囲気を残すようにしています。名前の最終判断にもユーザーファースト推進部が関わっていて、「アルファベットはやめる」など、コミュニティーの雰囲気を保つための努力をします。

技術に長けたデザイナーは、やはり高く評価されるのでしょうか。

クックパッドのデザイナーには、評価基準が5つあります。簡単に言うと、「技術」「行動」「ユーザビリティ」「ビジュアル」「スピード」です。ただ、技術＝コーディングができること、ではありません。もちろんそれも技術のひとつですが、さまざまなデバイスにあわせたデザイン能力も技術ですし、ユーザーと話をして核となるニーズを引き出すことも技術として評価されます。
 
さらに、そういったさまざまな技術をみんなに広めることで、ひとりの仕事をたくさんのスタッフに生かしていこうとしています。たとえば「開発者ブログ」のようなところでデザイナーが技術をアウトプットしたりですとか。そういう活動が「行動」として評価されます。

エンジニアリングのわかるスタッフをどうやって育てているのか気になります。

「技術研修室」のような部署を用意していて。新卒で入社した一般職の人などがサービス開発に関わる上で、技術がわからないために困ってしまうことがありますよね。そういったスタッフに向けた部屋で、開発に関する一定のスキルを身につけるためだけにある部署です。

新しい技術を習得してストックしておかないと、いざというときに使えなかったりしますが、日々、スタッフが技術を身につけていくための仕組みのようなものは他にありますか。

個人に委ねている部分もありますが、仕事終わりなどに勉強会を開いてツールのデモンストレーションをすることはありますね。

もちろんこれも、教える者も学ぶ者も「行動」しているとして評価されます。

そういった行動を評価の対象にするのはすごくいいですよね。評価されるとわかっていれば、学習のモチベーションも高まります。

勉強会などで技術を学ぶことは大事ですね。

技術への理解がなければ、よりよいユーザー体験は送り届けることができないと思います。
 
たとえば事業部が増えて組織が大きくなると、売り上げやユーザー登録数などの断片的な数字ばかりを見てしまいがちです。ビジネス的な数字も必要ですが、それよりも「ユーザーは今晩の献立が決まったのか」という根本的な部分を考え続けるようにしています。断片的な数字だけでなく、ユーザーがどんなストーリーをたどっているかを可視化することにも取り組んでみています。
 
クックパッドのサイトを見てレシピを探して、作った料理に家族が「おいしい！」と言ってくれた、というのがユーザーのストーリーで。レシピの保存数を増やすといったビジネス的な目標だけを追うのではなく、断片的な数字から導かれたつながりのあるストーリーをしっかりと捉えて、ベストなユーザー体験を設計していきたいですね。