GLOVIAアラカルトセミナー予告編

今、企業は様々な変化への対応を迫れられています。
経営の競争力を高めるために不可欠な「人材力」「IT活用力」について、日経BP社プロジェクト推進部長（前日経コンピュータ編集長）田口潤氏が、株式会社アイ・ティ・アール代表取締役／シニア・アナリスト内山悟志氏に聞きました。

田口今、企業を取り巻く環境はすさまじい勢いで変化しています。

内山少し前までは、変化対応が必要なのは通信業など限られた業界でした。最近では、あらゆる業種、規模で変化が加速、拡大してきています。その要因はM&A、グローバリゼーション、技術革新、規制緩和と法規制の強化などですが、その中で、経営者も変化への対応に取り組んでいます。昨日より今日、今日より明日と問題がより複雑になり、企業はそれに迅速に対応しなければならないのです。

田口しかし変化への対応と言っても、変化の要因はいろいろで、相矛盾することもあります。1つのことに捉われていると足をすくわれかねません。

内山最近、経営者とお話しすると、「最終的にはどこで競争力に差がつくのか」が話題になることが多くあります。以前は資本の論理や生産力、販売力など、規模に従属する要素が大半でした。ですが今や、規模だけではダイナミックな変化に対応しきれません。結局、「人と人の知恵比べだ」ということになり、人材が焦点の1つになっています。組織力は人材の総和ですから、改めて人がクローズアップされるんです。

ここでITもクローズアップされています。つまり“人材力の合計×IT活用力”が競争力だと考える経営者が、金融サービスや通信、ネット関連などを中心に増えています。特にグローバル競争になると、IT活用力は必須です。相手がそれで攻めてくるわけですから、ITで立ち向かわなければなりません。

田口その中でITは武器になるのか、逆に足を引っ張る要因になるのかという問題があるように思います。過去に構築したシステムの変更や刷新が困難なので、事業の見直しができないといったケースです。事業部門の分離や統合でも、システム面の対応に非常に時間が掛かります。ITが変化対応の足かせになっている面があるのではないでしょうか。

内山それには2つの要因があります。1つはIT部門にかかわるシステムの作り方の問題。もう1つは業務が分かる人が少なくなり、要件が定まらないというビジネス・サイドの問題です。

田口今、お話いただいたシステムの作り方の問題については、SOA（サービス指向アーキテクチャ）という考え方が提唱されています。

内山システムの構成要素、あるいはシステムそのものを部品化、つまりサービス化しておけば、変更要求があった時、対応するサービスだけを新しいものに置き換えたり、修正すればいいのです。部分的な変更であっても、システム全体を見直す必要がある現状に比べて、変化への対応力が高まるというアプローチですね。

これは確かにその通りなのですが、問題はそれができる人がいるかどうかです。SOAの利点を享受するには、サービスの大きさ（粒度）を適切に決めて、サービス同士の連結度がなるべく疎になる形でシステムを設計しなければなりません。しかし、これができる人材、いわゆるITアーキテクトはユーザー企業には極めて少なく、IT業界にも多くはおりません。

田口SOAの考え方による変化対応型システムの構築方法は、主に2つですね。1つはユーザー企業が必要なミドルウェアを買ってきて、その上にサービスを実装したり、既存システムをサービス化するやり方。もう1つはERPパッケージ・ベンダーもSOA指向で自社製品を実装しています。これを使って、既存システムとつなげ、将来の変化に対応するというものです。

内山そうですね。前者の方法はユーザー企業にとっては理想的ですが、実際にやろうとするとITアーキテクチャ・スキルと業務・業種の両方の知識が求められますから、難度は高くなります。一方、1990年代後半にERPパッケージを導入し、現在、大きなシステム改修を行っている企業は、SOAを意識してERPパッケージのモジュールをサービス部品として位置づけているケースが多く見られます。こちらの方がより現実的かも知れません。

ですが、どちらにせよ技術がまだ成熟しているとは言えない段階ですし、先ほども言ったように、高い変化対応力の実現はグランド・デザインする人の能力に掛かっています。ERPパッケージを使ってSOAを実現する場合でも、ベンダー任せにせずユーザー企業がしっかり理解することが重要です。

田口そうしたリスクがあるとすると、SOAにチャレンジするのはもう少し待つべきなのでしょうか。それともユーザーの慣熟度を上げるために、SOAの考え方を少しずつでも入れていく方がいいのでしょうか。

内山システムは構築したら終わりではなく、常に進化するものなので、今からSOAの思想で作り込んでいくべきだと思います。ツールもその間に進化していくし、技術も成熟して新たな考え方も出てくるので、それらを必要に応じて使っていけばよいのです。変化対応の重要な要件の1つが時間ですので、待っているのはまずいでしょう。

田口もう1つの要素である要件を決めるビジネス・サイドの問題についてお話し下さい。

内山1980年代、業務システムを構築するに当たって、伝票や帳票から業務フローをフローチャートに落として要件を策定、そしてシステム開発を行いました。今、業務部門でその作業に携わった人のほとんどが退職しています。それ以降に入社した人は、根幹のシステムが既に存在することを前提にシステムの追加や変更をしてきました。その結果、業務のやり方がシステムに合わせる形になってしまっていて、業務そのものの必要性など、根本にさかのぼっての議論ができない状況にあります。

田口取引先や顧客との関係などが変化する中で、業務そのものが不必要になっている可能性があります。あるいは新規の業務を作るべきなのに、システムがそうなっているからという理由でストップがかかっている可能性もあるでしょう。

内山ええ。多くの企業では、例えば月次で支店別に上がってくる売上高で経営判断するというやり方が受け継がれ、定着しています。でもこれは本当にそうすべきなのでしょうか。ダイナミックな変化の中で、実際には週次の報告が必要になっているかもしれません。要件そのものを根底から見直すことが求められるのです。

田口そうした問題に気づいた企業は、どのように対応しようとしているのでしょうか。

内山非常に基本的なところから、例えば業務部門の社員に業務フローを書かせる訓練から始めています。具体的には、かつて社員研修で行っていたロジカル・シンキングなど、ビジネスの基本となる考え方の整理法から学ばせようとしています。

こうしたことを1回学べば、社員は担当する業務プロセスの前後が見えるようになり、業務を俯瞰して、問題点やムダに気が付くようになります。遠回りに見えますが、企業が直面するダイナミックな変化に対応するには、組織全体の底上げを図り、IT部門に対し業務面からコンサルティングできるくらいのスキルを持った社員を、業務部門の中で育てていく必要があると思います。

田口ERPパッケージにしても、自社の業務に合わないからとカスタマイズするのではなく、なぜパッケージの業務プロセスが合わないのか、自社の業務を見直すべきだという姿勢で見てみる必要があると思います。今の話はそれに通じるものがありますね。

本日はどうもありがとうございました。