DMR REPORT FILE：3 「ゼロからの出発！ DB移行ソフトウェアを開発せよ！！」（上）
あらすじ：
商用ミドルウェアからオープンソースのRDBMS『MySQL』へ移行することを決定した"Database Migration Research"――通称『DMR』のメンバーたち。決め手となったのは、専用のマイグレーションソフトウェアの存在だったが、そのソフトウェアが開発中止になっていたことを知り、愕然とする。
他のソフトウェアを探すが、商用に耐えうるものは見つからなく、ただ時間だけが過ぎていく……。そこでリーダーのナカハラが「決断」したこととは――？
ナカハラ「データベース移行で使うソフトウェアは……フルスクラッチで開発する！！」
四人「「「「な、なんだってー！！！！」」」」
驚きを隠せないDMRメンバーの中で、真っ先に口を開いたのはオダであった。
オダ「フルスクラッチで開発だと！？ 馬鹿馬鹿しい！！ 問・題・外だ！！」
カンダ「たしかに、利用可能なマイグレーションソフトウェアは見つかっていません。ですがフルスクラッチで作るとなると、『コストを少なくする』という、そもそもの目的から外れてしまうのでは……？」
トリイ「新しく開発案件として追加するための予算もありませんし……」
ナカハラ「うむ。皆の懸念はもっともだ……」
ナカハラ「だが、この『データベース移行』を根底から理解すれば、既存のDBから新DBへとデータを移行させるのは、そんなに難しいことではないと思うんだ」
シバタ「どういうことですか？」
ナカハラ「まず、そもそも我々の目的である『データベース移行』というものが『どのようなものなのか』について、ブレークダウンしてみてほしい」
オダ「あぁ？ ……要するに、既存のOracleデータベースのスキーマを、新システムのMySQLのスキーマへと変換して、そこに既存データを変換して突っ込むんだろう？」
トリイ「オダさん、それだけでは不十分です。OracleとMySQLでは索引の形式が異なりますし、PKやFKなどの制約についても変換する必要があるはずです」
カンダ「Oracleの独自方式といえば、ストアドプログラム、トリガといったOracle独自言語のPL/SQLで記述されているものも、すべてMySQLで利用可能な記述方式へと書き換える必要がありますね……」
シバタ「そもそも、SQLの書き方から、OracleとMySQLでは結構違いがあると聞いたことがあるのですが……例えばビューなんかに記述されているSQLも移行しないといけないのでは……？」
ナカハラは1つ1つに頷きながら、皆の意見をホワイトボードへまとめた。
ナカハラ「つまり、まとめるとこのようになる」
データベース移行対象 ・スキーマ(DDL文) ・データ本体 ・制約(PK, FK, UNIQ, CHECK) ・索引 ・ビュー ・ストアド(PL/SQL) ・トリガ ・SQL文
オダ「こうして洗い出してみると、意外とシンプルだな……」
シバタ「そうですね……」
トリイ「ですがカンダさん、スキーマ生成のDDL文や制約、索引等のDDL文って、既存システムを担当しているSIerからの納品物に含まれていましたっけ？」
カンダ「いえ、テーブル定義書やER図という形で、設計書しか受け取っていないですね……」
トリイ「となると書類を見ながら1つ1つDDL文を書きなおすことに……うわぁ、考えただけで胃が痛くなります……」
カンダ「テーブルはシステム全体で2000個ほどあったはずですから……これを1つ1つ手作業でやっていくのは大変な作業に……」
オダ「いや、そもそも既存システムの業務アプリがテーブルを自動生成する仕組みになっているから、手作業でDDL書いていくのはぶっちゃけ無理じゃねえか？」
ナカハラ「フフフ……」
オダ「何がおかしいんだ、ナカハラ！！」
ナカハラ「いや、オダの言うとおりなんだよ。この『データベース移行』は普通に手作業で行うにはコストがかかりすぎる。そもそも、前提となっている『データベースの設計書』の信頼性なんて、みなが良く知っているんじゃないか？」
シバタを除く三人が沈黙した。
シバタ「そ、そうなんですか！？」
トリイ「……たしかに……改修につぐ改修で、どのテーブル定義書が最新版なのかすら、正直わかりませんからね……」
カンダ「運用していると、データ量増加が原因のスロークエリが発生することがあり、索引を追加で貼って難をしのいだことが何度かありますが、そのときの作業がすべて設計書にきちんと反映されているかは、まったく自信がありません……」
オダ「実際、プログラムを改修するにしても、設計書を見るより直接DBの中を見た方が、早くて安全だったりするからな……」
三人がため息をつく。ナカハラはニヤリと笑みを浮かべながら話を続けた。
ナカハラ「というわけで、手作業での移行は絶望的だ。つまりは、できるだけ既存のDBからDBを構成する要素を『機械的に』抽出し、自動的に新DBの形へと『機械的に』変換する必要があるんだ」
カンダ「なるほど、『DB』を対象にした『データコンバート』に近い作業……というわけですね……」
オダ「ナカハラ、言いたいことはわかった。だが、だからこそ、これらの作業を自動的にやってくれる『移行ソフトウェア』が、俺たちには必要なんじゃないのか！？」
ナカハラ「ああ。――だが考えてほしい。仮にそういったソフトウェアが存在したとして、はたしてそれは『既存システムのDBにそのまま利用できる』のだろうか？」
オダ「それは……」
皆が絶句し、会議室に沈黙が訪れた。
トリイ「既存DBのつくりを考えると、仮にあったとしても、そのまま適用することは難しいでしょうね……」
カンダ「個別にカスタマイズ対応するとしても、それはそれでコストがかかりますし、そもそも『対応できるか分からない』という点そのものが、大きなリスクになります……」
ナカハラ「その通りだ。だったらむしろ『データベース移行』というプロセスをすべて理解した上で、『既存システムのDB専用』の移行プログラムを開発する方が、柔軟性があり、万一の場合にも対応がしやすいのではないか……そう俺は考えたんだ」
シバタ「なるほど……それがナカハラさんのおっしゃっていた『フルスクラッチで移行ソフトウェアを作成する』ということだったんですね……」
オダ「フルスクラッチで作るメリットはわかった。だがナカハラ、必要なコストはどうする！？ 開発を依頼する予算も、ベンダのアテもないんだぞ！？」
ナカハラ「いや、あるじゃないか。どこよりも我が社のDBを知りつくしており、開発案件として予算案を通したりする必要もなく、安く、迅速に、そしてフレキシブルに対応可能な会社……いや、チームが」
トリイ「そ、そんな……」
カンダ「ま、まさか……」
ナカハラ「そう…………」
※この物語は事実をもとにしたフィクションです。実在の人物、団体、商品とは一切関係ありません※