保守契約が切れた業務アプリをどうするか ── 延命・改修・作り直しの判断表

業務アプリを作った会社との保守契約が、もうすぐ終わる、あるいはもう終わってしまった。アプリは毎日動いているが、次に不具合が出たら誰が直すのか、Windows の更新で動かなくなったらどうするのかが決まっていない。この記事は、社内に開発者がいない会社がこの状態から何を確かめ、どう方針を決めるかを説明します。

答えの要点は3つです。契約が終わる前に、ほかの会社でも保守を続けられるだけのもの（ソースコード、ビルド環境、設計書、アカウント情報、権利の確認）をベンダーから受け取ります。次に、アプリが動いている OS・ランタイム・データベースなどのサポート期限を調べます。そのうえで、手を入れられるか、実行環境のサポートが続くか、業務の変化がどれだけあるか、あと何年使うかの4つで、延命・改修・作り直しを選びます。

対象はベンダーに作ってもらった自社専用の業務アプリ（Windows アプリや社内 Web システム）です。市販のパッケージや SaaS はこの記事では扱いません。契約の解釈は個別の契約書によるので、ここでは IPA のモデル契約の考え方を紹介し、自社の契約書で確かめる点を示します。法的な判断が必要なときは専門家に相談してください。

ソースコードも仕様書も手元に残っていない状態から引き継ぐ場合は「ソースコードも仕様書もないシステムを引き継いだら」、VB6 や Access で作られたアプリの判断は「VB6 / Access業務アプリの延命と移行」を合わせて読んでください。

保守契約が終わると止まる作業

保守契約が終わっても、アプリそのものがすぐに止まるわけではありません。止まるのは、アプリを動かし続けるために誰かがしていた作業です。運用保守の契約に含まれる作業は、たとえば次のようなものです¹。

• 稼働監視、バックアップ、定期メンテナンス
• 操作方法などの問い合わせ対応
• 障害発生時の一次調査・復旧対応
• 不具合の修正
• OS やミドルウェアの更新への追従
• 機能追加・画面変更などの改修

契約が終わると、これらを引き受ける人がいなくなります。困るのは、何かが起きたときです。Windows の更新のあとで帳票が出なくなった、制度改正で計算式を変える必要がある、といった場面で、直せる人を探すところから始めることになります。

flowchart TB
        accTitle: 保守契約の終了で止まる作業
        accDescr: 保守契約が終わってもアプリは動き続けるが、監視、問い合わせ対応、障害対応、不具合の修正、更新への追従、改修を引き受ける人がいなくなり、何かが起きたときに直せる人を探すところから始まることを示す。
        END["保守契約の終了"] --> RUN["アプリは動き続ける"]
        END --> STOP["保守の作業を引き受ける人がいなくなる"]
        STOP --> S1["監視・障害対応・不具合の修正"]
        STOP --> S2["更新への追従・機能追加・改修"]
        RUN -.-> EV["更新や制度改正で変更が必要になる"]
        EV -.-> SEARCH["直せる人を探すところから始まる"]

図1: 保守契約が終わってもアプリは動き続けるが、変更が必要になったときに直せる人がいない。

そのため、契約が終わる前の時間が大事です。ベンダーとの関係が続いているうちなら、必要なものを受け取ったり、質問したりできます。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全6件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

契約が終わる前にベンダーから受け取るもの

ほかの会社に保守を頼む、自社で手を入れる、作り直す、のどれを選んでも、いまのアプリについての情報が要ります。受け取るものは大きく分けて4つです。

flowchart TB
        accTitle: 契約終了前にベンダーから受け取るもの
        accDescr: 契約が終わる前にベンダーから受け取るものを、ソースコードとビルド環境、設計書と運用手順、アカウントとライセンス、権利の確認の4つに分け、どれもほかの会社が保守を続けるために要ることを示す。
        GET["契約終了前に受け取るもの"] --> A["ソースコードとビルド環境"]
        GET --> B["設計書と運用手順"]
        GET --> C["アカウントとライセンス"]
        GET --> D["権利の確認"]
        A --> NEXT["ほかの会社が保守を続けられる"]
        B --> NEXT
        C --> NEXT
        D --> NEXT

図2: 受け取るものは4つに分けられ、どれもほかの会社が保守を続けるために要る。

ソースコードとビルド環境

ソースコードは納品物に含まれているとは限りません。IPA の「情報システム・モデル取引・契約書」では、ベンダーが作成し納入すべき物件（納入物）の明細は個別契約で決めるものとしています²。同じ契約書の解説は、ソースコードや付帯するドキュメントの開示・交付を受けるには、納入物にソースコードを明記するか、エスクロウ制度を活用することで対応できるとしています³。エスクロウ制度はソースコードなどを第三者の機関に預けておく仕組みです。国内では、ソフトウェア情報センター（SOFTIC）がソフトウェアのエスクロウ機関を務めています⁴。

まず自社の契約書と個別契約を開き、納入物の一覧にソースコードが書かれているかを確かめます。書かれていなければ、契約が終わる前に、ベンダーに受け取りの条件を相談します。

ソースコードだけでは、アプリを作り直す（ビルドする）ことはできません。同じ実行ファイルを作るには、ビルドに使った環境もそろえる必要があります。次の表は受け取るときに確かめる項目の例です。

いま動いているものと受け取ったソースコードが一致しているかは、とくに大事です。IPA の解説も、仕様変更や障害対応でソースコードだけを直し、ドキュメントを直さなかったことで、ドキュメントとソースコードと動いているシステムの間にずれが生じる例を挙げています³。

設計書・運用手順・アカウント

ソースコードのほかに、次のものを受け取ります。

• 設計書、画面や帳票の仕様、データベースの定義
• 日々の運用手順書、障害時の対応手順、過去の障害の記録
• サーバーやデータベースの管理者アカウント、外部サービスの契約やアカウント
• ドメイン名やサーバー証明書、ソフトウェアのライセンスキーとその名義

アカウントやライセンスがベンダーの名義になっていると、契約が終わったあとに自社だけでは更新や変更ができないことがあります。名義が誰かを一覧にし、自社の名義に移せるものは移します。

著作権と、手を入れる権利

ソースコードを受け取れても、それを直して使い続けてよいかは、著作権の扱いで変わります。IPA のモデル契約は納入物の著作権について3つの案を用意しています²。

• A 案: 著作権をすべてベンダーに残す
• B 案: 汎用的に使えるプログラムなどはベンダーに残し、それ以外をユーザーに移す
• C 案: 汎用的に使えるプログラムなどはベンダーに残し、それ以外をユーザーとベンダーの共有にする

著作権を移す契約では、翻案権など著作権法第27条・第28条の権利が「譲渡の目的として特掲」されていないと、譲渡した側に残ると推定されます（著作権法第61条第2項）⁵。IPA のモデル契約の条文がこれらの権利を含むと明記しているのは、この規定のためです³。自社の契約書に「著作権を移す」とだけあって第27条・第28条への言及がないときは、改変に関わる権利がベンダーに残っている可能性があります。

著作権がベンダーに残っていても、何もできないわけではありません。著作権法第47条の3は、プログラムの複製物の所有者が自ら電子計算機で実行するために必要な限度で複製することを認めています⁵。IPA のモデル契約の A 案・B 案も、ベンダーに著作権が残る部分について、ユーザーがこの規定に従って複製できることを定めています²。IPA の解説も、プログラムの一定の改変や複製・翻案は複製物の所有者にも著作権法で許されており、著作権を持たないユーザーがほかの会社に保守運用を委託することは可能だとしています³。ただし、どこまでの改修ができるかは個別の契約によるので、契約書を確かめ、迷う場合は専門家に相談します。

flowchart TB
        accTitle: 著作権の扱いと確かめる点
        accDescr: 契約書の著作権の条項を見て、ユーザーに移っている場合は第27条と第28条の権利も明記されているかを確かめ、ベンダーに残っている場合でも複製物の所有者に許される範囲とほかの会社への保守の委託を確かめることを示す。
        C["契約書の著作権の条項"] --> Q{"著作権はどちらにあるか"}
        Q -->|"ユーザーに移っている"| M["第27条・第28条の権利も明記されているか"]
        Q -->|"ベンダーに残っている"| V["複製物の所有者に許される範囲を確かめる"]
        Q -->|"共有になっている"| S["共有の条件を確かめる"]
        M -.-> L["明記がなければ権利が残る可能性"]
        V -.-> O["ほかの会社への保守委託は可能とされる"]

図3: 著作権がどちらにあるかで、確かめる点が変わる。

OS・ランタイム・データベースのサポート期限

業務アプリは OS、.NET Framework などのランタイム、データベース、帳票や通信のミドルウェア、市販のコンポーネントの上で動いています。この記事ではこれらをまとめて実行環境と呼びます。保守契約が終わっても、実行環境の部品のサポート期限は近づいていきます。

Microsoft の製品のうち固定ライフサイクルポリシーが適用されるものには、少なくとも5年のメインストリームサポートがあり、製品によってはその後に延長サポートが続きます⁶。延長サポートの間はセキュリティ更新が提供されますが、設計変更や新機能の要望は受け付けられません。延長サポートが終わると、セキュリティ更新は拡張セキュリティ更新（ESU）プログラムを通じてしか提供されません⁶。

ESU はサポート終了後も古い製品を動かす必要がある顧客のための、最後の手段としての有償の選択肢です。長く使うためのものではなくサポートされる新しい環境へ移るまでの一時的な橋渡しとされ、延長サポートの終了から最長3年までのセキュリティ更新を含みます⁷。製品のライフサイクルそのものを延ばすものでもありません⁷。

flowchart TB
        accTitle: 固定ライフサイクルポリシーの段階
        accDescr: 固定ライフサイクルポリシーの製品が、メインストリームサポート、延長サポート、サポート終了の順に進み、延長サポートではセキュリティ更新が続き、サポート終了後はESUプログラムを通じてだけ最長3年のセキュリティ更新が受けられることを示す。
        MS["メインストリームサポート（5年以上）"] --> ES["延長サポート"]
        ES --> EOS["サポート終了"]
        MS -.-> M1["セキュリティ更新と機能の要望を受け付け"]
        ES -.-> E1["セキュリティ更新は続く"]
        EOS -.-> X1["ESU経由で最長3年のセキュリティ更新"]

図4: 延長サポートが終わると、セキュリティ更新はESUを通じてしか受けられない。

サポート期限は製品とバージョンごとに Microsoft Lifecycle の検索ページで調べられます⁸。ほかの会社の製品もそれぞれのメーカーの公開情報で調べます。調べた結果は次のような一覧にしておきます。

この一覧を作ると、あと何年このまま動かせるか、どの部品から先に手当てが要るかが見えてきます。

延命・改修・作り直しの判断表

ここまでで分かったことを4つの問いに整理します。

1. 手を入れられるか。ソースコード・ビルド環境・改変の権利がそろい、直せる人（ほかの会社を含む）がいるか。
2. 実行環境のサポートが続くか。OS やランタイムなどのサポート終了がいつか。
3. 業務の変更要望がどれだけあるか。制度改正や業務の変化で、画面や計算を変える必要がどのくらい出るか。
4. あと何年使うか。利用を終える時期が決まっているか。

この4つから、次のように方針を選びます。

flowchart TB
        accTitle: 延命・改修・作り直しの選び方
        accDescr: 手を入れられるか、実行環境のサポートが続くか、変更要望が多く長く使うかを順に問い、手を入れられず変更要望も少なければ延命、手を入れられて実行環境がサポート内なら改修、実行環境のサポートが切れていて変更要望も多く長く使うなら作り直しを候補にする流れを示す。
        Q1{"手を入れられるか"}
        Q1 -->|"いいえ"| Q3{"変更要望が多く長く使うか"}
        Q1 -->|"はい"| Q2{"実行環境のサポートが続くか"}
        Q2 -->|"続く・移せる"| KAI["改修"]
        Q2 -->|"切れる"| Q3
        Q3 -->|"いいえ"| EN["延命"]
        Q3 -->|"はい"| TSU["作り直し"]

図5: 手を入れられるか、実行環境のサポートが続くか、変更要望と利用期間で方針を選ぶ。

表と図は目安です。1つのアプリの中でも、帳票の部分だけ作り直し、残りは延命するといった組み合わせがありえます。機能ごとに分けて判断すると、全部を一度に作り直すより小さく始められます。

延命するときの進め方

延命はいまのアプリをできるだけ変えずに使い続ける方針です。手を入れないので費用は抑えられますが、実行環境のサポートが切れたあとはセキュリティ更新を受けられない状態が続きます。そのため、延命は「いつまで」を決めて選びます。

1. 動いている環境を丸ごと保全します。実行ファイル、設定ファイル、データベース、インストーラーを複製し、バックアップから戻せることを確かめます。
2. 実行環境の部品のサポート終了日を一覧にし、いちばん早い日を延命の期限の目安にします。OS が ESU の対象なら、その期間を橋渡しとして使えるかを確かめます⁷。
3. 利用を終える時期と、そのあと何に置き換えるかを決めます。延命している間に、次の方針（改修か作り直し）の準備を進めます。

flowchart TB
        accTitle: 延命の進め方
        accDescr: 延命では、動いている環境を丸ごと保全し、実行環境のサポート終了日から期限を決め、ESUの対象なら橋渡しに使えるかを確かめ、利用終了の時期と次の方針を決める流れを示す。
        A["動いている環境を丸ごと保全"] --> B["実行環境のサポート終了日から期限を決める"]
        B --> C{"OSはESUの対象か"}
        C -->|"対象"| D["ESUを橋渡しに使えるか確かめる"]
        C -->|"対象外"| E["期限までに次の方針を準備"]
        D --> E
        E --> F["利用終了の時期と置き換え先を決める"]

図6: 延命は期限を決めて選び、その間に次の方針を準備する。

改修するときの進め方

改修は受け取ったソースコードに手を入れて使い続ける方針です。社内に開発者がいなければ、新しい保守先（ほかの会社）を探すことになります。

最初に確かめるのは、受け取ったソースコードとビルド環境から、いま動いているものと同じ実行ファイルを作れるかです。作れなければ、受け取ったものが足りないか、動いているものとずれています。この確認の前に機能の改修を始めると、直した箇所とは関係のない違いが紛れ込むおそれがあります。

テストのないアプリに手を入れるときは、直す前のいまの挙動を記録するテスト（特性化テスト）を作ってから変更する方法があります。進め方は「テストのないレガシー業務アプリに安全に手を入れる」で説明しています。

新しい保守先との契約では、監視や問い合わせ対応のような継続的な業務は準委任契約、内容を決められる改修は個別に見積もって請負契約、という使い分けが基本になります¹。保守の範囲の決め方は「受託開発・運用保守の契約はどう結ぶべきか」にまとめています。前の保守契約で起きたことを繰り返さないように、新しい契約では納入物にソースコードを含めることと、著作権の扱いを最初に決めておきます。

flowchart TB
        accTitle: 改修の進め方
        accDescr: 改修では、受け取ったソースコードとビルド環境から同じ実行ファイルを作れるかを確かめ、作れなければ不足やずれを洗い出し、作れれば特性化テストで現在の挙動を記録してから変更し、新しい保守先とは納入物と著作権の扱いを最初に決めることを示す。
        A["受け取ったものからビルドする"] --> B{"同じ実行ファイルを作れたか"}
        B -->|"作れない"| C["不足やずれを洗い出す"]
        C --> A
        B -->|"作れた"| D["特性化テストでいまの挙動を記録"]
        D --> E["変更する"]
        A -.-> F["新しい保守先と納入物・著作権を決める"]

図7: 改修は同じ実行ファイルを作れることを確かめてから始める。

作り直すときの進め方

作り直しは新しい実行環境で業務アプリを作り直す方針です。長く使えるようになる代わりに、いまのアプリが持っている仕様を取りこぼす危険があります。

IPA のモデル契約の解説は、長年運用・保守を続けてきたシステムを再構築するとき、仕様を理解する人がいない、ドキュメントが散逸している、動いているシステムと設計書・ソースコードが整合していない、といった問題があることが少なくないとしています。そのため、要件定義に入る前に現行システムを調査して仕様を明らかにし、再構築に伴うリスクと対策をユーザーとベンダーで共有・合意しておく必要があるとしています³。

同じ解説は「現行踏襲」という要求にも注意を促しています。ユーザーは動いている現行システムがそのまま再現されることを期待する一方、ベンダーは設計書やソースコードに書かれた内容を拠り所にするので、両者の思う「現行」にずれが生じることがあります³。「いまと同じに」と頼むだけでは足りず、何を同じにするのかを書き出して合意します。

一度に全部を置き換えず、機能ごとに少しずつ新しいシステムへ移す方法もあります。ストラングラーフィグパターンは既存のシステムの前に要求の振り分け役（ファサード）を置き、機能を少しずつ新しいシステムへ移して、最後に古いシステムを止める移行の方法です⁹。ただし、古いシステムへの要求を途中で受け止められない場合や、ソースコードにもデータベースにも手を入れられない場合には向かないとされています⁹。

flowchart TB
        accTitle: 作り直しの進め方
        accDescr: 作り直しでは、現行システムを調査して仕様を書き出し、現行踏襲の中身をユーザーとベンダーで合意し、一度に置き換えるか機能ごとに移すかを選び、機能ごとに移す場合はファサードで要求を振り分けて最後に古いシステムを止めることを示す。
        A["現行システムを調査する"] --> B["仕様を書き出す"]
        B --> C["現行踏襲の中身を合意する"]
        C --> D{"一度に置き換えられるか"}
        D -->|"置き換えられる"| E["新システムへ切り替える"]
        D -->|"難しい"| F["機能ごとに新システムへ移す"]
        F --> G["最後に古いシステムを止める"]

図8: 作り直しは現行の調査と「現行踏襲」の中身の合意から始める。

契約が終わる前と後でできること

最後に、時期ごとにできることを並べます。契約が終わる前なら、ベンダーに受け取りや質問を頼めます。終わったあとは、手元にあるものと、動いているシステムから調べられることが頼りになります。

flowchart TB
        accTitle: 契約終了の前と後でできること
        accDescr: 契約が終わる前はベンダーから資料と権利の確認を受け取り、実行環境のサポート期限を調べ、方針の候補を決め、契約が終わったあとは受け取ったものと動いているシステムの調査をもとに方針を進めることを示す。
        subgraph before ["契約が終わる前"]
            B1["ソースコード・資料・アカウントを受け取る"] --> B2["著作権の扱いを確かめる"]
            B2 --> B3["実行環境のサポート期限を調べる"]
            B3 --> B4["方針の候補を決める"]
        end
        subgraph after ["契約が終わった後"]
            A1["受け取ったものを確かめる"] --> A2["動いているシステムを調べる"]
            A2 --> A3["延命・改修・作り直しを進める"]
        end
        B4 --> A1

図9: 契約が終わる前はベンダーから受け取り、終わった後は手元のものと動いているシステムを頼りにする。

もう契約が終わっていて、ソースコードも資料も手元にない場合は、動いている環境の保全と、挙動からの仕様の復元から始めます。その手順は「ソースコードも仕様書もないシステムを引き継いだら」で説明しています。

関連記事

• ソースコードも仕様書もないシステムを引き継いだら
• VB6 / Access業務アプリの延命と移行
• 受託開発・運用保守の契約はどう結ぶべきか
• テストのないレガシー業務アプリに安全に手を入れる
• Windows 10サポート終了後の現実解

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

保守契約が切れても業務アプリは使い続けられますか？

保守契約が終わってもアプリが止まるとは限りません。ただし、障害の調査や不具合の修正、OSやミドルウェアの更新への追従を引き受ける人がいなくなります。使い続けるなら、ほかの会社が保守を引き継げるように、ソースコードやビルド環境、設計書、アカウント情報を契約が終わる前に受け取っておきます。

ソースコードは納品物に含まれているはずですか？

含まれているとは限りません。IPAのモデル契約では、納入物は個別契約で決めるものとされ、ソースコードの開示・交付を受けるには納入物にソースコードを明記するか、エスクロウ制度を使うとされています。まず自社の契約書と個別契約の納入物の一覧を確かめてください。

著作権がベンダーに残っていると、ほかの会社に保守を頼めませんか？

IPAのモデル契約の解説は、プログラムの複製物の所有者には著作権法で一定の複製や翻案が許されており、著作権を持たないユーザーもほかの会社に保守運用を委託できるとしています。ただし、どこまでできるかは個別の契約の条項によるので、契約書を確かめ、必要なら専門家に相談します。

延命・改修・作り直しはどう選べばよいですか？

自社やほかの会社が手を入れられるか（ソースコード・ビルド環境・権利がそろうか）、OSやランタイムのサポートが続くか、業務の変更要望がどれだけあるか、あと何年使うかの4つで判断します。手を入れられず、変更要望も少なく、利用終了の時期が見えているなら延命、手を入れられて実行環境もサポート内なら改修、実行環境のサポートが切れていて変更要望も多いなら作り直しが候補になります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。