「ご要望の新システムのデータモデルを作ってみました。実際の業務データのうち主要な物をこのモデルにそって動かしてみましょう」
「なるほど、こうデータが出て在庫予定が分かるわけだ。あ、言い忘れていた。前倒し納品可能かどうか確認する時に発注先の担当者情報も一緒に見たい時がある」
「大丈夫です、確か発注テーブルに格納されていますので。SELECT文を直して再度表示してみますね」
「これだよ、これ。そうか、もしかして発注時の特記事項も発注テーブルからSELECT文で引っ張れるのかな」
「はい、できます」
「おお、これでいこう」
こんなやり取りをしつつ、私は業務システムを顧客と一緒に開発している。データモデルとはER（エンティティ・リレーションシップ）モデルのことで業務システムの構造を表現しやすくリレーショナルデータベースに実装できる。
業務システムを実際に使う部門の長や実務を熟知している社員などユーザーの要望を伺いつつディスカッションをして、あるべきシステムの姿を掘り出していく。見えてきたらユーザーと一緒に業務フロー図とデータモデルをつくる。このやり方を前回の本欄で紹介した。
次に新データモデルで定義したデータベーステーブルに実際の業務データを登録していく。既存システムに入っている実データを取り込む。引っ張り出した実データをSQLで加工してから入れる場合もある。Excelのシートなどで別途管理されているデータも必要があれば使う。まだ形になっていない場合はユーザーに頼んでデータを作ってもらい、それも入れる。
実データが入ったテーブルを元にユーザーと話をしながらその場でSELECT文を書き、データを抽出して見てもらう。データベースを動かすと業務で使う情報がどのような流れで変化し、別の情報として現れるかを、実データによって、しかも連続した形でユーザーに提示できる。
実データの動きにユーザーは納得する
このやり方は強力で、ITの専門家ではない部門長や現場のユーザーの方に「新システムを使って業務をこういう風に進めるのか」と体感してもらえる。画面や帳票のサンプルを見せて想像してもらうよりもはるかに説得力を持って伝えられる。
冒頭の例のように、実データの動きを把握したユーザーは様々な注文を出してくる。それをデータモデルに反映し、実データを使って再び動かす。何度も話し合っているうちに技術者は業務への理解を深め、本番直前まで設計の精度を高めてデータモデルをより深いものにしていける。データのクリーニングも同時にできてしまう。
その上、ユーザーに驚くような変化が起きる。データベースの構造を理解していくのである。やり取りの終盤になると「出荷する時に重量の確認をしたいな。商品マスターとつないで計算すれば表示できるよね」と言ってきたり、人によってはSELECT文が書けるようになってしまったりする。
