なぜエンジニアリングマネージャー含む全マネージャーが権限委譲に苦しむのかを２０年間考え続けてどう組織を再設計およびエンジニアリングしたかの方法まとめ【前編：苦悩分析編】

本記事はEngineering Manager Advent Calendar 25日目の投稿です。

エンジニアリングマネージャーの心の叫び

（エンジニアリングマネージャーは大変だぁぁ！！！）
（マネージャーは大変だぁぁぁ！）

ゆめみ代表として、創業から２０年間経営に関わる中で、開発組織のマネージャーの心の叫びを見過ごしていると、３回連続マネージャーが心折れて辞任（会社の退職はせず部長職をギブアップ辞任）して、兼務部長に戻る事を繰り返してきた「片岡」と言います。

じゃあ、マネージャーの苦労を一切、自分が引き受けよう！と頑張っても、その自分もマネージメントの役割を担うマネージャーの一人な訳で、これは永遠に解決しない問題なのかなと開き直る事も。

そして、４回目としてマネージャーがギブアップしそうになったのを受けて

突如として、２０１８年１０月１日に「アジャイル組織宣言」というものを行い、いわゆるティール組織の自主経営を参考にして、組織全体の自己組織化を目指す形になりました。

その後、１年経過して、過去の苦悩を振り返ってみた時に感じた事は

（なるほどぉぉ、ココに「もがき苦しんで」いたのかぁ。。。）

と、外から見る事で「別の景色」が見えたという事でした。

・ティール組織？ただの理想でしょ？

・ゆめみは突拍子もない制度あるけど、実態は違うんでしょ？

そんな誤解や偏見もあるかもしれないので、今回は

前編：権限委譲についての苦悩分析編

後編：ティール組織における問題解法とエンジニアリング手法編

と記事を２回に分ける事で、ティール組織への理解不足や、ゆめみならではの組織エンジニアリング手法という例外性と「権限委譲についての苦悩分析」を切り分けて記事を投稿しました。

前編だけでも、ある程度完結した内容になっていますが、後編も興味あればご覧ください！

そんなこんなで、まずは前編：権限委譲についての苦悩分析編です。

下記の組織図からどういった組織設計が読み取れるか想像して見てください

一般的な組織図は上記のように箱と線から構成されます。

箱は組織のユニット（部署・チームなど）を示し、線はコミュニケーションパスを示します。

ユニットには職務・責務範囲などが規定され、人員が配置されます。

人員の中から、ユニットにおける責任者が選ばれ権限が付与されます。

責任者が自分の権限を超える範囲の意思決定を行う場合は、上位のユニットに対してエスカレーションが行われ、承認を得る必要があります。

この説明は、従来型の階層組織における組織管理の手法を説明したものであり、簡易的に図式化すると下記のようになります。

最初の組織図を上記のように解釈する一般性は、組織において人が規律を持って動くには必要な事だと思います。

一方で、外部環境の不確実性が高い状況においては、上記の組織設計を基本として、組織運営をする場合、エンジニアリングマネージャーを含むマネージャーに負担が大きくなるという事を述べたいと思います。

組織分割

まず冒頭の組織における箱、つまりユニットに着目してみましょう。ここにマネージャーの苦悩の要因があるのでしょうか？

一般的に、組織は、明確な境界で外部から識別される単位で分割されます。

組織は部分としての単位になぜ分けられるのでしょうか？

その根本的な目的は、「コミュニケーションの複雑性を減らす」ためです。

背景としては、組織を構成する人員が増えるたびに、コミュニケーション量は非常に大きくなるからです。

例えば、上図のように組織の人数が５人から７人に増える事でコミュニケーションのパスは２倍に、５名から１０名に増える事で、４.５倍に増えます。

一般的には、上限を７〜１０名に抑えるのが良いとされています。

拠点が離れているなど物理的な距離が離れている場合も、密なコミュニケーションが必要な場合は、組織が分割される事に繋がります。

組織分割として垂直的な分割と水平的な分割を例に挙げます。

水平的分割

組織の人数が増えてくると上記のように組織内でのコミュニケーションパスが増大するため、組織を分割します。

例えば、職能毎の組織の場合は、組織同士については分割後も協調する関係が保たれるために、組織の間には序列は存在せず、同格的な位置付けとなります。

垂直的分割

上図のように、上位の目的を達成するための手段を連鎖的に分解しながら、組織を分割していく方法です。

例えば、Vision->Strategy->Tacticsのように抽象レベルが異なるものについては、必要となる情報の粒度や思考プロセスも異なるため、同じ組織で行うには複雑性が高いため、分割する事でコミュニケーションの複雑性を取り除きます。

つまり、組織分割は「コミュニケーションの複雑性を減らす」事が目的であり、マネージャーの苦悩を生み出す要因にはならず、むしろマネジメントを行う為に必要なアプローチと言えます。

一見すると垂直的に分割することは階層を現している為、組織の階層はだめだ！フラット組織であるべきだ！という主張から問題視されるかもしれません。

しかしながら、実際に、ティール組織においても、このような組織分割は必要であり、適切に行われる必要があります。

では、次の箱同士の関係性に着目します。

権限の入れ子構造

下図の左のように典型的な開発組織の場合、垂直的に分割されています。
その場合の「権限構造」はどうなっているかと言えば、下図の右のように「入れ子構造」になっています。

入れ子構造とはどういうものでしょうか。

例えば、上図において、開発本部長の権限は開発本部の全ての業務範囲に及んでいます。同時に、開発部長は、開発部の全ての業務範囲の権限を持ち、課長は課の業務範囲での権限を持ちます。

このように、入れ子構造とは、組織分割が行われる際に、権限が及ぶ範囲が重なり合ったままで権限が付与される構造を意味します。

上図において、開発本部長はいざとなれば、権限を行使して課の方針についても変更する事ができるように、入れ子構造においては、上位の組織の権限が下位の組織の権限よりも優先される事を意味します。

つまり、下位の組織は、自らの権限範囲内であっても、その意思決定プロセスは画一的には規定されません。

課長は自らの権限を超える意思決定を行う場合は、エスカレーションして、部長の承認を得る必要があるように、入れ子構造において、下位の組織が自らの権限範囲を超える意思決定を行う際に必要な意思決定プロセスは、「承認プロセス」と呼ばれ、画一的に規定されます。

つまり、箱同士の関係性としては

権限構造：「入れ子構造」
権限範囲を超える場合の意思決定プロセス：「承認プロセス」
権限範囲内での意思決定プロセス：「画一的には規定されず」

が組織分割される時点で半ば自動的に「初期設定」として規定されます。

ココが重要なポイントなのですが、この「初期設定」に対して

「それは、おかしいだろ！！！」

と異論を唱える事なく、従来の組織では、当たり前のものとして受け入れられているという事です。（後で整理して分析します）

この前提で、階層が深くなる中で、下位の組織が、自らの権限範囲を大きく超える意思決定をする場合は、エスカレーションが何層にも渡ってしまう為、意思決定の迅速さが失われます。

その場合の解決方法として、階層のいずれかの段階で「権限委譲」というものが行われることになります。

権限委譲について

権限委譲（Empowerment）とは一体どういうものでしょうか。

権限委譲とは、権限を持つものが目標を達成する為に、組織の人員に権限を分け与える事を指します。

その実際のところは、権限委譲に伴って、組織分割後の初期設定である「入れ子構造」の権限構造および意思決定プロセスが変化する事になります。

例で説明をしてみます。

上記のように開発本部長は明示的に権限委譲を行う事で、入れ子構造ではなく、権限が分散される分散構造に変化します。

つまり「任せた！」という意思決定をもって、開発本部長は開発部の業務範囲の権限を自ら失い、開発部長に委ねることになります。（ただし、何かのきっかけで、権限委譲が解除されると元に戻ります）

権限を委譲する目的は、例えば、開発本部長は本部の戦略・方針などを決め、開発部長は戦略・方針に基づいた計画・実行を行うといった役割分担をお互いが自律的に実行する事です。

一方で、自らの権限を超える意思決定を開発部長が行う場合は、引き続きエスカレーションが必要であり、それは「承認プロセス」で実行されます。

この時点では

権限構造：分散構造
権限範囲を超える場合の意思決定プロセス：承認プロセス

となっています。

問題は、権限構造が「入れ子構造」だった時に

権限範囲内での意思決定プロセス：「画一的には規定されず」

として、比較的曖昧で規定されていなかった部分の意思決定プロセスに変化が生じます。

この「意思決定プロセスの変化」が、エンジニアリングマネージャー含めたマネージャーが権限委譲において苦労する要因に繋がります。

それを説明する為に、以下の３つの課題についてまとめます

①権限委譲レベル設定の曖昧さや、一貫性のなさ
②権限委譲を明確に行なっても、権威勾配が残る
③権威勾配への認知の非対称性が存在する

①権限委譲設定について

下記はManagement3.0で紹介されている権限委譲レベルです。ディリゲーションポーカーと呼ばれるワークショップを通じて、権限委譲の明確化の重要性を理解する効果があります。

その中で、権限委譲には７つのレベルがあるとされていますが、権限委譲をより詳細に明確化されている為、これを用いて説明します。

これまで説明してきたように、自らの権限範囲を超える意思決定を行う場合は、上記の７レベルの段階で言えば、「レベル４」の承認プロセスで行なわれます。

入れ子構造の権限構造においては、下位組織は自らの権限範囲内において、普段は、レベル７のように完全に自らが意思決定していたとしても、突然、レベル１のように上位組織からの命令によって意思決定される事もあります。

ところが、「分散構造」の権限構造においては、下位組織は、自らの権限範囲内においては、レベル５〜７の範囲で意思決定を行うことになります。

この際に発生する問題は「レベル設定の曖昧さ」です

対象となる意思決定事項に対してレベル５〜７のどのプロセスを採用するかのルールが曖昧になりがち

というものです。入れ子構造の時から、様々なレベルのプロセスを採用してきた為に、曖昧なままになりがちです。

「任せた！」というものであっても、レベル５〜７のようにやり方には差異がある為混乱が起きやすいです。

あるいは、Aという事項はレベル５、Bという事項はレベル６、Cという事項はレベル７などと細かく設定しすぎても、上司・部下の間でルールを守る運用難易度が高くて、一貫した運用ができないケースが多いです。

以上が１つ目の課題です。

②権限委譲を明確に行なっても、権威は残る

次に、仮に権限委譲のレベル設計を明確に行い、上司・部下が一貫した運用を行なったとしても、「権威」というものは無くならないです。

ここで、「権限」と「権威」を下記のように区別して改めて定義します。
（※英語では権限も権威もauthorityと同じ言葉で示されますが、明示的に区別する場合はformal vs informal authorityとして区別されます。ここでは、権限と権威という日本語の違いに対応させて定義します）

「権限」は公式に規定され、任命される事によって与えられる力となり、これまで説明したように権限委譲が可能なものとなります。

一方で、権威は委譲ができない、その人に紐づく暗黙的、非公式に人が従うものとして働く力としています。

そして、権限と権威を合わせて「権力」と定義します。

リーダーシップも権威の一つですが、例えば、必ずしも尊敬を受けてはいないが、組織の歴史的経緯上従うべきものとして働く力も含めて幅広く「権威」と定義しています。

つまり、権限委譲が実施されたとしても、権威は引き続き残るという事になります。

これが２つ目の課題です。

③権威勾配への認知の非対称性が存在する

最後の課題ですが、２者間における権威の差がある場合に、権威勾配（authority gradient）があると言います。

権威勾配が大きい場合には、医療や航空現場の文脈において「事故」に繋がりやすいという事例を引用して、心理的安全性の欠如の文脈で使用される言葉です。

ここでの権威勾配の場合は、２者間の「権力」によって生じる従うべきと感じる圧力差となります。極端に言えば、部下がめちゃくちゃ権威をもろともしない打たれ強さを経験としてもつ場合は、２者間の権威勾配は小さくなります。

権威勾配は必然的に発生するものであり、無理にそれを無くそうとして、リーダーが部下を甘やかせたり、温情主義をするべきでは無いとされています。

重要なのは、権威勾配があるという認知を当事者同士が認知する事ですが、下記の例のように上司・部下の間で、権威勾配に対しての認知の非対称性がある場合に問題が起きやすいです。

つまり、上司の視点としては、「権限委譲」を行なって任せたからには、部下からは、何かあれば相談や異論を挟む事もあると期待するとします。

一方で、部下からの視点としては、上司に対しては、権威勾配があるため、依然として相談や異論を唱える事が行い難いという状況を生み出します。

事態がいよいよ大変になった場合に、部下からお手上げモードの相談が上司にあって初めて「もっと早く言ってよーーー！（上司）」という事になりかねません。

この３点の課題を認識した上で、いくつか権限委譲が進まない難しさを示すパターン例を挙げます。

権限委譲が進まない難しさのパターン例

権限移譲レベル５：助言する

上記の場合は、部下が上司に事前に相談をして、上司が助言をした上で部下が決めるというプロセスです。

もともと様々なレベルで進めていたところから、「任せるぞ！」という事で、レベル５「助言する」として、権限委譲をする場合に発生する権限委譲の難しさについて述べています。

承認プロセスにこれまで慣れてきた経緯に加えて、人事評価や権威勾配が影響して、結局、部下が相談をするものの、上司がお墨付きの助言をする中でしか、部下は自らの意思決定を行わないというパターンです。

実質的に、上司が意思決定を行なっている「承認プロセス」を意味し、権限委譲が一向に進まないという難しさに繋がります。

権限委譲レベル６：尋ねる

このパターンでは、例が少し極端かもしれませんが、上司のコミュニケーションが下手くそな場合に、問題が起きる事について述べています。

上司  「任せた！（ただし、何かあったら尋ねるぞ）」

と始めたものの、部下としては「（なんだよ、、、結局、こまめに相談してお伺い立てないといけないじゃないか・・・）」となります。

結局、レベル５「助言する」に戻るなど、権限委譲が進まない難しさが起こり得ます。

ひどい場合は、上司がさらに追い討ちをかけて

上司　「任せたんだから、いちいち、相談しに来るなよ！」

と態度を急変されると、部下は「勝手に進めたらダメ、相談してもダメ」というダブルバインドと呼ばれる心的状態になり、場合によっては精神的に参ってしまいます。。

権限委譲レベル７：移譲

日本語では、「移譲」として「移す」という言葉で表現されますが、「完全委譲」という事で、定期的な報告が規定される事はあっても、意思決定については、完全に任されることになります。

ここでの難しさは、上司は完全に任せるスタンスになるので、例えば、部下が所属する部署のSlackチャネルに上司が参加したり、部署の定例会議に上司が参加するといった、上司による現場の状況観察が難しくなることです。

何故ならば、権威は残るため、上司がSlackチャネルや定例会議に参加する事で、部下はチェックされているように感じて、その行動を回避しようとしたり、上司もそれを気遣い、見ないようにするためです。

その場合、本来は上司が観察していれば、問題を回避するためのアドバイスを行う事が出来たはずが、部下も上司への相談が不要なため、気づかないまま事態は進み問題が発生するという事がおきます。

部下からの定期報告の中で上司が気づく仕組みを構築する必要がありますが、状況変化が激しい場合は、それも難しいです。

部下によっては、任せたからには、何とか自分で乗り切らないといけないという責任感が強い場合は、部下が問題を問題と気づいている場合でも、それを報告するのが遅れてしまう場合もあるでしょう。

その結果としては、レベル７ではなく、レベル５、６に戻るなど、なかなか権限委譲が進まない難しさが起こり得ます。

以上のように「権限委譲が進まない難しさ」というパターンを示しましたが、マネージメントの現場では、相手も様々ですし、状況はもっと複雑であり、色々と苦悩するパターンがあると思います。

ところで、かの松下幸之助氏が『まかせてまかせず』という言葉を残しています。

「まかせてはいるけれども、たえず頭の中で気になっている。そこでときに報告を求め、問題がある場合には、適切な助言や指示をしていく。それが経営者のあるべき姿だと思います。これは言いかえますと、『まかせてまかせず』ということになると思います。まかせてまかせずというのは、文字どおり『まかせた』のであって、決して放り出したのではないということです。」（松下幸之助）

まさに、人材育成の極意だと思いますが、ここまでの例で示したように、容易ではないからこそ、マネージャーが苦労する所以だと思います。

意見①：「それがマネージャーの仕事だ！」
意見②：「何とかする！というのがマネジメントの役割だ！」

という意見は当然だと思いますし、権限委譲に苦労しているマネージャーの努力は賞賛に値すると思います。

さて、ここまでの流れを踏まえて「従来組織の権限委譲」を整理すると以下のようになります。

「まかせてまかさず」は、ここで言う「権限委譲後の対応」であり、「適切なコミュニケーションに苦労する」と捉えることもできます。

例えて言うならば、「ぐるぐる回された」後に、「ディフェンスとゴールキーパーがいる中でのシュートを決める」という難題に挑戦するようなものです。

１つ１つの課題がクリアできたとしても、組み合わせる事で難題になります。

つまり、「承認プロセスにガンガン慣れさせられた」後に、「人事評価と権威勾配がある中で、自ら意思決定しろ」という難題に挑戦するという事を部下は強いられています。

一方で、マネージャーは部下が難題に挑戦するように、さらに上のマネージャーから強いられています。

特に、不確実性が高くなる時代において、ここでの問題設定はより難しくなっているように思えます。

マネージャーが苦悩する「人事評価」についても同じような構造があると考えています。

つまり、「入社時にえいや！と適当に給与が決まった」後に、「納得性、公平性を維持した上で、給与変更を適正に決めよ」という難題にマネージャーは挑戦を強いられています。

以上が、前編：権限委譲についての苦悩分析編でした。

後編では、このように、わざわざ問題を難しく設定して「難題」に挑戦するのではなく、問題設定を見直す解法について解説します。