保守の案件に参画するとき、契約書を確認しても「どこまで対応するのか」がはっきり書かれていないと感じる場面があります。検査を完了する期日や報酬の支払期日は明示される項目に含まれていても、保守の範囲そのものは項目として挙がっていません¹。範囲は契約書の文面だけでなく、現行システムの作りと、文書がどれだけ残っているかによって決まります。この記事では、範囲が決まる仕組みと、参画前に確かめる順番を整理します。

1. 明示される項目に保守の範囲は入っていない

検査を完了する期日と報酬の支払期日は明示の対象

業務委託の契約であらかじめ明示しておく項目には、成果物を検査する場合の検査を完了する期日と、報酬の額および支払期日が含まれています¹。発注する側と受ける側の双方が、いつまでに何を確認し、いつ支払いが行われるのかを、契約の入り口の段階で共有しておく仕組みです。

この3つの項目は、業務委託契約の中でも特に金銭と検収に関わる部分です。案件が始まる前に確認しておけば、成果物を受け渡した後の行き違いを避けやすくなります。契約書や発注書に、期日と金額がそれぞれ具体的な数字で書かれているかを見る習慣が役立ちます。

この3項目が契約書に見当たらない場合は、保守の範囲を確認する以前に、契約そのものの土台が整っていない可能性があります。まずは検査の期日と支払いの条件を明文化してもらうよう依頼し、そのうえで範囲の話に進むと、確認の順序が整理しやすくなります。

ただし、この一覧の中に「保守として対応する範囲」という項目は出てきません。検査の期日や支払いの条件は明確でも、日々の保守でどこまでの作業を引き受けるのかは、別の場所で確認する必要があります。

明示される項目を一覧で確認する

検査を完了する期日、報酬の額、支払期日は、いずれも案件が始まる前に確認できる項目です。金額や日付という具体的な数字で示されるため、後から行き違いが起きにくいという特徴があります¹。一方で、保守として何を対応するかという範囲については、この一覧のどこにも項目として立てられていません。契約書や発注書を読むときは、この3つがどう書かれているかとあわせて、範囲についての記載があるかどうかも確認すると、抜け落ちに気づきやすくなります。次の表に、明示される項目と保守の範囲との関係を整理しました。

明示される項目	内容	保守の範囲についての記載
検査を完了する期日	引き渡された成果物を確認し終える期限	含まれていない
報酬の額	支払われる金額	含まれていない
支払期日	報酬が支払われる期日	含まれていない

保守の範囲は契約書の外側で決まる

保守の範囲が契約書の明示事項に含まれていないからといって、何を確認しても分からないわけではありません。範囲は、いま動いているシステムがどのような作りになっているか、そして要件や設計がどれだけ文書として残っているかによって、実質的に決まっていきます。

古い作りのシステムほど、担当する範囲は現場の判断に委ねられやすくなります。設計の意図や変更の履歴が文書として残っていれば、どこまでが保守の対象かを言葉で確認しやすくなります。契約書の条文よりも、現場の実態を見る作業のほうが、範囲を把握する近道になることがあります。

もう一つ、契約書の外側にありながら保守の範囲に関わってくるものがあります。発注する側に定められている禁止行為です。次の章で、この規定が保守の局面にどう関わるのかを見ていきます。

図の作成：Remogu編集部。契約書に明示される項目と、保守の範囲が実質的に決まる要素を整理したもので、統計データではありません

2. 禁止行為は保守の局面でも効いている

発注する側に定められている禁止行為

業務委託の取引では、発注する側に対して禁止行為が定められています²。受ける側が一方的に不利な扱いを受けないよう、発注する側の行動に枠を設ける仕組みです。

この規定があることを知っておくだけでも、条件について声を上げやすくなります。保守の期間中に、当初の合意にない作業を求められた場合は、規定の存在を踏まえて、まず内容を確認する姿勢が取りやすくなります。

この規定は、契約を結ぶ場面だけで働くものではありません。保守のように、契約が結ばれた後も長く続くやり取りの中でも、同じ枠が働き続けます。日々の連絡や条件のすり合わせも、この枠の中で行われることになります。

保守が続く間も同じ規定が働く

新しく案件が始まるときは、条件を確認する機会が自然に生まれます。一方、保守のように長く続く関係では、当初の条件がそのまま流れてしまい、途中で変わった点を確認しないまま進んでしまうことがあります。

禁止行為の規定は、こうした関係の途中でも同じように働きます²。範囲が曖昧なまま作業が増えていくと感じたときは、契約の入り口だけでなく、いま進んでいる保守の内容そのものを、あらためて確認する材料になります。

やり取りの中で条件が一方的に変わったと感じたときは、その場で流さず、メールやチャットなど文字に残る形で確認を取っておくと、後から状況を振り返る材料になります。口頭だけのやり取りは、時間が経つほど双方の記憶が食い違いやすくなります。

もっとも、範囲を確認する材料は規定だけではありません。実際に向き合うことになるシステムが、どのような作りをしているかも、範囲の広さを左右します。次の章では、現場の実態を数字で見ていきます。

3. レガシーを抱える企業は半数程度

半数程度がレガシーシステムを抱えている

システムを利用する側の企業のうち、半数程度が、いまもレガシーシステムを抱えています³。長く使われてきた仕組みほど、当初の設計や変更の経緯が担当者の記憶に依存しやすくなります。

レガシーシステムという言葉には、単に古いという以上の意味があります。改修を重ねるうちに、最初の設計から離れた作りになっている場合や、一部だけが新しい技術に置き換わっている場合も含まれます。保守を引き受ける側からすると、外から見える範囲と、実際に手を動かす範囲が一致しない場面が生まれやすくなります。

半数程度という割合は、保守の案件に参画すると、レガシーシステムに当たる可能性が決して低くないことを意味します。事前にレガシーかどうかを気にしすぎるより、レガシーであることを前提に、確認の仕方を準備しておくほうが実用的です。

古い作りは保守の範囲を曖昧にする

新しく作られたシステムであれば、構成や依存関係が整理されていることが多く、保守の対象を区切りやすくなります。これに対して、長く使われてきたシステムは、機能ごとの境目がはっきりしないまま積み重なっていることがあります。

境目がはっきりしないシステムほど、保守の範囲は言葉ではなく、実際の作りを見て確かめる必要があります。参画する前に、対象のシステムがどの程度の年数使われているか、改修がどのくらいの頻度で入っているかを尋ねておくと、範囲のイメージを持ちやすくなります。

文書が十分に残っていない場合でも、変更履歴やバージョン管理の記録が残っていれば、それが範囲を推測する手がかりになります。いつ、どの部分に手が入ったかを追うことで、担当者への質問も具体的になります。

作りの古さよりも、確認のしやすさを直接左右するのは、要件や設計が文書としてどれだけ残っているかです。次の章で見ていきます。

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

4. 要件と設計は文書中心で進んでいる

要件定義と設計はいまも文書が中心

要件定義や設計は、いまもドキュメントを中心に進められています⁴。仕様書や設計書という形で、何を作るか、どのように作るかが言葉として残される進め方です。

文書が中心の進め方には、良い面と難しい面の両方があります。良い面は、後から参加する人でも、文書を読めば経緯を追えることです。難しい面は、文書の更新が追いつかず、実際の作りと文書の内容がずれてしまう場合があることです。

文書の残り方を見れば、範囲が読める

保守の範囲を確かめるとき、文書の有無は具体的な手がかりになります。仕様書や設計書が残っていれば、対象の機能や仕組みを言葉で確認しながら話を進められます。逆に文書があまり残っていない場合は、実際の画面や処理を動かしながら、範囲をひとつずつ確かめていく進め方になりやすくなります。次の表に、文書の残り方ごとの違いを整理しました。

文書の残り方	範囲の確認のしやすさ	確認の進め方
仕様書・設計書が残っている	文書を読みながら確認できる	文書の記載と実際の動きを突き合わせる
一部だけ残っている	残っている範囲は確認できる	抜けている部分を担当者に確認する
ほとんど残っていない	言葉だけでの確認が難しい	画面や処理を動かしながら確認する

実際には、この3つの状態がきれいに分かれているとは限りません。仕様書はあっても更新が止まっている、設計書の一部だけが最新版になっている、といった中間的な状態もよくあります。表はあくまで目安とし、実物を見ながら判断することが欠かせません。

内側の作りも範囲の見えやすさを左右する

文書があるかどうかと同じくらい、システムの内側の作りも範囲の見えやすさに関わります。次の章では、モジュール性という観点から見ていきます。

図の作成：Remogu編集部。文書の残り方によって確認の進め方がどう変わるかを整理したもので、統計データではありません

5. モジュール性を意識した設計は依然として少ない

モジュール性を意識した設計は少数派

モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側の企業を中心に、依然として少ない状況です⁵。機能ごとに独立して手を入れられるような作りが、まだ広くは行き渡っていないことになります。

モジュール性を意識した設計とは、機能同士のつながりをできるだけ整理し、ある部分を直しても、ほかの部分に影響が及びにくいようにしておく考え方です。これが少ないということは、一つの修正が思わぬところに波及する可能性が、相対的に高いシステムが多いことを意味します。

日々の作業に置き換えると、ある画面の修正を頼まれたつもりが、裏側で共有されている処理まで確認する必要が出てくる、という形で表れます。着手前に思っていた作業量と、実際にかかる時間にずれが生じやすい原因の一つです。

境目が薄いシステムほど、確認の手間が増える

モジュールの境目がはっきりしないシステムでは、ある機能の保守を引き受けたつもりでも、実際に手を動かすと隣接する部分まで確認が必要になることがあります。範囲を言葉で区切りにくいという点は、前の章で見た文書の残り方とも重なります。

境目を事前に完全に把握することよりも、着手した後に確認が必要な範囲が広がる可能性をあらかじめ共有しておくことのほうが、現実的な備えになります。参画前の打ち合わせで、この点を尋ねておくと、後の行き違いを減らせます。

システムの内側の作りに加えて、外部のサービスとの関わり方も、保守の範囲を考えるうえで欠かせない要素です。次の章で見ていきます。

6. 外部のサービスの維持や運用に不安がある

外部サービスの維持・運用に不安を抱える企業は多い

外部のサービスについても、維持や運用に対して不安を抱える企業は多い状況です⁶。自社の中だけで完結しない仕組みが増えるほど、変更やトラブルが起きたときに、どこまでを自分たちで見て、どこからを外部に委ねているのかが分かりにくくなります。

外部のサービスは、契約書の中で名前が挙がっていないことも珍しくありません。保守の対象がどこまでかを確認するときは、システムの内部だけでなく、外部と連携している部分の一覧も、あわせて尋ねておく価値があります。

この不安は、システムそのものの保守とは別の種類の確認事項です。外部のサービスに接続している部分があるかどうか、接続している場合はその更新にどう対応しているかは、保守の範囲を考えるときに見落とされやすい観点になります。

外部との接続部分も、確認する範囲に含める

保守を引き受ける前に、対象のシステムが外部のサービスとどのようにつながっているかを尋ねておくと、あとから範囲が広がったと感じる場面を減らせます。接続の数が多いシステムほど、確認しておきたい項目も増えます。

外部のサービスとの関わり方を含めて範囲を確認しておくことは、契約書に書かれている項目だけを見るよりも、実務に近い形で保守の全体像をつかむことにつながります。次の章では、契約の場面でよく挙がる課題と、参画前に確かめる順番を整理します。

7. 契約の手間と、確かめる順番

取引ごとの手間と、モデル契約の認知

システム開発の契約では、取引ごとに手間や工数がかかる点を課題として挙げる企業が多い状況です⁷。契約条件を毎回確認し直す作業そのものが、双方にとって負担になっている実態がうかがえます。

あわせて、モデル契約そのものを知らないとする企業も多いという状況があります⁸。参考にできるひな形があることを知らないまま、その都度契約の内容を一から詰めている場面があることになります。

手間がかかることと、ひな形が知られていないことは、別々の課題のようでいて、つながっています。参考にする形が定まっていなければ、確認する項目を毎回洗い出す必要があり、それが手間の大きさにも表れます。

更新への対応は、日常の中に組み込む

サービスの更新への対応は、特別なイベントとしてではなく、日常的に対応していく必要があるという考え方が示されています⁹。保守を、決まった周期でまとめて行う作業としてだけでなく、普段の運用の一部として捉える見方です。

この考え方を踏まえると、保守の範囲を確認するときも、一度きりの確認で終わらせず、更新が発生するたびに範囲を確かめ直す前提を持っておくと、実際の進め方に近づきます。参画した後も、範囲についてのすり合わせを続けることになります。

日常的に対応するという前提に立つと、保守を決まった作業をこなす仕事としてだけでなく、変化に合わせて調整し続ける仕事として捉え直すことになります。この見方の違いは、参画した後に感じる負担の大きさにも影響します。

確かめる順番を一覧で整理する

ここまで見てきた内容を踏まえると、参画前に確かめておきたい項目には、順番があります。まず契約書に明示されている項目を確認し、次にシステムの作りと文書の残り方を尋ね、最後に外部サービスとの関わりと更新への対応を確認するという流れです。取引条件の明示義務違反は1,126件（41.3％）にのぼるという状況もあり¹⁰、口頭のやり取りだけに頼らず、確認した内容を言葉で残しておくことが、双方にとっての備えになります。次の表に、確かめる順番を整理しました。

順番	確認する内容	確認の相手・方法
1	検査完了期日・報酬額・支払期日	契約書・発注書の記載を確認する
2	現行システムの作りと文書の残り方	担当者に尋ね、実際の画面や文書を見せてもらう
3	外部サービスとの接続と更新への対応	接続の有無と更新の頻度を尋ねる

確認する相手も、順番によって変わります。最初の2つは契約や仕様に詳しい担当者、3つ目は運用や情報システムを担当する部署が窓口になることが多く、一人にまとめて聞こうとすると情報が抜け落ちやすくなります。

図の作成：Remogu編集部。ここまでの内容をもとに、確認する順番を整理したもので、統計データではありません

初めて保守の案件に参画するとき、最初に何を確認すればよいですか

まず契約書や発注書を確認し、検査を完了する期日と、報酬の額および支払期日が具体的に書かれているかを見ます¹。そのうえで、保守として対応する範囲そのものについては、担当者に尋ねる形で確認します。契約書の項目だけでは、範囲までは分からないことが多いためです。

要件が曖昧なまま保守が始まってしまったら、どう対処すればよいですか

要件がはっきりしないまま進んでいると感じたら、現行システムの作りと、要件や設計がどれだけ文書に残っているかを、あらためて確認する機会を持つとよいです。仕様書や設計書が一部でも残っていれば、それを手がかりに、対応する範囲を言葉にしていく作業ができます⁴。文書がほとんど残っていない場合は、画面や処理を実際に動かしながら、範囲を一つずつ確認していく進め方になります。

週3日など稼働の少ない条件でも、保守の案件は引き受けられますか

稼働の日数そのものよりも、対応する範囲がどこまでかを先に言葉にしておくことが大切です。範囲が明確になっていれば、稼働の少ない条件でも、どこまでを担当するかの認識をそろえやすくなります。条件は案件によって異なるため、気になる案件があれば、条件を確認しながら参画を検討する進め方が現実的です。

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

出典・参考情報

＊1 公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット（2026年7月・2026年9月確認）
＊2 公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット（2026年7月・2026年9月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年9月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年9月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年9月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在（2025年4月・2026年9月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年9月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」相手の前提（2025年4月・2026年9月確認）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年・2026年9月確認）
＊10 公正取引委員会「令和7年度におけるフリーランス・事業者間取引適正化等法第2章の運用状況」2番目に多い違反（2026年6月・2026年9月確認）