« 少数精鋭でやれない場合にどうするか | トップページ | 省庁向けモデリングライブの効果 »

2018.07.20

DB構造の悪さが事業の足をひっぱる

 何度も大規模改修するわりに、いつまでたっても使いにくく保守しにくい。大企業を含めてそのような業務システムを抱える例がじつは少なくない。基幹システムとして事業の足を引っ張っていることが明らかなので、思い出したように刷新プロジェクトを立ち上げるのだが、使いやすさも保守性も一向に改善されない。

 じっさいには「刷新」が求められるケースはそれほど多くない。たとえばCOBOLシステムをRDBベースに置き換える場合ならば、全面刷新は必要だし、意義深い。他にも、それまで手当されていなかった業務領域をシステム化するとか、サイロ化された複数のシステムをひとつに統合するといった場面でも全面刷新やスクラッチ開発が求められる。しかし、頻度が少ないとはいえいったん全面刷新した後に、10年以内のサイクルでおおがかりな改修を繰り返しているとしたら、何らかの根深い原因があると考えていい。

 典型的な原因が「DB構造の悪さ」だ。これを手当しない限り、言語処理系を置き換えようが業者を切り替えようが状況は改善しない。では、なぜDB構造が的外れであるようなシステムがむざむざと生み出されてしまうのか。単純な話だ。関係者がDB構造の重要性を理解していないためだ。

 DB構造の軽視が引き起こす典型的な残念パターンを示そう。上述したように、COBOLシステムをRDBベースに作り替える場合、COBOLデータベースの構造をRDBに沿った論理的な形に整理し直すための手順が欠かせない。ところが、なんらかの理由でそこらへんの認識を欠いたまま、COBOLのファイル構造をそのままRDB上でエミュレートするような機械的マイグレーションが強行されることがある。緊急退避的な措置としてはアリかもしれないが、恒常的な移行手段としては絶対にやってはいけない。DB構造を形式化するための機会を生かせないだけでなく、後々まで企業活動の足をひっぱり続けることになる。

 COBOLのまま移行されていればまだマシで、膨大なアプリのコードがJavaに機械的に置き換えられたりする。そうなるとユーザ企業の制御が効かなくなる。事業活動の神経系であるはずの業務システムが、特定の開発業者にとっての経営資源と化す。業者にお伺いを立てないとちょっとした改修も出来ないし、費用についても業者の言い値を受け入れざるを得ない。業者に悪意がないとしても、結果的には寄生虫のような心地よいニッチを獲得してしまっている。

 2つ目の残念パターンが「オブジェク指向で歪められたDB」だ。上述したように、RDBを活用するには、ある種の数学的枠組みにもとづいてデータ要件を捉え直す必要がある。簡単なスキルではないが、業務システム開発に関わる技術者であれば、簿記とともに優先的に身につけるべきものだ。ところが、その種のどちらかといえば地味な技術よりも、JavaやRubyといったオブジェクト指向言語を用いた開発スキルを身につけるほうが手っ取り早いし現代的、と思われるようになった。

 それだけでも嘆かわしいのだが、オブジェクト指向におけるクラス構造が、より合理的で扱いやすいDB構造であるといった勘違いまで生まれた。その結果、主キーがすべて「id」であるような歪んだ設計スタイルが疫病のように広まっている。それはRDBをオブジェクトストアとして使うための変則的なやり方で、結果的に関数従属性や定義域制約を無視した傍迷惑なDB構造が今日もどこかで生み出されている。

 残念パターンはまだまだある。たとえば「システム刷新」と謳うわりにはDB構造を見直さないプロジェクトが後を絶たない。「今やれていることを同じようにやれるようにしてほしい」というユーザの要望を真に受けて、設計担当者が古いDB構造をそっくり真似てしまうためだ。その要望が同じDB構造を要請すると考えることがまず間違っているし、たいていはDB構造の悪さゆえにシステムを刷新したくなるのだから本末転倒である。仮にDB構造の問題が認識されていても、それを見直すためのスキルを持つ要員が手当されることがまずない(技術者ならば誰もが出来ると思われているからだ)。

 業務システムとは何か。複雑精妙な関係にある膨大なテーブル群を基礎とし、社内の様々な部門がそれを利用し、適宜交代してゆく保守担当者が参照するためのドキュメントが求められる――それが業務システムというものだ。簡単に作れるしろものではない。これを生み出す専門性の核は「DB構造を的確に捉えること」である。これを完遂できないのであれば、システムは呪いにかかったように、使いにくく、保守しにくく、バグが出やすいという三重苦に悩まされ続けることになる。

 DB構造を適切に洞察することの重要さはどんなに強調しても足りない。これを理解するための、素晴らしい新刊書、中山嘉之氏の「ITアーキテクチュアのセオリー」を紹介したい。協和発酵の伝説の情シス部長としてシステム開発を成功させ続けてきた氏のノウハウがふんだんに語られている。これはまた、広域のDB構造をここまで周到に考えることをしないままではシステム開発はうまくいかない、という厳しい指摘でもある。システム開発の難しさや責任の重大さを知って慄然とする。それがこの本の正しい読み方だ。

|

« 少数精鋭でやれない場合にどうするか | トップページ | 省庁向けモデリングライブの効果 »

コメント

ご無沙汰しております.渡辺先生が,「2つ目の残念パターン」として指摘されている事柄については,オブジェクト指向アプローチが悪い,あるいは,その表記法であるUML,特に主キー,外部キーを明記しないクラス図が悪い,というよりは,むしろ,複合主キーを楽に扱うことができない,現在流行のORマッパー製品に問題があるように井田は感じておりますが,如何でしょうか?
RubyのActiveRecordにせよ,PHPのEloquent ORMにせよ,それを使いたいがために,折角分析で得られた,論理的強度を持ったER図(あるいはクラス図)に,わざわざ複合属性でないIDを導入し,複合主キーは,非キー属性に格下げした上で,それらの組み合わせによるユニーク制約などを追加する(あるいは追加し忘れる)羽目になるのでしょう.これは,優れた概念モデルを劣った論理モデルに退行させる行為です.私は,ID方式による複合主キー方式(独立クラスにはIDを付与し,従属クラスには,独立クラスのIDを受け継いだ複合主キーを付与する方式)が一番よいと考えております.もしも,このような複合主キーをそのまま実用レベルで扱えるORM製品が登場し,それが世間に受け入れられたならば,このあたりの事情はかなり改善されるように思えるのですけれど,どうなんでしょうね.

投稿: いだあきお | 2018.07.25 08:24

井田さん

私はオブジェクト指向やUMLが悪いとは考えていません。業務システムのような「複雑精妙なDB構造を含み、異なる部門のユーザが利用し、長期にわたって保守されてゆくソフトウエア」の開発にオブジェクト指向開発は向いていない、と主張しているだけなんですよね。

それゆえ、ORマッパーが改善されるべきだとは思いません。それを使う限り、OOP言語で業務システムを記述することが是認されてしまうからです。そもそもORマッパーは、定義上「オブジェクトID」を主キーとして要請する仕掛けなので、複合主キーが扱いやすい形に改善されるとは期待できません。

業務システム開発に必要なのは、ORマッパーでもOOP言語でもなく、オブジェクト指向を隠蔽できる仕様記述形式(DSL)と、これを基礎とする開発環境(DSP)です。それらを用いることで「複合主キーを許すべきか」なんて不毛な議論も要らなくなる。オブジェクト指向開発へのこだわりがもたらすその種の無駄な「宗教論争」が、DB構造の問題をさらに見えにくくしているという困った側面もあると思いますね。

投稿: わたなべ | 2018.07.25 11:56

ご多忙中,ご回答感謝いたします.

私が,今1つよく分からないことは,渡辺さんが主張されている,「オブジェクト指向を隠蔽できる仕様記述形式(DSL)と、これを基礎とする開発環境(DSP)です」があったとして(それは,多分X-TEA ModelerやX-TEA Deiverのようなイメージのものなのだとは思いますが),それらは,対象領域の概念モデル構築時に(オブジェクト指向分析と比べて)どのような決定的な差異をもたらすのでしょうか?モデリングを行うのはツールではなくて人間であるため,このような疑問が沸いてきます.

対象業務から,要のもの,要のことを抽出し(これらはエンティティクラスになりますね),それらの間の制約を関連としてモデル化していくことは,オブジェクト指向分析でも(あるいはオブジェクト指向分析だからこそ)実施されていることですし,そのようにして構築されたモデルであれば,成果物の表記がER図であれ,クラス図であれ,それらの本質的価値は同じであるように,私には思えるのです.
(ここで,オブジェクト指向分析は,オブジェクト指向プログラミングを前提とした分析ではありません.ご存知の通り,分析とはそもそも実装独立な行為です)

因みに(蛇足ですが),オブジェクトモデルに複合IDが登場しない,というのは,よくある誤解です.たとえば,関連クラスのインスタンス(要するにリンクです)は独自のIDを持つことはできず,リンクで結ばれた両端のインスタンスのIDを組み合わせによってのみ識別される必要があります.また,そうでない場合,つまり,関連の両端のクラスのインスタンスを1つずつ特定しても,リンクが複数ある場合,は関連あるいは関連クラスとしてモデル化することは許されません(少なくともUMLの仕様ではそうなっています).なので,現状のORマッパーは,純粋なオブジェクトモデルですら,適切に関係モデルとのマッピングができない代物が多いのです.

投稿: いだあきお | 2018.07.25 17:46

井田さん

汎用的かどうかの違いによる効率の差はあると思います。オブジェクト指向は汎用的な枠組みで、業務システムだろうがゲームソフトだろうが組込系ソフトだろうが扱えます。いっぽうDSL/DSPは特定のソフトウエア領域に最適化されています。私は業務システム開発の専門家として作業効率を上げるために、業務システムに最適化されたDSL/DSPを自作して活用しているわけです。

あと、「複合主キーをふつうに扱えるORマッパー」があるとしても、相変わらずJavaやRubyの膨大なコードとつきあわなければいけないような気がします。せいぜい「オブジェクト指向プログラミングをより深く楽しむ」ことはできるかもしれませんが、コーディング量が減らないのであれば、意味があるようには思えませんねぇ。

投稿: わたなべ | 2018.07.26 20:19

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: DB構造の悪さが事業の足をひっぱる:

« 少数精鋭でやれない場合にどうするか | トップページ | 省庁向けモデリングライブの効果 »