データモデルとは何ぞ？
あるお客様の要件定義作業をお手伝いしたことがある。
なぜパッケージベンダ―である我々が要件定義作業を手伝ったかとい
うと、その会社のユーザ部門が我々のパッケージを調べFit&Gapして
導入を決めたが、情シ部がシステム導入に関しては要件定義をしっか
りしないといけない。開発はW/F型で基本設計、詳細設計の各フェー
ズで経営層の承認を得ないといけない、という内規を持ち出してき、
どうせユーザ部門は要件定義などできないのだから、手伝ってやれ、
という不思議な依頼を受けたことがきっかけだ。
動機はともかく、要件定義作業（正しくは要件定義書の代筆）を手伝
うことはやぶさかではないが、情シ部からは要件定義書の目次も指定
され、その中身を網羅するのに往生した。どこかの教科書に準拠して
るのだろう。システム化の目的から、業務フロー、システム全体図か
ら、画面、データ、帳表、バッチ、連係、加えて非機能要件の運用や
信頼性などの項目まである。スクラッチ開発の設計・開発フェーズで
はない。パッケージ導入＋カスタマイズの要件定義フェーズだ。確か
にユーザ部門ではこれだけのドキュメントは書けない。おそらく情シ
部でも無理。ユーザが自分で作れない要件定義書って何だろう？と正
直思う。だからであろう。当然、今回のシステムで必要ない項目や今
決めなくてもよい項目もあるのだが、それらを省略した成果物を出す
と目次に沿ってないと差し戻されてしまう。不要である、という判断
がつかないのだ。
基本的にパッケージなので設計解はすでに出ており、すべての項目に
何か書くのは可能ではあるのだが、要件定義フェーズのドキュメント
に設計解を書くことは妥当なのかという疑問は残る。例えば画面。要
件定義の画面は基本的な構成と遷移になるが、パッケージは具体的な
画面がすでにある。わざわざ時間を逆再生するに労力と時間をかける
べきなのか、という疑問だ。
特に悩んだのがデータモデル。業務理解として使うデータモデルと、
システム構築のためのデータモデルがあることは理解している。この
間に連続性はなくてよいのだが、情シ部は要件定義でデータモデルを
作ったのだからその通りに作れと言ってくる。ということはシステム
のデータモデルを書く必要がある。しかしパッケージはMVCモデルを
採用しているため、業務に対してデータは疎な関係である。またパッ
ケージとしての性質上、MVCのM(Model)はよりプリミティブな業務
単位になっている。お客の業務（システムドメイン）にあわせてデー
タモデルを作るのではなく、汎用的なビジネスロジック（Model）を
組み合わせてお客様のシステムを実現する。当然、MVCのM(Model)
はデータと機能、状態が包含されているため、データだけの観点で表
現することは難しい。これに加えて、業務単位に用意される画面
（View）が絡んでくらななおややこしい。
クラークの三法則の一つに「十分に発達した科学技術は、魔法と見分
けがつかない」とあるが、十分に作りこまれたパッケージの構造を、
ユーザに理解していただくことは難しい。そして、それはそれで構わ
ない。今、途上国ではモバイルが爆発的に普及している。有線の様に
大規模インフラ整備が不要で、かつ彼らの生活を飛躍的に発展させる
からだ。安価で便利だから使う。それで十分だ。モバイルの仕組みを
知る必要もないし、先進国のたどった道をなぞって有線インフラを整
備する必要もない。技術力を高めることや高価なインフラをもつこと
は決して目的ではない。ツールをつかって自分たちの生活の質をあげ
ることこそが目的だ。
システムも同じ。技術は日々高度化、複雑化、大規模化を突き進んで
いる。黎明期は求めるシステムがなかったので自分たちで作るしかな
かったかもしれない。
しかし今は様々なパッケージやサービスが出てきているので、それら
が使えるのなら使う方が間違いがない。そのシステムが使えるかどう
かはユーザ自身が一番わかっている。逆に自分たちで作ろうとしても、
自分たちがもっている技術以上のものは作れないので無理をしないの
が身のためだ。モバイルは作れず黒電話をつくることになりかねない。
一点勘違いしてもらいたくないのは、ユーザ企業が情報技術を持つ必
要はない、と言っているわけではない。システム開発技術は必要はな
いと言っている。開発技術の代わりにユーザが持たないといけない技
術がある。それは変革の技術だ。情報を武器にどのようにビジネスや
業務を変えてゆくか。いわゆるDXで、これはユーザエンジニアリング
以外何物でもない。もしユーザ企業で開発を自分たちでやり、DXをベ
ンダー任せに試用としてるのであれ考え直す必要がある。逆である、
と。