もう限界かもしれない、と感じているあなたへ——20年PMが見てきた、優秀な人から静かに壊れる組織の仕様

プロローグ

正直に言う。

20年以上、

コンサルとPMの現場を這いつくばってきた人間として、

断言できることが一つある。

優秀な人から、

静かに壊れる。

これは綺麗事のキャリア論ではない。

精神論でもない。

組織のインセンティブ構造から、

必然として導き出される結論である。

私はこれまで、

数えきれないほどの「壊れていく人」を見てきた。

そして、

その人たちには、

ある共通点があった。

能力が低かったわけではない。

努力が足りなかったわけでもない。

むしろ逆である。

最も能力が高く、

最も責任感が強く、

最も優しかった人から、

順番に壊れていった。

なぜか。

理由は単純である。

組織の仕様が、

そういう設計になっているからだ。

本記事では、

その仕様を、

仕様書のように解体する。

「もっと頑張れば何とかなる」と、

すでに限界を超えそうになっている全ての人に、

冷徹なロジックという名の、

最大級の優しさを差し出したい。

本記事を含む一連の記事は、書籍化を視野に入れながら執筆を続けている。

第一章　疲弊した脳に発生する、二つのバグ

人が疲弊している時、

脳のメインメモリは枯渇している。

つまり、

複雑な情報を処理する余裕がない状態だ。

この状態で発生する典型的なバグが、

二つある。

第一のバグは、

「自分が悪いのか、会社が悪いのか」

という二択である。

第二のバグは、

「会社を辞めるか、このまま我慢するか」

という二択である。

どちらも、

一見すると合理的な問いに見える。

しかし実は、

これは認知の狭窄である。

専門用語で言えば、

「バイナリ思考」と呼ばれる典型的な認知エラーだ。

実際の現場は、

そんなに単純ではない。

少なくとも、

五つの変数が複雑に絡み合っている。

第一の変数は、

あなた自身のスキル。

第二の変数は、

案件の特性。

第三の変数は、

上司の資質。

第四の変数は、

顧客の成熟度。

第五の変数は、

会社のガバナンス。

これらが多次元的に絡み合った結果として、

「今のあなたの苦しさ」が発生している。

ところが疲弊した脳は、

この多変数システムを処理できない。

だから、

全ての責任を一つの変数に押し付ける。

その押し付け先が、

「自分の能力や精神力の不足」になる。

これが、

自爆の起点である。

優しく真面目な人ほど、

このバグを起こしやすい。

なぜなら、

「自分が悪いことにしておけば、

他人を責めなくて済む」

という、

優しさの暴走が発生するからだ。

その優しさが、

結果として自分自身を破壊する。

20年見てきたが、

この構造は例外なく成立する。

第二章　壊れるのは、能力が低い人ではない

これがおそらく、

本記事で最も重要な指摘である。

壊れる人は、

能力が低い人ではない。

責任感が強い人である。

これは慰めの言葉ではない。

組織のインセンティブ構造から、

数学的に導き出される必然である。

考えてみてほしい。

ある組織に、

「客第一主義」「売上優先」「人手不足」の三条件が揃っている。

つまり、

ほとんどのコンサル会社、SI会社、

そして多くの一般企業がそうである。

この組織で、

無責任な人間は何をするか。

適当にアラートを上げて、

タスクを放り出す。

「いやー、僕には無理ですね」と言って、

涼しい顔をしている。

能力が低い人間は何をするか。

最初からスコープアウトする。

簡単に言えば、

巻き込まれる前に逃げる。

「自分には関係ありません」と言って、

距離を取る。

では、

最後まで責任を持って打ち返そうとする、

真面目で優秀な人は何をするか。

全てを抱える。

炎上案件。

未決定事項。

無理な納期。

顧客の理不尽な要求。

部下のミス。

上司の無能。

全てが、

その人のメインメモリに集中デプロイされる。

会社側も学習する。

「あいつに任せておけば、何とかしてくれる」と。

そして、

意識的か無意識的かは別として、

その人にタスクを集中させる仕組みが完成する。

結果として何が起きるか。

最も優秀で、最も責任感が強い人だけが、

過負荷で潰れる。

最も無責任な人と、

最も能力の低い人は、

何事もなかったかのように、

定時で帰る。

これは、

会社が悪いという話ではない。

組織というシステムの、

仕様上の必然である。

責任感が強い人にタスクが集中するように、

組織は無意識に設計されている。

その設計を理解せずに、

「もっと頑張れば」と自分を追い込むと、

ある日突然、

基盤ごと、

パツンと切れる。

私はこの「パツン」を、

数えきれないほど見てきた。

切れる前日まで、

その人は普通に仕事をしている。

切れた翌日から、

その人はもう、

二度と元には戻らない。

第三章　案件ガチャという、最上位のOS

組織の仕様を理解した上で、

次に理解すべきことがある。

それは、

「案件ガチャ」の存在である。

どれだけ企業理念が立派でも、

どれだけISMSやガバナンス規程が整っていても、

配属された案件の利害構造が破綻していて、

上司が機能不全であれば、

そこは一瞬で地獄になる。

逆に、

世間の評判が悪い会社でも、

目の前の顧客と上司との信頼関係が強固であれば、

健全な巡航速度で仕事ができる。

これが意味することは何か。

「会社の評判」は、

あなたの日々の幸福度を決定する変数として、

実はそれほど大きくないということだ。

あなたの幸福度を決定するのは、

会社という抽象ではなく、

案件という具体である。

具体的には、

その案件の顧客が誰か。

その案件の上司が誰か。

その案件のスコープが妥当か。

その案件の納期が現実的か。

これが、

あなたの日々を支配する最上位のOSである。

会社はその下で動く、

サブシステムに過ぎない。

20年見てきたが、

「いい会社の悪い案件」で壊れた人は、

非常に多い。

「悪い会社の良い案件」で長く生き残った人も、

同じくらい多い。

つまり、

会社単位で判断する人は、

判断軸を間違えている。

判断軸は、

案件単位である。

第四章　いきなり転職という、巨大なトランザクション

組織の仕様と案件ガチャを理解した上で、

最後に理解すべきことがある。

それは、

「環境を変える順序」である。

苦しくなった時、

多くの人が最初に考えるのが、

「転職」である。

しかし、

これは合理的な選択肢ではない場合が多い。

なぜか。

転職は、

巨大なトランザクションだからだ。

つまり、

一度実行すると、

ロールバックできない。

辞表を出した後で、

「やっぱり戻ります」とは言えない。

転職先で「やっぱり違いました」と言って、

すぐにまた次へ行けば、

職歴に傷がつく。

巨大なトランザクションは、

慎重に実行されるべきものである。

仕様書として正しい手順は、

「極小スコープから段階的に書き換える」

ことである。

具体的には、

以下の順序が合理的である。

第一段階は、

「今の案件の中で、できることを変える」。

例えば、

タスクの引き受け方を変える。

「全部やります」から「優先順位を確認させてください」に変える。

これだけで、

メインメモリの過負荷が緩和される場合がある。

第二段階は、

「案件を変える」。

つまり、

社内異動を申し出る。

これは転職よりもはるかにリスクが低い。

会社というOSは同じまま、

案件というアプリケーションだけを差し替える操作である。

第三段階は、

「役割を変える」。

例えば、

PMからPMOへ。

現場PMから本社スタッフへ。

これも社内で完結できる場合が多い。

第四段階で、

ようやく「会社を変える」、

つまり転職が選択肢に入る。

そして第五段階として、

「業界を変える」「働き方を変える」が続く。

多くの人は、

第一段階を飛ばして、

いきなり第四段階を実行しようとする。

その結果、

「転職したけど、また同じ状況になった」

という現象が頻発する。

これは、

階層を間違えた書き換えである。

案件レベルのバグを、

会社レベルの変更で直そうとしているのだから、

直らないのは当然である。

第五章　人を責めるより、構造を見る

ここまで読んできて、

おそらくあなたは、

少しだけ視界が変わっているはずだ。

あなたが今、

苦しいのは、

あなたの能力が低いからではない。

あなたの精神力が弱いからでもない。

あなたが優秀で、

責任感が強く、

優しいからこそ、

組織の構造上、

過負荷が集中している。

それだけのことだ。

これは、

決して責任転嫁ではない。

責任の所在を、

正しい変数に代入しているだけだ。

私のブランドキーフレーズの一つに、

こういう一文がある。

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

自分を責めるより、構造を見る。」

人を責めても、

構造は変わらない。

自分を責めても、

構造は変わらない。

変えるべきは、

構造である。

具体的には、

あなたが今いる案件の構造。

あなたが今関わっている顧客との関係構造。

あなたが今受けているタスクの分配構造。

これらを、

仕様書のように、

冷静に書き起こすことから始まる。

書き起こしてみると、

意外なことに気づく。

「自分の能力不足だと思っていたこと」の大半は、

実は構造上の不具合だった、

ということだ。

第六章　環境を変えることは、逃げではない

最後に、

最も伝えたいことを書く。

環境を変えることは、

逃げではない。

プロフェッショナルとしての、

耐久設計である。

エンジニアは、

熱がこもったサーバーを冷却装置のある部屋に移す。

それは「逃げ」ではない。

機器の寿命を延ばすための、

合理的な耐久設計である。

人間も同じだ。

過負荷がかかる環境に居続けることは、

「根性」ではない。

「自分という機器」の寿命を縮める、

合理性の欠如である。

20年見てきたが、

長く現場で活躍し続けている人は、

例外なく、

「環境を変える技術」を持っている。

案件を選ぶ。

顧客を選ぶ。

上司を選ぶ。

無理な時は、

きちんと撤退する。

撤退は、

戦略の一部である。

撤退できない人は、

戦略を持っていない人だ。

そして、

戦略を持っていない人ほど、

「もっと頑張れば」と、

自分のメインメモリを焼き切るまで使い続ける。

その先にあるのは、

栄光ではない。

ただの故障である。

エピローグ

20年PMが見てきた。

結論から言う。

優秀な人から、

静かに壊れる。

これは能力の問題ではない。

組織の仕様の問題である。

仕様を理解せずに自分を責めることは、

仕様書を読まずにバグレポートを書くようなものだ。

意味がない。

だから私は思う。

今、

もしあなたが、

「もう限界かもしれない」と感じているなら、

まず、

仕様書を見てほしい。

あなた自身ではなく、

あなたを取り囲む構造の仕様書を。

その仕様書には、

おそらくこう書かれている。

「責任感が強い人にタスクが集中する設計です。

設計上の不具合ではなく、仕様です。」

仕様であるなら、

仕様を変えるか、

仕様の違う場所に移るしかない。

自分を変えるのではない。

構造を変える。

それが、

長く、

優しいまま、

壊れずに生きていくための、

唯一の技術である。

人を責めるより、

構造を見る。

自分を責めるより、

構造を見る。

立ち止まり、

仕様書を、

もう一度読み直すタイミングなのかもしれない。

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

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

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

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

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

最初の2週間で土台を作れたなら、次は3ヶ月・1年の設計に入る。

炎上対応・SH管理・リモートPM・育成論まで、現場で機能した技術をExcelテンプレート8点付きで体系化した。PMとして長く戦うための実務地図として使ってほしい。

20年PMが全技術を詰め込んだ実務完全インデックス（¥1,980） https://note.com/quiet_emu2080/n/nd22c7c98908c