はじめに

こんにちは！エンジニアリングマネージャーの小田中（@dora_e_m）です。この記事はカケハシ Advent Calendar 2023 の 12日目の記事になります。 https://adventar.org/calendars/8587

今年はPart2もあるのでぜひそちらもご覧ください！ https://adventar.org/calendars/8728

この記事ではタイトルのとおり、新規事業のプロダクト開発チームにおいて新任のエンジニアリングマネージャー（以下、EM）がどのような役割を担うのか、私自身の実体験をもとに紐解いていきます。

前提: カケハシに存在するEM、開発ディレクターというロール

カケハシにはEMに加え、開発ディレクターというロールがあります。カケハシでは基本的にどのチームでもスクラムを採用しており、開発ディレクターはスクラムマスターとイコールで考えていただくとイメージしやすいかと思います。(こういうロールがあるっていうことは、スクラムマスターという役割が大切にされているってことですね！)

本稿を執筆する小田中はEMと開発ディレクターを兼務しています。そして、EMと開発ディレクターはまったく別の役割というわけではなく、ある種グラデーションのような性質を持ちます。なのでここで扱う内容にはカケハシ内部では開発ディレクターが担う役割も含みますが、あえて区別せずに取り扱います。EMと開発ディレクターの違いや、開発ディレクターにフォーカスした話は別の機会でお伝えできたらと思います。

新規事業プロダクト開発チームの体制

2023年12月現在、私が所属するチームは以下のメンバーで構成されています。

プロダクトマネージャー3名
エンジニア4名
EM1名（私）

私達が携わっているのは立ち上げ期のプロダクトです。 PMF(Product Market Fit)を目指し小さく仮説検証サイクルを回すフェーズであり、要求には不確実性が伴います。開発面でも実現可能性から模索することが必要なケースが多くあります。どのような設計が適切か、その機能を実現するためのデータはどこからとってくるのか、どれくらいのリクエスト数まで耐えられるのか・・・。このように、技術の面でも不確実性が存在しています。ステイシーマトリクスでいうと「複雑」の領域が、私達を取り巻く環境です。

PdMの役割

PdMはプロダクトをPMFへと導くため、仮説検証の前提となる仮説を立て適切な優先順位にアップデートし続けることが求められます。そのためにPdMが参照するデータは2つ。

定量データ：Datadogを用いて顧客が実際に使った軌跡をログ解析します。
定性データ：社内の元薬剤師や薬局への顧客訪問において得られたヒアリング結果から課題を洗い出します。

定量データと定性データを駆使しながら、時にはもともとあった仮説を覆しながら仮説を更新します。仮説の更新を通して要求の不確実性を下げていくのがPdMの役割です。

エンジニアの役割

エンジニアは仮説検証のための機能開発をタイムリーに行うこと、そして仮説検証サイクルを高速に回し続けるためにコードベースをクリーンに保ち続けることが責務になります。また、今現在取り組んでいる要求だけではなくプロダクトがPMFを実現しスケールしていくことを想定した、先回りした基盤づくりも求められます。

EMの役割

PdMが要求の不確実性を、エンジニアが技術の不確実性をそれぞれ下げる責務があるならば、EMは一体何をするべきなのでしょうか。ざっくりいうと「チームのパフォーマンスを最大化すること」だと考えます。では、それを実現するためにはEMはどう行動すればよいのでしょう。

EMが取るべき行動は2つ。コミットメントとフォーカスを生むこと、そしてチームと組織の架け橋になりバリューを最大化することです。

私たちのチームはスクラムを採用し、イテレーティブに開発を進めていきます。PdMがプロダクトオーナー（PO）をつとめ、私はスクラムマスター(SM)を担当しています。次項では、私がEM・SMの帽子を被りながらどのようにチームに働きかけているかを紹介します。

コミットメントとフォーカスを生む

できるだけ多くのタスクを積みたい欲と戦う

新規事業開発では、どうしてもやりたいことが溢れがちです。幸い、私達のチームのPdMはひとつづつ小さく進めることの意義に対して理解があるため、大量のユーザーストーリーを「どれも全部大事だよ！」と押し付けてくることはありません。優先順位を見定め、そのときに一番大切なストーリーに絞って開発を進めることができています。
しかし、PMFを目指してできるだけ早く開発を進めたいという気持ちから、可能な限りタスクを積みたいという心理状態がエンジニアからも発生します。この「できるだけ多くのタスクをこなす」という状態になっているとチームで採用しているスクラムは形式的なものになっていきます。スプリントのゴールがぼやけ、学習効果が薄れてしまいます。
私がジョインしたタイミングではそのような「できるだけ多くのタスクをこなす」状況になっていたのですが、今はスプリントゴールをある程度明確に定め、なるべくWIPも制限しながら開発するようにチームのスタンスが変化してきました。そのような変化を促した原動力がふりかえりを起点とした学習サイクルです。

効果的な学習サイクルを設計する

スプリントでの経験から学び成長するために重要な役割を果たすのが「ふりかえり」です。このチームでは意識的に多くのふりかえり手法を試しています。

10月から12月の間に試したふりかえり手法

Starfish
Fun Done Learn
Celebration Grids
学習サイクル
思ってたんと違う（オリジナル手法）
フォースフィールドアナリシス
実験・練習
YOW
MADE IN HEAVEN（オリジナル手法）
ハッピーメモリーズ（オリジナル手法）
未来へのステップ（オリジナル手法）
感謝の輪
信号機
WIN LEARN TRY

ふりかえり手法はランダムに選択しているわけではなく、そのスプリントで引き出したい学びにフォーカスして選んでいます。たとえば新しいユーザーストーリーに着手するタイミングではCelebration Gridsで実験から得られる学びにフォーカスしたり、チームとして区切りを迎えるタイミングではスプリント期間中の出来事を思い出すワーク・アクションを考えるワーク・互いに感謝するワークを組み合わせて実施したりしています。なぜ組み合わせているかというと、ふりかえり手法にはそれぞれ得意分野があるからです。

一例として、Fun/Done/Learnはチームの状態を明らかにすることに適していますが、アイデアの創出まではカバーしていません。実験・練習はアクションを生み出しますが、そのアクションにたどり着く過程については言及しない手法です。手法の得意分野同士を組み合わせることでチームの状況にフィットした効果的なふりかえりが可能になります。

ワーキングアグリーメントがアップデートされたり、それに伴ってチームの行動が変わっていったりと、いまのところ効果的にふりかえりを実施することができている手応えがあります。一方で課題もあり、複数の手法を組み合わせるとどうしても時間が伸びがちです。チームの学びを最大化しながらタイムボックスを守り、スプリント全体の時間をうまく使うためにもっとスキルアップしたいな〜と思っています。

ワーキングアグリーメント

私たちのチームでは、ふりかえりで得られた学びをワーキングアグリーメントの形で言語化することを積極的に行っています。自分たちのチームの約束事として明文化することで本気でそれに取り組むことになり、結果的にふりかえりの学びを効果的に自分たちに取り込むことにつながっています。

学びから生まれたワーキングアグリーメントは作成した時点で全員の腹に落ちているので浸透度が高く、普段の会話の中でも当たり前のように登場します。

チームと組織の架け橋になりバリューを最大化する

ここまでの話はチームの短期的な活動にフォーカスしたものでした。ここからはチームの中長期的な活動、組織と接続した領域での話になります。

ロードマップを意識した体制検討と採用計画立案

新規事業においては、新規プロダクトを軸に事業をスケールさせていきたいと考えています。その中で、新規プロダクトはまだまだ機能を充実させたい。周辺領域・既存プロダクトの連携など、このチームで取り組みたいテーマは盛りだくさん。どっちもやらなきゃあならないのがEMのつらいところですが、それを実現するために鍵を握っているのが体制の拡充、そしてそれを実現するための採用です。中長期的に求められるアウトカムを見据え、そのアウトカムを実現するための体制を描いていきます。

このときに気をつけているのが、いざアクセルを踏んでいくぞ、というときにはチームとして組成されている状態になっているよう、ロードマップから逆算して計画することです。ブルックスの法則にあるように、土壇場になって人を追加するとかえってチームのパフォーマンスを損ねることになります。チームが機能するようになるための十分な期間がとれるかが成功の鍵を握っています。

そのためにPdMやVPoEと密に連携しながら計画を共有し、フィードバックをもらいながらブラッシュアップし続けています。また、所属メンバーを起点としたリファラル採用のアプローチ、ダイレクトリクルーティング（いわゆるスカウト）の活用、カジュアル面談の実施など多方面から採用活動にアプローチしています。

会社としての全体最適を意識した意思決定

EMはチームのパフォーマンスを最大化することに責務を負います。そしてそのパフォーマンスを発揮する対象はチームに閉じません。場合によってはチームがフォーカスするプロダクト・サービスの枠を超え全社最適の観点で貢献します。

11月に私達が実施した他チーム（以降、チームKとします）とのコラボレーションについて紹介します。チームKが開発するプロダクトに対し、緊急度の高い要望が発生しました。けれどチームKは他でも優先度の高い案件を抱えており、リソースが逼迫している状況でした。

当初、このチームにメンバーを一人ヘルプで出してくれないかという相談がきていました。それに対し、メンバーからの提案により「一人ではなくチーム全員で手伝いにいく」という選択をとりました。

一人でヘルプにいくとどうしても属人化してしまう。ヘルプ期間が終わってからも問い合わせなどで断続的に時間がとられる。そして、ヘルプに行っている期間はその人はチームにいないわけですから、その間チームに蓄積されるナレッジから切り離されてしまいます。

この意思決定に基づいた進め方を実現するためには各所と調整が必要になりました。

まず、自チームのPdMとは、ヘルプ期間中は自チームのプロダクトのインクリメントが出なくなるが全体最適の観点で問題ないか相談しました。KチームのPdMとは、プロダクトバックログの扱いについて調整しました。チームとして仕事を受け取るのでプロダクトバックログアイテムごとこちらのチームで引き取ってよいか、というのが相談のポイントでした。仕事のやり方まで他のチームに合わせるとなるとその学習コストがかかってしまうため譲れないポイントだったのですが、快くOKを出してくれてホッとしました。

続いて、KチームのEM、開発ディレクターと進め方について相談しました。こちらのチームで引き取るので他のタスクとの優先順位の判断などもこちらでやっていきたいと伝えたところ、こちらも快諾してくれました。やさしい！

このヘルプ業務を成功させるためにもっとも重要な役割を果たすのが、我らがチームメンバー。エンジニアたちです。彼らがいちばんパフォーマンスを出せるやり方についてヒアリングし、それをもとに業務を調整していきました。たとえば、QAやリリース作業などはこちらのチームで巻き取れない仕事でした。こういった仕事をKチームにお願いしたり、適切なフィードバックが得られるようスプリントレビューにKチームのPdMを招聘したりといった後方支援に奔走していました。

結果的に期待されたスケジュール通りにリリースすることができ、チームとしてのヘルプ業務を全うすることができました。また、チームで取り組んだことで知識が暗黙知に落ちることを防ぎ、引き継ぎを念頭にドキュメントを充実させることにも成功しました。結果、一ヶ月間のヘルプ期間を経てキレイに引き継ぐことができ、ヘルプ案件にありがちな「ずっとボールを持ち続ける」状態に陥ることがありませんでした。

自分の過去の経験でも有数の「うまくいった」ヘルプだったのですが、何がよかったのかをふりかえってみると、以下がポイントだったのかなと思います。

個人ではなくチームで取り組み属人化を防いだ
ナレッジのドキュメント化を積極的に行った
適宜Kチームと同期をとっていたのでスムーズに知識移譲が行われた
早い段階から責任範囲、引き継ぎタイミングを明確化できていた
明示的な引き継ぎの時間と合同ふりかえりの時間を設けたため、オーナーシップの譲渡が明確になった

他のチームとコラボレーションするということは今後も積極的にやっていきたいので、この学びを得られたのは大きな収穫でした。

無知の知を自覚し、変幻自在であれ

無知の知、変幻自在。両方ともカケハシが掲げるバリューです。今回、新規事業におけるEMの文脈で改めてこの2つのバリューが大切だと感じたのでピックアップします。

ここまで、新規事業プロダクト開発チームのEMに期待されていること、やるべきことを実体験を交えながら紹介していきました。その時置かれた状況によってフォーカスをチームから組織に変えたり、場合によっては他のチームの領分にまで越境したりと、EMには変幻自在な動き方が期待されている、ということが伝われば幸いです。

そしてもうひとつ大切なのが、無知の知。自分には知らない領分があると自覚し、アップデートし続けていくことです。

ここからは役割についての説明ではなく、私の個人的な経験、考え方、未来を見据えた展望の話です。もしよかったらこちらも読んでいただけると嬉しいです。

EMは変化を起こすからこそ信頼貯金が大切

10月からカケハシにジョインし、ジョインしたタイミングからエンジニアリングマネージャーを担うことになりました。これはけっこうチャレンジングなことで、マネージャー職にとって大切な「信頼貯金」がゼロの状態からスタートすることを意味しています。

長く在籍している組織であれば実績がある。築き上げた人間関係がある。そういった信頼貯金があるからこそマネージャーはチームの垣根を超え全体最適を見据えた動きをしたりドラスティックな変化を起こしたりしていけるのです。

じゃあ、それがない状態でどうやってEMとして活動するのか？これはもう、ひとつひとつ地道に成果を上げていくしかありません。

本稿で紹介したWIP制限やふりかえりの実施は、チームの信頼を築いていってくれました。また、1on1を通して相互理解を深め、個人個人の課題と共に向き合うという姿勢も自分がチームに溶け込んでいくために重要な役割を果たしてくれました。

チームの外側からのまなざしでいうと、さきほど紹介したKチームのヘルプなどは信頼貯金を貯める機会になったのかな、と思います。

ここで重要なのは「信頼貯金を貯めるぞ！」という利害を意識した動きではなく、真に貢献しようという利他的なモチベーションで動くことです。信頼してもらいたいという気持ちが先立つと矢印が自分に向き、行動が歪む。目の前にいるメンバーの困りごとを解決したい、組織の全体最適に貢献したい、そういった姿勢で臨むことが、結果的に信頼を育むと私は信じています。