マネジメントの技術の1つとして、現場にいなくてもマネジメントをする方法があることを知った。 この記事で言いたい"マネジメント”と指すものを具体的に言うとメンバーの状況把握や評価の情報集め、チームの状態を把握する、問題を把握する、みたいなところを指す。
こういったものを知るには、自分が直接「現場」（＝チームのミーティングや作業に立ち会うなど）に行って直接収集する方法と、他者を通じて収集する方法がある。 後者は、メンバー1人ずつと 1on1 で話すことでもいいし、別のマネージャから見えているものをヒアリングする、別のメンバーから聞く、などの方法がある。
マネージャはなんらかの意思決定者・責任者であることが多く、放っておいても多方面から話がきやすい構造になっているのでミーティングが増えやすいというものがある。 そういう状況を考慮すると、チームを前に進めるために常に自分がいなければいない状況をなるべく少なくするほうが利口だと思うだろう。
1on1 では驚くほど多くのことを知ることができるな、というのが今複数チームをマネジメントをしていて思ったことだった。 ましてや僕は今片方のチームでは"落下傘マネージャ" = そのチームにメンバーとしての期間を経ずにいきなりマネージャになった身であり、現場の情報を把握する数少ない、確かな情報源の1つであった。
でも、ここで、1on1 でわかるから十分だな、と一瞬なりそうになったのだが、やっぱりそれでは良くないな、と思い直すことになった。
1つは、1on1 の時間の使い方について。 このような使い方だと「マネージャの情報収集のため」が第1目的になる。さらに現場にいないのであれば報告する情報量も増え、メンバーにとっては下手すると「業務報告」の場になりかねない。 別にそういうマネジメントスタイルが良くないわけではない。1on1 を頻度高くやっているのであればそれでもいいのかもしれない。 僕の場合は複数チームのマネージャをやっていることでミーティングの時間が物理限界になっていることもあり、1on1 は直属のメンバーでも基本的には隔週としている。 隔週の1on1で業務報告で終わるのはイマイチだと僕は思う。1on1 はメンバーのための時間である。
マネジメントや 1on1 への期待値を話した時、あるメンバーから「業務の共有よりは技術の深い話をしたい」ということを言ってもらった。 1on1 への期待値は人によって違って良いのだが、業務報告よりは〜という需要はあるのだな、と思い、1on1 に情報収集を頼りすぎてはダメだ、と思った。
もう1つは、必ずしも全ての人が 1on1 で正しい情報を届けられるとは限らないということ。 「業務報告」スタイルを取っていたとして、その情報が過不足ないかどうかはわからない。 戦略策定や組織課題の把握、人事評価のインプットに足りうる情報が揃うのかどうか、それを正しく言語化できるのかどうか、そもそも伝えてくれるかどうか、というのは人による。
現場にいるからこそできる 1on1 での会話というものもある。 実際僕はチームのスクラムセレモニーだったり、チームミーティングのほとんどに出るようにしている。（細かい技術的な会話はもちろんメンバーに任せているが） そこで見えるもの、あった出来事をもとに会話を深めて行けるように思う。
現場に出るにも、頻度高く1on1するのも、どちらも同じ「時間の割り当て」 = マネジメントであるから、どの選択をするかそれ自体からマネージャの仕事であり技術である。 今のところ僕はそれをどちらかに極端に振らず、出るミーティング、出ないミーティングの期待値を合わせながら、1on1 を適切な間隔で行うことで、1ヶ月と少し経った今なんとかやっていけていると思う。
いよいよ残るは「技術」である。エンジニアリングマネージャなのだから、ピープルマネジメントは上記のようにできたとして、エンジニアリングをマネジメントするには技術に習熟する必要がある。 期初のマネジメント(9月〜プロダクトの背景、組織の状況把握 / 10月〜戦略策定、メンバーとの関係構築 / 11月〜 ミッション策定)を経て、ようやくソースコードを読み始めることができてきた。 技術課題を正しく理解し、正しく解決できるようにするには伸びしろしかない。別の分野を深く知ることは今回チャレンジしたかったことの1つなので、今すごく前向きな気持ちでいる。
