「保守に含むか」の前に、何が違ったかをそろえる
月末の請求を出そうとしたら、集計額が現場の台帳と合わない。担当者は「不具合を直してほしい」と伝えますが、開発会社は「仕様の確認が必要」と返します。原因、調査の範囲、業務を止めずに進める方法が未定のままでは、対応を依頼する判断が止まります。
保守に含むかは、依頼の呼び名だけでは決まりません。合意した仕様・対象環境・契約の範囲に照らし、まず調査で何を確かめるか、その後どの作業を行うかを分けて合意します。以下の業務例と進め方は説明用の提案で、特定企業の実績や一律の契約条件ではありません。
判断材料が足りない
確認と合意をそろえる
同じ請求画面でも、依頼の種類と確認先は変わる
説明用に、請求システムへ来た3つの依頼を比べます。最初の分類は仮置きです。入力漏れや運用の変更、外部連携の遅れなどが分かれば、原因と分類を見直します。
「納品時の仕様との不一致」と「稼働後の要望」は確認する資料が異なります。開発時の不具合対応の条件と、継続保守の条件を両方確認し、名称だけで無償・有償を決めないようにします。
不具合の疑い：合計が違う
合意した計算条件・入力履歴・正しい結果を照合する。未入力を0としていないかも確かめる。
新しい要望：部門別の項目を追加
元の仕様にあるか、新しい集計ルールか。画面・帳票・CSV・権限へ影響する範囲を確認する。
環境変更：外部サービスから取り込めない
提供元の通知、設定、連携処理、対象バージョンを確認する。相手側の変更と自社側の対応を分ける。
分類だけで保守内・有償・責任を決めない
受付から完了まで、依頼ごとに判断を残す
受付の時点では、発生日時、対象業務、操作、期待した結果と実際の結果、業務への影響をそろえます。個人情報を含む本番データやパスワードは、最初の問い合わせに添付せず、担当者と共有方法を決めてから必要な範囲を扱います。
調査しても再現しない場合は「問題なし」で閉じず、確認できた条件と未確認の条件を残します。追加調査が必要なら、対象を広げる前に判断へ戻ります。外部サービスの障害中など、受託側だけで完了を決められない場合も同様です。
- 01
業務への影響を確認
請求を止める範囲、確認中の表示、代替手順を業務責任者と決める。
- 02
最初の調査を合意
計算・入力・取り込みのどこを調べるか。費用、報告内容、判断に戻る時点を決める。
- 03
対応する範囲を決める
分かった原因と契約を照合し、修正・設定・運用変更の対象、費用と時期を合意する。
- 04
業務で確かめて完了
正しい集計、帳票、取り込み、再実行時の重複を確認し、残る課題を記録する。
運用・設定・連携・開発を比べて、直す場所を絞る
プログラムを直す前に、入力方法や設定を整えれば解消するかを確認します。一方、入力の注意だけでは繰り返す不一致や、外部連携の仕様変更が原因なら、仕組みの変更が必要になる場合があります。
運用を整える
締めの手順・入力担当・訂正の承認をそろえる。担当者が替わっても同じ結果になるか確認。
既存設定を変える
利用可能な集計・マスタ・権限設定を確認。設定でできないことや他業務への影響を残す。
既存ソフトを残して連携を直す
取り込み条件・エラー記録・再実行を確認。連携先の利用条件、重複と漏れを照合。
プログラムを改修する
変更する仕様と影響先を絞る。検証環境、切替、元へ戻す手順と受入確認を合意。
保守契約では、調査と対応と確認の分担を決める
契約書だけでなく、対象システムや作業範囲を記した仕様書・条件の一覧も合わせて確認します。IPAのモデル契約は、仕様・管理・検収の共通理解に向けた双方の対話を重視しています。下の確認項目は、その考え方を日々の依頼へ落とした本記事の提案です。
社内の業務担当は「何が正しい請求か」と訂正対象を判断し、管理・契約担当は優先度と承認をまとめます。受託側は調査結果、選択肢、影響と確認方法を説明します。どちらかが全部を引き受ける前提にせず、受入確認の日程も含めてそろえます。
- 対象：システム・環境・バージョン・既存連携のどこまでを扱うか
- 調査：初期調査に含む作業、費用、資料、結果の報告と追加調査の判断
- 対応：不具合、設定変更、機能追加、外部サービス変更の例ごとの扱い
- 役割：現場の正しい業務結果、技術的な調査、費用承認を誰が担当するか
- 完了：正常な操作だけでなく、訂正・再実行・帳票・他業務の確認を誰が行うか
- 継続：受付時間、変更履歴、更新・終了の条件、未使用枠や超過の扱い
他社から引き継ぐときは、調査と継続保守を一度に決めない
保守会社の交代では、ソースコードがあるだけで引き継げるとは限りません。利用・改変の権限、動かす環境、構築手順、外部サービスの契約主体、既存の不具合と変更履歴を確認します。資料が足りない箇所は不足として残し、対応できる範囲を調査します。
切替中は、現在の窓口と新しい窓口が担当する期間、同時に変更しない対象、未対応の依頼の渡し方を決めます。動作や請求結果の確認が済むまで旧環境をどう保持するか、戻す判断を誰がするかも合意します。現在の契約や提供元の条件を越えて、資料やアカウントを移せると約束しないことが大切です。
SHINJIDAIには、最初に任せたい範囲から相談する
SHINJIDAIは、課題の相談・解決策の提案から設計・開発・導入まで伴走しています。保守の相談では、困っている業務、現行システム、契約・資料の有無を確認し、調査から始めるか、既存設定や連携の見直しで進めるか、改修が必要かを整理します。
対応可能な範囲を確認したうえで、調査・改修・保守それぞれの内容、費用、双方の役割と確認方法を合意します。実装する場合は、例えば請求の集計と帳票・取り込みを業務担当と照合し、残る未確認事項を整理します。対応可否や調査の費用は個別に確認するため、他社システムを無条件に引き継ぐ約束ではありません。
最初の相談では「どの業務が、いつから、どう困っているか」「何を残したいか」「現在の依頼先や資料の状況」の概要があれば出発点になります。機密データを先に提出する必要はありません。次に決めたいのは、最初の調査対象、対応可否を判断する材料、業務を続けながら確認する方法です。
業務の課題整理から、設計・開発・導入まで
保守の調査・修正・引き継ぎの範囲から、
SHINJIDAIにご相談ください。
- 修正依頼の調査と対応の費用が分からない
- 今のシステムを残して保守を引き継ぎたい
- 何を任せ、何を社内で確認するか決めたい
課題の整理から伴走困っている業務、現行システム、契約・資料の状況を確認します。対応可否を確かめる最初の調査と、設定・連携・改修の選択肢を整理。範囲・費用・双方の役割を合意し、実装と業務での確認まで伴走します。
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
ID・パスワードや顧客データは、フォームに記載しないでください。
開発・保守の進め方を見る出典
2026年10月8日確認。IPAの資料はモデル契約の位置づけと対話の考え方を参照しています。本文の業務例・確認項目・図はSHINJIDAIの提案であり、モデル契約の条文や個別契約の解釈をそのまま示すものではありません。支援範囲は当社の公開方針と照合しています。
よくある質問
不具合なら、必ず保守料の範囲で直してもらえますか？
症状だけでは判断できません。合意した仕様との違い、発生した時期、変更履歴を確認し、開発契約の不具合対応と保守契約の対象を照合します。原因を調べる作業と、修正する作業の範囲・費用も分けて確認してください。
原因が分からないまま相談してもよいですか？
相談できます。いつ、どの業務で、期待した結果と何が違ったかを概要で伝えてください。調査できる資料・環境、最初に調べる範囲、費用と報告の条件を合意して進めます。原因の特定や修正が必ずできるという約束ではありません。
帳票の項目を1つ増やすだけなら、軽微な修正ですか？
画面だけでなく、入力、計算、CSV、連携先、閲覧権限に影響することがあります。見た目の小ささで決めず、変更する場所と確認する業務をそろえ、契約の対象・上限・超過時の扱いを確認します。
他社が作ったシステムの保守を引き継げますか？
SHINJIDAIでは、ソースコード、利用権限、環境、資料の状態を調査したうえで対応可否と方針をご案内します。調査・既存不具合の改修・継続保守を分けて範囲と費用を合意します。現在の契約や利用許諾で引き渡せる資料も確認が必要です。
停止時の連絡や復旧の時間も、この記事だけで決められますか？
この記事は日々の依頼の範囲と進め方を扱います。受付時間、緊急時の連絡、初動と復旧の目標は別に決め、障害時SLAの記事と合わせて確認してください。問い合わせの受付と、復旧完了の約束は区別します。