クックパッドに転職して感じたこと

こんにちは。 レシピサービス開発部でエンジニアを担当しているnaraです。
クックパッドには2022年1月に転職し、早くも3ヶ月が過ぎました。
まだまだ分からないことが多いですが、日々楽しく開発に携わっています。

今回は転職間もない自分が、クックパッドで"実際に働いてみて感じたこと"を紹介したいと思います。
本エントリーが、クックパッドに興味を持っている方の参考になれば幸いです!

働き方が柔軟

突然ですが、私は現在イギリスの大学でComputer Scienceを専攻しています。
日中は仕事を行い、仕事が終われば学業に専念するといったハードな生活を送っており
これらを両立させるには、時間を上手くコントロールする必要があります。

特に、試験期間中は学業に専念したくなるのですが、クックパッドではフルフレックスで働けるので、 業務時間を柔軟に調整できています。
実際、前期の試験期間中は"稼働を減らして、試験に専念する"といった選択を取ることができ、 試験を無理なく乗り越えられました。

このように、柔軟に働き方を調整できるため、自分のような社会人学生も
働きやすい環境だと実感しています。

あらゆる情報がオープン

クックパッドでは、あらゆる情報がオープンに発信されています。
前職では、コミュニケーションが部内に閉じられており、他部署の情報が入ってくることがありませんでした。
そのため、ほぼ全ての情報が公開され、部署関係なく自由に意見が交換されている
クックパッドの文化に最初は驚きました。
現在は、前職のように組織の壁を感じることがほとんどなく、部署間の連携もスムーズに行えていると感じます。

また、コミュニケーションだけでなく、データもオープンにされており
全ての社員がDWHにアクセスして、分析SQLを発行できます。
SQLの実行結果を共有する仕組みも存在しており、デザイナーが分析SQLを共有しているのを見たときは驚愕しました....

ユーザとの距離がとても近い

クックパッドで働いていると、社員同士だけでなくユーザーとの距離も近いと感じます。
特にそう感じる理由として、ユーザーインタビューがほぼ毎週のように実施されており
エンジニア・デザイナー問わずユーザーと触れ合う機会が多いためです。

前職でもユーザーへのインタビューは実施されていましたが、年に数回行われるレベルだったため
仮説を定性的に評価するのが難しいと感じた経験がありました。

この点、クックパッドではユーザーインタビューの仕組みが整っているため
仮説を定性的にも評価した上で、サービス開発を行えています。

ユーザーインタビューに関する取り組みは、以下の記事を読むと面白いと思います。
note.com

業務の域を超えて仕事ができる

個人的に入社して最も驚いたのは、業務の域に制限がないことです。
前職では、部署/職種単位で細かく役割が分かれており、基本的にトップダウンで与えられた役割に従って個々が動いていました。

しかし、クックパッドでは「何をやって欲しいか?」より「何をやりたいか?」が問われ
個人の挑戦したいことをベースに、個々が全体の目標に向かって動いています。

そのため、業務の域を超えて仕事に携わることができ、 実際に自分もエンジニアとしての機能設計・開発に留まらず、 企画やデータ分析まで自分の得意分野を活かしながら、幅広く業務に携われています。

また、エンジニアとして業務の幅も広く
モバイルエンジニアでありながらサーバーサイドの開発に携わったり
複数のサービスの開発に携わって活躍しているメンバーもいます。
(個人的に、一つの領域のみやっているエンジニアの方が少ないのでは?と思っています)

もちろん「複数の業務に携わる」 = 「仕事の範囲が増える」ので、
その分タフネスが要求されますが、主体的にチャレンジするのが好きな人にとって
やりがいのある職場だと感じています。

助け合いの文化である

前述のように、何でもチャレンジできる職場ではあるのですが
クックパッドのシステムは歴史があり、アーキテクチャも複雑です。
また、レシピサービスは複数のマイクロサービスのもと稼働しており
一つの機能を開発するにも、様々なアプリケーションに手を入れる必要性が出てきます。

実際にエンジニアとして開発に携わってみて、設計や実装の難しさを日々感じています。

しかし、クックパッドではSlackで雑に助けを求めると、誰かがすぐに助けてくれたり
チーム外の人がPull Requestのレビューに参加して、アドバイスをくれたりします。
また、ペアプロにも気軽に応じて貰えます。

個人的にはこの助け合いの文化のおかげで、経験のない言語で書かれたアプリケーションでも、 率先して開発にチャレンジする事ができています。

まとめ

本エントリーでは、クックパッドで"実際に働いて感じたこと"を書いてみました。
これまで自分が経験してきた職場と異なり、クックパッドのエンジニアは裁量が大きく
何でもチャレンジできる反面、主体性が求められていると日々感じます。

また、エンジニアとして課題にぶち当たることも多いですが、 職種やチームを超えて助けあう文化があるので、楽しく開発にチャレンジできています!

最後に

クックパッドではエンジニアを絶賛募集しています。
主体的にサービス開発を楽しみたい方には、活躍できる場がたくさんあります!

ぜひ、お気軽にご応募ください!
info.cookpad.com

複数リージョンへの Alexa Skill のデプロイを可能な限り自動化する

こんにちは、ボイスサービス部の ymd (@y_am_a_da) です。今年からは採用にも関わっています。

クックパッドは日本で No.1 のレシピサービス*1ですが、ここ数年は海外展開にも注力しており、世界 74 ヶ国 32 言語で展開しています。

ボイスサービス部は、もともとクックパッドのひとつのプロジェクトとして音声 UI を利用したサービスの開発だったり、デモを作成*2していたのですが、サービスの拡大などにより最近独立した部署として設立されました。 規模が一番大きい Amazon Alexa (以下 Alexa) 向けのサービスは、レシピサービスと比較するとまだまだ小規模ですが現在 9 ヶ国 3 言語で展開をしています。

Alexa 向けのサービスも、このくらいのサービス規模になってくるとコードのデプロイや、サービスのメタデータの更新など、手動でやるのはなかなかに大変な規模になってきています。 この記事では、 Alexa 向けサービスのデプロイを省力化するために、クックパッドで実際に行っている自動化のテクニックについて紹介をさせていただきます。

クックパッドスキルの全体像

Amazon Alexa では、いわゆるモバイルアプリケーションにおけるアプリに相当するものとしてスキルというものがあり、ユーザーはこれを有効化してサービスを利用します。クックパッドでもこのスキルを介してサービスを提供しています。 具体的なデプロイのプロセスのお話をする前に、まずはこのスキルの全体像を紹介し、この記事で紹介するデプロイとはそもそも何をすることなのかを説明します。

以下の画像が、クックパッドスキルの全体像になります。実際にはもう少し複雑なのですが、デプロイの説明をするために必要最小限のリソースを記載しています。

クックパッドスキルの全体像

Alexa は基本的にクラウドベースで稼働しており、 Amazon Echo デバイス上での処理は必要最小限です。

これはスキルに対しても言えることで、例えばユーザーがクックパッドスキルに何かを話しかけた場合、 Amazon Echo が取得した音声が Alexa Skill (この場合はクックパッドスキル) に送信され、 Intent と呼ばれるコマンドに変換されます。 Alexa Skill では、開発者は生の発話を扱い処理するのではなく、もう一段回抽象化された Intent と呼ばれるものを扱います。 Android の開発者には馴染みのある単語かもしれませんが、 Alexa における Intent の概念も非常に近いです。 この Intent などを含んだリクエストを AWS Lambda に送信し、処理の結果を返すことで Amazon Echo に応答の発話をさせることができます。

また、現在 Amazon Echo には液晶付きのデバイスも存在しており、スキル側で応答の発話と一緒に画面に何かを表示させることも可能です。

表示内容は JSON ベースの Amazon Presentation Language (APL) という言語で記述します*3。この記述は AWS Lambda からのレスポンスとして直接渡すこともできるのですが、ファイルとして置いておいてレスポンスではそのファイルの URL だけを渡し、別途デバイス側でアクセスしてインポートさせることもできます。 後者の仕組みは APL Package と呼ばれており、Lambda から返すレスポンスのサイズを節約できるだけでなく (最近まで 24KB 以内に抑える必要があったため切実)、ファイルのキャッシュにより表示も高速化されるため、クックパッドでは積極的に利用しています。

DynamoDB は表記の通り、セッションを越えて永続化したいデータを保存しています。主にいくつかのパーソナライズされた体験を提供するために利用しています。

クックパッドスキルのデプロイ

全体像がわかったところで、 クックパッドスキルでのデプロイはどういうことをやっているのか。について紹介したいと思います。 クックパッドスキルでは大まかに、デプロイによって以下の画像に記載のものを更新しています。

デプロイで更新するリソース

簡単なところからいうと、 AWS Lambda のコードや、 Lambda 関数の設定をアップデートしています。ここでいう設定は、Lambda 関数のランタイムだったり、環境変数だったりを指しています。また、S3 に存在する APL のファイルもアップデートしています。 Alexa Skill の Interaction Model は、発話と Intent のマッピングファイルのことで、開発者はこれを記述することでユーザーのどういった発話をどういった Intent に変換するべきかを定義することができます。 Skill Manifest はやってきたリクエストをどこに送信するのかのエンドポイント (クックパッドスキルでは Lambda の ARN を指定しています) や、スキルストアに公開する紹介文、パーミッション関連などスキルに関する様々なデータになります。

クックパッドスキルのデプロイという行為は、 PR のマージ後に走る CI と、その後にチャットボットを利用したデプロイコマンドの実行により上に述べたリソースを最新のものにアップデートし、必要に応じて審査にサブミットすることを意味します。

ここまでの説明だけを見ると、登場するリソースも少ないですし、ただ CI とチャットボットがあるだけで仕組みも非常に簡単そうに見えますが、 Alexa 固有の仕様によって工夫が必要な部分もいくつかありますのでここで紹介をしていきます。

Lambda 関数の管理について

スキルストアに公開されている Alexa Skill は、1 つのスキルに 2 つの実体が存在します。Live バージョンと Development バージョンです。 Live バージョンは名前の通り一般公開され実際に使用されているバージョンのスキルです。 Development バージョンはこちらも名前の通り開発用に使用するスキルです。

Live バージョンは基本的にデータの一切の変更が不可能です。開発者は Development バージョンのスキルに必要な変更を加え、審査に出し、パスすることで変更を Live バージョンに反映することができます。

以下の図が Development バージョンのスキルを審査に提出した際のフローになります。それぞれのバージョンが持つメタデータやバージョンの変化に対するの理解を簡易にするためにこのような書き方をしておりますが、実際の挙動は明らかではありません。 すなわち、図では Development バージョンのスキルが審査を経て新しい Live バージョンになっていますが、ただ単に Development バージョンのスキルのデータで Live バージョンのスキルを上書きしていることもありえます。

スキルのライフサイクル 上記の図から以下のことが言えます。

  • Development バージョンのスキルは、少なくとも審査提出時には本番環境の Lambda 関数をエンドポイントに設定する必要がある
  • Lambda 関数に互換性の無い変更をする場合、審査に提出する Development バージョンのスキルは Live バージョンと異なる Lambda 関数を利用する必要がある

後者が少し厄介です。もう少し詳しく説明すると、例えば新しい発話への対応や、インタラクションフローの変更をする場合、 Live バージョンで利用している Lambda 関数と互換性がないため、異なるエンドポイントにコードをデプロイをし、それを Development バージョンのエンドポイントとして設定し、審査に提出する必要があります。

こういった仕組みを開発者が簡単に使える形で実現するにはどうすれば良いでしょうか。クックパッドでは以下のことをやっています。

1. 開発用のスキルを別途用意する

Development バージョンのスキルは少なくとも審査提出時には本番環境の Lambda 関数をエンドポイントとして設定する必要があります。うっかり開発環境の Lambda を設定したまま提出すると酷いことになります。

スキルのエンドポイントに開発版 Lambda 関数をセットし審査に出した場合

このエンドポイントの切り替えを自動でよしなにやるようにしても良いのですが、とはいえ事故が怖いので基本的には審査提出前の最終動作確認以外では使わず、開発時には別の開発用スキルを利用するようにしています。

2. Lambda のバージョニングとエイリアスを活用する

これが一番重要です。上に述べている通り、互換性の無い変更を加えたい場合、審査に提出する Development バージョンのスキルの Lambda 関数は Live バージョンのものと別でなければならず、かつ審査後そのまま新たな Live バージョンになるため本番環境のものである必要があります。

互換性の無い Lambda 関数をエンドポイントに設定する場合

これを解決するにあたって、 Lambda 関数のバージョニングやエイリアスを作成する仕組みを利用します。バージョニングは、最新の Lambda 関数のコードや設定をもとにバージョンを発行し、独立した関数として使用できる機能です。エイリアスは、ある Lambda 関数のバージョンに紐づくポインタのようなものを作成出来る機能です。

これを利用することで、例えば互換性の無い変更をしたい場合には新しくエイリアスを発行し、新しいバージョンの関数と紐付け、それを審査に提出するスキルのエンドポイントとすることで安全に本番環境の Lambda 関数を利用できます。

このエイリアスは、コードを管理している GitHub リポジトリの tag から自動的に生成できるようにしています。tag は セマンティックバージョニングに倣ったルールで各 PR ごとに開発者が付与します。 エイリアスは、ここで付与された tag のメジャーバージョンをもとに必要に応じて作成します。 開発者は破壊的な変更をした時にのみメジャーバージョンを上げるだけで自動的に最適なエイリアスにコードがアップロードされるようになっています。

スキルのエンドポイントは、このエイリアスを参照させるようにすることで互換性の無い場合でも安全にそれぞれのコードを参照できるようになっています。

バージョニングとエイリアスを利用して互換性の無い変更を安全にデプロイする

Alexa Skill の管理について

クックパッドでは、展開している国や言語ごとにスキルを別で分けています。複数スキルがあると管理が大変なので、 1 つのスキルで複数リージョンへ展開することも選択肢としてはあったのですが、 1 つにした場合、スキルの審査は展開している全てのリージョンで行われ、その全てでパスをしないと公開できないようなので複数に分けています。 例えば、あるリージョンに向けただけの変更をしただけなのに、全く関係のない別のリージョンで審査に落ちて公開ができない。というのは避けたいですし、そもそも国や時期によって審査のスケジュール感もばらつきが大きいのでこのようにしています。

しかし、複数スキルがあると、 Skill Manifest や Interaction Model の管理が大変なので、リポジトリでファイルベースで管理し、 ask-cli という Alexa Skill 用の CLI ツールを利用して自動で更新出来るようにしています。

具体的には、 Alexa Skill には Skill Package という概念があり、これは Skill Manifest や Interaction Model などスキルを構成する要素をまるごと含んだものなのですが、 ask-cli にはこの単位でスキルをアップデートするコマンドがあるため、それを利用してスキルごとにまとめてアップデート出来るようにしています。

また、 ask-cli には少し前に CI 上からでも簡単に利用できるようになったため、 PR がマージされるごとに CI で Skill Package を更新するようにし、意識しなくても常にそれぞれのスキルが最新の情報に更新されるようにしています。 https://github.com/alexa/ask-cli/blob/develop/docs/concepts/CI-CD.md

ちなみに、スキルは細かく分けていますが、 Lambda のエンドポイントは AWS のリージョンごとにしか分けていないのでいくつかのスキルでは同じ関数を利用しているものもあります。今後展開する国が増えてきたらまた変わるかもしれませんが、少なくとも今はこのエイリアスやバージョニングのおかげで特に不便はしていません。

APL ファイルの管理について

最後は APL ファイルの管理についてです。上で述べたとおり、 APL は URL から別の APL ファイルを取得し、それを利用する仕組み (APL Package) を備えています。クックパッドでも APL Package を利用していくつかのファイルは Amazon S3 上に保管するようにしています。

基本的には、ただ S3 上に APL のファイルを置いておき、その URL を渡せば良いだけなのですが、少しだけ厄介な部分があります。

公式でも説明されているのですが、 APL Package で取得されたファイルは強くキャッシュされるため、ただ新しくファイルを更新してもそれが反映されるまで大変長い時間がかかります。

これを回避する方法はいくつかあるんですが、クックパッドではリージョンや Lambda のバージョンごとにディレクトリを分けるようにし、デプロイする度に新しい APL ファイルを参照させるようにしています。 AWS Lambda は AWS_LAMBDA_FUNCTION_VERSION という環境変数で関数のバージョンを取得することが出来るため、これをもとに APL ファイルの URL を動的に生成させることで、自動的に適切な APL ファイルを指す URL を渡すことができるようになっています。

この仕組みのもう一つのメリットとしては、デプロイした後に問題が発覚して切り戻したい場合でも、 Lambda のバージョンを戻すだけで自動的に APL ファイルも一つ前のバージョンに戻せることです。キャッシュも気にする必要がありません。

リージョンを分けている理由としては、上に述べた通り AWS Lambda はリージョンごとに用意しているため、それに合わせるためです。 言い換えると、 Lambda 関数ごとにディレクトリを用意していて、その中でさらにバージョンごとにディレクトリを用意し、そこに APL ファイルをアップロードしている。という運用になります。

S3 にアップロードする APL ファイルは、リポジトリで全て管理をしており、デプロイのタイミングで AWS S3 にアップロードするようにしています。

まとめ

今回は Alexa 向けのサービスデプロイに関わる色々な仕組みや工夫について紹介をさせていただきました。

今回は紹介しきれませんでしたが、昔と比べるとかなり整備はされてきているものの、まだまだ管理や運用が難しい部分も多く、かつ展開するリージョンが多くなるほど大変になるものもあるため、これらを省力化できるようにすることは非常に意義のあることだと思っています。

まだまだ複数リージョンに展開をしているスキルの数は少なく、言い換えると事例や実践的な情報も少ないため、ここで紹介した内容が皆さまの日々の開発に役立てばと思います。

弊社ではこのように色々な技術スタックを持ったエンジニアが数多く在籍しております。絶賛エンジニア募集しておりますのでご興味ありましたらぜひこちらのサイトをご覧ください。

info.cookpad.com

*1:2021 年 12 月 31 日時点/iOS,Androidアプリ 1日あたりのアクティブユーザー数(2021年10月〜12月 App Annie)

*2:こちらに作成したデモの紹介記事があります https://techlife.cookpad.com/entry/2020/10/26/090000

*3:今回のテーマとは少し異なりますが、クックパッドにおける APL の tips はこちらの記事で他にも色々と紹介しているのでぜひ合わせてご覧ください。 https://techlife.cookpad.com/entry/2021/05/28/110000

CookpadTV の開発スタイルとエンジニアマネージャーの役割

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

CookpadTV?

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

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

AppStore
GooglePlay

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

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

f:id:osadake212:20220330174332p:plain

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

サービス開発部の様子

2021年の開発の様子

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

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

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

f:id:osadake212:20220330174352p:plain f:id:osadake212:20220330174425p:plain

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

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

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

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

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

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

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

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

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

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

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

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

f:id:osadake212:20220330174447p:plain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

キャリアについて

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

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

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

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

さいごに

クックパッドではエンジニアを募集しています。特に、自分の守備範囲を超えて活動するのが苦じゃない人は大活躍できる環境があります。そこに興味がある方はまずカジュアルにお話ししましょう。お待ちしています!
@osadake212
クックパッド株式会社 | クックパッド株式会社 採用サイト

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/