業務委託で受けている.NETの業務アプリの保守。定例で次の改修の相談をしていると、発注元の方が「この画面はもう長いあいだ同じ版のままで、更新の予定は特にありません。分かるのは、そちらだけなので、引き続きお願いします」と言いました。頼られた安心の裏で、この保守にはいつ終わりが来るのかという不安が顔を出します。.NETのフリーランスが古い保守を抱え続けると、自分しか分からない箇所と更新されない部品だけが増え、手を引く時期を逃しかねません。古い保守は、続ける理由より、手放す条件を先に決めます。

1. 古い.NETの保守が手放しにくい理由

頼られる安心と、出口の無さ

保守を長く受けていると、発注元から頼られる場面が増えます。仕様を知っている、障害の切り分けができる、改修の見積もりが早い。どれも受ける側の評価につながるものです。ただし、頼られている状態は、代わりに任せられる人がいない状態でもあります。一人に集まった頼みごとは、発注元から見れば安定した体制ですが、受ける側から見れば抜けにくい持ち場です。

書き手の見立てでは、古い版のまま更新の予定が無い業務アプリで、この傾向が強まります。部品を入れ替える計画がなければ、保守の仕事は同じ箇所の手直しと障害対応が中心になります。そのため、新しく覚える技術は増えず、このシステムでしか通用しない知識だけが厚くなっていきます。ここで言う知識は、動いている理由を知っているという意味で、本人にとっては財産でもあります。

頼られることと出口が無いことは、同じ状態の表と裏です。表だけを見ていると、続ける理由はいくらでも見つかります。裏に気づいたときには、引き継げる人も文書も残っていない形になりがちです。手を引く時期を逃す不安は、この表と裏を別々の話として扱うところから生まれます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

積み上がるものは、本人にしか見えない

この四つは、日々の作業の中では目立ちません。自分しか分からない箇所は、動いている限り問題として表に出ません。更新されない部品は、障害が起きて初めて話題になります。一人で抱える当番は、休める日が続くうちは負担として数えられません。手順が頭の中にあるうちは、文書が無くても仕事は回ります。

ただし、四つは別々に増えるのではなく、互いを強めます。文書が無いから自分しか分からず、自分しか分からないから当番も代われません。部品が更新されなければ、直す箇所の癖は古いまま残り、手順はさらに頭の中へ溜まります。一つ手放そうとして、ほかの三つにも手をつける必要が出てくるのが、この保守の手放しにくさです。

では、この状況を、発注側の業界はサポートの終わった部品についてどう見ているのでしょうか。

2. サポートが終わった部品への、発注側の業界の見方

金融庁の分析レポートに出てくる記述

発注側に規制当局がいる業界では、サポートの終わった部品の扱いが公の文書に書かれています。ここでは金融機関を例に、金融庁が2026年7月30日に公表した「金融分野におけるITレジリエンスに関する分析レポート」の記述を見ます。レポートが語るのは金融機関と委託先の話で、一般の業務アプリの発注元にも同じ要請がかかる、という意味ではありません。

レポートは、サポート期限の終了に伴うハードウェアやソフトウェアの廃止・更改について、計画的かつ安全に実施するための更新計画が十分に整備されていない事例が認められたとしています¹。書かれているのは事例の存在までで、そうした金融機関がどのくらいあるかは示されていません。

金融庁は2026年5月22日にも、日本銀行と連名で、各金融機関等に対し、経営層の直接関与の下でAIによるサイバー脅威の変化への対応に取り組むよう要請しています¹。要請の相手は金融機関等で、主題はAIによるサイバー脅威の変化への対応です。保守を受ける側に向けた要請ではなく、レガシー移行そのものを求めた要請でもありません。

同じレポートは、金融機関等向けの対応の項目として「特定した資産の技術負債を解消しておく」を掲げています。未対応パッチの適用等で技術負債を極力解消し、特にサポートが終了している製品はサポート対象のバージョンへ更新する、という内容です¹。製品名や版の指定は、この項目には出てきません。

レポートの記述を並べて見る

下の表は、三つの記述を、レポートの中の位置づけと向けられた相手ごとに並べたものです。同じレポートに入っていても、事例の記述、日本銀行との連名の要請、対応の項目は別の節の記述なので、一つの調査結果としては束ねていません。共通しているのは、すべて金融機関等についての記述であることです。受託者の契約や引き継ぎについての事実は、このレポートの中にありません。

レポートの記述	中身	向けられた相手
更新計画の整備	サポート期限の終了に伴う廃止・更改について、更新計画が十分に整備されていない事例が認められた1	金融機関の事例
2026年5月22日の要請	金融庁と日本銀行の連名で、経営層の直接関与の下でAIによるサイバー脅威の変化への対応を要請1	金融機関等
掲げられた対応の項目	サポートが終了している製品は、サポート対象のバージョンへ更新する1	金融機関等

発注元の更新計画が、最初の分かれ目

金融機関の例が示すのは、サポート期限の終了を前にした更新の計画が、事例としてレポートに書かれるところまでです。そこから先は書き手の見立てになりますが、発注元に更新の計画があるかどうかが、保守を続けるか手放すかを考える最初の分かれ目になると見ています。

計画があれば、サポートの終わった部品をいつ置き換えるかを発注元と話せます。計画が無ければ、保守の依頼だけが続き、受ける側は終わりの時期を知らないまま当番を持つことになります。そのため、定例の場で更新の予定を尋ねることが、続けるか手放すかを考える最初の材料になります。次は、その更新の作業を誰が持つのかを決める契約の中身です。

3. 保守契約で受けている範囲の確かめ方

レポートが掲げる確認の項目

同じレポートが掲げる金融機関等向けの対応には、「ベンダーとの維持保守契約の内容を確認する」という項目があります。パッチ適用作業が現行の維持保守契約に含まれていること、及び役割分担が明確であることを確認するよう求めています¹。確認するのは金融機関等の側で、相手はベンダーです。

ここからが読み替えです。フリーランスの業務委託では、受ける側が保守の受託者で、立場がレポートとは逆になります。書き手は、この二つの項目を、自分の契約書を読む観点として移してみることを勧めます。レポートが受託者に求めている内容ではなく、立場を入れ替えた読み方です。

パッチ適用の作業が契約に入っているかは、受けている保守の仕事の範囲を決めます。入っていなければ、更新の作業を頼まれても契約の範囲外の追加作業になり、入っていれば、更新のたびにその作業まで受けることになります。契約の文言は案件ごとに異なるため、条項は手元の契約書で確かめます。

役割分担が明確かどうかは、障害が起きたときの動きに関わります。発注元のどの部署が連絡を受け、どこまでを受託者が直し、どこからを発注元が判断するのか。書き手の見立てでは、ここが決まっていない保守ほど、判断が一人に集まります。

見立てとして足す三つの項目

更新の作業は誰が持つか、契約の終わり方の条項、引き継ぎの期間。この三つは金融庁のレポートの記述ではなく、書き手が足した見立ての項目です。レポートの二つと同じ並びで置くと、出典のある部分と無い部分が混ざって見えるため、分けて示します。

出典：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月30日）をもとに作成。左の列だけが同レポートの項目で、右の列は書き手の見立てです¹

更新の作業の持ち主を決めておかないと、更新の計画が動き出したときに、保守の延長として一人で頼まれる場合があります。契約の終わり方の条項は、手を引くときにいつ、どの形で伝えるかを決めます。引き継ぎの期間は、手を引くと決めた後に何を渡せるかの上限になります。

契約を読み直す作業は、手を引くと決めてから始めるのでは遅くなります。続ける場合も、移行を提案する場合も、この五つが決まっているかどうかで、次に取れる動きの幅が変わります。次は、移行の話に入る前に、文書がどこまで残っているかを見ます。

4. 文書が残っているかで変わる移行の難しさ

金融機関の側が挙げた課題と回答

金融庁のレポートは、金融機関のシステム統合・更改について、障害時の影響が大きく必要な知識の専門性が高いため、プロジェクト遂行の難度が高いとしています。そのうえで金融機関の課題として、システム仕様書等の開発文書の整備と、有識者の適切な配置によるレビュー体制の整備等を挙げています¹。

別の箇所では、他の共同センターへの乗換えが困難となる技術的要因が確かめられています。回答で最も多かったのは「特になし」でした。一方で、「ベンダー仕様の把握」「リソース不足」「データ移行」の観点から困難との回答もありました¹。回答の数や割合は、この記事では取り上げません。

ここで取り違えないでおきたい点があります。この二つは、金融機関の側の課題と、金融機関が乗換えを考えたときの回答で、.NETの業務アプリの移行についての記述ではありません。開発文書が無ければ移行が失敗する、という因果をレポートは書いていません。

移行の難しさについての記述を並べて見る

次の表は、二つの記述を、挙がった要因と対象ごとに分けたものです。上段の課題は金融機関のシステム統合・更改についての記述で、下段の回答は他の共同センターへの乗換えについての別の記述です。同じレポートに載っていても調査の場面が違うため、同じ母集団の結果としては読めません。移行の難しさを一つの数字で比べることはできず、挙がった要因の種類を見る表です。

挙がった要因	レポートの記述	対象
開発文書の整備	システム仕様書等の開発文書の整備を課題として挙げている1	金融機関のシステム統合・更改
レビュー体制の整備	有識者の適切な配置によるレビュー体制の整備等を課題として挙げている1	金融機関のシステム統合・更改
乗換えが困難となる技術的要因	「ベンダー仕様の把握」「リソース不足」「データ移行」の観点から困難との回答もあった。最も多かった回答は「特になし」1	他の共同センターへの乗換え

自分しか分からない箇所を文書にする

ここから先は書き手の見立てです。自分しか分からない箇所を文書にしておくことは、続けるにしても手を引くにしても、先に要る作業だと考えています。続ける場合は、休める体制や、代わりの人へ頼むときの下地になります。手を引く場合は、渡せるものの質を決めます。

金融庁のレポートが挙げた開発文書の整備は、金融機関の課題として出てきたものです。ただ、受ける側の保守にも同じ向きで役立つと見ています。文書にする対象は、全体の設計書ではなく、自分の頭の中にしか無い部分から始めます。たとえば、障害のたびに自分が行う切り分けの順序や、設定に触れるときの注意点です。次は、続ける・移行を提案する・引き継いで手を引く、の三つを分ける条件に進みます。

5. 手放す条件を先に決める

三つの問いで、進む道を分ける

手放す条件は、続けている最中ではなく、まだ余裕のあるうちに決めます。書き手の見立てでは、使うのは前の三つの節で出てきた問いです。発注元に更新の計画はあるか、契約の範囲は明確か、文書は残せるか。この三つの答えの組み合わせで、続ける、移行を提案する、引き継いで手を引く、のどれに進むかが分かれます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

更新の計画があり、契約の範囲も明確なら、続けながら文書を整える道が開けます。計画はあるのに契約の範囲が曖昧なら、まず契約の読み直しを発注元に申し出ます。一方、計画が無いまま契約の範囲も曖昧であれば、移行を提案するか、手を引くかの二択に近づきます。

期限と状態で、条件を言葉にする

条件は、期限と状態の二つで書きます。期限は「いつまでに更新の計画が出なければ」の形で、状態は「サポートの終わった部品が残ったまま、一人で当番を抱えている」の形で決めます。数字の期限を一律に示すことはしません。契約の期間や発注元の予定によって、適切な長さが変わるためです。

条件を決めたら、定例の場で一度だけ発注元に伝えます。たとえば、次の契約の更新の前に更新の予定を教えてほしい、と尋ねる形です。条件を先に伝えておけば、手を引くときに突然の話にならず、発注元も代わりの体制を考える時間を持てます。

状態の条件には、他の案件との兼ね合いも含めます。当番を一人で抱える状態が長引くと、続けるか手を引くかの判断そのものが後ろへずれていきます。次は、手を引くと決めたときに何を渡し、どう伝えるかです。

6. 手を引くときの引き継ぎと伝え方

流用の事例から見る、部品の出どころ

金融庁のレポートの事例では、銀行が勘定系システムの老朽化に伴い更改を実施した際、上流工程で別プロジェクトの資産・機能を流用したときに別プロジェクトの実績を過信したことが、稼働直後のATM障害の原因として挙げられています¹。流用すると障害が起きる、という意味ではなく、実績を過信した点が原因に挙がった一つの事例です。

ここから先は書き手の見立てです。他の案件から流用した部品の出どころを残すことは、引き継ぎの項目に入れたいと考えています。別の場所で動いた実績は、いまの業務アプリで同じように動く保証にはなりません。出どころが分かれば、引き継ぐ側が確かめる範囲を絞れます。

引き継ぎで渡すものの一覧

下の表は、手を引くときに渡すものを五つに分け、中身と残す理由を並べたものです。五つとも書き手の見立てで、金融庁のレポートに載っている項目ではありません。共通しているのは、どれも自分の頭の中にあるうちは文書に現れない点です。渡す相手は、後任の保守担当にも、発注元にも、移行を担う別の受託者にもなりえます。誰が受け取っても読める形にしておくと、引き継ぎの期間の中で説明に使う時間を短くできます。

渡すもの	中身	残す理由
構成の一覧	画面・処理・外部とのつなぎ・使っている部品の一覧	全体を見渡す起点になります
手順	障害時の切り分け、定期作業、リリースの手順	頭の中にある手順の置き場になります
未対応の指摘	気づいていながら手をつけていない問題の一覧	引き継ぐ側が負債の所在を知る材料になります
既知の不具合	再現の条件と、暫定の回避策	同じ調査の繰り返しを避けられます
流用した部品の出どころ	他の案件から持ち込んだ部品と、その元	確かめる範囲を絞れます

伝える時期は契約の条項に従う

伝える時期は、契約の条項に従うのが基本です。契約の終わり方の条項に事前に知らせる期間が書かれていれば、その期間を前提に、条件の伝達と引き継ぎの日程を組みます。この記事は契約書の解釈を示すものではありません。個別の契約の読み方は、契約書そのものと、必要に応じて専門家に確かめます。

引き継ぎの期間は、契約に書かれた期間の中に収めるのが前提です。期間に収まらなければ、延ばせるかどうかを発注元と協議します。先に渡すものの一覧を作っておけば、協議の場で必要な期間を具体的に示せます。次は、手を引くのではなく、移行の仕事へ移る場合の受け方です。

7. 移行の仕事へ移るときの受け方

保守で得た知識が、移行の入口になる

保守で得た「どこが動いていて、どこが分からないか」の知識は、移行の入口になります。これは書き手の見立てです。移行の仕事では、まず現状を棚卸しする場面が来ます。長く保守を受けてきた人は、動いている箇所と、自分でも分からない箇所の境目を知っているため、棚卸しの入口に立てます。

分からない箇所が残っていること自体は、棚卸しの成果になります。何が分からないかを一覧にして示せば、移行の範囲を区切るときの材料として使えます。ただし、動いている理由まで説明できる範囲と、動いているのを見ているだけの範囲は、分けて伝えます。

移る順番と、それぞれの中身

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

更新計画の提案は、第2節で見た「発注元に更新の計画があるか」とつながります。計画が無い発注元には、棚卸しの結果を材料に、置き換えの順序を示す形で提案します。移行の範囲の区切りは、全部を一度に動かす案ではなく、動かす部分と当面残す部分に分ける案です。契約の切り替えは、保守の契約から移行の仕事の契約へ、範囲と期間を決め直す段階を指します。

頼られた場面に、条件を持って戻る

冒頭の定例の場面に戻ります。「分かるのは、そちらだけなので、引き続きお願いします」と言われたとき、続ける理由はいくらでも挙げられます。そのとき支えになるのは、手放す条件を先に決めてあることです。頼られた安心は、条件があって初めて、出口のある安心に変わります。

更新の計画、契約の範囲、文書の三つについて、期限と状態を自分の言葉で決めておけば、続けるときも、移行を提案するときも、引き継いで手を引くときも、同じ判断軸で動けます。移行の仕事へ移るなら、Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。登録して、自分の保守の経験に近い条件を確かめるところから始められます。

古い保守は、続ける理由より、手放す条件を先に決めます。決めておけば、次の定例で「引き続きお願いします」と言われても、続けるのか、移行を提案するのか、引き継ぐのかを、自分の条件で答えられます。

8. よくある質問

古い版の保守だけで、フリーランスとして続けていくことはできますか

続けられる場合もあります。書き手の見立てでは、分かれ目は更新の計画と契約の範囲です。更新の計画があり、契約の範囲が明確で、文書を残せる状態なら、続けながら整える道があります。計画も契約の範囲も曖昧なままなら、期限と状態の条件を先に決めておきます。

移行を提案しても発注元が見送ったら、どうしますか

手放す条件を先に伝えてあれば、見送られたこと自体が判断の材料になります。条件に当てはまるなら、引き継ぎの準備に移ります。伝える時期と引き継ぎの期間は、契約の条項に従います。

VB.NETの資産でも同じ考え方で判断できますか

判断できます。分かれ目は言語ではなく、更新の計画、契約の範囲、文書の三点です。VB.NETでもC#でも、サポートの終わった部品が残るかどうかと、その状態で当番を一人で抱えるかどうかは、同じように問われます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月30日・2026年10月確認）