運用中のサービスを立て直す: 給油デリバリープラットフォームの正常化

最初に必要だったのは修正ではなく、修正する順序でした

目立つエラーから直せば、速く動いているように見えるかもしれません。しかし報告が届く順序と、事業に与える影響の大きさは同じではありません。不便な画面を一つ直しているあいだに、取引を止める問題が残っていることもあります。

引き継ぎの段階では、機能全般の検証で欠陥を確認し、重要度を整理しました。見つかった問題は欠陥台帳にまとめ、補完開発の基準にしました。

欠陥台帳は、エラーを集めておくだけの文書ではありません。運用で直面する問題を、開発が扱える作業に変える接点です。問題があるという話と、どの条件で問題が起きるのかを説明できることのあいだには差があります。

このプロジェクトを理解するうえで重要な順序もここにあります。修正を多くこなすことより、サービスに影響する問題を把握し、改善の順序を決めることが先でした。

大きな入れ替え一回より、週単位の改善を続けました

運用中のサービスを一度に変える方法には負担があります。変更範囲が広がるほど、問題が起きたときにどの修正の影響なのか区別しにくくなり、運用担当者が覚えるべき変化も大きくなります。

N社では固定要員で補完開発を続け、修正内容を週単位でリリースしました。検証で見つかった問題を開発へ渡し、その変更が実際のサービスに反映される流れを繰り返したのです。

ここで、週単位という周期そのものがすべてのプロジェクトの正解ではありません。より重要なのは、修正が長期間たまったまま待たされず、運用の改善につながる経路です。次のリリースで何を変えるのかを説明でき、リリース後もその変更を扱うチームがいなければなりません。

サービスの正常化は、一度の完了宣言よりも、こうした繰り返しに近いものです。エラーを見つけたあとに誰かの答えを待つ時間ではなく、確認した問題を実際の変更へつなげていく過程が必要でした。

QAと開発のあいだに、運用を置き去りにしませんでした

コードを直す人がいても、デプロイ経路を扱う人が別なら、作業はまた止まりかねません。運用で見つけた問題を伝えるときも、同じ説明を何度も繰り返すことになりがちです。

IXCは補完開発とともにクラウド運用を担いました。デプロイと障害対応を、開発・検証と同じチームの中でつなぎました。

同じチームが担うという事実だけでエラーがなくなるわけではありません。この構成の意味は、責任のつながりにあります。検証で明らかになった問題を誰が修正し、修正した結果をどこに反映し、運用中に新たな問題が起きたら誰が再確認するのかがつながります。

機能開発だけを発注するか、既存サービスの保守まで任せるかを検討している組織にとって、ここは区別すべき点です。機能を一つ増やす力と、すでに動いているサービスを変え続ける力は重なりますが、同じ範囲の仕事ではありません。

安定化の次の課題は継続課金でした

サービスの正常化後は、カード自動決済によるビリングを準備しています。定期的に発生する取引を処理するために、料金プラン、決済失敗後の再試行、顧客への案内を先に定める作業です。

継続課金は、カードをもう一度承認する機能とだけ見るわけにはいきません。顧客に請求した状態とサービスが認識する状態が食い違ってはならず、失敗したときの次の行動も決まっていなければなりません。

たとえば、決済応答を受け取れなかったという事実だけで失敗を確定することはできません。すでに処理された取引を二重に請求しないよう確認する手順が必要です。こうした例外を併せて考えて初めて、ビリングは運用できる機能になります。

現在、ビリングの構築は進行中です。正常化の過程で整えた開発・検証・運用の流れをもとに、料金プランと決済の例外条件を次の機能に反映しています。

このプロジェクトが変えたのは、エラー一覧の次の段階でした

N社では、全般的なQAの結果が補完開発の順序につながり、週次リリースとクラウド運用を通じてサービスの正常化を進めました。検証、修正、リリースを別々の作業として残さなかったことが、このプロジェクトの核心です。

既存のサービスを引き継ぐ組織に必要なのは、ソースコードだけではありません。現在の状態を説明できる記録、何を先に変えるかを決める基準、変更を運用に反映できるチームが併せて必要です。

この事例が示すアプローチは明確です。サービスを立て直すとは、最初から作り直すことだけを意味しません。いまの問題を確認し、直し、運用に反映する過程を持続可能にすることでもあります。