» 【第56号】業務モデル・続き

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

DRI通信56号「業務モデル・続き」2001.5.1
緑したたる美しい季節、小泉新総裁が5人の女性大臣を従えて登場しました。
不良債権と景気後退にはさまれ、これがこけたら後がない感じですから、
しっかりやってもらいたいところです。
2001年度、本格稼動の出足が今一つ悪いように感じられますが、皆様に
あってはいかがですか。
先月は「業務モデル」をテーマに書きましたが、何人かの方から貴重なご意見
をいただきました。いずれもかなり長文なので、若干抜粋しましたが、それで
もかなりのボリュームになりました。そこで今回用意した分は次号にまわし、
ご意見と、それに対する私のコメントだけで構成することにいたしました。
<堀越(TIS)>
全てそのとおりだと思いますが、ただ一点だけIOについて。
IOイラストだけでは業務モデルとしては、未完成だと思います。IOする
データ項目が完全に定義できていない状態では、業務概要に過ぎず、完全に
業務を写像するのであれば、実業務でいう記入ルールに相当する入出力デー
タの定義(どの概念ファイルの項目なのか)が必要だということです。
</堀越(TIS)>
■椿
「そのとおりだと思います。言訳がましいですが、IOイラストがあり、概
念DB構造図があるということは、概念DB構造図作成の過程において、IO
データの正体が見えているという前提で書いていました。有り難うございま
した。」


<戸田(戸田ソフト)>
まず検討しなくてはならないのは、「業務モデルを作成する意味が、現在の
SEの仕事にあるか」ということです。これは、システム・エンジニア
(SE)がビジネス・エンジニア(BE)に発展していく上で重要なポイント
だと思います。
つまり、現在のSEの場合は、あくまでも個別の情報システムの設計・
開発が目的であり、業務の改善や効率の向上は余り視野に入っていません。
そして主要な目的に必要でないことには、当然力を割きません。「実装独立な
業務モデル」が、魅力がないスローガンであるのは、そのことを実践する
効果の発生が、自分の仕事のスコープを超えているからです。
「実装独立の業務モデル」の効果は、次の何年か先のシステム改訂の機会
に主に生じますが、現在の開発では「コスト」にしか見えません。まして、
受託システム開発業者が、これに投資するインセンティブはないのです。
ですから、議論のポイントは、「業務を改善・向上させるビジネス・エン
ジニアリングは成立するのか」ということになります。もし、そのようなミッ
ションを持った技術者(多分BEと呼ばれる)が必要とされ、日常的に自社の
業務モデルの成果や効率をチェックし、改善する役目を担っているとすると、
彼らの主要な思考の道具として、DOAに準拠した業務モデルが必須のもの
として使われることになるでしょう。
しかし、現在のミッションはこのようなBE型ではなく、あくまでも旧来の
SE型であるということです。その理由は、意図した情報システムをきちんと
設計し、開発・稼動させることの負荷が極めて大きいということです。逆に
言えば、開発プラットフォームが飛躍的に改善し、システム開発が容易となり、
システム改善が頻繁に行えるようになれば、技術者のミッションがSE型から
BE型に変化し、その際に実装独立の業務モデルが不可欠の道具になるだろ
うと思われます。
もし、そのようなBE型への変化が起こると、当然、現在の業務モデルの記述
範囲に変化が起こります。なぜなら、現在の業務モデルの記述範囲がIOの所
で切れているからです。業務改善を主任務とするBEには、それでは不十分で、
リアル世界を含めた業務全体を完全に記述することが必要となります。
従って、どうしても人間が担当しているIOから先の機能の分析と記述が必要
となります。すなわち、人間が現行担当している情報処理部分を論理的に整理
し、その上でコンピュータ・プログラムに置換するという形の業務改善が、
BEの主要な解決策になるだろうと思います。そうなると、実装独立がリアリ
ティを持ってきます。何しろ、現在人間が情報処理しているプロセスやデータ
をIT側に取り込むのですから、実装手段の違いは明白です。
このような視点で現時点を見直すと、次のように言えるのではないでしょうか。
「システム開発の負荷を劇的に減じる(多分10倍以上の生産性向上)手段を
皆が先を争って開発しようとしているのだ」と。ERPも一つの選択肢であ
り、ソフトウェアの部品化、例えばJavaのEJBなどもその一つ。オブ
ジェクト指向やUMLもそのような観点で見るべきでしょう。
いずれにせよ、我々の分野の進展は、その歩みを止めることはありません。
いずれSEがBEへと進化し、その任務スコープが変化する時、実装独立な
業務モデルをハンドリングするツールが必要であることは論を待ちません。
THeRepositoryがそんなツールの標準となることを期待したいと
思います。
</戸田(戸田ソフト)>
■椿
「いつもながらの鋭いご指摘です。わたしは30年以上前から、ユーザ側から
BE的にシステムを見てきたため、どうしても作る側からの見方に理解が足
りないようです。しかしCRMでもCustomer Outが言われています。
BEが認知される日の遠くないことを期待します。」 
<油谷(SCS)>
今は価値のない?!業務モデルのコンテンツライブラリー化への夢、大いに期待い
たします。
以下に私見を述べます。
業務アプリケーションソフトウエア=業務モデル*実装手段
この式を定理とすると、CASEビジネスの失敗は、まさに実装化手段が普遍
ではなかったことに起因するように思えます。ITの進化を見越して、実装化
の独立性を確立しえなかったことによるのでしょう。
しかし、この問題解決は簡単なように思えますが、そうではないのです。事業
として考えた場合、ITの進化に合わせ莫大な投資をし続けなければ市場から締
め出されることになるからです。現在、CASEビジネスは殆ど存在しえません。
あのIBMですら出来なかったのですから・・・。
</油谷(SCS)>
■椿
「いざもの造りをするときは、その時の実装環境にしばられますので、ご意見
良く分かります。われわれもTHeRepositoryを開発するに当たっては、決断を
迫られました。しかしこのとき一番気にしたことは、リポジトリのコンテン
ツ−お客様の貴重な資産−の永続性・ポータビリティでした。ツールは作り替
えても中身は陳腐化しない、このためにリポジトリの概念構造はいかにあるべ
きか、を考えました。業務リポジトリ−これは人とIOとエンティティとデ
ータ項目が要素だから不変−とソフトウエアリポジトリを分離したのもその
ためです。予算の制約で全てはできていませんが、設計だけはプログラムレ
スまで見通した積もりです。今後ともよろしく。」
<桧垣(NEC)>
私のところでは、まず システム=人間の作業+機械の作業ととらえてシス
テムを管理しています。つまり、椿さんのいうとおり、業務モデル(業務フ
ロー)と対応手段を独立して管理してます。実装に、AP対応と人的作業の
2つがあるとし、それを一元的に管理するドキュメントを作成しています。
この二つは相似形であり、
             AP        作業
インタフェース  インタフェース仕様書  手配書+記述マニュアル
                           +シーケンス
処理仕様      機能設計書       作業手順書
履歴        ログ          手配書の履歴
状態管理      管理テーブル      管理台帳
のように成果物を管理しています。
とても大賛成です。私もNEC本体の技術力が空洞化せずに、SW開発をアウト
ソースするために、
・業務フロー
・データ構造
・インタフェースモデル
・各種ビューでのモデル図
・状態遷移図
といった主要BD成果物をきちんとレビューし、あるいは自ら概要までを設計
して渡せるようにさせています。これらを全て同じ図法で書くことで、モデル
ベース(図面ベース)のコミュニケーションを強化し、ミスを削減しています。
「ある単位の業務モデルリポジトリのコンテンツをライブラリとして貯え、
これを適宜選択・組合わせて、自社に」の部分を現在試行中です。APの部
品化、ある単位業務フローの部品化、ドキュメント要素の部品化等を考えて
います。
「このとき各社が用意すべき情報システム要員の大多数は、ITの専門家で
はなく、ビジネスエンジニアと呼ばれるべきものになり」は非常に重要だと
思っています。ホワイトカラーの生産性の悪さの原因は、システム化された
プロセスモデルと、人的にやっているプロセスモデルがまったく同じに記述で
きることが、分かっておらず、自らが携わる業務の業務フローが如何にに汚く
非効率的な業務フローになっているかを整理しないことです。業務フロー
(IPF等)を書き、プロセスモデリングを通して、機能的なモデルが書けれ
ば、コンピュータ化できなくても、かなり効率UPすることを理解させる必要
があると思います。機械化は、開発コストと人的コストを比較して判断する必
要があります。
なお現在UMLでモデルを書く人達が増えて来ましたが、今のところTH図の
方が、業務セマンティクスな部分がはっきりしていてちょっと説明すると、
素人でも理解が容易だと考えています。
</桧垣(NEC)>
■椿
「ご賛同いただきありがとうございました。特に「TH図の方が分かりやすく
素人でも理解が容易」はうれしいですね。次回のK2W勉強会(6月15日)
は要件定義は如何にあるべきかです。ぜひ良いネタをご披露ください。」