ECサイトを24時間止めた夜。PMの私が「信頼」という言葉で放置したもの
PMが本当に管理すべきもの
深夜0時。
リリース作業が始まりました。
ECサイトは24時間365日稼働が前提です。サイトを止めるには少なくとも1週間前からユーザーへの告知が必要で、作業時間帯はアクセスが最も少ない深夜に限られます。この日もそのルール通りの深夜スタートでした。
メンバーは私、プログラマ、運用メンバーの3名。統括のマネージャーが1名いましたが、リリース作業への参加はありませんでした。段取りは決めてありました。手順書もあります。あとは予定通りに進めるだけだ、そう思っていました。
今回の改修の核心は、ログイン認証の仕組みを刷新することでした。ユーザーが再ログインせずにそのまま使い続けられる、シームレスなログイン継続が要件です。そういう前提でリリースに臨んでいました。
作業開始前、プログラマに最終確認を取りました。
深夜0時、それぞれが自宅から作業に入りました。画面の向こうに3人いる。チャットと通話でつながっているだけで、互いの表情は見えません。外では誰も起きていない時間帯です。
「問題ないですよね」
「はい、大丈夫です」
即答でした。その迷いのなさを、私は信頼の証だと思いました。今振り返ると、あれは自信ではなく、不安を隠すための即答だったのかもしれません。ただ、その時の私にはわかりませんでした。作業を開始しました。
午前4時。動作確認の結果が返ってきました。
ログインが、できませんでした。
第一部 午前4時 最初の独断
リリース後の動作確認は、私が直接テストをしていました。ログイン画面は表示されます。IDとパスワードを入れて送信する。ただ、そこから先に進めない。何度やっても、同じ画面に戻ってくる。
シームレスにログインできるという要件が、まったく動いていませんでした。
プログラマにチャットでメッセージを送りました。
「ログインできません。確認してください」
返信はありませんでした。
時計を見ました。午前4時15分。サイトの再オープンまであと45分。年商数十億規模のECサイトです。今この瞬間も、ログインしようとした誰かが画面の前で首をかしげ、別のサイトへと去っていく。その数が、分単位で積み上がっています。
クライアント側の担当者への第一報は、私が入れました。ログインができない状態になっていること、原因の特定を急いでいること。淡々と事実だけを伝えたつもりでした。
電話口の声が変わったのは、それから数秒後でした。
怒鳴り声が始まりました。
受話器を耳に当てながら、もう片方の手でチャット画面を開きました。プログラマへのメッセージを打ちます。
「状況を教えてください」
返信が来ません。
「今何をしていますか」
沈黙。
「作業を止めてください。まず状況を報告してください」
……。
返信は、来ませんでした。
電話口では怒鳴り声が続いています。損失額の試算を口にしながら、責任の所在を問い続ける。私は相槌を打ちながら、画面を見続けました。返信のないメッセージだけが、画面に積み上がっていきました。
意図的な判断でした。電話はとにかく発散させる。落ち着いてもらわなければ、その後の対応協議ができません。だから、聞き続けました。
ただその間、プログラマが黙々と作業を続けていました。
彼は原因を「認証データの引き継ぎ」の問題と判断し、既存の認証関連データをすべて削除したんです。「再ログインすれば使えるようになる」という考えで、私への報告も確認もなく実行しました。
これが、先方の怒りにさらに火をつけました。
「再ログインなしで使い続けられる」という要件を実現するためのリリースで、その認証データを全削除した。要件を自ら潰したも同然の行動です。損失額の試算を口にしながら、責任の所在を問い続ける声が電話口から止まりません。
受話器を握りしめながら、頭の中では別のことを考えていました。
プログラマと、早く話さなければならない。
第二部 収束しない連鎖
最初の電話がようやく終わりました。先方が「状況を確認する」と言い出したタイミングで、通話が切れました。
一瞬、空気が変わった気がしました。怒鳴り声がやんだだけで、状況が好転したような錯覚を覚えます。深夜から朝にかけての疲労が、判断を甘くしていたのかもしれません。
削除された認証関連データを復旧させ、改めてシームレスログインの動作確認を行いました。
今度こそログインできる。そう思っていました。
ログインは、でませんでした。
認証データの削除が原因ではなかった。問題は最初から、プログラム自体にありました。認証の切り替え処理に誤りがあり、ログイン状態を正しく引き継げない実装になっていたんです。
希望は、一瞬で消えました。
時刻は朝7時を過ぎていました。オープン予定の時間を2時間超過して、サイトが使えない状態が続いています。
2度目の電話が始まりました。先方への状況報告と対応協議です。
1度目の電話で2時間以上怒鳴られた後です。正直、受話器を取る手が重かった。ただ、かけなければならない。現状を伝え、対応方針を協議する。それがPMの仕事です。
またチャット画面を開きました。
「プログラムの不具合の可能性大です。まだ、作業は行わないでください」
既読。返信なし。
電話が終わりました。プログラムとデータの確認を始めた瞬間、おかしいと気づきました。
データの更新日時です。大量のレコードが、本日付けに変わっています。リリース手順の中に、そんな処理はありません。
プログラマにビデオ通話をつなぎました。
「このデータ、今日更新されていますね」
「……はい」
「なぜですか」
しばらく間がありました。
「データにパッチを当てました」
「えっ！いつですか」
「2度目の電話中です」
「なぜ報告しなかったんですか」
また間がありました。今度は少し長かった。
「簡単に直せると思ったので」
「それだけですか」
「……自分の評価が下がるから、被害を最小限に収めたかった…」
その瞬間、リリース開始直前の光景が頭をよぎりました。
「問題ないですよね」「はい、大丈夫です」
あの即答の意味が、今になってわかりました。
後になって、なぜそこまで怖かったのかを確認しました。彼には、以前のプロジェクトで失敗してこっぴどく怒られた経験があったそうです。今回も同じことになると、最初から恐れていた。
私は驚いて聞き返しました。「私があなたを怒ったことがあったか」と。
「ないです」と彼は答えました。「でも、失敗すれば怒られると思っていました」
私は言葉を失いました。怒ったことは一度もない。それでも彼の目には、私は「失敗を許さない人間」として映っていた。その誤解を解く機会を、私は一度も作れていなかったんです。
悪意がなかったとは、もう言えませんでした。評価を守るために、報告を止めた。その間も状況は悪化し続けていました。
ただ、後になって冷静に考えると、彼の立場も見えてきます。まだプロジェクトに参加して半年。日本の職場で評価が下がることへの恐怖は、私が想像する以上のものだったかもしれません。
「報告すれば怒られる、ならば自分で直す」という判断に至った背景には、そういうプレッシャーがあったのだと思います。だからといって、隠蔽が正当化されるわけではありません。ただ、責任の全てを彼に押しつけることもできませんでした。
2度にわたって、電話中に独断で動いていた。そしてどちらも、事態を悪化させた。
朝方、サイトの再オープンの中止を決断しました。
第三部 24時間の停止
朝8時、サイト停止とシステムの切り戻しを決断しました。
「戻す」と一言で言いますが、その作業は単純ではありませんでした。今回の改修では複数の要素が絡み合っていたからです。
まず、ログイン認証のプロダクト自体を元に戻す必要があります。次に、朝方の確認でわかったことですが、新しい仕組みでログインできていたユーザーが一部存在していました。その人たちのセッション情報を、元のデータベースに正確に戻さなければなりません。さらに、新しい仕組みに合わせて変更していた各種設定も、すべて元の状態に戻す。
それぞれが独立した作業ではありません。順番を間違えれば、新たな問題が発生します。
まず有識者を集めて会議を開きました。
「どの順番で戻すか」を議論しながら、時間が過ぎていきます。プロダクトを先に戻すべきか、データを先に整合させるべきか。手順を間違えれば、新たな問題が発生するリスクがあります。慎重にならざるを得ない。しかしその慎重さが、また時間を食う。
画面の向こうでは、サイトが止まり続けています。
「どの順番で、何を戻すか」が決まったのは、昼過ぎでした。深夜から作業を続けていた体が、いつの間にか汗ばんでいました。自宅の窓から見える景色は、いつも通りです。世界は普通に動いているのに、画面の中だけ時間が止まったようでした。
手順書を作り直し、クライアントに内容を説明して承認を得て、ようやく作業を開始しました。
作業に入ると、今度は逆に時間が加速しました。一つ一つの手順を確認しながら進めているのに、気づくと夕方になっていて、気づくと夜になっていました。
作業が完了したのは夜の10時過ぎ。
最終確認を終えてサイトが再開したのは、夜中の12時でした。
深夜0時のリリースから数えて、24時間。年商数十億規模のECサイトが止まり続けました。
始末書を書きました。
深夜、一人でキーボードを打っていました。経緯を整理しながら書くのですが、書けば書くほど、問題の根がどこにあったかが見えてきます。プログラマの独断ではない。テストの不備でもない。その前に、私がやるべきことをやっていなかった。そういう文章になっていきました。
ふと、クライアントの担当者のことを考えました。
深夜0時から付き合わされ、24時間後にようやくサイトが復旧した。その間、怒鳴り続けた先方の担当者も、翌日には自分の上司から相当な叱責を受けたはずです。私のちょっとした心の緩みが、先方に金銭的な損失を与え、担当者に計り知れないストレスを与えた。
始末書を書きながら、その担当者の顔が浮かびました。怒鳴り続けた声の奥に、どれほどの焦りと恐怖があったか。当日は受話器を握りしめながら耐えることしかできませんでしたが、今は、あの怒りの正体がわかる気がします。
クライアントへの損害賠償の話が始まりましたが、その後の金額的な決着については私には知らされませんでした。それがどれほどの規模になったかは、今も正確にはわかりません。あの夜のサイトが24時間止まった、という事実だけが残りました。
第四部 結局、私が悪かった
この件を振り返るたびに、同じ結論に辿り着きます。
プログラマの独断も、隠蔽も、確かに問題でした。ただ、それを引き起こした土壌を作ったのは私です。
① コードレビューを省いていました。
スケジュールの都合もありましたし、プログラマへの信頼もありました。「大丈夫だろう」という判断が、最初のドミノを倒しました。レビューで問題を発見できたかどうかは、正直わかりません。ただ、省いた事実が起点にあったのは確かです。
② テストが不十分でした。
テスト環境では都合の良いデータしか使っていませんでした。本番環境には、想定していなかった多様なデータが存在します。その確認を怠った。そしてそれを見逃したのは、プログラマだけではなく私でもありました。
当時、私は3つのプロジェクトを並行して抱えていました。このプロジェクトに割ける目が足りていませんでした。「優秀だから大丈夫だろう」という過信が、テスト内容の確認を省かせました。
③ サイトが止まるという現実を、本当には理解していませんでした。
これが、今振り返ったときに最も痛感することです。
コードレビューを省いたのも、テストを甘くしたのも、結局は「まあ大丈夫だろう」という感覚があったからです。年商数十億規模のサイトが止まったとき、何が起きるか。損失額だけではありません。
深夜に購入しようとしたユーザーが画面の前で首をかしげる。翌朝出社したクライアントの担当者が青ざめる。経営層への報告が走る。社内で責任の所在が問われ始める。ベンダーへの怒りの電話が鳴り続ける。そして最終的に、誰かが始末書を書く。
それが自分のこととして、具体的に想像できていませんでした。
リリース作業は「技術的な作業」ではありません。ビジネスの命綱に触る行為です。その感覚が、あの夜の私には欠けていました。
想像できていれば、手を抜けなかったはずです。
④ リリース時の指揮系統も決めていませんでした。
問題が発生したときに誰が何をするかを、事前に決めていませんでした。だから私が電話対応に縛られた瞬間に、現場の指揮が消えました。感情対応と現場指揮は、1人では同時にこなせません。あの朝に痛感しました。
⑤ 平時のコミュニケーションが足りていませんでした。
プロジェクト参画半年のメンバーが「報告すれば評価が下がる」と感じていた。そういう関係性しか作れていなかった責任は、PMである私にあります。悪い情報が上がってくる環境は、有事の当日には作れません。
この経験が変えたこと
あの夜以来、リリース前に必ず自分に問いかけることにしています。
「もしこのサイトが止まったら、何が起きるか」
これを具体的に想像できるまで、作業に入りません。想像できれば、省けるものが何もないことがわかります。コードレビューも、テストも、指揮系統の取り決めも、メンバーとの関係構築も。すべてが「止まったときのための保険」だと理解できます。
この問いは、リリース作業だけに使うものではありません。プロジェクトのあらゆる判断の前に立てられます。「このレビューを省いたら」「このテストを簡略化したら」「この確認を後回しにしたら」。想像が具体的であるほど、手を抜けなくなります。
プロジェクトマネージャーが管理するのは、スケジュールでも進捗でもありません。突き詰めると、人と判断の連鎖を管理することです。
その連鎖が正しく機能するかどうかは、有事ではなく平時に決まります。
機能させるのは、今日の仕事です。
現場からは、以上です。
付録：二度とサイトを止めないための「PM最終チェックリスト」
重要なリリースを控えているなら、以下の項目を自分自身に問いかけてみてください。
指揮系統の分離：トラブル発生時、あなたは「電話の相手」をしますか。それとも「現場の指揮」を執りますか。この2つを同時に演じることは不可能です。誰が対外対応を担い、誰が現場を指揮するか。事前に決めてあるかどうかが、有事の分岐点になります。
物理的な安全装置：本番環境へのアクセスは制限されていますか。誰かがパニックになっても、独断で書き込みができない仕組みになっていますか。人の意志や誠実さは、極限状態では脆く崩れます。仕組みで防ぐしかありません。
撤退ラインの明文化：何が起きたら切り戻しを開始するか、事前にクライアントと合意していますか。「まだ直せる」という希望的観測を排除するための判断基準を、あらかじめ数字で持っていますか。
情報の透明性：あなたが電話で話している間も、現場で何が起きているかをリアルタイムで把握できる共有の場所はありますか。既読スルーは、指揮の消失と同義です。
心理的安全性の担保：チームメンバーに対し、「ミスを隠すこと以外はすべて許す」と、明確に言葉にして伝えましたか。伝えていなければ、メンバーは「怒られる」という過去の経験から判断します。あなたの意図は、言わなければ伝わりません。
