2017.11.17

危うい「プロセス指向」が廃れない理由

 このブログで何度も説明してきたように、UIを設計してそこからDBのあり方を導くようなやり方をとれば、よほど単純なシステムでない限り開発プロジェクトは失敗する運命にある。失敗とみなされなくても、生み出されるシステムは保守性が悪くバグが出やすいという難病を抱えることになる。そんなやり方ではなく、データ要件にもとづいてDB構造をまとめ、そこからUIを導くべきだ。しかしそのスタイルはなかなか普及しない。なぜか。

■プロセス指向の危うさ

 業務システムを代表とするデータベース処理システムはさまざまな要素で出来上がっているが、その基本要素といえるものが「アプリケーション」で、そのあり方は図1のように模式化できる。典型的なアプリはUI(ユーザインタフェース)とテーブルとの入出力を伴っており、UIを介してユーザの要求を受け取ったり、処理結果をユーザに示したりする。この意味で、「UI上の要素とテーブル上の要素とをマッピングすること」がアプリの本質である。

図1.アプリケーションのあり方
20171117a

 では、これら3つの要素(UI,アプリ,テーブル)はどのような手順で設計されるのだろう。大別して2つの流儀がある。最初にUIやアプリの仕様をまとめ、これを起点としてテーブルの仕様を導くやり方(POA,プロセス指向アプローチ)。もうひとつは、最初にテーブルの仕様をまとめ、これを起点としてUIやアプリの仕様を導くやり方(DOA,データ指向アプローチ)だ。

 ちょっと考えるとどちらのスタイルでも大した違いはなさそうだが、実際の結果はまったく違ってくる。なぜか。単一のアプリだけ眺めていてもわからないのだが、複数のアプリを図2のように並べてみると事情が見えてくる。単一のアプリから見ればUIとテーブルは入出力の対象として等価値のように見えるが、複数アプリを含めた「システム」として俯瞰すれば、両者は等価値でない。テーブル群はデータベースという独特の上位構造を形成しているからだ。

図2.システムのあり方
20171117b

 DBはただのテーブルの集まりではない。多種多様なデータ項目のあり方を効果的に統合するための、さまざまな機構や工学的思想が組み込まれている。それらを無視してDBを構築することも可能だが、それらを積極活用することではじめてシステムの品質や保守性を高められる。DB構造が複雑であればあるほど、その効果は大きい。

 たとえば、アプリ上で記述されていたデータ項目の仕様をDB側に移行し一元化することで、アプリが抱えるべき仕様の情報量が減る。もともとシステム仕様の大部分は、アプリケーション側に極端に偏在していた。その一部をテーブル側に持って行くだけでも、システムの保守性は劇的に改善される。

 また、「適切に設計されたDB構造から、適切なUIや処理様式を導出できる」という重要な効果もある。データ構造を考える際に援用される数学的枠組みである「関数従属性」にもとづいて論理的なデータ構造をまとめて、そのままの形で実装できるのがDB(RDB,リレーショナルデータベース)の最大の利点だ。そして、そのような論理的なDB構造から、その上に載るデータに対してどのような処理がなされるかが「パターンの組み合わせ」として導かれる。

 これまでアプリ上にバラバラに配置されていたデータ記述をデータベース上に一元化すること、そして論理的なデータ構造としてデータストアを実現し、これを起点としてUIやアプリを設計すること――これらがDOA(データ指向アプローチ)の基本テーゼである。DOAにおいて業務の本質は、UIやアプリではなくDB構造によって示される。

 いっぽうのPOA(プロセス指向アプローチ)ではどうか。「適切に設計されたDB構造から、適切なUIや処理様式を導出できる」の逆「適切に設計されたUIや処理様式から、適切なDB構造を導出できる」のだろうか。残念ながらそうはいかない。

 ひとまとまりのUIや処理様式があって、これにもとづいて何人もの技術者にDB構造を設計させてみればわかる。適切なDB構造を構想できる技術者もいるだろうが、アプリ単位、あるいはUI単位にいちいちテーブルを用意するといった古い設計スタイルから抜け出せない技術者もいる。

 ようするにUIがどんなに緻密にまとめられていても、これを起点にして構想されるDBの形はひとつのパターンに収束しない。たいていは、その場しのぎのようなグダグダなテーブル構造が生み出され、データベースは「雑多なテーブルの物置」と化す。そして、雑然としたテーブル群をなんとか整合的に処理するための複雑怪奇なアプリの山が「エクセル方眼紙」上で仕様化され、不釣り合いなほどに洗練されたタスク管理ツールと人海戦術を駆使して実装される。

■プロセス指向が廃れない理由

 このようにPOAの危うさは明らかであるにもかかわらず、開発の現場では今でもPOAが主流である。なぜなのだろう。

 まず、POAが設計手順としてものすごく簡単だからだ。ユーザから求められるとおりにUIをまとめて、それぞれに対応するテーブル仕様をまとめる――これは誰でもやれる単純作業なので教育コストがかからない。結果的に使いにくく保守性の悪いシステムが出来上がるとしても、保守契約を結べば継続的に稼げる。ユーザ企業にはいい面の皮だが、開発ベンダーは困らない(遅かれ早かれ愛想を尽かされるだろうが)。

 2つ目の理由。POAがRDB以前の伝統的な設計手法だったからだ。RDBが普及した後でも、それが「論理的なデータ構造をそのまま実装できる便利なプラットフォーム」ではなく、ISAMのように昔風なデータストアの一種としかみなされないのであれば、POAを捨てる理由がない。そのような態勢が子々孫々と受け継がれている職場は少なくない。彼らにとってはDOAが実践可能であることさえ想像を絶する。異口同音に「UIもアプリもわかっていない状態でDB設計なんかできるはずがない」と言う。

 3つ目の理由は「オブジェクト指向言語でのスクラッチ開発」の影響である。オブジェクト指向言語を用いてシステムを手作りする場合、RDBはしばしば「オブジェクトストア」のように扱われる。すなわち、「id(オブジェクトid)」を単独主キーとし、クラスのプロパティをフィールドとするテーブルが用意され、永続化されるべきオブジェクトのプロパティ値がそこに保管される。なおクラス構造がどのように構想されるかと言うと、関数従属性のような数学的枠組みは援用されず、基本的に開発者の創造的洞察にまかされる。

 完全な新規開発であれば、この開発方針でも問題は生じないのかもしれない。しかし、ふつうは既存のDBを多かれ少なかれ扱わねばならず、クラス構造とテーブル構造のずれ(インピーダンス・ミスマッチ)に悩まされる。たとえば、クラスに対応するテーブルの主キーは常に「id」なのに、既存テーブルには複合主キーがふつうに含まれる。オブジェクト指向プログラミングの文脈で複合主キーは目ざわりなので、「複合主キーを使ってDB設計すべきではない」などといった本末転倒な思い込みさえ生まれる(*1)。ようするに、RDBを無理矢理オブジェクトストアとして使っているゆえの副作用が生じているだけの話だ。

 いずれにせよ、オブジェクト指向言語で個別案件を扱えば、クラス構造を起点としてDB構造が決まることになる。これは、アプリのあり方にもとづいてDB構造を導くという現代版POAに他ならない。DOAにおいて、DB構造を決定する際にアプリ仕様が明確になっている必要がないのとは対照的だ。もちろん、オブジェクト指向言語を用いてDOAを実践することは可能ではあるのだが、実状としてはどうしてもPOAに傾いてしまう。

 以上の理由から、DOAはいまだにマイノリティとして世を忍ぶような状況なのだが、私は悲観していない。DOAにはシステム開発を一変させるための鍵が含まれているからだ。上述したように、DB構造を決めればアプリやUIの仕様は、パターンの組み合わせとして自然に決まる。つまりDB構造から必要なアプリやUIを機械的に導出できるということで、このことの意味は極めて大きい。

 じっさい、DOAのこの特性を応用した、業務システム開発を合理化するための革新的技術がいくつも生み出されつつある。それを使えば、オブジェクト指向プログラミングのような労働集約型作業なしでシステムを手早く組み立てられる。DOAにはそういった技術を生み出す潜在能力がもともとある。他業界のエンジニアには恥ずかしくて見せられない「エクセル仕様書」をはじめとした、稚拙で非効率なシステム開発を抜本的に合理化する――そのことに真摯に取り組めば、ひとは遅かれ早かれDOAに出会うことになるだろう。


*1.このブログでの参考記事:
単独主キーでもDB設計は楽にならない
ナチュラルキーを主キーにしてはいけない

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

«図表ばかりで文章が足りない