» 【第101号】システム部門の文化の進化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第101号】システム部門の文化の進化

DRI通信101号「システム部門の文化の進化」 2005.2.1
ついこの間お正月だと思っていたのに、もう2月になりました。実感は2週間
くらいしか経ってない。「人生の、はじめのほうから見ると結構長いのに、終
わりの方から振り返るとあまりにも短い」とか。ほんとですね。
2005年の第1分科会が動き出しました。
(詳細はDOA+コンソーシアムのウェブサイトをご確認下さい。)
24日、DOAを議論するときに、前提としているアーキテクチャについて、MSの萩原さん、椿、東京国際大学の堀内さんがプレゼンして、議論しました。予想通り多岐にわたるアーキテクチャがでてきてまとめきれず、2月28日もう1回やることにしました。
■システム部門の文化
強いシステム部門は、進化したシステム部門の文化を築き上げています。
先進的なIT技術を消化し、過酷なユーザニーズの変化に前向きに取り組み、
成功させて成長を続けていきます。弱いシステム部門は、ビジネスニーズに
応えるために、コンサルタントやSIerの支援を得て、先進技術に取り組みま
すが、失敗したり、成功したとしても大変な時間やコストの犠牲をともなった
上で、となります。中学生が大学受験しても合格がおぼつかないように、弱い
システム部門のままで、ERP、SCM、CRMなどに取り組んでも、所期の成
果を得ることは容易でありません。システム部門の文化とは何か、これを進
化させるにはどうすべきか、など考えてみます。


■SCMM
この道40年の特権から、次のような5段階のSCMM(Systems department
Culture Maturity Model)を提案させていただきます。
 C1:アマチュア
 C2:セミプロ
 C3:プロ
 C4:プロ集団
C5:エキスパート集団
C1は、ユーザの代表者が選ばれて、システム開発を担当するといった、まだ
開発者とユーザが分化しない段階の、システム開発者の持つ文化です。ユー
ザニーズを持っている担当者が直接かかわるため、そのニーズは反映しやす
いわけですが、即効性のある個別ニーズへの対応が中心となり、他との調整
を必要とする標準化などは後回しとなります。1970年代まではこの文化が主
流でしたが、1990年代のC/S時代、ユーザ部門がベンダーと組んでシステ
ム開発するときも、この文化が再登場したきらいがありました。
C2は、C1でのシステム開発経験者と新入社員などが、システム開発専門家
として組織化され、アプリケーション対応の共用データや手順・設計ドキュメント
の標準化などに取り組み始めた段階です。個別アプリケーションの機械化が、
主目的ですからアプリケーション横断の見方はまだ念頭にありません。
C3は、個別アプリケーションの開発に関しては、ほぼ「任しとき」と言える段階
で、手順・設計ドキュメントの標準化も身についています。しかしまだ部分最適
の孤島システム指向で、スコープはアプリケーションごと、プロジェクトごとで
あり、C2で作られたアプリケーションの連携には、ユーザの要請に都度応じる、
もぐらたたき方式で間に合せます。データモデルも作り始めますが、RDBの
テーブル設計が目的です。社内外組織やモノに関するコードもある程度は標準
化されていますが、個別に設定されたものも残っており、ERP導入や、DWH
導入に際しては、アプリケーション横断のデータ流通のための標準化から手掛
けなければなりません。一般にCIOは不在で、データ管理組織もなく、コードや
メタデータの管理は、開発者に任されていて、劣化が発生し勝ちです。
C4は、孤島システムの弊害に気付いて、これを改め始めた段階です。全体最
適の基本条件として、データのシームレスな流通のための共用コードの標準
化を図り、これを維持するためのデータ管理体制と手順の整備の必要性が叫
ばれ始めます。しかし、それはまだ全員のコンセンサスにはなりません。全体
最適でないことの責任を問われる人、また全体最適であることを喜ぶべき人が
はっきりしていないため、人も予算も限られ、エンジンがかかりません。それで
も進んだ担当者は、整合性の取れる、より精度の高いドキュメンテーションを
指向して、実装独立のモデルドリブンの要件定義の方法論を習得し始めます。
C5は、適切な全体最適・長期最適に取り組めるようになった最終段階です。
業務横断の共用データやこれを活用する人材など「購入できないインフラ」の
重要性が、トップ・CIO以下全員に認識され、この整備と維持に適切な手が打
たれるようになります。ITの激しい変化に柔軟に対応するために、まずビジネス
の構造が、個人差の出ない実装独立の図と表によりモデル化・可視化されます。
これはメタデータのデータベース、リポジトリに反映され、ソフトウエアはこれを
もとに作られる方式になっていきます。
こうして、ドキュメンテーションは、それまでのソフトウエアに関する自然言語
主体のものから、業務モデルに関する図と表主体のものに変り、視野が広がり
ます。これまで、いわば自分の身の回り5m先までしか見えなかったものが、
他の人のカバーしている500m先まで、多くの人が見るようになります。現状
や問題点の共有が容易になりますので、ビジネスの変化に対応する意思決定
が迅速にできるようになります。デル・コンピュータが、パソコン生産に実現した
BTO(Build to Order)方式を、システム開発に持ち込んだことになります。当然、
システム企画・管理部門のガバナンスが行き届き、冗長データは最低限度に
コントロールされ、システムは無駄の少ない筋肉質になります。
■段階に応じたテーマ
以上のようにシステム部門の文化を5段階に分けましたが、日本の先進企業は
C4に到達したところかと思います。この段階ならば、苦労はしてもERP、SCM
に成功裡に取り組むことができるでしょう。より高度のCRMやEAへの取り組み
は、C4もC5に近くなってからのテーマかと思われますし、逆にCRMやEAに
取り組むことによって、C5にレベルアップしてゆくと言えるでしょう。
しかし日本の企業の多くは、まだC3段階のように思われます。「情報システム
はコアコンピタンスでない」と判断し、ITガバナンス不全のC3段階でアウトソー
シングすると、名前は情報企画部と改名しても、その実は予算を持ちこれをばら
まく調達事務部門となってしまいます。落札先が適切であれば、当該アプリケー
ションは、満足すべきQCD(Quality-Cost-Delivery)で出来上がってきますが、
それは孤島システムでしかなく、この上に、これらを繋ぐためのスパゲッティシス
テムを作らなければならなくなる心配があります。アプリケーション間の整合性
は、あくまでも発注側のガバナンスによって確保すべきテーマであると考えます。
(注)このSCMMでは、ユーザ企業を対象に、データモデリング、実装独立、
業務横断、標準化の観点を重視したため、CMMI(Capability Maturity Model
Integration)の成熟度モデルとの関係は考慮しませんでした。