IT資産の不協和音を断つ―EAに挑む Part 1

IT Leaders編集部 - 2009年12月1日(火) 09:00

グランドデザイン描き ITと業務の不協和音に終止符を打つ

総論〜システム部門が先導せよ

先の見えない今だからこそ、企業が取り組まなければならないプロジェクトがある。それはEAだ。社内のIT資産を見える化して効率化し、変化に強いシステムに鍛え直す。この取り組みをリードするのは、ほかならぬシステム部門である。

協和発酵キリンのシステム部門があるフロアの会議室には、常時2枚のモデル図が掲示されている（写真）。

協和発酵キリンのシステム部門は、社内システムのas isとto beモデルを見ながら議論を深める

向かって左は、社内で活用しているアプリケーションを一望できる鳥瞰図だ。調達や製造、受注、会計など30以上のアプリケーション間を、データがどのように流れているかを詳細に記述している。右は、これから目指すシステム構成・関連図である。異なるシステム間でデータをやりとりするためにデータモデルを変換する「エンタープライズHUB」を中心に、2012年末までに実現すべきシステムの全体構成を示している。

どちらも、中山嘉之部長が自ら作成したものだ。「モデル図を描いていると、『ここに○○機能があればもっときれいなモデルになるのに』などと、欠落している部分が見えてくる」（同氏）という。メンバーは会議中、これらの図を視野に入れながら議論する。このため、チーム内の意思疎通がスムーズで、設計業務におけるブレがない。

同社がデータモデルを設計したのは、1982年にさかのぼる。それ以来、同じモデルが整合性を保ったまま現在に引き継がれている。

モデルが整合性を失う危機は2度あった。1度めは、90年代後半のことである。オープンシステムが台頭し、ある程度のIT知識を持つエンドユーザーならば簡単なシステムを作れるようになった。このまま放置すればデータが社内に散在し、矛盾を引き起こすようになる。そこで、マスターデータを一元管理する環境を構築した。これが、エンタープライズHUBである。

第2のピンチは、ERP（統合業務）パッケージの導入だった。ERPパッケージのデータモデルが、自社のそれと異なっていたのだ。このため、既存モデルをERP向けにコンバートするプラグインを用意した。これにより、パッケージの大幅なカスタマイズを回避しつつ、自社のデータモデルを維持した。

協和発酵キリンは、技術のトレンドやその場の必要性に流されたシステム対応を一切排除してきた。全体最適にこだわり、データモデルを軸に統制をかけてきたからこそ「『変化に強いシステム』と『ほしい時にほしい情報が手に入るシステム』を具現化できた」（中山部長）。

グランドデザインの欠落が開発・運用の手間を増大

「我が社でも、同じようにシステム全体像を共有している」と胸を張れる企業はどれだけあるだろうか。多くの企業では、事業部門や業務ごとに個別の設計思想に基づいて開発したシステムが乱立。重複した機能やデータ間の整合性を“力業”で保つため、運用の手間やコストが膨れあがっている（図1-1）。例えば、あるシステムでデータ項目を1つ増やすと、連携しているすべてのシステムのデータ項目も増やさなければならない。場合によっては、社内にシステムが分散しているため、変更が影響を及ぼす範囲を特定できないことすらある。

図1-1　これまでの場当たり的な開発によりサイロ化した企業システムは、無駄なコストの温床になるばかりかビジネス変革の足かせになりかねない

運用業務だけではない。サイロ化したシステムは、開発業務の負荷も増大させた。システム開発時に、新システムを既存システムと個別に連携させる手間が発生するからだ。各システムが共通の業務モデルやデータモデルに基づき設計されていれば、こうした付帯業務は基本的に発生しないはずである。アクセンチュアの沼畑幸二エグゼクティブ・パートナーは、「開発プロジェクトにおいて、既存システムとのインタフェースを開発する作業は、全体の開発工数の3割を占める。システム部門は、新規開発のたびに多大な“税金”を払っていることを認識すべきだ」と指摘する。

業務を横断的に見られるシステム部門が先導すべき

なぜ、こんなことになってしまったのだろうか。それは、業務プロセスとそれを実行するためのシステムを関連づけて整理し、全体最適を図る「EA（エンタープライズアーキテクチャ）」の視点を欠いていたからである。これまで、システム部門はその時々の最新技術を導入し、ユーザーからの要求に応えてきた。立ち止まって社内の業務やシステムの全体像を考えることはなかった。いわば“場当たり的”なシステム開発に甘んじていたわけだ。

そのツケが、先に述べたようなシステム開発・運用の非効率である。それらは当然、ビジネスにも悪影響を及ぼす。無駄なコストがかかるだけではない。市場環境のめまぐるしい変化に呼応したビジネス変革の足を引っ張る。システムの混沌は、企業の収益と成長を阻害する。もはや、「既存システムはつつがなく動いているから」と問題を先送りしてはいられない。

経済低迷は、EA実践をためらう理由にならない。むしろ、新規開発を一時的に見送っている今こそ好機であると考えたい。今のうちに自社の業務とシステムの現状をじっくり見つめ直しておけば、景気が底を打った際に一気に攻勢に転じられる（詳細はPart2）。

くれぐれも、「我々の管轄はあくまで情報技術。現場の業務についてはユーザー自身が考えるべき」と言うなかれ。協和発酵キリンの中山部長は、「企業内で発生するデータをすべてコンピュータで処理するようになり、各業務部門は他部門の業務を詳細に知ることがなくなった。社内のすべての業務プロセスを説明できるのはいまや、データの流れを把握しているシステム部門だけだ」と語る。ガートナージャパンの中島一晃リサーチディレクターは「EAだからといって、構える必要はない」と言う。「as isとto beのギャップ分析は、EAに限らずあらゆる開発プロジェクトに共通する作業であり、システム部門はこれまで幾度となく経験してきたはずだ」（同氏）。EA実践において、システム部門が担うべき役割と期待は大きい。

アーキテクチャを定義しユーザーに逆提案せよ

とはいえ、システムのみならず社内の業務すべてを洗い出して構造化するのは決して容易なことではない。業務部門の関与も不可欠だ。EAが社内に根付き、その効果を実感できるようになるまでには、相応の時間とコストがかかる。

そこで、インフラやアプリケーション、データといったシステム側の整備を先行させることにより、短いサイクルで効果を出していく方策を2つ紹介する。

第1は、IT資産の整理統合である。社内に保有するハードやソフト、データを棚卸しして見える化し、不要なものや重複分を廃棄する。これにより、システムの複雑性を軽減できるほか、運用や保守費用を大幅に削減できる（詳細はPart3）。さらに、この作業はシステムの現状を鳥瞰することにも役立つ。

第2は、システムアーキテクチャの原則を策定することである。具体的には、標準となるシステム基盤を定め、その上で社内に存在するデータやアプリケーションを明確に定義・配置する。とりわけデータのガバナンスは重要だ。人、モノ、金という経営資源の動きを示すのがデータであり、この扱いに不整合があると企業活動全体に支障をきたす（詳細はPart4）。

調達や開発、セキュリティなどに関するルールも明示したい。クニエの木村拓ディレクターは、「システム部門はこれまで、ユーザー部門の要求をできるだけ満たすことを使命としてきた。これからのシステム部門は、ユーザー部門に対して『こういうアーキテクチャに基づいてシステムを作る』と逆提案していくべき」と話す。

これらシステム側からの2つの方策は、業務とシステムの構造化というEAの中長期的な取り組みに必ず効いてくるだろう。システムのさらなるサイロ化を防げるし、業務とシステムを関連づけやすくなるからだ。

ビジネスの変化に柔軟に対応できるシステムを目指すEAは、住まいの大掃除に似ている（図1-2）。不要品を処分し、「書斎」「寝室」「客間」など各部屋の機能を明らかにする。これにより、モノの所在が常に明確になり、無駄な買い物を減らせる。ライフスタイルの変化に応じた模様替えもしやすくなる。