冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

チームの学びに対してマネージャにできること、できないこと

先日、マネージャしててちょっと嬉しいことがありました。あることに対して「妥協せず、結果を反省する」ことができたということなんですけど、チームが遠慮せずに自信を持ってそれを実践したという意味で非常に大きな出来事でした。今回は、そこに至るまでの過程を思い返して感じたことをまとめてみます。

マネージャもチームの一員なので当事者意識というのは当然持っているんですけど、チームのすべてをコントロールできるわけではありません。当然会社内の役職の話の中で権限上できることというのはあるんですが、こと「チームの学び」については明確に「できること」と「できないこと」がわかれると思っています。マネージャがチームの成長をコントロールしようなんておこがましいとは思わんかね、という話です(本間丈太郎の口調で)。

できること

本当に微々たるものです。

  • きっかけを作ること
  • 結果、過程を評価すること
  • 環境を作るための雑用
  • 学びを共有する場の構築

促したり、気づきが多い場を作ったり、間接的なことがほとんどになります。環境を作る雑用は割と直接的ですが、社内の申請やサーバの準備など技術の本筋にはあまり関係のないところで、技術的な学びと解決はチームが試行錯誤するようにします。

メンバーが学びあうことが大事

また、個々の学びだけでなく、学びあうことも重要です。学びあいが多いチームはどうなるか。

まず、議論が多くなります。そして議論を通じてナレッジの共有が進み、ナレッジの共有を最適化するための議論が始まります。ここまでくればしめたものです。チームにとって一番良い形の学びに向けて勝手にまわりだします。

最初は、私から依頼して学びの部分を共有してもらったりしたのですが、最近はメンバーから共有が必要な内容のアピールが出てくるようになりました。私はそれをスケジューリングすることがメインです。

できないこと

大体がチームあっての話なので、できないことが多いです。

  • 行動の管理
  • 文化を創ること
  • 学びの内容を強制すること

つまり、マネージャがチームの状態や行動を自分の思う通りにコントロールしようということですね。やっても良いんですが、マネージャに超人的な能力を要求されます。チームの状態や行動をコントロールしてチームを動かすということは、学びと成果の責任が全てマネージャになるということで、マネージャの能力がチームの限界になります。

メンバーの成長実感がない

もう一つの問題は、こういうチームではメンバーが成長した実感を得られないことです。

私がそういうマネージャの下で働いていたときは、自分で試行錯誤しなくなりました。試行錯誤しない状態だとチームとして成果は上がっているのかもしれませんが、自分の失敗や成功とは感じないんですよね。

そういう思いもあって、なるべくマイクロマネジメントをしないように気をつけていたのですが、メンバーのスキルを過小評価してしまってチームに入ったこともあって、きっかけ作りとか伝えることとかやり過ぎているのかな、と思うこともありました。最近、ようやくやり過ぎを押さえられるようになってきたように思います。

まとめ

私は特に超人じゃないので、スキルセット的に得意なこともそうじゃないこともあります。また、チームの全ての仕事と学びに対してマネージャが責任を負うことは事実上不可能です。そのために様々なスキルセットを持ったメンバーが集まってチームを構成するわけです。せっかくチームを作って仕事をしているんですから、自分一人でやろうとするよりは、メンバーそれぞれがスキルを高いレベルで発揮できるようにしたほうが良いですよね?

自然にいろんなことができるようにきっかけは作っておく、一押しすれば転がりだす、というのが理想的なチームです。そのための準備として学び合う場を作ることがマネージャの役割の一つだと思っています。

ちょっと余談ですけど、チームには大抵一人は椎竹先生みたいな人がいるんですよね。こういう隠れた高スキルな人を見つけるとこういう場作りが楽になるので、メンバーのことは良く知っておきましょう。