DBエンジニアに求められるスキルの“理想と現実”

第1回経験年数と所属組織はどのようにスキルの差に影響してくるか?

DBエンジニアの皆さん、自分のスキルに自信がありますか?「自分の強みと弱みを知っている」と言えますか?

確信をもって「大丈夫」と言える人はほとんどいないでしょう。筆者も長い間、さまざまな人の相談にのってきましたが、スキルの悩みは永遠のテーマと言えます。

そもそも⁠DBエンジニア⁠といっても、

  • プロジェクトのDB担当(アプリ、基盤)
  • DBコンサル
  • DBの運用担当
  • サポート系

など、さまざまな職種があります。おのおの得意不得意があるのは当然です。

そこで、経験年数、所属組織、職種、所属企業の種類(エンドユーザ側か、SI子会社か、派遣か、など)といったデータも取るように調査してみました。

対象としたスキルと定義

今回どのようなスキルを対象としたか、項目と定義をまとめたのが表1です。レベル1が初心者、3がほぼ一人前、5がエキスパートや指導者という感じです。

ITの項目が多くを占めますが、コミュニケーションやドキュメンテーションといったビジネススキルもあります。Oracleの用語が一部入っていますが、多くは他社DBMS製品でも同様に読み替えることができます。

表1 スキル項目と定義

[コード:A]DBMSアーキテクチャ

レベル定義
1入門書をマスターしたレベル
※Oracle Master Bronze取得相当のレベル
2サーバープロセスとクライアントの役割分担が説明できる
※Oracle Master Silver取得相当のレベル
3ブロックやエクステント、オブジェクトの構造を説明できる。SQLにおけるOracleの動きを説明できる(正常系⁠
※Oracle Master Gold取得相当のレベル
4RACの構造や動きの説明も実施できる。障害時の動きを説明できる。
※Oracle Master Platinum取得相当のレベル
5Oracleの内部構造と動きを一通り説明できる。未知の動きについてもアーキテクチャの観点から考察と推論を行える。アーキテクチャにおいて業界でも上位のエンジニア
[コード:B]物理設計ノウハウ
主要な業務:データベース物理設計
レベル定義
1初心者。手とり足とり、指示してもらって設計ができるレベル
2ガイドラインに従って設計のドラフトを作ることができる。上席の支援が必須
3設計のドラフトを作成することはできるが、上席のレビュー必須
4パラメータ間のバランスや影響なども指摘できる
5極めて性能要件が高いシステムでも物理設計/対障害設計を実施できる(監督できる)
6日本初のようなシステムについても妥当な設計とレビューを行える
[コード:C]オペレーション(オブジェクト操作、DB操作)
主要な業務:アプリリリースや移行業務、日常メンテナンス業務
レベル定義
1書かれているオペレーションを実施するのみ
2簡単なオペレーションの変更のみ実施可能。レビューは不可
3普段使用している機能やオブジェクトに関しては手順書を自分で作成できる
4新機能に関しても調査しながら手順書を自分で作成できる。他人の手順書をレビューできる
5オブジェクトや運用オペレーションの方針を立てられる
6
[コード:D]SQLチューニング(分析含む)
主要な業務:性能テスト、性能改善、ボトルネックの分析(インスタンスチューニングを除く)
レベル定義
1インデックススキャンとフルスキャンの違いが理解できる
2トレースが理解できる。インデックスを追加して、フルスキャンをインデックスに変更する程度
3結合方法について理解し、チューニングを実施することができる
4View(マージやプッシュなど)が絡むような多少難易度の高いチューニングも実施できる
5高度な問題のチューニング(例:DBリンクが絡み、性能の最適化が困難となっているようなSQLのチューニング)も実施できる
6
[コード:E]インスタンスチューニング(分析含む)
主要な業務:性能テスト、性能改善、ボトルネックの分析(SQLチューニングを除く)
レベル定義
1初心者。基本的な考え方を知っている
2どの待機イベントが多いかを区別できる。主だった数種類の待機イベント(log file sync,db file sequential read等)について内容を説明できる
3Statspackなどから原因を特定できる。v$sessionやEM(Enterprise Manager)で概況を把握できる
4Oracle以外かどうかの切り分けも実施できる
5原因だけではなく、対策に関してもほぼ全てのケースで提示できる
6事象が日本初のような難易度の高いインスタンスチューニングについても仮説・検証を基に解決できる
[コード:F]インシデント対応、トラブル切り分け、サポート問い合わせ
主要な業務:障害対応、技術質問対応
レベル定義
1上席が書いた問い合わせをサポートに送る程度
2KROWNから簡単な調査を実施できる。基本的な技術質問をサポートに依頼できる
3KROWNから類似の事象を探して、原因を類推できる。既知のトラブルであれば、対策をリードできる。v$sessionやEM(Enterprise Manager)で概況を把握できる
4性能トラブルを一人で切り分け/シューティングできる
5原因不明のトラブルであっても解決への道筋をひき、進めることができる
6日本初のような複雑度の高いトラブルについても切り分けと対応を実施できる
[コード:G]ヘルスチェック、健全確認(傾向分析含む)
主要な業務:定期分析、定常監視、アプリリリース後の分析(確認)
レベル定義
1初心者。基本的な考え方を知っている
2EM(Enterprise Manager)やStatspackを使って、簡単な確認を実施できる(Top5待機イベントなど)
3安定稼働のために行うべき基本的なことを知っている。既存のシステムのリリースであれば健全確認が実施できる
4キャパシティプランニングが実施できる。傾向分析で目立つ問題点を見つけ、対策を立案できる
5新規業務のリリースであっても、健全確認が実施できる
6隠れたトラブルの芽やボトルネックの存在を豊富な経験を基に指摘できる(全てとは限らない)
[コード:H]バックアップ&リカバリ(設計やオペレーションを含む)
主要な業務:バックアップリカバリの設計・設定、リカバリの実施
レベル定義
1初心者。基本的な考え方を知っている
2考え方は知っており、上席者の手伝いができる
3手順に従ってオペレーションができる。基本的な動きを知っている
4バックアップリカバリを一人で実施できる。ガイドに従って、バックアップリカバリの設計ができる
5バックアップリカバリの設計や実施を監督できる
6想定していない物理障害に対して、最適なリカバリをその場で組み立てて実施できる
[コード:I]構成管理(PSR、パッチ)
主要な業務:パッチ当ての判断、パッチ当て実施
レベル定義
1初心者。基本的な考え方を知っている
2手順書に基づいてパッチ当てを実施する程度
3個別パッチをダウンロードして、パッチ当てを実施できる
4メリットデメリットを理解でき、個別パッチについての適用判断(する/しない)ができる
5PSR(構成)に関する方針(会社の標準構成や今後の適用計画)が立てられる
6
[コード:J]セキュリティ
主要な業務:セキュリティ設計・設定、監査の設計や設定
レベル定義
1初心者。基本的な考え方を知っている
2最低限必要なセキュリティの設定を知っている
3マニュアルに記載されている推奨設定等から監査等を設定できる
4新規システムに対して、一通りのセキュリティ設定を一人で実施できる
5システム全体の総合的な観点で、DBのセキュリティを設計・監督できる
6セキュリティにおいて業界でも上位のエンジニア
[コード:K]インフラスキル
主要な業務:インフラ構築の常識(構築の流れや分担、DBチームが行うべきこと)に関する知識。OSやストレージ、ネットワークに関する知識
レベル定義
1初心者。基本的な役割分担を知っている程度
2"マニュアルに沿っただけのインストールと設定に必要なOS/ストレージ/ネットワークの知識を保持している。既存システムのデザインシートをベースに、標準的な構成のDBを構築できる。上席者によるレビューは必要
3単独でシステムの環境構築が行える。OS/ストレージ/ネットワークについて日常業務で必要となるコマンドは知っている
4新バージョンのOSや新シリーズの機器を導入できる。機器の選定や、顧客要件を満たすための提案が行える
5例のないシステム要件について、採用する技術の選定から実際の構築までを行える
6インフラにおいて業界でも上位のエンジニア。未知のトラブルについても切り分けや対応が実施できる
[コード:L]SQL作成スキル
主要な業務:開発者としてSQLを作成するスキル(構文、SQLのファンクション、副問い合わせ、ヒント文など)
レベル定義
1初心者。基本的なSQL文(whereに=や!=などを使ったもの)が作成できる
2有効なインデックスを意識しながらSQL文を作成できる
3OLTPアプリケーションにおいて実行されるほとんどのSQL文について記述できる(レベル4に見られるような分析関数などは含まない)
4簡単なヒント文の付与や分析関数など、SQL文としてより良く機能させる方法を知っている
5バッチ処理全体として最適となるようSQL文群全体をデザインしたり、DBリンクを意識して、性能が最適となるようSQL文をデザインできるレベル
6DBMSの構造とSQLの構文の双方を極めた高度なSQLを作成できる
[コード:M]コミュニケーション(説明とネゴシエーション)
主要な業務:業務遂行のために必要な、主に他チームに対する説明とネゴシエーションの能力
レベル定義
1技術的であり、かつ、簡単な説明であれば実施できる
2説明については、独力で実施できることが多い
3お互いの利害が大きく異ならないような調整事項であれば、独力で実施できる。日常業務の説明や調整は独力で実施できる
4障害対応などの日常業務を越える調整が実施できる
5困難な調整(他チームにとって、多くの工数を必要とするような調整等)や、複数の部門が関わるような調整を実施できる
6非常に高いリーダーシップとコミュニケーション能力を発揮できる
[コード:N]ドキュメンテーション
主要な業務:仕事上必要な各種文書を作成するための文書能力
レベル定義
1上席者の手とり足とりの指導が必要なレベル(新卒入社1年目など)
2上席者の多少のレビューと修正が必要ではあるが、日常的なドキュメントは、おおむね作成することができる
3簡単な文書など(日常業務レベル)は、独力で問題なく作成できる
4日常業務を越えるような報告書や稟議の書類を作成できる
5指導者のレベル
6非常に高いドキュメント作成能力を持っている

自信のあるスキル、不安なスキルは?

まずは全体の平均像を見てみましょう。

グラフ1 平均スキル値
グラフ1  平均スキル値

この母集団のDBの経験年数は6.69年でした。

予想どおり、平均はおおよそ3あたりの数値になっています。しいて言うと、オペレーションやバックアップリカバリ、SQL作成といったよく使われる知識は皆さん自信をもっているようです。そして、セキュリティは若干自信がないようです。

経験年数とスキルの関係は?

結果を分析したところ、DB経験年数との相関が強く出ました。⁠経験が長いほど、スキルが伸びていく」という結果です。

グラフ2 経験年数と平均スキル値
グラフ2 経験年数と平均スキル値

だいたい5年くらいで、ほぼ一人前(平均スキル値が3)になっているようです。

しかし、最初はスキルの成長が速いものの、1から2、2から3、3から4と熟練していくにつれ、徐々にスピードが落ちていきます。DB使いとして10年以上経た人達は、スキルの平均がおおよそ4に達していますが、このあたりが「一般的な現場のスキルのピーク」と考えてよさそうです。

所属組織による差は?

では、所属組織によって違いは出てくるのでしょうか。

まずは業務アプリチームに所属している人の傾向を見てみましょう。

グラフ3 業務アプリチームの特徴
グラフ3 業務アプリチームの特徴

普段の仕事で触れることが少ない、バックアップリカバリや、構成管理(パッチの適用など⁠⁠、セキュリティ、インフラスキルなどの項目が、全体の平均に比べて若干低めになりました。やはりインフラ担当や運用担当におまかせしているのでしょう。

一方、運用やデータセンター部門はどうでしょうか。

グラフ4 運用やデータセンター部門の特徴
グラフ4 運用やデータセンター部門の特徴

グラフ4を見ると、SQLチューニングやSQL作成、コミュニケーションスキルなどが若干低めに出ています。バックアップリカバリや構成管理(パッチ適用など)は日々の仕事で使用するため、流石に得意なようです。

平均値だということもありますが、意外だったのは、皆さん現場でスキルアップに努めているようで、年数に比べ、所属組織による差はそれほど出ていないことです。

今回はここまでです。DBエンジニアの皆さん、自分のスキルを定義に沿って自己(記入)評価してみて、比べてみてください。自分の意外な得手・不得手に気づくかもしれませんよ。

この話は、7月21日(土)に開かれるJPOUG(オラクルのユーザグループ)のイベントでもっと深堀してディスカッションします。参加費無料、初心者歓迎です。

次回は、DBエンジニアの所属する会社の種類や職種ごとの強みと弱みを見ていきます。伸ばすべきスキルも紹介します。お楽しみに!

注:本記事の見解は、筆者自身の見解であって、所属企業の見解を必ずしも反映したものではありません。一部のデータ件数は少ないため、精度が劣る点はご了承ください。

おすすめ記事

記事・ニュース一覧