再構築後の保守を考える企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、保守は障害対応だけでなく、改善と相談窓口の設計も含めることを重視して進め方を整理します。
この記事では、基幹システムの再構築後に結ぶ保守契約で確認すべきポイントを整理します。開発が終わった後の運用を見据えて、保守の内容と範囲を事前に設計したい担当者・経営者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
保守契約は「障害が起きたら直す」だけではない
保守契約と聞くと障害対応を思い浮かべますが、基幹システムの保守にはもっと広い役割があります。日常の問い合わせ対応、軽微な改修、法改正への対応、データベースのメンテナンス、セキュリティアップデート、そして業務の変化に合わせた改善提案。これらのうち何が保守の範囲に含まれ、何が別途費用になるのかを契約前に明確にしておかないと、稼働後に「思っていたサポートが受けられない」という不満が生まれます。
保守は「コスト」ではなく「システムの寿命を延ばす投資」
保守費用を削減したい気持ちは理解できますが、保守を削るとシステムの劣化は確実に早まります。障害の放置、セキュリティの未対応、法改正への未追従は、いずれ業務停止や法令違反として大きなコストになって返ってきます。保守費は、再構築で投じた初期投資を守り、システムの稼働寿命を最大化するための維持費だと捉えてください。適切な保守があるからこそ、システムは10年以上にわたって価値を発揮し続けられるのです。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、保守契約の範囲が曖昧なまま稼働を迎え、軽微な修正の依頼のたびに「保守範囲外です、別途見積になります」と言われて不信感が募るケースです。保守範囲は、問い合わせ対応・障害対応・軽微修正・法改正対応・定期メンテナンスの各項目について、含む・含まないを一覧にして契約書に明記しておくのが基本です。
また、保守契約を結ばずに稼働し、障害が起きてから依頼先を探すケースも危険です。基幹システムの障害は業務停止に直結するため、発生から数時間以内に対応できる体制が必要です。保守契約のない状態で障害が起きると、対応可能な会社を探すところから始まり、その間業務が止まります。
さらに、開発会社とは別の会社に保守を依頼するケースでは、引き継ぎの質が保守の質を決めます。設計書・ソースコード・運用手順書が整備され、引き継ぎ期間に十分な時間が取られているかを確認してください。
自社で確認できるチェックポイント
保守契約の内容を検討する前に、次の点を確認してください。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
保守契約ならではの確認ポイント
基本のチェックリストに加えて、保守の範囲定義（何が含まれて何が別途か）、対応時間（平日のみか・夜間休日対応の有無）、障害時の初動目標時間（SLA）、月間の問い合わせ・軽微修正の上限件数、年間の保守費用と改修費用の区分、担当者の引き継ぎルール、そして契約期間と更新条件を確認してください。特にSLA（障害の初動までの時間）は、業務への影響度で区分を設け、最重要の業務には数時間以内の対応を求めるのが適切です。
保守費用の目安は、初期開発費の15〜20%／年が一般的です。この費用で障害対応・問い合わせ・軽微修正・定期メンテナンスをカバーするのが標準的な保守契約の相場感です。これより大幅に安い保守は範囲が狭い可能性があり、高い場合は改修費用が含まれている可能性があります。内訳を確認してください。
保守契約では、担当エンジニアの固定化も交渉すべきポイントです。毎回違う人が対応すると、経緯の説明からやり直しになり、対応の速度と質が落ちます。担当を固定するか、少なくとも引き継ぎの仕組みを持つ保守体制を選んでください。
保守契約の見直しは年に一度行うことをおすすめします。業務の変化でシステムの利用形態が変われば、保守に求める内容も変わります。SLAの水準、対応範囲、費用のバランスを毎年確認し、必要に応じて調整するのが、保守を最適な状態に保つコツです。
延命・部分改善で対応できるケース
保守の体制は規模に合わせて設計すべきです。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
小規模なシステムであれば、月次の定期メンテナンスと障害時のスポット対応で十分なこともあります。大規模なシステムでは、専任の保守チームと定期的な改善提案を含む手厚い契約が必要です。自社のシステム規模と業務の重要度に合った保守レベルを選ぶことが、過不足のない費用設計のコツです。
また、保守契約の中に年1回の「定期健診」を含めることをおすすめします。データベースの肥大化、性能の低下、セキュリティの脆弱性を定期的にチェックし、小さな問題を大きくなる前に対処する仕組みです。
保守契約は開発契約と同時に検討を始め、稼働前に締結するのが理想です。稼働後に慌てて保守を探すのではなく、開発段階から保守への移行を計画に含めてください。特に、開発会社が保守も担う場合は、開発契約の中に保守移行の段取りを明記しておくとスムーズです。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
構築方式によって、保守の形態は異なります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージの場合、バージョンアップ対応がベンダーに委ねられる反面、カスタマイズ部分の保守は別途必要です。パッケージの保守とカスタマイズの保守を分けて契約するケースもあります。
周辺開発で補うケース
周辺開発の保守は、開発した会社に継続依頼するのが最もスムーズです。小規模な改修を月額の中で柔軟に対応できる契約形態が使いやすくなります。
スクラッチ再構築が向くケース
スクラッチの場合、設計思想を知る開発会社に保守を任せるのが品質面で最も安定します。開発から保守への移行期に引き継ぎ資料と運用手順書を整備することが条件です。
マクティズムの見解
マクティズムの見解として、基幹システムの保守契約で確認すべきことでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、保守は障害対応だけでなく、改善と相談窓口の設計も含めることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
保守の相談で私たちが最も大切にしているのは、「作ったら終わり」にしないことです。稼働後こそシステムの本当の価値が問われる時期であり、業務の変化に合わせた改善提案を含めた保守こそが、開発会社としての本領だと考えています。10年使い続けるシステムを10年支え続ける。その覚悟を持ったお付き合いが、私たちの保守の姿勢です。
相談前に準備しておく情報
保守の相談では、現行の保守体制と費用、障害の発生頻度と対応状況、改修要望の頻度、保守で不満を感じている点が分かると、初回から最適な保守体制を提案できます。現在の保守契約書のコピーがあれば、改善点を具体的に指摘できます。
実務では、開発の終盤から保守移行計画を策定し、稼働初月の集中支援期間を経て定常保守へ移行する段階的な形をおすすめしています。
よい保守契約は、障害を防ぎ、改善を継続し、システムの寿命を延ばします。初期投資と同じくらいの真剣さで保守を設計してください。システムは作って終わりではなく、使い続けて初めて価値を生むものだからです。
保守は地味な仕事ですが、日々の業務を静かに支え続ける、最も長く効く投資です。安定した保守に支えられたシステムは、現場にとって空気のように当たり前の存在になります。その当たり前が、業務の安心感そのものです。
保守の設計は、範囲の定義、SLAの設定、費用の取り決め、引き継ぎ計画の策定、契約の締結、の順です。開発と並行して進め、稼働日に保守が始まる状態を目指してください。
保守の品質は日常的に感じにくいものですが、障害が起きた瞬間にその価値が分かります。適切な保守に支えられたシステムは、障害時でも素早く復旧し、業務への影響を最小限にとどめます。その安心感は、保守費以上の価値を持っています。
保守契約を結ぶということは、システムの安定運用を「仕組み」として確保することです。個人の善意や記憶に頼る運用から、契約に基づく確実な体制へ。この切り替えが、基幹システムの寿命を大きく左右します。
保守の設計は、再構築と同じくらい重要な投資判断です。作ることに注力するあまり、守ることを後回しにしないでください。
よい保守契約に支えられたシステムは、10年使い続けても現役です。その10年の安定が、保守への投資の本当のリターンです。
システムの価値を守り続けること。それが保守の使命であり、開発と同じくらい大切な仕事です。
守り続ける体制を、最初から設計してください。それが再構築の投資を完成させる最後のピースです。
よくある質問
保守期限が近い場合、いつから相談すべきですか？
規模にもよりますが、基幹システム再構築は1年〜1.5年以上かかることがあります。保守期限が見えた時点で現状整理を始めるのが安全です。現在の保守の状況と不満点が分かれば十分に相談を始められます。
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。はい。稼働後の保守体制まで含めた提案を、開発段階からお出しします。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。パッケージ保守と周辺保守の切り分けも含めて、一緒に設計します。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。はい。保守契約のレビューや改善提案だけのご依頼にも対応しています。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。保守への不安をお聞かせください。安心できる体制を一緒に設計します。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。
