はじめに — コミュ障がPMをやるとどうなるか
プロジェクトマネージャー（以下PM）の仕事は、突き詰めれば「人と話して情報を流すこと」が大半を占めます。要件を聞き出し、メンバーに伝え、顧客に進捗を報告し、トラブルが起きれば関係者を巻き込んで対処する。技術力よりもまず、コミュニケーションが要件として上位に来る職種です。
私はこの「人と話して情報を流す」が、強烈に苦手です。雑談に踏み出せず、相手の表情から空気を読むのに人より時間がかかり、込み入った話になると頭が真っ白になります。にもかかわらず、本業や副業の流れでPM寄りの役割を任されてきた結果、何度もプロジェクトを止めかけてきました。本記事は、その失敗の構造と、AI/PMO（Claude Code＋Markdown＋GitHub）でどう折り合いをつけたかを、同じ悩みを持つ人に向けて書き残すものです。
なお、本記事における「コミュ障」という言葉の使い方とADHD／ASD傾向との関係については、医学的な観点も含めて記事末尾の補足にまとめています。気になる方はそちらを先にお読みください。
コミュ障PMが詰む構造 — 影響は掛け算で効く
最初に結論から書きます。コミュ障がPMをやると詰む最大の理由は、 コミュニケーションの欠如がプロジェクトの全フェーズに影響し、それが足し算ではなく掛け算で効いてしまう ことです。1つひとつのフェーズで「ちょっと聞きづらかった」「確認が遅れた」が積み重なり、最終的に取り返しのつかない遅延・品質問題・関係性悪化に行き着きます。
フェーズごとに、私が何度も踏んできたパターンを並べてみます。
要件定義フェーズ — 役割を並行化できない
PMの最初の関門は、曖昧な要望から具体的な要件を引き出すことです。顧客や上長が「いい感じにしておいて」と言ったとき、健常なコミュニケーション能力を持つPMは、その場で踏み込んで聞き返します。「いい感じ、とは具体的にどの画面のどの挙動を指していますか？」と。
私は当初、ここでつまずく理由を「聞き返せないから」と片付けていました。ただ、より解像度を上げて自分を観察すると、コミュ障寄りであっても、 聞くべきことが具体的に頭の中で組み上がっていれば、その場で手を挙げて質問することはできる とわかってきました。実際、PMではなくエンジニアの立場でMTGに同席するときは、自分の担当する実装範囲について「ここはどう動くのが正解ですか」と踏み込めます。あるいはPMの立場でも、事前準備で想定質問が揃っていれば、それを読み上げて確認を回すことはできる。
私のような人間にとって本当に難しいのは、 MTGのファシリテーションをしながら、リアルタイムで顧客の発言を解釈し、何が曖昧かを抽出し、その場で具体的な聞き返しに変換する という並列処理です。ファシリの間は流れを止めないことに認知リソースを使い切ってしまい、要件の具体化はあとから「あのときもっと突っ込んで聞くべきだった」と気づく形でしか進まない。経験豊富なPMが無意識にこなしている同時並行を、私はどれだけ年数を重ねても自然にはできるようになりませんでした。
結果として、その場では曖昧なまま頷き、自分の解釈で要件を補完してしまい、後工程で大きな手戻りが発生します。要件定義の小さな曖昧さは、後の設計・実装・テスト・受け入れの各フェーズで、最初の10倍以上のコストを発生させる。これがすでに「掛け算」の第一段階であり、 コミュ障寄りの人がPMファシリテーターを兼ねてはならない構造的な理由 でもある、と私は今のところ考えています。
メンバー協働フェーズ — レビューと指示でフリーズする
PMがチームを率いる場合、最も頻度が高いコミュニケーションはメンバーへの指示と、上がってきた成果物のレビューです。
私の場合、ここで2種類のフリーズが起きます。1つは、メンバーの提案に違和感を覚えたときに、「いや、それは違う」と言い切れない。「うーん、そうですね、でも……」で終わって相手に伝わらない。もう1つは、明らかに間違っている方向に進んでいるメンバーに対して、軌道修正を切り出すタイミングが取れない。気づいた時点で言えばよいものを、「もう少し見てから」「明日の朝会で」と先延ばしし、実装が進んでから言うことになる。
これも要件定義と同様、 早期介入の遅れが後工程の手戻りを掛け算で増やす 構造です。健常なPMなら15分で済んだ軌道修正会話を、コミュ障PMは半日かけてSlackで書いては消し、結局1日遅れて持ち出すことになります。
顧客窓口フェーズ — 「悪い報告」の文面を一人で抱え込む
プロジェクトを進めると、必ずどこかで「悪い報告」をする場面が来ます。スケジュール遅延、想定外の追加コスト、技術的に実現困難な要望、メンバーの離脱。これを顧客にどう伝えるかが、PMの腕の見せどころです。
コミュ障PMは、ここで致命的に弱い。ただ、その理由は単に「心理的負荷が高いから」ではないと、私自身は思っています。後回しにしてしまう本当の理由はもう一段深いところにあって、 この言い方で、顧客にこの悪い報告をしてよいのか という文面の判断で延々と悩み続けるパターンが圧倒的に多い。
コミュ障寄りでなければ、社内に普段から信頼関係のあるメンバーが何人かいて、「ちょっとこの文面見てくれない？」と気軽に文章レビューを頼めるはずです。ところが、ビジネスライクなコミュニケーションしかできないコミュ障寄りの私は、そもそも普段から「気軽にレビューを頼める信頼関係」を社内で築けていない。結果、自分一人で文面を書いては消し、書いては消しを繰り返すことになる。報告が1日遅れ、1週間遅れ、最終的に「もう手遅れになってから」発覚する、というパターンを何度も繰り返してきました。
顧客との信頼関係は、悪い報告の質とタイミングで決まると言っても過言ではありません。早く正確に伝えれば一緒に対処できる問題が、遅れることで「隠していた」と受け取られ、信頼そのものを失う。文面の悩みを一人で抱え込む構造が、そのまま掛け算の悪化要因として効いてくるのが、コミュ障PMの顧客窓口フェーズです。
障害対応フェーズ — 情報吸い上げの速度が致命的に落ちる
本番障害が起きると、PMの仕事は「情報を集める・優先度を決める・指示を出す・関係者に状況を伝える」を高速で回すことになります。ここでのコミュニケーション速度は、文字通り障害の被害規模を左右します。
コミュ障PMは、平時の倍以上のストレス下で、複数の関係者に同時並行で確認を取らなければならない状況に置かれます。電話を取るのが怖い、矢継ぎ早の質問に頭が回らない、関係者の感情に圧倒されてしまう。結果として、本来なら30分で集まる情報に2時間かかり、その間に被害が拡大していきます。
なぜ「掛け算」になるのか
要件定義・メンバー協働・顧客窓口・障害対応の4フェーズで、それぞれコミュ障PMは「30%遅い／30%精度が低い」とします。これが独立した影響なら、トータルの劣化は単純に積み上がるだけです。
ところが実際には、要件定義の曖昧さがメンバー協働の手戻りを生み、その手戻りが顧客報告の悪化に繋がり、悪化した信頼関係が障害時の対応を一層困難にします。前フェーズの劣化が次フェーズの初期条件を悪化させるため、影響が掛け算で蓄積されていく。
これが、コミュ障PMが「ちょっと苦手」では済まず、「構造的に詰む」と私が表現する理由です。
一般的な対処法と、その限界
世の中には、コミュニケーション能力を高めるためのアドバイスや書籍が無数にあります。私もそれらを試してきましたが、本質的にコミュ障寄りの人間には合わないと感じる部分があります。
メンタリング・コーチング
経験豊富なPMに付いてもらい、ロールプレイで会話を練習する手法です。短期的には効果がありますが、根本的な「相手の沈黙が怖い」という感情の部分は、ロールプレイの安心安全な場では再現できません。本番の顧客の前ではやはりフリーズします。
コミュニケーション本・研修
「相手の話を最後まで聞く」「Yes, and で受ける」といった汎用テクニックを学ぶアプローチです。知識として正しいのですが、コミュ障の根本問題は「知らない」ではなく「知っているのに反射的にできない」ことなので、技法の追加では解決しません。
「慣れろ」アドバイスの構造的な問題
最もよく言われ、最も筋が悪いのが「数をこなせば慣れる」というアドバイスです。これは健常コミュニケーション層の人が、自分の経験を一般化して言っているだけで、コミュ障寄りの脳ではそもそも「数をこなす」という曝露そのものがダメージを蓄積させていきます。
会話の場数を踏むほど消耗し、消耗するほど次の会話が怖くなる悪循環に入る。私自身、新人時代に「とにかく電話を取れ」と言われて毎日吐き気と戦った経験がありますが、3年やっても電話への恐怖は減りませんでした。
私がたどり着いた折り合い — AI/PMOで欠点を補完する
ここまで散々書いてきましたが、結論として私はPMをやめませんでした。やめずに、「コミュ障の脳でも回せるPMの形」にプロセスを作り変えたのです。鍵になったのが、AI（Claude Code）とPMO的なMarkdown管理を組み合わせた運用です。
具体的には、以下の4つの方針で日常業務を組み替えました。
同期コミュニケーションを「非同期＋AI整形」に置き換える
コミュ障PMの最大の弱点は、 同期コミュニケーション（会議・電話・対面）でのリアルタイム応答 です。逆に言えば、非同期に持ち込めば苦手領域を最小化できます。
私は会議を可能な限り減らし、依頼事項・確認事項はSlack・メール・GitHub Issuesで非同期化しました。非同期テキストなら、書いては消し、AIに添削させ、温度を整えてから送信できます。リアルタイムでの即興判断を、 数分の推敲時間 に変換する戦略です。
会議を完全に消すことはできないので、残った会議には「議題と論点を事前に文書化し、当日は読み合わせ＋意思決定だけにする」ルールを徹底しています。これだけで、当日に頭が真っ白になっても流れが止まらなくなります。
SSoT（信頼できる唯一の情報源）をMarkdownで持つ
コミュ障PMが「聞き返せない」「確認が遅れる」のは、 頭の中で情報を保持して尋ねる という同期コミュ依存のスタイルに乗っているからです。これを、 すべての要件・決定事項・懸念事項をMarkdownファイルに書き出し、関係者全員がそこを見る という運用に変えると、私の弱点が表に出にくくなります。
具体的には、プロジェクトごとに以下のような構造を持つMarkdownリポジトリを作っています。
project-x/
├─ README.md # プロジェクト概要・体制・連絡先
├─ requirements.md # 要件と曖昧ポイントのメモ（曖昧なまま記録）
├─ decisions.md # 意思決定ログ（誰が・いつ・何を決めたか）
├─ risks.md # リスク・懸念事項
├─ sprints/ # スプリント別タスク
└─ logs/ # 議事録・コミュニケーション履歴
ポイントは requirements.md に 曖昧ポイントをそのまま記録する こと。「いい感じに、という指示の解釈が3通りある」と書いて、関係者に共有しておく。すると相手側から「あ、これは2番目の意味でね」と返ってきたり、曖昧さを共通認識として持てたりします。聞き返す勇気を出さなくても、文書経由で確認が回る構造です。
Claude Codeに「2人目のPM」を演じてもらう
私はClaude Codeに、自分の作業の「2人目のPM」役を演じてもらっています。具体的には、以下のような問いかけを日常的に投げています。
- 「この要件、曖昧な部分はどこ？顧客に確認すべき点を3つ挙げて」
- 「このスプリント計画、リスクとして見落としていそうな観点は？」
- 「この障害報告を顧客向けに書き直して。事実と原因と対処を分けて、感情的に取られない温度で」
- 「メンバーAのコミットの傾向を見て、進捗が遅れていないか・無理してないか観察して」
Claude Codeはリポジトリ全体（要件・意思決定・スプリント・ログ）を読んだ上で答えてくれるので、私が「聞きづらくて確認が遅れた」「気づくのが遅かった」を機械的に補完してくれます。私自身が早期介入できなくても、AIが「ここは確認した方がいい」と先回りで指摘してくれる構造です。
この発想の元になった、Claude Codeを個人PMOとして使う運用方法は、別記事のClaude Codeで個人タスク管理をPMO化するに詳しく書きました。
顧客向け文書はAIに下書きさせて温度を整える
悪い報告・難しい説明・断り文句といった「温度の難しい文書」は、Claude Codeに下書きさせ、自分が手を加えて送信する運用にしています。
コミュ障PMが書く文章は、自覚なしに冷たくなったり、逆に過剰に謝罪的になったりしがちです。AIに「事実／原因／対処／お詫び を簡潔に、相手を責めない温度で」と指示すると、感情の濃度が中庸に揃った下書きが出てきます。それをベースに、 自分が言いたかったが言葉にできなかったニュアンスを1〜2行追加する だけで、人間味のある報告メールが完成します。
これは、生身の私が顧客に対面で説明するよりも、 明らかに伝達品質が高い という結果になっています。コミュ障の自分が苦労して書いた文章よりも、AI下書き＋微調整の方が客観的に良いという、なんとも複雑な事実です。
補完できた領域・できない領域
ここまで読むと「AIがあれば解決じゃん」と聞こえそうですが、正直に言うとそんなに楽観的な話ではありません。
補完できたこと
- 要件の曖昧さの早期検出（AIが「ここ曖昧では」と先回りで指摘してくれる）
- 非同期テキストの温度調整（顧客向け報告・難しい説明の品質が安定）
- 進捗とリスクの可視化（議事録・タスク・決定事項がすべてMarkdownにあるので、後追いで全体像を把握できる）
- メンバー協働の軌道修正の遅れの解消（Claude Codeが「このメンバー、今週コミット少ないけど無理してない？」と気づかせてくれる）
これらが効くようになって、平時のPM業務であれば「劣化版」ではなく「むしろ平均より丁寧」と言ってもらえるレベルまで持っていけました。
補完できないこと — PMをやめる選択肢も視野に
一方で、 どうしてもAIで補完しきれない領域 もあります。
- 障害対応の本番（リアルタイムで複数人と話す場面はAI下書きが間に合わない）
- 顧客との初回ヒアリング（信頼構築のための雑談は非同期に置き換えられない）
- 大人数会議でのファシリテーション（場の空気を読むスキルが必須）
これらが業務の主軸になるポジションでは、いくらAIで武装しても根本的に向いていません。私は実際、フルタイムでこの3つが中心になるPMポジションは引き受けないようにしています。受けても自分も顧客も不幸になるためです。
コミュ障寄りの人がPMに向き合うときに、最も重要な判断は「どこまでをAIで補完して回し、どこからは別の人に任せるか」を見極めることだと考えています。AIは強力な補完ツールですが、PMを「向いている職種」に変える魔法ではありません。
始め方の3ステップ
コミュ障寄りの自覚があり、PM寄りの役割を担っている人が、明日から試せる3つのステップを置いておきます。
ステップ1: 要件・決定事項をすべてMarkdownに移す
最初にやるべきは、ツールの導入ではなく、 頭の中とチャットアプリに散らばっている情報を1箇所に集めること です。プロジェクトごとに requirements.md decisions.md risks.md の3ファイルだけ作り、関係するすべての要件・決定・懸念をそこに集約します。
曖昧なまま書いて構いません。むしろ曖昧さは曖昧として記録するのが本筋です。これがあれば、後でAIに読ませて補完を依頼できる土台になります。
ステップ2: Claude Codeに「PM観点のレビュー」を依頼するルーチンを作る
ステップ1の3ファイルが揃ったら、Claude Codeに以下を依頼するルーチンを週1回入れます。
- requirements.mdを読んで、曖昧な要件を3つ挙げて、確認すべき相手と質問文を提案して
- decisions.mdとrisks.mdを読んで、矛盾している決定や、対応漏れのリスクを指摘して
- このスプリントの進捗をlogs/から読み取って、危険な兆候があれば教えて
これを週次で回すだけで、自分が「聞き忘れていた」「気づいていなかった」が、確実に減ります。
ステップ3: 外向き文書はAI下書きを通す
顧客報告・遅延連絡・断りメール・難しい説明など、 温度調整が難しい文書はすべてClaude Codeに下書きさせる ルールにします。プロンプトのテンプレートを1つ持っておくと楽です。
以下の事実から、顧客向けの報告メールを書いてください。事実／原因／対処／今後の対応を簡潔に、相手を責めず・自分も過剰に謝罪せず、中立的な温度でお願いします。
出てきた下書きに自分のニュアンスを1〜2行足して送信する。これだけで、自分で一から書くより速く・伝達品質が高い文書が安定供給されます。
まとめ — コミュ障でPMをやらざるを得ない人へ
コミュ障寄りの人がPMをやると、コミュニケーション欠如が要件定義・メンバー協働・顧客窓口・障害対応の各フェーズで掛け算的に効いてしまい、構造的に詰みやすい職種です。これは性格や努力の問題ではなく、職種要件と認知特性のミスマッチに近いと私は理解しています。
もちろん、社内で良い人間関係を築けてチームビルディングが回っているなら、コミュ障寄りでもチーム形成への悪影響は小さく済むかもしれません。実績が豊富で案件をスムーズに回せている場合も同様で、信頼の貯金が悪い報告や同期コミュの粗さを吸収してくれます。それらに恵まれているなら、本記事の前提とは別の話になります。
ただ、そうではない場合 — 人間関係に悩まされ、ときに指摘されながら、自身のPM適性に悩みながら、評価されないPM業務を続けているなら。やれることは大きく3つしかないと私は今のところ考えています。 まずAIに頼り切ること。仕組みで解決すると決めること。それでもなお回らないなら、PMを降りて戦いやすい場所で戦うこと。
現代のAI（特にClaude Codeのようなリポジトリ全体を読めるエージェント）と、MarkdownベースのPMO運用を組み合わせると、 同期コミュニケーション依存の業務スタイルを、非同期＋AI補完型に書き換える ことが現実的になってきました。すべての領域を補完できるわけではないものの、平時のPM業務の品質を平均以上に持っていくことは可能です。
私自身、前職で社内SEだった頃は、部署内で一定の評価をもらえている自負がありました。アプリの要件定義段階から積極的に提案し、DBとアプリケーションの設計・実装・テスト・リリース・運用保守までを通しで回せていた。ただそれは、あくまで一人の社内SE／エンジニアとしての立場の領域を出るものではなかった。現職でPMの役回りをスタートしてからは、その自信を一挙にたたき折られ、一時は自分に対してネガティブな感情しか持てなかった時期もあります。
ただここ1年ほどで、AI環境が育ち、コミュ障寄りでもやっていける形が整いつつあります。向いていない職種を、向いている形に作り変える。これがコミュ障PMにとっての現実的な落とし所だと、私は今のところ考えています。同じ悩みを持つ方がいれば、本記事の運用が何かの参考になれば嬉しいです。
補足 — ADHD／ASD傾向と「コミュ障」表記について
本記事では「コミュ障」という簡易な言葉を一貫して使いました。私自身、ADHD傾向やASD傾向を自覚していますが、医療機関で正式な診断を受けたわけではないため、専門的な表現には踏み込まず、総じて「コミュ障」という言葉で統一しています。読者の中には同じ傾向を持つ方も、診断を受けた方もいると思いますが、本記事は医学的な解説ではなく、あくまで一個人の実務経験と運用ノウハウとして読んでいただければ幸いです。
関連記事
公式リンク
- Claude Code 公式ドキュメント — 本記事で言及したAIエージェントの公式リファレンス
このブログについて
X（旧Twitter）でも、AI活用と高配当株投資の話を発信しています。同じ悩みを抱える方の参考になれば。