30人くらいの組織でセルフマネジメントしていた話

ここ数年、ウォーターフォールでない、つまりアジャイル開発系界隈で組織的なテーマが（観測範囲では）話題となっているような気がしていて、組織化を意識するほどのビジネスボリュームが出てきた証左かなと思ったりしているわけです。

ある時期、30人くらいの組織の責任者だったとき、ビジネスの形態もあって少人数のプロジェクトチームを複数並行で動かしながら考えていたことがもしかすると参考になるかもしれないと思っているのですが、それは読み手にお任せするとして。

フラットな組織

所属する組織の制度的には多分、組織図に掲載する複数の公式なチームに分割することができました。イメージしやすくするために仮の話をすれば人数的に3チームぐらいかもしれません。

もし3つのチームにしたらどうなるか。責任者があと2人増えることになります。組織のビジネスがそれでやっていけるならいいのですが、2人分のコストをただ増やすなんて馬鹿らしいと思ったんですね、当時は。

それで上申して1つのチームに併合したんです。確かに当時はフラットな組織が流行っていて組織のフラット化の流れがあり、部下なし課長、部長などのなんちゃって管理職という問題もありましたが、こちらとしてはフラットな組織の意思決定の速さをもしかしたら適当に理由の一つにしていたかもしれませんが、ビジネスのコストを軽くすることの方が優先順位が高かったですね。

セルフマネジメントのチーム

責任者としての管理スパンが増えるのでマイクロマネジメントなんてしようとは思いませんし物理的にしようと思ってもできません。リソースは有限なので。

そこで、プロジェクトごとのチームを作るときに実績に応じてデレゲートするわけです。こちらとしてはリソースをリスクの高そうなプロジェクトに集中したいというニーズはあるし、ベテランで任せておけるだけの信頼に値するリーダは関与しなくていいよと思っているので、関与の度合いを下げることは立場的な思いは違うけれど合意するポイントは同じなんですね。なので任せた、任せられたと言えるわけです。

でも全くのノーコントロールかといえばそんなことはしないです。こちらがきになるところはずっとモニタリングしているんです。そうですね、レポートの端に現れる雑さを見るというか。手が回っていないところはリーダの優先順位が下がっていると判断してそこだけ見ている感じです。それを意識的にリーダがしていれば受け流すし、カバー漏れならケアしておいてねーとメッセージを伝えればいいだけです。

こうして濃淡をつけることでリーダとそのチームが自律的に自主的に動ける裁量をバーンと渡してしまうことでセルフマネジメントが働くようになります。

本当のセルフマネジメントチームかといえばそうではないかもしれないですけど、本当かどうかなんて答えはないし、組織構造に現れる管理の細かさでそうしたところの良し悪しも変わってくると思います。

大事なことは、自分の頭を使って考えて行動して結果を出してもらうことです。それがエンジニアの評価につながるのですから。

あと、自分がいなくなったら（バスに轢かれたとか異動したとか）になったときにはよろしくね、とリーダたちにはよく言っていましたね。先も考えて、と。