基幹システム（会社の中心となる業務を動かす仕組み）の保守案件は、新しく仕組みを作る案件とは仕事の形が異なります。稼働開始という区切りに向かって進む開発とは違い、保守はそこから先の期間そのものが仕事の中心になります。この記事では、保守案件で長く負うことになる中身と、参画する前に確かめておきたい順番を整理します。

1. 期間が長いこと自体が条件

「作って終わり」ではない仕事の形

保守の案件には、明確な完成形が用意されているわけではありません。稼働している仕組みを止めずに動かし続けることそのものが、日々の仕事の中身になります。

短い区切りで終わる開発案件とは異なり、保守の案件は稼働している期間だけ続きます。区切りが先に決まっている仕事ではなく、続くことを前提にした仕事です。

短期の開発案件のリズムより、続くことを前提にしたリズムのほうが、参画したあとの実感に近くなります。期間が長いこと自体を、まず1つの条件として受け止めておくと、案件の中身を見誤りにくくなります。

新しく仕組みを作る案件では、要件を固めて形にする作業が中心になります。保守の案件では、すでに動いている仕組みを前提に、変化に対応し続ける作業が中心になります。中心となる作業の性質が異なる点も、期間の長さと合わせて押さえておきたいところです。

日常的な対応として位置づけられている

デジタル庁がまとめた方針では、継続的なアップデートへの対応が挙げられています²。更新への対応は一度きりの出来事ではなく、日常の中で対応していく仕事として位置づけられています³。

更新のたびに新しい案件が立ち上がるわけではなく、同じ案件の中で更新への対応が繰り返されます。ここに、保守案件の期間が長くなる理由と、日常的な対応が求められる理由が重なっています。

期間の長さと、対応の頻度。この2つを合わせて見ておくと、保守案件で求められている仕事の形がつかみやすくなります。次の章では、この日常的な対応の中身を具体的に見ていきます。

日常的な対応として組み込まれている案件ほど、担当する人にとっては仕事の見通しを立てやすくなります。逆に、対応の頻度が読めない案件では、参画してから負担の実感がつかみにくくなります。

図の作成：Remogu編集部。保守案件で長く負うことになる仕事を整理したもので、統計データではありません

2. 更新への対応は毎月ある仕事

出来事として構えると起きること

更新への対応を、年に数回の出来事のように構えてしまうと、実際の頻度とずれが生じます。継続的なアップデートへの対応が挙げられている以上²、対応の間隔は思っているよりも短く、頻繁に訪れます。

出来事として構えた体制では、更新のたびに人を集め直し、手順を思い出すところから始まります。この繰り返しは、負担として積み重なりやすい進め方です。

更新への対応は、通常の業務の一部として日常の中で対応していく方向性が示されています³。出来事として身構えるより、日常の一部として組み込むほうが、負担の感じ方は軽くなります。

出来事として構えた体制のまま長く続けると、対応のたびに前回の経緯を振り返る手間が積み重なります。振り返る手間が増えるほど、実際の作業時間よりも段取りに時間がかかるようになります。

毎月の仕事として組み込むと変わること

毎月ある仕事として位置づけると、確認する項目や進め方があらかじめ決まった形になり、繰り返しの中で対応の精度が上がっていきます。出来事として構えるときとは、体制の作り方そのものが変わります。

保守の案件でこの2つの構え方の違いを理解しておくと、どちらの進め方を前提にした案件なのかを、参画する前に見分ける材料になります。

構え方の違いは、日々の負担だけでなくクライアントとのやり取りの仕方にも表れます。次の比較表では、出来事として構えた場合と、毎月の仕事として組み込んだ場合の違いを並べます。

毎月の仕事として組み込まれた案件では、対応の記録も自然に積み重なっていきます。積み重なった記録は、次に似た更新が来たときの手がかりにもなります。

同じ更新対応でも、構え方によって日々の進め方が変わります

更新への対応を出来事として構えるか、毎月の仕事として組み込むかによって、体制の作り方や確認する項目、クライアントとの共有の仕方まで変わってきます。同じ更新対応という仕事でも、構え方が違うだけで日々の負担の感じ方は変わります。ここでは、2つの構え方を横に並べて比べます。どちらの前提で動いている案件なのかを、参画する前に見分ける材料にしてください。

観点	出来事として構えた場合	毎月の仕事として組み込んだ場合
体制の作り方	更新のたびに人を集め直す	あらかじめ決まった体制で対応する
確認する項目	その都度洗い出す	繰り返しの中で決まった形になる
対応の間隔	間隔が空き、感覚をつかみにくい	日常の中で感覚をつかみやすい
クライアントとの共有	更新のたびに個別に説明する	定例の中で継続して共有できる

図の作成：Remogu編集部。更新への対応の構え方の違いを整理した概念図で、統計データではありません

3. 終了する機能の入れ替え

終了は前もって知らされる

使っているサービスが終了する場合は、終了の時期と代わりの機能が前もって知らされます¹。何の前触れもなく機能が消えるわけではなく、切り替える先を確かめる時間があります。

前もって知らされるからこそ、保守を担う側には確認と入れ替えの作業が発生します。知らされて終わりではなく、そこから先の対応こそが保守案件の中身になります。

終了する機能の入れ替えは、突発的なトラブル対応とは性質が異なります。予定された作業として、進め方をあらかじめ組み立てられる仕事です。

予定された作業として進められる分、終了する機能の入れ替えは、日程を事前に組み立てやすい仕事でもあります。慌てて対応するより、通知を受けた時点で計画を立てるほうが、進め方に無理が出にくくなります。

新しい機能ばかりではない

市場でよく使われているクラウドであっても、提供されている機能のすべてが新しいものというわけではありません⁴。古い機能も、なお継続して提供されています。

つまり、終了が知らされた機能を入れ替えたとしても、周りには古い作りのまま残る機能が併存します。入れ替えは部分的な作業であり、仕組み全体を一度に新しくする作業ではありません。

終了が知らされて入れ替える対応と、古いまま残る部分。この2つを合わせて理解しておくと、保守案件で発生する作業の幅がつかみやすくなります。

古い機能が残っているかどうかは、仕組み全体を見渡してはじめて分かることもあります。1つの機能だけを見て判断すると、周辺に残る古い作りを見落とすことがあります。

知らされて入れ替える機能と、残り続ける機能を比べます

保守の案件で向き合う機能には、終了が知らされて入れ替える機能と、知らされないまま継続して提供される古い機能の2種類があります。前者は予定を立てて進める作業で、後者はそのまま使い続けるかどうかを見極める作業です。きっかけの出どころも、提供側からの通知か、保守を担う側の気づきかで異なります。次の比較表で、この違いを整理します。

観点	終了が知らされる機能	継続して提供される古い機能
知らされ方	終了時期と代わりの機能が事前に知らされる	特に知らされることはなく提供が続く
対応の性質	入れ替えの予定を立てて進める	そのまま使い続けるか見極める
作業のきっかけ	提供側からの通知	保守を担う側の気づき
仕組み全体への影響	該当機能のみの入れ替え	古い作りが仕組みの中に残り続ける

4. 古い作りが残ったまま続く

そのまま使っても新しくなるとは限らない

提供されているサービスをそのまま使ったとしても、新しい構成になるとは限りません⁵。仕組みを移す作業を終えても、中身が新しくなったとは言い切れないということです。

この点は、保守を担う側にとって重要な前提になります。新しくなったはずの環境の中にも、古い作りがそのまま残っている場面を、見込んでおく必要があるからです。

古い作りが残っているかどうかは、外から見ただけでは分かりにくいものです。保守を担う中で、実際に触れてはじめて見えてくる部分でもあります。

古い作りが残っていることに気づいたら、そのまま流さず、次にどう向き合うかを整理しておくことが、保守を担う側の仕事になります。

半数程度がいまも抱えている

利用する側の企業の半数程度が、いまもレガシーシステム（長く使われてきた古い仕組み）を抱えています⁸。これほど広く残っているという実態は、保守案件の位置づけを考えるうえで見過ごせません。

半数程度という数字は、レガシーシステムを抱えることが特別な状況ではなく、広く見られる状況であることを示しています。保守を担う案件も、この状況の延長線上にあります。

そのまま使っても新しくなるとは限らないこと、そして半数程度がいまも古い仕組みを抱えていること。この2つを重ねて見ると、保守案件が向き合う仕事の実像が見えてきます。

半数程度という広がりを踏まえると、古い仕組みへの対応は一部の案件だけの特殊な仕事ではなく、保守の案件全体に共通して起こり得る仕事だと分かります。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

5. 改善を続ける体制の一部になるか

稼働後も改善が続く前提

本番稼働の後も改善を続けていく前提で、予算と体制と日程を計画する必要があります⁷。稼働開始はゴールではなく、そこから先の計画の起点になります。

改善を続ける体制に加わることは、決まった作業をこなすことよりも、状況に応じて進め方を見直す場面に立ち会うことを意味します。

この体制の一部になれるかどうかは、保守案件を選ぶときに確かめておきたい観点の1つです。改善が前提の案件と、そうでない案件とでは、日々の進め方が変わります。

改善を続ける体制に加わる案件では、稼働開始後の日々の中でも、方針や状況に応じて進め方を調整する場面が繰り返し訪れます。

提案が方針に沿っているかを見る

事業者からの提案が方針に沿ったものかどうかに、留意する必要があります⁶。提案をそのまま受け入れるより、方針との整合を確かめるほうが、進め方の見通しは立ちやすくなります。

方針との整合を確かめる視点を持つことは、改善を続ける体制の中で、保守を担う側に求められる役割の1つです。

方針との整合を確かめる視点を持っていると、事業者からの提案を鵜呑みにせずに済みます。

予算と体制と日程を計画する視点、そして提案の整合を確かめる視点。この2つの視点が、実際の案件のどこに現れるかを次の比較表で整理します。

改善を続ける体制の有無で、案件の進め方はここまで変わります

改善を続ける体制がある案件と、稼働開始をもって関わりが終わる案件とでは、予算の組み方から日程の考え方まで前提が異なります。参画する前にどちらの前提の案件なのかを確かめておくと、稼働開始後に想定していた関わり方と実際の関わり方がずれる事態を避けやすくなります。

観点	改善を続ける体制がある案件	改善を前提にしていない案件
予算の組み方	稼働後の期間も見込んで計画する	稼働開始までの期間で完結させる
体制の続き方	稼働後もメンバーが関わり続ける	稼働開始とともに体制が解かれる
提案への向き合い方	方針との整合を確かめながら進める	提案をそのまま受け入れる
日程の考え方	改善のサイクルを織り込んだ日程	稼働開始が最終地点の日程

6. 古いという認識が薄い現場

「ない」と答える割合が最も高い

レガシーシステムはないと答えた割合は、日本が最も高くなっています¹⁰。他の国と比べて、古い仕組みを抱えているという認識そのものが薄いことがうかがえます。

一方で、利用する側の企業の半数程度が、いまもレガシーシステムを抱えています⁸。認識と実態のあいだに、開きがあることになります。

この開きは、保守を担う側にとって見過ごせない意味を持ちます。現場が古いと感じていない仕組みの中に、実際には古い作りが残っている場面に出会うことになるからです。

「ない」と答える割合が高いという結果は、実際に古い仕組みが少ないことを示すとは限りません。認識の違いが数字に表れている可能性も考えられます。

抱えている実態との開き

認識が薄いまま保守が続くと、古い作りへの対応が後回しになりやすくなります。改めて手を付けるタイミングが、なかなか訪れないという状況です。

現場の認識より先に、保守を担う側が古さに気づく場面もあります。気づいたことをそのまま流すより、方針との整合とあわせて共有するほうが、次の判断につながります。

認識と実態の開きを踏まえておくと、保守案件で自分が果たす役割を、より具体的にイメージできます。次の章では、この開きを踏まえたうえで、案件を受ける前に確かめておきたい順番を見ていきます。

7. 受ける前に確かめる順番

契約の形を確かめる

システム開発の契約では、取引ごとに手間や工数がかかる点を課題として挙げる企業が多くなっています⁹。保守案件を受ける前には、この点がどう扱われているかを確かめておくと、参画後の負担を見込みやすくなります。

取引のたびに個別のやり取りが発生する形なのか、まとまった単位で進める形なのか。この違いは、日々の進め方に直結します。参画してから慌てて確かめるより、最初に確かめておくほうが、落ち着いて仕事を始められます。

契約の形を確かめる際には、取引の単位だけでなく、更新や機能の入れ替えといった日常的な対応が、その単位の中にどう含まれているかも合わせて見ておくと安心です。

改善の前提を確かめる

契約の形を確かめたら、次に見ておきたいのが改善の前提です。本番稼働の後も改善を続ける前提で、予算と体制と日程が計画されているかどうかを確認します⁷。

改善の前提が計画に含まれている案件では、稼働開始後も体制が続きます。含まれていない案件では、稼働開始とともに関わりが終わる可能性があります。この違いを、参画前に確かめておく意味は大きいです。

改善の前提が計画に含まれているかどうかは、案件の説明を読むだけでは分かりにくいこともあります。分からない点は、参画前の打ち合わせで確かめておくと、後になって認識のずれに気づく事態を避けられます。

保守案件は、期間が長いこと自体が条件になる仕事です。契約の形と改善の前提、この2つを確かめる順番を押さえておくと、参画した後に想定外の負担に驚くことを防げます。

保守案件は、開発の案件とどう違いますか

開発の案件は稼働開始という区切りに向かって進みますが、保守の案件は稼働開始からの期間そのものが仕事の中身になります。更新への対応は、日常の中で対応していく仕事として位置づけられています³。

古い仕組みが残っているかどうかは、参画する前に分かりますか

提供されているサービスをそのまま使ったとしても、新しい構成になるとは限りません⁵。外から見ただけでは分かりにくく、保守を担う中で見えてくる部分もあります。

契約の形は、どんな点を確かめればよいですか

取引ごとに手間や工数がかかる点を課題として挙げる企業が多くなっています⁹。取引のたびに個別のやり取りが発生する形なのか、まとまった単位で進める形なのかを、参画する前に確かめておくと安心です。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）、デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わりの知らせ（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わらない作業（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」古い機能も残る（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」使えば新しくはならない（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」提案を読む（2026年・2026年8月確認）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年8月確認）
＊10 IPA「DX動向2025」古い仕組みの見え方（2025年6月・2026年8月確認）