データ移行を考慮しないデータモデル設計は駄作
…「という側面もある」というくらいのつもりで聞いてください。
実際には色々な都合や事情もあって、データ移行の難易度がやたらと跳ね上がらざるを得ないプロジェクトというのもあると思います。
ですが一方で、データモデルを設計するエンジニアの大半が
「移植性」
という名のソフトウェア品質を度外視して設計しているというのもまた事実です。「へぇー…そんなのもあるんだ」というエンジニアも多いかもしれません。
移植性とは、現在最新化されているISO 25010（JIS X 25010）で定義された
ソフトウェア品質
の国際規格で定められている品質特性の１つです。
いまだにバグの有無だけが品質だと勘違いしている企業やエンジニアは数多く存在しています。実際、そういったところで作られている品質マネジメント…品質計画などを見てみると「テスト密度」「バグ密度」などと言った観点でしかソフトウェアの品質を測ろうとしていません。
エンジニアが個人的に自主勉強した…という事例はあるでしょう。私もその一人です。
ですがそもそもソフトウェア品質のあり方について従業員にきちんと説明責任を果たしているＩＴ企業なんてひょっとすると両手で数えられる程度にしか存在していないかもしれません。
それくらい軽視された仕組みであり、だからこそ絶えずリリース後に障害が発生し続ける世の中が蔓延しているのだと思います。
ソフトウェア品質は決して「ソフトウェアテスト」を中心とした話ではありません。
ソフトウェアテストは実装されたプログラムを検証するためのただのプロセスの１つです。もちろん、実装されてしまったソフトウェアに対してその品質を保証する…という意味では他のプロセスの追随を許しませんが、それだけでソフトウェア品質をすべて担保することは叶いません。
そもそも作りこむ時点での品質を保証するためには、「設計」というプロセスや開発プロセスそれぞれの「ルール化」と言ったものもソフトウェア品質に密接な関係を持っています。
そんな中の１つ
「移植性」
が今回のテーマとなります。
「移植がしやすいかしにくいか」という指標において、もちろんのことながら99%くらいのエンジニアは設計やテストの観点で考えたことはないでしょう。
単純に老朽化したシステムを再構築（リプレース）するにあたって既存の情報資産である「データ」や「ファイル」などを新システムに移行するのも移植の１つですし、ＯＳなど環境を最新化するなかで既存プログラムがそのまま活用できるようにするマイグレーションも移植の一つです。
そういった自らが作ったソフトウェアに対し、リリース後のライフサイクルを考慮に入れて、「次」の移植をイメージするエンジニアなんていったいどの程度存在しているでしょうか。
Ｂ２Ｂのソフトウェア開発においては、エンジニアにとって
「契約の切れ目が縁の切れ目」
と考えている人も少なくありません。特に仕様書や設計書、エビデンスなどを残そうとせず、保守・運用や次期開発などが困るようになるなんて全く想像すらしていないはずです。
だから「移植性」という概念自体を知らない人も多いし、知っても興味を持とうともしません。
実際、旧システムから新システムへ切り替えるプロジェクトが発足した時、データ移行の必要性は知っていても、新システムのデータモデルを検討する際に「自分だったらこんなデータモデルにする」
「その方がプログラミングしやすい」
「その方が性能のボトルネックも解消される」
「SQLがシンプルになる」
と言った「モノづくり」志向を中心に検討している人が多いのではないでしょうか。
それがどんなに旧システムのデータモデルと大きく変化していても、「そっちのほうがいい」という観点だけで見てしまうため、どうしても
お客さまの資産をいじくりたおす
ことによるリスクを忘れがちです。
システムを構築する際、新規で導入するインフラや新規で開発するソフトウェアについては納品するまで顧客資産とも呼べないので、それなりに作り手のこだわりが入るのは仕方がありませんし、別に構わないと思います。
ですが、既存資産を流用するにあたって、それらの資産は決してＩＴ企業のものでも、エンジニアのものでもないということを忘れてはなりません。
移行対象となるデータはその最たるものです。
いくらお客さまの要望を満たすためであっても、それがイコール「お客さまの資産をこねくり回しても許される」というものではありません。お客さまの所有しているビルや人、その他物理的資産を自分たちの都合で勝手に増改築したり、異動させたりなんてことしませんよね？
にもかかわらず、なぜかデータだけはそれが許されると思いがちです。
実際にはお客さまにお伺いを立てているかもしれませんが、この「データをこねくりまわす」ことで移行作業が複雑化するリスクやコストまできちんと考えたうえでバランスを考慮しているエンジニア…というのはまずいないのではないかとさえ思っています。実際、そんな検討をしているデータモデル設計者にはいまだかつて１度も会ったことがありません。
もちろん「データ移行はストレートコンバートにするべきだ」と言っているわけではありません。新システムにお客さまが望む様々な要求を組み込むことで、当然データ構成だって最適化されていくべきだとは思います。
ですが、そうやって旧システムと新システムとのデータモデルに大きな乖離を生めば生むほど、その乖離の度合いが複雑化すればするほど、
・データ移行に求められる要求難度が指数的に跳ね上がる
・そしてその分のコストはすべて顧客が賄う
というところまで考えられていません。データ移行あるいはデータ移行のために作成されたツール類などはシステム本体と異なり、一度実施し、成功してしまえば二度と使うことが無い、いわば『使い捨て』の作業であり、製品です。
ですから軽視されがちなのはわかりますが、だからこそそこに余計な歪みを押し付けてコストを高騰させるような愚を犯すべきではないのです。
データの構造や構成を設計する時、「新システムに対する要望の取り込み」という観点以外に
「旧システムから移行されるデータ構成とのバランス」や
「さらに次のシステムへと移行する際に負担をかけないデータ構成」
と言った観点で検討するだけで、移植性（の一部でしょうが）という品質特性はグッと向上することになるでしょう。
これは「品質」といわれてすぐに「バグの有無」としか発想できない人には永遠にわからないことです。移植性はバグの有無やあるいは定量的なバグの指標値を設けるだけしかできない環境では決して考えることができないようになっているからです。
そしてそう定義づけると、私の知る限り「品質マネジメント」や「品質計画」を十分に実施できている企業というのは、ホント両手で数えられるほどしか存在しないんじゃないかなー…と思ってしまうわけです。
余談
同じような理屈で、「非機能」というとすなわち「性能」しか思い浮かばない人というのもありますね（一般的に性能というと、ソフトウェア品質のなかの「性能効率性」のなかの「時間効率性」だけを指します）。ソフトウェア品質で定義されているすべてを挙げろとは言いませんけど、せめて信頼性やセキュリティくらいは出てこないと「あ、このプロジェクト、ヤバいかも」と思ってしまいます。
あと、UI/UXなどを標榜している組織であれば「（利用時の品質は別にあるけど、それはそれとして）最低でも「使用性」の評価水準って設けてるよね？」と気になってしまったり。
逆に「保守性（試験容易性、変更容易性）」などまで考慮されていたりすると「さすが！」と思ってしまいます。「性能効率性」でも、時間効率性だけでなく資源効率性や容量満足性などまで検討されていると「このプロジェクトにはまともに活動できているアーキテクトやDBAがいるのかも？」という予測が立ったりします。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。