こんにちは。投稿推進部の清水(@pachirel)です。 2009年にクックパッドに入社してから、インフラ周り、クックパッドの人事周り（採用・評価）や広告周りのシステム開発を担当していました。
2014年4月頃から、2〜3名の小さなチームで新規サービスのプロトタイピングをいくつか行っています。
企画の詳細は省きますが、私がこの10ヶ月ほどで学んだことをまとめました。アジャイル開発やLean startupの考えに共感しているので、そこから得た内容に私の体験を付け加えたものになっています。
今回はプログラミングに関する技術的な内容は含まれていません。
なぜ作るか
スタートアップが失敗する原因で一番多いのは「人が必要としていないものを作ってしまった」というものです。 The Top 20 Reasons Startups Fail
社内の新規サービス開発でも同じ傾向があるのではないでしょうか。
一方で「自分たちが作りたいものを作る」のが大切だと思っています。どうすれば「需要のあるものを自分たちが作りたいと思う」状態になれるか。それは、自分たちがそのサービスのユーザーになることです。
エンジニアがエンジニア向けのサービスやツールを作るというのは分かりやすい例ですが、仮に自分とは遠い対象に向けて作る場合、例えば料理をしない人が毎日料理をしている人に向けて何かサービスを作るとしても同じことです。
誰かのために料理を作る。家で他にやりたいことがある中でも作る。子どものために料理を作るユーザーになりきって、子ども向けのレシピを実際に作ってみる。 実際に子ども向けに料理を作っている主婦に話を聞きに行き、実際に料理をしている現場に立ち会い、子どもがそこに居る状態で料理を作るというリアルを理解する。そういう現場を目の当たりにして自分の身を持って理解することではじめて、同じ目線に立つことができます。
私はお芝居をしたことがありませんが、俳優の役作りにも近いかもしれません。 同じ目線に立てれば、その目線で自分が感じる「困りごと」や「それを解決できそうなもの」はかなり正解に近づいているはずです。その手法に自分たちのアイデアが組み込まれていれば、ユニークで競争力のあるサービスになると思いませんか。 この状態でペルソナやユーザーストーリーを書けば、ずっと信じられるものになるでしょう。私はチームメンバー全員でこのプロセスを踏む必要性を感じていて、今のチームで実践しています。
なにを作るか
ここまでで、サービスの輪郭は見えてきているので、プロトタイピングでそれを具体化していきます。私の居たチームは少数で、かつコードが書けるメンバーが私1人だったので、プロトタイプを実装しようとすると私がボトルネックになってしまい、思ったスピードでサービスの検証が進められませんでした。
そこで、モックサービスを利用しました。flintoとprottを試しましたが、デザイナーとプロジェクトを共有しやすいprottを今は使っています。最初はこれで本当に検証できるのかという不安もありましたが、実際にやってみると、かなり有用なフィードバックを得ることができ、時間の節約に繋がりました。特にデザイン（色、アイコン、配置、文言等）部分は、動くソフトウェアでなくても十分検証できます。
実際にインタビューをしてみて気づいたのは「理想のユーザーは居ない」ということです。確かに目の前でインタビューに答えてくれている方は将来ユーザーになってくれる可能性が高いのですが、人によって使い方は異なり、感想は食い違うこともあります。多数決で決めてしまうと、全体としてちぐはぐしたサービスになってしまいます。 人はひとりひとり違います。でも、実際に使ってくださるのはそういう方々です。様々なフィードバックのうち、どれを取り入れるべきかという判断に困りました。
そこで、私たちは想定している問題をきちんと解決できているか優先することにしました。想定している問題をインタビュー対象の方が同じように問題だと認識しているか確認できていることが前提にはなりますが、その上であれば細かい部分はリリース後に数字を見ながら改善していけばよいと割り切りました。どうしても、ユーザーインタビューでは数が確保できないし、インタビューよりも実際に使ってもらったほうがより正しいフィードバックを得ることができます。
この方法を取るためには、自分たちのサービスが何の課題に向き合っていて、解決できているかをどういう指標で見るかということが大事です。
Lean analyticsではそれをOMTM（One Metric That Matters: 最重要指標）と呼んでいます。例えば、クックパッドを例に取ると、ページビューが多いことは必ずしも良いことではありません。レシピを素早く決めたいと思っている人にとっては、ページビューは少ない方がいいのです。ページビューの増加がユーザー数の増加によるものなのか、ユーザーの迷いの結果なのかがこの指標だけでは判断できません。この指標はレシピ検索サービスの満足度の指標としては悪い指標です。サービスの質に直結する指標を設定するのが重要です。
きちんと指標を決め、計測をし、それを統計的に意味のある形で理解する必要があります。最近、日本語訳が出たLean Analyticsは去年、社内で読書会をして英語で読みましたがとても参考になりました。統計学は社内で何冊か読書会をしたのですが、その中では入門統計学が数学の難しい部分をなるべく省いて、統計学の雰囲気をつかめるように書かれていて、一番読みやすかったです。
インタビューの手法については、 Running LeanやLean customer developmentを参考にしています。
Lean customer developmentについては翻訳が出ておらず、私も読んでいる最中ですが、日本語ではこちらのスライドが参考になりました。 人間と話す: Lean Customer Development (Lean Startup Update 2015)
だれと作るか
先ほど、「チームメンバー全員でユーザーになりきる」という話をしましたが、その前提として、それを実践できる人だけでチームを作る必要があります。なりきれる度合いには個人差がありますが、実際にそれにチャレンジできる、してもいいと思えるテーマかどうかはそのプロジェクトが成功するかどうかのテストの1つになると思います。 ここで躓くならば、最初から始めない方がよかったなんてことがあるかもしれません。自分にその熱意がないなと思ったらそっと手を引くのも長期的にはチームのためになると思っています。
異なる専門性を持つメンバーでチームを組むというのも重要です。 サービス開発に必要なあらゆる要素に専門性を持つメンバーが居れば完璧ですが、世の中そんなにうまくはいきません。 スタートの時点できちんとメンバーを揃える努力をするのはマネージャの仕事とはいえ、自分たちのチームはどの分野が強く、どの分野が弱いのかということを全員が把握しておく必要があります。
そして、チームに足りないものを補ったり、良いところを伸ばしたりすることで戦える状態を作るのです。
サッカーなどのチームスポーツに例えると、選手の特性を把握して適切なポジションを決めたり、素質のあるメンバーを足りないところにコンバートしたりすることが必要です。その上で、メンバー間の理解を深めていきます。
このあたりは「ジャイアントキリング」という漫画に最近ハマっていて、おすすめです。引退したエースストライカーが元居たサッカーチームの監督になって低迷するチームを再生していくストーリーで、漫画みたいにうまくいくことはそうそうないですが、こういう物語に感化されて思い切った行動ができて、良い方向に向かえばいいよねと思っています。
ファシリテーションやスクラムのケーススタディとしては、ザ・ファシリテーターや SCRUM BOOT CAMP THE BOOKが参考になりました。
と偉そうに書いたものの、実際には私は管理職ではないので、用意されたチームと期待された役割の中でどうにかする必要がありました。 同じチームのメンバーとの会話を増やして何を考えているかを知り、自分の考えを共有して少しずつチームとしての役割分担を決めていくようにしました。 穏便に進めようとするとどうしても遅くなってしまうので、スピード重視の新規プロジェクトでは考え方の相違による摩擦を恐れず、コミュニケーションを取ることが重要なのだと学びました。 チャットやメールで済まさず対面で話す、笑顔を忘れない、相手の立場を尊重することを大事にしています。
まとめ
私は普段エンジニアとしてRubyやSwiftを書いているのですが、今回は新規サービス開発を通して学んだことについて書きました。
エンジニアとして、自分が心をこめて作ったものがたいして世の中の役に立たずに消えていくというのはくやしく、寂しいものです。そういう経験を少しでも減らすために、コードを書き始める前段階から主体的に関われるチームに身を置きたいし、自分の居るチームがそういうチームになるような影響を与えられる存在でありたいと考えています。