データベースエンジニアのフリーランス案件で求められるスキルと経験
公開 2026-10-29 監修:株式会社エージェントベスト
データベースエンジニアのフリーランス案件で求められるのは、データの持ち方を決める設計、遅いSQLの原因を突き止める力、決めた時点までデータを戻せるバックアップと復旧、止まらない構成の知識、版上げや製品の移行を計画する力です。クラウドの案件では、これにマネージドサービスの仕組みと費用の理解が加わります。
案件で深く問われるのは、扱った製品の数より、本番のデータベースで何を判断し、何を直したかです。この記事では、分野ごとのスキルと、経験の段階ごとに求められる水準を整理します。報酬との関係はデータベースエンジニアの報酬の記事で扱っています。
案件で見られるスキルの全体像
| 分野 | 主な中身 | 求められやすい案件 |
|---|---|---|
| 設計 | 論理設計(正規化、キー)、物理設計(インデックス、パーティション、容量) | 新規構築、再構築 |
| SQLと性能 | SQLの読み書き、実行計画、待機やロックの分析、統計情報 | 性能改善、開発支援 |
| バックアップと復旧 | 方式の設計、復旧手順、復旧時間の見積もり、訓練 | 運用設計、基盤の更改 |
| 可用性 | レプリケーション、クラスタ構成、切り替えの手順 | 基幹システム、24時間動くサービス |
| 移行・版上げ | 互換性の確認、データの移し方、切り替えと戻し方の計画 | サポート期限を機にした更改 |
| クラウドのマネージドDB | インスタンスの選定、パラメータ、メンテナンス、費用 | クラウド移行、Webサービス |
| セキュリティと権限 | ユーザーと権限の設計、監査ログ、暗号化 | 金融、公共、個人情報を扱う業界 |
設計:後から直しにくい判断を任せられるか
論理設計では、業務の言葉を聞き取ってエンティティと関係に整理し、正規化をどこまで進めるかを決めます。物理設計では、アクセスの多い検索に合わせたインデックス、データ量の伸びに合わせた領域の見積もり、大きな表を分けるパーティションの方針を決めます。
設計の案件で問われるのは、正しい答えを知っていることより、あえて崩した箇所とその理由を説明できることです。たとえば性能のために一部を非正規化した場合、更新時の不整合をどう防いだかまで話せると、設計を任せられる人として受け止められます。設計の考え方を体系的に確かめたい人は、データベーススペシャリスト試験の記事も参考になります。
SQLと性能:原因を突き止める順序を持っているか
性能改善の案件では、「遅い」という訴えから原因を絞り込む順序が問われます。
- 遅いのは特定のSQLか、データベース全体か、時間帯によるかを切り分ける
- 対象のSQLの実行計画を取り、想定と違う読み方(全件の読み込み、結合の順序など)をしていないかを見る
- 待機の種類やロックの競合を確かめ、ほかの処理との取り合いがないかを調べる
- 統計情報の古さ、インデックスの有無、SQLの書き方、パラメータのどこを直すかを決める
- 直した後に、ほかのSQLが遅くなっていないかを確かめる
製品ごとに見る画面やビューは違いますが、この順序は共通です。面談では、5番目の「副作用の確認」まで話せるかどうかで、経験の深さが伝わります。
バックアップと復旧:戻した経験があるか
バックアップは取っているだけでは意味がなく、決めた時点までの復旧が決めた時間内にできることが大切です。案件では次のような点が問われます。
- どの時点まで戻せればよいか(失ってよいデータの量)と、どれだけの時間で戻すか(止まってよい時間)を業務側と決めた経験
- フルバックアップと差分・ログの組み合わせで、任意の時点まで戻す手順を理解しているか
- 復旧の訓練を実施し、手順書を直した経験
可用性:切り替えの手順まで説明できるか
レプリケーションやクラスタの構成は、組んだことがあるだけでなく、障害時にどう切り替わり、戻すときにどうするかまで理解しているかが見られます。同期と非同期のどちらを選んだか、切り替えの判断を自動にしたか人が行うかといった選択には、それぞれ失うものがあります。その理由を説明できることが、設計に関わる案件への入口になります。
移行・版上げ:期限から逆算して計画できるか
データベースの版にはサポートの期限があり、期限を機に移行の案件が生まれます。PostgreSQLは各メジャー版を5年間サポートする方針で、MySQLは8.0のコミュニティ版のサポートが2026年4月に終わり、Amazon RDS for MySQL 8.0も2026年7月末で標準サポートを終えて有料のExtended Supportに移っています(2026年10月時点の各公式ページ)。移行の案件では、互換性の確認、データの移し方、切り替えの当日の手順、失敗したときの戻し方を一続きで計画できる人が求められます。
クラウドのマネージドDB:任せる部分と自分で持つ部分
マネージドサービスでは、OSのパッチやバックアップの取得の多くをクラウド側が担います。一方で、インスタンスの大きさ、パラメータ、メンテナンスの時期、版上げの計画、費用は利用者側の判断です。Amazon RDSでは、標準サポートを過ぎた版を使い続けると有料のExtended Supportに登録され、それも最長3年で終わると自動で版上げされる仕組みになっています。こうした仕組みを踏まえて、版上げの時期を費用とあわせて提案できる人は評価されやすくなります。クラウド全般のスキルはAWSエンジニアのスキルの記事も参考になります。
経験の段階ごとに求められる水準
| 段階 | 求められること | 参画しやすい案件 |
|---|---|---|
| SQLと定型運用が中心 | SQLを正確に書ける、手順書どおりにバックアップや変更作業ができる、異常に気づいて報告できる | 運用保守、開発支援 |
| 性能改善や障害対応を担った | 実行計画を読んで原因を特定できる、復旧を実施できる、作業の手順と戻し方を書ける | 性能改善、版上げの実作業、運用改善 |
| 設計や移行を任された | 方式を比べて決め、理由を説明できる、移行全体を計画できる、利用者側と停止時間を調整した経験がある | 新規構築、移行の計画、方式設計のレビュー |
資格は、段階を一つ上げるときの知識の整理に役立ちます。Oracle Databaseの管理の範囲を体系的に確かめるならORACLE MASTERの記事をご覧ください。
隣の職種との境目
データベースエンジニアとデータエンジニアは、どちらもSQLを使いますが、仕事の中心が違います。データベースエンジニアは業務システムのデータベースを止めずに動かし、速く保つことが中心です。データエンジニアは、分析のためにデータを集めて加工する流れを作ることが中心です。運用の信頼性を仕組みで高める考え方はSREのスキルの記事も参考になります。
よくある質問
使ったことのない製品の案件にも応募できますか?
設計、性能の考え方、バックアップと復旧の原則は製品が違っても共通です。参画の条件が「いずれかの製品で経験があること」となっている案件もあります。応募の前に、検証環境で対象の製品の基本操作と管理の作法を確かめておくと、面談で説明しやすくなります。
クラウドのマネージドDBの経験しかなくても大丈夫ですか?
クラウドの案件では、マネージドサービスの経験がそのまま評価されます。ただ、OSやストレージに近い部分をクラウド側が担っているため、オンプレミスの案件ではその部分の知識を問われることがあります。応募する案件の環境に合わせて、足りない部分を補っておきましょう。
資格がないとデータベースの案件には入れませんか?
多くの案件は資格を条件にしておらず、実務の経験で判断されます。資格は、知識を体系的に持っている裏づけや、未経験の領域に挑戦するときの説明材料として役立ちます。資格ごとの評価のされ方はORACLE MASTERの記事とデータベーススペシャリスト試験の記事で解説しています。
参考にした公的情報・資料
- Amazon RDS Extended Support with Amazon RDS(Amazon Web Services)
- MySQL on Amazon RDS versions(Amazon Web Services)
- Versioning Policy(PostgreSQL Global Development Group)
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。