スクラムマスターとエンジニアリングマネージャーを1年兼務して感じた難しさの正体
2023年、私はスクラムマスターとエンジニアリングマネージャーを兼務していたのですが、常に難しさを感じ続けた1年でした。
その困難に直面しながらも、なかなかその原因を深く分析する時間を取ることができませんでした。今回のAdvent Calendarの投稿を通じて原因をしっかりと言語化し、それを今後の改善に活かす絶好の機会にしたいと思います!
私の役割
Web・モバイルエンジニアで構成するチームのスクラムマスター
開発部全体のマネジメント(エンジニアリングマネージャー)
私は2023年を通じて上記2つの役割を兼務していました。
スクラムマスターとかエンジニアリングマネージャーって抽象的でわからんと思う人もいそうなので、簡単に説明しておきます。
エンジニアリングマネージャーの役割とは
世の中のエンジニアリングマネージャーを超ざっくり分類すると、3つに分けられるのかなと思っています。
プロジェクト計画と管理(PM系)
計画に合わせたリソース調整
進捗管理
問題の解消
技術面のリード(Tech系)
プロジェクトやメンバーのコードレビュー
新技術やベストプラクティス導入推進
技術課題に対する方針策定
メンバーの指導・育成
組織と人材管理(People系)
採用活動
メンバー評価とフィードバック
組織の雰囲気や労働環境の向上
マネフォ内のマネージャーはというと、人によって役割は様々で、決まった形はありません。
私が関わるプロダクトでは「3. 組織と人材管理(People系)」をエンジニアリングマネージャーが担当し、「1. プロジェクト計画と管理(PM系)」や「2. 技術面のリード(Tech系)」はテックリードやスクラムチームに推進してもらっています。
スクラムマスターの役割とは
もう一方のスクラムマスターの仕事を超ざっくり分類すると、4つに分けられるのかなと思っています。
プロセス推進とファシリテーション
スクラムのプロセスに沿うようにチームを支援
スクラムイベントの円滑な進行サポート
チームサポートとコーチング
チームの協力促進
アジャイルなマインドセットの醸成
障害の除去と問題解決
チームのパフォーマンスを下げる障害や課題の発見と解決促進
継続的な改善
チーム活動を定期的に振り返り、改善の促し
プロダクトに対する外部フィードバックへの適応支援
福岡拠点にはチーム数に対してほど良い人数のスクラムマスターが在籍しているため、上記の役割を概ね対応できていると思います。
年初に持っていた楽観的イメージ
2つの役割を持って大変そうに見えるかもしれませんが、年初時点で私はかなり楽観視していました。
というのも、前職でエンジニアリングマネージャーを4年ほど経験して、規模感も同じだったため、その貯金で効率よくやっていけると思っていたからです。
スクラムマスターの経験値が少なかったので、その部分さえクリアできればしっかり両立できるだろうと。
しかし、1年が経過し振り返ってみると、思うように進まなかった点が多く、反省点の多い1年となりました。
具体的な問題としては、以下の2つが挙げられます。
スクラムイベントを移譲しない問題
スクラムマスターは、チームメンバーの問題解決力を育てるために、適切なタイミングでスクラムイベントの主導権をエンジニアに移譲することが重要ですが、私はなかなかできませんでした。
エンジニアリングマネージャーを担っていると、ビジネスサイドからリリース日に関する要望の声をもらう機会が多くなります。その期待に応えるために、開発以外の余計な負担をチームから排除しようとした結果、スクラムイベントをチームへ移譲しませんでした。
この行動は目先の期日を優先した結果、チームの自己組織化と成長を阻害していた可能性があり、長期的な視点に立つと良くない選択だったと思います。
スプリントプランニングでマネージャーの顔になる問題
プランニングで案件(PBI)の優先順位付けはプロダクトオーナーが行い、案件を達成するためのタスクの優先順位はチームで行います。
本来のスクラムでは、そこにスクラムマスターが力を及ぼすことはありません。
しかしエンジニアリングマネージャーを兼務していると、スクラムチーム外の案件(例えば別チームのリソース不足に対するサポートのタスクなど)にも頭を悩ませたりします。
その悩みを解消するために、私がスクラムマスターとして関わるチームに対してサポートのアサインを一方的に決定してしまうことがありました。
両者の価値観は衝突することがある
2つの役割は、それぞれ異なる視点と責任を持っています。
エンジニアリングマネージャーは進行と管理を重視し、スクラムマスターはチームのパフォーマンス最大化と改善を重視します。
どちらも大事な価値観なので両立できれば良いのですが、スケジュール遅延やトラブル対応などの有事においては、両者の価値観が衝突することがあります。
それを兼務するとなると、自分の中で2つの価値観の矛盾に苦しむことになり、頭の痛い問題となっていました。
頼りにしたのはMVVCのバリュー
いろいろ悩んだ末、マネーフォワードの「バリュー」を用いて判断することで、スクラムマスターとエンジニアリングマネージャーの間で生じる自己矛盾に対して、一定の答えを見つけることができました。
マネフォにはMVVC(ミッション・ビジョン・バリュー・カルチャー)があり、さまざまな活動を通じて社内に広まっています。
なかでもバリューは組織の行動指針を示すものです。
マネーフォワードのバリューには「User Focus」「Tech & Design」「Fairness」があります。
これらは、「ユーザーの期待や想像を超えた価値を提供する」「テクノロジーとデザインの力を最大限に活かす」「全てのステークホルダーに対してフェアで誠実に向き合う」、ということを示しています。
エンジニアリングマネージャーとして、スクラムに反する決断を下さなければならない場合でも、バリューに基づいて判断することで、ストレスを軽減することができました。
2つ以上の価値観が衝突する際には正解を見つけることは難しいものの、バリューのような判断軸があることで、判断や行動のスピードが大きく変わると感じました。
一定規模の企業経営において、ミッション・ビジョン・バリューの重要性がよく語られますが、私自身がその重要性を実感することができました。
まとめ
今回は、スクラムマスターとエンジニアリングマネージャーの二つの役割を兼務する中での苦労について、感じたことを言語化してみました。
理想的には、これらの役割を両立させることが望ましいですが、現実には両者の価値観が衝突することがあり、一人の人間がこれらを兼ねると、自己矛盾に悩むことがありました。
そんな時、組織の行動指針であるバリューを頼りにすることで、多くの選択肢の中から自信を持って最善の選択をすることができるようになりました。
ここまで読むと、兼務をうまくこなせるようになったかのように思えるかもしれませんが、実際にはそう簡単にはいかないと感じています。
時間とエネルギーの制約から、エンジニアリングマネージャーとしての戦略立案や、スクラムマスターとしてのチーム支援、どちらも十分には行えていなかったと感じています。
来年はより多くの優秀な人を採用して、私自身がどちらか一方の役割に専念できるようにすることで 楽をしたい、もう一方の役割をしっかりと果たせるようにしたいと考えています。
ということで、カジュアル面談をお待ちしております!
様々な職種で採用実施中!
マネーフォワードの福岡開発拠点ではエンジニアを募集しています。
もし福岡開発拠点のメンバーとのカジュアルな面談に興味がある方は、それだけでも大歓迎です。面談希望の際は、「その他要望」欄にその旨をご記入ください。