» 【142号】 IO設計のガイド

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【142号】 IO設計のガイド

■IOがビジネスシステムの核
前号で述べた「情報システム=ビジネスシステム」とするユーザ企業の立場に
立つと、「製品=IO、部品=IOデータ」と言うことになります。

IOこそが情報システムの核となりますから、ビジネスに有効な高品質のIOを、
ビジネスの変化に応じて如何にすばやく作るかが最重要課題になってきます。
実際難航するプロジェクトのほとんどが、このIOに原因があったと報告されてい
ます。
「ビジネスに有効な」とは在庫や工数を最小にして、タイムリーに顧客ニーズ
に対応することかと思われますが、この業務設計の結果は必ずIOに表現され
てきます。したがって可視化されたIOやその連鎖は、業務仕様を共有し検討
するための、核となるドキュメントのはずです。

■IO設計のガイド
しかしIOを如何に設計すべきかについては、有効なガイドが見当たりません。
「手書きの時代の帳票を機械化すればよい」としてスタートしたこと、またI
Oはユーザに最も取付きやすいものであるため、とくにガイドの必要性が感じ
られなかったためかと思われます。
そしてGUIなどの登場とともに、「重点は非機能要件だ」として、名人芸追
求の世界に移行して行ったかに見えます。
しかし一般には分担して設計するため、同じ用語で違った意味のデータ、違っ
た用語で同じ意味を含んだデータ、ケース分けの基準の違い、例外ケースの摘
出漏れ、チェックデータや意思決定データについての考え方の相違など、種々
の原因から機能要件の詰めが甘くなり、冗長、漏れ、不整合などが発生し、プ
ロジェクト混乱の原因を作っているものと思われます。

■概念IOから考える
実装時に問題となる名人芸に、基準はふさわしくありません。そこで実装独立
の機能要件と、実装従属の非機能要件を分離して、まずは前者、実装独立の概
念IOを考えます。これによって考えるべき変数を減らし、安定度を増やし、
基準の寿命を長くします。実装従属仕様は試行錯誤の最小化を図るべく、前者
により全体整合性をとった後で検討するものとします。
全体整合性は、通常のPLAN−DB手法の適用によって可能です。すなわち
概念IO→部分図→DB統合の過程で、MDM(Master Data Management)す
なわちリソースデータの標準化が行われ、また通常見逃されやすい加工データ
(導出データ)整合性も、SPF(Schema Process Flow)チャート手法によ
る「加工データ−加工元データのトレース」によって、保証されます。これに
よって整合性のとれたDBとIOの関係「IOに必要なデータはすべて用意さ
れ、不要なデータは一切含まないDB」が作られます。
したがってこの場合注意すべきこととして、つぎの3つがあります。
(1) 適切な範囲のIOを選択すること
(2) IOの抜け漏れを制御すること
(3) 高品質のIOデータを抜け漏れなく含むこと
(1) はアプリケーション/DBのスコープを決めるものです。スコープを
大きくとりすぎると作業量が増えるだけでなく、異質なものが含まれて標準化
作業、および後々のメンテが難しくなります。これによって個別アプリケーシ
ョンDB内の問題は解決しますので、アプリ横断の問題は別途配慮します(D
RI通信127,128,131,132を参照ください)。
(2) は完璧を期す必要をいうのではなく、重要なケース分けや例外を見逃
さないための配慮です。また意思決定データ入力の場合、その元データとして
事前に何を供給すべきか、個人差があって、AsIsからは次善のものしか発
見できなかったり、意思決定データ投入後の状況が把握されないまま進行し、
問題が手遅れで発見されたりすることを排除しようというものです。
(3) も(2)と同様ですが、従来はさほどスピードが要求されなかったため、
担当者に委ねられ、IO上にはなかったイベント進捗に関するステイタスコー
ドなど補うべきデータを発見するものです。

■検討手順とIOパターン
これらをスムーズに実行するためには、すべての業務が頭の中にはいっている
スーパーマンがいない限り、次のような手順が必要になるでしょう。
(1) AsIsのIOを集める
(2) これをアプリケーションごとに分類する
(3) アプリケーション内においては発生順に並べる
(4) これをWBS(Work Breakdown Structure)ごとに分類する
(5) AsIsのIPFチャートを作成する
(6) AsIsの概念DB構造図を作る
(7) 問題点を整理しToBeの方針を決める
(8) ToBeのIPFチャートを作成する
(9) ToBeの概念IOを設計する
概念IOの設計においては、そのパターンごとに論ずるのが有効と考えます。
概念IOをどのようにパターン分けすべきかはまだ多くは論じられていません。
われわれも研究中ですが、次のような方向を考えています。
・情報システムはビジネスに有効なアウトプットを提供するためにある(イン
プットだけさせられて価値あるアウトプットが還元されないシステムはやがて
死ぬ)。したがってアウトプットから設計する。
・アウトプットは指図(給与計算書、出荷指図書など)のためか、意思決定元
データ提供のためである(注1)。意思決定には2種類ある。
 −戦略的(例):採用←部門別人数と負荷状況、販売計画←品別市場別売上推移
 −戦術的(例):商品補給量←在庫数、生産指図数量←製品および原料在庫数
・このようなアウトプットは実世界を反映するものであるが、これを実現する
ためのインプットを設計する必要がある。これはつぎの4種類に分けて考えら
れる。
 −タイプリソース:品番、品種など
 −オカレンスリソース:社員、顧客など
 −イベント:入庫、生産完成、POSなど
 −要約・断面:品別顧客別月別売上¥、品別倉庫別在庫数など(注2)
・このほか、最も厄介な意思決定データ(採用、販売計画、商品補給量、生産
指図数量など)の入力、およびシミュレーション(配管サイズ、コンプレッサー
型式など)条件の入力がある。
(注1)ここでは警告、エラーメッセージなどは除外した。
(注2)すでにインプットされたデータを用いてデータの生成を指示するだけ
であるが、実世界の反映と考えてインプットとして分類した。

■IO間の連鎖がポイント
このような分類を行うことによって、パターンごとのIO設計にかなりの指針
が提供できると考えられます。特に意思決定データ入力においては、意思決定
元データは何か、またこれをどのように提供するか、このデータ入力の結果は
どうであったかなど、IO間に関連があり、この関連のパターンをいかに捉え
るべきかなど難問が残されています。
また筆者の目下検討中の仮説ですが、IOの関連として、Plan-Do-Seeよりも
もっと詳細なPlan-Initiate-Receive&Check&Negotiate-Finalizeのような連
鎖があり、これにIOを位置づけることによって、高品質の情報システムが個
人差少なく設計できるように考えています。