先の見えない今だからこそ、企業が取り組まなければならないプロジェクトがある。それはEA（エンタープライズアーキテクチャ）だ。社内のIT資産を見える化して効率化し、変化に強いシステムに鍛え直す。この取り組みをリードするのは、ほかならぬシステム部門である。
協和発酵キリンのシステム部門があるフロアの会議室には、常時2枚のモデル図が掲示されている（写真）。
向かって左は、社内で活用しているアプリケーションを一望できる鳥瞰図だ。調達や製造、受注、会計など30以上のアプリケーション間を、データがどのように流れているかを詳細に記述している。右は、これから目指すシステム構成・関連図である。異なるシステム間でデータをやりとりするためにデータモデルを変換する「エンタープライズHUB」を中心に、2012年末までに実現すべきシステムの全体構成を示している。
どちらも、中山嘉之部長が自ら作成したものだ。「モデル図を描いていると、『ここに○○機能があればもっときれいなモデルになるのに』などと、欠落している部分が見えてくる」（同氏）という。メンバーは会議中、これらの図を視野に入れながら議論する。このため、チーム内の意思疎通がスムーズで、設計業務におけるブレがない。
同社がデータモデルを設計したのは、1982年にさかのぼる。それ以来、同じモデルが整合性を保ったまま現在に引き継がれている。
モデルが整合性を失う危機は2度あった。1度めは、90年代後半のことである。オープンシステムが台頭し、ある程度のIT知識を持つエンドユーザーならば簡単なシステムを作れるようになった。このまま放置すればデータが社内に散在し、矛盾を引き起こすようになる。そこで、マスターデータを一元管理する環境を構築した。これが、エンタープライズHUBである。
第2のピンチは、ERP（統合業務）パッケージの導入だった。ERPパッケージのデータモデルが、自社のそれと異なっていたのだ。このため、既存モデルをERP向けにコンバートするプラグインを用意した。これにより、パッケージの大幅なカスタマイズを回避しつつ、自社のデータモデルを維持した。
協和発酵キリンは、技術のトレンドやその場の必要性に流されたシステム対応を一切排除してきた。全体最適にこだわり、データモデルを軸に統制をかけてきたからこそ「『変化に強いシステム』と『ほしい時にほしい情報が手に入るシステム』を具現化できた」（中山部長）。
グランドデザインの欠落が開発・運用の手間を増大
「我が社でも、同じようにシステム全体像を共有している」と胸を張れる企業はどれだけあるだろうか。多くの企業では、事業部門や業務ごとに個別の設計思想に基づいて開発したシステムが乱立。重複した機能やデータ間の整合性を“力業”で保つため、運用の手間やコストが膨れあがっている（図1-1）。例えば、あるシステムでデータ項目を1つ増やすと、連携しているすべてのシステムのデータ項目も増やさなければならない。場合によっては、社内にシステムが分散しているため、変更が影響を及ぼす範囲を特定できないことすらある。
運用業務だけではない。サイロ化したシステムは、開発業務の負荷も増大させた。システム開発時に、新システムを既存システムと個別に連携させる手間が発生するからだ。各システムが共通の業務モデルやデータモデルに基づき設計されていれば、こうした付帯業務は基本的に発生しないはずである。アクセンチュアの沼畑幸二エグゼクティブ・パートナーは、「開発プロジェクトにおいて、既存システムとのインタフェースを開発する作業は、全体の開発工数の3割を占める。システム部門は、新規開発のたびに多大な“税金”を払っていることを認識すべきだ」と指摘する。
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
