ビジネス巻き込む実践的アプローチ―EAに挑む Part 2

池田和王海 - 2009年12月8日(火) 09:00

ビジネスとITの真の融合に向けた実践的アプローチ

EAの意義を理解する

先行き不透明なビジネス環境の中、企業は激しい変化に柔軟に対応できる構造への変革を急がなければならない。それには、業務とシステムを一体化して全体最適化を図るEAのアプローチが有効だ。まずはEAの意義を理解し、基本的な進め方を頭に入れよう。

多くの企業は、いまだ縦割り構造から抜け出せていない。商品やサービス、顧客グループごとに独立したビジネス構造を持ち、システムもそれに合わせる形でサイロ化している。

このような構造では、ビジネス機能やシステム機能、データが重複し、無駄なコストがかかる。何らかの変化が生じた際の対応スピードも落ちる。もちろん、業務効率化への取り組みは繰り返されている。しかしそれらは、部門や事業別に実施されるのが常。このため、部分最適にとどまらざるを得なかった。

2000年代前半までの経済状況では、それでもよかった。今ほど厳しい環境ではなかったし、リストラや業務効率化で利益を生み出せる面もあったからだ。しかし、2008年の金融危機以降、企業を取り巻く環境は一変した。グローバル化した経済においては、世界のどこかで発生する不測の事態が、一夜にして世界中の経済に影響を与え得る。そんな激しい変化の時代を勝ち抜くために企業は、恒常的な低コスト体質と、環境変化に俊敏に対応できる柔軟性を兼ね備える必要がある（図2-1）。

図2-1ビジネス環境の変化が、業務とITが一体化した全体最適を求めている

それには、業務とITの一体化が不可欠だ。業務とITを一体にとらえて標準化し、さらにモジュール化・共通化することで低コストかつ変化対応力のある構造に変革できる。これを実現するには、ビジネスとITを構造的にとらえて全体を俯瞰できなければならない。

この難度の高い課題を克服するために、EAに再び注目する企業が増えている。

システム標準化を超えて継続的な構造改革を

EAとは、ビジネスとITを構造的にとらえて全体最適を図るための方法論である。具体的には、企業の全体観をビジネス、アプリケーション、データ、インフラストラクチャといったアーキテクチャでとらえて可視化する。それぞれのアーキテクチャを相互に結び付けて管理することで、ビジネスとITを一体化させながら環境に応じて柔軟に変化させられるようになる。

こうしたEAの考え方は、決して新しいものではない。海外では1990年代から、国内においても2003年ごろからEAの本格的な実践が始まった。実際、継続的な企業変革のドライバーとしてEAを活用し、大きな効果を生み出している企業は存在する。

ところがその一方で、EAに取り組んだ企業の多くは十分な成果につなげることができずにいる。なかには、取り組みそのものがいつの間にか立ち消えになった企業もある。その原因の多くは、EAの活動がシステム標準化のレベルにとどまっていたことにある。

もちろん、システム標準化だけでも一定の成果を収めることはできる。しかし、それだけではEAは継続的な活動として根付かない。なぜなら、経営やユーザー部門からすると、システム標準化はIT部門に閉じた取り組みであり、自分たちにとってのメリットが見えにくく関心を持てない。さらに、システム標準化というテクノロジー起点の取り組みは、どうしても一過性のプロジェクト的な色彩が強くなるからだ。

EAによる継続的な構造改革を実現するには、システム標準化というボトムアップのアプローチに加えて、ビジネス視点からのトップダウンアプローチが不可欠である（図2-2）。といっても、実質的な活動はシステム部門がリードすべきだ。社内の業務を横串で見ているシステム部門は、EAの成否を左右する大きな役割を担っていることを強く認識してほしい。

図2-2先行き不透明な時代の構造改革のためのEAはトップダウンアプローチが基本

ゴール達成への施策をビジネスとIT両面から定義する

構造改革を目指すトップダウン型のEAにおいてベースとなるのは、ビジネスアーキテクチャである。

ビジネスアーキテクチャを定義する第1歩は、構造改革の目的とそれを達成するための変革テーマの明確化である。戦略的なビジネスゴール（提供価値）を頂点に、ゴール実現のために企業として何ができなければいけないか（ケイパビリティ）を洗い出し、そのケイパビリティ実現のためにどのような施策が必要なのかを業務とITの両面から定義する（図2-3）。

図2-3ビジネスゴールとIT施策の因果関係を明確にして、ゴール達成へのITの貢献を可視化する

業務施策のみでも、IT施策のみでもビジネスゴールは達成できない。両者が一体となって初めて業務改革を実現できる。このことを可視化して、ビジネス部門とIT部門が多方で認識の共有を図ることが、ビジネス視点からのトップダウンアプローチのEAには不可欠である。

業務のWhat、Howを特定し共通点を見いだす

次に、企業全体を鳥瞰して業務をモデル化する。さらに、どの業務領域でどのような変革が必要なのかをビジネスゴールから導き出してこのモデル上に対応付け、関係者の共通理解を深める。その後、変革テーマの実施状況や、環境変化によるテーマの追加・変更、全体最適の視点からの優先順位付けもこの枠組みの上で議論する。

続いて、業務プロセスをモデル化する。その目的は、業務の標準化・共通化の機会を特定することにある。業務プロセスのモデル化というと、J-SOX（日本版SOX法）対応のように詳細な業務フローの作成を連想するかもしれない。しかし、業務処理の手順をそのまま可視化する作業は膨大な労力を伴うばかりではなく、業務の枝葉末節な違いばかりが目に付きやすい。このため、業務プロセスの共通性を見出すための手法としては不適切である。

EAにおける業務プロセスモデルは、上で作成した業務モデル（レベル0）を基に作成する。レベル0を起点に、業務プロセスの枠組みを定義するレベル1、業務機能の共通部分と固有部分を切り分けるレベル2程度まで落とし込んでいく（図2-4）。

図2-4トップダウンアプローチのEAではビジネスアーキテクチャがカギになる（図をクリックで拡大）

レベル1では、業務プロセスのやり方（How）ではなく、何をするか（What）に着目し、抽象度の高いモデルを短期間で作成する。店頭やインターネットといったプロセスのHowは違っても、「物品やサービスを販売する」というWhatは変わらない。こうした業務の本質的な目的を特定し、業務プロセスの共通性を浮き彫りにすることが、レベル1の狙いだ。このレベル1では、拠点やロールタイプの定義も行う。

レベル2では、レベル1の枠組みに基づき拠点や業務処理、商品などの違いを意識した具体的なモデルを作成する。ここでは、店頭とインターネットでの処理の違いや、コールセンターと外回りの営業担当者の処理の違いといったHowの違いを業務機能ごとに分析する。標準化・共通化の可能性を検討するためだ。

業務プロセスをモデル化するEAのこうした手順は、個別システム化の手順と本質的には変わらない。ただし決定的に異なるのは、EAは全体を鳥瞰する枠組みを関係者で共有しながら進める点である。これにより、個別システム化では置き去りにされがちな全体最適の観点を維持し、中期にわたる業務改革の共通の拠り所を提供することが可能になる。

システムの原理・原則を定義
ビジネスとの乖離を防ぐ

業務とITを一体化させるEAを実現するには、システム開発の現場がその目的や考え方を十分に理解していなければならない。さもないと、目指す姿と構築されるシステムの乖離が起こり得る。そこで、ビジネスアーキテクチャと合わせて、システムの最上位のデザインガイドとなるアーキテクチャ・プリンシプルを定義する。

プリンシプルとは、その企業のアーキテクチャが順守すべき原理・原則を明文化したものである。プリンシプルは通常、企業のビジネス戦略から、システムのアーキテクチャに求められる普遍性の高い特性を導出したもの。さらに、過去のシステム化における基本方針や属人的なノウハウを参考にし、守るべき原理・原則として定義する。

ビジネスアーキテクチャは、ビジネスゴールを直接的に支援するためのガイドである。これに対してプリンシプルは、システムの長期的な変化対応力を担保し、ビジネスの継続性を支援するためのガイドとなる。

推進体制を経営直下に
人材の確保がカギ

EAに取り組む際は、EAガバナンスの仕組みを構築することが望ましい。実際のプロジェクトがアーキテクチャ標準やプリンシプルに準拠しているかどうかを確認するための体制や役割、管理のプロセスなどを明確にする推進体制を作るのである。

ガバナンスというと、統制というイメージが強いかもしれない。だが、決して押し付けではなく、「ビジネスゴールの実現のために何をすべきか」という現場からの相談に乗るというくらいの姿勢が望まれる。さらに、環境変化に合わせたアーキテクチャ標準の定期的な見直しも、EAガバナンスの仕組みの中に組み込むべきである。

EAガバナンス体制は、可能な限りトップマネジメントに近い位置付けにすべきである。EAを推進して全体最適を実現するには、個別部門の利害を超えた企業横断的な優先順位付けが必要だからである。CIOやCEO直下の活動であれば、より円滑な推進が可能だろう。そのうえで、十分な権限委譲も必要だ。構成要員には、システム部門だけではなくユーザー部門の代表者をそろえビジネスとITの協働体制を敷く。

なお、ガバナンス体制はあえてEAを名乗らないという選択肢も考慮すべきである。目指す目的は全体最適の構造改革であり、EAはあくまでも手段である。それに、過去にEAに着手したものの顕著な効果が上がらかったことから、EAという言葉自体が禁句・トラウマとなっている企業もあるだろう。このため、EAガバナンス体制には「構造改革室」のように、目的を表す分りやすい名称をつけたい。

EAを継続的に推進するには、アーキテクト人材の確保も重要な課題となる。業務とITを鳥瞰して全体最適の優先順位を付け、利害の一致しない業務部門間を調整できる人材となると、適当な候補者がいないことは多い。

そこで、EA実践の初期段階では社内人材の不足を外部パートナーで補完する。その一方でアーキテクト候補を選出し、順次スキルトランスファーを行っていくといった取り組みが必要である。