こんにちは。SREチームでリーダーをやっている木村です。
座右の名は「明日自分が交通事故にあっても、システムの運用を滞りなくする」です。
2021年から SRE 責任者の役割をしていますが、その中でいわゆるマネジメントという業務を行っています。
本日は、この答えのないマネジメントについて少しお話をさせていただけたら。と思っています。
そもそもマネジメントとは何をすれば良いものか？
初めてマネジメント業務をすると大体の人がこの疑問を最初考えると思いますが、
大きく分けると2つに分類されるかと思います。
成果を上げるための仕組みを作る
業務の割り振りや、メンバーの成長するための仕組み等を整えたりすること
リーダーシップ
その場に集まっているメンバーに目標やビジョンを共有し、周りのモチベーションを高めチームの成果が メンバー = 1 のエンゲージメントではなく、
メンバー = 1.xx にするために率先してチームに示すこと。
これだけだと、まだイメージがつかないと思いますので、もう少し具体的な説明をしていきます。
メンバーの成長について気をつけていること
チームの成果の最大化するにあたっての一番難しい所ですが、成功すると一番チームの成果が伸びる部分だと思っています。
一番重要(当たり前)なのが、メンバー一人ひとりが大切にしているアイデンティティは一人ひとり違うことです。
つまり、人の成長は工場の生産ラインのように同じことをすれば良い。というわけではありません。
また新米マネージャーさんと会話をしていて、言語化でよく困っているな。と思うシーンは「成長パラメーターの定義」かな？と思っています。
難しいし、答えのないものなのですが、私がメンバーの成長について普遍的な考えているのは下記になります。
やる仕事 x 個々のメンバーの能力に応じてデリゲーションをすること
エンジニアリングは当然のことながら、コードを書いているだけで仕事が完結しません。
- コードを書く
- 仕様を詰める
- 影響範囲を考慮して、リスクマネジメントをする
- etc.....
等、書いていたらキリがないのですが、大きく分類をすると
- 他のチームと確認、協議をしながらすすめる仕事
- 動く成果物を作ること
の2種類に分かれるかと思います。
例として、とあるメンバーが他のチームと確認、協議をしながらすすめる仕事の場合に
このメンバーに対してどの程度仕事や権限の移譲をすればよいか？
- 指示する >> 管理者として意思決定を行い、作業をしてもらう
- 売り込む >> 意思決定についての人々を納得させる
- 相談する >> 決定する前に、チームからの意見を得る
- 同意する >> チームと一緒に決定を下す
- アドバイスする >> チームによる意思決定に影響を及ぼす
- 問い合わせる >> チームの決定後のフィードバックを求める
- 移譲する >> 特に影響を及ぼさずチームに任せる
を意識してコミュニケーションを取るように心がけています。
これは仕事をする上で、権限不足によってやりたくても、権限がなくてできない。というジレンマを防ぐためです。
また権限不足は、しばし、チームの成長を阻害すると思っています。
なので SRE チームのリーダーとして、各メンバーの1on1 で最近起こったデリゲーションの視点で「現状ここが足りていなくて、権限が渡せないんだけども」という話を良くしています。
How は提示するが What はなるべく関与しない
端的に言えば、マイクロマネジメントをしすぎない。という言葉になりますが、具体で言うと
- どのようなものを作るか？
- どんなことをしたいのか？
は事業やサービスのロードマップに基づくものが多いので、How に関する説明や Why (なぜ必要なのか？) は説明をしますが、What (何をどうやって作るのか？) に関しては、なるべく口を挟まないようにしています。
What に関して、マネージャーが多く介入してしまうと、メンバーの自尊心が徐々に失われていき、指示待ちのメンバーが形成されてしまいます。
場合によっては、事前に話を聞きながら、「失敗しそうだな」と思いつつ、わざと失敗させることすらあります。
人が 一番学びを得るタイミングは、成功したときと失敗したとき です。
放置プレーのマネージャーなのか？と言われそうですが、重要にしていることは失敗が致命的なのか？否か？のリスクマネージメントの視点をもって聞くこと。だと思っています。
大きく失敗をすると、その影響は個人的な影響範囲ではなく、チーム全体に波及します。
マネージャーとして重要なのは、「目の前の大きな石はどかすが、小さな小石は転びながら成長してもらう」
これを心がけることが重要だと思っています。
能力の言語化のお手伝い
人によっては、完全にわけてしまう人もいますが、SRE チームでは、一貫してエンジニアがやらなくてはいけないことは一通り最低限できるようになる。という方針でピープルマネジメントをしています。
これも分類すると
- ピープルマネジメント
- メンター等になったときに人を成長に導く能力
- テクノロジーマネジメント
- 作り上げる技術力
- プロジェクトマネジメント
- プロジェクトに関係のある人と期待値マネジメントを行いながら、ヒト・モノ・カネの観点で、プロジェクトを管理する能力
- プロダクトマネジメント
- 作っているプロダクトの未来を描ける能力
これが全てできるヒトは紛れもなくスーパーマンで銀の弾丸ですし、人によっては、それってメンバーがやること多くない？なんの為のマネージャーとメンバーって役割で分けているの？と言われたりもしますが、過去の経験から
技術だけでは解決できない問題は、実際の所多いし、技術がないとそもそもその場に立てないことも多い。
という自分がいっぱい失敗した経験を元に
全ての能力を最低限できる能力を身につけることによって、できる幅と得意領域が総合トータルの引き出しが増えて更に伸びる。
というのを Join したメンバーには、一律で納得をしてもらうまで、何度も 1on1 で話すようにしています。
上記のような分類を軸にしてメンバーと話をして、メンバーの能力の言語化のお手伝いをして、成長を促すようにしています。
ただ、成長に置いて一番重要なのは、マネージャーは成長のお手伝いをすることはできるけども、成長のコミットメントをするのは、当人しかできない。
ということです。
極論、無理強いをしてもやらされている状態では、ある程度迄は伸びるかもしれませんが、爆発的な成長は、当人が納得(いわゆる腹落ち)をしない限り、経験として自分に身につかないからです。
マネージャーとして、できることとできないことの線引をすることによって、マネージャーもまた、メンバーに対する過度な成長期待マネジメントをコントロールをしなければならないと思っています。
最後に
このような基本的な軸をもちつつ、マネジメントという役割を行っていますが、それでも答えのない仕事なので、つまづくシーンも多々あるのが現実ですし、きっと世の中にはもっともっとすごい人もいると思います。
ですが、マネージャーもまたメンバーと共に、成長に対して常に真摯にコミットメントをして、チームが路頭に迷わないようにしていかなくてはいけません。
大変なこともたくさんありますが、逆にメンバーが爆発的に育っていたり、今までできなかったことができるようになったり、周りの人に褒めてもらっている姿等を見ると、「あぁやってよかったなぁ」という嬉しいこともたくさんあります。
このようにビザスクの SRE チームでは、総合トータルでチームやメンバーの成長に対して、真摯に向き合っています。
興味がある方は 是非こちらも見てください。
GitHub visasq/recruting-public
それではまた
