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構造をここまで周到に考えることをしないままではシステム開発はうまくいかない、という厳しい指摘でもある。システム開発の難しさや責任の重大さを知って慄然とする。それがこの本の正しい読み方だ。

| | コメント (0) | トラックバック (0)

«少数精鋭でやれない場合にどうするか