保守開発の進め方は、現状分析から始め、内製と外注の判断、RFP・SLAの設計、乗り換え時のROI、AIOpsやSREを使ったモダンな保守、紛争時の法的対応へと進む一連の流れです。
属人化やベンダーロックインに不安を抱える情シス担当者にも、この流れの把握は安定稼働に欠かせません。最低限ラインも後半で示します。
Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
保守開発の全体像と基本概念
保守開発とは、稼働中のシステムに対して、障害対応、機能改修、セキュリティ更新、性能改善などを継続的に行い、ビジネスの変化に追随させていく一連の活動です。
運用と違って、保守はシステムに変更を加える非定型の業務が中心になります。保守開発の進め方を誤ると、属人化やブラックボックス化が進み、ベンダーロックインや突発的なコスト増といったリスクに直結します。
運用と保守の違いと業務範囲
運用は、システムを止めずに動かし続けるための定型業務で、サーバの起動停止、バックアップ取得、パッチ適用、ネットワーク監視などが含まれます。これに対して保守は、障害発生時の復旧やプログラム修正、新たな業務要件に応える機能改修など、非定型で変更を伴う業務が中心です。
両者を曖昧なまま契約すると、SLAの責任範囲がはっきりせず、トラブル時の押し付け合いになりがちです。そのため、実務では、運用業務と保守業務を別々の契約に切り分けるケースも増えています。たとえば、24時間365日の監視と一次対応は運用ベンダー、プログラム修正と機能改修は開発ベンダーといった形で役割を分けます。
境界を明確にしておくと、責任分界点の議論が進めやすくなり、後述するSLA設計や費用交渉でも有利に働きます。
保守開発の種類と契約形態
保守の種類によって必要な頻度が変わるため、種類を整理しておくことが、契約条件の検討の出発点になります。
- 是正保守：障害発生後の修正
- 予防保守：セキュリティパッチ適用などの先回りの対応
- 適応保守：法改正やOSアップデートへの追随
- 完全化保守：新機能追加やパフォーマンス改善
自社のシステムの特性に応じて、どの保守がどの程度の頻度で必要かを整理しておくと、後の見積もりの精度が大きく上がります。
契約形態には、請負契約、準委任契約、SES契約のほか、近年は「ラボ型開発」を保守の第3の選択肢として選ぶ企業も増えています。
ラボ型は、チーム単位で一定期間を確保し、試行錯誤しながら保守や改修を進める形態です。仕様変更の頻度が高い保守案件と相性が良いという特徴があります。
契約形態は、請負なら瑕疵担保責任が明確、準委任なら柔軟性が高い、ラボ型ならチームの継続性が担保される、という観点で選ぶと失敗が減ります。
現状分析と保守開発の進め方
保守開発の進め方は、まず現状分析から始まります。属人化、仕様書の欠落、対応の遅れ、費用が妥当かどうか分からないといった課題を洗い出すと、内製と外注の判断や乗り換えの優先度が見えてきます。
ここを丁寧に行わないまま外注先の選定に進むと、表面的な相見積もりだけで決めてしまい、後の引き継ぎで失敗する典型的な流れに入ります。
属人化・ブラックボックス化のチェック
現状分析では、属人化とブラックボックス化の度合いを確かめます。担当エンジニアが退職した途端にシステムが動かなくなる、仕様書が口頭伝承のみで残っていない、ソースコードのコメントがほとんどない、といった状態は要注意です。
社内の属人化は、担当者の不在シミュレーション、ドキュメントカバレッジ、テストケース数といった指標で調べられます。
外部ベンダーに保守を委託している場合は、コーポレートロックインとテクノロジーロックインの両面から評価する必要があります。
- コーポレートロックイン：業務仕様を特定のベンダーが独占している状態
- テクノロジーロックイン：独自のフレームワークや独自ミドルウェアに依存している状態
どちらか一方でも当てはまると乗り換えのハードルが急に高くなるため、優先して解消する策を検討します。
内製と外注の判断基準
内製と外注は、得られるものと抱えるリスクが表裏の関係にあります。
- 内製：業務への理解やノウハウが蓄積しやすいものの、人材の確保が難しく、属人化のリスクも抱える
- 外注：体制が安定している反面、中身が見えにくく、情報の差からコストが不透明になりがち
判断軸は、次の4点です。
- 業務クリティカリティ：止まると業務への影響が大きいかどうか
- 改修頻度：仕様変更や機能追加が、どの程度の頻度で起きるか
- 社内エンジニアのスキルセット：保守を社内で担える技術や経験があるか
- 想定インシデント時のダウンタイム許容度：障害時に止められる時間をどこまで許せるか
これらを評価することが推奨されます。たとえば、改修頻度が低く、ダウンタイムを大きく許容できる社内システムは、外注が向いています。一方で、サービスの差別化に直結するコア機能で改修頻度が高い場合は、最低限のコアエンジニアを内製で確保し、周辺機能を外注するハイブリッド体制が現実的です。
情シス担当者がほぼいない中小企業では、外注が前提になります。そのうえで、「丸投げ」を避け、月次レビューを社内で必ず実施するルールを設けることが大切です。
外注先選定と相見積もりの進め方
外注先を選ぶときは、同業界の保守実績、得意な技術領域、企業の業績の安定性、インシデント対応の実績、担当者の提案力とコミュニケーション能力の5点を必ず確認します。
相見積もりの社数は、3〜4社が最適とされています。これは、比較の精度と社内の合意形成のスピードのバランスから導かれた経験則です。社数が多すぎると比較に疲れて意思決定が遅れ、少なすぎると相場感がつかめません。
インシデント対応の実績は、過去のSLA達成率、平均復旧時間(MTTR)、24時間365日対応の有無、重大インシデント時のエスカレーション体制から見抜けます。「対応できます」といった抽象的な回答より、具体的な事例と数値を示せるベンダーのほうが信頼できます。また、提案資料に過去案件のKPIが載っているかどうかは、提案力を測る目安になります。
RFPとSLAの設計方法
保守開発を成功させる肝は、RFP(提案依頼書)とSLA(サービスレベル合意書)の設計品質にあります。RFPの粒度が粗いと見積もりは大きくばらつき、SLAが曖昧だと障害時の責任分界で揉めやすくなります。逆に、ここを丁寧に作り込めば、提案の精度が高まり、契約後のトラブルを大きく減らせます。
RFPに記載すべき必須項目
RFPの必須項目は10項目あり、まずは見積もりの前提になる5項目を挙げます。
- システム概要
- 保守対象範囲
- 現状の課題
- 期待する成果
- 対応時間帯
残りの5項目は、障害時の連絡や納品物、契約と予算、選定の基準に関わります。
- 障害時の連絡フロー
- ドキュメント納品要件
- 契約期間と更新条件
- 予算レンジ
- 選定基準
とくに、対応時間帯と障害時の連絡フローは曖昧にしないことが大切です。たとえば、平日9〜18時か24時間365日かで、見積もりは大きく変わります。
中小企業や情シスゼロ企業は、最低限ラインとして、(1)現状のシステム構成図、(2)直近1年間の障害履歴とその対応時間、(3)期待する応答時間と復旧時間の3点を整理することを推奨します。
フル装備のRFPが理想ですが、これだけ揃えれば見積もりの精度は大きく上がり、提案ベンダーから的確な質問も返ってくるようになります。
SLAとSLOの使い分けと法的注意点
SLA(Service Level Agreement)とSLO(Service Level Objective)は、次のように役割が違います。
- SLA：契約上の約束で、達成できなければペナルティが発生する
- SLO：事業者側の目標値で、契約上の拘束力は持たない
両者の使い分けが曖昧なまま運用すると、障害時に責任の所在で揉める原因になるため、契約段階でどちらの位置付けかを明示することが大切です。
返金の決め方はサービスごとに違い、たとえば次の2社は条件の立て方が対照的です。
- Amazon S3：月間稼働率95%を下回ると100%返金を明記
- サイボウズ：SLAではなく「目標値としてのSLO」を採用し、別途「連続24時間単位での返金保証規定」を組み合わせるハイブリッド型
自社のサービス特性に応じて、厳密なSLA型とハイブリッド型のどちらにするかを設計段階で決めておくと、後悔が少なくなります。
法的な注意点として、「稼働率〇〇%未満で利用料の〇〇%返金」といったSLA条項は、民法548条の2第1項の「定型約款」として扱われ得るため、留意が必要です。変更時はインターネットでの周知など法的な要件があり、一方的な改定は無効とされる可能性があります。そのため、法務部門と連携してリーガルチェックを行うと、後の紛争を防ぐうえで効果があります。
責任分界点と損害賠償の合意形成
セキュリティインシデントへの対応が遅れ、数千万円規模の損害賠償に発展した事例も実在します。
責任分界点を曖昧にしたまま契約すると、事故の際にベンダーとユーザー企業が押し付け合いになり、被害が拡大する典型的なパターンが繰り返されています。
サイバー攻撃の発生時については、次の3点を契約書に書き込んでおくことが、事業継続の観点で欠かせません。
- 初動責任：サイバー攻撃を検知した際に、どちらが先に対応するか
- 復旧責任：システムを元の状態に戻す作業を、どちらが担うか
- 賠償範囲：損害のうちどこまでを賠償の対象とするか
SLAペナルティの賠償上限額は、月額利用料の数十パーセントから1〜3ヶ月分相当が一般的な目安です。
実損が出た場合の補償範囲、上限の有無、第三者への損害の扱いなど、論点ごとに合意を取ったうえで、条文に落とし込みます。
中小企業の場合は、サイバー保険と組み合わせて実損リスクに備える実務パターンも増えています。契約交渉と並行して保険商品を検討すると、安全度が高まります。
保守ベンダー乗り換えのROIシミュレーション
保守ベンダーの乗り換えを稟議に通すには、定性的な不満よりも、定量的なROIシミュレーションを根拠にすることが大切です。費用対効果を試算するフォーマットを用意しておけば、経営層への説明がスムーズになり、意思決定も速まります。
乗り換えROIの算出フォーマット
ROIの算出は、「(現状の月額保守費 − 乗換後の月額保守費) × 想定継続月数 − 移管初期費用」の式で行います。
移管初期費は、引き継ぎ費用やリバースエンジニアリング費が主なコストです。
保守費用の相場は、年間開発費の10〜20%が一般的な目安です。たとえば、開発費1,000万円のシステムなら月額50〜150万円程度で、システム規模によっては月額60〜240万円のレンジに収まります。
数字を当てはめた例では、毎月の差額40万円を10ヶ月積み上げれば、移管初期費と相殺できます。
- 現状の月額保守費：120万円
- 乗換後の月額保守費：80万円
- 移管初期費：400万円
11ヶ月目以降は純粋なコスト削減となるため、3年間のトータルでは1,000万円超の削減効果が見込めます。この試算を稟議資料に明記すると、経営層から承認を得やすくなります。
他社システム保守移管の手順と並走期間
他社製システムの保守移管は、8つのステップで進めます。
- 現状把握
- 新ベンダー候補の選定
- 費用とスケジュールの確認
- ドキュメントの洗い出し
- 現ベンダーとの解約交渉
- 新旧ベンダーの並走
- 本番移管
- 再ロックイン防止策の整備
移管にかかる期間は1ヶ月半〜10ヶ月ですが、一般的には3〜6ヶ月を見込むのが現実的とされています。
並走期間は1〜3ヶ月を設定するのが標準的で、この期間に障害対応のシミュレーションを2〜3回行い、運用ノウハウを確実に移転します。
並走期間を省くと、本番移管直後に起きた障害で復旧が遅れるリスクが急に高まります。そのため、コスト削減を理由に短縮するのは推奨されません。並走期間中の費用は二重に発生しますが、結果的にトータルコストは下がるケースが大半です。
波風を立てない解約交渉トーク
現行ベンダーへの解約通告は、引き継ぎへの協力の度合いを左右する繊細なやりとりです。「御社に問題があるから乗り換える」と受け取られると、ドキュメントの提供拒否やパスワードの共有遅れなど、報復的な対応を招くおそれがあります。
実務では、「社内の方針変更により保守体制を見直す」「グループ全体のIT戦略の一環として再編する」といった中立的な言い回しが推奨されます。解約を伝えるタイミングは、新ベンダーの選定が完了し、並走期間の合意が取れた段階が理想です。早すぎると現行ベンダーの意欲が下がり、遅すぎると引き継ぎの期間を確保しにくくなります。
解約後も再委託や緊急時の対応で関係が続く可能性があるため、最後まで誠実な姿勢を保つことが、業界での評判を守ることにもつながります。
AIOps・SRE・マイクロサービス化によるモダン保守
従来の保守開発は人手に頼る進め方が前提で、コストは下がらないものとして語られてきました。しかし近年は、AIOpsやSRE、マイクロサービス化を取り入れることで、保守費用を抑えながら可用性を高められるようになっています。
モダンな保守の手法を提案できるベンダーかどうかは、長期的なパートナーを選ぶうえで大きな分かれ目になります。
AIOpsとSREによる自動化提案
AIOpsは、機械学習を使って異常検知やログ分析を自動化する仕組みで、人手による監視の負担を大きく減らします。SRE(Site Reliability Engineering)は、信頼性を工学的に高めるアプローチで、エラーバジェットやポストモーテムといった考え方で運用を体系化します。
これらを取り入れると、人月単価ベースの保守費を、自動化基盤への投資に置き換えていく流れが業界で広がっています。
自動化を提案できるベンダーかどうかは、過去の自動化導入実績、MTTR短縮の定量効果、運用工数削減の事例数の3点で見分けます。「監視ツールを導入しました」だけでなく、「年間運用工数を300時間削減しました」のように具体的な数値で語れるかどうかが、提案力の指標になります。提案段階でこの観点を打ち出せるベンダーは、長期的に保守コストを抑えていける相手として信頼できます。
マイクロサービス化によるロックイン根本解決
モノリシックなシステムは機能間の依存が密接で、ベンダーロックインに陥りやすい構造です。
一方で、マイクロサービス化により機能ごとにモジュールを分けると、機能別に異なるベンダーへ発注するマルチベンダー戦略が技術的に成り立ちます。その結果、一部の機能に問題が起きても、その機能だけを別のベンダーに移せるため、ロックインの根本的な解決につながります。
注意点として、オープンソースを採用していても、ソースコードの著作権がベンダーに帰属したままだと、結局ロックインから抜け出せません。そこで、契約段階で「成果物の著作権はユーザー企業に帰属する」「ベンダーは利用許諾を受ける形にする」といった条項を明記することが、技術のアーキテクチャと並ぶ大事な対策です。法務と技術の両面から防衛策を講じることが欠かせません。
紛争時の法的エスカレーションと最終手段
保守開発の進め方で見落とされがちなのが、旧ベンダーとの紛争時に取る法的なエスカレーションの手順です。ソースコードの開示やドキュメントの提供を拒まれるなど、非協力的な対応を受けた場合、放置すると事業継続に深刻な影響を及ぼします。事前に法的な対応の選択肢を理解しておくと、いざという時に冷静かつ迅速に動けます。
弁護士相談と第三者仲裁の選択基準
ソースコードや設計書の開示を拒まれた場合は、まず契約書の該当条項を確認し、内容証明郵便で正式に開示を請求します。それでも応じない場合は、IT分野に強い弁護士への相談が次の段階になります。判例では、契約に基づく成果物の開示義務違反として損害賠償請求が認められたケースも複数あり、法的な根拠ははっきりしています。
訴訟に進むと時間とコストが膨らむため、第三者仲裁機関の活用も有力な選択肢です。たとえば、一般財団法人ソフトウェア情報センターなどが提供するADR(裁判外紛争解決手続)では、専門知識のある仲裁人が短期間で判断を下します。また、費用も訴訟より抑えられるうえ、関係修復の可能性を残せるため、中小企業にとっては現実的なエスカレーション手段となります。
リバースエンジニアリングという最終手段
旧ベンダーが非協力的で、ドキュメントも残っていないという最悪のシナリオでは、第三者のエンジニアがソースコードから設計書を起こし直す、リバースエンジニアリングが最終手段になります。費用は数百万円から1,000万円超に及ぶこともありますが、長期的なロックインを解く保険として有効です。
本番システムを止めずに解析するため、ステージング環境の構築や検証期間の確保も欠かせません。アカウントの引き継ぎで特に見落とされやすいのは、次の点です。
- 全パスワードの再設定：移管時に全パスワードを再設定しないと、旧ベンダーの関係者がアクセスできる状態が残り続けます。
- 不要な権限の削除：残ったままだと、退職者経由の情報漏洩リスクが表面化します。
- 権限と鍵の把握：IAM権限、SSH鍵、APIキー、データベース管理者アカウントの4種を網羅的に洗い出し、移管完了時の必須チェックとします。
まとめ
保守開発の進め方は、現状分析から始めて、内製と外注の判断、ベンダー選定、RFP・SLAの設計を進めます。そのうえで、契約後の運用、乗り換え時のROIシミュレーション、紛争時のエスカレーションまでを一連の流れとして見通しておくことが大切です。属人化やブラックボックス化、ベンダーロックインといった構造的な課題は、場当たり的な対応では解決しにくく、長期を見据えた管理が求められます。
とくに中小企業や情シスゼロ企業では、フル装備のRFPやマルチベンダー化が現実的でない場合があります。その場合でも、現状のシステム構成図、直近1年の障害履歴、期待する応答時間と復旧時間の3点を押さえるだけで、見積もりの精度と契約の質は大きく上がります。
法的な面では、SLA条項の定型約款としての扱いや責任分界点の合意形成について、法務と連携して進めることが、後の紛争を防ぐことにつながります。
これからの保守開発は、AIOpsやSRE、マイクロサービス化といったモダンなアーキテクチャを取り入れ、コストを抑えつつ可用性を高める方向に向かっています。
乗り換えでは、ROIシミュレーションを稟議資料に明記し、波風を立てない言い回しで現行ベンダーとの関係を保ちます。さらに、新旧の並走期間を十分に取り、リスクを抑えます。万が一紛争になったときに備えて、ADRやリバースエンジニアリングという選択肢も持っておきます。
保守の進め方を押さえることで、自社のシステム保守は「コストセンター」から「事業継続を支える戦略基盤」へと変わっていきます。
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。