エンジニアマネージャがスクラムマスターしてもいいけど条件があるよ

結論としては、「エンジニアマネージャがスクラムマスターしてもいいと思いますが、自分が今なんの役割で話しているかを相手に伝えるといいよ」になります。

アジャイル開発は価値観であり、スクラムは多くを語らないフレームワークです。そのため、答えがないことが多いので、ここに書いていることが正解とは限りません。よって、いろんな意見を知り、自分なりの答えを持つことがおすすめです。

スクラムマスターの役割と責任

スクラムマスターの役割と責任について、スクラムガイドを確認してみましょう。

スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。 –スクラムガイドより

スクラムマスター（SM)はスクラムのために生まれた存在です。だから、上記のように、スクラムに関わる作業以外のことを、原則しません。これはつまり、 チームに入っていたとしても、チームの仕事に直接関与しないということです。

もう少しスクラムガイドを見てみましょう。スクラムガイドにはSMの支援内容がたくさん書かれていますが、それらの末尾の言葉は以下のようになっています

コーチする、支援する、働きかける、守られるようにする、理解してもらう、促進する、指導する、トレーニングする、計画する、助言する、理解してもらう、実施してもらう、取り除く –スクラムガイドより

チームの仕事に直接関与していないことがよくわかります。

その結果、「ええープロジェクトの仕事してくれないのー」となりがちで、開発しながらSMを担当・・・といった兼務の人が多く、専任を立てられない傾向がある気がしています（この話題はまた別の機会に）。

さらにスクラムガイドを読んでいきましょう。

スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。 –スクラムガイドより

さらにこうも書かれています。

スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。 –スクラムガイドより

実際に、いろんな現場を見てきましたが、多くの人が、「SM ＝ チームでスクラムを教える人」、または「SM ＝ チームのスクラムイベントをファシリする人」だと思っています。

しかし、「スクラムチームと組織」とあるように、現場チームだけでなく、マネジメント、ステークホルダー、経営・・・と組織に対してスクラムをインストールしなければなりません。チームに閉じこもっているSMは、役割と責任の一部しか満たせないことがよくわかります。

SMがチームという狭い範囲だけで活動してしまうと、「こうやらなきゃだめ」という原理主義に陥りやすくなり、チームとマネジメント層に壁が生まれます。その結果、目的と手段がおかしくなってしまう傾向があります。

さらにスクラムガイドを読んでいきましょう。

スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。–スクラムガイドより

スクラムマスターは、「スクラムを『正しく』やれば、チームはハッピーになる！」と信じています。しかも、チームの仕事もしない。こうやって書くととても怪しい存在です（大半のマネージャはここで眉をひそめます）。

しかし、実際はスクラムが機能するとうまくいく可能性を高められるため、スクラムマスターはスクラムのインストールや正しく使うための支援を必死にします。

これは、スクラムマスターが以下に経験豊富で教えるのが上手であっても、チームとして結果が出なければ「責任を果たせていない」と言えます。

エンジニアリングマネージャの役割と責任

エンジニアリングマネージャ（EM）の世界には、スクラムガイドのようなものがないので、各社がEMというものを定義することが多いです。ただ、公開されている情報を見ていると、ある程度の傾向はあるように感じます。たとえばこんな感じでしょうか。

1. EMは、チームのピープルマネジメントに責任を持つ（チームメンバーの成長支援と、成果支援など）
2. EMは、CTOやテックリードに協力して、テクノロジーマネジメントに責任を持つ（プロセス、品質、運用など）
3. EMは、チームやチームを超えた範囲で、採用と組織づくりといった組織マネジメントに責任を持つ

ドラッガーなどが教えてくれる一般的なマネージャは、人を育て成果を出すため、1がメインの仕事と言えます。EMの場合は、仕事の性質上、テクノロジー面や、採用面が追加されます。

ざっくり3つに分けましたが、これらのマネジメント領域に責任を持つことによって、ビジネスやプロダクトに貢献していきます。

SMとEMの役割範囲

SMとEMには共通点があります。

1. 組織を支援する点
2. 人を育てる点
3. 上記に関わりながら、ビジネスやプロダクトに貢献する点

相違点は以下です。

1. SMは、スクラムに関係することしかしない
2. SMは、プロセスを除いたテクノロジーマネジメントをしない
3. SMは、採用にはかかわらない

これらをざっくり図にまとめるとこんな感じでしょうか。

チームはプロジェクトやプロダクトに向かって、ミスを最小限に抑え、点を取られないように頑張ります。野球に例えると内野の守備に似ています。

一方、EMは内野を見守りながら、いつでも支援できるように準備するので、外野の守備に似ています。ライトやりながらセンターもやってレフトも守らなければならないので、守備範囲はとても広くなります。

ときには、勢いのあるライナーやフライが外野に飛んでくるため（急なトラブル、チームを超えた課題など）、EMはそれらをカバーし、内野にボールをすぐ返していきます（バックホーム）。

SMはその性質上、外野の一部（図だとセンター付近）を守っています。しかし、SMだけの経験しか積んでいない人はまだ少ないはずなので、「テクノロジーマネジメントに強いSM」というように守備範囲を広げているSMもいるはずです。

SMとEMは、人や組織に関わりながら、ビジネスやプロダクトに貢献するという同じゴールを持っています。

エンジニアマネージャがスクラムマスターできるのか？

これはつまり、SMがEMになれるのかという問いでもあります。

自分の答えは「いいよー」です。

ただし、メンバーからしてみると、EMとしての意見なのか、SMとしての意見なのかがわからないため、相手に何かを話すときは、「EMとSM。どっちの帽子をかぶっているか？」を相手に伝える必要があります。

たとえば、EM/SMの人がこういった場合、メンバーはどう思うでしょうか？

僕「ちょっと期限があるので、少し残業してでも対応しましょう」

メンバーがEMの意見として聞いているなら、EMの命令・お願いに感じます。メンバーがSMの意見として聞いているなら、「スクラムって残業するのか」と思うでしょう。

自分は、「うまく方法を選べばいい」と思っているので、「EMはSMもできる」と考えています。

ただ、やはり兼務には見解があるので、原理原則っぽくなっちゃいますが、役割を別々でできるなら、別々でやったほうがいいケースもあるとおもいます（大規模な組織とか大人数の管理とか）。

というわけで、「エンジニアマネージャがスクラムマスターしてもいいけど条件があるよ」については、結論

1. エンジニアマネージャがスクラムマスターしてもいい
2. ただし、自分が今なんの役割で話しているかを相手に伝えよう

という回答になります。