人を頼るリーダーシップ - チーム規模拡大で学んだ「任せる」ことの大切さ

お疲れ様です！ ADWAYS DEEEでエンジニアリングマネージャー（EM）をやっている、いとうです。 EMになってから1年が経ち、アドウェイズ3年生になりました。

EMに転身したときは、どう振る舞うのがよいかについて不安に感じていたことをよく憶えています。そこから一年間で色々考え、価値観をアップデートしていきました。今回はその中の1つについてお話できればと思います。

はじめに

突然ですが、皆さんは「人を頼る」ことをどのように思われるでしょうか？

「メンバーが気持ちよく働けるように、開発以外のタスクは自分がやろう」
「困ったらマネージャーがすべてやらなきゃいけない」
「開発以外のタスクを降ったらメンバーが嫌がるんじゃないか」

自分は以前、マネージャーとして・チームリーダーとしてこんなことを考えていました。しかし、色んなメンバーとチームを組み、色んなプロジェクトを経て、「人を頼る」ことの重要性を痛感するようになりました。

今回は、私がどのような背景で「人を頼る」ことの重要性に気づいたのか、今はどのように「人を頼るリーダーシップ」を実践しているかについてご紹介したいと思います。リーダーとして、EMとしてどのような立ちふるまいをしたら良いかについてに困っている方・迷っている方の参考になれば嬉しいです。

時系列で振り返る「人を頼る」ようになった理由

チーム編成を変えるたびに学びを得てきたので、その中で印象に残った出来事とそこで考えたことについてご紹介していきます！

2024年7~9月：エンジニアのみのチームでプロダクト開発をしていた時代

EMに転身する前（2024年6月まで）私はエンジニア4人の小規模チームで技術改善業務を担当していました。

この頃の私は、メンバーが気持ちよく働けるように、開発以外のタスクは自分がやろうと考えていました。設計でさえ、たくましい先輩が多くいらっしゃったのにも関わらず、スピード感を早めるためにと自分がまず土台を作り、壁打ちなどをしながらアップデートをする方針をとっていました。その上で、チーム外との調整など開発と関係のないことは「自分がやる」スタイルで回していました。

7月にEMになり、チームメンバーはそのまま技術改善からプロダクト開発へプロジェクト・役割を変え、ビジネス側の領域への関心が増加しました。そのため、ビジネス側との調整など、開発以外の関心事は広がっていき、以下の考え方がさらに加速していきました。 - 「メンバーが気持ちよく働けるように、開発以外のタスクは自分がやろう」 - 「困ったらマネージャーがすべてやらなきゃいけない」 - 「開発以外のタスクを降ったらメンバーが嫌がるんじゃないか」

そのなかでもなんとかプロジェクトを回すことができていました。「キャパシティは超えそうだけど、まだ大丈夫。なんとかやっていこう、自分ならできる。」そう言い聞かせながら。

2024年10月〜2025年1月：プロダクトマネージャー・デザイナーのジョイン

10月になり別プロジェクトへの移行に際して、プロダクトマネージャー（PdM）とデザイナーがチームにジョインしました。 PdM・デザイナーと一緒に働くのは、自分にとってはこれが初めてでした。ジョインに際し、これ以上自分がやったらキャパシティオーバーをしそうと思った私は、最初にPdMと自分でのタスク・役割の明確化を分からないなりにやってみました。これによりPdMにはビジネス側との調整を、自分はプロジェクトを円滑に回す役割があることを再認識しました。同時に、プロダクトマネジメントやデザインはPdM・デザイナーにそれぞれおまかせすることにしました。

しかし、プロダクトマネジメントもデザインも自分でできる必要があると思っていた私は、時間が経過していくにつれて、PdMがいるにも関わらずビジネス側の領域にも手を出し始めていました。スピード感を高めるため。エンジニア側の動きをスムーズにするため。越境していくため。いろいろな理由をつけながらやってやっていました。

そこで、至極当然の失敗をしました。

失敗ケース1：キャパシティオーバー

開発・プロジェクトマネジメント・プロダクトマネジメントのキャパシティを 4:5:1 にしていた私は、時間が経過するにつれ、開発とプロダクトマネジメントにも手を広げたほうがいいと思っていました。開発タスク・プロダクトマネジメントタスクをこのキャパシティ状態にさらに追加したらどうなるか。また、忘れてはいけませんが、開発組織を作る上でチーム業務とは別にEM業務もあります。そうして自分のキャパシティ状態を 5:5:2 + α くらいの比率にして動き、あることに気づきます。

あれ、プロジェクトちゃんとまわせてる？

当然うまく回せているはずもなく、プロジェクトの計画は伸びてしまいました。プロジェクトマネジメントの相対的な比重が落ちているので、当然のことではあります。

このことを機に、こちらのことを考えました。 - 自分はプロジェクトマネジメントに比重を置こう - キャパオーバーはメンバーにも悪い影響を与えるからやめよう

そこから、ドキュメント作成など開発関連のタスクを他のエンジニアに、期待値のすり合わせをした上で移譲しました。これにより、キャパオーバーは解消できました。

2025年2〜3月：合計11人の大きいチーム編成

今度はさらにメンバーをそれぞれの役割で増やし、10人を超えるチームを作りました。キャパオーバーについて学んでいた私は、今度は期待値の調整をちゃんと行いました。チームが大きくなると、関心事が大きくなります。

このチームで、自分は2つの失敗をしました。

失敗ケース1.5：やっぱりキャパシティオーバー

自分はプロジェクトマネジメントに比重を置こう

キャパオーバーはメンバーにも悪い影響を与えるからやめよう

実はこの考え方では、うまくいきませんでした。キャパシティを超えず、プロジェクトマネジメントに比重が大きくできていればOKと思っていた私は、常に100%のキャパシティで余裕を作らず動いていました。

しかしチームが異なれば動き方も異なるもの。さらに、EMにはいろいろなタスクが降りかかります。

余裕がなく、キャパオーバーでも多少はなんとかできることを知っている私は、またキャパオーバーを起こしました。その結果として、必要な調整が遅延してしまい、自分がプロジェクトのボトルネックとなってしまいました。

今回のキャパオーバーで、「自分はバッファを常に作っておく」ことの必要性を実感しました。不確実性の高いことをしていく・不確実性の高い時代を生きる上で、常に余裕を空けておくことにより、柔軟に比重を変えたり、不確実性に対応できることを学びました。

失敗ケース2：PdMに任せるべきものを見誤った

ADWAYS DEEEでは、本質的な価値に向き合うためにユーザーストーリーを書いた上で開発をしています。詳しくはこちらを参照してください！

https://blog.engineer.adways.net/entry/2024/06/21/120000

今回は早くプロジェクトを回すために、プロジェクトマネージャーである自分がユーザーストーリーを作成しました。ですがこれは、様々な視点を持っているPdMが書くもの。このことについてチームのメンバーからフィードバックをいただき、ハッとしました。

越境をするにも、やり方というものがあります。役割に大きく紐づくタスクを無為にとってきて自分でやるのは良い越境ではないことに気づき、こちらの考え方を知ることができました。 - 役割に大きく紐づくタスクを明確にする - そのタスクを無為に巻き取らない

2025年4〜5月：チームの分離

プロジェクトを分けるため、いままでのチームを2つに分離しました。もとのチームではプロジェクトマネジメントをしていたのは自分一人だけだったので、分けるにあたり自分がいないチームのメンバーの方にタスクを移譲しました。この移譲の結果うまくチームを分離できたので、人を頼っていいんだなと再認識できました。

自分が入った新しいチームでもこの経験を活かして、どんどん人を頼るようにしていきました。その結果として、もともと自分がチームの会話の中心にいましたが、チームメンバー間の連携をどんどん起こすことができました。同時に、自分が目指すチームはこのように「自己組織化したメンバーが同じ方向を向いたチーム」なんだなと再確認できました。

自分のリソース比については、開発関連、プロジェクトマネジメント、プロダクトマネジメント、バッファで 3:5:1:1 で、柔軟な動きも取れるようになっていました。

「人を頼るリーダーシップ」の一例

以上の背景から考えた、自分が実践している「人を頼るリーダーシップ」についてご紹介します！

スーパーマンである必要はない

EMConfでよく聞いた「エンジニアリングマネジメントとは、価値を実現するためになんとかすること」というフェーズは、自分はとても気に入っていて行動指針にしています。かつ、「なんとかする」というのは「自分だけでなんとかする」のではなく、ときには専門家を呼んだりしてチームの課題に対処することだと聞いたときはハッとしました。自分がスーパーマンになるべきで、そのために自分がなんとかできなければいけないと思っていたからです。

スーパーマンを目指さず、専門家を呼んだりとなんとかするために人を頼っていく。
もちろん自分ができる範囲は広いほうが良いが、チームの目的を阻害してまでやることではない。やるならバッファの中で少しずつできる領域を広げていく。
その前提として役割を遂行する。役割を遂行した上で初めて越境が生まれる。

これら3つは、自分が人を頼るリーダーシップを実現していく上での指針としています。

役割を明確にしつつ、同じ方向を向くように

PdM・デザイナー・エンジニア・EMにはそれぞれ役割があります。また、この役割はメンバーによって、チームによって異なります。これらの役割を明確化することで、以下のような点がはっきりします。 - メンバーそれぞれに何を頼ってよいか・頼るべきか - 逆に自分に何を頼って欲しいか（ギブ・アンド・テイク） - タスクの所在（どの役割の人がそのタスクをすべきか）

「人を頼るリーダーシップ」を実現する上で、ロール間・ロール内の役割・期待値の明確化は土台になります。

一方で、役割を明確化するだけでは、メンバーが違う目標に向かって動いてしまう可能性があります。メンバーの存在意義も明確にするため、チーム・メンバーの目標を明確化することも大切だと思い、チームMVV・OKRの形で実践するようにしています。