読者です 読者をやめる 読者になる 読者になる

全ての作業にリーダの許可が必要なチームのパフォーマンスは低下する

 などつぶやいているわけです。はい。

どうして、と思った方は騙されて読んでみましょう。そうだよね、と思った方もそうだよねが同じかどうか読んで確かめましょう。

リーダの責任と権限の範囲

チームで作業をしていると、チームのリーダ、プロジェクトならプロジェクトマネージャがリーダに当たりますが、担当している作業で起きることについてはリーダが責任を負います。そのチームの運営形態に関わらず、リーダの上司から見ればチームの責任の代わりにチーム内の権限を委譲しているわけです。

作業の判断

チームの権限をリーダに委譲されているなら、チームにおける「最終」判断はリーダに付与されていることになります。

それはそうですよね、チームの責任を負っているのですから。

ただ、一つのタスクを完了させるためには複数の作業、つまり、プロセスを経て完了することが必要ですから多段的な判断が存在することになります。

例えば、基本設計では

・情報収集→執筆→セルフレビュー→内部レビュー→外部レビュー

が標準的なプロセスとすると、5つのプロセスごとに誰かが次のプロセスに遷移して良いかを判断していることなります。

情報収集では、

・執筆のためのインプットとなる情報の範囲は明確か
・収集する情報量は適当か

の判断が必要です。

誰が判断するか

では、その情報収集の作業の判断を誰がするのかと問われると誰がするのでしょうか。

明示的に示さなければ担当するメンバがするものだ、と思っても間違いではなさそうです。でもチームの中の他に判断するメンバがいるかどうかを探してみると少なくとももう一人、候補者がいることがわかります。そう、リーダです。なぜなら最終的な責任を負うのはリーダだから。

なぜリーダが出てくるか

 

情報収集の作業は5つのプロセスで構成されています。そのうち、リーダが介在するプロセスは内部レビューです。どうしてかはわかりますか。そう、チームとして外部に出して良いという判断のジャッジをする最終ゲートだからです。

・情報収集→執筆→セルフレビュー→内部レビュー→外部レビュー

ところで、内部レビューで指摘することは執筆で生じたことだけでしょうか。「てにをは」であればそうでしょう。

でも、本来執筆すべき対象範囲を過小としていり、範囲が違った場合はどうでしょうか。それも内部レビューで指摘していれば、情報収集のプロセスもリーダが関与することになります。

判断することを誰が決めるか

では、作業のプロセスの判断を全てリーダがするのかといえば、それは

・リーダのプロセス設計次第

になります。なぜかって、それはリーダが上司から権限移譲とともに責任を負わされているからです。

とするなら、リーダが付与された責任を取れるためにプロセスをどう設計するかにかかっていることになります。

チームのメンバを信頼するなら5つのプロセスのうち、最終判断以外はメンバに権限移譲するかもしれません。でも、最終責任を負うことの担保をリーダ自ら行うことで担保したいなら、全ての作業の判断はリーダが行うことになります。

リーダはチームに必要なスキルを全て持っているか

全ての作業の判断をリーダが関与するのであれば、チームのパフォーマンスは落ちます。

どうしてか。それは、チームの活動全てにおいてメンバよりリーダが優れているということはないからです。

チーム、特にプロジェクトではプロジェクトとしての目的を達成するために必要なスキルセットをチームとして構成するようにメンバをチーミングします。プロジェクトとして必要となるスキルセットを全て持ったメンバを人数分調達する、ということではありません。

であるならば、リーダを含めてチームのメンバは得意なスキルを持っているけれど、そうでないスキルもある、ということになります。

それはリーダも同じです。

全ての作業にリーダが判断するとチームのパフォーマンスが低下する

リーダは役割としてチームの最終判断をせざるを得ないけれど、リーダでさえ得手不得手があるわけで、作業プロセスの判断は他に得意なメンバが判断した方が適切なことがあり得るのは容易に想定できるわけです。

ということは専門性を持っていない分野においてリーダが判断すると

・判断自体を誤る

ってもおかしくはないですし、それは現場で日々起きていることです。

あと、全ての作業をリーダが判断するということはそれだけ判断にリーダのリソースを消費するということの裏返しでもあります。枝葉末節のプロセスに重きを置き、全体をリーダとして見るリソースがショートする自体を自ら運営する制度として作り上げているということになるのです。

期待と権限を移譲する

解消するには、部分的なプロセスの権限移譲と合わせて移譲する範囲での期待、つまり貢献を明示的に示すことでできるようになります。

ポイントなのは、期待を先に示すということです。これをしないと何も変わらずに責任だけを押し付けることになります。