[技術解説]

2009年12月8日(火)池田 和王海

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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