» 【第91号】成熟度モデルを考える

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第91号】成熟度モデルを考える

DRI通信91号「成熟度モデルを考える」  2004.4.1
「暑さ寒さも彼岸まで」を修正しなければならないような日々が続き、風邪を引いたりする人が目立ちましたが、皆様いかがですか。
2月末のDOA+コンソーシアムの第2分科会ではメディア情報開発の山田、下地様からWebtribeの、また第1分科会ではSDIの佐藤様からT字形DB設計法のプレゼンテーションがあり、活発なQ&Aもあって理解を深めることができました。
■技術成熟のS字カーブ
このところ3号続けて、成熟度モデルを扱いました。それはシステムアーキテクチャ(SAMM)、メタデータリポジトリ(MRMM)、およびデータモデル(DMMM)に関するものでした。成熟度モデルとは、基礎技術の革新によって、成熟度が大きく向上していく様子を示すものです。初めに、あるニーズを満たす技術Aが生まれますが、その効果は一般にS字カーブ/成長曲線を描いて向上します。すなわち初めは目に見えて効果が出てきますが、あるところで効果逓減の法則にしたがって、伸びが止まってきます。そこで、それまでひそかに準備されてきた次世代技術Bが登場し、Aを追い抜いていきます。そのBにもやがて限界が見え、次の技術Cがこれを代替してゆくというわけです。


■説得力
ユーザはどこかで技術Aから技術B、さらに技術Cに移行してゆかなければなりませんが、この説得には面白い特性が見られます。技術Aによる伸びが止まってからならば、次の技術Bに移行すべきことは誰にでも分かるので、Aでしか生きられない人を除いて、反対はなく、説得は比較的簡単です。しかし初期段階で、Aに取り組み始めてまだその麓にいる人は、一般にBの話に聞く耳を持ちません。この技術Aによって、現在抱えている課題はすべて解決できるように見えるためです。むしろAに取り組んでいない部外者や素人の方がBを理解し、Aの限界を悟ります。
■カーブ乗り換えのコスト
一般に技術AにはAの、またBにはBのインフラ投資が必要です。ハード・ソフトのほか、ノウハウや教育のための、コストや時間です。勿論BをこなすためにAを経過する必要がある場合は、Aを卒業する必要があるわけですが、Aをバイパスした方が良い場合が多々あります。電話からポケベルをバイパスして携帯へ、メインフレームからC/SをバイパスしてWebへ、順次ファイルから構造型DBMSをバイパスしてRDBMSへなどはその例かと思います。
システム開発プロジェクトにおいても、個別アプリケーションをターゲットにした孤島システム開発をバイパスし、統合リソースを前提にしたデータ流通の保証されたシステム、しかも実装独立でITの変化による影響を原則として受けないシステム、をねらう戦略があります。実際今、多くの企業が孤島システムの統合を課題として認識し始めていますが、20年前これを提言しても、「個別アプリの開発こそ課題である」として、われわれの取組みに賛同していただけた企業は、例外的でした。しかしその例外的企業において、リソース一元化、メタデータ管理を実践し、90年代の混乱期、余裕を持って経過させた、システムアーキテクチャ・バイパスの効果は、確かな手ごたえを感ずるものでした。
■洞察力
10億円かけて5年持つシステムを開発するより、15億円かけて15年持つシステムを開発する方が得策であることは、誰にでも分かるでしょう。しかし開発企画において、開発にいくらかかるかは誰しも真剣に考えますが、それが何年持つかについては、あまり気にしていないかに見えます。
予測が難しいことが原因ではありますが、ひとつは技術者や経営者の設計コンセプトの本質を見る洞察力の欠如かと思われます。たとえば孤島システムはコンピュータの自動計算能力を活用し、省力化や品質向上をねらうものですが、これを統合するシステムはさらにコンピュータによるコミュニケーション能力をも活用し、全体最適をねらうもので、「早晩これに移行せざるを得ない」ということが洞察できれば、いま個別アプリを作るとしても、統合化に際してスクラップにしない方式を考えることになります。
また、もうひとつの原因は、経営者の「任期中に手柄を上げたい」思いと、評価はカットオーバー時点になされ、後々は追及されないことかと思われます。
洞察力を身につけると言う課題は容易ではありませんが、ひとつの鍵は理想を描いてみることではないかと思います。現実にこだわってそこからしか発想しないと、限界が出やすい。現実は一旦さておき、「課題解決の理想を考え、次にこれと現実とを如何につなぐかを考える」、このような発想によって問題の本質がよりよく見えてくるように思われます。今はERP技術の本質やオブジェクト指向技術の本質を見ていかなければならないように思われます。
■マネジメントの対処 
技術Aが技術Bに変わり、さらに技術Cに変わるというとき、マネジメントは技術Bをバイパスすべきか否かを意思決定しなければなりません。技術Bが何年持つか、技術Cは一過性のものではないか、限界が来る危険性、何時実用になるかなどの技術的判断が必要ですが、さらに大勢の関係者を説得し、これを理解してもらわなくてはなりません。このとき単に技術Cを考察するより、さらに次の技術Dを想定し、成熟度モデルを示して説明すると、説得力が上がるものと思われます。
新技術に移行する場合、その進めかたに次のような注意が必要です。一般に、新技術を売り込むベンダーは早く売り込みたいし、導入担当者も早くその結果を見たい、と言うことで、当初は準備そこそこに実装します。結果がよければこれを他に展開してゆくわけですが、安易に展開してこれが混乱の元になることが多々あります。したがって、ここで一腰落とす必要があります。たとえば、90年代のC/Sシステムの乱立は、標準化、とくにリソースデータの標準化なし、無政府状態のまま、早かろう安かろうと展開したのが主な原因だったと伝えられています。このような中で作られたソフト・要員・文化の資産/負債を、秩序正しいものに切り替えていくことは大変なことです。地球環境問題と同様、手遅れにならないような、マネジメントの適切な対処が望まれます。