» 【第20号】動かないコンピュータの根本原因

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第20号】動かないコンピュータの根本原因

DRI通信20号 「動かないコンピュータの根本原因」1998.5.1
今年のゴールデンウイークはいかがお過ごしでしょうか。若い頃は、槍、八ヶ岳、
北岳、仙丈、甲斐駒など残雪の山々に、また50すぎてからも月山、立山、八甲
田スキーに過ごしていましたが、このところ仕事を抱え込み、仕事の合間にせい
ぜい、山うど、あしたば、みつば、よめな、クレソンなど鎌倉の山菜とりができ
る程度になってしまいました。
さて今月は技術というより、「動かないコンピュータ」のマネジメント/システ
ム戦略の問題をとりあげてみました。


昨年の記事になりますが、住友銀行「開発
を2度失敗、3回目に100億円投じて収束へ」(日経コンピュータ3月3日)、
日本高速通信「契約金額の5倍以上に膨れて、10億円を超えた。契約金額を超
えた分は、日本IBMが全額負担した」、日本石油「92年6月の時点で20億
ー30億円あればできると思っていましたが、結局3倍の費用がかかってしまい
ました」、ある大手カード会社「基幹システムの場合、当初の見積額が130億
円だったが、実際の費用は400億円に達した」(日経ビジネス11月10日)
など、またアメリカでも「C/Sシステムの16%しか納期、予算内に完成して
いない。1/3はキャンセルされている」(Database and Programming Design
7月号)など動かないコンピュータの事実が報告されています。
マルチベンダー、クライアント/サーバー、サプライチェーン指向の複雑ハイテ
ク大規模システムで、SEのスキルがついていけないなど、立派な理由もある訳
ですが、「品質・納期・コストが守れず失敗率が高い、メンテも大変、インフラ
や標準化未整備で属人的勘と経験による開発が主流」とは、自動車・電機・建築・
プラント建設と比べ「情報産業は最低の製造業」との見方もできるのではないで
しょうか。
PC、インターネットなど情報技術  コンテンツの品質
の発達は目覚ましいものがあるわけ  ↑          C
ですが、これはすべてPSTツール  |
(P:プロセス、CPUとプログラム |
 S:ストア 、DB        |          
 T:トランスファ、ネットワーク) |          ?
に関するものです。右図のように、  |          ↑  
PSTツールの機能・性能とコンテ  |A────────→B       
ンツの品質とを対比すると、前者は  └───────────→
どんどん発達しAからBまでは来た      PSTツールの機能・性能\nのですが、後者はなかなかCに行こ
うとしていないように見えます。各社DBのコンテンツの品質は10年前と比べ
てどれだけアップしているのでしょうか。勉強嫌いの若者が次々と高級車を乗り
替えるのに忙しいのと似ている、といった印象は私だけのものでしょうか。
動かないコンピュータの原因をプロジェクトマネジメントに帰する論調が多いの
ですが、それ以前に根本原因があるように、私には見えます。プロジェクトマネ
ジャーはオーケストラの指揮者にたとえられますが、演奏者は皆同じ楽譜を与え
られているのでしょうか。少しづつ違った不完全な「楽譜もどき」を見ながら演
奏するのではどんなに優秀な指揮者でも不協和音しか作れないのではないでしょ
うか。システム開発のための「楽譜」−−システムのイメージを正確に共有でき
るドキュメント−−が大きな鍵を握っているように思われます。
システムとは、相互にからみあった要素から構成されるものを言います。要素自
身十分複雑なシステムであることも多いわけですから、十分細かい要素にまで分
解し、相互関係を明示しなければなりません。分解に際しては個人差の出ないレ
ビュー可能な結果を得るための分解モデルとその表現法が必要になります。
表現法に関して、私は、「人と人とがコミュニケーションするための言語は次の
3種に大別できる」という仮説を提案しています。
(1)図面言語  :自動車の組立図、建物の平面図、プラントのP&I図など
(2)テーブル言語:部品表、機器データシートなど
(3)テキスト言語:自然言語、プログラム言語など
そしてシステム開発を除くすべての製造工業で、仕様の記述に(1)と(2)が
成功裡に使われている、(3)を使うとたちまち曖昧さや誤りが発生し混乱を招
く、と考えています。したがって「システム仕様をいかにして(1)と(2)で
表現しつくすかが課題である」と考えます。
ところで自動車・電機・建築・プラント建設などのハードウエア製品については、
工場やボーリング場をオフィスに転用する程度で、ユーザニーズはさほど変わり
ません。ところが業務アプリケーションソフトに関しては、ビジネス環境の変化
に対応して、多様な変更要求が発生します。従来のほとんどのソフトウエアは、
ビジネスモデルとITが不可分に結合して造られていますから、ビジネスモデル
の変化とITの変化の積でメンテナンス要求が発生します。データ流通の範囲が
広ければ広いほど競争力が上がるため、単一アプリから、全社、企業連合へとシ
ステムスコープが拡大するため、この積は急速に増大しつつあります。
したがって「ビジネスニーズによって変化するビジネスモデル」と「ITによっ
て変化するソフトウエア」とをはっきり分けなければ、今後やっていけなくなる
(9号、10号参照)ことは誰がみてもあきらかなはずです。ビジネスモデルに
おけるデータモデルは、本来分野横断的に、さらには企業横断的にデータ流通を
保証するものでなければなりませんが、反対にソフトウエアは小人数で短期開発
でき、カートリッジ式保守のできる小さいものが良いと言えます。
これを実現するには、まずシステム開発企画の考え方から変革してゆかなければ
なりません。次の左図のようにソフトを含めて大規模システムを考えるのでなく、
右図のようにビジネスモデルに限っては大規模に、しかしソフトはできるだけ小
さく、しかも既存システムも活かしながら、というDOA時代の「システムは全
体として見れば常時移行中」の発想に切り替えなければならないと思われます。
これはERPパッケージを活用するときも決して無視できない考え方かと思いま
すがいかがでしょう。
        工程                工程
  分析 設計 製造 運用 保守    分析 設計 製造 運用 保守 
 ┌──────────────┐  ┌───┬──────────┐
 │   大規模システム    │  │ 大 ├──────────┤
分│              │ 分│ 規 ├──────────┤
 │              │  │ 模 ├──────────┤
野├──────────────┤ 野│ B ├──────────┤
 │              │  │ M ├──────────┤
 ├──────────────┤  │   ├──────────┤
 ├──────────────┤  │   ├──────────┤
 ├──────────────┤  │   ├──────────┤  
 └──────────────┘  └───┴──────────┘  
   POA時代の発想          DOA時代の発想
追伸
DRI通信は今のところ一方通行になっています。読者からのコメントのうち
一般性のあるものについては、弊社の判断になりますが、ホームページに一定
期間載せて見たいと思います。先の七夕会のコメントも同じ扱いにいたします。
よろしく。