データベース・エンジニアも、システム設計、コンサルティングに踏み出そう ～RDBのスキルで活躍の場はもっと広がる
データベースには詳しいが、それ以外の知識／スキル、たとえば企業の業務システム構築全般のことや業務知識は経験も少ないし自信が持てない。エンジニアとして、もっと活動の幅を広げたいが、果たしてこれでやっていけるのか。 ――データベース・エンジニアの道を歩んできた方々の中には、こんな不安を抱く方がおられるかもしれません。しかし、データベースが得意なら活躍できる素養は持っているはず。
データベースの基礎の上に、企業システムの本質をとらえるための知識を付けていけば、ユーザーをリードしながらシステム企画／構築を引っ張る立場に立つことは可能です。
データベースが得意というだけでは不安！？
前回は、ITプロフェッショナルの道をさらに究めていくには、「基礎的な技術知識をしっかりと身に付ける」、「会社の外に出て、自分の可能性を広げる」といったことを述べました。
また、多くの方は、ITエンジニアならば、もっと広い領域で活躍したいと考えているでしょう。しかし、経験もなく自信が持てない、そういった思いもあると思います。
実は筆者も、日本オラクルでの執行役員時代に様々なエンジニアと会話しましたが、「自分はデータベースに関しては、人に負けない知識とスキルが付いたという自負があるが、それ以外のことは知識や経験が少ないため、今後もIT業界でやっていけるかどうか時々不安になる」といった相談を持ちかけられることがありました。確かに、データベースのことばかり専門的にこなしていると、システム開発全般を担当しているエンジニアや、ユーザー企業へのコンサルティングを担当している他社のエンジニアと比べて、対象領域の広さの違いに「自分はこのままで大丈夫だろうか？」と不安になるのかもしれません。
業務システム全般の企画／設計や、ユーザーへのコンサルティングを担当する場合、これまでよりも活躍の場を広げる、あるいは上流領域に活躍の場を移すことになるわけですから、経験のない自分が「本当にできるのか？ 大丈夫か？」、また「そんな場が自社にあるのか」と不安になるのも無理はありません。
しかし、そうした道を志す方にまず言いたいのは、「データベースの専門家だからといって、憶することはない」ということです。むしろ、現在主流のデータベース技術、つまりリレーショナルデータベースに精通したエンジニアには、他のエンジニアにはない強みがあります。
データベース・エンジニアの強み
データベース・エンジニアだからこその強みとは、すなわちRDB自体の強みです。
RDBは、今日の企業システムにおいて中核を成す重要なソフトウェアですが、単に大切なデータを格納する器だからという理由で、現在の地位を獲得できたわけではありません。これまで、RDB以外にも、階層型やネットワーク型など、さまざまなデータベース・アーキテクチャが使われてきましたが、企業システムの核としての地位を確立できたのはRDBだけです。それはなぜでしょう？
RDBは、1つ1つの情報（データ）を、どういうかたちに分解して格納すれば最適か、また取り出したときに扱いやすいのかを考え尽くしたアーキテクチャで成り立っています。したがって、RDBを使いこなすためには、「情報を要素に分解し、次にその要素を組み合わせて再構造化する」という考え方が不可欠です。
わかりやすく言えば、情報システムはその名のとおり、情報を扱う仕組みであり、「有効な情報を蓄え、それを戦略的に活用する」ことが究極の目的なのです。データベース・エンジニアの皆さんは、日ごろからそのことを考えてデータベースの設計に取り組まれているはずです。
そして、この「情報を要素に分解し、再構造化する」という考え方こそ、今日の企業の情報システムをとらえるうえで根幹となるアプローチなのです。この考え方の上に、さらにこれを発展させる知識／技術を習得していけば、データベースを含む業務システムを広い範囲でとらえられるようになります。
企業の情報システムとは、換言すれば「データを溜めて（要素に分解して格納し）、それを取り出して戦略的に使う（再構造化する）」ということをやっているに過ぎないのです。How（手続きや実現手段）を追いかけるのではなく、What（何のため＝目的）にフォーカスすれば、自ずと見えてくるのです。
核となるのは「情報を要素に分解し、再構造化する」という考え方
先述のように、RDBの核を成す「情報を要素に分解し、再構造化する」という考え方が、システム開発全般にも広く応用できるわけです。では、RDBにかかわる知識／スキルをベースにして、さらにそれを発展させていくには、どうすればいいのか。
実はこれに関する知識／技術は、システム開発の世界では随分前から確立されています。
まず「情報を要素に分解し、再構造化する」うえでの基礎技術として「データ正規化」があります。さまざまな形で分散して存在する情報を、一定のルールに基づいて分解／最適化させる手法です。データベース・エンジニアの皆さんには、なじみの深い技術でしょう。まずは、この正規化の知識／スキルがベースになります。
次に、正規化した情報を見える化するための技術として、「E/R（Entity/Relationship）モデル」があります。これを使い、個々の情報要素をどのように関連づけてデータの構造体を作るかを概念から定義するわけです。
正規化とE/Rモデルは、いずれもデータベース・エンジニアにとって基礎的な技術ですが、思いのほか理解できていないエンジニアが多いのも事実です。
また、正規化の手順をそのまま実行すると時間がかかりすぎて大変ですが、考え方や手順はしっかりと理解しておく必要があります。これらの技術を身に付けたデータベース・エンジニアが、さらに視野を広げたいと思ったら、ジャームズ・マーティンやトム・デマルコらが提唱した「機能モデル（Function Model）」について学ぶとよいでしょう。これは、業務／システムの要素を機能に分解し、システム要求をもとにそれらを組み合わせて新たな業務／システムを構成するというアプローチです。
この成果物に、正規化とE/Rモデルで再構造化したデータ構造体を組み合わせれば、業務／システムの設計図が出来上がります。
なお、業務／システムを構成する機能の中を、データがどのように状態を変えながら流れるのか、機能に対してどういったデータの入出力があるのかを設計するには「データ・フロー図（DFD：Data Flow Diagram）」を使います。このDFDも使いこなせるようになっておくと、さまざまな場面で役立つはずです。
本質を見定めて、必要な知識を効率良く学ぶ
機能モデルやDFDの考え方は、近年、企業システムの世界で注目されている「BPMBusiness Process Modeling）」にも通じるものです。RDBの基礎技術を理解し、正規化とE/Rモデルのスキルを習得した上に、機能モデル／DFDの知識／スキルを積み上げていけば、業務システム開発のさまざまな領域／工程で応用が効きます。
ただし、マーティンやデマルコの方法論はいずれも壮大であり、一からすべてを習得しようとすると、途中で挫折してしまうかもしれません。それを避けるためにも、ここまでにお話ししたポイント、すなわち「情報を要素に分解し、再構造化する」ことの重要性を念頭に置き、それを実践できるようになるために彼らの方法論を学ぶのだということを常に意識して臨むことが大切です。そうすれば、重要な点に絞り込み、効率良く知識を吸収できるでしょう。
こうして、データベース・エンジニア必修の技術（正規化、E/Rモデル）に論理化の技術（機能モデル、DFD）を身に付ければ、活躍の場は一層広がります。
業務に詳しくないエンジニアは、ユーザーとのコミュニケーションで引け目を感じがちです。どんなに努力しても、現場で業務を担っている方々に勝てるわけはありません。しかし、これらの知識があれば、業務の詳細を知らなくても、業務を機能の視点で整理し、それを再構成したり、ITシステムに落とし込んだりといったことが可能になります。
プロセスを逐一ヒアリングしていくと、とめどもない作業になりますが、モデル化を目的に聞き出していけば、はるかに効率的に、しかもエンジニア側が優位な立場で進めることができます。ユーザーの側にはそうした知識がないので、エンジニアがこの考え方でリードすれば、彼らにとって頼もしいパートナーと映るでしょう。このとき、ユーザーとITエンジニアがタッグを組むという関係が生まれるのです。
今回お話しした考え方をベースにすれば、企業の情報システム開発の世界で必要となる論理的思考力や問題解決力も自然と伸びます。それにプラスしてコミュニケーション力があれば、おのずと選ばれるITエンジニアになります。
ただしその前に、まずは自分が今後、どういう道を目指したいのかを、ある程度明確にしておくべきでしょう。ゴールも見定めず闇雲に学んでも、どこにも行き着かなかったということになりかねません。なりたいと思う姿を描けない限り、そうなれるわけがありません。