欧米と日本の“いいとこ取り”でIT化を加速 ライフネット生命のCIOが取り組む、システム内製化への道（4/5 ページ）

[吉村哲樹，ITmedia]

意外と難しい「コア業務」と「ノンコア業務」の切り分け

馬場：　保険業界では、日本企業が海外企業を買収するケースも多いのですが、成果が出ている買収案件は決して多くないとされています。日本の金融機関による海外企業の買収は、「買いっ放し」が多く、買った後に、グローバルのシナジー効果を生み出すための施策をうまく打ち出せていないように見えていて「ちょっともったいないな」と思うこともあります。

中野：　海外企業が他社を買収した場合は、かなり大胆に統合しますよね。コモディティ業務に関しては、人もシステムも統合してコストをカットして、基幹システムにはERPを入れる。買収されると親会社から最初に来るのが「うちのシステムに乗ってね」というオーダーだったりする。

　ビジネス戦略も、グローバルで一貫性を持たせるようにしていますよね。そうしないと買収によるシナジー効果は生まれませんし、そもそも買収した意味がありません。

　あるいはソフトバンクグループのように、買収した企業の裏側のシステムにはあまり手を付けない例もありますが、あれは事業ポートフォリオを増やすための投資だと割り切っているのかもしれません。疎結合を前提にしてるように見えます。密結合させると、売却などで分離する際に、手間がかかるからかもしれません。

馬場：　中途半端にくっつけようとするのが最も悪手ですね。一方、製造系の企業はERPによるグローバル統合はわりとうまく行っているケースが多いように思います。

中野：　製造業でも、生産や販売の業務に関しては各国の商習慣や文化の違いが顕著に表れるので、統合に苦労するケースが多いと聞きます。それに比べれば、人事や会計などのバックオフィス系の業務は比較的統合しやすいでしょうね。

　ただ、これらの業務の中にもそれぞれ“コア”の業務と“ノンコア”の業務があって、例えば人事関連なら採用や評価の仕事は自社の競争力に直結するコア業務ですし、各国の事情が深く絡んできますから統合が難しいこともあります。

　例えば、財務会計・給与計算などはノンコア業務ですから、統合やアウトソースの方針を入れて設計すべきなのでしょう。

　ただ、「ノンコア」を語るときにはっきりさせておくべきは、「ノンコア＝重要ではない」というわけではないことです。

　経理や労務、ヘルプデスクの業務は会社を支える基本的な業務です。例えば、給与支払いや決算がままならなかったり、端末管理にひもづくようなセキュリティ運用がまともにできないような会社は、いくら業績が良くて崇高な理念を掲げていても、まっとうな企業とはいえないでしょう。

　財務会計がしっかりしていないと管理会計など出せないですし、労務管理がしっかりしていなければ、まともな採用や評価はできません。ここの基本がきちんと機能していなければ、事業の土台が揺らぎます。

　つまりノンコアとは、「施策における方針の違い」を表すものなのです。各社の個別要件を別々に実装するよりも、「可能な限り集約し、標準化して、効率よく行うべき領域」ということです。

馬場：　コア・ノンコア議論で悩ましいのが、明らかなノンコア業務であっても、ある程度の業務規模がないと、アウトソースしてもコストに見合わないんですよね。ライフネット生命は、その意味では中小規模の企業なので、アウトソースしてもペイできないケースが多いのです。

中野：　これは本当に難しい問題ですね。標準化・集約が前提となる以上、「規模の経済」の理論が働くので、内部で手掛けた方が単純に安いケースもある。

　でも、「アウトソースするより内製の方が安いから」といって人を雇い入れることにしたものの、企業の成長に人の採用が間に合わずに自転車操業状態になったりするケースもあります。その後、ビジネスが成長したからアウトソースしようと思っても、米国企業のように人を解雇して組織を縮小できるわけではありません。

　従って、たとえビジネス規模が小さくてもノンコア業務をアウトソースしてコストメリットを出しやすくするよう、国はムダにプロセスを煩雑化させるようなルールをなるべく撤廃するべきですし、企業側にもノンコア業務を切り出しやすくする工夫が求められるでしょう。

　大企業だけではなく、小規模の企業でもアウトソースがうまく機能するように、プロセスとルールを作っていくことが必要だと思います。

　例えば、企業規模に合わない複雑な制度（福利厚生・人事評価・報酬）を作ったり、効果があるか分からない社内規定がたくさん存在したり、組織構造が論理的に破綻していたり――というのは、システム化の大敵です。こうした煩雑化した業務はシステムに載せるのが難しくなるので、結局、人手が必要になってしまう。ノンコア領域では、人手がかかる運用を強いられるようなことは避けるべきです。

馬場：　当社の中でも今、コア業務とノンコア業務を明確に分けようとしているのですが、現場から理解を得るのはなかなか難しそうです。明らかに顧客価値には直結しないノンコア業務であっても、それを実際に回している現場の担当者の目には「このオペレーションがなくなったら全体が回らなくなってしまう！」と映る。たとえなくなったら困る仕事でも、「とっかえひっかえ」できるものはあります。でもこのことを現場に理解してもらうには、少し時間が必要かもしれません。

中野：　私がかつて所属していたWebサービス企業で、基幹システムの刷新プロジェクトを手掛けたときも、同じようなことを経験しました。大手グローバル企業が採用しているのと同じ海外製パッケージ製品を導入したのですが、製品の仕様としてコア業務・ノンコア業務が明確に区別されていて、しかもそれをカスタマイズせずにそのまま入れたので、現場の業務には想定していたこととはいえ、かなり大きな影響が出ました。

　でも、思い切ってカスタマイズせずにパッケージの機能をそのまま使ったおかげで、システムは安定しましたし、何よりオペレーション、特に監査や連結が必要な業務に対する効果は大きかったと思います。データが一元化され、監査機能が整備されたことによって迅速な対応が可能になりました。

馬場：　日本企業は、せっかくパッケージ製品を入れても、カスタマイズを大量に行うのでアプリケーションの運用がとても複雑になってしまいますよね。そのため、せっかく採用した優秀なIT人材が、アプリケーションの運用に忙殺されてしまっている。

　こうなってしまう主な原因は、アプリケーションの開発者が設計段階で運用のことを考えていないからだと思います。金融ではITにまつわるリスクを回避するために、システムの運用と開発を分離する「運開分離」が必須だといわれています。しかし、本来、求められているのは「リスクの排除」であって、「運用と開発の分離」はそのための1つの方法に過ぎません。

　従って、リスク低減策さえきちんと講じていれば、本来は運用と開発を無理やり分離する必要はなく、DevOpsだって実現できるはずです。

中野：　監査機能などを適切に入れていけばクリアできるかもしれませんよね。それに運用と開発を完全に分けてしまうと、システムトラブルが発生した際に問題の切り分けが難しくなりますから、さらに余計なリスクを抱え込むことになってしまいます。