前任者のソース管理が失われかけた会員システムを、救済して2段階で改修した事例｜システム保守
制作内容
「コードが残っているうちに手を打てた」話
制作会社を通じて、全国組織の資格認定団体が運用されている会員システムの改修をご依頼いただきました。
この記事は「前任者に連絡が取れないシステムを引き継ぐことになった」「今のうちに触っておかないとまずい気がする」という方に読んでいただきたい内容です。
クライアント概要
- 業種: 全国組織の資格認定団体（会員制）
- 規模感: 全国組織
- 依頼: 会員システムの機能改修2件（認定番号の表示、受講履歴のCSV取込とマイページ表示）
- 体制: 制作会社を通じた二次請け
課題・依頼背景（Before）
ご依頼は機能改修2件でしたが、調査に入って分かったのは、その手前に別の問題があることでした。
- 前任の開発者が使っていたソース管理サーバに接続できず、履歴をたどれない
- そのままではコードの正本がどこにあるのか確定できない
- 本番環境で動いてはいるが、次に誰かが触るときの足場がない
機能を足す以前に、このシステムのコードが失われかけている状態でした。動いている間は問題が表面化しませんが、サーバの入れ替えや障害が起きた時点で復旧の手立てがなくなります。
改修そのものも、単純ではありませんでした。会員一人ひとりに紐づく認定番号の表示ルール、年度をまたぐ受講履歴の扱い、外部から受け取るCSVの様式のばらつきなど、確認すべき点が複数ありました。
提案・解決アプローチ
最初にお伝えしたのは、機能改修の前に調査と救済の工数が必要だということです。見積でも調査を独立した項目として提示し、「なぜその費用がかかるのか」を金額の前に説明しました。
次に、リリースの進め方です。2つの機能をまとめて一度に本番へ反映する案もありましたが、見送りました。会員システムは動いていることが前提の仕組みで、まとめて反映して問題が出たとき、どちらの機能が原因かの切り分けが難しくなるためです。
検証環境についても、本番と同じサーバ上に作る案は採っていません。お客様側でご用意いただいたテスト機に複製環境を構築し、本番から切り離した状態で検証しました。
| 選択肢 | メリット | 見送った理由 |
|---|---|---|
| 2機能を一括で本番反映 | リリース作業が1回で済む | 問題発生時に原因の切り分けが難しい |
| 本番サーバ上に検証環境を作る（採用せず） | 環境差が出ない | 本番へ影響が及ぶ経路を作ってしまう |
| テスト機に複製環境＋2段階リリース（採用） | 本番と切り離して検証でき、切り分けもできる | ─ |
実装内容
- 前任者のソース管理が使えない状態からの調査と、コードの正本の確保
- お客様のテスト機への複製環境の構築（接続はパスワードから鍵認証へ切り替え）
- 機能①：認定番号の表示改修（先行リリース）
- 機能②：受講履歴のCSV取込とマイページへの表示
- 取り込み手順とロールバック手順の文書化
- 反映前の状態を本番上に退避し、必要時に戻せる状態を維持
CSVの取込では、見出し行の有無や並び順といった様式のばらつきを想定した確認項目を用意し、手順書に反映しています。
成果
機能①②とも本番へ反映済みで、稼働しています。2段階に分けたことで、機能①の反映結果を確認してから機能②に進むことができました。
作業の途中で、お客様へお渡しする記入要領の資料に実在の会員名が例として混入していることに気づき、除去した上でお渡ししています。当初の依頼範囲ではありませんが、そのまま配布されると個人情報が広がるため、こちらで見つけた時点で対応しました。
また、改修とは別に発生していたマイページの表示エラーについては、原因調査と修正を行った上で費用をいただいていません。実作業が小さく、切り分けの過程で判明したものだったためです。
本プロジェクトで大切にしたスタンス
ポイント1：調査費を値引きの対象にしなかった理由
調査は成果物が目に見えにくく、真っ先に削られやすい項目です。それでも今回は、前任者のソース管理へ接続できずコードが失われかけていた状況を具体的に説明し、独立した項目として計上しました。
ここを削って機能改修だけを進めれば、目先の費用は下がります。しかし「次に誰かが触るときの足場がないまま機能だけ増える」ことになり、数年後の引き継ぎがさらに難しくなります。
ポイント2：一括リリースを選ばなかった理由
会員システムは、会員の方が日常的にログインして使う仕組みです。まとめて反映して問題が出た場合、影響が出るのはお客様ではなく会員の方々になります。
リリース回数が増える手間より、問題が起きたときに原因を1つに絞れることを優先しました。あわせて、反映前の状態を本番上に退避し、戻す手順を文書に残しています。
ポイント3：依頼範囲外の個人情報の混入をそのままにしなかった理由
資料に実在の会員名が例として入っていた件は、依頼された作業とは無関係でした。指摘せずに納品しても、契約上の問題にはなりません。
それでも、その資料は今後会員の方へ配布される想定のものです。気づいた側が黙っていれば、混入したまま広がります。範囲外であっても、見つけた時点でお伝えして直すほうが結果的に双方の負担が小さいと判断しました。
本事例の総括とポイント
- 依頼は機能改修2件だったが、着手前の調査で「コードの正本が失われかけている」状態が判明した
- 調査を独立した項目として見積に計上し、金額の前に必要な理由を説明した
- 本番とは切り離したテスト機に複製環境を構築し、接続は鍵認証へ切り替えた
- 2機能の一括反映は見送り、機能①を先行させる2段階リリースで進めた
- 反映前の状態を退避し、ロールバック手順を文書として残した
- 依頼範囲外だった資料への実在会員名の混入を発見し、除去した上でお渡しした
- 切り分けの過程で判明した表示エラーの修正は、実作業が小さいため無償で対応した
こんな方はご相談ください
前任者と連絡が取れないシステムの改修や、引き継ぎ先が不在のまま動いている仕組みでお困りの方は、無料相談からご相談ください。
- 情シス代行サービス: 現状の調査から、壊さない改修・引き継ぎ可能な状態への整備まで、まとめてご相談いただけます → /services/it-outsourcing/
Others
その他の制作実績
