この記事はSmartHR - Qiita Advent Calendar 2025 - Qiita シリーズ2の3日目です。
ここに書かれている文章は100%オーガニック、人間の手でタイピングされたものです。
まえおき
この文章の前提として、私はエンジニア組織のセカンドラインマネージャーとしての立場からエントリを書いています。 プレイングマネージャーなど、別の立場から見ると違う意見や感じ方があるかもしれませんので、その点を留意してください。
正確を期すため所属会社であるSmartHRのレポートラインの資料で示すと、このDirectorというポジションでの観点となります。
https://www.figma.com/board/HFNrUtz5Bf1c52YABCxxrY/SmartHR-%E9%96%8B%E7%99%BA%E7%B5%84%E7%B9%94%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6?node-id=0-1&p=f
開発チームのマネジメントをする
いきなり主題から外れますが、自分自身においても、チームにしても、より良くしていくには理想との差分を考えることが大切です。例えばアーキテクチャやコードの書き方一つとってもそうですね。
「いま困ってないからオッケー」も間違いではないのですが、変化が大きい環境ではより良くしていくためには同じ場所で考え続けるのではなく、何らかのチェックポイントからバックキャストしてどう近づけるか（あるいはこのままで良いか）を考えないと先に進むのが難しいです。
スクラムでいうところの透明性・検査・適応が大切なのはそういったことを実現するために必要なのかなと考えています。
閑話休題
「開発チームをマネジメントする」とはなんでしょう？チームメンバーの採用？プロジェクト進捗？チームの雰囲気？色々な観点があると思います。私がEMを始めた頃はチームのスクラムイベントを通じてチームの雰囲気を見ていることが多かったです。
今振り返って見ると、この頃のチームの接しかたは「問題が起こったら（起こりそうなら）対処する」という側面が強く、チームがより良くなっていくという観点はチーム任せだったように思います。
もちろん、それも大きな間違いではないと思うのですが、マネージャーとしてチームをより良い状態にしていくためには理想との差分を追求していく必要がありました。
そこに気がついてから開発チームの状況や長期的な計画を考える際に重要としているのは、以下のドキュメントに書かれている「ピープルマネジメント」「テクノロジーマネジメント」「プロダクトマネジメント」「プロジェクトマネジメント」のバランスです*1
これは広木さんがEMとして求められるスキルを体系化したものですので、ご存じの方も多いでしょう。このエントリでは、このドキュメントで整理された4つのカテゴリをベースに進めていきます。 エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド #マネジメント - Qiita
こちらのドキュメントはEMとしてこうしたスキルの獲得や強みを把握して意思決定などのマネジメントに活かしていきましょう、という話ではありますが、私はEMとしてのケイパビリティだけではなく、組織・チームなど各単位のケイパビリティとして各カテゴリのバランスを考えることが多いです。
EMにはEMとして求められる時間軸、影響範囲がありますが、チームという単位においても、求められる時間軸、影響範囲があります。もちろん、個人に対しても。 それらの枠の中で適切なケイパビリティが確保されているのか？あるいは支援が必要かを考えながらマネジメントをしているよ、という話です。
チームと4つのケイパビリティのバランス
個人の能力として4つのケイパビリティを全て十分な水準で備えるのは難しいですが、チームとしてケイパビリティをどの程度備えているか？あるいは苦手とする部分はあるか？ということを考えると、チームメンバーのバランスやマネジメント上注視する部分などを整理しやすくなります。
チーム内で長所や短所を理解して補っていけることが理想ではありますが、そうはいっても目の前のタスクがあるのでなかなか難しい面もあるでしょう。そんな時は、EMとしてプレイングマネージャーを通じて（あるいはチーム全体に対して）、仕組みや成長を促すことでバランスを取れるようにしていきます。
例えば、SmartHRのプレイングマネージャーというポジションにおいてピープルマネジメントを除外することはできませんが、プロジェクトマネジメントは別のメンバーに任せる、といった委譲は可能です。あるいは、得意なメンバーに背中を預けながら経験の浅いメンバーに挑戦を促すといったこともやりやすくなると思います。または、チームに人を配属する際には不足している能力を補える人を配属するなどが考えやすくなりますよね。
ケイパビリティと規模
自分自身がプレイングマネージャーだった頃、4つのケイパビリティの話を見ても「ほえ〜〜〜EMって大変なんだな」くらいにしか考えてなかったのですが、自身がEMとなってわかったことは、自分たちで決められる規模に応じて、それぞれの立場に応じたケイパビリティが備えられるようにチーム作りや委譲、支援などをしていくことが重要なんだな、ということです。
EMであれば事業成長に対してプロダクト開発がボトルネックにならないようなアーキテクチャや技術戦略、組織設計などが当たるでしょうし、チームであればロードマップなどのスケジュールに対して価値提供できる機能開発やその機能開発を阻害する課題の発見、解決などが当たるでしょう。 個人であればそのコードが妥当性のあるコードなのか？決定した仕様の懸念点をどこまで考えられか、といったことが当たると思います*2。
これは当時の自分に言いたいことなんですが、どのポジションにおいても、自身の責任範囲におけるテクノロジーマネジメントやプロジェクトマネジメント、プロダクトマネジメント、ピープルマネジメントは必要になるので、「EM大変そう〜〜〜」じゃなくてもっと体系立てた情報を咀嚼しておくべきだったな、と反省しております😓
そうしたことを踏まえて、今は管掌チームと話す際もこれらの4つのケイパビリティをチームとして十分満たせているか？誰かががんばりすぎていないかといったことを気にかけながらコミュニケーションを取っています。
こうした様々な要素をケイパビリティとして整理し、強み・弱みを把握した上でチームや組織の運営をしていけると透明性・検査・適応がやりやすくなり、より良い状態を目指しやすくなると考えていますので、皆様の参考になれば幸いです
なんか久しぶりにブログ書いたら文章のテイストがわかんなくなっちゃったんですが、これもオーガニック文章ならではの迷走ということで許してください。
