» 【120号】現行画面・帳票を素材に

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【120号】現行画面・帳票を素材に

今月は119号に続いて、114号の「リレーショナルモデルの問題点」の、
「④DB設計の素材について言及がない」の対策を考えました。「現行画面・
帳票こそがDB設計の素材」の提案です。

■欧米系のトップダウン手法
「実務にとって意味のある管理対象を写像したものが概念モデルである」とい
う3層スキーマの説明を忠実に実行するためか、欧米系のデータモデリングは、
トップダウンにエンティティタイプを切り出し、次のその関係を1:nかn:
mかなど分析していくものが主流のように見受けられます。したがって、これ
をサポートするツールも、まずエンティティタイプ名と箱を記述し、これを各
種工夫した方向つきの線で結ぶものになっています。初めは属性の記載には関
心が薄かったようですが、次第にKEY、参照KEY、その他主要項目を記載
するようになってきました。しかしトップダウンデータモデリングをサポート
するツールとして、エンティティタイプ→関係線→属性の順序(注1)で指定
していくことには変わりがないようです。
(注1)
この順序は関係線をメタデータのひとつであるかのような誤解を与え、リポジ
トリ設計者に混乱を招いているように見えます。コンピュータは参照KEYの
値によって、1対n関係を把握します。関係線は見ません。トップダウン・ア
プローチでやってきた人には違和感が残るかと思いますが、関係線は人間が1
対n関係を把握し易いようにと補助的に記述したもので、箱の座標と同種の作
図のためのデータです。1対n関係は厳密には属性間に作られる関係であって、
箱の間の関係ではありません。関係線から参照KEYを生成する機能をツール
が提供するため、リソースとイベントを分離して書かないなどの弊害もあるよ
うです。
この手法は、当該アプリケーションに精通したコンサルタントがデータモデリ
ングするには、効率の良い手法と思われますが、部分的知識しか持たないユー
ザやSEにとってはかなりハードルの高い手法となります。また単にデータモ
デリング手法を身に付けただけでは、精通しないアプリケーションには、なか
なか手が出しにくいものかと思われます。すなわち、データモデリングスキル
とアプリケーション知識の両方が必要とされる手法です。
アプリケーションには一般にケースバイケースに種々のルールがありますが、
精通したコンサルタントとて、すべてを把握しているわけではありませんので、
繰り返し修正しながらモデルを完成していくことになると思われます。この場
合は最少の回数で収束するための工夫が鍵になります。しかも完成とは何か、
その判定基準が難しい。コンサルタントの主観的判断になると、カットオーバー
寸前に、抜け・洩れ・矛盾などの欠陥が発見される危険性があります。
■ 画面・帳票の実装独立仕様と照合
これを防ぐには、要件定義として画面・帳票の実装独立仕様を確定する必要が
あります。すなわちどのような項目が含まれているか、その項目の意味が確定
している必要があります。画面・帳票上の項目は概念DBの属性を人間の見え
る世界に表現したもの以上でも以下でもありませんから、画面・帳票上の項目
との照合ができていれば、概念DBは完成しているといえます。
■画面・帳票の正しい設計が鍵
したがって、画面・帳票の正しい設計が鍵になります。画面・帳票は情報シス
テムの製品ですから、製品がもれなく、正しい部品から造られていなければな
りません。自動車会社なら、必要な車種がそろっていて、正しい部品から設計
されているということです。これによって、部品倉庫に相当するDBを設計
(注2)することになります。画面・帳票の正しい設計には、その目的や位置
づけをはっきりさせなければなりません。われわれは、このために画面・帳票
をいつ誰が作り誰に渡すかを書く業務フロー図のひとつ、IPF
(Information Process Flow)チャートが非常に有効であると実感しています。
(注2)
厳密に言うと、DBは設計しません。画面・帳票を設計し、そのデータ項目を
反映するだけです。「画面・帳票は決めるもの、DBはこれから決まるもの」
と考えます。ただし物理DB設計という意味での設計はあります。概念DBと
物理DBが区別されていないと、誤解が発生します。
また、この画面・帳票を構成する部品が、適切かつ高品質である必要がありま
す。このためには今まで使い込まれて品質の安定した、既存の標準データを活
用する必要があります。そこでわれわれは、現状の概念DB構造の活用を考え
ます。これは現状の画面・帳票からほぼ個人差なく、導くことができます。ビ
ジネス環境の変化に対応するために、画面・帳票とそのデータ項目は変化しま
すが、業種の変更でもしない限り、一般に概念DB構造の90%は不変です。
この大部分の属性が新規システムの標準データとして活用できます。
新規画面・帳票設計のために必要なIPFチャートは新規のものですが、これ
もいきなり作るより、現行のIPFから作成する方が有効のように感じていま
す。ユーザにも取り付きやすいため、これを作成する過程でユーザとシステム
担当者のコミュニケーションがスムーズになり、開発関係者としての一体感が
醸成される効果は少なくありません。現状のIPFチャートおよび概念DB構造
図によって、現状が可視化され、問題点が共有されていると、以後の新規シ
ステムのための改定方針も誤解なくスムーズに決まり、正しい画面・帳票設計
から、1回で概念DB構造が収束することも少なくありません。逆に、あるプ
ロジェクトで、顧客の要望に押され、現状分析を省略したため立ち戻るところ
がなく、新規画面・帳票の修正が繰り返され長期化した痛い経験があります。
なおこのような、現状画面・帳票→現状概念DB→新規画面帳票→新規概念D
Bの進め方について、時間がかかり「得策でない」との見方もあるようです。
しかし、対象システムの性質、コンサルタントの技量にもよりますが、画面・
帳票の選択、テンプレートの活用などによって、失敗のリスクを抑え、スピー
ドアップを図ることが可能です。またアプリケーションが未熟で、「現状画面・
帳票がない」と考えられる場合があるようです。このときでもわれわれは、ユー
ザと最もコミュニケーションのとりやすい画面・帳票にこだわり、手書きのメ
モや類似システムの画面・帳票を参考にします。
■リポジトリ設計も画面・帳票から
要するに情報システム構築は組立加工製造業であって、製品を決め、これを
構成する部品を識別し標準化するのが、正しい攻め方だと考えます。この製品主
導アプローチは営業、生産といったアプリケーションだけでなく、システム開
発というアプリケーションにも適用可能であって、そのDBであるリポジトリ
設計にも適用されるべきと考えます。
すなわち、まずシステム開発工程における画面・帳票−データモデル図や業務
フロー図などの設計ドキュメント−を正しく設計し、これを素材にデータモデ
リングを行ってシステム屋のDBであるリポジトリ構造を決めるわけです。設
計ドキュメントは方法論によって決まりますから、方法論→設計ドキュメント
→リポジトリ、の順序となります。われわれはTHデータモデル図、データ定
義書、IPFチャート、画面・帳票定義書を素材にデータ分析し、これを統合
してリポジトリ構造を決めています。しかし多くの場合、素材/証拠物件のはっ
きりしない−欧米流の設計者の、主観的判断にしかよらないと思われる−リポ
ジトリ構造が提案されているように思われます。これでは正しいことの証明が
難しく、実装しテストし、さらに実用に供して初めて不具合が発見されるとい
う、長期の試行錯誤サイクルにはまりこむ心配が、残るように思われます。
(注3)
私は決してトップダウンアプローチを否定するものではありません。アプリケー
ション、参加メンバーなどプロジェクトの状況によってはトップダウンを実施
します。しかし概念DBは設計すべきものではなく、「設計すべきは画面・帳
票、概念DBはこれから決まるものである」という位置づけを忘れてはならな
い、と考えます。