超現場主義！失敗しないITプロジェクトマネジメント Remake #2 「発注者」と「受注者」というバグ

第2回：ヒト（People）

前回、2006年の「上場前夜」の緊迫感の中で生まれたこの記事についてお話ししました。当時の私たちの最大の敵は、技術的な難易度でも、予算の多寡でもありませんでした。
それは、「発注者（ユーザー企業）」と「受注者（開発ベンダー）」の間に横たわる、あまりに深い溝でした。

第2回の元記事：ユーザー企業側プロジェクトマネージャの勘違い：超現場主義！ 失敗しないITプロジェクトマネジメント（2）

2006年の視点：対等なパートナーシップの欠如

20年前の失敗プロジェクトの典型的な風景は、こうでした。

ユーザー企業のPMは「お客様」として君臨し、「金は払っているんだから、期日までに言ったものを作れ」と命じる。開発側のPMは「下請け」として、無理難題にひたすら耐え、現場が疲弊しても「できません」と言い出せない。

• 丸投げの構造:
  ビジネスの目的やリスクを共有せず、単なる「作業」として発注する。
• 「業者」扱い:
  開発パートナーを、共に汗を流す仲間ではなく、代替可能なリソース（部品）として扱う。
• 結果としての隠蔽:
  「怒られたくない」「契約解除が怖い」という心理から、進捗の遅れや技術的課題が隠蔽され、リリース直前で修復不能な爆発を起こす。

当時の記事で、私たちは叫びました。
「ベンダーを業者扱いするな。共にリスクを背負い、運命を共にするパートナーとして扱え」 と。
上場という「絶対に失敗できない」局面を乗り切るためには、この関係性の再構築こそが、何よりも優先されるべき「技術」だったのです。

現代の視点：「ワンチーム」という幻想

あれから20年。
アジャイル開発が普及し、「内製化」が叫ばれ、Slackの同じチャンネルで発注者も受注者もフランクに会話する時代になりました。
かつての殺伐とした「主従関係」は減り、表面上は理想的な「ワンチーム」が増えたように見えます。

しかし、既視感のある炎上現場を覗くと、形を変えた新たな「ヒト」のバグが潜んでいます。

1. 責任の所在の曖昧化

「みんなで議論して決めよう」というスタイルは、一見民主的ですが、裏を返せば「誰が責任を取るか」を曖昧にします。

プロジェクトが順調なときは、確かに「ワンチーム」は機能します。
しかし、いざ問題が起きた瞬間、その幻想は脆くも崩れ去ります。

「発注者だから」と急にマウントを取り始めたり、「仕様が決まっていなかった」と言い訳を並べて責任逃れを始めたり。
境界線が曖昧になった分、有事の際の「逃げ道」も増えてしまったのです。

2. 「ぬるま湯」としての心理的安全性

今やマネジメントの必須用語となった「心理的安全性（Psychological Safety）」。
しかし、その本当の意味を誤解している現場は少なくありません。

本来の心理的安全性が高いチームとは、「目的を達成するために、たとえ耳が痛いことでも、上司や仲間に遠慮せず言える状態」 を指します。
しかし、現実には単に「仲が良い」「誰も怒られない」「お互いに気を遣って厳しいことを言わない」だけの、「ぬるま湯（Comfort Zone）」 を心理的安全性と呼んでしまっている。

リスクが見えているのに、「雰囲気を壊したくないから」と指摘を飲み込む。
これは、20年前の「怖くて言えなかった隠蔽」と、結果において何も変わりません。

3. 「お見合い」によるタスクの蒸発

かつては「契約という冷徹な壁」がありましたが、同時にそれは「ここまでは俺の仕事、ここからはお前の仕事」という明確な境界線でもありました。

今はその壁が取り払われた結果、本来であればタスクごとにきっちり役割分担が決まっていて、責任を持って完遂されるべき領域が、「誰かがやってくれるだろう」という 「お見合い」 状態になってしまっています。

この背景には、テレワークの普及も影を落としているのかもしれません。
20年前の現場では、同じ部屋で膝を突き合わせ、タバコ部屋や飲み会で「あの件どうなってる？」「あ、俺やっとくわ」という濃密な（時にウザいほどの）情報共有が自然と行われていました。
しかし、Google Meetの画面越しでは、空気感や「なんとなくの違和感」は伝わりません。明確に言語化され、チケット化されないタスクは、誰の視界にも入らぬまま、静かに蒸発していくのです。

• インフラの設定は誰が見るのか？
• 外部連携APIの仕様確認は誰のボールか？
• 受入テストのシナリオは誰が書くのか？

誰も指摘しないまま、やるべきタスクがポロポロとこぼれ落ちていく。
そしてプロジェクト終盤、リリースの足音が聞こえてきた頃になって初めて、「え、あれ終わってないの？」という悲鳴と共に炎上するのです。

構造的な「分断」をハックする

「発注者 vs 受注者」という壁は確かに低くなりました。
指示する側とされる側、という境界は溶けつつあります。しかし、代わりに 「ビジネスサイド vs エンジニアサイド」、あるいは 「専門領域」 という、より見えにくい壁が組織内部に生まれています。

この壁を越えるために、現代のPMやエンジニアはどう振る舞うべきでしょうか？

1. 「言語」の翻訳者になる

かつての仕様書が共通言語でした。今は違います。
ビジネスサイドは「LTV」「Churn Rate」で語り、エンジニアは「Microservices」「Latency」で語ります。

PMの役割は、この異なる言語を翻訳することです。

• 「このリファクタリングをしないと、将来的に機能追加のスピードが半分になります（＝機会損失コスト）」
• 「このUI変更は、コンバージョンを上げるために技術的負債を負ってでも今やるべきです」

テレワーク時代だからこそ、この「翻訳」をテキスト（ドキュメントやSlack）で高解像度に残せるスキルが、チームの分断を防ぎます。

2. LLM時代の「振る舞い」を変える

AI（LLM）がコーディングや資料作成を肩代わりしてくれる時代、人間がやるべき仕事は「手作業」から「意思決定」にシフトします。

• エンジニア:
  「コードが書ける」ことの価値は相対的に下がります。代わりに、「ビジネスの要件を正しく理解し、AIに適切な指示（プロンプト）を出し、出力されたコードがアーキテクチャ的に正しいか判断する」設計力と審美眼 が求められます。
• PM:
  議事録やスケジュール引きはAIがやります。PMは、AIが出した選択肢の中から「何をやらないか（捨てるか）」を決める決断力 と、ステークホルダー間の政治的な調整 に全振りすべきです。

3. 「同期」と「非同期」の使い分け

テレワークでの「お見合い」を防ぐには、コミュニケーションのメリハリが不可欠です。

• タスクの定義（非同期）:
  「誰が・いつまでに・何を」は、NotionやGitHubのIssueでテキスト化し、曖昧さを排除する。ここはAIを使って徹底的に具体化する。
• 熱量の共有（同期）:
  一方で、「なぜやるのか」「このプロジェクトの正念場だ」という熱量は、Google Meetや対面で直接伝える。

20年前、私たちはタバコ部屋で信頼を築きました。
今は、「AIに任せられる作業は全て任せ、浮いた時間で人間同士が膝を突き合わせて『未来』を語る」 ことこそが、最強のチームビルディングなのかもしれません。

「ヒト」という不確定要素を制御することは不可能です。
しかし、20年前の上場前夜も、そしてAIが台頭する現代も、唯一の特効薬は変わりません。

「お互いへの敬意」を前提とした、一切の手加減をしないコミュニケーション。

かつて私たちが「対等なパートナーシップ」と呼んだものは、現代では「AIを使いこなすプロフェッショナル同士の高度なコラボレーション」へと、その言葉を変えて求められています。

次回は、そんな「ヒト」が選ぶ「モノ（技術）」について。
「トレンドという怪物」に飲み込まれないための、現代版の技術選定思想をお伝えします。

次回：#3 「枯れた技術」か「新しい技術」か