ソースコードがないシステムは保守を引き継げるのか｜引き継ぎを断念して刷新に至った実例

長く使ってきたシステムについて、開発したベンダーから「保守を終了したい」と通告された。別の会社に引き継いでもらえばよいと考えたものの、手元にソースコードがないことに気づいた——この記事は、そうした状況に置かれた発注者に向けたものです。

ソースコードがないとなぜ保守を引き継げないのか

システム保守とは、動いているシステムに手を入れ続ける仕事です。不具合の修正も、法改正や業務変更への対応も、セキュリティ更新も、すべてソースコードを書き換えることで実現します。ソースコードとは、システムの動作そのものを記述した設計図であり、これがなければシステムの中身を変更する手段が存在しません。

ここが、仕様書がない場合との決定的な違いです。仕様書がなくてもソースコードさえあれば、コードを読み解くことで仕様を復元し、保守を続けられます。実際の進め方は仕様書なしのシステム保守引き継ぎで解説しています。しかしソースコードがない場合、読み解く対象そのものがありません。

この状態で新しい保守会社を探しても、引き受けられる会社は見つかりません。断られているのは会社の能力の問題ではなく、変更する手段がないという物理的な理由です。

ソースコードが手元にないという状況はどう起きるか

発注者が意図的にソースコードを手放すことは、まずありません。多くは契約時の取り決めと納品物の確認が抜けたまま、年月が経過したことで起きます。

• 開発時の契約に、ソースコードの納品や著作権の帰属についての取り決めがなかった
• 納品物として受け取ったのは動くシステムだけで、ソースコードは開発会社が保持していた
• 担当者の交代が重なり、納品物がどこにあるか社内で分からなくなった
• 開発会社との関係が続いている間は問題にならず、保守終了の通告を受けて初めて発覚した

共通しているのは、開発会社との関係が良好なうちは何も起きないという点です。問題が表面化するのは、関係が切れる瞬間です。ソースコードの所在確認を含む初動については開発会社と連絡が取れない・倒産した場合にやることもあわせてご覧ください。

実例：保守終了の通告から刷新に至るまで

FUNBREWが実際に相談を受けた案件です。あるシステムについて、それを開発したベンダーから保守終了の通告がありました。理由は、そのベンダーにそのシステムを保守できる要員がいなくなったというものでした。

相談を受けて調べたところ、発注企業の手元に、元々開発されたシステムのソースコードがありませんでした。つまり、私たちが引き継ぐとしても、コードを改修する手段がない状態です。何かあっても直せないシステムの保守を引き受けることはできませんでした。

お客様の当初のご要望は、そのシステムをそのまま使い続けたいというものでした。日々の業務で使えている以上、当然の希望です。しかし改修できないという事実は変わらず、そのシステムは作られてから10年ほど経過したものでもありました。最終的には、そのまま使い続けるのではなく、システムを刷新するという形になりました。

「そのまま使い続ける」は選択肢になるか

今動いているのだから、触らずに使い続ければよいのではないか。この考え方は、短期的には成立します。改修しなければ壊れないシステムも実際にあります。

ただし、触らないという判断が有効なのは、システムの外側が変わらない間だけです。実際には、次のような外部要因が改修を必要とさせます。

• サーバーやOS、ミドルウェアのサポート終了に伴う移行
• ブラウザや外部サービスの仕様変更による動作不良
• 法改正や社内制度の変更に伴う処理の見直し
• 脆弱性が公表された際のセキュリティ対応

いずれも、システム側は何もしていないのに対応が必要になる種類の変化です。ソースコードがない状態でこれらに直面すると、対応する手段がないまま業務が止まります。「そのまま使い続ける」は、選択肢というより、いつ来るか分からない期限までの猶予期間だと考えるのが実態に近いといえます。

引き継ぐか刷新するかの判断基準

ソースコードの有無を確認したうえで、次のように整理すると判断しやすくなります。引き継ぎ全般で確認すべき点は他社開発システムの保守引き継ぎにまとめています。

• ソースコードがある：仕様書がなくても引き継ぎは可能。まず引き継ぎ先を探す
• ソースコードがない・所在不明：改修手段がないため保守の引き継ぎは成立しない。刷新を前提に検討する
• ソースコードの権利関係が不明：契約書と納品物を確認し、使用・改変の可否を先に確定させる

刷新に傾く条件

ソースコードがない場合でも、刷新には相応の費用と期間がかかるため、即断はできません。判断を刷新側に傾けるのは、次のような条件です。

• システムが作られてから年数が経ち、当時の技術基盤が現在の標準から離れている
• 動作環境そのもののサポート終了が視野に入っている
• 業務側の要件が当時から変わっており、どのみち手を入れる必要がある

先ほどの実例で刷新という結論になったのも、改修手段がないことに加えて、システムが作られてから10年ほど経過していたことが理由でした。改修できない状態で古い基盤を維持し続けるより、作り直したほうが結果的に安全だという判断です。

まとめ

ソースコードが手元にないシステムは、引き継ぎ先が見つかっても改修する手段がないため、保守を継続できません。断られる理由は能力ではなく、変更手段の不在です。

FUNBREWが相談を受けた案件でも、ベンダーの保守要員がいなくなったことによる保守終了の通告があり、ソースコードが手元にないために引き継ぎは成立しませんでした。そのまま使い続けたいというご要望はありましたが、作られてから10年ほど経過していたこともあり、最終的にはシステムを刷新する形になりました。

保守終了を通告されている、あるいはソースコードの所在が分からないという場合は、お問い合わせよりご相談ください。現状で何ができるかの切り分けからお手伝いします。