序章：IT未経験からPMへ
IT業界に飛び込んで、わずか3ヶ月。右も左もわからないまま、私はPMに任命された。最初に任された案件は、10年がかりで進められてきた基幹システムのリプレイス。しかも、並行して日々の運用保守まで抱えている。
「これは...本当に"ヤバいやつ"かもしれない」と、本能が警鐘を鳴らしていた。
第一章：10年越しの地雷原
この案件、1.5年前にベンダー交代で私の所属する会社が引き継いだが、それまでの8年間は別の会社が開発していた。
そして、誰一人としてコードの奥底を見た者がいない。
唯一決まっていたのは、3ヶ月後のリリース日だけ。
しかも、プロジェクト関係者は約10名。リリースが伸びに伸びて10年という時間が過ぎ、誰もが疑心暗鬼。一歩間違えば爆発四散しかねない状態だった。
第二章：信じるしかなかった
私は、当時の部長と先輩エンジニアの言葉にすがった。
「10年もやってきたんだ。大した問題は起きないだろう」
その言葉を信じ、関係者の疑心暗鬼ポイントを一つずつ潰してまわった。
懸念を可視化し、リスクを潰し、「リリースしても大丈夫」という証明を構築した。
そして迎えたリリース日。
ついにシステムは世に放たれた――
第三章：応答なし
リリース後、1時間でシステムが応答しなくなった。
慌てて調査を始めるも、すでに全関係者が「この機会に起動に乗せたい」と腹を括っていた。
リリースにかけた10年。ここで引き下がれるわけがない。
私たちは、サービスを1週間停止する覚悟を決め、リプレイス側の改修に突入した。
第四章：不眠と胃痛の4日間
ここから先は、地獄だった。
4日間、関係者全員が不眠不休で原因を追い、修正を続けた。
10人のステークホルダーがそれぞれ違う意見をぶつけ合い、場は混乱。
唯一の救いは、私が全意見の矢面に立ち、冷静に捌き続けたことだろう。
その間、エンジニアたちは私の指示のもと、怒涛のように手を動かしてくれた。
そして判明した真実――
新システムは旧システムの2倍以上のメモリを必要としていた。
第五章：切り戻しと奇跡の復旧
リソースのトレードオフにより、切り戻しが決定された。
しかしその際、注文データに不整合が多発してしまった。
私たちは一件一件を手作業で照合・修正。
これが事故ゼロで収束したのは、今でも奇跡としか思えない。
第六章：最恐の真相
数ヶ月後、根本原因がようやく判明した。
原因は、RDBMSに設定されたviewのSQL。
それが異常にメモリを食う設計になっていたのだ。
そしてそのSQLを書いたのは、
あの現場で散々偉そうに無駄な指示を飛ばしていたコンサルタントだった――
終章：代償と報酬
この経験で私は、3ヶ月間胃痛に悩まされる代わりに、鉄の心を手に入れた。
プロジェクトは一度崩れたが、
あの地獄を生き抜いたことで、私は本物のPMになったと思っている。
教訓
- 実アクセスを想定したアクセスクエリで1日の実アクセス相当の負荷試験は絶対やること
※時間がないからとかで簡略化しては絶対にダメ - ベンダー交換案件でコード全体見てリファクタリングする時間取らないケースは絶対詰む
- ベンダー交換の場合、請負側に原因があると思いがちだが受注側にも原因が少なからず存在する
※いじめっ子といじめられっ子どっち悪いの理論と一緒 - 最初から炎上が約束されている案件は意外と身近に存在する
《To Be Continued…》
次章：2人で5人月をこなす日々
乞うご期待。