シンプルなチームへの権限委譲

プロジェクトでも定常的な業務でも『組織・チーム』という人の集まりを作り、各人に役割を負わせるとき、権限を分担する。最近では、管理職のいない組織づくりで上手くやっているというケースも一部ではあるようだが、これは、権限を持つロールに属する人を複数にしているだけの話で、従来の形態の亜種だと理解すると上手な制度設計の1つのパターンだと受け止められる。

古式ゆかしい、旧態的で伝統的な組織であれば、権限を持つ役割は通常1名で不在には代理設定するように設計しているものだ。権限を持つ人を複数置かず1名としておくのは権限=責任の所在を明示的にするためであって、そうした要求に基づくか単になんとなくそうしているだけの理由に過ぎない。他の要件、例えば意思決定を昼夜行う必要があるのであれば複数体制を取るか切れ目なくできるように制度を設計するだろう。

身近なチーム内での権限委譲はどう考えればいいのだろうか。最近、権限委譲を7つのレイヤーで表現したスライドを見かけたような気がするのだが、そこまで細分化が必要なのだろうかという印象しか残っていない。自分としては(先の7段階の権限委譲のような)細分化し過ぎる考え方は、運用に耐えないと経験的というか自分の性格的に判断している。今は2番目の段階だから、次は3番目に…などやってられない。権限は委譲するか委譲しないかの2択で十分だ。

ではどのように委譲するかしないかを決めれば良いか。それはright personに権限を持たせると決めておけば良い。プロジェクトチームなら、チーム内で一番専門性を発揮するメンバにそのメンバが担う権限を委譲するということである。システムデザインはアーキテクトに意思決定する権限を付与すれば良い(明示的にする必要があるのかは差し置いて)し、実装はメンバに判断してもらえばいい(レビューはあるとしても)。

通常の業務での役職の意思決定で違和感を覚えるのは、案件の判断を行う役割の管理職がその案件の専門性を持っていないのに(ろくに勉強もせず)自力で判断するときである。専門家を引っ張り込んだ上で(専門家の意見を尊重して)判断するのであれば、right personが意思決定に十分な影響を与えていることになるので問題がないが、知識もないのに判断されてはたまったものではない。

エンジニアが権限から違和感を覚えるのは、こうしたケースもあるし、プロジェクトでももちろん起きる。でも、権限における違和感、不条理の原因の構造は組織の構造で起きる原因と同じである。であるから、ストレスのないチームでの権限委譲は、

  • right personであるか
  • right personを適切なロールに置いているか
  • right personはロールにふさわしい資質を持っているか

で行えばいい。

あとは、そうした役割を一部でも経験年数が少ないうちからそれこそ委譲し、慣れさせる機会を作ることも大事である。

 

 

The Right Person

The Right Person