はじめに

システム開発の現場では、こんな光景をよく見ます。

PMがレビューだけでなく、コードを書き始めてしまう
顧客の要望を「また無茶を言ってくる」と敵視してしまう

その瞬間、プロジェクトは崩れ始めます。

今回はプロジェクトをサッカーに例えて整理してみます。

⚽ プロジェクトをサッカーに例える

まず大きな対応関係です。

監督＝ PM
選手＝エンジニア（PL含む）
サポーター＝顧客

ここで重要なのは次の2点です。

1. PMは選手ではなく監督

PMはピッチでボールを蹴る人ではありません。
チームを勝たせる人です。

2. 顧客は相手チームではなくサポーター

顧客は倒すべき存在ではなく、一緒に勝利を目指す存在です。
相手は「市場」や「課題」であって、顧客ではありません。

各ポジションの役割

それぞれのポジションには、代替できない責任があります。

監督＝ PM

監督はピッチに立ちません。
しかし、試合の勝敗に最も影響を与える存在です。

役割

戦術を決める（目的・優先順位）
チームの方向性を示す
交代・フォーメーション変更を判断する
最終責任を持つ

✅ 良い動き方

ピッチ全体を俯瞰する（目の前の作業に入り込みすぎない）
流れが悪い時に戦術を変える（優先度を調整）
選手を信じて任せる
試合前に戦術を明確に伝える

❌ 悪い動き方

常にベンチから叫び続ける（マイクロマネジメント）
方針を頻繁に変える
責任を選手に押し付ける
自分がピッチに入る（実装に過干渉）

ミッドフィルダー＝ PL

ミッドフィルダーはチームの流れを最も体現するポジションです。
攻守のバランスが崩れると、試合は一気に苦しくなります。

役割

攻守のバランスを取る
パスを回す（情報共有）
チームの流れを作る

✅ 良い動き方

常にパスコースを作る
→ 相談されやすい状態を保つ
味方が詰まったらフォロー
→ レビュー・技術支援
試合のリズムを読む
→ 作業量と負荷を調整

❌ 悪い動き方

ボールを持ちすぎる（抱え込み）
攻撃だけ／守備だけに偏る
情報を止める

フォワード＝開発エンジニア

フォワードの仕事は、結果を出すことです。
チャンスを確実にゴールにつなげることで、試合を動かします。

役割

ゴールを決める（機能を完成させる）
目に見える成果を出す

✅ 良い動き方

パスを受けやすい位置に走る
→ 手が空いたら次のタスクを取りにいく
打てるときは迷わずシュート
→ 仕様が明確なら即実装
無理ならMFに戻す
→ 抱えきれない時はPLに相談
オフサイドにならない
→ 先走った実装をしない

❌ 悪い動き方

パスを待つ（指示待ち）
シュートを打たない（リリースを遅らせる）
ボールを持ちすぎる（相談しない）

ディフェンダー＝テストエンジニア

ディフェンダーの安定はチーム全体の安心につながります。
守備が固まっているからこそ、フォワードは迷いなく攻められます。

役割

失点を防ぐ（バグ・障害防止）
リスクを最小化する

✅ 良い動き方

危険の芽を早めに潰す
→ 仕様矛盾を早期指摘
ラインを揃える
→ コーディング規約を守らせる
無理な攻撃は止める
→ 品質が担保できないものは止める

❌ 悪い動き方

なんでも止める（過剰品質）
攻撃を否定
指摘だけして代替案を出さない

ゴールキーパー＝運用エンジニア

ゴールキーパーは最後の砦です。
他のすべてを抜かれても、ここで止めればゴールを守れます。

役割

最後の砦
障害対応
可用性の確保

✅ 良い動き方

常に最悪を想定
→ 障害シナリオ準備
大きな声で指示
→ 監視・ログ整備
キャッチできないなら弾く
→ 致命傷前にフェイルセーフ

❌ 悪い動き方

反応が遅い
問題を隠す
守備範囲外を放置

サポーター＝顧客

顧客は敵ではありません。
チームが勝つことを最も願っている存在です。

役割

チームの存在理由
評価者
フィードバック

✅ 良い動き方

建設的な応援
→ 具体的フィードバック
長期目線で支える
→ 一時的な不具合で総否定しない

❌ 悪い動き方

戦術に過干渉
結果だけで全否定

おわりに

プロジェクトが崩れるとき、多くの場合、

PMがピッチに入り込み
選手が監督の仕事を始め
顧客を敵として扱ってしまう

という構図になっています。

これはスキルの問題ではありません。
役割の境界が崩れているサインです。

PMは監督としてチームを勝たせる
エンジニアは選手として役割を果たす
顧客はサポーターとして共に勝利を目指す

この前提が揃ったとき、プロジェクトは「チーム」として機能し始めます。