ドキュメントのないPHP決済システムを引き継ぎ、17年間保守している話
株式会社グルーヴサイン代表取締役の米沢です。
弊社は、他社が開発したPHPシステムの保守や引き継ぎを主な業務としています。
ただ、「PHPシステムの保守・引き継ぎ」と書くだけでは、実際にどのような仕事をしている会社なのか、なかなか伝わりにくいかもしれません。
そこで今回は、弊社が最も長く担当している案件についてご紹介します。
2009年に決済代行会社のシステムを引き継ぎ、17年が経過した現在も保守を続けている事例です。
「分からないことは前任者に聞いてください」から始まった
会社を設立して2年ほど経った2009年、知人から相談を受けました。
これまで開発を任せていたエンジニアを担当から外すことになったので、代わりにシステムを見てもらえないか。
対象となったのは、決済代行会社が運営するシステム一式でした。
ユーザー向けの決済画面、運営会社の管理画面、加盟店向けの管理画面があり、クレジットカード、銀行、コンビニなど、複数の決済手段に対応していました。
ユーザー数は数万人、加盟店は約100社、管理画面だけでも100画面を超える規模です。
後から聞いた話では、私が選ばれた理由は、技術力だけではなかったようです。
それまでの仕事を通じて、コミュニケーションの取り方や責任感を評価していただき、「長期間任せられそうだ」と判断してもらえたとのことでした。
止めることのできない業務システムを任せる相手を選ぶ際には、技術力と同じくらい、連絡の取りやすさや継続して対応する姿勢も重視されるのだと思います。
システムは、フレームワークを使用しない、いわゆる「素のPHP」で作られていました。PHPのバージョンは5系で、仕様書や設計書などのドキュメントも、ほとんど残っていませんでした。
引き継ぎ時に言われたのは、
分からないことは前任者に聞いてください。
ということだけです。
実際に前任者へ質問できたのは、最初の半年ほどでした。その後は、ソースコードと実際の動作を確認しながら、自分で仕様を読み解いていくことになりました。
その約1年後には、別の決済代行会社が使用しているシステムも引き継ぐことになりました。
こちらも同程度の規模で、EthnaというPHPフレームワークを使用して作られていました。Ethnaは現在では採用例が少なく、対応できるエンジニアも限られているフレームワークです。
興味深いことに、この2社目のシステムを開発したのも、1社目と同じエンジニアでした。
会社やシステムは異なっていても、プログラムの構成や命名、設計には同じ開発者の癖が表れます。1社目のシステムを読み解いた経験が、2社目の引き継ぎでも大いに役立ちました。
この記事では、この2社の決済システムを保守してきた経験をあわせてお話しします。
最初に行ったのは、テスト環境の整備
システムを引き継いで、最初に行ったのはテスト環境の整備でした。
本番環境へ影響を与えることなく、調査や修正、動作確認ができる場所を用意するためです。
地味な作業に見えるかもしれませんが、既存システムを安全に引き継ぐうえでは、最も重要な工程の一つです。
その後、決済画面や管理画面を実際に操作しながら、ソースコードとデータベースの内容を照らし合わせ、少しずつ仕様を確認していきました。
現在のような生成AIはありませんでしたので、当時はすべてのコードを自分で読み、一つひとつ処理を追いかけて理解するしかありません。
「なぜこのような構造になっているのだろう」と頭を抱えることも、一度や二度ではありませんでした。
しかし、クライアントから依頼される修正や機能追加を一つずつ対応するうちに、画面、データベース、バッチ処理、外部システムとの連携が、どのようにつながっているのか理解できるようになりました。
システムの構造だけでなく、クライアントの業務や運用方法も分かるようになると、調査や修正にかかる時間も次第に短くなっていきました。
長期間稼働している業務システムを引き継ぐ際には、画面上のプログラムだけを見ても全体像は把握できません。
ソースコード、データベース、サーバー構成、cronなどの定期処理、外部API、メール送信、ファイル生成、バックアップ、そして実際の運用手順まで確認する必要があります。
重大障害から学んだ、決済システム保守の原則
17年間も保守を続けていれば、重大な障害に直面したこともあります。
特に記憶に残っているのは、1社目のシステムで発生した銀行決済の再実行障害です。
このシステムでは、決済処理ごとにトークンを発行していました。そのトークンの生成方法を変更した際、決済済みのデータが未決済と判定され、数百件の決済処理が再実行されてしまいました。
処理はcronによって自動実行されていたため、異常に気づいた時点では、すでに多数の処理が動いた後でした。
幸い、加盟店側のシステムに重複決済を防止する仕組みが備わっていたため、金銭的な実害は発生しませんでした。
しかし、決済処理に加えた一つの変更が、想定を超える範囲へ影響する可能性があることを、改めて痛感する出来事でした。
この障害以降、決済に関係する修正については、変更内容の大小にかかわらず、テスト環境で十分に検証し、影響範囲を確認したうえで本番環境へ反映することを徹底しています。
また、単体の処理だけでなく、前後のデータや定期処理、外部システムとの連携まで含め、一連の業務フローとして確認するようになりました。
特別に新しい方法ではありません。
それでも、お金を扱うシステムの保守に近道はなく、基本的な確認を省略しないことが最も重要です。
この障害は、その原則を強く認識するきっかけになりました。
複数システムが関わるPCI DSS対応
もう一つの大きな山場は、2社目のシステムで行われたPCI DSS対応です。
PCI DSSとは、クレジットカード情報を安全に取り扱うために定められた、クレジットカード業界のセキュリティ基準です。
2016年頃から、その対応の一環として、PHPで動いていたクレジットカード決済機能の一部を、C#で構築された新しいシステムへ移行するプロジェクトが始まりました。
複数の会社とシステムが関係する大規模な移行で、結果として完了までに2年から3年ほどかかりました。
リリース後には、新旧システム間の連携やデータ更新のタイミングに起因する不整合が表面化しました。
- 決済を実行できない
- 決済自体は完了しているが、結果が正常に記録されていない
- データを手動で補正しなければならない
といった事象が発生しました。
複数のシステムをまたぐ問題では、どの処理で不整合が発生したのかを特定するだけでも時間がかかります。
当時は連日、ログ、データベース、外部システムから返された結果を照合しながら原因を切り分け、必要なデータ修正を行いました。
深夜まで対応する日が1週間ほど続き、体力的にも精神的にも厳しい状況でした。
一方で、この経験を通じて、障害が発生した際に慌てず、次のように対応することが身につきました。
- 事実と推測を分ける
- 影響範囲を確認する
- 処理の流れを一つずつ追う
- 関係者と情報を共有する
- 復旧と恒久対策を分けて考える
以降は、難しい障害が発生しても、状況を整理しながら落ち着いて対処できるようになったと感じています。
この2社目のシステムは、その後、クライアントの社内事情により事業そのものが停止し、それに伴って保守契約も終了しました。
弊社との関係が悪化したわけではなく、事業が終了するその日までシステムを保守し、円満に契約を終えています。
保守という仕事は、機能を追加したり、不具合を直したりするだけではありません。
必要であれば、システムの役割が終わる最後の日まで、安全に稼働させ続ける仕事でもあります。
なぜ17年間、契約が続いているのか
1社目のシステムは、現在も弊社が保守を続けています。
長期間の運用を経てシステムは安定しており、大きな不具合が発生することはほとんどありません。
修正依頼も、週に1件あるかないかという状態です。
それでも17年間にわたって契約が続いているのは、単にPHPのプログラムを修正できるからではないと思っています。
日常的にはRedmineやChatworkを使って依頼や報告を行い、緊急時にはTeamsのチャットで直接相談を受けています。
長く関わるうちに、システムだけでなく、クライアントの業務、社内の役割分担、過去の判断や経緯についても理解するようになりました。
そのため、技術的な問題なのか、運用上の問題なのかが明確になっていない段階でも、
まず米沢さんに聞いてみよう。
と相談していただけることがあります。
保守という仕事は、ソースコードを修正するだけではありません。
システムと業務を継続して理解し、何かあったときにすぐ相談できる関係を維持することまで含めて、保守だと考えています。
現在は、不具合調査や機能修正だけでなく、次のような領域も継続して担当しています。
- サーバー移行
- PHPやOSの更新
- データベース
- 定期バッチ
- 精算関連処理
- 銀行や決済事業者との外部連携
AIによって、レガシーシステムの保守はどう変わったか
技術面では、近年、大きな変化がありました。
現在は、既存コードの調査、改修方針の検討、実装、テスト項目の整理などに、生成AIを本格的に活用しています。
以前であれば1日から数日かかっていた調査や修正が、内容によっては1時間ほどで完了することもあります。
仕様書がなく、長年にわたって修正が積み重ねられたレガシーコードの解析は、生成AIが力を発揮しやすい領域の一つです。
関連するファイルや処理を横断的に確認し、処理の流れを整理したり、変更による影響範囲の候補を挙げたりする作業は、以前より効率的になりました。
ただし、AIに指示すれば、すべて正しく自動で修正されるわけではありません。
機能追加や修正の内容を伝えても、実際に調査を進めると、仕様の矛盾、考慮されていない例外、過去の運用に由来する特殊な処理などが見つかります。
その内容に気づき、クライアントの業務や過去の経緯と照らし合わせ、
- 本当にこの仕様でよいのか
- 既存の運用へ影響しないか
- 別の処理もあわせて変更する必要がないか
と判断するのは、現在も人の仕事です。
AIは非常に強力な道具ですが、システムや業務への理解がなければ、出力された内容が正しいかどうかを判断できません。
17年間かけて積み重ねてきたシステムとクライアントへの理解があるからこそ、AIを安全かつ効果的に活用できる。
私たちは、そのように考えています。
同じような状況でお困りの方へ
これまで、次のようなご相談を受けてきました。
- 開発会社と連絡が取れなくなった
- 担当エンジニアが退職してしまった
- 仕様書や設計書が残っていない
- 古いPHPで作られており、対応できる会社が見つからない
- サーバーやPHPを更新したいが、システムが動かなくなるのが不安
- 全面リニューアルを提案されたが、費用やリスクが大きい
- 他社が作ったシステムという理由で、保守を断られた
ドキュメントがなくても、前任者がいなくても、既存システムを引き継ぐことは可能です。
実際に稼働しているソースコードとデータベース、サーバー、そして日々の運用には、これまで積み重ねられてきた仕様や判断が残されています。
実際に動いているコードこそが、最も正確な仕様書です。
それを読み解き、安全に維持できる状態へ整えることが、私たちの仕事です。
同じような状況でお困りでしたら、まずは現在の状況をお聞かせください。
ソースコードが手元になくても、システムの構成が分からなくても、うまく説明できなくても問題ありません。
お話を伺いながら、何を確認し、どこから着手すべきかを整理します。
レガシーPHPシステムの保守・引き継ぎのご相談を受け付けています。
初回のご相談・ヒアリングは無料です。