DBAの皆さん、こんにちわ。さて、「DBA」という言葉はどこから生まれたのでしょか？正直私もよくわかりませんが、20年ぐらい前にOracle Databaseが爆発的に普及したことをきっかけに「DBA」なるエンジニアのカテゴリーがIT界隈で生まれた気がします。そんな私も「Oracle DBA」として様々な案件で活動してきましたが今回はそんな話を少しだけ。
#「Oracle 技術で一生食っていけるぞ」という甘い言葉
実際に私が新卒で入社した時に、かなり年上の先輩から言われた言葉です。入社したばかりの私は「Oracleって何？おいしいの？」ぐらい無知でしたが、私に先輩が教えてくれたこの言葉を今でも覚えています。
私自身、なぁなぁでIT業界に入ったような感じなので、何か得意分野を身につけなければと思っていました。そんな時にこの先輩の言葉は非常に魅力的で「妄信」するに値するものでした。当時はただひたすらにOracleの検証に明け暮れたことを覚えています。インストールから始まり、パフォーマンスチューニング、バックアップ、リストア/リカバリ、高可用性実現などなど。そもそも無知だったので、多くの事を学ぶことができましたし、全国各地でセミナーの依頼もいただいて、よく登壇なんかもさせていただきました。このころは寝ても覚めても、夢の中でもOracle Database（当時は10g）を触っていたと思います。だって、それが「一生食える技術」と信じていたので。
#Oracleのインストールが飛ぶように売れた時代
Oracleの技術力がついてくると、Oracleのニーズの高さにも気付き始めました。用意されたサーバにOracleをインストールする仕事は「Oracle Database 導入案件」と言う名で仕事の依頼が殺到しました。もちろん、Oracle Real Application Cluster（Oracle RAC）、Oracle Data Guardなども同様です。また、ハードウェアの老朽化に伴う、「古いOracle Database」から「新しいOracle Database」へのデータ移行はまさに花形の作業となり、いくつのDatabaseからデータをExportしてImportしたか覚えてないぐらい大小さまざまなデータベースの移行を行いました。
#DBAだってすごく重宝された時代
大きなプロジェクトではDBAチームなども編成された時代でした。IT業界ではデータベースエンジニアはそもそも人数が多くないので、「人月単価（一か月間でクライアントからもらえる金額）」も他のエンジニアより高額です。当時のDBAの仕事はこんな感じでした。
- データベースの性能分析や定期健康診断
- テーブルやインデックスなどのオブジェクト管理
- 開発者の為のSQLレビュー
- 障害発生時のトラブルシューティング
- バックアップデータの管理や運用の確認と見直し
- データベースユーザや権限の管理
- データベース監査の管理
- データベースの起動停止
システムの根幹とも言えるデータベースの管理を一手に引き受けるDBAはプロジェクトでも__一目置かれる存在__であったように思います。
#クラウドの到来とOracle DBA黄金期の終焉
そんなある時、2009年頃から噂されていた技術が2013年頃爆発的に広がりました。そうです、AWSやAzureのような__クラウドテクノロジー__です。この頃は猫も杓子も「クラウド」と言っていたように思います。このクラウドテクノロジーが私のOracle DBAとしての黄金時代を瞬く間に終焉へと追いやりました。
今まで、「Oracle導入作業」の名のもとに、あらゆるサーバへインストールを行っていた作業は、クラウド上では数クリックで終わってしまいました。追加オプションとして請求出来ていた「バックアップの設計、導入」はクラウドではデフォルトで勝手に行われます。DataGuardのような高可用性機能の導入もチェックボタンにチェックを入れるのみの作業となりました。パフォーマンスの解析も誰でも見やすいツールが導入されて、StatsPackやAWRレポートを分析する職人的なスキルは必要としなくなったのです。
この頃から徐々に仕事の依頼の件数は減っていったように思います。年々落ちていく売上が自分の市場価値を表しているようで毎日辛く感じました。どうすればいいのかと不安な状態が続きました。
#Oracle DBAがこれからを生き抜くために
ただ、「捨てる神あれば拾う神あり」です。こんな不安な状況から脱出させてくれた技術があります。そう、クラウドです。「クラウド」＋「Oracle Database」というキーワードはクラウド黎明期では非常に重宝されました。私が今までやってきたOracle技術が全て無駄になったわけではなく、多くのOracle Databaseユーザはデータベースのクラウド化が行えず、実績も少ない状態だったので、悩んでいるクライアントも多くあり、こういうデータベースのクラウド化が新たな主戦場となりました。
また、Oracle DBAは信じられないかもしれませんが、世の中にはOracle Database以外のデータベースも多く稼働しています（少なくとも私はOracle DBA時代、ある程度大きな環境ではOracleしか使われてないだろうと思っていました。）。Oracleで学んだ技術は他のデータベースにも転用可能な部分が多くあります。他のデータベースに触れることは大事だと思いますし、他のデータベースを触れると初めて、Oracle Databaseのすばらしさに気づくと思います（ライセンス料以外は）。また、以外に「脱Oracle」のニーズは多くあります。こういった案件でこれまでのOracle DBAの技術とその他のデータベースの技術の２つの技術がとても役に立ち、重宝されます。
最後は「業務」や「データ」の意味も理解しようという事です。私はOracle DBA時代先輩から以下のように教わりました。
「業務やデータの中身に思いをはせてはいけない。君の仕事は目の前のSQLをいかに早くするかだ。」
これは多分間違いでしょうね。「業務」や「データの中身」を理解し、データの分析なども行えるようにならなければ、今後はDBAではダメだと思います。
まとめると、Oracle DBAがこれから生き抜くために
- これまでのOracleの技術を生かして、Oracleのクラウド化を手助けする。
- Oracle以外のデータベースにも精通し、異機種間でのデータのやり取りも難なくこなす。
- 「業務」や「データ」をしっかり理解し、DBの知識を生かしてデータに付加価値を与える仕事を生みだす。
と言ったところでしょうか。これがこれまで「Oracle DBA」であった私が痛烈に今感じている事です。
Oracle DBAはOracle以外もやらなくてはいけなくなった、そういう時代が来たように思います。
#最後に
これまでの内容はあくまで、私の経験に基づいて記載している内容で、皆さんの経験と合致しないかもしれませんが、共にデータベースエンジニアとして成長させてもらえれば何よりでございます。だって、データベースってミドルウェアは面白いミドルウェアなのですから。
（ちなみにその先輩はいまだにOracle DBAとしてのスタンスを変えずに頑張っています。がんばれ！）