システム開発の保守費見積：変更頻度と依存関係で外注・内製判断

この記事の要点

保守費の見積で見るべきは変更頻度と依存関係です。月額が安く見えても、変更のたびに影響調査・テストが膨らむ構造だと年間総額は跳ね上がります。情シス不在でも見積の妥当性を判断できる見方と、外注・内製・SaaSの選び方を整理します。

導入：保守が高いのは「変更頻度」と「依存関係」のせいかもしれない

システム開発の保守費が高いと、ちょっとした改善でも都度見積が膨らみ、結果的に改善が止まります。情シス不在の組織ほど「何にお金を払っているのか」が見えづらく、外注先の言い値になりがちです。保守費の見積で見るべきは変更頻度と依存関係——この2点を押さえるだけで、保守費の妥当性を判断しやすくなり、外注・内製どちらを選ぶにしても失敗確率を下げられます。

ここでいう「保守が高い」は、月額が高いだけではありません。月額は低いのに、変更のたびに“影響調査＋テスト＋リリース調整”が乗って、年間総額が高くなるケースが非常に多いです。見積書の金額だけを見て判断すると「保守を減らしたのに、改修費が増えて結局高い」という状態に陥ります。

この記事では、保守費が高騰する典型パターンを分解し、見積書のどこを見ればよいか、要件定義や業務フロー判断をどう使えばよいか、そしてSaaSという選択肢も含めた「次の一手」を整理します。情シスがいなくても、社内で意思決定しやすい形に落とし込みます。

結論：保守費は「月額」ではなく“変更のたびの総額”で判断する

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る

保守費の見積で見るべきは変更頻度と依存関係です。月額が安く見えても、変更のたびに追加費用が発生する設計・契約だと、年間の総額（TCO）は簡単に跳ね上がります。逆に、月額が一定でも「軽微改修の枠」「定例の改善枠」「影響調査の標準化」が含まれていれば、改善が止まりにくくなります。

判断をラクにするために、まずは年間を“イベント”として捉えます。月に何回変更が起きるか、四半期でどんな改修が入るか、年1回の法改正や繁忙期対応があるか。変更が多い前提なら、見積は月額よりも「変更1回あたりの総額」「変更を減らす設計投資」の比較で決めるべきです。

具体的には、変更が多い領域ほど見積の前提（工数単価・対応範囲・SLA）を細かく確認し、依存関係が多いほど「影響調査」「テスト」「リリース調整」が積み上がることを前提に、構造を変える判断（分離、置き換え、SaaS化）を検討します。ここを押さえると「高い・安い」の議論が、数字と根拠で進みます。

よくある失敗：変更のたびに高額で改善停止になる構造

失敗1：保守＝待機費、変更＝別見積が常態化している

「保守契約に入っているのに、修正は毎回別見積」という状態は珍しくありません。ここで重要なのは、保守費に含まれる作業範囲（監視・障害対応・軽微改修・運用代行）が明文化されているかです。含まれていないなら、月額が安いのではなく、請求が分割されているだけの可能性があります。

特に“軽微修正”の定義が曖昧だと、判断が毎回揉めます。例えば「テキスト修正はOK、入力項目追加はNG」「CSS調整はOK、表示条件追加はNG」など、線引きが事前にないと、運用は止まります。情シス不在の組織ほど、線引きを文章で残すことが重要です。

失敗2：改修の影響範囲が読めず、影響調査が毎回フルコースになる

依存関係が絡み合った状態（機能が密結合、DBが肥大化、画面とロジックが一体化）では、修正箇所が小さくても「どこが壊れるか分からない」ため、影響調査とテストが大きくなります。これは外注先の能力というより、システムの構造問題です。

また、ドキュメントが不足していると、影響調査は“コードを読む”しかなくなります。結果として、調査→仮説→検証→やり直しが増え、費用も納期も膨らみます。見積で「調査工数」が大きい場合は、仕様の不確実性と依存関係の多さが疑われます。

失敗3：担当者がいないため、優先順位と受入基準が決められない

情シス不在だと、依頼の窓口・仕様の決裁・受入テストが曖昧になり、結果として外注側はリスクを見積に乗せます。仕様が揺れるほど、変更頻度が上がり、保守費も上がります。

さらに、受入基準がないと「直したはずなのに、現場で困る」が起きます。これが続くと、外注側は“追加対応の保険”として調査やテストを厚く見積もるようになります。小さな改善を回すなら、最低限の受入基準（OK/NG判定）が必須です。

失敗4：依存関係の“増殖”に気づかず、後から雪だるま式に高くなる

最初は単純な機能でも、運用が回り始めると「この画面にも同じ項目を」「このデータもCSVで」「この通知も追加」と追加が積み重なります。追加そのものは正しい改善でも、依存関係を増やす追加を繰り返すと、変更1回あたりのコストが上がります。

改善が止まるタイミングは、たいてい“依存関係が限界を超えた時”です。だからこそ、見積段階で「依存を増やさない設計ルール」や「影響が広がるときの方針（分離、置き換え）」を持っておく必要があります。

要件定義：保守費の見積で見るべきは変更頻度と依存関係を“仕様”に落とす

変更頻度を「画面・データ・ルール」で棚卸しする

まず「どこがよく変わるか」を、感覚ではなく棚卸しします。例えば、キャンペーン文言は頻繁に変わるが、決済ロジックは滅多に変わらない、といった差があるはずです。変更が多い部分は、ノーコード/設定化/管理画面化などで“開発なしで変えられる”設計に寄せると、保守費の爆発を防げます。

棚卸しのコツは「変更の種類」を分けることです。文言や画像の変更、入力項目の追加、計算ロジックの変更、権限の変更など、種類が違うと必要なテストも違います。種類ごとに“標準の対応手順”を作ると、見積が安定します。

• 画面：文言・バナー・入力項目・表示条件
• データ：マスタ項目・CSV取り込み/出力・権限
• ルール：計算式・承認フロー・通知条件

依存関係は「つながりの数」で増える。分離の方針を決める

依存関係は“つながっている箇所の数”が増えるほど、改修時の影響範囲が広がります。見積を見るときは、改修費そのものだけでなく、影響調査・テスト・リリース調整が毎回どの程度必要かを確認しましょう。

例えば、同じデータを複数機能が参照・更新している場合、1機能の変更でも他機能が壊れる可能性があります。外部連携が多い場合も同様で、API仕様変更や認証方式の変更が入ると、想定外の工数が発生します。依存関係を可視化し、優先順位をつけて減らしていくのが王道です。

• 外部連携：会計、在庫、MA、決済、API
• データ共有：同じDBを複数機能が参照/更新
• 運用依存：人の手順がシステム前提になっている

外注・内製の意思決定では、「よく変わる領域」「依存が少ない領域」から切り出して内製化（または別ベンダーへ移管）するのが現実的です。逆に、依存が強い中核は、分離計画がない限り内製化しても苦しくなります。

見積に効く“仕様の粒度”は「受入条件」と「例外」

要件定義が粗いと、外注側は不確実性を上乗せします。ここで押さえるべきは、画面一覧のような量よりも「受入条件」と「例外パターン」です。受入条件が決まっていればテストの範囲が決まり、例外が整理されていれば追加実装が減ります。

情シス不在の組織では、全部を完璧に書く必要はありません。最低限「この状態になったらOK」「ここまでやれば完了」「例外はこの3つまで」など、意思決定の軸になる記述があるだけで、見積のブレが減ります。

業務フロー判断：変更頻度の高い業務を先に直すか、構造を先に直すか

業務フローを描くと、保守費の“本当の原因”が見える

保守費が高い原因が「システム」ではなく「業務の揺れ」にあるケースもあります。例：現場ごとに例外処理が多く、毎月ルールが変わる。こうした場合は、先に業務フローを整理し、例外を減らすだけで変更頻度が下がります。

業務フローの整理は、開発のためというより“保守費のコントロール”のために行います。誰が、いつ、何を入力し、どこで承認し、どのタイミングで通知するか。これが整理されると、仕様が揺れにくくなり、見積もりも安定します。

判断の軸は3つ：頻度・影響・代替

情シス不在の現場でも使える判断軸はシンプルです。

1. 頻度：月に何回変わるか（0/1/複数）
2. 影響：変わると誰が困るか（現場だけ/全社/顧客）
3. 代替：SaaSや運用変更で回避できるか

頻度が高く影響も大きいなら、設計で吸収（設定化・分離）する価値があります。頻度が低いなら、スポット見積でも問題ありません。頻度が高いが影響が小さいなら、運用で吸収（テンプレ化、運用ルール化）して開発依存を減らします。

情シス不在でも回る体制づくり：決める人・頼む人・確認する人

業務フロー判断ができても、意思決定の体制がないと改善は止まります。最低限、次の3役割だけは固定します。1人が兼務しても構いませんが、“誰がやるか”を決めるだけで、外注側の不確実性が下がります。

• 決める人：仕様の最終決裁（優先順位も含む）
• 頼む人：依頼の窓口（要望の取りまとめ）
• 確認する人：受入確認（現場視点のOK/NG）

この3役割が決まると、外注先とのコミュニケーションが安定し、変更頻度が高い状況でも「小さく早く回す」運用ができるようになります。

SaaS比較チェック：依存関係を減らして保守費を“固定化”する選択肢

SaaSが向くのは「標準業務」と「連携が少ない周辺」

SaaSは、機能追加や法改正対応がサービス側で進むため、自社での変更作業が減りやすいのが利点です。一方で、独自業務が多い、外部連携が多い場合は、結局カスタム開発が残り、保守費は下がりません。SaaS比較チェックでは、依存関係を減らせるかを最優先で確認します。

よくある落とし穴は「SaaSを入れたのに、周辺の連携開発が増えて高くなった」です。導入の目的を“機能追加”ではなく“依存関係を減らす”に置くと、選定がブレません。

• 要件の8割が標準機能で満たせるか
• データ連携は最小限か（CSVで足りるか、APIが必要か）
• 権限・監査・ログ要件は満たせるか
• 運用者が不在でも回るUI/サポートか

見積で見るべき項目：初期費用より「出口」と「連携コスト」

SaaSの見積は初期費用より、月額・従量課金・連携開発・データ移行・解約時のデータ取り出し（出口）で差が出ます。外注・内製の選択肢にSaaSを入れるなら、比較表を作る前に「出口」と「連携」を確認すると、後戻りが減ります。

出口の確認とは、「データをどんな形式で取り出せるか」「解約後に閲覧できる期間があるか」「添付ファイルやログは出せるか」などです。連携コストの確認とは、「API制限」「追加料金」「認証方式」「障害時の切り分け」を含みます。ここを曖昧にすると、運用段階で保守費が膨らみます。

SaaSとスクラッチの“混在”を前提に、境界を決める

現実には、全てをSaaSに寄せられないことも多いです。その場合は「SaaSでやること」と「スクラッチで残すこと」の境界を決め、境界をまたぐデータの流れを最小化します。境界が曖昧だと、依存関係が増え、変更のたびに調整が必要になります。

境界を決めるコツは、データの責任範囲（どちらが正か）を決めることです。例えば顧客マスタはSaaSが正、受注データはスクラッチが正、など。責任範囲が決まると、同期や修正のルールが作れます。

チェックリスト：保守費の見積で見るべきは変更頻度と依存関係（確認10項目）

• 保守費に含まれる範囲（監視/障害/軽微修正/運用代行）が明文化されている
• 変更のたびに発生する作業（影響調査・テスト・リリース）が見積に分解されている
• 月に何回、どの業務が変わるかが整理できている
• よく変わる部分は設定で変更できる設計になっている（管理画面/設定ファイル等）
• 外部連携の一覧と、変更時の影響範囲が説明できる
• ソースコード/設計書/環境情報の引継ぎ条件が契約に含まれている
• テスト観点（最低限の回帰テスト）が合意できている
• 改修の優先順位を決める窓口と決裁者が決まっている
• SaaSで代替できる周辺業務が洗い出せている
• 年間総額（保守＋変更＋運用工数）の見立てができている

上の10項目が揃うと、外注・内製の判断も、SaaS比較も“同じものさし”で比較できます。逆に、揃っていない場合は、保守費を下げる前に「見える化」を進めるのが近道です。

よくある質問

保守費が高いと言われたら、まず何を要求すべきですか？

まずは「保守に含まれる範囲」と「変更時に必ず発生する作業の内訳（影響調査・テスト・リリース）」の提示を求めます。内訳が出ると、変更頻度が高い領域と、依存関係が原因の領域が切り分けしやすくなります。

情シスがいなくても内製化は可能ですか？

いきなり全てを内製化するのは難しいですが、「変更頻度が高いのに依存が少ない部分」から小さく始めるのは現実的です。例えば、文言・マスタ・帳票など、設定化しやすい領域を先に整備すると、内製負担が増えにくいです。

また、内製＝エンジニア採用だけではありません。まずは“仕様を決める”“受入をする”という非エンジニアの役割を固めるだけでも、外注費は安定します。小さな改善を回せる状態を作ってから、段階的に内製比率を上げるのが安全です。

外注先を変えるだけで保守費は下がりますか？

構造が密結合のままだと、外注先を変えても影響調査とテストは減りません。まずは依存関係を可視化し、分離や置き換えの計画を作った上で、引継ぎ条件（成果物・権利・環境）を整えるのが近道です。

外注先変更の際は、ソースコードの管理方法、環境構築手順、リリース手順、障害時のログの見方など、運用に必要な情報が渡るかも重要です。ここが抜けると、新しい外注先も調査に時間がかかり、結局高くなります。

要件定義に時間をかけると、逆に高くなりませんか？

短期的にはコストが増えることがありますが、変更頻度が高い業務ほど、要件定義で「どこを設定化するか」「どこを固定するか」を決めないと、改修のたびにコストが増えます。保守費を抑える目的なら、要件定義は“将来コストの削減”として効きます。

ポイントは、要件定義を“全部を書く”のではなく、“よく変わる部分だけ解像度を上げる”ことです。変更頻度が低い部分は粗くても問題ありません。重点配分ができれば、費用は増えすぎません。

SaaSにすると自由度が落ちるのが不安です

自由度の代わりに、保守・法改正対応・セキュリティの多くをサービス側に寄せられます。独自業務を無理にSaaSへ寄せると失敗しやすいので、SaaS比較チェックで「標準で足りる範囲」と「残る独自開発」を分けて判断しましょう。

不安がある場合は、まず“周辺業務”からSaaSを試すのが安全です。依存関係が少ない領域から置き換えると、撤退（出口）もしやすく、効果も検証しやすいです。

まとめ：改善を止めないために、見積の前提を“構造”で整える

「保守が高い」問題は、月額の大小ではなく、変更頻度と依存関係の掛け算で起きます。見積書を読むときは、変更のたびに何が発生するのかを分解し、よく変わる領域は設定化、依存が強い領域は分離・置き換えを検討しましょう。これだけで、改善が“止まる”状態から“回る”状態に近づきます。

外注・内製の判断に迷う場合も、まずは現状整理だけでもOKです。変更が多い業務、依存が強い連携、運用のボトルネックを一緒に切り分ければ、次の一手（改修・再構築・SaaS化・体制づくり）が見えやすくなります。スポット相談でも対応可能ですので、お気軽にご相談ください。

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る