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

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

DRI通信10号 「ビジネスモデルとソフトウエアー2」 1997.7.1
雨上がりの青空は美しく、時折太陽はかっと照りつけますが、まだ上着を着て歩
けます。あじさいは今を盛りと咲いています。皆様ご活躍の事と拝察いたします。
DRI通信9号には、「若干違うぞ」との意見もありましたが、大方は賛成のご
意見をいただきました。「ビジネスモデルは江戸時代からあった」とは穂鷹さん
の意見です。「いままでもやもやしていた問題がすっきりした」とのご意見は何
人かの人からいただきました。そこで若干調子に乗って、続けてみます。
■2頭の虎を乗りこなす
ビジネスモデルはビジネス環境の変化に応じて変えなければなりません。ソフト
ウエアはITの変化に応じて変えなければなりません。これらが一体になってい
ると変更の頻度が掛け算で発生いたします。さきに紹介した Morgenthalerさんは
、「今日のビジネスマネジャーは速い技術変化と速いビジネス変化の2頭の虎を
乗りこなさなければならない」と言っています。そこでビジネスモデルとソフト
ウエアは早晩分離されざるを得ないと予想しているわけです。


■グローバルビジネスモデルとローカルビジネスモデル
ビジネスモデル(BM)とソフトウエア(SW) は1:nですから、
           BM
┌────┘│└────┐
  SW1 SW2 SW3・・・
のように書けることになりますがもう少し詳しく考えて見ます。
ソフトは一般にBMの一部を実装したものですから、正確には営業、生産、経理
などのローカルBM(LBM) と対応します。全体をグローバルBM(GBM)と言う
ことにします。またソフトウエアは、そのリポジトリ上での表現をソフトウエア
モデル(SWM)とし、DDLやプログラムソースのようなソフトウエア環境(SWE)
従属の表現をソフトウエアオブジェクト(SWO) として区別します。すると次の
ように書けます。
         GBM
┌────┘│└────┐
LBM1 LBM2 LBM3・・・
│ │ │
SWM1 SWM2 SWM3・・・
│ │ │
SWO1 SWO2 SWO3・・・
LBMは、営業、生産、経理などのアプリケーション分野だけでなく、国内、海外、
東京、中国、などの地域対応にも生成されます。これをわれわれはコンテキスト
(CTX)と呼んでいます。したがってLBM=GBM*CTX のように、あるいはTHモデル流
に、[LBM]ー[GBM.CTX]のように書く事ができます。
■ソフトウエアモデルとソフトウエアオブジェクト
1個のLBMに対して現実には1個のSWMがつくられると思われますが、可能性と
してはソフトウエア環境(SWE)−CobolかNaturalかCANOAIDか、DB2かOracleか、
物理ファイルに冗長データを事前結合するかなど−に応じてn個のSWMがつく
られ得ます。したがってSWM=LBM*SWE、または[SWM]ー[LBM.SWE]の
ように書くことができます。これはSWEをなんらかのパラメータにより規定
すれば、LBMからSWMが自動生成できることを意味します。
SWMとSWOの対応を1:1とすべきか、1:nとすべきかは難しいところです。
これはSWEをどこまで規定し、SWMを表すリポジトリにどこまで表現するかに
よるからです。個人的には1:nとして、同じSWMに対してコンパイル方式と
インタープリーティング方式が選択できるといったモデルにできるのではと思っ
て検討しています。SWMからSWOへの変換は、さほど難しくないと思われます
(ミドルウエアSMAINによるインタープリーティング方式を検討中)。
■ビジネスモデル独立の条件
ビジネスモデルをソフトウエアから独立させた以上、これは独立した成果物とし
て認知され、商品として流通されるものでなくてはなりません。金儲けの手段と
して有利かどうかは別ですが。そのためには実装独立でありながら、正しいSWM
およびSWOを生成できるよう、ユーザ要件のすべてを記述したものとしなければ
なりません。従来のようにソフトウエアを作りながら、現場合わせでユーザ要件
を詰めるといったすすめかたはできなくなります。はじめは慣れないので何が実
装独立で何が実装従属かを判定することも難しいでしょう。
■組立図と部品表\n設計図なしに「もの」だけができてしまうことは許されませんから、完璧な設計
図および設計書を作ることになります。建築で言えば、コンセントの位置、内装
の材質や色などをすべて設計段階に決め記述することに相当します。建築の場合
は設計と工事の区別はやさしいのですが、ソフトの場合はいずれもデスクワーク
なのでまぎらわしい。DDLやCOBOLを書くのはやはり設計ではなく工事に相当す
ると考えなくてはなりません。
設計結果の表現にはあいまいさがあってはなりません。そこでエンジニアリング
の常套手段、組立図と部品表をつくることになります。組立図にはすべての部品
が表現され、その位置付けや他の部品との関係が明示されます。その部品の仕様
は部品表(定義書)に記述されることになります。
■処理の読める図
建築の場合、ドアのない部屋を作ったり、掃除のできない窓を作らないのは、そ
こでの人の動きを考えるからです。ビジネスモデルにおいては概念データベース
構造図が、建築の平面図に相当しますから、その上でデータの動き、処理を読む
必要があります。たしかにユーザの要求するデータが算出されるか、アウトプッ
トが得られるか、などをトレースすることになります。処理を読む以前の概念デ
ータベース構造図は、一般には抜けや矛盾を含み、データベースのスキーマ設計に
は使えても、後々いろりろな手直しが発生します。基本設計図を正しく作る技術
の習得に年期が要るのは、建築を初めすべてのエンジニアリングに共通のものか
と思われますが、概念データベース構造図も例外ではありません。
PLAN−DBでは、ここでSPFチャートの手法を使います。これによって概
念データベース構造図の上で結合、要約、抽出、加工、などの処理を読みます。
すると必然的にサブタイプが見えてきます。
■サブタイプを明示
一般に処理ロジックのなかには多くのIF文が含まれています。このIF文対応
の処理はサブタイプを対象にした処理ですから、処理ロジックの共用・再利用を
ねらうなら、サブタイプを明示しておかなければなりません。サブタイプを隠し
ておいて共用・再利用を叫んでも仕方がありません。処理を読むために必要なサ
ブタイプの識別・管理が重要です。逆に固有の処理ロジックを要求しないサブタ
イプはあまり管理する必要がないともいえます。
こうして作られるサブタイプの明示された処理の読める概念データベース構造図
は、複雑で作るのに時間がかかります。「DRI方式は時間が掛る」と批判する
SIベンダーもありますが、後のプログラム設計工程で、いろいろな人が重複し
て追加設計をし、しかも前工程に差し戻しを頻発させる従来型DOA方式に比較
すれば、トータルには最も時間の掛らない方式だと、われわれは考えています。
■21世紀の情報処理
こうしてビジネスモデルとソフトウエアが分離してくると、一般企業はビジネス
モデルの構築・管理に専念し、ITにかかわるソフトウエアはすべてアウトソー
スする方向が一般化すると思われます。ユーザは軽量クライアントを用いてWeb
経由ビジネスモデルにアクセスします。ビジネス環境の変化に応じて、絶えず大
規模あるいは小規模のBPRを実施し、これをビジネスモデルリポジトリに反映
します。大規模とは言ってもすでにリポジトリは構築されていますから、変更は
5%程度で済むでしょう。再構築といって大騒ぎをしていた1990年代は嘘の
ように見えるのではないでしょうか。
ソフトウエア専業者は、これを迅速にソフトウエアに変換し、安価で信頼性の高
いサービスを提供します。ソフトウエアリポジトリやハードウエアリポジトリを
構築・活用する技術は、ソフトウエア専業者にとって、迅速・安価・信頼性を実
現するための致命的核技術と認識されてくるものと思われます。
■おわりに
ちょっと長くなりすぎました。2点だけ。建築とソフトウエアとを比較しました。
ボーリング場を事務所に改装するというようなこともありますが、一般には建物
への要件はあまり変わりません。これと比較するとソフトウエアへの要件の変化
はかなり激しいものがあります。そこにわれわれの課題の難しさがあるようです。
今はソフトウエアだけがあってビジネスモデルのない特殊な時代かと思われます。
一度これを「きちんと作る」までは大変ですが、あとはこれを少しづつメンテナ
ンスすればよくなります。このきつい登り坂をスムーズにがんばって登り切りたい
ものです。
                               椿 正明
追伸
さきのDRI連絡で、文献と人名の紹介を書き落としましたので、追記します。
DATABASE Newsletter :R.Rossが2ヵ月に1回発行しているDBやIRMがらみの
専門誌。きわめて先進的でアメリカの第一線がよく分かる。年初のDB研でもし
ばしば参照させていただいている。
G.Morgenthaler :わたしも始めての人。かつてIllustraでStonebrakerらとオブジェ
クトDBMSーインフォミックスのUniversal Server の前身ーの開発をやっていたよ
うなので、一流の人と思う。
なおDRI通信不要の方、また逆にバックナンバーご希望の方はご連絡ください。