真のデータベースエンジニアを目指そう！：データベースエンジニアへの道（1）（1/3 ページ）

本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局）

[阿尾操, 下平浩由，アクセンチュア・テクノロジー・ソリューションズ]

はじめに

　本連載は、データベースを利用したアプリケーション開発にプログラマとして携わっている読者を対象として、データベースの利用者から設計者へとステップアップするために、いまから身に付けておきたい必須知識を解説していきます。いまはまだ「データベースエンジニア」が何であるか、どんな仕事をするのかがよく分からないといった方にも、本連載を通じて少しでもこの職種に興味を持っていただければ幸いです。

　第1回は、「データベースエンジニアの役割、およびデータベースエンジニアに必要とされるスキル」について解説します。

データベースエンジニアとは？

　データベースエンジニアとは、何者であって、システム開発においてどのような役割を担っているのでしょうか？

　情報処理技術者試験「テクニカルエンジニア（データベース）試験」では、その役割と業務を以下のように定義しています。

情報資源およびデータベースを計画・設計・構築・運用・管理する業務に従事し、次の役割を果たす。

1. データ管理者（DA）として、情報システム全体のデータ資源を管理する。
2. データベース管理者（DBA）として、基幹データベースの構築と維持を行う。
3. 個別システム開発の各工程（計画・分析・設計・運用・保守）において、データベース関連の技術支援を行う。

（「情報処理推進機構：情報処理技術者試験センター：情報処理技術者試験制度：制度の概要」から引用）

　換言すれば、データベースエンジニアとは、「データ管理者（DA：Data Administrator）」と「データベース管理者（DBA：Data Base Administrator）」の両者を指し、DAは情報資源を管理する役割を担い、DBAはデータベースを計画・分析・設計・運用・保守する役割を担います。

　では、両者の役割をより具体的に理解するために、一般的なシステム開発のVモデルの中での両者の位置付けを見てみます（図1）。データベースエンジニアは、アプリケーションの開発を行うSEやプログラマと同時並行で、独自のタスクを実施していることが分かると思います。さらに、DAが分析・設計といった上流フェイズを担当する一方で、DBAは実装・運用・保守といった中流以降のフェイズを担当することも分かるでしょう。

図1　システム開発におけるDAとDBAの位置付け

　これを踏まえ本連載では、データ管理者（DA）とデータベース管理者（DBA）を以下のように定義します。

データ管理者（DA）

業務の実世界から概念設計を行い、システム化の範囲で論理設計を行う。

　　　　　　　

データベース管理者（DBA）

論理データモデルから物理設計を行い、データベースを構築する。また、構築後のデータベースの運用設計および運用保守を行う。

いまこそ真のデータベースエンジニアが求められている！

　業務システムの開発に携わっていると、「アプリケーション単位で個別にデータを管理している結果、システム全体で重複したデータを管理しているシステム」を目にすることが多々あります。そこでは、各アプリケーションに都合の良いデータが分散して管理されています。例えば、製造業では、設計部門のデータベース、製造部門のデータベース、購買部門のデータベース、営業部門のデータベースなど複数の部門別のデータベースに分かれ、各データベース間のデータがシームレスに連携しているとはいいがたいことがあります。

　しかしながら、メインフレームの時代から脈々と受け継がれてきているような基幹系のシステムに携わると、「データ中心」コラム1という思想が徹底されていることに気付かされます。そこでは、データ中心という思想の下に、すべての業務プロセスに対して統合化された1つのデータベースで賄うということが当たり前のように行われています。つまりアプリケーション横断のデータベース設計が必須なのです。

　単一アプリケーションが乱立した背景には、企業の縦割り体質のほかにも、システムのオープン化、Web対応などがあったといわれています。いずれにしても、企業の競争力向上には必要な手段であったのかもしれません。しかし今日、それが短期的なROI（投資利益率）の向上にすぎなかったことが理解され始めています（いや、当時から「データ中心」の思想を叫んできた方もいらっしゃるでしょう）。そこで現在、最も懸念されるのは「データ中心」の思想を重視するようなエンジニアが乏しいということです。たとえメインフレーム時代のデータベースに手を入れた経緯があったとしても、そこで、データを中心に考える視点を持ち合わせていたかは疑わしいものがあります。

　そのような中、全体最適化、BtoB、SCM、連結会計のニーズの高まりから、システム全体を俯瞰（ふかん）できるような視点を持ち合わせたエンジニアが求められています。そこでは、まさにデータ中心の姿勢が求められています。いまこそ、真のデータベースエンジニアが必要とされているのです。

コラム1

なぜ「データ中心」なのか？

　業務システムであれば、ユーザーインターフェイスである「画面」や「帳票」、および企業固有の活動をシステムに実装した「業務処理」は頻繁に変更されることが予想されます。一方で、同じ業務システムであれば、そこで扱われる「データ」の内容・詳細は、変化しにくく安定している傾向があります。

　確かに、ユーザーの目に触れる「画面」は、技術の進歩や時代の流行、ユーザーの飽くなき探究心による影響を受け続けるでしょうし、ビジネスモデルの変化に応じてその「業務処理」（ルール）が変わるのは企業活動としては当然のことでしょう。

　とすれば、最も変更が少なく安定している「データ」に重きを置いて、要件を定義していく方が変更に強いシステムを構築することができるでしょう。また、せっかく安定している「データ」であってもアプリケーションと密な実装にしてしまうと、それらが変更されるたびに影響を受けることになります。また、「データ」は、複数のアプリケーションから共通・横断的に扱われていますので、アプリケーションの変更が「データ」に与える影響は計り知れません。そこで「データ」をアプリケーションから分離して考えることで、この影響を小さくすることができます。