1 on 1をベースとした組織構造の提案

こんにちは!id:unlearned です。

今年は寒いですね。 暖冬説はなんだったのかと思っているのですが、四季があるのは好きです。

さて、この記事は、Engineering Manager vol.2 Advent Calendar 2018 の20日目の記事です。

1 on 1っていいよね。

ドラッカー曰く、

マネージャーを見分ける基準は命令するする権限ではない。貢献する責任である。
権限ではなく、責任がマネージャーを見分ける基準である。

さて、僕は1 on 1好きです。 1 on 1をやることで、信頼感を醸成できますし、みんなとキャリアについて相談できます。 また、ボトムアップのアイディアも吸い上げできますし、本当に良い。

すべての仕事は人間がやっています。 僕は、1 on 1が仕事に人間性を取り戻し、職場が活気づくなんともROI(Return On Investment:投資利益率)が良い施策だと考えています。

僕の職場でも、「1 on 1はチームに週一で1人30分程度でお願いします」という形にしています。

「1 on 1いいよね」だけじゃ収まらない問題

1 on 1はチームに変化がある時に効果を実感できると思います。 特にチームの人数が爆増してたりとかすると、チームビルディングの一環としてもとても良い。

一方で、1 on 1対象者が増えてくると、時間的な負担が出て来ます。 1 on 1のメンバーが10人ほどに増えると、1週間に5時間ほど、時間の確保が必要なります。これは週全体の労働時間の1/8に当たります。

1 on 1はROIが良いと思う反面、「人は1 on 1だけに生きるにあらず」です。

また、10人ものメンバーの話を聞くのは、実際にはかなりのエネルギーを消耗します。少なくとも僕は頭がパンパンになりますし、早く帰って眠りたい気分にはなります。

その上、10人もの人間を、人間は理解したり、そのために何かアクションが取ることができるでしょうか? 時に、「俺は何人の人間をマネジメントしてるぜ」と、担当する人間の数が多い自慢をするする方がいますが、現実には、1人あたりのメンバーのために費やす時間を薄く分配しているだけです。

機械的に問題解決もなく1 on 1することが、貢献と言えるでしょうか?

こいつは大変だ!

解決策

組織を考える時に、1 on 1対象メンバーが5人程度になるように、うまく配置/分割していくのが良いと思います。

なんで5人かというと、1日に1人と1 on 1をやるような感じです。

1日に1人と1 on 1ができるなら、1 on 1に全力で望めます。 加えて、一週間に1 on 1に使う基本的な時間も、2.5時間に抑えられます。 空いた時間で、ガンガン問題解決作業を行いましょう。

とはいえ問題

とはいえ、1 on 1を構造的に組織的に行うには、思いの外、問題がつきまといます。

まず第一に、今後1 on 1を他の人に任せることを、ちゃんとメンバーに伝えなければいけません。 また、そのことについて、納得してもらう必要があります。場合によっては、ひきつづき1 on 1を行い続ける誠実さも必要です。

二番目に、今後誰に1 on 1を任せていくのかは非常に重要な問題になります。しかしすでに、適切な1 on 1をされているのであれば、比較的スムーズに1 on 1を行うメンバーが見つけられるかもしれません。そういったメンバーがいた場合、しばらく、2 on 1形式を行うことで、スムーズに1 on 1に移行していくことができるでしょう。

三つ目として、組織が階層的になる可能性があります。 5人に絞るということは、5人のエンジニアリングマネージャーをさらに上位のエンジニアリングマネージャーがその5人と1on1を行うという形式になってしまいます。個人的に、これは非常に痛い。 対策としては、エンジニアリングマネージャーというのはあくまでも役割なのであって、偉さの階層ではないという認識を開発文化として浸透させる必要があるかと思います。

まとめ

  • 1 on 1ができる限界の人数をベースに組織を考えてみたよ
  • 1人のエンジニアリングマネージャーが1 on 1を行う人数って限界があるよね
  • 分割しましょう
  • 1 on 1の担当を引き継ぐ時には、ちゃんとみんなの納得感を得よう
  • 1 on 1を適切に行うことで、1 on 1を引き継ぐことが容易になります
  • 組織が階層化しないように気をつけよう

以上です。 わかりづらいので、あとで図を加えるかもしれません。

楽しく行こう!