こんにちは、freeeカード Unlimitedでエンジニア兼スクラムマスターをしている mattsunです。この記事は freee Developers Advent Calendar 2022 の4日目です。昨日は ichyさんのとりわけスクラム開発をやるときに立ち向かわなければならない壁の話でした。
freeeカード Unlimitedは、2022年1月26日に正式リリースされた比較的新しいサービスです。開発の裏側については、「【連載 第1回】freeeカード Unlimited の開発の道のり」の連載を参照ください。
はじめに
本記事では、「スクラムマスターとエンジニアリングマネージャーを兼務するということ」について考えます。
この記事から得られること
- 「スクラムマスター」や、「エンジニアリングマネージャー」というロールに期待されることの理解が深まる
- 「似ていること」「違うこと」を整理することで、各ロール個別に考えたときとは異なる視点で理解が深まる
きっかけ
私は、エンジニアリングマネージャーのロールで採用され、今年2022年8月にfreeeに入社しました。アジャイルやスクラム、エンジニア組織づくりなどに興味があります。入社〜これまでは、1エンジニア(兼スクラムマスター)として業務していますが、今後エンジニアリングマネージャー(freeeでいうジャーマネ)のロールも担う予定です。
そんな(スクラムマスターとエンジニアリングマネージャーを兼務予定な)中、 アジャイル界隈で「マネージャーは不要」 というなかなか強い言葉を聞くことがありました。え、もしかして「スクラムしながら、(エンジニアリング)マネージャーするってアンチパターンなの?」とハッとしました。今後2つのロールを兼務するにあたり、どのような心構えでいればよいか整理したくなり、本記事を書くに至りました。
一方で、アジャイル界隈で有名で「認定スクラムマスター研修」なども開催している株式会社アトラクタ の方が 翻訳 執筆 1された、 エンジニアリングマネージャーのしごと という本が出版されました。このことから、「マネージャーは不要」といいつつも「エンジニアリングマネージャー」は大事なロールで、アジャイルやスクラムといった概念とも共通項があったりがあるのでは?と思いました。
というわけで、本記事では、「改めてそれぞれのロールにはどんなことが期待されるか」を整理したうえで、自分なりに「似ていること」「違うこと」を考えてみます。
スクラムマスターって
スクラムガイドから
まずはやっぱり「スクラムガイド」から、スクラムマスターに関する記述を抜粋します。スクラムガイド2020 より抜粋です。
スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果たす。
...中略...
スクラムマスターは、さまざまな形でスクラムチームを支援する。
- 自己管理型で機能横断型のチームメンバーをコーチする。 ...略...
これをみて感じた印象・考え
- 支援するってどういうこと?
- 指示ではないのかな
- コーチングのために「〜だとおもう」みたいな意見は言いそう
- ⾃⼰管理型って?
- ひとことでいうと「指示を受けることなく、自己解決できること」かなぁ
- 言い換えると、指揮系統となる人(プロジェクトマネージャーetc)はスクラムにはいないということかも
記事:スクラムマスターって何をする人なの?
Chatworkでアジャイルコーチをされている だいくしー
さんの記事「スクラムマスターって何をする人なの?」では、次のとおり言及されています。
スクラムマスターによってもたらされる成果物は「自己管理化されたスクラムチーム」です。スクラムマスターが直接モノをつくることはありません。スクラムマスターによって導かれた「自己管理化されたスクラムチーム」によってソフトウェアはつくられます。
これをみて感じた印象・考え
- 成果物は、チームってわかりやすいな
- ある意味ピープルマネジメントっぽい
エンジニアリングマネージャーって
freeeのジャーマネ
freee、新オフィスへの移転までのお話 より抜粋します。
ジャーマネとは・・・freeeではマネージャーのことを「ジャーマネ」という。「マネージャー」ではなく「ジャーマネ」なのは、芸能界におけるタレントのマネージャーをイメージしているため(「タレント」であるメンバーを叱咤激励して成長・活躍することをサポートする役割であって、メンバーの上に立つ者ではない、という思いを込めて)。
これをみて感じた印象・考え
つまり「エンジニアリングマネージャー=上司」ではなく、あくまで一つのロール(メンバーとは上下ではなく、横の関係)であり、 「タレント」であるメンバーを叱咤激励して成長・活躍することをサポートする役割 ということですね。
世の中のエンジニアリングマネージャーって
いろいろみていきますが、組織やチームによって大きく異る印象があります。 あくまで、自分の組織・チームだと「こういう期待値だよね」って意識合わせが大事そうだなという前提をおいて、整理していきます。
書籍: HIGH OUTPUT MANAGEMENT
書籍: HIGH OUTPUT MANAGEMENT では、次のとおりに述べられています。エンジニアリングマネージャーに関する言及ではなく、一般的な「マネージャー」に求められる考え方です。
マネージャーのアウトプット = 自分の組織のアウトプット + 影響の及ぶ隣接組織のアウトプット
これをみて感じた印象・考え
- サーバントリーダーシップとか、どのように実現するかとかはさておき、「組織のアウトプット」が成果だというのはわかりやすいなーと
- 加えて「影響の及ぶ隣接組織」も成果に入るのが面白いなと。逆にいうと、自分の組織だけでなく、隣接組織にも影響を与えよということかなと。
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド
「エンジニアリング組織論への招待」著者の @hirokidaichi
さんの記事「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」から抜粋します。「弱めのEM定義」と「強めのEM定義」の考え方です。
「弱めのEM定義」は、「エンジニアのマネジメントスキル」としてのピープルマネジメントスキルとテクノロジーマネジメントのスキルを持っているキャリアになります。
...中略...
「強めのEM定義」ではどうでしょうか。ピープルマネジメントに加えて、テクノロジーマネジメントのみならず、プロジェクトマネジメントやプロダクトマネジメントの一部の要件定義能力などが求められることもあります
これをみて感じた印象・考え
- 「ピープルマネジメント」はコアにありそう
- それ以外にも、「テクノロジーマネジメント」「プロジェクトマネジメント」「プロダクトマネジメント」も求められる場合があると。
- 組織やチームによって、どの要素を求められるかは大きく異なりそう
- これらは、 「エンジニアリング」 マネージャーに求められる固有の概念だなーと
- 全部完璧にデキる人なんていないのでは?
- 逆に抱え込みすぎると、ボトルネックになりそう
書籍:エンジニアリングマネージャー
冒頭でも触れた「株式会社アトラクタ」の方々が 翻訳 執筆 [^1] された「 エンジニアリングマネージャーのしごと 」という本の抜粋です。
2.2 活動を分類して生産性を高めるには
..略..日々取り組んでいるマネジメントの活動を次の4つのバケツに分類することでした。
情報収集
意思決定
ナッジング (ナッジングとは、議論に対して自分の観点を提供することで、決定に影響を与えること)
ロールモデル (良いマネージャーになるとは、物事をきちんと実行し、いうべきことを言うこと)
これをみて感じた印象・考え
- 情報収集は、1開発者としては短期的に必要とならない情報はとりにいかない(まとまった作業時間を確保したい)傾向にあるはず
- だから、長期的に有用となる情報をEMが取りに行くのは大事な観点
- はたして自分はこの思考ができているか(今はあまりできていない)
- 意思決定ときくと、トップダウンの決定にもみえるけど、
- あくまで「チームから情報を上げてもらう」「自分の意見を言ってチームで合意をえる」というスタイルもあるのだろうな
- 「チームが検討したこと」に対する意見も言える必要があるから「意思決定」が必要ということかも
- チームができないこと(たとえば、環境要因に関する決定とか)で決定することも多そう
- ナッジングって初めて聞いたけど大事そう
- 自分の考え方を発信して成長を促す感じかなぁ
- ロールモデルは大事な考え方。チームに認めてもらい、意見を聞いてもらうためにも。
自分が目指したい「ジャーマネ」の姿
これまで見てきた通り、世の中のエンジニアリングマネージャーに求められることは、その組織やチームによって多種多様で抽象的であることがわかりました。考察のため「エンジニアリングマネージャー」と「スクラムマスター」とを比較するにあたり、「自分が目指したい「ジャーマネ」の姿」を具体化しておきます。
私は、前述の 「弱めのEM定義」と「強めのEM定義」 で言うところの「ピープルマネジメント」に主軸を置きたいと思います。とはいえ、他の3つのマネジメント「テクノロジーマネジメント」「プロジェクトマネジメント」「プロダクトマネジメント」も、チーム全体で担保できる必要はあるとも思います。それらをすべて自分がリードするというよりは、強みを持つ人に移譲したり、ナッジングによりチーム全体で成果が出せる状態にするスタンスを取りたいです2。
「freeeのジャーマネ」像にも共感していて、自分のチームの成果が出ることも大切だけど、それよりも「メンバー個人の成長支援」を第一に考えられるようにしたいです。例えば、「異動戦国」というfreeeの制度は、短期的な「チームの成果」という意味ではマイナスと捉えることもできます(人が抜けるとアウトプットは落ちるので)。しかし、私は長期的には「存続可能なチーム」に寄与するし、社内のメンバーのモチベーション向上に寄与するとも思うのでいい制度だなと感じています。
ロールモデルとなるためにも、「自分が学び・成長する気概があること」は周りに示したいです。新しい技術のキャッチアップや、PRレビューを通じた学び(メンバーの実装から学びって多いよね)や、こんな本読んでますよーとか、こんなアウトプット出してみましたとかです。
似ていることと違うこと
似ていること
一般的なEMと、SM
- 成長支援という意味では似ている
- サーバントリーダーシップ的なところ
- しかし、EMでも技術で引っ張るスタイルもありえるし、必ずしもサーバントリーダーシップのスタイルを取らない人も多そう
自分の目指す「ジャーマネ」像との比較
- 「ピープルマネジメント」に軸を置き、成長支援に注力したいスタイルは考えがかなり近いと思う
- 「サーバントリーダーシップ的なところ」は合致する
違うこと
一般的なEMと、SM
成果が違う
- SMの成果は、「自己管理型のチームの成長」
- EMの成果は、「チーム(及び周辺のチーム)のアウトプット」
EMは評価をする
- 場合によってはそれが足かせになることを気をつけなければいけない
自分の目指す「ジャーマネ」像との比較
- EMは評価をする(が、SMと相反しないよう「味方」な関係でいたい)
- 「成長支援」という側面から、成長できたところに光を照らして言語化し、アピールするような存在になりたいと思う
- 「評価をするから上の立場」みたいな関係性にはなりたくないし(実際freeeのジャーマネはそういう考え方だし)、味方としていつでも相談しやすい存在でいたいと思う
余談
アトラクタの永瀬さんも、SHINAGAWA Agile Talks というポッドキャスト(12:00あたり) で、次のとおり言い切ってくれていて、「スクラムマスターとエンジニアリングマネージャーを兼務する」ことの不安が減少されました。
従来型の
プロジェクトマネジメント
というロールは、スクラムにおいては不要ということマネジメントそのものを否定はしていないし、エンジニアリングマネージャーは大事なロール
(いずれも意訳)
まとめ
アジャイル界隈の「マネージャー不要論」をみかけたことをきっかけに、それってどういうことなのか理解を深めました。
この問いに対する自分の理解として、不要と言っているのは「プロジェクトマネジメントを、一人のリーダーが行うこと」だという結論に至っています。言い換えると、特にスクラムでは「開発者(あるいはPOも含めて)が全員でプロジェクトマネジメントをしている、自己管理型のチーム」であるというスタンスだと思います。このマインドチェンジを促すために、「(旧来型のプロジェクト)マネージャーは不要」だという言葉が使われていたのかなと思います。
またこれらの思考を経て、スクラムマスターやエンジニアリングマネージャーに求められることの理解を深め、自分なりのエンジニアリングマネージャー像を検討することができました。
明日はスペシャルアジャイルストーリーズの3日目、micciさんの「アジャイル初心者がスクラムマスターをやってみた」をお楽しみに!
- 当初「執筆された」と書いてしまいましたが「翻訳」の誤りでしたので訂正いたします↩
- 一方で、チームの状態に応じて、スタイルを変える必要があるとも思います。たとえば、書籍: エラスティックリーダーシップには、「サバイバルモード(学ぶ時間がない)」「学習モード(課題解決のために学んでいる)」「自己組織化モード(ファシリテート、実験)」の3つのチームフェーズがあり、それぞれのフェーズに合わせてリーダーシップのスタイルを変えるべきだと言及されています。具体的には、それぞれのフェーズには、「指揮系統型(現場でリードしてゆとりをもたせる)」「コーチ(意思決定の仕方を教える)」「ファシリテーター(環境などに気を配る。チームの課題はチームが解決すると信頼する)」が適していると述べています。 今のチームは、学習モードと自己組織化モードの間くらいだと認識しているため、このスタイルが取れるとも思っています。(今まで自分がいたチームよりもレベルが高いと感じる・・!自分も学びが多くありがたい)↩