「とりあえずリリースして後で直そう」が、業務を半年間マヒさせた話

納期は絶対だ。細かい不具合は後で直せばいい。上層部からの至上命題を受け、プロジェクトリーダーだった私は、その決断を飲んでしまった。その安易な妥協が、現場にとってどれほど重い「足枷」になるかも知らずに。

「期限」という魔物に憑りつかれたプロジェクト

ある中堅企業の、基幹システム刷新プロジェクト。開発が予定より遅れ、リリース予定日まであと1ヶ月という段階で、深刻なバグがいくつも見つかりました。「部長、このままでは予定通りのリリースは危険です。あと2ヶ月、延期させてください」

私は必死に訴えましたが、返ってきたのは冷ややかな回答でした。「取引先にも既に通知しているんだ。今さら延期なんて恥をかかせるな。動けばいいんだよ、動けば。不具合は運用しながら直していけばいい」

会社側は、バグ修正を「後払いのツケ」程度に考えていました。しかし、ITにおける「後回し」のコストは、金利数千％の闇金のようなものです。

不完全な状態でリリースされたシステムは、案の定、稼働初日から現場に混乱を巻き起こしました。

私たちプロジェクトチームは、不眠不休で「火消し」に追われました。しかし、一度動き始めたシステムを修正するのは、 「時速100キロで走っている車のエンジンを、走りながら交換する」 ようなものです。

1つのバグを直そうとすると、動いている本番データに不整合が出てしまい、また別の不具合が生まれる。開発時に直していれば 1時間で済んだはずの修正に、運用後にはその 10倍、100倍の時間とコストがかかっていきました。

さらに追い打ちをかけたのは、現場の「システム離れ」でした。不具合に疲れ果てた現場スタッフたちは、密かに「以前の紙の伝票」や「個人のエクセル」で業務を回し始めました。システムには、後で思い出したように不正確な数字が入力されるだけ。

せっかく数千万円を投じたシステムは、半年もしないうちに「誰の役にも立たないデータのゴミ捨て場」へと成り下がりました。

システム開発において、フェーズが進むごとに修正コストは指数関数的に跳ね上がります。

「とりあえず出す」という言葉は、前向きな決断のように聞こえますが、実態は「リスクの先送り」に過ぎません。

もし納期が間に合わないのであれば、リリース日をずらすか、あるいは「機能を極限まで絞って、完成している部分だけで出す（MVP）」という判断をすべきでした。不完全なものを無理やり世に出すことは、結果として「現場の信頼」という、最も取り戻すのが難しい資産を失うことになります。