この記事は ZOZO Advent Calendar 2025 シリーズ 7の5日目の記事です。
突然ですが、この夏に私の所属するチーム（計測プラットフォーム開発本部 SRE）ではメンバー構成が変わる節目を迎えました。特に長く在籍したチームリーダーが他のチームへ異動したことはじわじわとチームに影響を及ぼし、チームとして少し不安定な状況となりました。そんな中、チームとしてどうやって良い状態にしていくかを考えていたときに出会った本について簡単に紹介します。
背景を少しだけ
チーム事情はここでは詳しく話しませんが、メンバー構成が変わった後は上位組織のマネージャーがチームリーダーを兼任するようになったこと、既存メンバーは経験がある人（私含め2名） + 若くて優秀な人（1名）という構成ということもあり、権限の不要なリーダーの仕事やチーム運営についてはメンバーみんなで分担しながらやってみることになりました。なお、SREとしての通常業務も引き続き実行しています。
目下の悩みはチーム目標を立てることでした。半期に一度、チーム目標を立ててそれを仕事のベースとしています。今まではチームリーダーが叩きを用意して、メンバーを含めそれについて議論して目標を決めるプロセスでした。しかし、チームリーダーがいなくなることで「叩き」の部分は誰が作るのか、そもそもこのプロセスが適しているのかという問いが出てきました。これに対する答えを出そうにも私はマネジメント経験がこれまであまりなかったため、まずはインプットを試みました。
そこで、参考にした本から得たことや実際にやってみて気づいたことをこの記事で紹介します。注意点としては、これから紹介する本を読んで全てが上手くいきました、ということではなく、現在進行形で読んだことを試しながら模索している状況であることをお伝えしておきます。
アジャイルチームによる目標づくりガイドブック
『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 電子書籍｜翔泳社の本』と同じシリーズ（？）の本で取っ付きやすそうと思い手にしました。この本のタイトルは目標づくりガイドブックとなっていますが、目標を作るのがメインではなく、目標を作った後の話の方がメインかと思うぐらいの構成になっています。この時点で私自身が「目標を作る」ことにフォーカスしていたことに気付きました。目標を作って、これをいかに達成するか、定期的に現在地を見て困難を取り除いたり、軌道修正したりということも含めて考えるべきだし、それはなかなか骨の折れることだなとも同時に思いました。
とはいえ、目標を決めないことには次に進めないのでメンバー間でどうやって決めるか話し合いました。その中で、チームとしてどこに向かっているのか分からないという意見が出ました。これはチームにとって重要なことで、採用するにもどのような人が入ってきてほしいかに関係するし、他のチームとの関係性にも関係してきます。
このため、目標を決める前にチームのミッションを決めることにしました。ミッションは以前作成したものの、なかなか意識する機会が少なくチーム内のメンバー構成も変わったタイミングだったので、思い切って再定義することにしました。
本の第1章に出てくるインセプションデッキを参考にして、「われわれはなぜここにいるのか」という問いに答えてミッションを作成することにしました。以下の記事を参考に準備を進め、各メンバーの考えを共有して自分たちのチームの存在理由を一つの言葉に表すことができました。
最低限ここが固まったことで、上位組織の目標達成に繋がるチーム目標やミッションから派生した取り組むべき目標の作成に取り掛かれました。
目標ができてようやくスタートラインに立てたところで、定期的なふりかえりと期末のふりかえりはやりましょうということに決めました。どうしても期末が迫らないとチーム目標が意識されず、結果として達成に近づけなかったということもあったので、ふりかえりの導入はみな賛成していました。実践に移していきたいと思います。
目標に向かっていけるチームの作り方
この本の興味深いところは、目標を作った後のことに多くのページを割いていることです。いくつかの章に分かれていますがその中でも、学びを活かす、メンバーとの関係性を良くする（互いを知ることも含まれる）というのは以前からできていますが、その上で目標に向き合いゴールに向かって積み上げていくこともチームとして考えながらやっていくことがさらに求められる部分だなと考えています。
また、チーム開発で起き得るシチュエーションに対してこういうことが背景に潜んでいるからこういう考え方やプラクティスをやってみるといいんじゃない？というのがいくつも紹介されています。逆引き的にこんなふりかえり方法があるんだなとか、考え方のフレームワークがあるんだなと参考にできそうです。
一例を挙げると、メンバー間で協働関係を作っていくためのきっかけとして「好き嫌い表」というものが紹介されています。ざっくり説明すると、得意・不得意、好き・嫌いの4象限に各メンバーがタスクを分類し、それぞれの象限に応じて得意を活かしてもらう、今は苦手だけどやってみたいことをサポートを得ながら進める、今すぐ手放して他のメンバーに替わってもらう、というようなアクションに繋げるもののようです。好き嫌い表の作成は機会があったら試してみたいです。
エンジニアリングマネージャーのしごと
チームの変動を受けて、そもそもリーダー、ないしはエンジニアリングマネージャーと呼ばれる役割はどんなものなのかあまり分かってないなと思い『エンジニアリングマネージャーのしごと』を読んでみることにしました。
目次を見るだけでも自分自身の管理から始まり、人間との関わり、評価・採用・解雇、影響力の発揮、プロジェクト管理、社内政治、キャリア開発、など向き合う領域は多岐に渡っています。メンバーとして携わる日々の業務──システム設計、開発、運用、各種自動化・コード化、技術調査、プロジェクト管理（これはやることもあるでしょう）、など比べてみると向き合う領域は重なる部分もありますが、重ならない部分の方が多いのではないかと考えられますね。この中でも印象に残った点を紹介します。
仕事の満足感を得るには日々の活動を4つに分類して考える
この本ではマネジメントの活動を、情報収集、意思決定、ナッジング、ロールモデルという4つの分類を紹介しています。情報収集はアクションの元になり、必ずしも定型的な仕事ではないということです。つまり、偶発的な同僚との会話やチーム外のメンバーとの会話などからも情報が得られるわけです。意思決定はエンジニアリングマネージャーがやることのイメージ通りです。ナッジングとは「議論に対して自身の観点を提供することで、決定に影響を与えること」です。この言葉は初めて聞きましたが、場面としてはイメージできるものです。コードレビューはナッジングの要素を持っていると言えそうですね。ロールモデルは昔からよく言われる「背中で見せる」ということです。
この4つの活動分類を考えるといずれも最終的にはチームの活動やチームメンバー、他のチームに何らかの影響を及ぼすことにつながります。社内で等級が上がるにつれて影響力を高めようとか範囲を広げようという風に言われてあまりピンと来ていませんでしたが、これらの活動と結びつけると考えやすくなると気付きました。
私自身においてはメンバーとして経験を積むにつれて自分でコードを書くことが少なくなり、設計やコードのレビュー、システムや仕組みの設計、何かしらの判断、メンバー間の調整、といった活動が増える印象があります。このため私は仕事の満足感（別の表現に置き換えると、今日も1日仕事頑張ったぞ〜、やりきったぞ〜という感覚）を得にくくなっていました。しかし、この4つの活動分類に近しい活動もしているな、と考えてみた方が日々の達成感・満足感に繋がりヘルシーに働けそうだなと思っています。
委譲にはグラデーションがある
簡単な説明として「タスクの責任を自分から部下へ移動させること」と書かれています。さらに委譲における両極端な例として、タスクを自分で全部やってしまうことと、丸投げが紹介されています。委譲のポイントはタスクの説明責任と実行責任です。以下は本からの引用です。
- タスクに説明責任があるとは、タスクを求められる品質で完了させる責任を持つということです
- タスクに実行責任があるとは、タスクを実際に自分で行うということです
つまり、タスクを自分で全部やる場合は説明責任も実行責任も持ってる状態で、丸投げの場合は説明責任も実行責任も相手に渡した状態ということです。説明責任は持ったままで、実行責任を相手に渡すのが委譲であるという説明がとてもしっくり来ました。タスクの実行を全てお任せできれば完全な委譲になりますし、相手にはやってもらうけど様子をチェックしますとか、自分がやり方を示しながら相手にやってもらうとかのパターンも自分で全て実行するのと完全な委譲の間に位置しています。
タスクをやってもらう相手に応じてどのレベルで委譲するかを意識すると、相手の学習に好影響を与えたりパフォーマンスを十分に発揮してもらえたりする機会になるんだなと思いました。
採用版鉄の三角形
プロジェクトマネジメントにおける3つの制約（いわゆる鉄の三角形）を元に採用におけるジレンマが紹介されています。
- 納期 + 品質 -> コストが低くない
- コスト + 納期 -> 品質が高くない
- 品質 + コスト -> 納期が早くない
ここで言う「納期」は採用までの早さ、「品質」は求める経験（鉄の三角形でいうスコープ）、「コスト」は予算をそれぞれ表します。今まではどのような経験・スキルを持った人を採用したいかにあたる「品質」だけを考える機会はありましたが、「コスト」「納期」に関しては見えないものとして個人的には意識の外にあったように思います。しかし、中途採用に本格的に携わるようになり、3つの制約を実感し始めました。一定期間で採用したい、このくらいの経験を求めたい、予算はこれくらいまで、という条件を全て満たすのは不可能に近く、プロジェクトと同様に優先順位を決めて採用していくしかないんだなあという印象です。本当に難しいですね。
おわりに
今回はチーム運営を考える上で最近出会った2冊の本について紹介しました。チームの運営やマネジメントのようなものは正解が示されている訳でもないし、体系的に学ぶ機会もないので、インプットしてやってみて学んで...の繰り返しでなんとかやってくことになるんだろうなあと思っています。もし、このポストを読んでくれた人でおすすめの本があればXなどで教えていただけると嬉しいです。
そして、まだまだ発展途上のチームではありますが一緒に働いてくれる方を募集しております。もしご興味があれば以下の採用ページへ、またはカジュアル面談も可能ですのでXにてお知らせください。
