» 【161号】「DOAは永遠です」

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【161号】「DOAは永遠です」

■情報システム
情報システムは情報処理プロセスP1、P2、・・・のネットワークから構成され
ています。江戸時代には、プロセスはすべて人間が担当し、インターフェースの
メッセージは音声か紙の上に表現されていました。音声ならば蜜結合、紙ならば疎
結合になります。現代でも販売実績(要約データ)を見て、販売単価や発注量(意
思決定データ)を決め、また棚卸しをして棚残(観測データ)を修正したりなど、
人間のプロセスは残っていますが、多くのプロセスがコンピュータ・プログラムに
よって行われています。したがって、多くの電子化されたメッセージが飛び交うわ
けですが、人間が介在するところには、画面や紙が登場します。

■POAとDOA
プロセスは他のプロセスからインプットメッセージを受け取り、アウトプットメッ
セージを生成して他のプロセスに渡します。プロセス設計担当者が、「そのアウト
プットを誰(と誰)がどのような形式で必要としているかよりも、プロセスの機能
・性能を満たすことを優先して考える」というのが、POAということになります。
POAの場合は、一般にメッセージの形式は「送信側と受信側の2者間で決めれば
よい」として取り組まれ、プロセスが多くなると、そのネットワークはスパゲッ
ティ状を呈し、後々の保守に問題を残すことが多くなります。

これを避けるために、関与するプロセス間で送受信されるメッセージの通信場(D
H:Data Hub)を先行して設計し、これを前提にプロセス設計を行うのがDOAで
す。DH設計の素材はプロセス間メッセージですが、この実装独立の仕様はプロセ
スを設計しなくても、プロセスを識別した段階で確定可能なはずです。一般には現
行の画面・帳票が使われます。

POAでは送受信メッセージは「流れるもの」として実感されます。DOAでは送
受信メッセージは「DHに鎮座するもの」として実感されます。DHを太陽とすれ
ばプロセスは惑星になります。したがって、POAの設計者は自己中心的にプロセ
スからデータを見る天動説、一方DOAは太陽を中心に考える地動説の立場に立っ
ているかに見えます。DOAは他のプロセスの存在を意識しており、より広い世界
観を持っていると言えるでしょう。これによって逆に「送信は所定のメッセージを
DHに届けさえすれば良い、受信者は自分の都合のよいタイミングで、DHを検索
すればメッセージを受信できる(ただし単純検索を除く)」という簡素な通信が実
現できることになります。

インプットを与えられて、プロセスを設計し、アウトプットを考えるのは、自然な
順序なのでやさしい。しかし、「インプットから所定のアウトプットを得るための
プロセスは何か」を考えるのは難しい。逆算で、人間の性に反するからです。昔将
棋の故原田八段が3手の読みを指導していました。「こう指す、するとこう来る、
そこでこう指す、これで棋力がアップするよ」と言っていました。DOAは、先読
み、試行錯誤、逆算を要求するので、ちょっと高級な思考と言えます。

■インターフェースを素材にDHを設計
物理学は、分子、原子、素粒子と要素還元法によって細分化し物性を究明して行き
ました。情報システムでも、たとえば「資材購買を購買計画・購買依頼・見積発注
・・・と分解し、さらに見積発注を発注先決定・発注と言うように要素還元的に分
解し、これをWBSとして表現する」などはよく行われるわけですが、「分解した
プロセス名は記述するが、その間のインターフェースは記述しない」といったケー
スが多々見られます。これは、DH未確定のままプロセスの設計を行い、スパゲッ
ティ構造を招来するPOAの典型的な進め方かと思われます。国を作ったが、国境
を決めなかったので、後でトラブルが発生するのと良く似ています。

DHを設計するには、①素材メッセージを収集する、 ②抽象化を行って意味と粒
度を把握する、③矛盾を調整し整合性をとる、などの作業を行うことになりますが、
多くの場合③には政治が必要になります。このため企業内は可能でも、企業間は難
しい。DHは、概念DB構造図として表現されますので、成果物として、まず
「メッセージ対応のイベント系エンティティタイプおよびその属性、さらにこれら
属性を定義するリソースエンティティタイプおよびその属性」の仕様が確定するこ
とになります。

リソースは、社員・顧客・商品などの経営資源を疑義なく表現するものであり、イ
ベントは受発注・生産などにおいて、これらリソースがどう関与しているか、ビジ
ネスの枠組みを表現しています。これをTHデータモデルでは、たとえば
 [品#]-(品名、単価、重量、・・・)
 [受注#]-(顧客#*、(顧客名)、受注品#*、(品名)、(単価)、受注
単価!、数量、
<受注金額>、届先住所、・・・)

(注)[A]-(B)はAがKEYであり、BがAの従属属性であることを示す。
*は
参照KEYであること、従属項目を囲む()は冗長属性、<>は加工属性、また!
は意思決定データを示す。

のように記述します。このビジネスの枠組みを規定する、メタデータと呼ばれる、
エンティティや属性は、情報システムの根幹を規定する、企業レベルの貴重なデー
タです。リソースを識別するコード体系と並んで、全社データ流通を実現する鍵と
なるものであるため、私は「システム広辞苑」と呼んでいます。

■DOA推進の障害
しかしこのメタデータ管理は、開発担当者任せなど、ほとんどの企業においてうま
く行っておらず、DOA推進の障害となっています。その理由としては、まず次の
ようなものが考えられます。
 ・情報流通を実現するために全社レベルで共有管理すべき企業資産であるとの
認識が、マネジメントにも担当者にも欠けている。その理由は、マネジメントは情
報問題は担当者に任せたつもり、一方担当者は個別アプリの開発しか頼まれていな
いと考える。
 ・メタデータに関する知識は、開発時OJT的に経験しないと身につきにくい
高度な内容を含み、プログラムメンテと言った、他の業務と違って新入社員には引
き継げない。
 ・習得した人は、視野が広がり的確な判断ができるため、開発に動員され、保
守段階になると担当者が不在となってしまう。
 ・メタデータ管理は、縁の下の仕事で地味で変化が少なく、「成功するのが当
たり前、失敗したら怒られる」。またマネジメントの評価も低いので、担当者は続
けたいと思わない。
 ・メタデータモデルは、まだ情報システムの全局面をサポートしておらず、未
完成の部分を残している。

しかし、それ以前に「情報システム=ソフトウエアシステム」の発想から、
 ・可視化は目的ではない、要はユーザが使えるプログラムを作ることだ
 ・パッケージ依存やSIer丸投げで済ましても、安ければよい
 ・レガシーやパッケージを繋ぐときスパゲッティが出来るのは仕方のない必要悪だ
 ・ソフトには寿命があり、5-10年ごとに作り直すもの、問題は開発プロジェクト
  の中で解決するのが基本
と考えるスタンスが根本原因になっているケースも多々あると考えられます。

■DOA推進の技術的対策
このようにDOAへの障害は種々あるわけですが、「情報システムは商品・サービ
スにおける競争力を支援すべきもの」と考える企業においては、その根幹はDOA
によって構築すべきであり、技術的には次のような対策が有効と、筆者は考えます。
 ①DOAの可視化コンセプトを身につけるために、IPFチャートを作る
 ②プログラミングレスを実現する
 ③データ管理のSaaS化を行う
 ④メタデータの標準を確立する

①で可視化の突破口として、IPFチャートを選んだのは、分かりやすさから
です。データモデル図は初心者にとって若干とっつきにくいのですが、IPF
チャートは多少の規則はあるものの、抵抗感を持つ人はほとんどありません。素材
はデータモデルと同様、画面・帳票サンプルです。特に新入社員教育の中に取り込
む案が面白いと考えます。先輩が会社業務の説明を行う代わりに、新入社員を2-
4人のチームに分け、これにアプリ対応の数枚の画面・帳票を与え、若干の説明を
してIPFチャートを作らせます。レビュー後発表会を開きます。これによって、
新入社員は会社業務を広く深く理解し、同時にこれまで暗黙知だった業務フロー図
が整備されます。新入社員は情報部門およびユーザ部門に配属になるでしょうが、
以後お互いIPFチャートを共有して効率的なコミュニケーションが行われるもの
と期待されます。またIPFチャートは、業務処理よりその成果物であるIOを優
先して認識し、かつ発生した情報はすべて一旦DBにストアすべきとしていますの
で、知らず知らずに「DOAアーキテクチャが当然」という世界観を身につけるよ
うになる-この点はBPMNなどを大きく上回る-と期待されます。

②は、当初からのDOAのターゲットです。まだ改良の余地は残されています
が、丹青ビジネス社ほか、種々のアプローチが成功し始めています。将来ともプロ
グラミングの名人に依存すべきものが若干残るでしょうが、大部分の通常の画面・
帳票対応のプログラムは自動化できるでしょう。そのときの保守はメタデータだけ
となるはずですから、保守は大幅に合理化されると考えます。

③は定型的なメタデータ管理をアウトソースするものです。コアとなるビジネ
スモデルの変更は自社で握らなければなりませんが、機械的な整合性管理など、大
部分のメタデータ管理は外部依存が可能になると思われます。

④メタデータの構造の最終形は、まだ見えていないと考えられます。メタデー
タのカバーすべき範囲が確定していませんし、その設計素材が確定していません。
素材に実装従属の要素が混入すると、IT進化により揺れ動き、収拾がつかなくな
る恐れがあります。したがって安易な多数決や政治決着でない、メタデータの標準
の確立が望まれます。

■ DOA推進のマネジメント
しかしDOAの成功に欠かせないのは、DOAのマネジメントだと考えます。今多
くの企業における情報システム問題として
 ・保守に時間と費用がかかる
 ・保守に人がとられて新規案件にかかれない
 ・システムは暗黙知となり、かつSILOシステム間にスパゲッティ通信があ
り、誰も全貌がつかめない
などが挙げられています。その第一の原因は、ユーザ部門の要求に基づいて、戦略
計画不在のまま、個別アプリを構築してきたからだと考えます。この責任は、所定
の機能を所定の期間と予算で開発した、ユーザ部門にも、開発担当責任者にも問う
ことが出来ません。本来はシステム部長やCIOの責任ともいえますが、多くのS
ILOシステムは着任以前から稼動していたというケースも多いでしょう。した
がって、「従来の延長線上では解決しない、これからどのような責任体制で臨むべ
きか」が問われていると考えます。

そこで筆者は、開発プロジェクト以前の、会社における情報システムの位置づけ・
コンセプト・体制の見直しを提案したい。今までの体制は、定期的にソフトウエア
の再構築を繰り返すPOA向けの体制だったのではないか。メタデータやリソース
データは勿論、イベント系のデータ構造も、再構築ごとにスクラッチするようなも
のではありません。業務ルールの変更やM&Aに対応して変更が発生するといって
もプログラムとは雲泥の差です。DOAの成果物を、プロジェクト単位のPOA的
ライフサイクル感覚で扱うのはミスマッチではないでしょうか。またプロジェクト
単位で問題解決を図るSIerの体質にもフィットしません。DOAのライフサイ
クルに合ったコンセプト・体制を指向すべきと考えます。またDOAではシステム
スコープをアプリ横断に、時として企業横断に拡大して取り組むため、標準の異な
るアプリシステム間をつなぐ-POA時代には、SILOを大きくしてスパゲッ
ティの複雑度を下げるなど、本格的には取り組まれていない-問題を解決しなけれ
ばなりません。

したがって、次のようなソフト開発以前の、TOP、LOB(Line of Business)、
一般社員、DMO(Data Management Office)の役割について、見直す必要があり
ます。
 ・TOP :リソース(人・組織、設備、顧客、商品・サービス等)の先行手
配、および業務モデル設計(誰がどの情報を扱うか)
 ・LOB :既存リソース(在庫、資金等)の有効稼動管理(SCMを含む)
 ・一般社員:日常オペレーション
 ・DMO :業務モデル把握管理

今までTOPは、情報問題はシステム部門に一任してきた企業が多かったでしょう。
そのため個別アプリのSILOができて、後追いで対応するためにスパゲッティ化
が進んだと見られます。やはり全社情報戦略計画には、TOP/CIOの関与が必
須のはずです。DMOは業務モデルを分かりやすく可視化して、TOP/CIOを
サポートする必要があります。こうして経営と情報のタイアップを図るのが、今後
のあり方ではないでしょうか。

■DOAは死なず
「DOAは古い」、「OOだ」、「SOAだ」と流行は変わりますが、いずれも定
期的にソフトを作り直すPOAの世界観を前提としたものに見えます。ユーザの情
報要求である画面・帳票、これに含まれたデータを、実装独立の世界で正しく位置
づけ、これをベースに情報システムを構築・運用するDOAがどうして古くなるの
でしょうか。私は、「DOAは死ぬはずがない、DRIはこれを追求して最先端を
行く限り、当初理解する顧客は限られるとしても生き残れる。逆に確実な短期のR
OIを指向して、多くの顧客の理解する流行技術に目がいくと、大手との体力勝負
になって危ない」と考えていました。最後に申し上げたい、「DOAはジャイアン
ツに劣らず永遠です」と。

以上で、13年続けたDRI通信も、終わりとします。長らくありがとうございま
した。

追伸:
先の160号で述べましたように、私の今年の課題は、概念リポジトリの決定版
(?)を本にすることですが、フリーで動けますので、認知症が始まるまで、日本
のDOA推進のための若干の活動は可能だと考えています。DRIの事業にマイナ
スとならない範囲で、時間は限られますが、DOA推進のためのマネジメントや技
術に関する相談・講演などでお役に立てればと思います。国から年金が出ています
から、交通費・宿泊費のみで対応できます。メール等で遠慮なく、mtsubaki@kce.
biglobe.ne.jpまでご連絡ください。

なお、皆様には宿題をお願いしたいと思っています。私はDOA手法の開発にあた
り、次の7つの仮説-他のDOAでは必ずしも前提としていない-を置きましたが、
検証不十分のものがあると思います。「おかしい、こう修正すべきだ」などがあり
ましたらお知らせください。

7つの仮説
①ビジネスは6業種に分類できる。
建設、生産財製造、消費財製造、小売、卸、サービス
②企業のビジネスシステムは、リソースを使う基幹系と、これを作るリソース整備
系に大別できる
③処理システムは5階層から成る
 業務ドメイン-システム-業務プロセス-業務/IO-IOデータ
④3階層通信場
 E1(個別アプリ)-E2(アプリ横断)-E3(企業横断)
⑤エンティティタイプ5種類(大分類)
 リソース、在庫型、断面、要約、イベント
⑥データ機能コードと加工データ13種類
 K、R、(加工)W、T、S、I、G、X、D、A、C、B、E、V、R
⑦SPF操作子11種類
 P、J、G、S、E、M、H、V、U、R、C