チームを自律させた次に目指す先は変動組織へ

エンジニアのチーム運営は、プロジェクトマネージャやマネージャのトップダウン的な指示からチームに権限をデレゲート、つまり、権限移譲することで裁量を増やしてチームが自立し、さらに自律へステップアップする方向に遷移するのが当面の目標だと思うのです。

意思決定の判断基準は文化である

現実には、指示命令系が強い組織では、指示され、確実に作業の成果を報告することが行動する際の判断基準になっており、それが定着して空気のような文化になっていることが多いのです。そのような文化にいきなりチームに権限移譲して、チームを自律さえて運営してね、というのがどれだけカルチャーショックかは、想像できるのではないでしょうか。つまり、自立させて、さらに自律、自らを律するためには、行動の価値判断基準を総取っ替えが必要なのだ、ということです。

全面展開しない

権限移譲されたことがないチームにいきなり権限移譲をしてもチームは今までやってきたことがないので経験値を持っていません。ここを理解しないで組織にビックバン的に一斉展開するとなんでも一緒で確実に失敗してしまいます。

小さく、限定的に始めて成功体験を1つのチームに得させることが最初のポイントです。その上で、組織内にフォロワーを作ることから徐々に展開を進めることが必要です。その際には、最初のチームが後からついてくるチームの相談相手になると良いです。

自律したチームが次に目指すのは

チームは自律して活動をできるようになるということは、チームの目標を自ら設定し、マネージャに修正されること（はほぼ）なく、チームが担うビジネスを回すことができるモードに入っている状態です。

自律したチームが目指す先、ステージはどこなのでしょうか。

エンジニアの性として対象のオブジェクトはスケールアウトしたくなるものです。１チームで自律出来るようになったら、2つのチームを自律したい。それの表れは、上述の先行する１番目のチームがフォロワーのチームの相談相手になる、という考え方です。

アメーバでも有機的でもない次へ

このスケールアウトしたいというのはどこにそうしたいと思う要因があるのでしょうか。心理的に大規模プロジェクトを想定しているのだと思うのです。複数のチームで複数のサブシステムを開発するプロジェクトを指示命令型や調整型で経験しているともう少し上手に、トラブルを少なくやりたい、と。

メンバが自律してチームを自律させる。だったら、スケールさせて、チームを自律させて複数のチーム（ズ）を1つの個体として自律させる。

これ、アメーバ経営に近い考え方のような気がしますが、（直接的に）経営をしたいわけではないのでちょっと違うと思うのです。

有機的組織かといえば定義が今ひとつ曖昧なので言葉の意味合いだけでいえば、変動組織運営なのかもしれません。