DBバイリンガルのススメ

本書がデータベースエンジニアの皆さんに「DBバイリンガル」を勧めるのは、以下の3つの理由があるからです。

ソムリエになる

ソムリエは、お客様の予算や好み、料理に合わせて最適なワインをリコメンドします。そのためには、自分自身がいろいろな産地、銘柄のワインや特性を知っていなければなりません。DBエンジニアにもソムリエと同じような役割があり、ユーザーの予算や既存資産、用途に適したRDBMSを選択・提案する立場になります。ソムリエの方々は、知識をつけるだけでなく日々いろいろなワインを飲んで勉強するので、そのためのお金が大変だそうです。DBエンジニアも、RDBMSベンダーの受け売り知識ではなく、自分で環境を準備して機能を確認するという姿勢が大切です。

現代のビジネスでは、すべてにおいて「顧客満足度」が優先します。“売り手の都合”ではなく、“ユーザーの立場”に立った提案ができなければ、ビジネスで成功できない時代なのです。そのために、まずやらなければならないことが、DBモノリンガル的な狭い視点からの脱却なのです。

理解を深める

これは自分の経験でもあるのですが、Oracleしか知らなかったときに比べて、SQL ServerやほかのRDBMSを使うようになってからRDBMSに対する理解がぐっと深まったと感じています。「海外に行って、改めてニッポンの理解が深まる」ということがあるように、Oracle自体に対する理解も深まります。実際、今まで何気なくやっていたことが、ほかのRDBMS製品に触れたことにより「あ、そういうことだったんだ！」と思うようなことが多いのです。

動物学者デズモンド・モリスの書いた「裸のサル」（*注1）という有名な本があります。この本では、サルと同じ祖先を持つ類人猿としてヒトを捉えているのですが、この本を読むと人間の日常の行動が類人猿の本能にもとづいていることが分り、ヒトへの理解が深まります。たとえば人間の争いは、結局はサルと同じく「縄張り争い」と「階級闘争」に集約されるなどと言われると、なるほどと思わざるを得ません。
RDBMS製品も同様で、SQL標準で定義されているRDBの1つとして捉えることで、製品への理解が深まります。もしも今の環境がOracleオンリーであって、ビジネス的にOracleだけでこと足りるような状況だったとしても、「比較することで理解が深まる」という物事の性質を利用するのは1つの技術向上の方法だと思います。SQL標準とRDBMS独自機能の区分けはもちろん、データベース設計、プログラミング技術、パフォーマンス向上、運用管理、他システムとの連携など、いままで知っていたつもりだったことが、実はもっと広い応用方法があることに気づかされます。

	*注1：「裸のサル　動物学的人間像」 デズモンド・モリス著、日高敏隆 訳、角川書店刊 1967年発表。原題“THE NAKED APE”。人は「裸のサル」であるという観点から、人間の諸行動を鋭く観察・分析した自然人類学の古典。

価値を高める

私はメーカー企業の出身なのですが、メーカーの技術者は自社製品のことしか知らない人が多いと思います。立場的に自社製品の情報はいち早く入手するのですが、他社製品の良さや分野全体のことに関しては疎い人が多く、このあたりがメーカー技術者の大きな壁だと感じます。

私がメーカーにいた頃、故・土光敏夫氏（*注2）の「穴を深く掘るには幅がいる」という方針が掲げられました。これは、「まず得意分野を持て。そしてそれを深くするためには周辺技術も勉強しなければならない」という意味です。今にして思えば、自社技術に偏りがちな技術者に対して危機感を持った発言だったのかと思われるのですが、当時の自分は仕事に追われてなかなか時間が取れず、結局転職するまで実践できませんでした。
この言葉は、データベースに置き換えてもピンときます。DBバイリンガル、マルチリンガルになることで、RDBMSに対する理解をぐっと深めることにより、DBエンジニアとしての自分自身の価値は大きく高まります。そして、そのことが冒頭でも触れたように企業・組織全体のビジネス的可能性を大幅にアップさせるのです。

	*注2：土光敏夫氏 1950(昭和25)年、石川島重工の社長に就任後、60(昭和35)年に播磨造船との大型合併を主導して石川島播磨重工を設立。その後、東京芝浦電気(現・東芝)社長・会長を歴任しながら、74(昭和49)年から80年まで経団連会長を務めた。「ミスター合理化」「改革の鬼」として知られる。なお、筆者の梅田氏はかつて東芝本社・技術部に在籍。

表1：DBバイリンガルになる目的

目的 内容 ソムリエになる ユーザーに適したRDBMSを客観的に提案できる力をつける 理解を深める 複数の製品を知ることにより、RDBMSに関する技術を深める 価値を高める 自己および組織のビジネス的な価値を向上させる

どうすれば、DBバイリンガルになれる？

まず「やってみる」

DB技術の習得は英会話と一緒で、まず「やってみる」ことが大切です。英会話では、グラマーを勉強したり、穴埋め問題をたくさんこなすより実際に外国人と会話するほうが上達への近道です。RDBMSでも、雑誌を読んだり、資格試験の勉強をするよりも、実際にトライアル版をインストールしてあれこれ操作する方が、よほど短期間でスキルアップできます。

本書を手にしているということは、きっと皆さんは知識欲や向上心の強いエンジニアの方々だと思います。本書を読んで、「よし、自分もDBバイリンガルになろう！」と思ってくださる方も少なくないと思います。しかし、思っただけではなく実際に行動できるかどうかが分かれ道なのです。AFN（American Forces Network：米軍関係者向けラジオ放送）を毎日聞いてもヒアリング力があまり上達しないように（これは個人的な経験談ですが･･･）、雑誌を読み流すだけではバイリンガルにはなれません。SQL Serverもマスターしようと思うのであれば、SQL Server2000の評価版などを実際に導入して、トライしてください。

もちろん、ほかのRDBMSの評価版を試してみるのもいいでしょう。10年前と違い、今やインターネットや雑誌で各社の評価版ソフトが入手できますし、技術的な資料やサポートもインターネット上で十分得ることができます。こんな時代になっても、まだ会社の仕事でしか勉強しないという“会社人間的”なオールドスタイルでいると、いつの間にかエンジニアとして大きな差を付けられることになります。

RDBMSの狭い範囲にとどまらない

RDBMSでシステムを構築した経験があれば、データベースの構築やセキュリティの設定、SQLの使い方など基本的な技術はマスターできているでしょう。そして、まだよく理解できていない部分があった場合に、「次回はそこを勉強しながら･･･」などと思った方もきっと多いと思います。

このようにある範囲の中の理解を深めるというアプローチはもちろん大切です。しかし、一方でもう少し顔を離して広い範囲でRDBMS製品を使うことも考えてください。たとえば、SQL ServerにはAnalysis Servicesというビジネス インテリジェンス（BI）を実現するための機能が標準装備されています（*注3）。ところが、せっかく“タダ”でBI機能が装備されているのに、これを使えていないケースが多いのが実情です。

ニーズがないわけではありません。BIなら簡単にできるようなことを“情報系システム”と称して、従来のようにプログラムで作りこんでいるのです。なぜ、そうしているかというと、単にエンジニアのスキル不足・勉強不足が原因と言えます。BIを使ったことがないから提案もしないし、安易にプログラムでの作りこみを選択することになっています。
　同じようなことはほかにもいろいろあります。やはりSQL Serverに標準装備されているDTS（*注4）を使えば直接できるデータ連携処理を、わざわざテキストファイルに落として入出力しているケース。標準のバックアップ機能で十分なのに、昔から使い慣れているというだけの理由でサードパーティ製の高い「バックアップ製品」を購入しているケース。ジョブのワークフロー管理で実現できる運用なのに、その機能を使ったことがないので、わざわざサードパーティ製の「ジョブ管理製品」を採用するケース……。などなど、技術者の怠慢がもとで余計な出費を強いられる場合が少なくないのです。
　RDBMS製品も時代のニーズに応じて変化しており、適用範囲が拡大しています。知っていて総合的判断で採用しないのと、知らないから使わないのは大違いです。「穴を深く掘るには幅がいる」というつもりで、使えそうな機能は積極的に勉強しておくことも大切だと考えてください。

	*注3：Analysis Services SQL Serverのデータ分析機能は、7.0のときにOLAP Servicesとして登場。SQL Server 2000では、さらにその機能を進化させた統合データ分析サービス機能「Analysis Services」を標準搭載する。詳細はこちら。 *注4：DTS DTS(Data Transformation Service：データ変換サービス) も、やはりSQL Server 7.0のときに導入された機能。SQL Server 2000では、GUIツール「DTSデザイナ」の強化をはじめとする機能拡張が施されている。詳細はこちら。

偏屈なこだわりを捨てる

技術者はある意味職人の世界ですので、当然のことながら人それぞれの“頑固なこだわり”を持っています。このような“こだわり”を持つことは、技術者にとって大切なことです。自分なりのポリシーや信念を持っている人は、それに見合う努力をしているもので、そうでないエンジニアは、ちょっと頼りなくて逆に信頼しにくい面があります。しかし、“こだわり”というのは両刃の剣で、中にはみんなが言っていることを鵜呑みにしているだけ、好き嫌いを最優先して客観視しない、自分のミスを認めないというタイプもいるからやっかいです。

DBバイリンガル、マルチリンガルをめざすとき、この“こだわり”が支障となる人がいます。「え、Oracleだったらこうなのに、SQL Serverはこの機能がないの？」ということにぶち当たり、「やっぱりSQL Serverなんか使えない！」と早々に結論付けるタイプです。こういうタイプは、逆にSQL Serverの方がOracleより優れている機能があっても、その部分は無意識に過小評価しがちなので、心底そう思っているのも事実です。

でも、そこで早々とさじを投げるのは、エンジニアとしては失格です。もちろんOracleの方が優れている機能もあるのですが、逆にSQL Serverの方が優れている点も同じように多々あります。そして、大切なのはどちらの製品も、これでは使えないというような致命的な問題点はないということです。たとえ、前出のようなタイプの人が「使えない」と断定したとしても、世の中では非常に多くのユーザーに問題なく使われているのですから、それを“使えない”のは単にその人の応用力不足だということになるでしょう。

RDBMS製品の進化に対応していく

クルマの世界がマニュアル車からオートマに変わってきたように、RDBMSの世界でもこれまで技術者が面倒を見てきた管理操作をだんだんと自動化してきています。OracleもSQL Serverも運用負荷の軽減のための対策に目を向けており、データファイル、ログファイルの領域管理やメモリ管理などもかなり自動化されてきました。個人的には、まだまだデータベースの断片化の解消やパフォーマンス向上など、問題点を調べるだけでなく解消操作も半自動で行って欲しいと思うことが多いのですが、以前に比べればかなり手がかからなくなってきたと思います。

こうした背景の中、エンジニアにとってのRDBMSの位置付けは以前より割合が小さくなっています。コマンドをたたいてRDBMSを設定・管理するという技術よりも、効率的にビジネスを成功させるための活用技術のほうが必要とされているのです。もはや狭義のDB技術は、ネットワーク技術やWeb技術、セキュリティなどさまざまな技術の中の1つでしかありません。データベースエンジニアも、RDBMSの狭い範囲だけでなく、一歩踏み出した広い技術を積極的に使いこなすように努力しなければなりません。

DBバイリンガルは、どんなときに便利？

さて、実際にDBバイリンガルになると、どんなときに便利と感ずるでしょう？ 自分の体験に照らし合わせて少し考えてみたいと思います。

RDBMSの選定時に実力を発揮できる

自分でRDBMSを選定・提案する立場であれば、やはりユーザーの状況に合わせてリコメンドできるのは満足感があります。しかし、ではどういうときがOracleで、どういうときがSQL Serverなのかという判断基準は人により違い、なかなか難しい問題です。

私の場合は、コストパフォーマンスを第一に考えます。コスト以外の要因としては、既存プラットホームと開発言語でしょうか。たとえば既存プラットホームがOracleばかりであれば通常はOracleを勧めます。自分はシステムインテグレータとしてDBマルチリンガルでなければなりませんが、ユーザーも同じようにバイリンガル、マルチリンガルとなる必然性はないからです。ユーザー企業であればもっと優先すべきことがほかにあるはずだと考えています。

また、開発言語としてJavaを採用した場合は、OracleやDB2 UDB、PostgreSQLを選ぶケースが多く、逆にVB、Access、ASP、 .NETなどをベースとした場合はSQL Serverとなる傾向があります。こちらの方は、「なんとなく」といった程度の希薄な理由なので、JDBCドライバによってJava + SQL Serverとするケースや、Visual Basic + Oracleの組み合わせも少なくありません。

プロジェクトメンバーとして重宝される

自分がRDBMSを選定する立場でなかったとしても、DBバイリンガルであることは非常に重要です。システムが多様化する中、いつもユーザーのシステムがOracleだけとは限りません。Oracleの場合もあれば、SQL Serverの場合もあるというのが当たり前の時代になっているのです。そんなとき「私はOracleしか知らないので･･･」と言っているようでは、プロジェクトのメンバー選定に困ってしまいます。管理者からすれば、「OracleでもSQL Serverでも大丈夫」と言ってくれるバイリンガルの方が、ずっとプロジェクト体制を組み易く、重宝されます。

DBバイリンガルであることは、プロジェクトの受注段階や要求分析段階でも役立ちます。いろいろなユーザーのところに行って既存システムをヒアリングする際、あるユーザーはOracleを使っていて、別のユーザーはSQL Server、また別のユーザーでは両方使っているなどのケースが多くなってきています。こんなとき、バイリンガルであればいつでも1人で打ち合わせを行えるので効率的です。

ライバルに差をつけられる

世の中には「この道一筋！」と、1つのことに入れ込むタイプがいます。DBの世界でも、暇さえあればいつもOracleの技術書ばかり読んでいる人がいます。こういう人を見ると「おいおい、ちゃんと外向きの（お金をもらえる）仕事をしろよ」と内心思ったりするのですが、Oracleに対する詳しさでは到底太刀打ちできません。技術者は職人気質なので、技術力のある方が優越感を持つ妙な世界なのです。

こんなときはバイリンガル、つまり二刀流になって勝負すると急に勝ち目が出てきます。相手が何か言ってきても「でも、SQL Serverならこうだよ」と切り返し、広い視野を利用して議論をすることができるのです。Oracleしか知らないエンジニアに、自分の世界の狭さを思い知らして、日頃の鬱憤を晴らすのも楽しいでしょう（？）。でも、こういう人は、負けたと感じたとたんに一生懸命SQL Serverを勉強するものなので、あっという間にまた追い抜かれてしまうことが多いのですが……。