〜課題解決のアクションを積み重ねることで、チームをつくる。「最初からやりすぎない」クックパッドマートの組織づくりとは〜

クックパッド株式会社が「買い物」の領域で手がける新サービス「クックパッドマート」。2018年より3人で事業開発をスタートした同サービスには、現在14名のエンジニアを含む30名ほどのメンバーが所属している。

事業部の副部長、そしてテックリード（エンジニアマネージャー）を務める勝間 亮さんは、そのチームづくりとマネジメントにおいて「最初から仕組みづくりをやりすぎない」ということを意識していると話す。

その代わりに、問題や課題が出るたびに、それを解決するアクションを実行している。

具体的には、Slack上に「意思決定したこと」だけを流すチャンネルを設ける、エンジニア同士で技術的な情報を交換できる定例会を行う、「他の人にはつまらないと思われそうな些細な質問」だけを話すランチをする…といった取り組みがあるそうだ。

こうした施策を少しずつ積み重ねることで、チームとしてうまく回るようにする、ということを目指す。この考え方の背景には、新規事業においては「事業を前に進めることを、まずは優先すべき」という思いがあるという。

今回は勝間さんに、クックパッドマートのエンジニアチームにおける組織づくりについて、詳しくお話を伺った。

組織づくりは「最初からやりすぎない」ことが大事

2009年にクックパッドに入社後、料理レシピ投稿・検索サービス「クックパッド」で、サーバーサイドを中心とした開発に4、5年ほど従事しました。その後、同じレシピサービスの領域で、サービス開発部のマネジメントを4年ほど経験しました。

そして2018年からは、レシピサービスから離れ、新規事業である「クックパッドマート」の立ち上げチームに入っています。

いまのポジションとしては、自分で開発もしつつ、テックリードという立場で開発組織のエンジニアマネジャーをしています。それに加えて、事業部の副部長として、サービス開発の領域を責任者として見ています。

サービス開発部のマネジメントをしていたときは、30人近くのエンジニアやデザイナー、サービスディレクターたちで、クックパッドというひとつのサービスを運営していました。

なので、いかにうまく無駄をなくした役割分担をして、それぞれが交通渋滞を起こさないように自律的に動くにはどうすればいいか、ということが課題でしたね。

当時はその課題を解決する仕組みとして、Spotifyの開発モデルを導入し、メンバー1人ひとりが会社の方向を向きながら、自律的に動くための仕組みづくりを行いました。当時はこの仕組みによって開発のスピードが上がり、うまくいったな、という手応えがありました。

一方、今回は新しい事業なので、最初は3人のチームからスタートしました。2018年の春頃から少しずつメンバーが増えてきて、いまは全体で30名、うちエンジニアが14名という状態です。

ここからもっと人が増えてきたときに、組織としてどういう課題が出てきて、どんな取り組みをしないといけないだろう…ということは、過去の経験からイメージが湧いている部分はあります。ですが、現時点でそこまで組織づくりを頑張る必要はないかなと思っていて。

それよりは、事業を前に進めること、事業として実現したいことをちゃんと形にすることを、エンジニアには意識して優先してもらうようにしています。

これまでの経験からも思うのですが、チームづくりにおいて「最初からやりすぎない」ということはひとつ大事かなと。

新しくマネジメントをする人だと、「あれもやらなきゃ、これもやらなきゃ」と色々出てくると思うのですが、やはり一番重要なのは、事業をちゃんと前に進めることですよね。

なのでいまは、先に仕組みを整えるというより、何か問題や課題が出るたびにそれを解決するアクションをする。それを少しずつ積み重ねることで、チームとしてうまく回るようにしていく。この進め方のほうが良いのではないかと考え、マネジメントに取り組んでいます。

領域間の情報共有がカギ！Slack上で「決めたこと」だけを共有

クックパッドマートは、クックパッドが新しくスタートした生鮮のECサービスです。農家さんの朝採れ野菜や、街の精肉屋さんのお肉、行列ができるベーカリーのパン、といったこだわりの食材が、簡単にスマホのアプリで注文できます。

特徴的なのが配送料です。配送コストをできるだけ下げることを目指しているので、パン1個、お肉1個、といった買い物でも配送料は0円です。その代わりに、自宅に届くのではなく、街にある色々なスポットが受け取り場所に指定されています。

このような仕組みなので、サービスはユーザー、販売者・生産者、受け取り場所、それぞれをつなぐ流通の4つの領域に大きく分かれています。それぞれの領域にプロダクトマネージャーがいますが、メンバーは明確にグループ分けされているわけではなく、もう少しゆるい役割分担のような形になっています。

自分たちの部署で特徴的かなと思うのは、なるべくそれぞれが自分たちで意思決定して、進めていくことを意識していることです。

ですが、皆がそれぞれの領域で仕事を進める中で、「自分がやっている領域以外のことが、よくわからない」という話を聞くようになって。

そこで作ったのが、「自分たちが意思決定したことだけ」を流すSlackのチャンネルです。

▼「決めた」チャンネルの投稿例（クリックで拡大します）

今日、誰が何を意思決定した、ということだけが流れるチャンネルなので、これを見ているだけでも、各領域で何が進んでいるのかを大体追いかけることができるようになっています。

ここでは決定事項の共有のみで、そこからの議論はしません。気になることがあれば、個別に話しています。

逆に言うと、このチャンネルに情報が流れてこない＝意思決定をしていない、ということになるので、「何か最近、この領域は何も決めてないんじゃないか？　何か問題があるのだろうか」といった風に捉えることもできます。

こうして、なるべく誰が何をしているのか、皆がわかるようにしています。

エンジニア同士の情報共有のため、定例会やランチ会を開催

また、エンジニア同士の情報共有についても、課題が出るたびにそれを解決するアクションをとってきました。

まず、自分がいま何を目指して、何に取り組んでいるのか、ということを共有する定例会を設けています。それに加えて、2〜3週間に1回ぐらいの頻度で、持ち回りで技術的な発表をする会を行っています。

これらの取り組みによって、お互いのやっていることや、技術に関する情報共有はかなりできるようになりました。結果的に、自分が取り組んでいる領域以外にも興味、関心が持てるようになりますし、オペレーション面のノウハウも共有されるので良かったなと。

ただ、こうした取り組みが進んだ一方で、「ささいなこと」を聞きづらい雰囲気がちょっと出てきてしまって。

「これ、いまさらちょっと聞きづらいな…」ということが増えてきたので、じゃあ、そういう話だけする会でもするか、と始まったのが、他の人にはつまらないと思われそうな些細な質問だけをするランチ、通称「しょうもないことしか聞けないランチ」です（笑）。

「◯◯っていうキーワードはどういう意味ですか」みたいなライトな話から、「アプリのあの画面って、本当にあれでいいとみんな思ってるんですか」といったまじめな議論まで、幅広く自由に話しています。自由参加なのですが、毎回7、8名が参加していますね。

他には最近、1on1のやり方を変えました。もともと1on1に関しては全メンバーが上長と月に1回行っていたのですが、これまでは「最近、どんな感じですか」とか「何か困っていることはありますか」といった話をしていたんですね。

それをやめて、いまは1on1でKPTをするようにしたのですが、これは良い感じにワークし始めているかな、という感覚があります。お互いに、話す内容をあらかじめイメージしやすくなりましたね。

また、メンバーが出してくるKeep（良かったこと）に対して、「なるほど、こういうことが良いと思っていたんだな」といった形で、私自身が気づきをもらうようなケースも増えましたね。

事業が掲げるビジョンの実現が、いまは第一に語られるべき

エンジニアとしての目線からチームづくりを考えると、例えば技術的な成長をどう考えるか、開発基盤をどうしていくか、R&Dは…といった話は当然でてきます。

ただ、やはり事業のフェーズに応じて、エンジニアが果たすべき役割は違うと思っています。いまのクックパッドマートではあくまでも、「『おいしい』の笑顔が集まる場所をつくる。」というビジョンの実現が第一で、優先して語られるべきだと私は思っていて。

その上で、エンジニア1人ひとりがどういう技術を身につけて、どう成長していくのか、という話になると思っています。一番大事にすべき軸は、事業によって変わってくると。全部は優先できないので、どこに重きを置くのか、ということですね。

ミッションやビジョンについて、普段から言葉で発する機会は多くはないですが、なるべく日頃から意識できるように、自分たちの執務エリアにそれらのワードを印刷したパネルを貼っています。

▼実際の壁面

他にも、エンジニアも含めて全員が事業の状態を共有するために、隔週で部署全体の定例会を行っています。事業部の数字や、今後どういうことをやろうとしているか、といったことを共有しているのですが、その場で、誰でも自由に意見が言えるようにしているんですね。

ただ、自分から意見を出すとか、手を挙げて話すといったことに抵抗がある人もいるので、それはSlack上の「実況チャンネル」で気になったことをどんどんつぶやいていいことにしています。

「お、これいいな」とか「これよくわからんな」とか、そんな感じでリアルタイムにリアクションが出てくるので、発表者がそのコメントを拾っています。

今後は私個人でいうと、エンジニアリングをきちんと軸として持ちつつ、事業という視点をもっとしっかり持てるようなエンジニア、もしくはエンジニアマネージャーになっていきたいです。その上で、いまの新規事業の開発という環境は、自分にとってすごく良いチャレンジだと思っています。（了）