はじめに
Webシステム開発のPL（プロジェクトリーダー）として参画したある案件での出来事です。
世の中には様々なPM（プロジェクトマネージャー）がいますが、中には「コードが書けない・システムのアーキテクチャを理解していないにも関わらず、妙に技術的な仕様に口出ししてくる」タイプの人がいます。
今回は、そんなPMとDockerのインフラ構成を巡って衝突し、最終的に私が「体制変更」という名目でプロジェクトから追放されるまでの生々しい失敗談（とそこから得た教訓）を共有します。
恐怖の提案：「とりあえずDBコンテナ、5個くらい立てて・・・」
プロジェクトの初期段階、ローカルおよび検証環境の構築を進めるために compose.dev.yaml を設計していた時のことです。
DBにはMySQLを採用し、当然ながら標準的な構成（Appコンテナ + DBコンテナ）で進めようとしていました。
そこで、技術的な知識を持たないPMが突然こんな指示を出してきました。
PM：「DBのコンテナなんだけど、とりあえず5個くらい立てて・・・」
私：「……5個ですか？ それはリードレプリカを構築したいとか、マイクロサービス的にデータベースを分割するという意図でしょうか？」
PM：「いや、なんかDBって負荷かかると止まるんでしょ？ 権限とかの問題もあるし最初から5個くらい並べておけば安心じゃないですかね。」
なぜその提案がヤバいのか
インフラやDockerを少しでも触ったことがある方なら、この発言のヤバさが分かると思います。
ただコンテナを5つ並列で起動したところで、データ同期やコネクションの振り分け（プロキシやロードバランサーのレイヤー）、トランザクションの管理をどうするのかという問題が完全に抜け落ちています。
そもそも、本番環境ならまだしも（それでもRDS等のマネージドサービスを使う前提なら）、開発・検証用のDocker環境で無意味に重いDBコンテナを5つも立ち上げれば、PCのリソースを無駄に食らい尽くすだけです。
技術的妥当性 vs PMの謎のこだわり
私はPLとして、システムの品質と開発メンバーの開発体験を守る責任があると勝手に思っていたので、以下のように論理的に説明を試みました。
- リソースの問題: 開発用PCのメモリやCPUを無駄に消費し、開発効率が著しく落ちること。
- 同期の問題: 5つの独立したDBコンテナを立てても、データが自動で分散・同期されるわけではないこと。
- 本番環境との乖離: 本番インフラの構成（クラウドのマネージドDB等）と全く違う構成をDockerで作ると事故る可能性がある。
しかし、システムの根本を理解していないPMには、これらの説明は「PLが自分の指示に逆らうための言い訳」にしか聞こえなかったようです。
完全に平行線でした。
結末：突然の「体制変更」
しかしある日、突然上層部から「プロジェクトの体制変更を行う」と告げられました。
理由はまあ「会社の意向」でした。
結果として、技術的負債を未然に防ごうと奮闘していた私（PL）と開発メンバー全員がプロジェクトから外されました。事実上の追放です。
この経験から得た教訓
この一件で私が学んだのは、以下の3つのことです。
1. 技術的負債のリスクよりも、政治的リスクを察知する
技術的にどれだけ正しい主張をしていても、決定権を持つ人間が「技術的妥当性」よりも「自分の意見が通ること」を優先する場合、論理による説得は無意味です。
2. 「コードが書けないPM」全員が悪いわけではない
コードが書けなくても優秀なPMはたくさんいます。彼らは「自分の管轄外の技術領域については、信頼できるエンジニア（PLやテックリード）に任せる」という線引きが明確です。（偉そうに語っていますが私なんて技術的にまだまだの人間です）
一番危険なのは「技術を知らないのに、マイクロマネジメントで技術決定を下そうとするPM」です。このタイプに遭遇したら、早めにエスケープルートを探すのが正解かもしれません。
3. 逃げるが勝ち
最終的に追放された時は悔しい思いもしましたが、今振り返れば、あのまま「謎のDBコンテナ5個構成」で突き進む泥舟プロジェクトに最後まで付き合わされなくて本当に良かったと思っています。
壊れたアーキテクチャの尻拭いをするのは、いつだって現場のエンジニアだからです。
おわりに
最後までお読みいただきありがとうございました。無意味なコンテナが1つでもこの世から減ることを祈っています。