長年利用されてきたシステムには，改善を積み重ねてきた“優れた業務ロジック”が多数存在する。これらの強みを的確に抽出し，全社レベルで活用しながら更なる改善を重ねれば，一層強いシステムを作り出せる。その基盤となるのは紛れもなくSOAだ。業務モデリングの段階から全体最適を目指せば，ロングライフな「サービス」を定義できる。
玉樹 正人 日立コンサルティング 取締役
ビジネスの変化に即応し，強い業務プロセスを構築するためには，IT資産（プログラムなど）をいかに上手に活用するかがポイントになる。そのために，SOA（サービス指向アーキテクチャ）の考え方，技術は必要不可欠なものだ。
しかし，SOAが単にシステムを「つなぐ」「再利用する」だけのものと考えているなら，本当の意味でIT資産を有効活用することにはならないだろう。今，求められているのは，「IT資産に含まれる，固有の“優れた業務ロジック”を全社レベルで活用する」という全体最適の視点である。上流の全体設計から個別の実装までこの視点を一貫して持ち続けられるか否かで，業務プロセスやアプリケーションのパフォーマンスに大きな差が生まれる。
使われないIT資産は3～7割にも
 |
| 玉樹 正人 氏 日立コンサルティング 取締役 |
残念なことに，多くの企業では，IT資産の利用効率が非常に低い状態に陥っている。これまでに次々と新しいシステムを導入してきたものの，システム構成が複雑になり，自社がどんなシステムを持っているのかさえ正確に把握できていないケースもある。
その結果，企業で利用されなくなったITの「不稼働資産」が増えている。実際に資産解析サービスやリエンジニアリング・サービスなどを通して分かったことだが，IT資産の約3割は不稼働資産になっている。ひどい企業では7割にも達する。
そもそもITは，人・組織と一緒になって仕事を分担している存在だ。経営者は，人・組織などの人的資源に対して，熱心に活性化や改善を重ねてきた。これと同じように，IT資産にも活性化や改善を重ねていくべきである。実は，世界に通用する元気な日本企業は，どこも自社のシステムを非常に大事にしており，改善を積み重ねている。
これを多くの企業が実践できればいいのだが，実際にはそうではない。システムが複雑化しすぎて手に負えなくなったり，パフォーマンスが悪いと判断されたりすれば，すぐにパッケージ・ソフトを導入しようとする傾向がある。システムを「作っては捨てる」という行為を繰り返しているのだ。
強い企業のシステムは“改善”を蓄積
実際にこんな例がある。1990年代にERPパッケージ・ブームがあったころ，製造業A社がホスト・システムをやめてERPパッケージを導入した。
だが，ERPパッケージを導入してすぐに，問題が生じた。製造業は“改善”が命なのに，パッケージを入れた途端，これがピタリと止まってしまったのだ。
変数の桁を増やす，画面のレイアウトを少し変える，というだけで200万円くらいの修正費用がかかり，バージョンアップには2億円かかるとパッケージ・ベンダーに言われたという。このため，おいそれとシステムを改善できなくなってしまった。結局A社は3年でERPパッケージの利用を諦めた。
たまたま以前のホスト・システムのリソースをテープで保存していたため，A社はそこからシステム仕様を解析し，SOA的な発想でシステムの再構築に踏み切った。ERPパッケージと比べて，そこには現場の工夫や改善がぎっしりと詰め込まれていた。
そして，改善を重ねた“優れた業務ロジック”を，SOA的なシステム設計により全社で活用することができた。ここに来てようやく，A社のシステムは強さを取り戻すことができた。
この例から分かるように，情報システムの強みは，長年利用してきたシステムの中にあることが多い。それらをパッケージ・ソフトで安易に置き換えてしまうと，企業は強さを失ってしまう可能性がある。
解決策は，既存システムから強いところを取り出し，全体最適の観点から他のシステムでも応用できるようにすること（図1）。一般にレガシー・マイグレーションは，プラットフォームをオープン化することに主眼を置く傾向にあるが，本当は優れた業務ロジックを抽出して，使いやすい形にまとめ直すことが重要なのである。ここにSOAの考え方や技術が必要不可欠であり，上流工程から一貫して全体最適を目指すことが求められている。
 |
| 図1●SOAでIT資産に内在する“強み”を活用 |
日本の製造業のトップ企業は，現場の工夫を詰め込んだ業務ロジックを決して手放したりせず，ずっと改善を続けている。パッケージ・ソフトを導入したとしても，それとIT資産の強いところをうまく組み合わせ，より高い成果が出るように最適化している。
モデリングの巧緻が問われる
さて，実際にSOAシステムを構築するときには，どのような点に注意すべきだろうか。その最大のポイントは業務モデリングである。
これがうまくできれば，システム設計時に，サービスやインタフェースを簡単にマッピングできる。また，業務に変化が起こったとき，あるいは変化を起こそうとしたとき，どこを変えたらそうなるかが容易に識別できるようになる。
うまくモデリングするには，まず業務の「基本」と「バリエーション」を峻別することが必要である。いくら経営環境が大きく変化しているとはいえ，業務の「基本」をころころ変えることはまずない。そこで，変化しやすい部分（バリエーション）を基本部分から切り離す。こうしておけば，10年以上経ってもシステムは外部の変化に耐えて生き残れる。これは，いくつもの実例が証明している。
 |
ただ，業務の本質を見抜く洞察力がないと，変化に強いモデルは作成できない。職人技とも言われる領域であり，この状況は昔から変わっていない。
「業務の基本は変化しない」という前提に立てば，業界ごとにリファレンス・モデルを作れる可能性はある。かつてはそう考えて，業界ごとにモデルを作る運動をしたことがある。
しかし，業務モデルに限って言えば，リファレンス・モデルの実用性は期待するほど高くないのではないか。例えば製造業の営業プロセスをモデル化する場合，「販売計画→引合→受注→売上」とモデリングすれば汎用性は高いが，現場ではいろいろと裏技的な工夫が行われている。これが長年の間に，こんな簡単なモデルでさえ，その境目を崩していってしまう。
重要なのは“理解の作り込み”である。SOAに適した業務モデルを作成するには，現場の責任者と一緒になって，業務の本質を見極めるための議論が欠かせない。「あぁ，そうだよね」という気付きがモデルのあちこちにちりばめられていないと，業務の本質を見極めたモデルにはならず，生き残れない。
SOAの実践はまず業務への深い理解がないと始まらない。技術基盤の重要さもさることながら，優れた業務ロジックを抽出し，そこに継続的な改善を加えていくことが，IT資産の強化，ひいては企業の競争力アップにつながる。SOAはそのための「場」でもある。
|
