データベースエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

データベースエンジニアのスキルシートは、扱った製品の名前を並べるより、製品と版・データの規模・可用性の構成を1行で要約し、設計・性能改善・移行・運用のどれを担ったか、何を直し何を戻したかを書くのが基本です。読み手は、同じ「Oracle、PostgreSQL」という並びからでも、方式を決めた人なのか、決まった環境を運用していた人なのかを知りたいからです。

この記事では、データベースエンジニアならではの書き方の要点と、架空の記入例を紹介します。スキルシート全体の基本の構成はスキルシートの書き方の基本、案件で求められるスキルの中身はデータベースエンジニアの案件で求められるスキルで扱っています。

製品名の羅列では伝わらないこと

データベースエンジニアのスキルシートでよく見るのが、使用技術の欄に製品名とツール名を長く並べる書き方です。しかし、一覧からは次のことが読み取れません。

• その製品で、設計をしたのか、性能を直したのか、定型の作業をしていたのか
• どれくらいの規模で、どれくらい止められない環境だったのか
• 障害のときに、自分で原因を調べて戻したのか、報告して他の人に任せたのか

データベースの案件の読み手は、インフラや開発の経験がある担当者であることが多く、一覧の長さより、構成と役割の説明を見ています。

スキル一覧は「製品・版・深さ」をそろえる

スキル一覧では、製品ごとに版と関わりの深さを添えると、読み手は合う案件かどうかを判断できます。

これは書き方を示すための例です。版を書く理由は、サポート期限と移行の経験が読み取れるからです。たとえばPostgreSQLは各メジャー版を5年間サポートする方針のため、どの版からどの版へ上げたかを書くと、移行の経験がそのまま伝わります。「利用のみ」「運用」のように、浅い関わりもそのとおりに書いておけば、面談で深く聞かれる範囲を自分で示せます。

プロジェクト欄の冒頭に「DBの要約」を置く

プロジェクト欄では、案件概要の次に、データベースの構成を1行で要約すると、読み手が全体像をつかみやすくなります。要約に入れたいのは次の4点です。

1. 製品と版：どの製品の、どの版か
2. 規模の目安：「数百GB規模」「表の数は数百」など、伏せられる範囲でぼかす
3. 可用性の構成：単体か、レプリケーションか、クラスタか
4. 止められる時間の厳しさ：「24時間稼働」「夜間に停止の時間帯あり」など

社名やシステム名は書かず、業種と構成の特徴で書きます。どこまで書いてよいかはスキルシートに書いてよいこと・いけないことをご覧ください。

工程ごとに「何をしたか」を書き分ける

性能改善は、改善の数字を書けない場合も多くあります。その場合は「業務開始前に終わるようになった」「画面の待ち時間への問い合わせがなくなった」のように、業務への影響で書けば十分です。守秘義務の範囲を超える数字は書かないようにしましょう。

SQLの経験は「何に使ったか」で書く

「SQL：5年」のような書き方では、データを取り出す程度なのか、遅いSQLを直せるのかが分かりません。SQLの経験は、使い道で分けて書くと深さが伝わります。

• 抽出・集計：調査や報告のためのデータの取り出し
• 開発：業務の処理を担うSQLやストアドプロシージャの作成
• レビュー・改善：他の人が書いたSQLの見直し、実行計画を見た書き換え

どれか一つでも、自分が主に担った使い道を書いておけば、読み手は開発支援の案件か性能改善の案件かを判断しやすくなります。

「戻した経験」は独立した1行にする

バックアップからの復旧や、障害時の切り替えの経験は、データベースの案件でもっとも確かめられる経験の一つです。訓練でも本番でも、実施したことがあれば独立した1行で書きます。「復旧訓練を計画し、見つかった手順書の不足を直した」のように、何を改善したかまで書けると伝わりやすくなります。

架空の記入例

以下は書き方を示すための架空の例です。実在の案件・企業とは関係ありません。

案件概要：小売業の受発注システムの基盤更改（期間：約1年、体制：基盤チーム5名のうち1名）

DBの要約：PostgreSQL（オンプレミス、版上げ前は11）。数百GB規模、レプリケーションで2台構成。夜間に短い停止の時間帯あり。

担当工程：移行計画、性能改善、運用設計

実施したこと

• サポート期限を過ぎた版からの版上げについて、互換性の確認項目を洗い出し、検証環境で事前に試した
• 切り替え当日の手順と、失敗時に元の環境へ戻す手順・判断の基準を作り、当日の作業を担当した
• 版上げ後に遅くなった検索について、実行計画を比べ、統計情報の取り直しとインデックスの見直しで解消した
• バックアップと復旧の手順を見直し、復旧訓練を実施した

使用技術：PostgreSQL、Linux、シェルスクリプト、監視ツール

工夫したこと：切り替えの前に、戻す判断をする時刻と確認項目を関係者と決めておき、当日の判断を迷わないようにした

認定資格の書き方

資格は、正式名称と取得年月を書きます。ORACLE MASTERのように対応する製品の版がある資格は、どの版に対応した資格かも添えましょう。資格ごとの評価のされ方と書き方はORACLE MASTERの記事とデータベーススペシャリスト試験の記事で詳しく解説しています。

よくある質問

規模の数字を書けない場合はどうすればよいですか？

「数百GB規模」「表の数は数百」「24時間稼働」のように、幅を持たせた言い方や、止められる時間の厳しさで書けば十分です。取引先との約束で書けない場合は、無理に書かず、面談で話せる範囲を口頭で伝えましょう。

運用保守だけの経験はどう書けばよいですか？

監視、バックアップの確認、定型の変更作業を一行にまとめず、障害の一次対応、原因の切り分け、手順書の改善など、自分で判断した場面を分けて書きます。運用の中で改善したことがあれば、それが一番の材料になります。

データ分析基盤の経験はデータベースエンジニアのスキルシートに書いてよいですか？

書いてかまいません。ただし業務システムのデータベースの運用とは求められることが違うため、項目を分けて書くと読み手が混乱しません。データ基盤の経験の書き方はデータエンジニアのスキルシートの記事も参考になります。