エンジニアリングマネージャーとしての道

アドベントカレンダー12月8日の記事です。 Qiitaのアドベントカレンダーだけど、自分のブログに書いてるしポエム寄りでも許されるよね。

qiita.com

アウトライン

• マネージャーとは
  • 諸注意
  • チームとは
  • 組織とは
  • 必要なこと
• マネージャーになるために
• マネージャーが危惧すること
• マネージャーからスクラムマスターへジョブチェンジ

マネージャーとは

エンジニアリングマネージャーにおいて重要なことはチームで働くことのパフォーマンスを最大化することである。

諸注意

注意すべきはマイクロマネジメントをすることが必ずしも正しいマネジメントではないということ。

トップダウンで命令を下すのも正しいマネジメントとは言えない。（そういった組織を目指すなら別だが、自分はそんな組織を作りたくない）

また、すべての責任を負うことが良いマネージャーではない。

良いマネージャーであろうとすると、メンバーの期待に応えようとして自分の首を絞めることがある。

たとえば、メンバーとしてマネージャーであればマネージャーが「責任は俺が取るからあとは自由にやれ」というマネージャーを望むのは間違ってはいないが、マネージャーからすればメンバー自身が責任を負う覚悟をしているかどうかは重要である。甘やかすことと守ることは違う。

守るべきときは守り、突き放すべきときは突き放すことができなければならない。

マネージャーとはかくあるべきとメンバーから言われることもあるが、真に受けてはいけない。

チームとは

なぜチームで働くのかを考えてみてほしい。

また、チームとはどんなものなのかを考えてみてほしい。

私が死んでも代わりはいるもの

チームで働くということは、互いが互いの代わりができるようにあるべきである。

集団で働いているということがすなわちチームではない。

複数人で協調し仕事をしていれば、お互いの欠点を補い合える。

さらには、休暇を取りやすくなる。

お互いにサポートしあっていれば、休暇を取るのに気を使う必要はない。

たとえばあなたが休暇を取得したとしても、同僚が「以前自分が休暇とったときに代わりにいろいろとやってくれていたし、今度は自分がサポートしてあげよう。」という気持ちになっていれば互いに気持ちよくいられる。

もし、一人で働いていたり、集団で働いているが協調していないとすれば上記のメリットは得られない

全員で協調し、互いの欠点を補いあうことこそがチームである。

チームであるには

• 誰かがやってくれているから自分は関わらなくても良いや。という考えを各自が捨てること。

• ペアプロやモブプロを推奨する

• 互いに尊敬しあい、誠実に指摘しあえる関係を築く

チームのパフォーマンスを下げる要因

• 自立していないメンバー
• コミュニケーションコスト
• 無計画

組織とは

人の集まりである

人の集まりであるということはそこに感情が存在する

また、互いに相手がどんな背景で何を考えて発言をしているのかを完璧に把握することはできない。

そのため、メンバー間で軋轢が生まれる。

軋轢が生じないようにすること、軋轢が生じた際にそれを解決することもマネージャーの期待される役割である。

必要なこと

• 1 on 1 を実施し、ティーチング、コーチングを使い分けられること
• メンバー一人ひとりのなりたい姿を把握し、そこに向かうためのサポートを行えること
  • 会社としてやってほしいことと、本人の目指す姿とのつながりを見出すこと
• 開発における知識
  • メンバーからの信頼を得られなければマネージャーとしてやっていくのは厳しい
• コードを自分で書きたくなるが、それをぐっとこらえられる自制心
  • 自分でコードを書くことはSPOFにならないか
  • 自分がボトルネックとなって、チームのパフォーマンスを下げないか

マネージャーになるためには

※ 自分自身マネージャーになりたいと思ったことはほぼ無い。 ※ 振り返るとこんな感じだよなーというのをつらつらと。結局は信頼貯金だとは思うので、これがすべてではない。

• 自分で考えられること
  • どうしたらいいかわからないことに対してもいくつか自分なりに考えてみる
  • 他者に丸投げしない
• 率先して動けること
  • 大体の人は誰かがやってくれると思うし、誰かがやってくれていればわざわざそれを奪おうとしない
• 組織の課題を見つけられること
  • 課題はいくらでも転がっている
  • 課題を作り出すことが目的ではない
  • 課題を見出すことが重要
  • 課題の本質と、その課題を解決したらどうなるか、解決すべき課題なのかを見極める
• 上司と課題について話し合えること
  • なにが課題なのか
  • なぜそれを課題だと考えるのか
  • その課題を解決するとどうなるのか
  • その課題を解決しないとどうなるのか
• 長期的な視点を持つこと
  • 持続可能な開発をするために組織も長期的に持続可能でなければならない
  • メンバーであれば短期的な視点でも良いが、マネージャーになるのであれば長期的な視点を持てなければならない
  • 新しい技術を取り入れることはエンジニアにとっては非常に魅力的であるが、その新しい技術を持って今後も開発できるのか、それによって新たな混乱を生まないか、自分は最後まで責任を負えるのか
    • 責任を負うというのは、全員を教育して自分がいなくても回るようにするとかそういったことを含む
• コミュニケーション能力・交渉力
  • 何かを成し遂げるためには関係各位への説明と、説得が必要となる場面は往々にして存在する
• 最後まで責任をもってやり遂げる
• 感情と論理の切り分け
• 上司に責任を取らせず、自分で責任を負う覚悟を決める

マネージャーが危惧すること

• 組織が破壊されること
• 組織を保てなくなること
  • 一人ひとりのやりたいことや、なりたい姿を目指すことを応援しサポートするが、組織を維持し続けることが前提である。

たとえば、自分がメンバーであった頃はどんどん新技術を取り入れるべきだ！それこそエンジニアだ！と息巻いていたころもあった。

自分自身マネージャーになってわかったが、非常に無責任な発言である。

新しい技術を取り入れるということは、その組織としてそれを維持し続けるということである。

大抵は新しい技術を取り入れたいというものの、それを維持し続けるための仕組みづくりは放り投げられるものである。なぜなら、新しい技術を取り入れたい人は取り入れたことに満足してしまいがちだからである。

マネージャーからスクラムマスターへジョブチェンジ

一番戸惑うのは指示しないこと。

トップダウンでのやり方はチームの成長につながらないので、やってはいけない行為。

誰かが指示して動く組織は、指示する人間の能力がキャップになる。

指示者を超える組織は期待出来ないということである。

会社組織上のマネージャーはどうしてもトップダウンで命令を下すことを要求される場面は避けられない。チームをリードして成果を出す責任があるからだ。 しかし、スクラムにおいてチームの責任はチームにある。

責任を持たないマネージャーが口出しをすることはあってはならない。

自分が気をつけたいと思って書き残したものは以下の通り。改めて見ると、ひたすら似たようなことを書いている。

- やたらめったら行動しない
  - 行動したくなったら我慢する
- 直接的に手を下すことはしない
  - チームに気づきを与えるのみにする
  - チームの成長の機会を奪っていないか
- 自分の考えを真っ先に開示しない
  - チームを待つ
- 目的が最優先
  - 徹底的に理論武装すること
- 決めつけてはいけない
  - チームには無限の可能性があると信じること
- スクラムマスターの考えを押し付けてはいけない
- 提案・助言に留める
  - 提案するときは理由がなければいけない
  - やってみない？どうかな？とチームに決定は委任する
- 考えたことをチームに伝えない
- 何かをしてもらうときはその理由と期限を明確に
- チームの障害を取り除く
- マネージャーと頭を切り替えること
- 1回のMTGがうまくいくかどうかではなく、その先まで見据える
  - MTG終わったあと、チームがどう失敗・成功するのか
  - それはチームの成長になるのか
- 課題だと思ったことはまず書き出して、その何が課題であるのかを深掘りして手を打つ。課題の本質を見極める。

※ 気をつけるが、実践できるかどうかはまた別の話。

---

マネジメント研修を受けて再考したのが以下

スクラムマスターとマネージャーは相反する関係か？

マネジメントの研修を受けると今まで自分の考えていたマネージャー像は自分の観測範囲内のマネージャー像であり、スクラムマスターとも必ずしも相反するものでもないことに気づく。

あなたの想像するマネージャーとはいったいどんなことをする人ですか？

相反関係にあるのはプロジェクトマネージャーのことを指してはいませんか？

あなたがマネージャーだと思っている人間はマネジメントについてどれだけの学を持っているのでしょうか？

マネージャーの原理原則に何があるかを理解しているだろうか？

マネジメントとは 部下を通して仕事の成果を上げること であって、必ずしもトップダウンで指示を下すことではない。

仕事の成果とは、組織や職場の目標の達成であり、そのために、 人・モノ・金 を 効果的・効率的 に活用する。

そのために、部下に裁量を与えその範囲内で自由にやってもらうのだ。

権限と責任

少し権限と責任について考えてみよう。

裁量（遂行権限）を与えられた部下には遂行責任と報告の義務が発生する。

報告の義務が発生するのは何故か。管理監督者には管理監督責任があるからだ。

権限がないといことはよく聞くことばではあるが、権限とはなんであろうか？

権限には責任が伴う。責任とは社内における責任、対外的な責任がある。

メンバーがどんなに権限を要求したところでどうしても渡せない権限が存在するということだ。

それが管理監督者は（対外的に）管理監督責任と結果責任を負っているからだ。

スクラムにおいてチームは遂行責任を負うが、果たして結果責任まで負うのだろうか？

誤解のないように正しく表現をしよう。”対外的に結果責任を負えるだろうか？”

そういった点において、会社組織上管理監督者は省くことはできない。

マネージャーもスクラムマスターもチームの成果を最大化することが目的であると言って差し支えないのではないだろうか。

目的が同一だとして違いがあるとすればどこにあるのか。

管理監督者であるかどうかが一つの鍵ではないだろうか。

スクラムマスターに果たして管理監督責任はあるのだろうか？

スクラムマスターはチームの成果を最大化するために尽力する存在であって、マネージャー（管理者）ではない。

なぜ、マネージャーとは違う呼び方を敢えてするのかはそういったところにもあるのだろう。

スクラムマスターはチームに指示は出さない。なにかを成し遂げられなかったときの責任はチームにあるのだろうか、スクラムマスターにあるのだろうか。それともPOだろうか。

問題が発生したときに対外的に責任を取るのは誰だろうか？

問題が発生したとき、責任の所在が曖昧になっては困る。

つまるところ相反するものがあるとすれば「対外的な管理監督責任」である。

対外的に管理監督責任のないスクラムマスターにはマネージャーはどうしたってなり得ないのかもしれない。

一方でマネージャーのみが持つ権限（たとえば人事権）も存在するとすればスクラムマスターは行動が制限されていることになり、チームのために効率よく最善の手を打つことができるだろうか？

シャーデンフロイデ

ところで、なぜ責任をとるのは管理者でなければならないのか。

チームメンバーの首にその価値はないのだろうか？

なにかを成し遂げられなかった責任が、サービスの終了につながったりして職を失うとしたらメンバーはその責任を負っていると言えないのだろうか。

たとえば大臣が問題を起こしたとき「総理が責任を取れ！」という発言を聞いたことはないだろうか？

総理が預かり知らぬところで大臣が問題を起こしたとして、それが大臣個人の問題だったとして人々にとってそんなことは関係ないのだ。

任命責任がなどとそれらしい理由をのたまうが、結局のところ権力者をその椅子から引きずり下ろしたくてたまらないのだ。

このとき得られる感情は「シャーデンフロイデ」という。つまり、「メシウマ」だ。

これが人間心理に組み込まれている以上、責任者は必要なのかもしれない。

シャーデンフロイデ: 人の不幸を喜ぶ私たちの闇