« システム化の恩恵を中小企業へ | トップページ | フィールドIDが全角日本語であることの意義 »

2014.06.20

「シンプル・イズ・ベスト」はややこしい

 データモデルは「シンプル・イズ・ベスト」ではない。データモデルを下手にシンプルにすると、他のモデル要素(業務モデルや機能モデル)が無駄に複雑化するからだ。システム仕様にはある種の「複雑さの保存則」があって、何かをシンプルにすると別の何かが複雑になる。

 その中でもとくに「機能モデル」が複雑になると、コード量が増えてシステムの保守性が顕著に悪化する。ゆえに、データモデルをシンプルにしておく戦略は不適切である。コツとしては、データモデルを精緻に正規化したうえで、その後で必要に応じてシンプルな形に調整する手順を踏むとよい。そうすることで、より多くのシステム要件をデータ構造の形で回収できるからだ。

 いちばんまずいのが、じっくり考えることをせずに最初からデータモデルをシンプルにまとめてしまおうとする姿勢だ。その典型例が「森羅万象テーブル(*1)」や「IDリクワイアド(*2)」と呼ばれるアンチパターンである。じっさいDB構造がシンプルにまとまるが、けっきょく保守性の悪いシステムが出来上がる。

 意外にも、あえて一部を複雑にすることで、システム全体の保守性が向上することがあり得るということだ。開発者はシステム全体の保守性を考えつつ、各モデル要素(データモデル、業務モデル、機能モデル)の複雑さを塩梅しなければいけない。これはシステム・アーキテクチャリングの基本なのだが、言葉で言うほど簡単な課題ではない。かくのごとく「シンプル・イズ・ベスト」の問題は単純ではない。

 これとは話がずれるのだが、最近印象的な経験をした。「CONCEPTWARE/生産管理」に続いて「CONCEPTWARE/販売管理」の修正を進めているのだが、業種別のシステムモデルについても「シンプル・イズ・ベスト」の重要さを再確認しつつ、かつ、それを実践することの難しさを痛感している。

 「CONCEPTWARE/販売管理」についてどのような修正を進めているかというと、主にロット管理に関する仕様、具体的には「ロットマスター」や「ロット別在庫」のテーブルをはずしている。ただしこれはロット管理をやめるという話ではなく、ロット管理対象商品については「外部との入庫・出庫」の際にロット№を摘要欄に記録する仕組みにするためだ。ロットマスターやロット別在庫をわざわざ保持せずとも、ロットトレースは可能なのである(関連記事「トレーサビリティを確保するための便法」)。

 このような修正を進めていて気づくことは、「新しい要素を付加するよりも、既存の要素を除くほうが手間がかかる」ということだ。

 どういうことか。「実行可能な仕様書」のエディタであるXEAD Editorで変更作業を進めているのだが、定義要素間のクロスレファレンスが監視されているため、修正に強い制約がかかる。たとえばロットマスターやロット在庫明細の定義を削除するには、これらを利用している機能定義やテーブル定義について、事前にその利用部分を除去しなければいけない。それらのテーブルはとくに多くの要素で利用されているものなので、芋づる式に修正箇所が出てくる。

 これはやっかいだが必要な制約だ。もしExcelあたりで仕様書を書けば、仕様変更にはほとんど何の制約もない。ある定義要素が他のどの要素によってどのように利用されているかについては、他の仕様書やコードをわざわざ調べない限りわからない。その調査が不十分ならば簡単にバグを作り込んでしまう。アジャイルかつ堅実に仕様変更を進めるには、変更制約が厳しいほうがずっとマシなのである。

 「既存の要素を除くほうが手間がかかる」という感覚的事実は、業種別のシステムライブラリも「シンプル・イズ・ベスト」であることを教えてくれる。つまり、どうせカスタマイズが前提なのであれば、不要な要素をはずすよりは、足りない要素を付加する形に留めておいたほうがよい。なによりも、そんなシンプルな仕様であるほうがシステムを試行・評価しやすいという大きな利点がある。

 ところが私などは経験豊富なだけに、こんな場合もあるあんな場合もあると意識してしまって、業種別のモデルシステムが必要以上に複雑になる。まあそのおかげで開発基盤の対応力を強化できたのではあるが、こんどはそのモデルシステムをわざわざシンプルな形に退行させている。そういうわけで「シンプル・イズ・ベスト」に至る道筋は、ときにひどく込み入っていたり間が抜けていたりする。


*1.森羅万象テーブル:テーブルに「レコード区分」のようなものがあって、その値毎に各フィールドの意味合いを読み替えることを前提とするテーブルのこと。原理的にはたった1個のテーブルにすべてのデータを盛り込めることからそのように呼ばれる。
*2.IDリクワイアド:全テーブルを"id"等の単一主キーとする設計方針。複合主キーにもとづく関数従属要件をプログラム側で考慮する羽目になるか、もっと悪いことにそれらのデータ要件が無視される。単純なデータ要件を扱う場合に向いている。

|

« システム化の恩恵を中小企業へ | トップページ | フィールドIDが全角日本語であることの意義 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「シンプル・イズ・ベスト」はややこしい:

« システム化の恩恵を中小企業へ | トップページ | フィールドIDが全角日本語であることの意義 »