こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。

7月はLayerXエンジニアブログを活発にしよう月間ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。

私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。

開発チームとCapabilityの定義

開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームをマネジメントしているので、その視点が強いかもしれません。

また、Capability の定義は「事業成長の原動力となる組織的能力や強み」とします。機能や能力だと、ちょっと言葉足らずな感覚があり、Capabilityという言葉で表現しています。

開発チームに必要な4つのマネジメント

Capabilityの一つ目は4つのマネジメント力です。

エンジニアリングマネージャーに求められるマネジメントとして語られることが多いですが、開発チームでは、以下の4つのマネジメントが機能していることが求められます。

ここでは非常に簡潔に記載しますが、より詳細は「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」がとても詳しくまとまっているので、そちらを参照いただければと思います。

ピープルマネジメント
- メンバーの評価・育成など、一人一人と向き合いモチベーション高く働けているかどうか、チームは目標に向かって多様性を持ちながらも一丸となって取り組める状態になっているかどうかのマネジメントで、エンジニアリングマネージャーがメインで行うことが多い。
テクノロジーマネジメント
- 数年後の事業の状態を見据え、適切な技術選定やアーキテクチャが選べているかどうか、技術の耐用年数や品質、開発速度などのバランスが取れているかのマネジメントで、エンジニアリングマネージャーやテックリードが担うことが多い。また、多様な技術スタックを内包するチームでは、それぞれのテクノロジーごとに分かれることもある。
プロダクトマネジメント
- 顧客や組織の持つ課題を見つけ、「何をつくるのか」、「なぜ作るのか」を決めるマネジメントで、プロダクトや機能の価値検証、より広義ではUI/UXやマーケティングなども内包する。プロダクトマネージャーやエンジニアリングマネージャーが担うことが多い。
プロジェクトマネジメント
- 何かの課題に対して、期限・スコープ・品質・コストといったバランスを決めて、関係者と調整し物事を進め達成まで導くためのマネジメントで、プロジェクトの数ごとに必要なので、チームに対し1:Nで発生しうるマネジメント。エンジニアリングマネージャーやプロダクトマネージャーが担うことも多いが、専任のプロジェクトマネージャーがアサインされることもある。

プロダクトマネジメントとプロジェクトマネジメントにおいては、広義だと被る部分も多いですが、プロダクトマネジメントは「プロダクト・事業全体の提供価値を最大化する活動全般のマネジメント」で、プロジェクトマネジメントは「一定の期間・ゴールを設定して、そこに辿り着くためのマネジメント」という整理をしています。プロジェクトはプロダクト内で完結することもあれば、プロダクトを横断するような大きなプロジェクトもあると思います。

これらのマネジメント全てをエンジニアリングマネージャーが意思決定しているチームもあると思いますが、「マネジメントとはエンジニアリングマネージャーだけのもの？」と聞かれたら、答えはNoです。チーム全体で上記の4つのマネジメントが効いている状態をつくるのはマネージャーの責務ですが、マネージャーが上記の全てを行うとマネージャーの能力がチームの上限値を決めてしまうことになるので、権限移譲できるのであればどんどんチームメンバーに移譲して意思決定してもらう方が良いように思います。本当にマネージャーしかできないのは、ピープルマネジメントのメンバーの評価くらいで、他の箇所に関しては、皆がそれぞれ意思決定できるようなチームの方が体感としては強いと感じています。

これら4つのマネジメントは開発チームに欠かせないCapabilityです。

チームを支えるメンバーの特性

二つ目のCapabilityはメンバーの特性が機能しているチーム力です。以下のような特性を持ったメンバーがチームに揃っていると、互いにいい影響を与え合い、チームとして安定します。

ソルバー（課題解決する人）
- 顧客やチームの課題を、技術力やドメインの知識といった専門性を深掘りして解決する人
ムードメーカー
- ハードな状況でもチームのムードをポジティブな雰囲気に持っていける人。ユーモアのあることを言ったり、「やるしかないでしょ！」、「面白そう！」などポジティブな言葉が多い人
気が利く人
- 何か漏れているものを拾ってくれたり、周囲のことがよく見えていて、困っている人がいると助けたり、チームが上手く回る仕組みを作れる人
目線を上げる人
- 全員の当たり前水準を上げる体現者、ハイパフォーマーだったり、カルチャーの体現者だったり、行動でチームの目線を上げることができる人
ジェネラリスト
- 連携しないと解決できない問題を、人と人を繋げたり、両方の仕事をやったりして、解決まで持って行ける人

これは、こちらの「体制を考えるときに意識していること」をかなり参考にさせていただきつつ、自分の主観も加えて、まとめ直させていただいたものです。

それぞれが不在の時をイメージしてみると、やっぱり何かしらが欠けてしまうように感じます。

ソルバーが不在: チームが複雑な難しい問題に直面したときに突破できない
ムードメーカーが不在: チームが苦しいときに踏ん張りが効かない
気が利く人が不在: やるべきボールが落ちたり、困っている人がそのままにされてチームのパフォーマンスが上がりづらい
目線を上げる人が不在: チームが現状に満足して、一人一人が向上しない
ジェネラリストが不在: チームが直面する多種多様な課題に対応できない

これらの特性は一人が複数の役割を担ってもいいと思いますが、このように多面的な特性がチーム内に揃っていると、互いに相互補完的に作用して、チームが安定するように感じます。全ての特性が揃っていなくてもうまくいくチームもあると思いますが、上手くいっていないチームはどこかが欠けていることがあるかもしれません。

特性というのは定性的でわかりにくいですが、意外と大事なCapabilityだと考えています。

まとめ

日頃、実際に自分が「開発チームのマネージャーとして意識しているチームのCapability 」をご紹介しました。

私自身はこの二つの軸でバランスが大きく崩れないように頼もしいチームメンバーを適宜頼りながら、バランスが崩れてしまったときに自分がその部分を担う動きを意識していることが多いです。チームのフェーズにもよると思いますが、まずはこの辺りを意識してみると比較的汎用的にチームのバランスを取れるかなと思っています。

より深くマネジメントを掘り下げたい場合は、上記にも載せている「体制を考えるときに意識していること」や「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」などを参照していただくと、より多角的、網羅的にマネジメントを学べると思います。

この記事が誰かの助けになれば幸いです。