自社開発システムの運用保守は外注できる？社内開発との役割分担
新しい機能を作りたいのに、利用者からの問い合わせやエラーの調査で一日が終わってしまう。社内でシステムを開発している中小企業では、開発担当者が日々の運用も抱え、改善に手が回らなくなることがあります。
自社開発システムでも、運用保守を外部に相談することは可能です。開発を丸ごと手放す必要はありません。社内で開発を続けながら、問い合わせの一次切り分けや定期確認などを保守会社と分担する方法があります。ただし、委託できる範囲は、コードや環境を調査して決めることが前提です。
この記事のポイント
- 社内開発を続けたまま、運用保守の一部を外注する選択肢があります。
- 「誰が判断し、誰が作業するか」を、平常時と障害時の両方で決めます。
- 引き継ぎ前に現状を調べ、対応時間・権限・費用の境界を合意します。
1．自社開発でも運用保守を外注できる
運用保守は、機能追加やプログラム修正だけを指すものではありません。問い合わせの整理、ログの確認、監視通知への対応、バックアップの確認など、日々システムを使い続けるための作業も含まれます。
たとえば、業務をよく知る社内担当者が仕様の決定と開発を担い、保守会社が問い合わせの内容や発生条件を整理して渡す形です。社内担当者は、毎回一から状況を聞き取る負担を減らし、修正や改善の判断に集中しやすくなります。
一方で、外注すれば社内の関与がなくなるわけではありません。業務上の優先順位や、停止を許容できる時間、データ修正の妥当性は、社内で判断する必要があります。委託先と連絡を取れる窓口を置き、担当者が不在の場合の代替連絡先も決めておきましょう。
2．社内開発と保守会社の役割を分ける
最初に整理したいのは、「社内に残したい仕事」と「外部に任せたい仕事」です。以下は、コードの変更とリリースを社内で続ける場合の分担例です。実際の担当範囲は、システムの状態と契約内容に合わせて調整します。
| 作業 | 社内 | 保守会社 |
|---|---|---|
| 仕様決定・機能開発 | 業務要件、優先順位、実装を担当。 | 問い合わせや障害の傾向を共有し、改善の判断材料を提供。 |
| 問い合わせ・不具合調査 | 業務仕様を確認し、必要なコード修正を担当。 | 合意した範囲で受付、再現確認、ログ調査、一次切り分けを担当。 |
| 監視・定期作業 | 監視対象と業務への影響を確認。 | 合意した時間帯・手順で通知確認や定期点検を担当。 |
| リリース・環境変更 | 変更内容の承認、反映、切り戻し判断と実行を担当。 | 事前共有を受け、必要に応じて反映後の確認を支援。 |
| バックアップ・データ修正 | 保全対象、復旧方針、修正内容を承認。 | 合意した範囲で取得状況や復元を確認し、承認済みの修正を実施。 |
マスタや業務データの修正は、単なる入力代行として扱わないことが大切です。対象と修正値を社内が承認し、作業前のバックアップ、影響確認、作業後の照合、記録を手順に含めます。本番環境へのアクセス権限も、保守契約だけで自動的に付与されるものとはせず、必要な操作ごとに確認します。
3．分担でつまずきやすいのは障害対応と変更の共有
「社内のコードが原因か、サーバーが原因か分からない」。障害発生時には、こうした状況が起こり得ます。原因が確定するまで担当を決められない体制では、初動が遅れてしまいます。
そこで、連絡を受ける窓口、初動を指揮する担当、社内への連絡条件を先に決めます。受注が全面停止している状態と、一部画面の表示崩れでは緊急度が異なります。業務影響に応じた重大度を定め、受付時間、一次回答の目安、調査の開始条件、経過報告の頻度を整理しましょう。一次回答までの時間と、原因を解消して復旧するまでの時間は別です。
原因が不明な場合は、事前に承認した範囲で被害拡大の防止や暫定対応を優先し、ログなどの証跡を残して調査を進めます。システム停止や切り戻しを誰が承認するか、緊急対応で許される操作、調査費用の扱いも決めておくと、責任や費用の確認だけで対応が止まる事態を避けやすくなります。
もう一つ重要なのが、変更履歴の共有です。社内が機能を追加したのに、保守会社が以前の仕様を前提に調査していては、切り分けが難しくなります。同じソースコード管理基盤を参照し、環境ごとの構成、リリース日時、変更箇所、既知の不具合を共有します。緊急の直接修正も記録に残し、コードと稼働環境の食い違いを放置しない運用にしましょう。
4．引き継ぎ前に確認しておきたい情報
資料を完璧にそろえてから相談する必要はありません。まずは、次の情報がどこまで分かるかを整理します。
- ソースコード、設計書、画面や業務の説明資料
- サーバー、データベース、外部サービスの構成と連携先
- クラウドの契約主体、アカウント管理者、権限の付与方法
- 言語、フレームワーク、依存ライブラリのバージョンとサポート状況
- 検証環境の有無、リリース手順、失敗時の切り戻し方法・判断基準
- バックアップの対象、保存先、取得頻度、復元手順と確認履歴
- 過去の障害、問い合わせ、手作業で対応している業務
バックアップは、取得に成功しているかだけでなく、復元できるかも確認したい項目です。必要なデータが対象に入っているか、どの時点まで戻せるか、復元後に業務が再開できるかを、検証環境などで確かめる計画を立てます。
仕様書がない場合は、コードと実際の動作、担当者へのヒアリングから整理する方法があります。ただし、情報不足や古い構成によって調査が長引いたり、環境整備が先に必要になったりする場合もあります。資料がなくても必ず引き継げる、と決めつけず、調査結果を見て判断しましょう。
5．対応範囲と費用を契約前にすり合わせる
「月額保守に何が含まれるか」は、作業名だけでなく条件まで確認します。問い合わせ件数や作業時間の上限、調査と改修の境界、時間外対応、外部サービス利用料、追加見積もりが必要な条件を明確にします。
監視の仕組みが常時動いていても、人が24時間対応するとは限りません。夜間・休日の受付や作業が必要なら、対応できる体制と費用を別途確認します。復旧目標を設定する場合も、前提となる構成や作業権限、連絡体制を含めて合意することが重要です。
アクセス権限は必要な範囲に絞り、個別アカウントや多要素認証、操作記録を検討します。個人情報を含むログや検証データは、共有対象、保管先、マスキング、削除方法を整理します。契約終了時に権限を回収し、資料や設定を引き渡せることも確認しておきましょう。
6．小さく引き継ぎ、実際の運用で調整する
進め方は、相談、現状調査、範囲・見積もりの合意、試行的な引き継ぎ、継続運用の順に考えると整理しやすくなります。
最初からすべてを移すより、問い合わせの一次切り分けや定期確認など、対象を絞って始める方法もあります。試行期間に、連絡がつながるか、手順どおり作業できるか、社内に必要な情報が返ってくるかを確認します。その結果をもとに手順や分担を更新し、引き継ぎの完了条件を確かめます。
継続後は、対応内容や未解決事項を定期的に振り返ります。同じ問い合わせが繰り返されるなら、操作説明の改善や機能改修につなげることもできます。社内開発と保守会社が情報を持ち寄れる体制をつくることが、分担を続けるうえで大切です。
よくある質問
Q．開発は社内で続け、問い合わせ対応だけを頼めますか？
A．相談することは可能です。一次受付だけか、ログ調査まで含むかを分け、社内へ引き継ぐ条件と連絡先を決めます。対応可否は調査と協議によって判断します。
Q．設計書がないシステムでも相談できますか？
A．相談できます。まず残っているコードや環境を確認し、不足する情報と調査範囲を整理します。資料の補完や環境整備が必要な場合もあります。
Q．保守を外注すれば、不具合の修正もすべて含まれますか？
A．契約によって異なります。一次調査、暫定対応、コード修正、機能追加を分け、保守費に含む範囲と追加見積もりの条件を確認しましょう。
自社開発を続けながら、運用保守の分担を見直しませんか
Ouverでは、ソースコードとサーバー環境を調査したうえで、保守引き継ぎの可否や進め方を検討します。自社開発を続けたい場合も、現在の体制と、負担になっている作業をお聞かせください。
「開発は社内に残したい」「まずは問い合わせの切り分けを相談したい」など、ご希望をもとに、任せたい範囲を整理するところからご相談ください。