スクラムマスターとマネージャーの両方がいる組織を考える - 今までと違うマネジメント

概要

スクラムを導入したときにエンジニアリングマネージャーに期待されることの変化を整理してみようと思います。
あくまで１つの考えであり、ポエムとして書いてみました。

スクラム x エンジニアリング x マネージャー なので、それぞれの領域掛け算で重複する部分の解釈が難しいと思っており、その３つが存在する組織の役割を考えてみます。

また、今回のケースではエンジニアリングマネージャーとスクラムマスターがそれぞれ別の人が専任で存在している前提の組織として、ある意味理想のスクラムの推進組織を想定しています。

この記事は Engineering Manager Advent Calendar 2022の14日目の記事になります。

自己紹介

今の会社はスクラムが当たり前の組織で、各開発チームに専任のスクラムマスターもいる組織で働いています。
経歴：何社かメガベンチャーでエンジニアリングマネージャーとして働いていましたが、今の会社で２年ほど開発ディレクター(スクラムマスター)として働いて、最近エンジニアリングマネージャーという肩書にまた戻ってきました。

スクラムマスターという専任で担当した経験と、今回はスクラムマスターと兼任しない形でエンジニアリングマネージャーという存在というものになったときに、その差分は何なのかを自分なりに整理しました。

スクラムとマネージャーの混ぜるな危険感

スクラムを導入しよう！と考える人はこれからも増えていくと思います。
何せ世の中VUCA。はいはいVUCA。

新しい概念は難しいです。用法用量を守って、それぞれの領域が必要と考えています。
マネージャはスクラムマスターではないですし、POでも無いです。
そしてチームでもない。

スクラムをちゃんと理解するのも難しいですし、マネージャーって何だというのも難しい。
エンジニアがフレームワークやライブラリを学ぶのと同様に、フレームワークやプラクティスがいくつも存在しており、使いこなすには経験が必要ですし、深く磨かなければいつまでも使えるようになることが出来ないため、修練が必要であり。使いこなせる人はマネジメントのスペシャリストと考えています。

スクラムマスターとマネージャーが何が難しいというと、同じマネジメントの領域を扱っているために、今までの考えのままで考えると、よくわからなくなってしまうからです。

まず、今までのままの考えではダメということです。
ではどう変わるのか？
を考えてみます。

スクラムで稀によく出てくるマネージャー不要論

時々話題になります。
ある意味正しく、ある意味間違っていると思っています。

気になる人はググってください。

スクラムが導入されるとマネージャに何が起こったのか？

肩書きが変わらないのに役割が変わった

スクラムで不要になったマネージャは主にプロジェクトマネジメントやタスクマネジメントです。
プロダクトマネージャーは専門職種が定義されるほどに認知と人気は高まっており、エンジニアリングマネージャーの募集も求められています。

つまり専門性が高まったマネジメントは求められているのではないかと考えます。
マネジメントに期待する各領域の水準が１段高まっています。

これまでとスクラムを導入したあとの違い

組織の形の違いのイメージはこうなりました。

これまでの組織の形

ヒエラルキー型の組織で、マネージャの指示の下でメンバーが立ち回ります。
マネージャーはタスクを整理し、差配をして、メンバーは上手くタスクをこなしていく役割です。

スクラムを導入した組織の形

フラット型の組織で、それぞれのメンバーの役割はありますが、上流下流の関係はありません。
メンバーは他の職種の価値観や自らが行うことの価値を理解して、活動をします。
マネージャーは大きな方向性だけ決めます。

マネージャはどこへ行く？

これまでのマネジメント領域全てを推進するマネージャーではなく、これからは専門型マネージャーが求められます。

強いEMや弱いEMという考え方の記事に既にありますが、幾つかのマネジメント領域が存在します。

これまでざっくりとマネジメントと呼んでいましたが、様々な領域のマネジメントがあるため、複数のマネジメント領域を分解して再整理してみようと思います。

そして、この領域別に担当を再設定することが、スクラムとこれからのマネージャーを定義することになるかと思います。

マネジメントの分解

ここではプロダクト開発における、プロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントの３つに加え、エンジニアリング領域のテクノロジーマネジメント、スクラムの領域のタスクマネジメント、プロセスマネジメントに分解してみました。

• プロダクトマネジメント
• プロジェクトマネジメント
• ピープルマネジメント
• テクノロジーマネジメント
• タスクマネジメント
• プロセスマネジメント

この６つの単位でこれまでのマネージャーとスクラム組織のマネージャーを比較してみます

今までのマネージャの役割

• プロダクトマネジメント → プロダクトマネージャー もしくは不在
• プロジェクトマネジメント → マネージャー
• ピープルマネジメント → マネージャー
• テクノロジーマネジメント → エンジニアリングマネージャー もしくは不在
• タスクマネジメント → マネージャー
• プロセスマネジメント → マネージャー もしくは不在

スクラムな組織でのマネージャの役割

• プロダクトマネジメント → プロダクトオーナー
• プロジェクトマネジメント → プロダクトオーナー + チーム
• ピープルマネジメント → マネージャー
• テクノロジーマネジメント → チーム + エンジニアリングマネージャー
• タスクマネジメント → チーム
• プロセスマネジメント → スクラムマスター

スクラムな組織ではスクラムのプロセスの中でチームが自分たちでタスク管理を行いプロジェクトマネジメントを行うことを期待しています。
これは誰か１人がマネジメントをするのではなく、みんなでマネジメントするシェアードマネジメントという考え方です。
スクラムはこの特定の領域のマネジメントを複数人で管理することを推奨されているプロセスと思います。

そのため、スクラムを適応すると今までマネージャーがメイン業務として行っていたプロジェクトマネジメントとタスクマネジメントは担当しなくなりました。

残っている部分でマネージャーが推進するべきはピープルマネジメントとテクノロジーマネジメントになるかと思います。

よくある勘違い

横に逸れますが、よくある勘違いとしてチームメンバーとスクラムマスターの役割を兼任している人が集中してタスクマネジメント(タスク差配やタスク整理)をしてしまうケースがあります。
しかし、本来はタスクマネジメントはチーム全員の役割であり、スクラムマスターはタスクマネジメントの仕組みは作りますが、実際のプロセスではあくまで傍観者かと思っています。

また、スクラム導入前のマネージャーの役割としてタスクマネジメントは主業務になっているため、それを変わらず持ってしまうことがあります。
会議の呼び方は変わったが、実際はスクラム導入が出来ていないパターンです。

スクラムはマネージャと呼ばれることは変わらないですが、期待する役割が変わるパターンです。行動変化を起こしていきたいです。

役割が変わることは難しい

この切り替わりは直ぐに出来る人材が来るわけではないかと思います。
スクラムマスターもエンジニアリングマネージャーもそれぞれのステップがあるかと思います。

スクラムマスター

• 導入期 (初級)：プロセスの一部として参加し、チームを改善する活動を推進を行う
• 成熟期 (上級)：プロセスを設計と導入を行い、チームとプロダクトオーナーの対話を促進する

初級のスクラムマスターはスクラムイベントのファシリテーションなどを自分で行っていて、チームから改善活動を募っている状況。また、プロジェクトマネジメントの一部に深く入り、プロダクトオーナーとチームメンバーの会話が促進するような定例のファシリテーションや会議で利用する資料作成などの具体的な業務がスクラムマスターが行っています。まだチームがプロジェクトマネジメントを受け取るという感覚を掴めていないため、プロジェクトマネジメントをチーム自身で推進するということをコーチングします。

上級のスクラムマスターは具体的なプロダクト開発に関する作業はあまり持たず、プロセスの改善に注力しています。また、開発の基本のプロセスの実行者はチームとプロダクトオーナーのみで回る作業になっている仕組みを構築できており、新しく現れた例外要素や特別なプロセスへの対応、状況変化のプロセス設計などを中心として対応をしています。状況変化によって現れた新しいプロセス課題に対して、フィットするプロセス構築ができていない箇所に対応するプロセス設計と導入を行います。

マネージャー

• 狭い範囲(初級)：開発チームのマイルストーンの締切りタスクを差配してコントロールする
• 広い範囲(上級)：組織全体のビジョンを個人のストーリーとして語り、組織全体に変化を起こす

初級のマネージャは主にプロジェクトマネジメントに注力されており、期限までのタスクにの調整を行っている。個別の実装作業の調整を外部と仲介役として行っている。

上級のマネージャは組織ビジョンを理解し、個人のモチベーションや成長を促す形で１人１人に合わせたポジションと目標を設定できる。期限を区切らない組織づくりについて１人１人のピープルマネジメントを行う。全体感の理解が必要な業務には会議に参加するが、基本的に接続役としてチームで一番くわしいメンバーに目標を設定し、担当を任せる。

ここでの整理では基本的にエンジニアリングマネージャは上級のビジョンを伝えて、１人１人のパフォーマンスを最大化するように個々の不安や課題を解消する道を導く必要があります。
１人１人だけに目を向けてもダメですし、ビジョンだけに目を向けてもダメです。
放おって置くとそれぞれ別の方向に行ってしまう力を同じ方向に向けて力を発揮し、価値に繋げることこそピープルマネジメントの１つの成果です。

個人とビジョンという会社の中で最も遠いものを上手く紐付けるストーリーテラーこそエンジニアリングマネージャーであり、ストーリーを語るための具体策として戦略を作り上げることが求められる１つなのではないかと考えました。

エンジニアリングマネージャのピープルマネジメント

今までのマネージャーはプロジェクトのタスクをこなすことでした。
目標設定もプロジェクトの予定に「従ってXXXをする」といった目標が多かったように思います。
アジャイルになった組織では何かをするという予定は変わる前提です。もう１段上の考え方を持って、目的ベースで目標を建てる必要があります。そのためには価値ベースで考えたり、ビジョンの方向性を確認したりする必要があります。そしてそれをサポートするのがエンジニアリングマネージャーになるかと思います。

スクラムで定義されているのはチームで開発をより良く進める方法であるため、チームそのものの組成や会社としての評価を個人にどう伝えるかという部分は言及されていません。この部分については主にマネージャーの役割として必要になります。
そして、今まではタスクをこなせば評価されていたものが、チームメンバーとコラボレーションをしながら価値を提供する方法を伴奏して考えることこそが役割になるのではと思います。

つまり、上位のビジョンから理解して、個人の文脈に合わせて伝える必要があるというのは

• 会社が目指すビジョンと事業を理解し、どのような価値を実現しようとしているかを理解する
• チームがどのようなものを作り出すことで事業の貢献が出来るかを理解する
• 各個人の得意を適切に配置して力を発揮しやすいコラボレーションの環境を作る
• 各個人の不安を解消し、強みをさらに発揮や成長をするためのマインドセットや視点を作る
  というようにブレイクダウンの手伝いをすることです。

ざっくりまとめると

• 事業戦略の理解
• 開発戦略の構築
• 組織戦略の設計
• 育成戦略の接続
• 力の発揮の伴走

といった戦略レベルの思考を考えられると良いのかなと思いました。
戦略レベルのものは直近の対応というよりは3ヶ月〜1年という未来にどうなっているかという目線で組織やプロダクトをどのように進めるかを検討し、現在のアクションに落とし込むことと考えています。

ピープルマネジメントは個人の方だけを見たモチベーションマネジメントだけではないです。会社のビジョンという大きなものを見て、個々人が走る土台を作った上で動く必要があるかなと思います。
事業やプロダクトと接続する中で、チームビルドとタスクアサインだけでは足りなくなるのかなと思います。

エンジニアリングマネージャのテクノロジーマネジメント

今回はあまり触れられてません。

スクラムマスターとエンジニアリングマネージャーの違いは今回整理しましたが、この話を整理するためにはテックリードという登場人物を増やす必要があるかと思います。

チームや組織の規模に寄ると思いますが、基本的にはテクノロジーマネジメントの主役はテックリードであり、エンジニアリングマネージャーはサポート役だと思っています。

そのためピープルマネジメントにフォーカスしてみました。
他のアドベントカレンダーの日にエンジニアリングマネージャーとテックリードの整理を誰かが書いてくれることを期待します。

おまけ PMBOKのマネジメントでもやってみた

PMBOK 9つの知識エリア

知識エリアごとのツールと技法

• 統合マネジメント
• スコープマネジメント
• タイムマネジメント
• コストマネジメント
• 品質マネジメント
• 人的資源マネジメント
• コミュニケーション・マネジメント
• 調達マネジメント
• リスク・マネジメント

PMBOKのマネジメントをスクラムでしてみたら

• 統合マネジメント → プロダクトオーナー
• スコープマネジメント → プロダクトオーナー
• タイムマネジメント → チーム / プロダクトオーナー
• コストマネジメント → チーム / プロダクトオーナー
• 品質マネジメント → チーム / プロダクトオーナー
• 人的資源マネジメント → エンジニアリングマネージャー
• コミュニケーション・マネジメント → スクラムマスター / エンジニアリングマネージャー
• 調達マネジメント → プロダクトオーナー / エンジニアリングマネージャー
• リスク・マネジメント → プロダクトオーナー / チーム / エンジニアリングマネージャー

こんな感じでしょうか？
あまり綺麗に分かれた印象はないですが、現場に近いものほどチームが担当し、組織そのものを作ったり、組織の外と調整の必要があるときにエンジニアリングマネージャーが担当しているかなと思います。

まとめ

• スクラムを導入してもマネージャは必要
• スクラムを導入するときにはマネージャーは肩書きは変わらないかもしれないが、役割が変わる
• スクラムマスターも難しいし、マネージャーも難しい、役割を変えるのは難しい、頑張ろう
• スクラムでチームはプロジェクトマネジメントとタスクマネジメントを全員で持つ
• ピープルマネジメントは大事だが単純なモチベーションマネジメントだけではない
• テクノロジーマネジメントはチームとテックリードと中心で決めていく

スクラムによってマネジメントを分解してみんなで様々なものをマネジメントすることになりました。
マネージャーは組織の変化を大きく推進しよう！

今の会社は割とスクラムでの開発がしっかり根付いていて、そのような組織の中でのエンジニアリングマネージャとしての自分の今のお気持ちでした。
良ければコメント等のご意見お待ちしております！

また、Twitterなどでもお声掛けも気軽にしてもらえればと思います。