稟議は初期開発費で動くが、財布に響くのは保守・運用・追加開発
システム開発の稟議は初期開発費の額でイエス・ノーが決まりがちですが、実際に会社の財布に響いてくるのはリリース後の「保守・運用・追加開発」の費用です。開発費が 1,000 万円のシステムでも、5 年間の総保有コスト (TCO) で見ると倍近くになることは珍しくありません。にもかかわらず、初期見積の段階で保守運用費が明記されていない、あるいは「別途相談」で処理されているケースが多いのが実情です。
この記事では、発注側の担当者が初期見積の段階で確認しておくべき「保守・運用・追加開発」の見積構造を整理します。相場感、契約に含まれる / 含まれない項目、SLA と単価の関係、月額固定費の内訳、追加開発の妥当性判断まで、長期コストを正しく見積もるための視点を一通り解説します。開発費本体の考え方は システム開発の見積相場 を、初期見積書のチェック項目は 見積書の見方 をあわせて参照してください。
FIXIT保守って開発費の 15〜20% って、けっこう高くない？
Kaname運用に乗せると 5 年は動かしますから、むしろ抑えめな水準です。
FIXITKanameOS やライブラリの追随、脆弱性対応、外部連携先の仕様変更で工数を使います。
FIXITじゃあ「保守は要らない」って選択は、事実上ない？
Kaname数か月止まっても平気な社内ツールなら別ですが、業務で使うなら年単位で予算を確保しておかないと止まります。
1. 「保守」「運用」「追加開発」の分類と定義
まず用語を揃えます。現場では混同されがちですが、契約書と見積上は別枠で扱われることがほとんどです。
| 区分 | 内容の例 | 見積の建て方 |
|---|---|---|
| 保守 | バグ修正、脆弱性対応、OS / ライブラリのアップデート追随、軽微な仕様調整 | 月額固定または年額 |
| 運用 | 監視、障害一次対応、バックアップ、アカウント管理、定型作業 | 月額固定 + 従量 |
| 追加開発 | 新機能追加、既存機能の大幅改修、他システム連携追加 | 都度見積 (人月ベース) |
保守と運用を明確に分ける会社と、まとめて「保守運用」と呼ぶ会社があります。呼び方は問題ではなく、「何が含まれ、何が別料金なのか」がドキュメント化されているかどうかが本質です。
「軽微な仕様変更」は保守か追加開発か
もっともグレーゾーンになりやすいのがこの境界線です。「文言修正やボタンの色変更は保守内、画面追加や業務ロジックの変更は追加開発」と契約書で明文化されていないと、毎回もめる原因になります。契約時に「1 回あたり何人日以内、月間累計何人日まで」といった上限を数字で決めておくのが実務的です。
2. 保守費用の相場は開発費の 15〜20% が目安
年間の保守費用は、初期開発費の 15〜20% が国内の一般的な目安です。1,000 万円で作ったシステムなら、年 150〜200 万円、月額 12〜17 万円程度がベースラインになります。ただしこれは「案件によって 10% を切ることも、30% を超えることもある」レンジであり、次のような要因で上下します。
保守費が上振れしやすいケース
- 24 時間 365 日の稼働が必要で、夜間の障害一次対応が発生する
- 決済・個人情報など高セキュリティ領域を含む
- 外部システム連携が多く、連携先の仕様変更で保守作業が発生する
- 独自フレームワークや古い技術スタックで作られている
- 利用者数が多く、問い合わせ対応工数が積み上がる
保守費が下振れしやすいケース
- 社内利用のみで、営業時間対応でよい
- モダンで標準的な技術スタックで、アップデート追随が容易
- 外部連携が少なく閉じたシステム
- 利用者が少なく、問い合わせが限定的
「開発費の ○%」という比率だけで判断せず、上記の条件のうち自社のシステムがどこに該当するかを見積依頼時に共有すると、精度の高い保守費見積が返ってきます。
3. 保守契約に含まれる項目・含まれない項目の一般例
保守契約でもっとももめる原因は「これは保守の範囲内だと思っていた」という認識のズレです。契約書ドラフト時に、次の表のような整理を行っておくと安全です。
| 含まれることが多い | 別料金になることが多い |
|---|---|
| 障害調査・原因特定 | 大規模なバグ発覚時の全面改修 |
| 発見された不具合の修正 (納品済み仕様の範囲内) | 仕様変更を伴う修正 |
| OS・ミドルウェア・ライブラリのマイナー更新 | メジャーバージョンアップ (言語・DB の世代交代) |
| セキュリティパッチの適用 | 脆弱性発覚に伴うアーキテクチャ変更 |
| 定型的な問い合わせ対応 (月あたり件数の上限あり) | エンドユーザー向け直接サポート |
| バックアップの正常性確認 | データ復旧作業 (有事対応) |
| 月次レポートの提出 | 個別分析・KPI ダッシュボードの新規作成 |
「含まれない項目」に該当する作業が発生した場合の単価も、契約時に決めておくのが望ましい運用です。単価が未定のまま追加作業を依頼すると、あとから想定外の請求が来る温床になります。
4. SLA (応答時間・稼働率) と見積の関係
SLA (Service Level Agreement / サービス品質保証) は、保守費を左右する最大の変数の 1 つです。同じシステムでも「翌営業日対応」と「1 時間以内の一次応答」では、必要な体制が変わるため見積が 2 倍以上開くこともあります。
SLA で確認すべき 3 点
契約時に確認するのは、応答時間・復旧目標時間・稼働率の 3 点です。応答時間は、障害連絡から一次応答までの時間で、営業時間内 30 分以内といった形で定めます。復旧目標時間 (RTO) は、どの程度の時間で復旧させるかの目標値で、4 時間以内といった形で定めます。稼働率は、月間または年間の目標稼働率で、99.5% といった形で定めます。この 3 点のうち、どれか 1 つが厳しくなるだけで、必要なオンコール体制と監視構成が変わり、保守費に直接反映されます。
稼働率と体制の関係
稼働率 99% (月間ダウンタイム約 7 時間) と 99.9% (同約 43 分) では、必要な監視体制・冗長構成・オンコール人員が異なります。「とりあえず高い方に」と設定するのではなく、業務停止時のビジネスインパクトから逆算して決めるのが妥当です。基幹業務なら 99.9%、社内の補助的ツールなら 99% 以下でよい、という判断も現実的にはあり得ます。
なお、SLA を保証するには準委任契約より請負契約に近い建て付けが必要になるため、契約形態にも影響します。詳細は 請負契約と準委任契約 を参照してください。
5. インフラ費・監視費・SaaS 費など月額固定費の見落とし
開発費と保守費の議論に集中すると、月額のランニングコストが抜け落ちがちです。次の項目は、初期見積の段階で「誰がどう支払うか」を確定しておくべきコストです。
- クラウドインフラ費 (AWS / GCP / Azure など): 負荷やデータ量で変動する月額利用料
- 監視・ログ基盤費 (Datadog / New Relic など): 監視対象数とログ量に応じた月額
- エラー通知・パフォーマンス計測 (Sentry / Bugsnag など): イベント数ベースの月額
- メール送信・SMS 送信サービス (SendGrid / Twilio など): 従量課金
- CDN・画像配信 (Cloudflare / CloudFront など): 転送量に応じた月額
- 外部 API 利用料: 地図・決済・認証など、月額または従量
- 有料ライブラリ・SaaS ライセンス: 業務ロジックで使う商用 SDK など
- ドメイン・SSL 証明書: 年額数千円〜数万円
- 開発環境の維持費: ステージング環境も本番と別に費用が発生
これらは開発会社の見積書に載らず、「請求はサービス提供元から直接」となる項目が多くあります。契約名義が誰か (発注側か開発会社か)、支払い方法 (クレジットカードか請求書か)、コスト超過時のアラート運用まで、初期段階で決めておくと、あとの経費処理と稟議がスムーズです。
コツ
月額固定費のうち、クラウドインフラ費と外部 API の従量課金は、負荷が読みきれない初期こそブレやすい費目です。開発会社に「想定利用量における月額試算」と「利用量が 2 倍に伸びたときの月額試算」の両方を出してもらうと、稟議で説明しやすい数字になります。
6. 追加開発の見積の妥当性を判断する 4 つの観点
リリース後、事業側から「この機能を追加したい」という要望はほぼ確実に出ます。そのときに提示される追加開発の見積が妥当かどうかを、発注側が判断できる観点を整理しておきましょう。
(1) 工数の内訳が要件単位で示されているか
「一式で何人月」というレベルではなく、要件ごと・テスト・リリース作業のそれぞれに何人日かかるのか、というところまで内訳が割れているかを確認します。割れていない見積は精度が低い可能性が高いです。
(2) 既存コードへの影響範囲が明示されているか
追加開発は、既存機能への回帰テスト工数が意外に大きくなります。「影響を受ける画面・機能」「テスト対象範囲」が明記されているかは、見積の質を見る指標になります。
(3) 初期開発時の単価と整合しているか
初期開発時の人月単価と、追加開発の単価に大きな乖離がないかを確認します。同じ会社・同じ体制で単価が 2 倍になっているなら、その理由 (希少スキル要員のアサインなど) を説明してもらう必要があります。
(4) 別会社に依頼した場合との比較可能性
自社で工数を再計算できない場合は、別会社に相見積を取ることも選択肢です。ただし、既存コードのキャッチアップ工数が別会社側で必要になるため、単純比較にはならない点に注意します。
追加開発と仕様変更の見積判断について、より実務的な観点は 仕様変更・追加の見積 で詳しく解説しています。
まとめ
保守・運用・追加開発は、初期開発費と切り離して見積・契約するのが原則です。保守費の目安は年額で開発費の 15〜20%、対応時間帯やセキュリティ要件・連携数によっては 10〜30% のレンジで振れます。契約時には「含まれる項目」と「含まれない項目」、そして後者の単価まで明記し、SLA (応答時間・稼働率) を業務停止時のインパクトから逆算して設定します。クラウド費や監視費など月額固定費は初期見積段階で名義と支払い方法を確定させ、追加開発の見積は工数の内訳・影響範囲・単価整合・比較可能性の 4 点で妥当性を判断します。この視点をそろえておけば、5 年 TCO で見たときに「保守費が想定の 2 倍だった」という事故を避けられます。
AI 駆動開発のクリエイティブスタジオである FIXIT では、初期開発の見積段階から保守運用フェーズを含めた長期コストの試算をお渡ししています。「5 年 TCO で見たときの妥当な予算感を知りたい」というご相談は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。