DBA外注の始め方｜業務範囲・契約形態・費用相場を発注者視点で整理

「本番のスロークエリが日に日に増えている」「バックアップは動いているが、リストア手順を誰も検証していない」「深夜にデータベース障害が起きたら、対応できる人が社内に一人もいない」。社内に DBA（データベース管理者）専任がいない中堅企業で、こうした症状が同時多発しはじめると、ようやく「外注も検討すべきでは」という声が経営層から挙がります。

とはいえ、いざ DBA 外注を検討しはじめると、判断材料の少なさに戸惑うはずです。何をどこまで頼めるのか、SES・派遣・準委任・請負のどれで契約すべきか、月額いくらが妥当か、そもそもベンダーが PostgreSQL / MySQL の日常運用ノウハウを本当に持っているのかを見極める術がない。稟議書や見積依頼書に落とし込もうとしても、書ける粒度の判断軸が手元にありません。

DBA 外注が難しいのは、単一の相場や標準契約が存在せず、「業務範囲 × 契約形態 × 費用相場 × 発注チェック」の4つの軸を掛け合わせて設計する必要があるためです。1軸でも定義が曖昧なまま発注すると、月額単価だけが独り歩きし、実際に届いた成果物が期待と噛み合わないまま契約更新に流されてしまいます。

なお、本記事は日常運用・保守フェーズの DBA 外注を対象としています。「PostgreSQL のバージョン EOL 対応でクラウドへ移行する」「オンプレの Oracle から PostgreSQL に載せ替える」など大規模なデータベース移行プロジェクトの外注については、別記事PostgreSQL移行の外注にまとめているのでそちらを参照してください。切り戻し設計・データ整合性検証・移行完了検収基準など、移行フェーズ固有の論点は本記事では扱いません。

本記事では、DBA 外注（日常運用フェーズ）の始め方を発注者視点で整理し、稟議書と見積依頼に使える具体的な判断軸を解説します。読み終えたときに、「うちは運用支援だけ準委任で月◯万円で回すのが妥当」という発注方針の仮説を立てられる状態を目指します。

DBA外注が必要になる状況と、内製・採用との比較

DBA 外注に踏み切る前に、まず「そもそも外注が最適解なのか」を採用・内製育成と並べて評価することが、稟議書の冒頭を書き出す最短ルートになります。

DBA不在で表面化する4つの症状

社内に DBA 専任がいない企業で外注検討のトリガーになる症状は、おおむね次の4つに集約できます。

• 性能劣化: スロークエリが増え、業務時間帯のレスポンスが目に見えて悪化している。開発チームがアプリ側のリファクタで対症療法を続けているが、根本原因がインデックス設計・統計情報・実行計画のどこにあるか切り分けられていない
• 容量逼迫: ストレージ使用量が右肩上がりで、いつ枯渇するかの予測が立たない。パーティショニングやアーカイブ運用が未着手で、緊急対応でストレージ追加を繰り返している
• 障害増加: レプリケーション遅延、ロック競合、ディスク I/O のスパイクなどが月に数回発生し、都度アプリ開発者が業務を止めて調査している。障害記録が属人的で、再発防止策が積み上がらない
• 定常運用の属人化: 特定のエンジニアだけがバックアップ・監視・パラメータチューニングの手順を把握しており、その人が有休や退職に入ると運用が止まる懸念がある

これらの症状が2つ以上重なった段階が、外注検討の実質的なトリガーです。

なお、PostgreSQL のバージョン EOL 対応やオンプレからクラウドへの移行といった「移行プロジェクト」がトリガーとなっている場合は本記事の主対象外です。別記事PostgreSQL移行の外注で、発注仕様書7項目・切り戻し設計・データ整合性検証といった移行フェーズ固有の論点を扱っていますので、そちらをご覧ください。

採用・内製育成・外注の判断マトリクス

DBA 人材を確保する選択肢は、正社員採用・内製育成・外注の3つに大別されます。それぞれの向き・不向きを比較したのが次の表です。

DBA 領域では母集団が限られており、正社員採用に半年以上かかることが珍しくありません。日常運用の症状が既に表面化している状況では、外注で当面の運用を安定させた上で並行して採用や育成を進める、というハイブリッド戦略が現実的な落としどころになるケースが多いです。

外注が最適解になる典型パターン

以下の状況では、外注が「最短で最も低リスクな選択肢」になりやすいです。

• 日常運用の属人化を早期に解消したい: 特定の兼任者が退職する前に、外部ベンダーへ運用手順とナレッジを移管したい
• オンコール対応を分散したい: 深夜・休日の障害対応を社内メンバー1人に集中させたくない。ベンダーのオンコール体制で分散させたい
• 定期改善タスクを外部化したい: 監視ダッシュボード整備、スロークエリ棚卸し、インデックス再設計など、内製すると後回しになりがちな改善タスクを月次で確実に進めたい

逆に、事業のコアロジックがデータベース設計に強く依存している場合や、機密性の観点で本番データを外部に触らせられない場合は、外注ではなく採用・育成を優先すべきです。

DBA外注で頼める業務範囲（日常運用中心）

「DBA を外注する」と一口に言っても、業務範囲は多岐にわたります。RFP（提案依頼書）や見積依頼書を書く前に、どの業務を外注し、どの業務は社内で持ち続けるかを線引きしておくことが、費用と品質の両面で失敗を避けるコツです。

なお本セクションでは日常運用フェーズで頼める業務に絞って解説します。大規模な移行プロジェクトで頼める業務範囲（データ移行設計・切り戻し設計・移行完了検収など）は別記事PostgreSQL移行の外注を参照してください。

DBA外注で頼める代表業務7種

日常運用フェーズで DBA 外注に頼める代表的な業務は次の7種類です。

RFP を書く際は、この7業務を「必須」「オプション」「対象外」に分類しておくと、ベンダー側も見積を出しやすくなり、複数社の比較もしやすくなります。

PostgreSQL固有の日常運用・障害対応ノウハウ

PostgreSQL で日常運用を外注する場合、ベンダーが以下の領域を実務レベルで扱えるかを確認する必要があります。

• VACUUM / ANALYZE 運用: autovacuum のパラメータチューニング、大規模テーブルでの手動 VACUUM の計画、VACUUM FULL とオンライン整理の使い分け
• インデックスメンテナンス: pg_stat_user_indexes を用いた未使用インデックスの棚卸し、REINDEX CONCURRENTLY の運用、B-tree / GIN / BRIN の選択判断
• スロークエリ調査: pg_stat_statements を用いた高負荷クエリの継続監視、EXPLAIN (ANALYZE, BUFFERS) の読み解き、統計情報の再取得判断
• 障害時のロック待ち解析: pg_locks と pg_stat_activity を組み合わせたロック競合の可視化、長時間実行トランザクションの検出と対応

なお、論理レプリケーションを用いたバージョンアップ、pg_dump ベースの移行、切り戻し設計、データ整合性検証といった移行フェーズ固有のノウハウは本記事では扱いません。詳細はPostgreSQL移行の外注を参照してください。

MySQL固有の日常運用・障害対応ノウハウ

MySQL の場合は、以下の領域が日常運用の焦点となります。

• InnoDB バッファプール調整: innodb_buffer_pool_size の適正化、innodb_buffer_pool_instances の分割、バッファプールヒット率の継続監視
• スロークエリログ運用: long_query_time の設定、mysqldumpslow や pt-query-digest による集計、実行計画の変化追跡
• インデックス統計更新: ANALYZE TABLE の実行タイミング設計、統計情報の永続化設定（innodb_stats_persistent）の運用
• 障害時のデッドロック解析: SHOW ENGINE INNODB STATUS の読み解き、information_schema.innodb_lock_waits を用いたロック待ちの可視化、アプリ側のトランザクション設計への改善提案

面談段階で、これらの具体名詞をベンダーの技術者がどの程度自分の言葉で語れるかが、実務経験を見極める最初のフィルタになります。

マネージドDB時代の役割変化

Amazon RDS / Aurora、Google Cloud SQL、Azure Database for MySQL / PostgreSQL などのマネージド DB サービスを利用している場合、外注 DBA に依頼すべき業務範囲は大きく縮小・変質しています。次の切り分けが目安になります。

マネージド DB を採用している場合、「バックアップと冗長化はマネージドで賄えているので、外注はチューニングと監視設計に集中してほしい」という切り分けが RFP に書けるようになります。ここを曖昧にしたまま見積依頼を出すと、ベンダー側は保守的に全業務を含む前提で見積を作るため、月額単価が不必要に高くなりがちです。

DBA外注の契約形態の選び方

DBA 外注の契約形態は、大きく分けて SES（準委任契約に基づく技術者派遣型サービス）、労働者派遣、請負、フリーランス直契約（準委任）の4種類があります。それぞれの違いを、発注者にとっての「指揮命令の可否」「成果物責任」「稼働時間の柔軟性」「費用構造」の観点で整理します。

4契約形態の比較

指揮命令権のあり方が契約形態の本質的な違いです。「今すぐ本番 DB を見て」と直接指示できるのは労働者派遣のみで、SES・準委任・請負では発注者から作業者への直接指示は原則できません（詳細は後述の偽装請負の項を参照してください）。

契約形態そのものの違いをより網羅的に理解したい場合は、SES・派遣・業務委託の違いとは？発注者が知るべき調達方法の選び方もあわせてご覧ください。本記事は DBA 領域固有の判断軸に集中して解説します。

業務範囲別の推奨契約形態

DBA 業務の各領域に、どの契約形態が向いているかの目安は次のとおりです。

なお、大規模なデータベース移行プロジェクトを単発で発注する場合は請負契約が中心となりますが、こちらの詳細は本記事のスコープ外です。移行プロジェクトの契約形態については別記事PostgreSQL移行の外注で扱っています。

偽装請負にならないための指示範囲

DBA 外注では、業務の性質上、発注者が「本番 DB を今すぐ見てほしい」「このスロークエリの原因を今日中に調査してほしい」といった具体的な作業指示を直接出したくなる場面が頻繁にあります。しかし SES（準委任）・請負・フリーランス直契約では、発注者から作業者への直接指示は偽装請負に該当するリスクがあります。

厚生労働省が示す「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる37号告示）では、注文主が請負・準委任契約の下で作業者に直接指揮命令を行うことを偽装請負として整理しています（厚生労働省: 37号告示に関する疑義応答集）。

DBA 外注で偽装請負を避けるための具体的な指示ルールは次のとおりです。

• してよい指示: 契約範囲内の作業依頼をベンダー側の管理責任者（PM・SM 等）に対して行う、月次の作業計画をベンダー側に共有する、成果物の受け入れ検査を実施する
• してはいけない指示: 作業者本人に直接「今すぐこの作業をやって」と指示する、作業者の勤務時間・休憩時間を発注者側で管理する、作業者本人の業務評価を発注者側で実施する

「即応性が必要な障害対応をどうしても外部リソースに直接指示したい」という要件がある場合は、労働者派遣契約を選ぶか、SES 契約であっても「エスカレーションはベンダー側の管理責任者を経由する」フローを設計時に明文化しておく必要があります。

DBA外注（日常運用フェーズ）の費用相場と見積確認ポイント

見積書の金額が妥当かどうかは、単価だけを比較しても判断できません。稼働形態・対応時間帯・オンコール範囲などの前提条件をそろえた上で比較することが不可欠です。

なお、移行プロジェクト単発の請負見積（工数見積・成果物単位の見積構造・分割検収）については別記事PostgreSQL移行の外注で扱っていますので、そちらを参照してください。本セクションは日常運用契約の月額単価・時間単価に絞って整理します。

DBA外注（日常運用）の費用構造

日常運用の DBA 外注費用は、大きく「月額単価型」と「時間単価型」に分かれます。

• 月額単価型: 月あたりの稼働時間（例: 140時間 / 160時間）を上限に設定し、月額固定で契約する。稼働時間の変動が少ない日常運用に向く
• 時間単価型: 実稼働時間 × 単価で請求する。稼働時間の変動が大きい、または稼働時間そのものが少ないスポット依頼に向く

さらに、次の要素で費用が変動します。

• 稼働形態: 常駐 / 準常駐 / 非常駐（リモート中心）で費用が変わる。常駐が最も高く、非常駐が最も安い
• 対応時間帯: 平日日中のみ / 平日夜間含む / 24時間365日のオンコール込みで大きく変動する
• オンコール対応: オンコール月額（基本料金）+ 実出動時の時間単価、という構成が一般的
• 継続改善タスクの有無: 監視ダッシュボード整備、スロークエリ棚卸し、Runbook 整備などを月次で回すかどうかで工数が変わる

相場感の目安レンジ

DBA 外注（日常運用フェーズ）の月額単価は、スキルレベルと稼働形態でおおむね次のレンジに収まります（2026年時点の目安）。

なお、この単価はあくまで発注者向けの一次情報を集約した目安です。DB 製品（PostgreSQL / MySQL / Oracle / SQL Server）、業界（金融・医療は要求水準が高く上振れ）、地域（首都圏 / 地方）で上下します。フリーランス人材が発注者にどう見えるかについては、フリーランス側視点の記事（例: データベースエンジニアの業務委託は稼げる？）で示されている単価レンジ（月70〜100万円）と概ね整合します。

複数社から見積を取り、上記レンジから大きく外れる場合は、稼働形態・対応時間帯・オンコール範囲の前提が異なっている可能性が高いです。安すぎる見積は稼働時間の上限が低く設定されている、オンコールが対象外になっている、といった条件差が背景にあります。

日常運用の見積書で必ず確認すべき6項目

日常運用契約の見積書を受け取ったら、次の6項目を必ず明文化させてください。ここが曖昧なまま発注すると、契約後にトラブルの温床となります。

1. 対応時間帯: 平日9〜18時のみか、夜間・休日を含むか。含む場合は基本料金か時間単価加算か
2. SLA（サービスレベル合意）: 障害検知後の一次対応までの目標時間、月間ダウンタイム上限などが明文化されているか
3. オンコール範囲: どの重大度（Sev1 / Sev2 など）から出動するか、月あたりの出動回数上限、超過時の追加費用
4. 月次レポート成果物: 稼働実績、対応した障害・チューニング内容、翌月の改善提案が含まれているか。書式サンプルを事前に受領する
5. データアクセス範囲: 本番 DB への直接アクセス権の付与範囲、参照系のみか更新系まで含むか、IP 制限・監査ログの取得体制
6. 退場時の引継ぎ: 契約終了時の引継ぎドキュメント、アクセス権剥奪の手順、後任ベンダーへの引継ぎ支援の有無と費用

これらを事前に定義しておくと、複数社の見積を単価だけでなく総合的な条件で比較でき、稟議書に「A社を選定した理由」を書きやすくなります。

DBA外注先の選定基準と面談時の確認質問

見積書の条件が揃ってきたら、次はベンダーが「PostgreSQL / MySQL の日常運用ノウハウを本当に持っているか」を面談で見極めるフェーズになります。

DBA外注先を評価する5つの軸

面談・提案書レビューで確認すべき軸は次の5つです。

1. DB 製品対応範囲: 自社が利用する DB 製品（PostgreSQL / MySQL / Oracle / SQL Server / マネージド DB）を主力として扱っているか。副次的に扱っているだけの場合は障害時対応の速度が落ちる
2. 類似業界・規模の実績: 同業界・同規模のシステム（トランザクション量・データ量・可用性要件）での運用実績があるか
3. 障害時対応体制と SLA: 障害発生時の一次対応者の人数、エスカレーションフロー、過去の重大障害の RCA（根本原因分析）事例
4. セキュリティ・データアクセス統制: 情報セキュリティマネジメントシステム（ISMS）認証、SOC 2 レポート、監査ログの取得体制、退場時のアクセス権剥奪手順
5. コミュニケーション体制: 週次定例の頻度、Slack / Teams などのチャット常駐の可否、担当者交代時の引継ぎプロセス

これらを提案書と面談で確認することで、「単価は安いが実績が浅く、障害時にワンオペで対応させられる」といったリスクを事前に排除できます。

面談で聞くべき技術質問例（PostgreSQL 日常運用編）

「PostgreSQL の実務経験は5年以上あります」という自己申告だけで判断せず、次のような具体質問で経験の粒度を確認してください。

• 「autovacuum のパラメータ調整で、直近1年で対応した具体事例を教えてください。どのパラメータをどう調整し、何を根拠にしましたか」
• 「pg_stat_statements で発見した高負荷クエリの改善事例を1つ、EXPLAIN ANALYZE の実行計画の変化と合わせて説明してください」
• 「REINDEX CONCURRENTLY を本番環境で実施した経験はありますか。実施時にどのようなリスクを想定し、どう回避しましたか」
• 「大規模テーブルの VACUUM FULL が必要になったとき、どのような判断基準でオンライン整理と使い分けましたか」

正解を求めるのではなく、自分の言葉で状況・判断・結果を語れるかを見極めるための質問です。曖昧な回答や、教科書的な一般論しか返せない場合は、実務経験が浅い可能性が高いと判断できます。

面談で聞くべき技術質問例（MySQL 日常運用編）

MySQL の場合は次のような質問が有効です。

• 「InnoDB バッファプールのヒット率が低下した際、どのメトリクスから調査を始め、どうチューニングを進めますか」
• 「本番でデッドロックが多発した場合、SHOW ENGINE INNODB STATUS の出力からどう原因を特定しますか。過去の対応事例があれば教えてください」
• 「long_query_time の初期設定値をどう決めますか。設定後に見えてくるスロークエリの傾向から、どのように改善優先度をつけますか」
• 「MySQL 5.7 から 8.0 へのバージョンアップを計画する場合、事前検証で最低限確認する項目を挙げてください」

DB 製品ごとに深く踏み込んだ質問を用意しておくことで、複数の DB を扱えると自己申告するベンダーの実質的な得意領域を判別できます。

セキュリティ・データアクセス統制の確認観点

DBA 外注では本番データベースへのアクセス権を委譲することが多く、セキュリティ統制の確認は避けて通れません。次の観点を面談・契約書で確認してください。

• アクセス権付与の手続き: どのアカウントで誰に付与するか、参照系と更新系の分離、緊急時のみ有効化する一時アカウントの運用可否
• 監査ログ: 誰がいつどの SQL を実行したかを追跡できる体制。DB 側の監査ログ（PostgreSQL の pgaudit、MySQL の Audit Plugin など）に対応可能か
• 退場時のアクセス権剥奪: 契約終了時にアクセス権を漏れなく剥奪する手順が定型化されているか。退場チェックリストを提示してもらう
• 端末・ネットワーク統制: ベンダー側の作業端末のセキュリティ基準、VPN / IP 制限による接続制限、多要素認証の必須化

DBA外注（日常運用契約）の発注前・運用中・契約終了時チェックリスト

発注方針が固まったら、実行フェーズごとに具体的なチェックリストを持っておくことで、稟議承認後の実行段階で漏れや事故を防げます。

なお、大規模移行プロジェクト固有のチェック項目（切り戻し設計・データ整合性検証・移行完了検収基準）は本記事のスコープ外です。移行プロジェクトの発注仕様書7項目についてはPostgreSQL移行の外注で解説しているため、そちらをご参照ください。

発注前準備

契約書に押印する前に完了させておくべき項目です。

• RFP（提案依頼書）の作成: 目的・現状課題・業務範囲（必須／オプション／対象外）・稼働形態・対応時間帯・SLA 目標を明文化する
• NDA（秘密保持契約）の締結: 提案検討段階で自社の DB スキーマや障害履歴を開示する前に締結する
• データアクセス範囲の定義: 本番 / ステージング / 開発の各環境でのアクセス権範囲、参照系と更新系の分離、監査ログ要件
• SLA の合意: 障害検知後の一次対応目標時間、月間ダウンタイム上限、月次レポートの提出タイミング
• 契約形態の稟議承認: SES（準委任）／派遣／請負のいずれで契約するかを法務・情シスと合意した上で稟議に上げる
• 緊急時連絡体制の合意: オンコール時の連絡先、エスカレーションフロー、代理担当者の設定

運用中の管理

契約開始後、月次で継続的に管理すべき項目です。

• 週次定例の開催: 稼働時間の消化状況、対応中のインシデント、改善提案の進捗を週次で確認する
• 障害対応記録の管理: 発生日時・原因・対応内容・再発防止策を都度記録し、月次でレビューする
• ナレッジ蓄積: ベンダーが対応した内容を Runbook や運用ハンドブックに継続的に反映してもらう
• 月次レポートの受領: 稼働実績、対応した障害・チューニング、翌月の改善提案が含まれたレポートを毎月末に受領する
• 稼働時間の可視化: 契約上の稼働時間上限に対する消化率を月中でモニタリングし、超過見込みの場合は事前に契約変更を協議する
• 指揮命令の適切性チェック: SES・準委任契約の場合、発注者側から作業者への直接指示が発生していないか、四半期ごとにセルフチェックする

契約終了時の引継ぎ・退場管理

契約終了時に発生しやすい事故（アクセス権残置、運用ドキュメント欠落）を防ぐための項目です。

• アクセス権の剥奪: DB アカウント、SSH 鍵、VPN アカウント、社内システムアカウントを漏れなく削除する。退場チェックリストを作成し、責任者が確認する
• 運用ドキュメントの受領: Runbook、対応履歴、監視設計書、パラメータ設定書、直近3ヶ月の月次レポートを納品物として受領する
• 後任への引継ぎ: 内製化する場合は社内担当者への引継ぎセッションを実施する。後任ベンダーへ切り替える場合は並行稼働期間を1〜2ヶ月確保する
• 貸与物の返却: ベンダー側に貸与した端末、ドキュメント、機密情報のコピーの返却または廃棄を確認する
• 契約終了通知の書面化: 口頭ではなく書面で終了通知を交わし、双方の合意記録を残す

このチェックリストをそのまま社内の運用マニュアルに転記しておくと、発注担当者の交代時にもナレッジが引き継がれ、次回の外注検討がスムーズになります。

まとめと次のアクション

DBA 外注の判断は、次の4軸を掛け合わせて設計することで、ブラックボックス感を解消できます。

• 業務範囲: 日常運用の7業務のうち、必須・オプション・対象外を切り分ける。マネージド DB を使っている場合は自動化されている領域を除外する
• 契約形態: SES（準委任）・派遣・請負・フリーランス直契約のいずれかを、指揮命令の必要性と成果物責任の観点で選ぶ
• 費用相場: 月額単価型か時間単価型か、稼働形態と対応時間帯を揃えた上で複数社の見積を比較する。目安レンジから大きく外れる場合は前提条件を確認する
• 発注チェック: 発注前（RFP・NDA・SLA 合意）／運用中（週次定例・月次レポート・稼働時間モニタリング）／契約終了時（アクセス権剥奪・ドキュメント受領）の3フェーズでチェックリストを持つ

稟議書に落とす際は、この4軸をそのまま章立てにし、「外注が最適解である理由（採用・内製との比較）」→「必要な業務範囲」→「推奨契約形態と理由」→「費用試算（複数社比較）」→「発注後の管理体制」の順で構成すると、意思決定者にとって判断しやすい形になります。

まずは1〜2社に無料相談を依頼し、RFP のドラフトを見せてフィードバックをもらうところから始めるのが現実的です。ベンダーとの初回対話の中で、自社が言語化できていなかった前提条件（マネージド DB 前提の業務切り分け、オンコール範囲の妥当性など）に気づくことも多く、社内の議論が前に進みやすくなります。

なお、日常運用ではなくデータベース移行プロジェクトの外注検討が主目的の場合は、別記事PostgreSQL移行の外注で発注仕様書7項目・切り戻し設計・データ整合性検証・移行完了検収基準を扱っていますので、そちらもあわせてご覧ください。