はじめに
システム開発の現場では、こんな光景をよく見ます。
- PMがレビューだけでなく、コードを書き始めてしまう
- 顧客の要望を「また無茶を言ってくる」と敵視してしまう
その瞬間、プロジェクトは崩れ始めます。
今回はプロジェクトをサッカーに例えて整理してみます。
⚽ プロジェクトをサッカーに例える
まず大きな対応関係です。
- 監督 ＝ PM
- 選手 ＝ エンジニア（PL含む）
- サポーター ＝ 顧客
ここで重要なのは次の2点です。
1. PMは選手ではなく監督
PMはピッチでボールを蹴る人ではありません。
チームを勝たせる人です。
2. 顧客は相手チームではなくサポーター
顧客は倒すべき存在ではなく、一緒に勝利を目指す存在です。
相手は「市場」や「課題」であって、顧客ではありません。
各ポジションの役割
それぞれのポジションには、代替できない責任があります。
監督 ＝ PM
監督はピッチに立ちません。
しかし、試合の勝敗に最も影響を与える存在です。
役割
- 戦術を決める（目的・優先順位）
- チームの方向性を示す
- 交代・フォーメーション変更を判断する
- 最終責任を持つ
✅ 良い動き方
- ピッチ全体を俯瞰する（目の前の作業に入り込みすぎない）
- 流れが悪い時に戦術を変える（優先度を調整）
- 選手を信じて任せる
- 試合前に戦術を明確に伝える
❌ 悪い動き方
- 常にベンチから叫び続ける（マイクロマネジメント）
- 方針を頻繁に変える
- 責任を選手に押し付ける
- 自分がピッチに入る（実装に過干渉）
ミッドフィルダー ＝ PL
ミッドフィルダーはチームの流れを最も体現するポジションです。
攻守のバランスが崩れると、試合は一気に苦しくなります。
役割
- 攻守のバランスを取る
- パスを回す（情報共有）
- チームの流れを作る
✅ 良い動き方
- 常にパスコースを作る
→ 相談されやすい状態を保つ - 味方が詰まったらフォロー
→ レビュー・技術支援 - 試合のリズムを読む
→ 作業量と負荷を調整
❌ 悪い動き方
- ボールを持ちすぎる（抱え込み）
- 攻撃だけ／守備だけに偏る
- 情報を止める
フォワード ＝ 開発エンジニア
フォワードの仕事は、結果を出すことです。
チャンスを確実にゴールにつなげることで、試合を動かします。
役割
- ゴールを決める（機能を完成させる）
- 目に見える成果を出す
✅ 良い動き方
- パスを受けやすい位置に走る
→ 手が空いたら次のタスクを取りにいく - 打てるときは迷わずシュート
→ 仕様が明確なら即実装 - 無理ならMFに戻す
→ 抱えきれない時はPLに相談 - オフサイドにならない
→ 先走った実装をしない
❌ 悪い動き方
- パスを待つ（指示待ち）
- シュートを打たない（リリースを遅らせる）
- ボールを持ちすぎる（相談しない）
ディフェンダー ＝ テストエンジニア
ディフェンダーの安定はチーム全体の安心につながります。
守備が固まっているからこそ、フォワードは迷いなく攻められます。
役割
- 失点を防ぐ（バグ・障害防止）
- リスクを最小化する
✅ 良い動き方
- 危険の芽を早めに潰す
→ 仕様矛盾を早期指摘 - ラインを揃える
→ コーディング規約を守らせる - 無理な攻撃は止める
→ 品質が担保できないものは止める
❌ 悪い動き方
- なんでも止める（過剰品質）
- 攻撃を否定
- 指摘だけして代替案を出さない
ゴールキーパー ＝ 運用エンジニア
ゴールキーパーは最後の砦です。
他のすべてを抜かれても、ここで止めればゴールを守れます。
役割
- 最後の砦
- 障害対応
- 可用性の確保
✅ 良い動き方
- 常に最悪を想定
→ 障害シナリオ準備 - 大きな声で指示
→ 監視・ログ整備 - キャッチできないなら弾く
→ 致命傷前にフェイルセーフ
❌ 悪い動き方
- 反応が遅い
- 問題を隠す
- 守備範囲外を放置
サポーター ＝ 顧客
顧客は敵ではありません。
チームが勝つことを最も願っている存在です。
役割
- チームの存在理由
- 評価者
- フィードバック
✅ 良い動き方
- 建設的な応援
→ 具体的フィードバック - 長期目線で支える
→ 一時的な不具合で総否定しない
❌ 悪い動き方
- 戦術に過干渉
- 結果だけで全否定
おわりに
プロジェクトが崩れるとき、多くの場合、
- PMがピッチに入り込み
- 選手が監督の仕事を始め
- 顧客を敵として扱ってしまう
という構図になっています。
これはスキルの問題ではありません。
役割の境界が崩れているサインです。
- PMは監督としてチームを勝たせる
- エンジニアは選手として役割を果たす
- 顧客はサポーターとして共に勝利を目指す
この前提が揃ったとき、プロジェクトは「チーム」として機能し始めます。