買物情報事業部の根岸です。寒いですか。僕は今名前がわからない簡易暖房みたいなものの前にいるのであったかいです。今日は、僕がサービス開発エンジニアとして行っているサービス改善プロセスの一部についてお話させて下さい。

サービスの価値を高めるための改善は、より少ない人数で、より速く行うことが重要になります。これは、意思決定を最小限必要な人数以上で行うとコミュニケーションコストが高くなること、また、意思決定は一定の確率で失敗するものなので、イテレーションの速度を早くすると結果的に全体の価値を高めることなどが理由です。

それでは、最小の改善とは、最速の改善とは一体どのようなものなのでしょうか。

最小の改善が行われる単位

最小の改善が行われる単位は、サービスの開発を行っている個人です。個人が、改善の対象となっているサービスの課題を発見して解決へと導くことが最小の改善になります。

リリースしたサービスでメトリクスを取得することでもなく、限定リリースを行ってユーザの動向を細かくチェックすることでもなく、社外のユーザーを呼んだユーザビリティテストでもなく、社内にいるモデルユーザーへのヒアリングでもなく、チームでコミュニケーションを取って改善策を決めることでもありません。

改善が行われるプロセスは実装でも、サービス設計でも起こりえます。クックパッドのふつうのサービス開発エンジニアがサービスの改善をしようとしているとき、改善の対象は実装だったりペーパーモックだったり価値仮説だったりします。サービス開発エンジニアは、仕様に沿った実装だけを行う職種ではありません。

最小の改善単位に対する最速の改善

それでは、最小の改善単位を最速で回すために何が必要なのでしょうか。書き下すと、下記のような内容だと考えています。

• サービスのユーザーを理解する
• サービスのユーザーなど、価値モデルを自分の機能的人格の一部とする
• 価値モデルとしてのユーザーのために、コミュニケーションコストを最小化する

順に説明していきます。

サービスのユーザーを理解する

サービスのユーザーにとって価値が高い状態を作るためには、サービスのユーザーが何者なのかを深く理解する必要があります。この観点ではすでにこのブログでもいくつかエントリーが書かれています。

• 自分がユーザーになる ->新規アプリを開発する際にディレクターとして心がけたこと
• 実在するユーザーにインタビューし、モデル化する ->クックパッドでのユーザ調査

買物情報事業部が提供している特売情報はB2B2Cなプラットフォームサービスなので、ユーザーには買い物をするお客さんと、特売情報を入稿するスーパーの店員さんがいます。サービス開発エンジニアは買い物客になることはできますが、サービス提供者としては本質的にスーパーの店員さんにはなれないので、普通に考えるとスーパーの店員さんに対してはインタビューだけでユーザー理解を進めなければなりません。一方で買物情報事業部では、所属しているメンバーは全員、スーパーの業務を丸一日お手伝いしつつ、投稿作業を行うということを少なくとも一回はやっています。

そこら辺歩きまわっていらっしゃいませいらっしゃいませと言っていると、今日の焼き芋は本当に大きいわねとお客さんが世間話を仰ります。本当にそうですね、おいしそうな匂いですね〜。と返答して温かい気分になります。しかしながら商品の撮影のために手に持っているスマホを、みんなが見ている気がします。確かに店員さんが携帯片手にフラフラしてたらなんだこいつと思いますよね。冷や汗を書きながら写真を撮影したところで、あ、こないだのインタビューで投稿する店員さんが"特売情報投稿中"っていう腕章をつけている店舗があってすごいな〜と思ったけど、あれの役割のひとつはお客さんに対するエクスキューズなのかもなと唐突に思い当たります。発明の価値の大きさに感無量です。バックオフィスでIE8に向かい合って、撮影した写真を入稿しようとすると、ホコリ取りカバーが付いているディスプレイでは、淡く調整された投稿画面のインターフェース要素のコントラストが低すぎて視認しにくいことに気づきます。とにかくつらいです。入稿を終えてアルコール飲料の品出しに回ると、僕のことをクックパッドの社員だと知っている店員さんが話しかけてくれます。「クックパッドに投稿始めてからベビーカーを持った若いお客様が増えて、通路広げるの検討しようって言ってます」 えっ、本当ですか、すごいなあ、嬉しいなあ。確かに、午前中なのに若い人が多いですね。

とにかく自分がユーザーの立場になると、サービスを利用している情景が自分の中にある状態となります。インタビューが不要なわけではなく、両者が補完しあって精緻なユーザー理解に繋がると思います。

サービスのユーザーなど、価値モデルを自分の機能的人格の一部とする

この、精緻な理解に基づいたユーザーが、自分の人格の一部となることがとにかく重要になります。出来上がった人格を個人の中で価値モデルとして取り扱い、壁当て、サービス価値の向上に使えるからです。 実装者・サービス提供者である自分を一旦忘れて、何らドメイン知識も持たない状態でインターフェースを操作して、何が起きるか理解できるか、期待した動作をしているか、価値を感じるか、結果として仮説が正しいかを検証していきます。

さて、ユーザーのことばかり話していましたが、組織に所属するサービス開発エンジニアとしては、サービスを改善する上で様々な観点があると思います。

• 1) この仕事に従事していて良いか
• 2) サービスのユーザーにとって価値が高いか
• 3) 組織の目的に沿っているか
• 4) 実装可能か
• 5) 新しく配属されたメンバーの教育に沿っているか
• 6) SEOの戦略に沿っているか

みたいな感じです。(1)が個人的意思決定で、残りが組織的意思決定の観点になると思います。 (2)のユーザーにとっての価値モデルを先ほど機能的人格の一部として分離したことで、他の観点も全て人格として分離することが可能となります。

• 1) 労働者としての自分自身
• 2) サービスのユーザー
• 3) 組織のリーダー
• 4) エンジニア(デバッグ用のクマ)
• 5) メンター
• 6) SEO推進者

これらの人格が頭の中でワイワイ合議するということが、僕が捉える最小かつ最速のサービス改善の実体です。

価値モデルとしてのユーザーのために、コミュニケーションコストを最小化する

しかしながら、現実の世界と同じく、払うことができる検討のコミュニケーションコストと言うのは有限なので、6人でフルパワーで合議を行うとかならず混乱が起きます(価値仮説から想定されるユーザの検索クエリとmeta descriptionの内容が乖離してるクマ〜)。

ここで、チームメンバー間でコミュニケーションをする上で、要点をまとめるためのフォーマットの存在が重要であるように、ある程度定型化された意思決定プロセスに落としこむことが省力化のために重要になります。たとえば僕は、SEO推進者のためのチェックリストを持っています。

こういった省力化によって、最も重要な人格であるサービスのユーザーの人格が、ニコニコいかにこのサービスが理解不能かを話しているのを、みんなが黙って聞くという状況を作ることができます。

そして、結果として改善のスピードが最速になります。

おわりに

最小の単位で最速の改善を実行して、サービスの価値に確信を持ったら、チームメンバーに見せに行きましょう。リリースしましょう。そして、自分の確信が間違っていたことをすぐに知るでしょう。これは大抵の場合で、自分が作り上げたサービスのユーザーとしての人格、価値モデルが間違っているからです。しかしそれでも、価値に確信を持っていないものをリリースしてもよいサービスは生まれないでしょう。検証を経て、価値モデルを修正し、またさらに改善をし続けることが重要なのです。

徹底して最小、最速の改善が行えるようにしましょう。そのために、個人で良い意思決定ができるようになりましょう。最良の価値は、最も速く改善を繰り返したサービスから産まれるからです。