» 【第40号】デフォルメが過ぎているのでしょうか

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第40号】デフォルメが過ぎているのでしょうか

DRI通信40号「デフォルメが過ぎているのでしょうか」 2000.1.1
皆様あけましておめでとうございます。
Y2Kとかで会社に詰めておられた方も多かったのかと思います。ご苦労様で
した。3月末までは気が抜けないのでしょうが、このまま泰山鳴動鼠一匹だと
いいですね。そう祈りましょう。
先月はDQ、すなわちデータ品質に関する報告でしたが、Y2KもDQの特殊
ケースかと思われます。すべて成果物については質と量が問われるのが常です
が、情報システムについては、ステップ数など量は表現されても、質を表現す
る数値がない。しかも東京都庁のような建造物ならその質は見て分かるのに、
システムはInvisible、目に見えないので一層始末が悪い。ISOの認定も質の
保証としては全く間接的でしかありません。
DQは、多くの場合、システムの柔軟性の指標となります。それは企業が新し
い状況にどの程度迅速に対応できるかに関わるわけですが、これが企業収益に
どの程度影響するか、簡単に計算できないところに難しさがあるようです。
■大規模システムは大手SIが担当
さて今月は大規模システム開発の実態について、コンサル現場の知見に基づく
私なりのややデフォルメされた仮説を述べ、皆様のご意見を頂きたいと考えま
した。


大規模システム開発に取り組むのは、大手企業ですが、原則として大手SIに発
注します。理由は主に2つ。保険があること、たとえ失敗しても発注者の首がと
びません。大手SIの責任にすることができますし、赤字負担して何とか動か
してくれる可能性もあります。また手配師がいて動員力があること、ただし手
配師しかいない恐れがあります。
短期的な売上げを追求しすぎて、空洞化すれすれの大手SIが増加している心
配があります。私は、かつて20年勤めた千代田化工が短期的売上げアップを
指向して配管設計を外注化し、プラント設計技術の空洞化を招来したのを思い
出します。
■開発担当は専属ソフトハウス
大手SIの下には何社かの専属のソフトハウスがいます。彼らは永くレガシー
システムのメンテに関わってきました。そのキーマンが業務とソフトウエアを
繋いできました。ユーザからのメンテ要求を受け止めるには、どの物理ファイ
ル・どの物理プログラムにどのような変更を加えればよいかを考え、見事に回
答してきたわけです。彼らの頭の中の90%は、物理ファイル・物理プログラ
ムで占められ、業務知識は暗黙知化しています。
比較的小さなメンテには、この物理差分メンテの方法が有効でした。しかし5
年、10年とメンテを続けるうちに、ソフトは古い温泉宿の迷路のように複雑
化してきます。担当者が交代し、物理差分メンテしかやったことのないSEや
プログラマばかりになってきます。複雑な暗黙知ですから守備範囲を広げるこ
とはできません。各人担当部分は分かっても、全体を見通す人は誰もいなくな
ります。
■物理差分メンテ技術による開発
ビジネス環境やITの大きな変革に対応するために、全面再構築が企画されま
す。われわれはこのとき、ユーザの情報要求、すなわちIOに基づくDOAの
設計を考えますが、メンテを担当してきたSEやプログラマは、ゼロからシス
テマティックに設計する事ができません。蓄積してきた物理差分メンテ技術を
活かすためにでしょう、概要でよいからと、物理ファイル・物理プログラムの
イメージを要求します。何回もプロセス中心の試行錯誤を繰り返して、ユーザ
要求に近づけようというわけです。昔の物理ファイルイメージと違っていると
強引にこれに摩り替えようとする人もでてきます。
各ソフトハウスは、元来はウオーターフォールの構造化技法でしょうが、固有
の、悪くすると属人的方法でアプローチします。大手SIは一般に方法論を統
一するほどのリーダーシップを発揮しようとしません。そこで大量の暗黙知ド
キュメントを作って物理差分メンテ技法による試行錯誤を行うことになります。
十分レビューできませんので、各ソフトハウスの責任範囲を切り分け、各リー
ダーの話し合いに任せるしかありません。
■ 開発規模が大きすぎる
それでもリーダーに恵まれるとうまく行くのでしょうが、一人でも問題のある
リーダーがいるとひどいことになります。Capers Jones によると「15000
ファンクションポイント以上では、失敗率70%」とのことですから、規模を
下げない限り、プロジェクトマネジメント技術をいくら磨いても根本的解決は
得られません。規模を下げるための独立したシステムへの分解が最も効果的と
言えます。
DOAは、システム/プロセス間のインターフェースとなるデータ/IOを先
ず調整し固定しますので、必然的に独立した小さなサブシステムを切り出しま
す。映画がスチル写真の連続から成るのと似て、順序付けられた固定したイン
ターフェースがプロセスを表現することになります。DOAは、はじめデータ
モデリングの新技術習得も重なって、一見負荷が掛かるわけですが、データ/
IOの調整・標準化とサブシステム分割を行っていますのでトータルには最も
合理化されたものとなります。
■定期点検・補修が必要
ただしDOA開発の場合にも忘れられ勝ちの注意点があります。開発時作られ
たビジネスモデルを記述する形式知のDOAドキュメントが、劣化することで
す。小さな緊急メンテナンスには、物理ファイル・物理プログラムに対する差
分メンテが安直なため、これだけで対処し、いつしかDOAドキュメントのメ
ンテが忘れられ勝ちということです。DOA開発を経験したSE・プログラマ
も物理差分メンテ技術中心に退化してしまう危険があるのです。
化学・石油・原子力プラントでは定期点検・補修工事が当たり前ですが、ソフ
トにおいても、おそらく5年に1回は、規模は小さくともドキュメントや要員
スキルのリフレッシュのためのプロジェクトを実行すべきではないかと考えま
す。従来はスクラップアンドビルトが頻発したため、このような定期点検・補
修が要請されなかったのではないでしょうか。
■もたれ合いの悪循環
一般に発注側の大手企業は、大規模システムの見積査定能力を持っていません。
大手SIとて上流工程が進捗するまで、構造化技法と仮定しても正確な見積はで
きません。言わんやDOAでの見積もりなど論外です。したがってリスクを見
込んだ割高の見積が出され、結局これが通ることになります。専属のソフトハ
ウスはこれによって安定収入が約束されますので、良心的SEはぐちをこぼし
ながらも、お金のために遅くまで働くことになります。損をしているのは発注
者ですが、保険料として我慢することになります。恐いのはこれによって、生
産性が下がり、日本の国際競争力低下を招く事かと思います。
金と時間をかけて完成しても、小さな独立したサブシステムから構成するとい
う課題は先送りしたままになります。ITやビジネス環境の変化は激しく、
またすぐにメンテナンスが発生します。大規模なため前近代的保守の悪循環か
ら抜け出られません。ERPとて、このような大規模システムをリプレースす
る事はできず、会計部分のみ侵食し、却って問題を複雑化させたりします。
■経営と情報の距離を縮めるための形式知
やはり、システムを小さな独立したサブシステムから構成し、これを形式知と
して個人差なく表現する方法論が不可欠なのではないでしょうか。これを発注
者、SI、ソフトハウスが共有し、同じ楽譜を見て演奏するオーケストラのよ
うなプロジェクトを編成するまでは本当の解決がないと私は考えているのです
が、いかがでしょうか。形式知こそ、最近騒がれている「経営と情報の距離を
縮める」課題の鍵を握っているのではないかと思われます。新年早々、デフォ
ルメの過ぎた、あるいは誤解を含んだ論述だったかもしれませんが、皆様のご
意見を伺わせてください。
[以上]