（登壇者）
- 日本オラクル：小田圭二氏
- アシスト：関俊洋氏
- DB Onlineチーフキュレーター：谷川耕一氏
谷川：最初にDBエンジニアの現状をまずは認識したいと思います。先程、関さんのセッションでもありましたけど、DBエンジニアというのは、今、捉え方としてはとても広いところがあるので、その辺の現状認識、どんなキャリアなのかみたいな話をしたほうがいいと思っていて。このパネルディスカッションのための打ち合わせの時に、小田さんから3タイプ、3種類のDB担当がいるんじゃないかっていう話があったので、そこを少し小田さんのほうからまずは説明して頂けますか。
3つのタイプのDBエンジニア
小田：はい。3種類のDBエンジニアというのを定義しています。1つは開発者。PJで実際システムを作りながら、特に業務側にも踏み込んで作っていくという立場の開発者DBAになります。ここには、データモデリングもする人も入りますし、物理設計等についても表とか、そういったアプリケーション寄りに関しては行います。あとは、表とかINDEXを作ったり、SQLをどうするかといったところに関して、開発フェーズはすごくDBエンジニアの必要性がある。さらに、SQLチューニングがどうしても必要になります。このSQLチューニングで、苦労してるっていうのがこの開発側DBAの1つの特徴かなと思います。
2つ目が、運用側で、ずっとDBの面倒をみてるという人。DBの守護者みたいな形ですね。こういう運用側DBAもいる。彼らは、作るというよりは、運用・監視から始まって、キャパシティの管理、あと再構成だとか。またアプリケーションの変更にも対応しますし、バックアップリカバリも運用の中のタスクの1つです。あと運用で言うとですね、やっぱりトラブル対応。インシデントっていうのがどうしても起きますので、そういう時に対応するのが運用側DBAです。これは、現場によっては、運用側DBAがいないと、いきなり開発側の作った人のDB担当のところに問合せがいったりもするんですけど、運用側が定義されてる場合はこっちにいくことになります。あと忘れてはいけないのがパッチ当てですね。運用の一環として、SQLチューニングをやっていくようなこともあります。あとバージョンアップをしたりもします。
ここら辺が開発側、運用側というよくあるDBAのパターンです。あともう1つは、全体最適、品質向上のためのDBA、ガバナンスをきかせるようなタイプのDBAです。未然防止とか、横展開を考える担当です。ガイドやツールを作成したり、あとはレビューですね。さらに言うと難易度の高いトラブル対応だとか、高品質な運用をすることもできる全体最適担当のDBAがいます。
じゃあこういう3タイプがいるとして、現状のDBエンジニアってどうなのという、データをちょっとお見せしたいと思います。
DBエンジニアが一人前になるには5年くらいかかります
小田：これは、DBスキル定義ということで、DBエンジニアにはどんなスキルがあったほうがいいんだろう？ということを、10年くらいかけて作り上げてきたものです。
小田：まず、アーキテクチャの知識がいりますし、論理設計のノウハウも一部のエンジニアには必要です。物理設計も当然必要です。あとオペレーションは、DBには絶対ついてまわります。あとSQLチューニングであるとか、インスタンスチューニングと言われる技が、DBそのものの性能の話。あとインシデント対応とかですね、トラブル、サポート問合せっていうのも、製品である以上やっぱりつきものです。かつ、ヘルスチェックとかですね、こういうのも運用するにあたってはけっこう必要です。あまりDB以外でこういうことやらないかもしれないですけど、DBはやらないといけません。気が付いた時には事故になってるってことになります。あとはバックアップリカバリ、構成管理でパッチも必要です。忘れちゃいけないのはセキュリティですね。最近DBのセキュリティ事故も多いですし、クラウドになるとここの知識も重要視されてます。あと先程も何人かの方が言ってましたけどインフラスキル。どうしても、いろんなインフラの知識が必要なんですね。回り道のようでここがないとなかなか伸びないっていうところも我々、経験として持っています。だから、このインフラスキルっていうところも大事になります。あとは、アプリ側の人が中心ですけど、SQL作るスキル。あとコミュニケーションとかですね、ネゴシエーションって書いてますけど、結局、仕事するにはそこら辺のスキルがいる。あとドキュメント作成なんかも必要だねってことで、我々なりに作ったこの定義をもとに、どれくらいかけて一人前になってるんだろうねっていうところを記したのがこれです。
これを見ると、3っていうところがあると思うんですけど、3でだいたい一人前です。上のほうにいくともっと上達していくんですね。例えば5とか6くらいになってくると達人みたいなレベルになってきます。1は初心者のレベル。
データ集めてわかったんですけど、やはりDB経験が何年っていうのにかなりきれいに比例してスキルは上がっていきます。なので、このグラフはですね、DB経験が1年、3年、5年、10年、それ以上と、データをきれいに分けて過去10年くらいこのデータを溜めてます。
谷川：これは基本的にはオラクル社内のものですか？
小田：いえ、オラクル社外ですね。
谷川：じゃあある意味、一般的というか、Oracleに近いところにいるDBエンジニアを分析するとおそらくこういうふうになるだろうということですね。
小田： SIer、情シス、SI子会社といったDBエンジニアを集めるとこういうふうになります。ここで、ポイントはこの3年から5年っていうところで、まだ3に到達するかしないかくらいです。ということは、DBでほぼ一人前になろうとすると、世の中だと5年くらいはかかるんですね。5年、10年、5年から10年だとだいたいもう3を超してくるので、だいたい一人前にはなってるかなと。Oracle DBだからというわけではなくて、やっぱりDBって複雑だからだと思うんですけど、一人前になるのに5年くらいみておいたほうがいいのかなと思いますし、我々がコンサルするお客様でも、どういうふうな育成しましょうかって話をするとこんな感じに「3年から5年くらいはかかっちゃうよね。OJTも含めて」という意見が多いかなと感じてます。
谷川：関さん、今のお話はいかがですか？
関：3年から5年っていうのは本当にその通りですね。スキル的なところで言うと、アシストもDBをやってる会社なんで、5年くらいで一人前っていう考え方は1つあるかもしれないです。一人前のレベルもあれですけど、中級くらいですかね。Oracle Master Goldくらいまでは5年くらいでいくんじゃないかなと思ってます。
谷川：先程小田さんに最初に説明して頂いた3種類、開発者としてのDBAと、運用側のDBAと、全体最適をするDBAっていう、ちょっともしかしたら、馴染みがないかなと思ったんですけど、関さんは3つの分け方を聞いた時にはどう捉えましたか？
関：開発と呼ばれてる方の仕事ってけっこう意外と多いんですよね。実際はその開発の下に構築っていう役割が1つあるのかなと。我々そこでお邪魔することが多くて、例えば開発の方のタスクの中にSQLチューニングってありましたよね。あれって運用でトラブった時にやるイメージがみなさんの中で強いと思うんですけど、実は開発側のタスクだったっていうところは、それは僕は正しいと思って、意外と気付きとしてはあるのかなと。トラブった時にやるもんじゃないんですよっていうのを、なかなかユーザー側の方にわかってもらえないです。
谷川：先にやっとけと。
関：先にやっとくのがいいんですけど、だいたい運用でトラブった時に緊急対応ということが多いです。
谷川：その辺は小田さん、コンサル的なメニュー感から言っても、開発の段階でSQLチューニングっていうのは、けっこう大きなクローズアップになってたりするもんなんですか？
小田：しますね。むしろ運用の人で安定した運用をしているDBのエンジニアは、あんまりチューニングしないですね。落ち着いたシステムであれば、あんまり経験することもないです。よくないパターンは、ちゃんと性能テストをやらない、特にデータ件数が少ない状態でサービスインして、本番でトラブる。これが最悪です。
谷川：それも広い意味でのチューニングとしてきっちり捉えておいて、初期段階の開発の段階でやるというのが1つ、さっきの3を超えるためのエンジニアになるための条件みたいなものですかね。
小田：そうですね。スキルだけでなく、事情にもよると思いますが。
