「使えない人」を入れ替えても組織が回らない本当の理由──20年PMが見た構造のバグ、ポンコツは、絶滅しない

正直に言う。

私は長い間、組織の問題は「使えない人」だと思っていた。

判断が遅い人。
話が噛み合わない人。
言うことがころころ変わる人。

あの人さえいなければ、もっとうまく回るのに。
あの人が、ボトルネックなんだ。

そう信じて、二十年、現場を見てきた。

だが、不思議なことが起きた。

ある現場で、その「使えない人」が異動した。
これで回る、と思った。

回らなかった。

別の人が、新しいボトルネックになった。
構造は、何ひとつ変わらなかった。

そこで、ようやく気づいた。

問題は、特定の誰かではなかった。

ポンコツは、絶滅しない。

そして、絶滅しないことには、ちゃんと理由があったのである。

第一章　「ポンコツ」を、二つに切り分ける

結論を急ぐ前に、切り分けをしたい。

仕事ができない、と見える状態には、二種類ある。

ひとつは、本人の問題。
能力か、姿勢か、いずれにせよ、その人個人に由来する。

もうひとつは、構造の問題。
誰がそこに座っても、同じように機能不全を起こす。
役割の設計そのものに、無理がある。

この二つは、どちらも「あの人は使えない」という同じ言葉で語られる。

だから、ほとんどの人が、混同する。

構造のバグを、個人のせいにする。
役割設計の欠陥を、その人の人格の問題として処理する。

前者と後者では、打ち手がまるで違う。

本人の問題なら、配置を変えるか、育てるかだ。
構造の問題なら、人を入れ替えても解決しない。

そして、現場で起きていることの多くは、後者だ。

人を交換しても直らない不具合は、人の不具合ではない。

それは、構造の不具合である。

ところが、構造は目に見えない。
人は目に見える。

だから私たちは、見えるほうを、犯人にしてしまう。

第二章　課長という、単一障害点

二十年、現場を見てきて、最も壊れやすいポジションがある。

課長だ。

上から、数字を求められる。
下から、相談が上がってくる。
顧客から、要求が飛んでくる。
評価をし、育成をし、会議に出て、炎上を消す。

そして、権限は、たいして持っていない。

これを、システムで言えば、どうなるか。

あらゆる経路からのリクエストが、一点に集中している。
処理すべきトランザクションは膨大なのに、実行権限は限られている。

これは、典型的な単一障害点だ。

すべての負荷が、一人に集まる構造。
その一人が倒れれば、全体が止まる。

ここで、見落としがちな構造がある。

優秀な課長ほど、壊れる。

なぜか。

優秀だから、すべてのリクエストに、丁寧に応えようとする。
握りつぶさない。
全部、自分で処理しようとする。

その結果、処理能力を超えた負荷が、一身にかかる。
そして、ある日、落ちる。

これを見て、周りはこう言う。

あの人、急にダメになったね、と。

違う。

ダメになったのではない。

単一障害点に、設計通りの負荷がかかって、設計通りに落ちただけだ。

課長がポンコツになったのではない。

ポンコツになるように、役割が設計されていたのである。

そして部長になると、今度は別のシステムにつながる。

経営という、見えない上位システム。
会社の事情、政治、責任、数字。

若い頃、私は、険しい顔をした部長を見て、思っていた。
なぜ、あんな顔になるのだろう、と。

五十代になって、少しわかった。

あれは、性格ではなかった。
見えない負荷を、表情だけが、漏らしていたのだ。

第三章　ポンコツを前提に設計する

ここで、少し踏み込みたい。

では、ポンコツが絶滅しないなら、どうすればいいのか。

ひとつ、面白い事実がある。

コンサルやPMという仕事は、優秀な人だけを相手にする仕事ではない。

むしろ、逆だ。

話が噛み合わない。
判断が遅い。
優先順位がバラバラ。
人によって、言うことが違う。

そういう、不完全な人間の集まりを、それでも何とか前に進める。

それが、仕事の正体だ。

つまり、私たちの仕事は、ポンコツの存在を前提に、初めて成立している。

完璧な組織。
完璧な課長。
完璧な顧客。

そんな世界があったら、火消しも、調整も、構造化も、ほとんど要らない。

PMもコンサルも、仕事が激減する。

ポンコツがいるから、私たちの仕事がある。

これは、皮肉ではない。
設計思想だ。

ここで、三つの打ち手を整理しておきたい。

第一に、不具合を、人か構造かで分類すること。 誰かが機能していないと感じたとき、こう問う。 これは、その人個人の問題か。 それとも、誰がそこに座っても起きる問題か。 見分け方は、簡単だ。 その人を別の人に入れ替えたら、直るか。 直らないなら、それは構造のバグだ。 第二に、単一障害点をつくらないこと。
一人に負荷を集中させる設計は、必ず、いつか落ちる。
だから、冗長構成にする。
その人が休んでも、誰かが引き継げるようにしておく。
属人化は、平時には効率がいい。
だが、有事には、致命的だ。

第三に、ポンコツの自分にも、冗長構成を用意すること。
これが、いちばん大事だ。
人を責める前に、思い出す。
自分もまた、誰かから見れば、ポンコツである。
判断を誤る日もある。
噛み合わない日もある。
だから、自分にも予備を持つ。
一人で抱えず、引き継げる相手を、あらかじめ持っておく。

打ち手は、いずれも地味だ。
劇的な人材改革ではない。
ただの、不完全さを前提とした、構成設計である。

ポンコツの排除は、組織を強くするためにあるのではない。

そもそも、排除では、組織は強くならない。

第四章　ただし、何でも構造のせいにするな

ここまで読んで、こう思った人がいるかもしれない。

では、すべては構造の問題なのか。
個人には、何の責任もないのか。

そう単純ではない。

ここで二重否定を置きたい。

使えないと言われる人を、無能だと決めつけて責めるな。
その不具合の多くは、構造のバグであって、人格の欠陥ではない。

だが同時に、何でも構造のせいにできると、過信するな。

構造論は、便利すぎる。

すべてを構造のせいにすれば、誰の責任も問われない。
気が楽だ。

だが、世の中には、構造では説明しきれない人も、確かにいる。

理不尽な人。
無責任な人。
都合が悪くなると、逃げる人。

これらをすべて「構造の問題だから」と片づけると、振り回される側だけが、消耗する。

構造を見ることと、何でも許すことは、違う。

構造を見るのは、無駄に人を憎まないためだ。
泣き寝入りするためでは、ない。

だから、ここで三つの問いを置く。

ひとつ。
あなたが「あの人は使えない」と思うとき、それは本人の問題か。
それとも、誰がやっても無理な役割を、押しつけられているだけか。

ふたつ。
あなたは、構造を見ているのか。
それとも、構造を口実に、向き合うのを避けているのか。

みっつ。
あなた自身が「使えない」と思われているとき、それは本当にあなたの能力の問題か。
それとも、あなたが単一障害点に、座らされているだけではないか。

この三つ目が、効く。

私たちは、他人のポンコツには、すぐ気づく。
自分が座らされている、無理な構造には、なかなか気づけない。

最終章　思った以上に、優しい

ここまで、いかにポンコツと構造を切り分けるかを書いてきた。

最後に、少しだけ、構造から離れた話をしたい。

ポンコツは絶滅しない、という言葉を、私はずっと、少し冷めた目で眺めていた。

人間は不完全だ。
だから、組織には常に不具合がある。
だから、私の仕事はなくならない。

そういう、職業上の安心材料として、受け取っていた。

だが、五十代になって、この言葉が、少し違って聞こえるようになった。

ポンコツが絶滅しないということは、誰もが、いつか必ずポンコツになる、ということだ。

若い頃に優秀だった人も、いつか衰える。
今、誰かを「使えない」と評している自分も、いつか「使えない」と言われる側になる。

これは、悲しい話だろうか。

私は、そうは思わない。

むしろ、これほど公平な話はない。

完璧でなくていい、という許可が、最初から全員に与えられている。

あなたが今日、誰かのミスを許せば、いつかあなたのミスも、誰かが許してくれるかもしれない。

これは、計算ではない。
ただ、不完全な者同士が、なんとか一緒にやっていくための、暗黙のプロトコルだ。

二十年、現場を見てきて、最後に思うことがある。

人間は、思った以上に不完全で、思った以上に面倒で、そして、思った以上に優しい。

判断は遅いが、困っている同僚を、そっと手伝う人がいる。
話は噛み合わないが、新人の失敗を、黙ってかばう人がいる。

完璧ではないからこそ、人は、人に優しくできる。

完璧な人間ばかりの組織は、たぶん、冷たい。
互いの不完全さを補い合う必要が、ないからだ。

だから、ポンコツが絶滅しないこの世界を、私は、それほど悪くないと思っている。

使えない誰かに、苛立つ自分を、責めなくていい。

それは、あなたが冷たいからではない。
ただ、不具合の出どころを、まだ切り分けていないだけだ。

人を責めるより、構造を見る。

そうすれば、たいていの苛立ちは、少し和らぐ。

分からない相手のことは、分からないまま、抱えていけばいい。

ただ、その人を憎む前に、一度だけ問う。
これは、人の問題か。構造の問題か。

そして、自分もまた、誰かにとってのポンコツであることを、忘れないこと。

気合や根性で、不完全な人間は、なくならない。

構造として、不完全さを前提に、組織を設計する。

そうやって、互いのポンコツを少しずつ許し合いながら、優しいまま、壊れずにやっていけたら、それでいい。

完璧な勝者としてではなく、不完全なまま、長く居続けられる者として。

そしてポンコツもまた、絶滅しないのである。

組織の機能不全を特定の誰かの「ポンコツぶり」として片付けるのではなく、負荷が集中する役割やシステムという「構造のバグ」として見つめ直すこと。

人間誰もがいつかは不完全な存在になるという前提に立ち、不完全さをカバーし合える構成をあらかじめ設計しておくこと──それこそが、怒りや消耗を生まずに組織を長く動かし続けるための最も本質的な知恵なのです。

本稿は、いずれ書籍として構想している「人間を構造で読む」一連の記録の一篇である。仕事術ではなく、人間と組織を構造で読むための、ひとつの試みとして残しておきたい。

あわせて読みたい関連記事

部下をつぶすPMと育てるPM
https://note.com/quiet_emu2080/n/nb9663002771b

怒らない上司（無料）
https://note.com/quiet_emu2080/n/ne8ec973a6e19

PMが絶対に失敗するのはスキルじゃない
https://note.com/quiet_emu2080/n/n1b1110656a0c

AIを使い続けた3年間の正直な記録
https://note.com/quiet_emu2080/n/n8a9843349c9a

PMの心得——20年が教えてくれた、知識体系では学べないこと
https://note.com/quiet_emu2080/n/n2b23c914ea67

不毛な調整をスコープアウトする、現場の調停プロトコル
https://note.com/quiet_emu2080/n/n3a49f518e1d2

心理的デッドロックを回避する、個別プラグイン交渉術
https://note.com/quiet_emu2080/n/n5e84c129a0b1

炎上プロジェクトの救い方
https://note.com/quiet_emu2080/n/n79df96e24b41

PMという仕事は、誰も教えてくれない（全目次・無料）
https://note.com/quiet_emu2080/n/nc727b32351ab

現場PMの実践ノートマガジン
https://note.com/quiet_emu2080/m/mb3eda5b30688

指原莉乃×PM論
https://note.com/quiet_emu2080/m/m957be4f5d32b

エンタメ×PMマガジン
https://note.com/quiet_emu2080/m/mf01b3630a0da

キャリアマガジン
https://note.com/quiet_emu2080/m/mf96a1ab04ea6