メディアプロダクト開発部の長田(@osadake212)です。
私の主な仕事は、ライブ配信サービスの cookpadLive などを運営しているクックパッドグループの CookpadTV 株式会社のサービス開発をすることです。CookpadTV ではサービス開発部の部長としてエンジニア組織の運営を通してサービス開発に関わっています。
本記事では、CookpadTV で取り組んでいることと、そこでのエンジニアチームの動き方や、エンジニアリングマネージャーの役割についてざっくりお話しします。

CookpadTV?

CookpadTV はクックパッドグループで動画関連サービスを提供している会社で、2018年4月に設立されました。もともとはクックパッドの事業部の一つだったのですが、素早く意思決定し多くのチャレンジをするために分社化しました。

CookpadTV は料理が持つ人を幸せにする力を信じていて、今まで良いきっかけがなくて料理を楽しめていない人たちに向けて、既存の考え方に囚われない新しい切り口でサービスを提供することで、私たちが信じている価値を届けることにチャレンジしています。
そんな私たちが運営しているサービスの一つに cookpadLive というクッキング Live アプリがあります。このサービスは 2018年3月にリリースされ、本記事の執筆時点で5年目に突入しました。

AppStore
GooglePlay

cookpadLive ではアイドル・声優・お笑い・俳優など、さまざまなカテゴリの著名人のクッキング Live を視聴することができます。今まで料理をする良いきっかけがなかった人たちにむけて、自分の推しを通じて料理の楽しさを届けており、Live 配信前後の Twitter の反応を見ていると、「普段は料理をしないけど、〇〇さんの配信を見て作ってみました！」のような投稿を見かけることがあります。普段料理をしない人にとって料理をするという行為はとてつもなくハードルが高いものですが、そのハードルを少しでも下げるきっかけを与えることができています。

今年の1月には「cookpadLive cafe 表参道」をオープンしました。自社の配信スタジオにカフェが併設されていて、配信の様子を観覧しながらキャストと同じ料理を食べて楽しむことができる体験ができるスペースになっています。
有名人に会えるLive観覧カフェ「cookpadLive cafe」が東京出店！ CAMPFIREにてクラウドファンディングを開始！

またこのカフェでは様々なアニメ作品とコラボした「AniCook」という企画が開催されており、コラボカフェ史上最高クオリティの「美味しさ」に挑戦し、アニメファンの皆さんはもちろん、アニメの版元企業からも大絶賛いただくメニューを次々に生み出していこうとしています。

サービス開発部の様子

2021年の開発の様子

サービス開発部には現在、私を含め5人のエンジニアが在籍しています。CookpadTV では大小含め多くのサービスを展開していて、50以上のサーバーアプリケーション（staging 環境や社内マイクロサービスを含む）と 9つの iOS/Android アプリケーション（独自 MDM 配信を含む）を開発・保守しています。

エンジニアの人数に対して管理しているアプリケーションの数が多いので、サーバー・クライアントのどちらの開発もできる人材が多いのがチームの特徴です。
とはいえ、並行して開発できるプロジェクトには限りがあるので、優先順位を決め、事業的にチャレンジする価値が高いものから順番に開発に取り組んでいます。

私の部では半年に一度振り返りのタイミングを設けていて、半年間でできたこと、できなかったこと、これからやりたいことの認識合わせをしています。
以下はその振り返り会の2021年の資料の抜粋なのですが、チームで開発・リリースしたものについてまとめたものです。

この他にも細かい修正や小規模な開発は常に行われており、同時期に複数の開発プロジェクトが走っている状態です。

各プロジェクトの開発の流れ

普段の開発は以下のような流れで行われています。

アイディア出し
要件整理
仕様整理
設計
実装
テスト
リリース
運用

特別珍しい開発工程が含まれているわけではないのですが、全ての工程にメンバーが関わっています。エンジニアの人数もそうなのですが、開発・配信ディレクターやデザイナーの人数も多くはないので、開発メンバーそれぞれの守備範囲が広いのが特徴です。

開発サイクルは1週間を区切りとしていて、以下のような定例をぐるぐる回しています。

各サービスの意思決定者が集まる定例（ディレクター会）
決定事項の共有と1週間の開発予定を計画する定例（開発定例）
プロジェクトのフェーズ毎に必要に応じて打ち合わせ（分科会）

この他にも短い進捗報告の場があったりするのですが、基本的にはこれらの会を軸に開発を進めています。

ディレクター会はその名の通り、開発ディレクターが集まってアイディア出し、問題報告、要件、仕様整理、開発の進捗報告、などを行っています。プロジェクトによってはこの会でエンジニアがオーナーとなり、そのプロジェクトを運用まで持っていくことに責任を持っています。

例えば、運用フェーズでも運用者に渡す前・渡した後にエンジニアが運用することがあり、自分たちで作った運用フローが業務を圧迫していないかや、事故を未然に防ぐことができているかなどを確認しています。
具体的には、実際に Live 配信の現場に立ち会って、急にトラブルが起きたらどうするかをイメージしてシステムを設計したり、 Live 配信中に大量に販売した商品を梱包して発送する作業をして、発送ミスが起きないようにするにはどういう仕組みが必要なのかを考えたりしています。

開発定例会はエンジニアが1週間をどう過ごすかを計画する場として運用しています。
ディレクター会で展開された情報をキャッチアップしつつ、1週間のタスクをどういう温度感で取り組むべきなのかをそれぞれの開発メンバーが意識できるようにしています。
また、システムで発生したエラーの振り返りや AWS のコスト振り返り、障害が発生したら障害の振り返りなども行い、システム面でも対応漏れが起きてないかを確認したりしています。

分科会は開発工程に応じてさまざまな会が都度開催されています。
設計前雑談、設計レビュー、Pull Request 補足説明、動作確認会、使い方説明会、夕会など、さまざまです。設計は Google Docs を使って情報共有をすることが多いです。

プロジェクトによって内容は変わるのですが、だいたい上の図のオレンジで囲んだような項目をプロジェクトをリードする人がまとめて設計レビューで展開します。

この設計レビューを開催する前に設計前雑談というのもやっていて、準備なしで「さぁどうしますかねー」から話始める短い打ち合わせをやっているのも特徴です。

エンジニアリングマネージャーの仕事

エンジニアリングマネージャーとしては上述の仕事を視座・視野・視点を変えて取り組む必要があります。
開発だけじゃなく、マネジメント・経営・ビジネスについて理解できていないことや、そもそも知らないことも本当に多いのですが、この会社・このチームのエンジニアリングマネージャーとして、私が普段から心がけていることを紹介します。

社内で起こっていることをちゃんと把握する

CookpadTV はエンジニア以外にも多くの役割の社員が在籍しており、 cookpadLive をはじめ、全てのサービスは他の事業部の人と協力して開発・運営しています。すごく当たり前のことを書いているのですが、最近になって改めて重要なことだと気付かされています。

CookpadTV のように複数の新規事業を立ち上げたり、立ち上げた事業を成長させようとしてるフェーズの企業の開発では、開発するものの仕様・タイミング・優先順位が重要になります。
事業計画に沿って新しいチャレンジをするためにはいつまでにどういう検証・機能が出来ている必要があるかを把握していないと、その時に必要なシステムや仕組みが何なのか、将来発生するリスクや開発は何なのかを判断することができないはずです。
この判断を大きく間違えてしまうと、せっかく開発したサービスを使うタイミングがなかったり、マネタイズの機会損失をして事業を撤退しなければいけなくなったりします。

CookpadTV の開発スタイルでは、エンジニアが要件・仕様整理することが大小問わずあるので、上で述べたような事業の状況に合わせた判断が必要になるのですが、これを開発メンバー全員が行うのは無理があります。マネージャーとしては、いろんな情報をキャッチアップしておいて、できるだけこの判断がいい感じにできるように心がけています。
例えば、ユーザー向けの新機能は Live 配信の企画に沿って運用できるものになっているのかを配信ディレクターの様子から伺ったり、季節のイベントに合わせた大型企画を最大限成功させるためにできる工夫がないかを探ったり、トライアルに間に合わせるために作った暫定的なシステムを用意した時に発生しうるイレギュラー対応を先回りして仕組み化しておくべきものは無いかを探ったりしています。

こういう情報は、隣の席で何気なく話されていることから分かるものもあったりするので、一見無駄かもしれないようなことでも隙があれば積極的に関わるようにしていて、オフィスでオープンに行われている打ち合わせに聞き耳を立てたり、なんとなく雑談していることから読み取れることはないかを意識しています。

この仕事は誰のどういう成長・成果に繋がるかを考える

プロジェクトがあったとして、それを誰がどのように取り組むのかをアサインする権限を私は持っています。単純にチームの最高速度が出せるように開発リソースをアサインする場合もありますが、期初にチームの目標を設定するときに、その人の Will・Can・Must を整理しているので、基本的にはそこに合うように計画を立てます。

例えば、「システム全体の設計するスキルを高める」という Will を持った人がいれば、その1年の山場となりそうなプロジェクトを任せる前に、早めに小さいプロジェクトから素振りをしてもらったり、「プロジェクトの管理をする」という Can を身につけて欲しい人がいれば、他部署の打ち合わせに同席してもらったりと、単純に他の人がやったほうが早いものであってもチームの成長・成果に合わせて仕事を設計しています。

ちょっと話は逸れますが、やる気があってモチベーションが高い人が一番成長するというのを実感しているので、「どうしてもこの仕事やりたいけど、今着手しているものが終わってない...」みたいな状況の人がいたとして、その仕事をやったほうが成長に繋がると感じた場合は、今着手しているものをなんとか整理して仕事を引き剥がしたりもします。

まぁこのへんの判断を助けてあげるのがマネージャーの仕事かなーと思ってます。

最後は自分がなんとかするという覚悟をする

これは結構大事だと思ってます。自分ができることは限られていますが、やれる範囲のことはなんとかするし、範囲外のことはどうしたら解決できるかを考えます。
Live 配信中に現場でトラブルが起きても、全然知らないシステムで大障害が起きても、自分の守備範囲外のスキルを持ったメンバーが辞めても、最後の砦としてやっていく気持ちが必要です。（でも実際は、真の最後の砦が後ろに何個かありますw）
そういう気持ちで取り組んでいると自然と守備範囲が広がりますし、自分の成長にも繋がるし、チーム的にも強くなっていくはずです。

ちょっと話は逸れますが、逆にこれは課題になってると感じることもあって、自分の能力の上限がチームの能力の上限になってしまいます。自分が見えていることをうまく伝えつつ、この課題が解消されるように試行錯誤しています。言いたいことは「マイクロマネジメントは悪か？よりよい組織をつくるためのマネジメント形態についての考察」という同僚の新井(@SpicyCoffee66)さんの記事にまとまってるので見てみてください。

キャリアについて

「キャリアについて」とかいう、また釣り針の大きい話をしてしまう割には面白いことは話せないのですが、「どう作る」のかではなく「何を作る」のかが重要だと思っています。
何を今更当たり前のことを言ってるんだ、と思われる方も多いかと思うのですが「技術は目的ではなく手段」というのを CookpadTV の開発を通して痛感していて、そういう志向のエンジニアは、マネージャーというキャリアは非常に財産になるんじゃないかと思っています。

一般的に、マネージャーになるとコードを書く時間がなくなってしまう、とか、技術力のないマネージャーは使えない、とか言われるのでとてもネガティブなイメージがあるかと思います。（し、それが間違ってるとも思わないです。）
実際のところ一般的な開発業務と比較すると、プロジェクトの進行管理、障害・サポート対応、他の事業部のキャッチアップ、メンバーの成長の設計、採用活動などの業務の優先順位が上がってしまうので、システムの設計や開発から離れがちになってしまうのですが、既存システムの設計や実装に携わらない期間が長くなったり、最新技術のキャッチアップを怠ったりすると、すごいスピードで置いて行かれている感覚があります。
なので、バランスをとりながら仕事をする必要があります。

幸いにも、私のチームは同じメンバーで長く働けていて、マネジメントコストが高くないことや、CookpadTV の方針である、やらないことを潔く決めてチャレンジすることに重きを置いていることや、各個人の強みを活かしてチャレンジすることが推奨されていることなどのお陰で、私自信も継続的に開発に関わることができています。
2021年に私が作った pull request は 489 件で、1日1回は少なくとも何かしらコードを書くことを心がけていました。

かなりタフネスが求められる仕事ではありますし、がっつり設計したり実装したりする時間はとりづらいのですが、「何か」をチームで生み出す筋肉が鍛えられているのを実感できていて、その経験は普遍的なものになり得ると感じているので頑張ってます。
クックパッドにはこういうタイプのエンジニアもいるんですよ、というのが少しでも伝われば幸いです。
まぁ嫌になったらまたメンバーに戻る選択肢も無いわけではないですし、実際クックパッドにはそういうキャリアを歩いて活躍している人が何人かいます。