PMの仕事は、突き詰めれば「人と話して情報を流すこと」が大半です。要件を聞き出し、メンバーに伝え、顧客に報告し、トラブルでは関係者を巻き込む。技術力よりまずコミュニケーションが上位に来る職種です。

私はこの「人と話して情報を流す」が強烈に苦手です。雑談に踏み出せず、空気を読むのに時間がかかり、込み入った話になると頭が真っ白になる。にもかかわらずPM寄りの役割を任され、何度もプロジェクトを止めかけてきました。本記事は、その失敗の構造と、AI/PMO（Claude Code＋Markdown＋GitHub）でどう折り合いをつけたかの記録です。

なお「コミュ障」という言葉の使い方とADHD／ASD傾向との関係は、記事末尾の補足にまとめています。

コミュ障PMが詰む構造 — 影響は掛け算で効く

最大の理由は、コミュニケーションの欠如がプロジェクトの全フェーズに影響し、足し算ではなく掛け算で効くこと。各フェーズで踏んできたパターンを並べます。

要件定義 — 役割を並行化できない。曖昧な要望から要件を引き出す関門。私が本当に難しいのは「聞き返せない」ことではなく、ファシリテーションをしながらリアルタイムで顧客の発言を解釈し、何が曖昧かを抽出し、その場で具体的な聞き返しに変換する並列処理です。事前準備で想定質問が揃っていれば読み上げて確認できるし、エンジニアの立場でなら担当範囲に踏み込めます。でも流れを止めない方に認知リソースを使い切り、要件の具体化は後から「もっと突っ込むべきだった」と気づく形でしか進まない。その場で曖昧なまま頷き自分の解釈で補完し、後工程で大きな手戻りが出る。これが掛け算の第一段階で、コミュ障寄りの人がPMファシリテーターを兼ねてはならない構造的理由だと考えています。

メンバー協働 — レビューと指示でフリーズする。メンバーの提案に違和感を覚えても「いや違う」と言い切れず「うーん、でも……」で終わる。間違った方向に進むメンバーへの軌道修正も切り出せず先延ばしし、実装が進んでから言うことになる。健常なPMなら15分の軌道修正会話を、コミュ障PMは半日Slackで書いては消し、1日遅れて持ち出す。早期介入の遅れが後工程の手戻りを掛け算で増やします。

顧客窓口 — 悪い報告の文面を一人で抱え込む。遅延・追加コスト・実現困難な要望。コミュ障PMがここで弱いのは心理的負荷だけが理由ではなく、「この言い方でこの悪い報告をしてよいのか」という文面判断で延々悩むから。気軽に「文面見てくれない？」と頼める信頼関係を普段から社内で築けていないので、一人で書いては消しを繰り返す。報告が遅れ、最終的に「手遅れになってから」発覚し、「隠していた」と受け取られて信頼を失う。

障害対応 — 情報吸い上げの速度が落ちる。平時の倍以上のストレス下で複数の関係者に同時並行で確認を取る場面。電話が怖い、矢継ぎ早の質問に頭が回らない、感情に圧倒される。本来30分で集まる情報に2時間かかり、その間に被害が拡大します。

なぜ掛け算かというと、要件定義の曖昧さがメンバー協働の手戻りを生み、それが顧客報告の悪化に繋がり、悪化した信頼が障害対応を困難にする。前フェーズの劣化が次フェーズの初期条件を悪化させるからです。だから「ちょっと苦手」では済まず「構造的に詰む」。

一般的な対処法と、その限界

  • メンタリング・コーチング：ロールプレイは短期的に効くが、「相手の沈黙が怖い」感情は安全な場では再現できず、本番ではフリーズする
  • コミュニケーション本・研修：「最後まで聞く」「Yes, andで受ける」は知識として正しいが、根本問題は「知らない」ではなく「知っているのに反射的にできない」ことなので解決しない
  • 慣れろ系のアドバイス：最も筋が悪い。コミュ障寄りの脳では曝露そのものがダメージを蓄積する。私も新人時代に「電話を取れ」と言われ毎日吐き気と戦ったが、3年やっても恐怖は減らなかった

たどり着いた折り合い — AI/PMOで欠点を補完する

結論として私はPMをやめず、コミュ障の脳でも回せるPMの形にプロセスを作り変えました。鍵はAI（Claude Code）とPMO的なMarkdown管理の組み合わせです。

同期コミュニケーションを非同期＋AI整形に置き換える。最大の弱点は会議・電話・対面でのリアルタイム応答。会議を可能な限り減らし、依頼・確認はSlack・メール・GitHub Issuesで非同期化しました。非同期テキストなら書いては消し、AIに添削させ、温度を整えてから送れます。即興判断を数分の推敲時間に変換する戦略です。残った会議は「議題と論点を事前に文書化し、当日は読み合わせ＋意思決定だけ」にすると、頭が真っ白になっても流れが止まりません。

SSoTをMarkdownで持つ。「聞き返せない」「確認が遅れる」のは、頭の中で情報を保持して尋ねる同期コミュ依存のスタイルに乗っているから。すべての要件・決定・懸念をMarkdownに書き出し、関係者全員がそこを見る運用に変えると弱点が表に出にくくなります。

project-x/
├─ README.md             # プロジェクト概要・体制・連絡先
├─ requirements.md       # 要件と曖昧ポイントのメモ（曖昧なまま記録）
├─ decisions.md          # 意思決定ログ（誰が・いつ・何を決めたか）
├─ risks.md              # リスク・懸念事項
├─ sprints/              # スプリント別タスク
└─ logs/                 # 議事録・コミュニケーション履歴

ポイントは requirements.md に曖昧ポイントをそのまま記録すること。「『いい感じに』の解釈が3通りある」と書いて共有すると、相手から「2番目の意味でね」と返ってきたりする。聞き返す勇気を出さなくても、文書経由で確認が回る構造です。

Claude Codeに「2人目のPM」を演じてもらう。日常的にこんな問いを投げます。

  • 「この要件、曖昧な部分はどこ？顧客に確認すべき点を3つ挙げて」
  • 「このスプリント計画、見落としていそうなリスクは？」
  • 「この障害報告を顧客向けに書き直して。事実と原因と対処を分けて、感情的に取られない温度で」
  • 「メンバーAのコミットの傾向を見て、進捗が遅れていないか・無理してないか観察して」

リポジトリ全体（要件・意思決定・スプリント・ログ）を読んだ上で答えてくれるので、「聞きづらくて確認が遅れた」「気づくのが遅かった」を機械的に補完してくれます。この発想の元になった運用はClaude Codeで個人タスク管理をPMO化するに詳しく書きました。

顧客向け文書はAIに下書きさせて温度を整える。悪い報告・断り文句など温度の難しい文書はClaude Codeに下書きさせ、自分が手を加えて送ります。コミュ障PMの文章は自覚なく冷たくなったり過剰に謝罪的になりがちですが、「事実／原因／対処／お詫びを簡潔に、相手を責めない温度で」と指示すると中庸に揃った下書きが出る。そこに言いたかったニュアンスを1〜2行足すだけで完成します。これは生身で対面説明するより明らかに伝達品質が高い、という複雑な事実です。

補完できた領域・できない領域

「AIがあれば解決」ほど楽観的ではありません。補完できたこと：

  • 要件の曖昧さの早期検出（AIが先回りで指摘）
  • 非同期テキストの温度調整（顧客向け報告の品質が安定）
  • 進捗とリスクの可視化（すべてMarkdownにあるので後追いで全体像を把握）
  • メンバー協働の軌道修正の遅れ解消（「このメンバー今週コミット少ないけど無理してない？」と気づかせてくれる）

これらが効いて、平時のPM業務は「劣化版」ではなく「むしろ平均より丁寧」と言ってもらえるレベルまで持っていけました。一方、AIで補完しきれない領域もあります。

  • 障害対応の本番（リアルタイムで複数人と話す場面はAI下書きが間に合わない）
  • 顧客との初回ヒアリング（信頼構築の雑談は非同期に置き換えられない）
  • 大人数会議でのファシリテーション（場の空気を読むスキルが必須）

これらが主軸のポジションは、AIで武装しても根本的に向いていません。私は実際、この3つが中心のPMポジションは引き受けないようにしています。重要なのは「どこまでAIで補完して回し、どこからは別の人に任せるか」の見極め。AIはPMを「向いている職種」に変える魔法ではありません。

始め方の3ステップ

  1. 要件・決定事項をすべてMarkdownに移す — ツール導入ではなく、散らばった情報を1箇所に。プロジェクトごとに requirements.md decisions.md risks.md の3つを作り、要件・決定・懸念を集約。曖昧なまま書いてよく、むしろ曖昧さは曖昧として記録するのが本筋。AIに読ませて補完を依頼する土台になります
  2. Claude Codeに「PM観点のレビュー」を週1で依頼する — requirements.mdの曖昧な要件3つと確認すべき相手・質問文を提案させる／decisions.mdとrisks.mdの矛盾や対応漏れを指摘させる／logs/からスプリントの危険な兆候を読み取らせる。週次で回すだけで「聞き忘れ」「気づかなかった」が確実に減る
  3. 外向き文書はAI下書きを通す — 温度調整が難しい文書はすべて下書きさせる。テンプレを1つ持っておくと楽です

以下の事実から、顧客向けの報告メールを書いてください。事実／原因／対処／今後の対応を簡潔に、相手を責めず・自分も過剰に謝罪せず、中立的な温度でお願いします。

出てきた下書きに自分のニュアンスを1〜2行足して送る。一から書くより速く、伝達品質が高い文書が安定供給されます。

まとめ — コミュ障でPMをやらざるを得ない人へ

コミュ障寄りの人がPMをやると、コミュニケーション欠如が各フェーズで掛け算的に効いて構造的に詰みやすい。これは性格や努力ではなく、職種要件と認知特性のミスマッチに近いと理解しています。社内で良い人間関係を築けていたり、実績の貯金が悪い報告や同期コミュの粗さを吸収してくれるなら、本記事の前提とは別の話です。

そうでないなら、やれることは3つ。まずAIに頼り切ること。仕組みで解決すると決めること。それでも回らないなら、PMを降りて戦いやすい場所で戦うこと。現代のAI（特にリポジトリ全体を読めるエージェント）とMarkdownベースのPMO運用を組み合わせると、同期コミュ依存の業務スタイルを非同期＋AI補完型に書き換えるのが現実的になってきました。すべては補完できなくても、平時のPM業務を平均以上に持っていくことは可能です。

私自身、前職で社内SEだった頃は部署内で一定の評価をもらえている自負がありました。アプリの要件定義段階から提案し、DBとアプリの設計・実装・テスト・リリース・運用保守までを通しで回せていた。ただそれは、あくまで一人の社内SE／エンジニアとしての立場の領域を出るものではなかった。現職でPMの役回りを始めてからは、その自信を一挙にたたき折られ、一時は自分にネガティブな感情しか持てない時期もありました。ただここ1年でAI環境が育ち、コミュ障寄りでもやっていける形が整いつつあります。向いていない職種を、向いている形に作り変える。これがコミュ障PMにとっての現実的な落とし所だと、今のところ考えています。

補足 — ADHD／ASD傾向と「コミュ障」表記について

本記事では「コミュ障」という簡易な言葉を一貫して使いました。私自身ADHD傾向やASD傾向を自覚していますが、医療機関で正式な診断を受けたわけではないため、専門的な表現には踏み込まず「コミュ障」で統一しています。本記事は医学的な解説ではなく、一個人の実務経験と運用ノウハウとして読んでいただければ幸いです。

関連記事

公式リンク

このブログについて

X（旧Twitter）でも、AI活用と高配当株投資の話を発信しています。同じ悩みを抱える方の参考になれば。

→ @tofu_dividend