データベースエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのデータベースエンジニアの仕事は、データを失わず、止めず、速く保つための判断と作業です。ただし、案件が運用保守なのか、性能改善なのか、移行や版上げなのか、新しく設計して作るのかで、1日の過ごし方も、向き合う相手も、手元に残る成果物も大きく変わります。

この記事では、データベースの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはデータベースエンジニアのスキルの記事、報酬の決まり方は報酬の記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「案件の目的」と「本番との距離」で決まる

データベースの案件は、募集の名前が同じ「DBエンジニア」でも、働き方がまったく違うことがあります。違いを生むのは主に次の2つです。

• 案件の目的：今あるデータベースを安定して動かすのか、遅さを直すのか、別の版や製品へ移すのか、新しく作るのか
• 本番との距離：本番のデータベースを自分で操作するのか、手順書やスクリプトを渡して別の担当者に実行してもらうのか

この2つの組み合わせで、フリーランスのデータベース案件はおおむね次の4種類に分けられます。

1つの案件で複数の種類にまたがることもあります。たとえば運用保守として入り、途中から版上げの計画を任されるような流れです。以下の1日・1か月の流れは典型的な例なので、目安として読んでください。

運用保守の案件の仕事

1日の流れ（例）

朝は、夜間のバッチやバックアップが正常に終わったかを確かめ、監視の通知を振り返ります。午前は、開発チームから来たテーブル追加や権限変更の依頼を受け、作業の手順を書き、レビューを受けます。午後は承認された変更を検証環境で試し、決められた時間帯に本番へ反映します。夕方は、領域の使用量やセッション数の推移を見て、近いうちに手を打つべきことがないかを確かめます。

運用保守では、決められた手順で正確に作業することと、いつもと違う兆しに早く気づくことの両方が求められます。

1か月の流れ（例）

• 毎日：バックアップと夜間処理の結果確認、監視の通知の確認、依頼への対応
• 毎週：変更作業の計画と実施、運用チームとの定例で課題を共有する
• 月に1回程度：容量や性能の推移をまとめて報告する。パッチの適用や統計情報の見直しなど、まとまった保守作業を計画する
• 随時：障害の一次調査と報告、復旧の手順の実行

成果物

作業手順書、変更の記録、障害の報告書、月次の稼働報告、容量や性能の推移の資料、運用手順書の改訂などです。夜間や休日の呼び出しがある案件では、対応の記録も成果物に含まれます。呼び出しの範囲は案件によって大きく違うため、参画前に確かめておくことが大切です。

性能改善の案件の仕事

1日の流れ（例）

午前は、業務部門や開発チームから「どの画面・どのバッチが、いつ遅いか」を聞き取り、対象を絞ります。そのうえで、遅いSQLの実行計画、待機の種類、ロックの競合などを調べます。午後は、インデックスの追加、SQLの書き換え、統計情報の取り直し、パラメータの変更といった改善の案を検証環境で試し、効果と副作用を確かめます。夕方は、結果を短い資料にまとめ、開発チームと次に何を試すかを決めます。

性能改善の案件では、原因を絞り込む順序と、直したことで別の処理が遅くならないかの確認に時間を使います。手を動かす時間より、調べて比べる時間のほうが長くなることも少なくありません。

1か月の流れ（例）

• 最初の1〜2週：遅い処理の一覧を作り、業務への影響の大きい順に並べる。計測の方法をそろえる
• 中盤：上位の処理から原因を調べ、改善案を検証環境で試す
• 後半：本番への反映の計画を立て、反映後の数値を確かめる
• 月末：改善の前後の数値と、残っている課題を報告する

成果物

遅い処理の一覧と優先順位、原因の分析資料、改善案と検証の結果、本番反映の手順、改善前後の比較の報告などです。開発チームが同じ問題を繰り返さないよう、SQLの書き方の指針をまとめることもあります。

移行・版上げの案件の仕事

データベースの版にはサポートの期限があり、期限を機に移行の仕事が生まれます。たとえばPostgreSQLは各メジャー版を最初のリリースから5年間サポートする方針で、PostgreSQL 14は2026年11月に最後のリリースを迎える予定です（2026年10月時点の公式ページ）。Amazon RDSでは、標準サポートを過ぎた版を使い続けると有料のExtended Supportに移り、それも最長3年で終わると自動で版上げされる仕組みです。期限の全体像はデータベースエンジニアの将来性の記事で整理しています。

1日・1か月の流れ（例）

前半は調査の期間です。今の版で使っている機能、アプリが発行しているSQL、ストアドプロシージャやトリガー、文字コード、外部とのデータ連携などを洗い出し、移行先で動きが変わる箇所を一覧にします。アプリの開発チームと、修正が必要な箇所と担当を決めます。

中盤は、移行の手順を作り、検証環境でリハーサルを繰り返します。データの移し方、かかる時間、停止できる時間に収まるかを確かめ、失敗したときにどこまで戻すかの手順も作ります。

後半は切り替えの準備です。当日の作業の時間割、関係者の連絡の流れ、切り替えを中止する判断の基準を決めます。切り替えは夜間や休日になることが多く、その前後は稼働が増えやすくなります。

成果物

現状調査の結果、互換性の確認一覧、移行の方式の比較、移行手順書、リハーサルの記録、切り替え当日の作業計画と中止の基準、戻しの手順、切り替え後の確認結果などです。

設計・構築の案件の仕事

1日・1か月の流れ（例）

新しいシステムや再構築のプロジェクトで、データベースの部分を担う案件です。前半は、業務の担当者やアプリの開発チームから要件を聞き、テーブルの構成、キー、インデックスの方針を決めていきます。並行して、データ量の伸び、止まってよい時間、失ってよいデータの量を確かめ、構成（冗長化の方式、バックアップの方式、クラウドならサービスとインスタンスの大きさ）を決めます。

後半は構築と試験です。パラメータの設定、ユーザーと権限の作成、バックアップと監視の設定を行い、障害を想定した切り替えや復旧の試験をします。クラウドのマネージドDBでは、構築の多くをコードで行うこともあります。

成果物

テーブル定義書、ER図、物理設計書（インデックス、領域、パーティション）、方式設計書（冗長化、バックアップ、監視）、パラメータの一覧、構築手順書、試験の計画と結果、運用への引き継ぎ資料などです。設計の案件では、なぜその方式を選んだかを残しておくことが、後で運用する人の助けになります。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのデータベース案件にあります。

1. 手順書を書いてから操作する：本番に触れる作業は、手順と戻し方を先に書き、レビューを受けてから行う
2. 作業の記録を残す：いつ、誰の承認で、何をしたかを残す。後から原因を調べるときの手がかりになる
3. 影響を先に伝える：停止や遅くなる時間が出る作業は、業務側に前もって知らせる
4. 権限の範囲を守る：本番のデータに触れる権限は必要な範囲だけにし、取引先の承認の流れに沿って使う

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。夜間の作業や呼び出しへの対応をどう精算するかは案件によって違うため、日々の稼働をつけておくと、月末の報告と精算がしやすくなります。

関わる相手と、その相手に出すもの

データベースエンジニアの1日は、誰に何を渡すかで組み立てられています。

働く場所については、設計やSQLのレビュー、クラウドのマネージドDBの作業はリモートで進めやすい一方、閉域網の中の本番に触れる作業や切り替え当日は出社や指定端末になりやすい傾向があります。詳しくはデータベースエンジニアのリモート案件の記事をご覧ください。分析用のデータの流れを作る仕事はデータエンジニアの仕事内容、クラウド基盤全体の仕事はAWSエンジニアの仕事内容が近い内容です。

よくある質問

運用保守の案件でも、設計や改善の経験は積めますか？

案件によります。定型作業が中心で改善の提案を求められない案件もあれば、運用の中で気づいた問題を改善まで任される案件もあります。経験を広げたい場合は、応募の段階で「改善の提案や実施を担う余地があるか」を聞いておくと判断しやすくなります。

夜間や休日の作業はどのくらいありますか？

運用保守の呼び出しや、移行の切り替え、まとまった保守作業は、業務への影響が少ない夜間や休日に行われやすい傾向があります。頻度は案件ごとに大きく違うため、参画前に作業時間帯と精算の扱いを確かめましょう。確認の観点はデータベースエンジニアの案件の選び方で整理しています。

参画して最初の1か月は何をすることが多いですか？

構成とバックアップの方式の把握、運用手順書と変更の流れの確認、権限の申請、監視の見方の習得から始めるのが一般的です。初月の進め方はデータベースエンジニアの参画初月にやることで詳しく解説します。