情報を制する者はシステムを制す
「情報を制する者は〇〇を制す」
という言葉はいろんなところで用いられていますが、個人的にはソフトウェア開発等によって構築されるシステムにも通ずるものがあると考えてきました。この考え方は少なくとも2006年ごろには芽生えてたように感じます。
まずは、現在の業務システムが抱える問題点を整理してみましょう。
情報システムにも色々ありますが、こと業務システムに限って言えば必ずと言っていいほどデータベースを導入しているところが多いのではないでしょうか。
データベース設計を行なう際に、必ず次のような問題点があげられます。
世の中が急激に変化するため、ユーザーの要求に迅速に対応することができない
既存システムの変更要求対応に時間を要し、新しい開発に時間を費やせない
各業務単位で作業を進めてきたため、システム全体を眺めると似たデータが各所に存在している
たしかに、上記の問題点は多くのシステム開発の現場でよく耳にする現実かもしれません。しかし、だからといってそのままにしておくこともできません。
これらの問題点に対する解決策は次のとおりだと述べられています。
取り扱う情報の構成を先に標準化し、「標準データ」の維持を行なうプロセス（追加・更新・削除）を一貫して設計する（データ中心アプローチ）
プロトタイプを作成し、エンドユーザーが操作性や機能性を納得した上で本当に望んでいるシステムを提供する
つまり、システムを開発するにあたって、プロセス中心アプローチ（POA）ではなくデータ中心アプローチ（DOA）の設計手法を使って「管理すべきデータは何か」を分析・設計すれば同じデータが複数箇所に管理され、それらの値の整合性が取れていないような状況にはなりません。
さらに、DOAを行なっておけばプログラム設計時に複雑なコーディングや高レスポンスが期待できないような処理を見つけることができるため、未然に問題を防ぐことができます。
また、将来の拡張にも柔軟に対応することができるようになります。
ちなみに、ここで出てきたプロセス中心アプローチ（POA）やデータ中心アプローチ（DOA）と言う考え方は1980年代～1990年代が全盛で、2000年代以降はDOAをベースにオブジェクト中心アプローチ（OOA）と言う考え方が主流となっています。
MVCを語るなら、OOAがわかっていなければ話にもなりません。
しかし、残念ながら世の中の傾向がどうあれ、未だにPOAの考え方やDOAの考え方が根強く、システムの最適化を鈍らせていると言うのが現状です。
なぜなら、1980年代～2000年代前半の時代に育ったエンジニアが、今まさにシステム／ソフトウェア開発の中心を担っていたり、あるいはそうした人たちから考え方が改まらないまま若手が継承してしまっているからです。
また、組織において「縦割り」でタスクを与えることも起因しているのでしょう。縦割りで、特定の機能などに対し「設計」「製造」「テスト」を同じメンバーに割り振るため、どうしても担当する機能以外について無頓着・無関心となりやすく、常に全体最適の視点で物事を見る目を養うことが阻害されてしまうからです。
POAとはその名前のとおり、プロセス（手順）を設計するための手法です。
設計の成果物としてDFD(Data Flow Diagram)やHIPO図などを作成しますが、ITパスポート試験で出てくるレベルの初歩的な内容ですので、ここでPOAについて詳しくは解説しません。
データベースはDOAの設計手法を使って設計していかなくては、つくるだけでも一苦労なうえに作ることができても長くは保ちません。
通常、多少なりともソフトウェアアーキテクチャを理解していれば、まさかプロセスを設計する手法を用いてデータベースを設計する…なんてことはないだろうと考えていると思います。
実際、POAしか考えられない人に昨今のシステムを上流工程から任せると、おそらく十中八九トラブルが起きます。トラブルとならないまでも品質面で必ず問題が起きます。
しかし残念なことに、プロセス中心アプローチによるデータベース設計が日常化され未だに跋扈しているため、先述の問題点があげられるのです｡
POAによるデータベース設計
１つの具体例を元にこの現状を解説します。
インターネットショップのシステムを立ち上げることを考えてみます。
どのようなデータを管理するべきか、データベース設計をしてみましょう。
まず、販売する商品は自社商品だけでは少ないので、他社からも仕入れて販売するとします。この場合、「仕入れ」という処理が発生するので仕入れ先の名前や住所を管理するテーブルが必要です。また、仕入れ商品のテ－夕管理も必要です。
次に、その商品をインターネット上で「販売する」という処理が必要です。
ここでは、注文してくれる顧客のデータと注文を受けた商品の管理が必要です。
さらに、インターネットショップなので目の前で商品を手渡すことができません。
そのため「出荷」という処理が発生し、出荷先のデータや出荷する商品のデータ管理が必要です。
さて、ここまで考えたところで振り返ってみると、次の情報グループ（以下、エンティティと言う）を洗い出すことができました。
・仕入れ先エンティティ
・仕入れ商品エンティティ
・顧客エンティティ
・注文エンティティ
・出荷先エンティティ
・出荷商品エンティティ
実は、ここまで行なってきたインターネットショップシステムに必要なデータの分析方法は、プロセス中心アプローチ（POA）となります。
気付いていましたか？
まず、インターネットショップシステムに「どのような処理（手順）が必要か」を考えました。そして次に「どのような処理が発生するか」という順序で分析しました。そしてその処理で取り扱う情報を洗い出し、それらの情報単位でエンティティを考えました。
つまり、プロセスを中心に骨格を形成し、データを肉付けしたわけです。
気付かなかった人は実際の設計においてもDOAではなく、日頃POAでデータベース設計をしている可能性が非常に高いということです。
プロセス中心アプローチの問題点
では、この分析方法のどこに問題があるというのでしょうか。
それは、プロセスを中心にデータ分析を行なうと、
「データの一元管理ができない」
ところです。わかる人用に言葉を変えると、一切「正規化」されていないと言うことになります。
たとえば、このインターネットショップがみなさんの会社が管理するショップだとします。私の所属する会社が、みなさんの会社の仕入れ先としてお付き合いをするかもしれません。その場合は「仕入れ先」のエンティティに私の所属する会社データが登録・管理されることになります。
一方、私の所属する会社はみなさんの会社の商品を購入するかもしれません。
その場合、私の会社データは「顧客」エンティティにも登録・管理されることになります。その結果、先述した分析方法でデータベースを構築すると、私の会社データは２つの異なるエンティティで登録・管理されることになります。
仕入れ先としての業務は毎日取引を行なっているので、会社が移転して住所などのデータが変わることがあれば、すぐにみなさんの会社に連絡して新しいデータに変更してもらえます。
一方、顧客としてのお付き合いは頻繁にはないかもしれません。
その場合、住所などのデータが変わってもすぐには連絡せずそのままにしておく可能性があります。
結果として、みなさんのデータベースで管理されている私の会社のデータは最新の住所と移転前の住所の両方が管理されることになり、整合性の取れていないデータを管理することになるのです。
これが先述した情報システムにおける問題点の１つです。
データ中心アプローチによる問題解決
では、データ中心アプローチはどのように行なうかですが、データ中心アプローチではプロセスから考えるのではなく、先にデータから考えます。
インターネットショップを運営するためには、「商品」が必要です。
そして、商売をする以上そこには、「取引をする人」も必要です。
この「商品」と｢取引をする人」の間には、「取引をする人から、商品を仕入れる」という関係が成り立ちます。
このように、データを先に考え、１つの事象を１箇所で管理する方法が、データ中心アプローチ（DOA）です。
データを一元管理し、用途に応じて使い分けると言うことは、
・リソースの無駄遣いを減らす
・管理運用の複雑さを低減する
・シンプルになって、第三者が見てもわかりやすくなる
などの恩恵が与えられると言うことです。
もちろん、全てが正規化されればいいと言うわけでもありません。
正規化すると、大抵の場合は「性能が下がる」と言われています。
目的に応じたエンティティ数が増え、そのテーブル間の結合が増えるために参照系の処理が複雑化し、非機能要件にしわ寄せが来るためです。
ですから、データベース設計においては「まず正規化を果たし」次に「各データへのアクセス頻度を調査」したうえで、「必要に応じて部分的に正規化を崩す（非正規化）」ことが一般的なデータベース設計手法の流れとなります。
億を超えるような大規模システムであればよほど有能なDBA（データベースアドミニストレーター）をプロジェクトに就けるのは必須と言われています。
一昔前なら、月単価400～500万くらいのDBAがフリーランスで２～３プロジェクト/月担当している…なんて話もよく聞きました（今はどの程度なんでしょうね？）。
世界的に見ても、本当に優れたDBAというのは希少だからです。
データベース設計というものは、それほどまでに簡単なようで実は結構難しいのです。
多くのエンジニアは、まずプログラミング開発から担当・経験するため、日ごろプロセスから洗い出す癖がついてしまっています。その結果、データベース設計を必ず行なうとわかっていながらまずプロセスを考えてしまいます。ですから、なんとなくデータベースの設計ができている気になってはいても、本当の意味で最適化されているか？というと疑わしいものばかりができあがっていきます。
しかし、昨今常態化しているモデル開発は、生産性、保守容易性、そして品質安定のスマートなシステム開発です。低コスト化や短納期化などの要求も当たり前になってしまい、ただ単純に開発するだけでは顧客満足を満たせない時代となって軽く20年は経ったでしょうか。
大規模化が当たり前になった現在だからこそ、これがどれほど重要とされているかわからないほうがどうかしています。
まわりまわって既成製品のカスタマイズで効率化を図ろうとする開発手法もありますが、それはモデリングによるスクラッチ開発が不得意な人向けの開発手法と言っても過言ではないでしょう。
確かにスクラッチ開発と比べて安価ではあるのかもしれませんが、お客さまにとって最適解かと言うとそれは微妙です。既成製品はその性質上、お客さまのニッチな要求に応えづらい構造をしていることが多いためです。
元来、開発言語は何であれ、開発アーキテクチャとしてはOOA（オブジェクト中心アプローチ）で進めると、
無駄が少なくシンプルゆえに最も効率的で
シンプルゆえに最も品質が高く
部品の組み合わせ次第で最も汎用的となり
シンプルゆえに最も保守性が容易
となります。
しかしながら、普段からプロセスしか見ずに、別の視座で物事を見ていない人の場合はこの視座への変化が難しく、結果として難易度が高いように見られています。
ウォーターフォール開発モデルが失敗しやすいといわれているのは、何も上流・超上流工程におけるコミュニケーション不良だけが原因ではありません。お客さまのニッチな要求あるいはその要求の変更に耐えうるシンプルさや保守性を最大限考慮に入れたオブジェクト指向的な設計ができないエンジニアの能力の低さにも原因があります。
そう考えると
都度調整、都度変更、ちょっとずつ作って都度確認…
というアジャイル的な開発モデルというのは、そうしたエンジニアの能力不足を能力が低いままでもなんとか成立させようとしているだけにも映ります。期間やコストなどを含め、そのすべての負担をお客さまに押し付けるだけでエンジニアたちだけが苦労しなくて済むようにしているようにしか見えないプロジェクトも存在します。
そうなってしまうとOOA…オブジェクト中心アプローチで設計するなんて夢のまた夢です。実際、オブジェクト指向言語を活用しているエンジニアのうち、本当にオブジェクト指向を使いこなせている人はどの程度いるでしょう。
カプセル化（隠ぺい）
継承（インヘリタンス）
ポリモーフィズム（多態性）
という基本の３大要素すらまともに使いこなせていない人のほうが多いのではないでしょうか。最近見るソースではSingletonすらロクに扱えていないシステムをよく見かけます。
とはいえ、データベース周りはOOAで作成するよりもDOAで作成した方が良いケースはまだ少なくありません。
たとえば、「連携する他システムがいまだに旧態依然としていて、全体最適を考えるのであればその方が都合がよい」…などと言った場合です。
ですので、今しばらくはDOAでも良いと思いますが、まずはPOAからの卒業と、DOAに慣れることから始めるといいでしょう。
昔はよく言っていたものですが、
「情報の取り扱いを制したものは、システムを制す」
「データベースを制するものは、システムを制す」
というのは現在も変わっていないのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。