DOAが普及しにくい理由を考えてみた。
DOAは人に優しく、自分には厳しい。
データモデルを作ることは、深い思慮が必要です。
使えるデータモデルを実際に設計できるようになるまでには
様々な考慮が必要である。
データモデルを設計するためには、依頼者（ユーザ）のヒヤリングをするわけだが、
依頼者の要望・意見が、構築すべきシステムの状況を表現しているわけではない。
依頼者との打ち合わせの中から構築すべきシステムのあるべき姿をあぶり出し設計していかなければならない。
様々なルールの塊を整合性を保ちながら、利用できる素材を使って構築することである。
依頼者にはコンピュータは何でもできるように思われているが、
構築する側にとっては様々な制約を伴うソフトウェア、ハードウェアの組み合わせだ。
想像されるモデルは、ひと通りではなく、浮かび上がるモデルを取捨選択、
変更しながら改良していく手間が繰り返されなければならい。
データモデルの達人は、この繰り返しを高速に広範囲に行う能力を身に着けているようである。
DOAによる、業務システムを構築するためには、
2,000時間、3年程度の学習時間が必要だと感じている。
一般的な資格試験の学習時間は次の通り。
公認会計士 3000時間、標準勉強期間は3年以上
司法書士 3000時間、標準勉強期間は3年以上
社労士 1500時間、標準勉強期間は1.5〜2年程度
これまでの経験から、システムを構築することは業務上のルールの塊を構築することだと感じでいる。
さて、業務上のルールとは何だろう。
駅の改札をイメージしてみよう。
依頼者は、改札システムを依頼しヒヤリングすると、「有効な切符を持っている人を通して欲しい。」と希望。
通常の切符、回数券、定期券などの検討できるだけの券を有効期間を考慮してシステムを構築した。
しばらくして、改善の依頼が来た。
「期間限定の切符や無条件に切符を持っていなくても、然るべき手帳を持っていれば。通して欲しい。」
またしばらくして、改善の依頼が来た。
「この特別切符は、偽物が大量に発行されたので、切符を駅員が確認して、
通すようにしますので通れないようにして欲しい。」
重ねて、「今後もルールの修正が必要だと思うのでプログラムの修正なしに変更が可能にして欲しい。」
この内容を整理すると、
基本ルールがあります。
限定列挙して特別に許可する場合があります。
限定列挙して特別に許可しない場合があります。
プログラムとデータベースを適切に組み合わせて、設計する必要があることがイメージできるのではないでしょうか。
プログラムのコーディングを直接、書き換えることは動作保障も含めて困難でしょう。
困難であればそうであるほど達成したときの自己満足感があるが、依頼者はシンプルに達成して欲しいのである。
困難の上達成した内容を、更なる変更に対応できるのでしょうか。
様々な場面で、ｙ＝2a+5、y=x^2+3a+5のような数式では対応できない業務のルールが要求されるのである。
DOAを利用するするためには、制約を効率的に組み立てていけるようなフレームワークが必要だろう。
DOAは、然るべき枠組みを用意した上で、業務上のルールをシンプルに組み立てる手法のように思える。
DOAを習得するにはかなりの時間を費やさなければならない。
少しずつ、匍匐前進していくつもりで続けることが大切なようである。
DOAの達人が、XEADやRmenuの提供を進めている。
2012-03-19月曜日に、
DAMA-JAPAN大阪分科会＆第15回関西IT勉強宴会が開催されます。
DOAに興味のある方、是非ご参加ください。
申し込みは、http://atnd.org/events/26157 から
当日お会いしましょう。
