» 【第55号】業務モデル

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

DRI通信55号「業務モデル」2001.4.1
株価も為替も不穏な動きの中、しかし4月を迎えて、桜は満開、いよいよ21
世紀本番がはじまりました。ITは堅調という話しもありますが、皆様のと
ころはいかがですか。
広域のシステムの接続は、多くの関係者のからむ標準化、したがって技術
というよりマネジメント問題・政治問題・人間問題になり、時間が掛かり
ます。ビジネスとしてはなかなか難しい。しかし誰かがやらなければなり
ません。21世紀の課題に向かって挑戦してまいります。皆様方のご支援
よろしくお願いします。
前回は「データ流通の条件」を考察しました。戸田コンサルタントから「要
するにシンタックス的条件とセマンティカルな条件と二つあり、後者は奥が
深い。・・データ流通の条件がIT技術的な面だけでなく、社会経済的イン
フラの整備に大きなポイントがあることは、もっと強調されてしかるべき」
と言ったコメントを頂きました。コメントは大歓迎、短いものでも気軽にど
しどしお願いします。
■業務モデル
さて今月は「業務モデル」−この中に「プロセスモデル」と「データモデル」
が含まれる−を考察しましょう。かつてはこれを「ビジネスモデル」と言って
いましたが、最近これは「収益モデル」と言った意味で使われることが多くな
り、誤解を招くので、原則として「業務モデル」と言うことにしています。


用語「業務モデル」として敢えて表現したいのは、実装独立ということです。
特にデータモデルについてですが、英語では”Conceptual Model” ということ
になります。これを翻訳すると概念モデルになりますが、概要モデルと誤解
する人が出るので、その意味でも最近はなるべく「業務モデル」と言うことに
しています。
■実装独立
実装独立とは、コンピュータか手書きか、電話かFAXかEMAILかなど
と言った実現手段に独立と言う意味です。たとえば受注という業務では、顧
客、商品、数量、納期、金額などのデータが扱われますが、これは「業務モ
デル」としては江戸時代も100年後も変わらない。変わるのは、「紙と筆
と飛脚からコンピュータやインターネットへ」など、実現手段だけだという
風に、ビジネスの目的・本質を捉えた考え方をしようというわけです。
その二大メリットは
・変化が少ないので、モデルが陳腐化しにくい
・専門的なITが含まれないので、ユーザにとって分かりやすい
ことかと思われます。
■業務アプリケーションソフトウエア
業務アプリケーションソフトウエアは、この「業務モデル」をそのときの実
装手段を用いて実現したもの、すなわち
業務アプリケーションソフトウエア=業務モデル*実装手段
のように書けるかと思います。従来のドキュメントは、ほとんどの場合、こ
の二つを渾然一体で書いていました。このため担当者以外には分かり難く、
また陳腐化・不良資産化しやすかったと言えます。ドキュメントは電子化さ
れ、リポジトリとして記録される場合もありましたが、業務モデルと実現手
段の分離はあまり進まず、陳腐化しやすく、また図としての出力や整合性管
理支援の不備などもあって、今一つ効果を発揮できませんでした。
なぜ「業務モデル」と実装手段が分離できなかったのか。その理由は
・ソフトは動いてなんぼの世界だ「要はソフトを作ること」、業務モデルに
は価値がない
・ソフトの仕様なら書けるが、業務モデルは書き方が分からない
・ユーザ要件は、プロトタイプを作って確認しないと固まらない
など、もっともなものが多いかと思われます。しかしそれによって、時が経
ち、変更が重なり、人が交代してシステムは次第に暗黙知の塊になって行っ
たように思われます。
■業務モデルの構成要素
さてその業務モデルの構成要素とは何でしょうか。まずユーザに直接見える
ものとして、「人」と「IO」(いずれも広義)を挙げることができます。
「人」とは顧客や受注担当など業務に関わる人や組織で、コンピュータ/D
Bもこの一つとして扱います。[IO」とは、いまは一般的には画面・帳票
ですが、手書き伝票、電話メモ、EDIなどの電文を含めます。いずれも指
図や計画のためのドキュメント(広義)であり、「いくつかのデータを含む」
のが特徴です。「『IOがデータの塊である』という論理的側面のみを見る限
り100年経っても変わらない、だから安定しているのだ」と考えることが
できます。この「人」と「IO」は、いわばクライアント側の要素ということ
ができます。
「IO」は情報システムの製品として位置づけられますが、「IO」を規定し
ただけでは、これがどのようなデータ/部品から作られているかは不明です。
「IO」に含まれるデータとして、たとえば顧客コード、顧客名、届先コー
ド、届先名、帳合い先コード、などが挙げられますが、これらは必ずしも独
立でなく、何らかの関係・制約がある場合があり、逆に二つのシステムで、
おなじ顧客コードというデータ項目が少し違った意味で使われているといっ
たこともあります。また、「IO」上のデータが、別のいくつかのデータか
ら作られた、言わば中間部品(加工データ)であったりすることもあります。
これらの関係を明らかにするためには、原材料である部品としてのデータを、
ちょうど部品倉庫の棚番と置き場を決めるように、識別整理する必要があり
ます。棚番をエンティティタイプとするなら、置き場がデータ項目に相当す
ることになります。また倉庫はデータベースに対応するものとなります。こ
の三つも、「100年経ってどのようにITが進歩しても変わらない要素」
と言えます。したがってデータベース、エンティティ、データ項目を、業
務モデルのサーバー側の要素と考えることができます。
■業務モデルの表現
これらの要素は、業務モデルにおいてどのように表現されるべきでしょうか。
これはなかなか証明できかねるテーマですが、われわれは30年近い実践と
研究の結果、次の4種のドキュメント−要件定義基本4ドキュメント−によ
って表現できるとの結論を出しました。
・IPF(Information Process Flow)チャート
・IOイラスト
・概念DB構造図
・データ定義書(加工データに対するSPF(Schema Process Flow)チャー
トを含む)
前の二つがクライアント側の個別ニーズを、後の二つがサーバー側の共用資
源を表現するものになります。
このような業務モデルに関するドキュメントのメリットは何でしょうか。
われわれは次のようなものと考えます。
・開発時、ユーザと正確かつ効率的なコミュニケーションを行うことができる
・ユーザは業務モデルまでは把握できるので、丸投げ手配師にならずにアウ
トソーシングできる
・保守時一旦ここまで立ち戻って改訂を行うことから仕様の劣化が防げるの
で、開発と保守の差を無くし、大規模再構築の必要を無くせる
■THeRepositoryとそのねらい
そこでわれわれは、この要件定義基本4ドキュメントをベースにメタデータ
に関するデータモデリングを行い、結果として昨年秋発表したTHeRepository
の構造を決めることになりました。従来のリポジトリのように実装手段を含む
構造ですと、ITの進化によって、そのコンテンツが陳腐化しますが、業務
モデルの範囲に限定しておけば、陳腐化を免れることができます。ソフトの
世界との接点は本来ソフトウエアリポジトリ側において記述すべきですが、
当面「これを持たないと不便」とのことから、最小限の物理ファイル構\n造との関係をTHeRepositoryに用意することにいたしました。従来のリポ
ジトリ・ツールは業務モデルかソフトウエアかどちらかしか記述できず、
両者を記述し関係付けるコンセプトを持っていなかったように思われます。
われわれの夢は、今は価値がないとされる業務モデルのコンテンツが流通し、
市場価値を持つようになることです。ある単位の業務モデルリポジトリのコ
ンテンツをライブラリとして貯え、これを適宜選択・組合わせて、自社に合
ったデータモデルを構築することができれば、「パッケージに身体を合わせ
ろ」と言った妥協を大幅になくせるものと考えます。これをアメリカより、
1年でも2年でも早く実現するのです。そうすれば90年代に付けられた差
を一気に逆転する可能性すらあるように思うのです。
またTHeRepositoryは、ソフトウエア部品を直接管理するものではありませ
んが、保守の合理化にも大いに役立つものと考えています(若干PR気味です
みません)。保守案件も先ずはユーザ要件として与えられるはずです。この
とき現状の業務モデルが記述されていれば、これとの対比により、どこが変
わるかがはっきりし、ひもづけ情報によりソフトのどこに手を入れるべきか
が正確につきとめられます。現在は保守担当者が、暗黙知に頼って、ソフト
のどこに影響があるか当たりを付け、ソフトを解読して逆向きにそれがどの
ような業務を実装しているか−これは開発に携わった、業務が頭にある要員
には可能でも、新規に保守担当として配属された要員には非常に厳しい−を
判断しながら、試行錯誤的に調べなければならず、時間がかかりかつミスも
発生しやすくなっているのではないでしょうか。
われわれは、21世紀の比較的早い段階に、ユーザ企業の多くは、自社でコ
ンピュータを持ち運用する形態から、これらをアウトソーサーに委託し、イ
ンターネット経由自社データベースを参照・更新するようになるものと考え
ます。そしてこのとき自社の業務モデルを十分把握・管理して行うか、ある
いは丸投げ空洞化して行うかによって、企業競争力に大きな差が生ずるもの
と考えます。このとき各社が用意すべき情報システム要員の大多数は、IT
の専門家ではなく、ビジネスエンジニアと呼ばれるべきものになり、これを
いかに用意するかが、今後の重要な経営課題になると、われわれは考えてい
るのですがいかがでしょうか。