会員事業部*1の小川（@conceal_rs）です。
会員事業部ではプレミアムサービスの価値を向上させるために、日々機能改善や新しい機能やサービスの開発をしています。今回はサービス開発をするときにエンジニアがどういう役割を果たすといいかについて、私なりの経験からの話をしたいと思います。
サービス開発とは
サービス開発とはユーザのみなさんに、アプリやウェブを通じて何らかの価値を提供することだと考えています。価値と言ってもいろいろなものや形態があり、Webサービスというとだいたいがツールぽいものを想像しますし、最近だとゲーミフィケーションを使った脳トレサービスなどもあります。また既存のサービスに新しい機能や体験を追加して価値を届けるということもサービス開発です。私が所属している会員事業部はプレミアムサービスを利用して頂いているユーザのみなさんに新しい価値を提供すべく、日々業務に勤しんでいます。
もちろんサービス開発とは、何も新しいものだけではありません。例えばバグ修正や既存機能の改善、また他社と連携した企画など、さまざまなものを含んでいます。開発規模も数日で終わるものから数ヶ月かかるものまで、果ては数人で数ヶ月以上かかるものまで多種多様な開発があります。
クックパッドでのサービス開発
ではクックパッドにおけるサービス開発はどのように行っているのか。このブログでもサービス開発についての幾つか記事が書かれていますが、ここでは私がいままで行ってきたサービス開発についてお話したいと思います。
チームで開発する
クックパッドではサービス開発をするとき、ディレクターとエンジニアがチームを組むことがほとんどで、その多くがディレクター1名とエンジニア1名の2名体制という少人数です。少人数での開発になる理由としては、クックパッドでのサービス開発ではそこまで大規模なものはあまりないということと、少人数だとスピード感があるためです。
大規模なものがないというと先ほどの開発規模の話と齟齬があるかもしれませんが、実際にサービス開発に関わるときに関わる範囲というのはそれほど大きくはありません。例えば小さな機能であればRailsで言うところのコントローラー単位になることが多く、また大きなものになったとしてもchankoのような限定公開する仕組みを使っているため、影響範囲を閉じ込めることが可能です。
別の観点では、ディレクターとエンジニアが一対一で話をするほうが、より充実した議論ができる可能性が高いということも理由の一つです。改善や機能追加であっても、どのようなものをユーザのみなさん提供するかについてしっかり議論しなければならないと考えています。議論するときにあまり人数が多くなると、論点が発散してしまって収集がつかなくなることもあります。そのようなときに二〜三人であれば、議論もそこまで発散しないですし、落とし所を探りやすいという印象があります。
ユーザへ提供する価値を考える
サービスを開発するときには、まずユーザのみなさんに提供する価値がどんなものであるのかをしっかり考えるようにしています。当たり前のように思えて意外に難しいのがこの価値を考えるプロセスです。EOGSやAARRRなど色々なツールを使うことが多いですが、まずは使ってもらうユーザさんのことをしっかり考えるように心がけています。例えばクックパッドの主なユーザは主婦層ですが、じゃあいつ使うのか、昼時ならどういう気持ち・状況で使っているのか、重要度・切迫感はどの程度かなど、いろいろなことを考えるように心がけています。
とは言え私は男性なのですべてわかるとは思っていません。そういうときは身近にいる人のことを考えたり、社内でターゲットユーザに近い人を探して話を聞いたりします。それで全てがわかるわけではないですが、よりユーザさんの目線に近い人とたくさん話をすることで、いろいろなことに気づけるので積極的にやるべきだと考えています。
またデータもわかる範囲で調べるようにしています。例えば官公庁が出している白書や調査会社が公表しているデータからわかることも多いですし、クックパッドへのアクセス情報からわかることもあります。
これらの気づきやデータも参考にして、提供する価値についてしっかりと考えることを心がけています。
効果測定する
さて価値を考えてチームで実装すればあとは公開するだけですが、ただ公開すればいいというわけではありません。事前に考えた価値に本当に効果があったかを検証しなくてはなりません。この辺りをしっかり考えておかないと、漠然と「なんとなく使われている」ということしかわからず、どう改善していいものか判断できなくなってしまう可能性があります。よりよいものを作り続けるためには、この効果測定をしっかり設計しなければなりません。逆に言うと、測定できる指標をしっかり設計しないと、何が良いものであるかを判断できないということでもあります。
エンジニアのサービス開発への関わり方
サービス開発の概要は説明してきましたが、ではエンジニアはどのように関わるべきなのでしょうか。これも私の体験からくる持論なのですが、簡単に紹介したいと思います。
企画段階では実現可能性について考えない
エンジニアであれば企画を考えたり相談したりしているときに、どれ位の期間で実装できるか、実装可能かどうかについて考えることが多いと思います。もちろん実現不可能なものを考えても仕方ないのですが、私自身は企画段階では実現可能性についてあえて考えないようにしています。「そんなことしたら無理ゲーやらされることにならない？」と不安に思うかもしれませんが、企画が固まりきるまでに実現できるかどうかを考えてしまうと、逆に発想が制限されてしまう可能性もあります。この制限によって、本当に作りたかったものではないものとは微妙に違うものができあがってしまっては元も子もありません。作りたい価値を明確にするまではできるかぎり自由な発想で議論できるようにしたいので、実現可能性についてはあえて考えないようにしています。
サービスの価値を一歩引いて考える
じゃあサービス開発するときにエンジニアが気をつけるべきことってなんでしょうか。例えばディレクターから企画が出されたときに漠然と良さそうだと感じたとしたら、そのまま実装に入ってしまうことって多いかもしれません。ただこの漠然とした感想というのが危険です。本当に良いと思っていないのに作り始めると、たいてい中途半端なものになってしまいます。そのようなときは、できれば一歩引いた状態で考えることを心がけています。ただ一歩引いて考えると言ってもなかなか難しいものです。漠然と良いとか悪いと感じることってなかなか言語化できないので説明もしづらいし、そうすると何も言えなくなって「黙っておこうかな」と思うこともあるかもしれません。
あえて「なぜ」と問いかける
そういうときの一つの方法として、あえて「なぜ何ですか？」と問いかけるようにしています。例えば「料理が楽しくなる機能」についての企画であれば、「料理が楽しくなる必要があるの？」と問いかけます。個人的には楽しくなったほうがいいと思っていますが、なぜ「楽しいほうがいい」のかについて詳しく議論されていないことも多く、また企画者がその理由を言語化しきれていない場合、チームが漠然とした価値に向かって進んでいってしまう危険性があります。そのような状態では精度が低いものが生まれる可能性が高く、公開しても価値を感じ取ってもらえずに終わることになってしまいます。これでは意味がありません。そのためにもできるかぎり問いかけを続けるようにしています。
そもそも論、極論を提示する
もう一つの方法として、「そもそも論」や極論を言うときもあります。例えば先ほどの「料理が楽しくなる機能」であれば、「そもそも料理って自分でする必要があるの？」という問いかけになります。そこで「例えばある業者が1食100円でバランス的にも食材の安全性についても完璧な料理を作ってくれるとしたら、自分で料理する意味はあるの？」という極論を出します。もちろん現実的には実現不可能だとは思うのですが、価値を考える上ではこのような問いかけをすることも重要です。
このような方法を使う理由としては、一般的に何らかの議題について話をしたり考えたりするときには、人は何かしら前提条件をおいている可能性が高いと考えているからです。考えるべき価値というのは議題の奥深くに存在していることがほとんどなのに、その表層だけをたどってしまって価値に行き着かないことがわりと多いと感じています。そのためにも「そもそも論」や極論を提示してみるのも一つの方法です。
よりよいサービス開発に向けて
このようにエンジニアが行うサービス開発といっても、企画を考えて実装するだけではなく、いろいろな役割があることをつらつらと書いてみました。もちろんこれが正解というわけではなく、他にもっといい方法があるかもしれません。日々試行錯誤しながらよりより価値を提供できるようにサービス開発を続けています。クックパッドでは一緒にサービス開発をするエンジニアを募集しています。我こそはと思われる方はぜひご応募ください。
*1:技術部長でもあります
