» 【135号】画面・帳票の位置づけ

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

■ものづくり屋指向とユーザ指向
画面・帳票を情報システムにどう位置づけるかは、その人がこれまで情報シス
テムにどうかかわって来たかによって、大きく違ってくるようです。

「情報システム=ハードウエア+ソフトウエア」として、ものづくりにかかわって
きた人には、画面・帳票は情報システムの枝葉、その場限りの成果物のように
見えるようです。「情報システムは、和紙と筆しか使わなかったけれど、江戸時代
だってあった。顧客台帳をベースに売掛管理が行われていた」と考えるわれわ
れは、画面・帳票こそ情報システムの製品であり、その骨格を形成するものと
考えます。前者は私には、具体的な成果物の規定されないOSやミドルウエア
設計のアプローチを、ビジネスアプリケーションにそのまま適用しているよう
に見えます。
情報システムは単体プログラムから、DBシステムになり、さらにその複合体
へと大規模化します。そこでこれを把握・理解するために、誰しも部品化を考
えます。しかしそのとき、何を部品と考えるかが、ものづくり屋とわれわれで
は−もちろん人による例外はおおありですが−大きく異なるように見えます。
ものづくり屋は、ソフトウエアの部品として、まず処理モジュールを想定する
ように見えます。汎用性の高いモジュールを用意し、これを組み合わせて種々
のニーズに応えようと考えるわけです。われわれは、製品である画面・帳票お
よびこれを構成するデータが部品の核であると考えます。この部品はユーザと
の接点になりますので、双方が理解できる粒度の安定した部品になります。こ
れを作り出すためのソフトウエアは「このデータ部品に対応して後工程で考え
ればいいではないか」と考えます。
自動車会社はいろいろな製品、車種の自動車を作りますが、なるべく少ない部
品から作ろうとします。このため設計図には部品表が明示され、極力既存の部
品を使おうと考えます。部品メーカーがどんなに良い部品を作ってきても、製
品の構成に不要な部品は発注しません。同じことをわれわれは製品である画面・
帳票について行います。このため、全画面・帳票を決めれば、DB(正確には
概念DB)を構成すべき、整合性のとれた全データ部品は決まると考えます。
素材となる画面・帳票がありますので、設計者の思いから発明されたエンティ
ティや属性によって混乱を招くことはありません。
ものづくり屋の部品、モジュールを如何に用意するかは、なかなか難しいと思
われます。
サービスは実装独立のデータ(群)ですから、これを実現する実装従属の処理
であるモジュールは、1対nで対応し、ユニークには決まりません。何らかの
基準によりブレを減らして「処理のパターン」を見抜くのでしょうが、個人差
なしは難しく、ある程度妥協の産物とならざるを得ないでしょう。モジュール
はハードウエア製品における工作機械(群)に相当する機能かと思われます。
この工作機械を組み合わせて、ニーズに対応する種々の製品を造ろうとするこ
とに対比されます。
■両者を繋ぐSOAへの期待
最近の話題SOAは、この「処理のパターン」をサービスに基づいて形成しよ
うと言う、「サービス対応にモジュールを用意するアーキテクチャ(開発環境
/体制)の構築」の薦めと思われます。サービスの単位/粒度をどう設定すべ
きかについては規定していないようですが、これは「サービスは与えられるも
の、われわれはこれに基づいて作る」という、ものづくり屋の発想から来るも
のかと思われます。そうであれば、われわれはサービス=画面・帳票と考えま
すので、SOAはわれわれの主張する画面・帳票を受け止めてくれる、実装工
程の受け皿のようにも思われます。
サービス提供の対象は、「ビジネスユーザ」と「他システム」のいずれかかと
思われますが、SOAが注目されるのは、脱孤島システムを実現するための
「他システム」の場合だと思われます。このとき、サービスの実体は、前者の
場合は画面・帳票、後者の場合はいわゆるトランザクションとなるように考え
ます。前者には使い勝手などを含む非機能要件、後者にはレコードフォーマッ
トが付随しますが、これを除く実装独立の仕様は、いわば「概念IOレコード」
として同じになります。これをベースにモジュールが用意され、ニーズの変化
に迅速対応できることは、きわめて望ましい展開と思われます。
■中核部品としての「概念IOレコード」
この「概念IOレコード」には、いわゆるヘッダー・ディテールなどといった、
やや複雑な構造も含まれますが、ユーザの理解する、粒度の安定したサービス
/部品が識別できます。これを構成する最小の部品は、たとえば受注レコード
における受注顧客番号、届先番号など、いわば「概念IOデータ」と呼べるユー
ザの認識する最小かつ最多の部品になります。これはあるエンティティの属性
が、ユーザに見える形で媒体上に表現されたものです。このIOと、構成する
エンティティおよび属性との関係を、われわれは概念DB構造部分図として明
示します。これが情報システムの核となる部品であり、これを積み上げること
によって、データ系および処理系の構造が記述されます。
このエンティティと属性、および「概念IOレコード」と「概念IOデータ」
を繋ぐために処理モジュールが存在するわけですが、当初われわれはこの機能
をSPF(Schema Process Flow)チャートで記述するにとどめ、ものづくり屋が
重視するモジュールへの展開は実装工程の課題として残します。
したがって、われわれはモジュール切り出しの基準となるサービス−「概念I
Oレコード」と「概念IOデータ」−そのものを部品と考え、ユーザの情報要
求を満たすべくそのデータ標準化を指向することになります。モジュール以前
のサービスの標準化を優先するわけです。データ標準化とは、処理プロセスが
Pier to Pierで個別に通信するのでなく、DB通信場経由Hub and Spokeによ
り通信することによって、相互独立性を獲得するための環境作りであり、その
結果は、リポジトリ(レコードフォーマットなど)およびリソースDB(コー
ド値)に記述されます。
この本質は1980年代からのDOA/データ中心アプローチに他なりませんが、
個別アプリケーション専用の物理DBを中心とするものではなく、全社を視野
に入れて個別アプリケーションDBを連携する実装独立DB複合体を前提とす
る、1歩前進したDOAということができます。
■高品質の画面・帳票を得るには
このように画面・帳票を核部品とする場合、その品質が課題となります。IT
の進歩とともに、画面が複雑化し、難しくなってきたわけですが、ビジネス要
求の本質は変わらないはずです。手作業やバッチ処理の時代ならどう考えるか、
ビジネスシステム/ビジネステクノロジーの観点から考えれば解が得られるも
のと思われます。RFIDなどの登場はむしろ技巧を要せず、システム構成を
やさしくするものと思われます。
画面・帳票はユーザ要件から決まるわけですが、これがビジネスの目的・ねら
いとどのように結びついているかを忘れてはなりません。これによって「これ
までこうしていたから」と言う安易なユーザ要件を外すことができます。また
「ビジネスにこのような情報が必要だからこのデータを入力する」といった情
報誘導型の攻め方が必要です。
ユーザと設計者が、この議論をスムーズに進めるためには、その画面・帳票の
使われる局面を見える化することが有効です。画面・帳票をいつ誰が作り、こ
れを誰がいつ使うかを極力客観的に図示するわけです。このために業務フロー
図を用いるわけですが、われわれはIPF(Information Process Flow)チャー
トを活用しています。こうしてもし正しいユーザの情報要求を満たす画面・帳
票が設計できたならば、データモデリングにより、整合性・標準化を確保し、
これをベースにモジュール設計を行うことになります。
この手法においては、正しい製品=画面・帳票をいかに効率よく設計するか、
またその過程を通して関係者の人材育成をいかに進めるかが、最大の課題にな
ります。一般には、関係者間のコミュニケーションをスムーズにするのが有効
ですから、現行システムの分析を通じて、そのデータモデル図および業務フロー
図を作成し、その現状および問題点の共有を図ることが、われわれの定番となっ
ています。何といっても現行システム、特にその画面帳票がユーザとシステム
関係者がコミュニケーションを取るのに一番有効な題材だからです。
■トップダウンアプローチの特徴
このように、われわれは画面・帳票を部品の基礎としますので、分析・設計素
材として現行画面・帳票の収集が不可欠のものとなりますが、これをあまり重
視しない手法も見られます。もちろん業務の概要を理解するために現状画面帳
票も参照するわけですが、むしろ物理DB構造やシステムドキュメントをベー
スにトップダウンにリレーショナルテーブルやモジュールを設計しようと言う
わけです。スキルの高いリーダーがいて、その手に負える大きさのシステムの
場合は効率的に進められますが、そうでない場合は悲惨な結果となる心配があ
ります。このような場合のシステムの中核部品は、画面・帳票よりは1歩実装
に近い、ものづくり屋寄りのリレーショナルテーブル、ドメイン、モジュール
などのように思われます。
(注)SOAにおけるサービスの粒度を画面・帳票として考えました。もっと
拡張できるかとも思いますが、アーキテクチャを考える上では、十分であり、
また分かり易いのではないかと思います。