» 【第9号】ビジネスモデルとソフトウエア

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

DRI通信9号 「ビジネスモデルとソフトウエア」   1997.6.1
鎌倉の山菜とりが終わって一段落したら、もう梅雨のまえぶれのような雨がふ
っています。一段落1ヵ月、これは歳をとったからでしょうか。
■ビジネスモデルとソフトウエアの分離
6号で、ビジネスモデルとソフトウエアを対比させて説明しました。かつてハー
ドウエアとソフトウエアが一緒になっていた時代がありました。今ではハードウ
エアとソフトウエアは別物として扱われ、ソフトウエアが一人歩きして売り買い
されます。しかしビジネスモデルとソフトウエア(正確にはビジネスアプリケー
ションソフトウエア)とはまだ区別する人の方が例外的です。私はこの2つは
10年以内に別物とする人が大勢を占めるのではないかと思っています。


この2つは7号にも述べたように、
  ビジネスモデル(概念、実装独立)ーDOA
  ソフトウエア (物理、実装従属)ーPOA
の対比ができますが、ビジネスモデルが決まればソフトウエアは自動生成される
か、汎用ソフトウエアによって実行できるため不要になるか、だと思われるから
です。
ここにビジネスモデルとは、おおよそTH図とIPFチャートおよびそこに示さ
れている部品(エンティティ、データ項目、業務プロセス、画面・帳票など)の
定義書の内容によって表現されるものとします。これは人間の見るイメージです
が、これを電子化したイメージがビジネスモデルリポジトリのコンテンツという
ことになります。
またソフトウエアとは、画面・帳票を作るプログラム、加工データを導出する
プログラム、物理ファイルを定義するDDLなどになります。これを電子化した
イメージはソフトウエアリポジトリにストアされます。なおこれらのソフトウエ
アを動かす環境/プラットフォーム、すなわちOS、DBMS、言語などの基本
ソフトウエアは除外して考えます。
■性質の違い
OS、DBMS、言語などの基本ソフトウエアはハードウエアの進歩を活かすた
めに変わります。アプリケーションソフトウエアは、これらが変わればその環境
で作動するために変わらざるを得ません。その環境をフルに活かした心憎いソフ
トウエアが良いソフトということになります。プログラマーは「その環境をフル
に活かすには」として工夫をし創造性や個性を発揮します。しかしその有限の寿
命を覚悟しなければなりません。
その意味では、ソフトウエアは標準化には向きません。またあまりに大きいソフ
トウエアは、厄介な問題を引き起こします。プログラマーの創造性発揮には大き
すぎるし、またすべてが同じ長さの寿命とならないため、捨てる部分と残す部分
をどうきり分けるかが難しく、保守が難しくなるからです。プログラマーの好む
適度の大きさのソフトウエアが望ましいといえるでしょう。
一方ビジネスモデルは、実務を写像したものですから、本来、部門、企業、業界
を超えた連携を考慮したものでなければなりません。とくにビジネスモデルにお
いてコミュニケーションの場を与える概念DBは、これに応えるべくオープンな
整合性を実現しなければなりません。
■ビジネスモデルとソフトウエアの関係
したがって、2つの対応は
  ビジネスモデル(BM):ソフトウエア(SW)=1:N
  概念DB       :物理DB      =1:N
  BMリポジトリ    :SWリポジトリ   =1:N
のようになります。
ビジネス環境の変化に対応して変化し、かつ広域整合性を保証すべきビジネスモ
デルと、ハードウエア環境の変化に対応して変化し、かつ局所最適化を実現すべ
きソフトウエアは分離しかつ連携すべきものと思われます。
従来は、ビジネスモデルの概念が希薄で、ソフトウエアしか念頭になく、これに
広域整合性を実現させようとして大規模化し、混乱を招いていたケースが少なく
なかったように見えます。実際AD/Cycleをはじめ、CASEツールのリポジトリ
のほとんどはSWリポジトリしか提供していなかったのではないでしょうか。
■ビジネスエンジニアリングの担当部門
ソフトウエアはシステム部門が担当しますが、ビジネスモデルはだれが担当する
のでしょうか。BPRはだれが担当してきたのでしょうか。システム部門?業務?
総務?社長室?TQC推進室?どうも一般に責任を持ってこれを受け止める部門
は用意されていなかったようです。経営トップが経営の問題(What)と認識し、
これをシステム部門に降ろしたとたんに、次元の低い(失礼!)情報技術の問題
(How)にすりかえられてしまう心配があったのではないでしょうか。
ソフトウエアエンジニアリングという言葉がありますが、どうもはかばかしい成
果があがっていません。「エンジニアリング=サイエンス+ノウハウ」と私は考
えていますが、ソフトウエアにはあまりに自由度/私意性がありすぎてサイエン
スが存在しにくい。ノウハウだけではエンジニアリングにならないのが原因では
ないかと思います。
これに反し、ビジネスモデルは、人、画面・帳票、データ項目、エンティティな
ど素材が固定的であり、きちんとしたモデル化ーサイエンスの適用ーが可能です。
これはビジネスエンジニアリングと呼ぶことができると思いますが、今後の大き
な課題ではないでしょうか。
DOA(データ中心アプローチ)とOOA(オブジェクト指向)の違いや関係に
ついて質問を受けることがあります。「DOAはビジネスモデルのための技術
であり、OOAはソフトウエアのための技術だ」と言ったら、ちょっとわかりや
すくなるように思えるのですが、いかがでしょうか。
■おわりに
今回は、従来「概念」とか「実装独立」といっていたものを、「ビジネスモデル」
として説明して見ましたがいかがでしたでしょうか。DRI通信も一方的なコミ
ュニケーションになりがちなので、Face to face でお話しできる機会を持ちたい
と思っています。9月と4月、年2回くらい、DRIのセミナールームで会費
1000円くらい、18時から21時までやってはどうかと考えています。ご意
見/注文などありましたらお寄せください。
                               椿 正明
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■