データ統合の実現
こうした状況から中野氏は、ToBe（図3）として「統合と連携」をキーワードに進めた。まずは、外資系のさまざまな企業の社内システムを見学したという。「『突撃 隣の社内システム』みたいな感じで訪問し、いろいろな社内システムを見学させてもらった。ヒアリングする中で、まずレベルが完全に違うことが分かってきた。その差を例えるなら、虎と猫くらいに違う。システムの作りも違うし、システムを作るアーキテクチャや経営思想、考え方が違う。システム投資に対する根本的な考え方も違い、システム部門のあり方も全然違っていた」（中野氏）
図3
こうした経緯を踏まえて中野氏が、どうしていくかを考えたのがToBeに挙げた3点だ。一見するとASISの課題をひっくり返しただけだが、まずは「システム連携をきちんとする」という点だ。ここはInformaticaのソリューション導入に関わるところだが、データを適切にし、そのデータをもとに、「データを使える、活用ができる」状態にしていくことにToBeを置いたという。また海外に関しても、単一のプラットフォームで海外に提供できるシステムを目指した。
ToBeを目指す取り組みは、「5並列刷新プロジェクト」という少々“やんちゃ”なものだった（図4）。ERP（統合基幹業務システム）とSalesforceを導入していたが、Salesforceはきちんと使えていなかったといい、これを再構築した。サービスではチケット関係にRedmineやスプレッドシートなどをバラバラに使用しており、Workday側で吸収できないようなワークフローなどもあったという。ここでは、まずServiceNowに整理するといったことから検討するなど、システム連携の見直しから着手した。
図4
システム連携を大きく分けると、「データ連係」と「アカウント連携」の2つがあった。当時はこの2つを中心に考え、特にデータ連係の部分を重視していたという。
「データ連係の部分をエンジニアに自由に作らせると“俺様仕様”となってしまい、あちこちにリソースが増えていって統合が取れなくなったり、開発したエンジニアがいなくなった途端に何も分からなくなったりするなどの問題が生じる。SaaS型のAPIの仕様が変わった途端にデータ連係がつまずいて業務が止まるといった状況に陥るリスクも考えられ、“標準化”を方針にした」（中野氏）
ここでの大方針は、システム構成自体をグローバルベースで再構成しつつ、システムを継続的に改善できる組織を作るということだった。また、もう少し細かいところでは、システム選定時の必須要件として、システム運用を可能な限り省力化することを決めていた。そのためパッケージシステムは、“パッケージ”である時点で選定から外したという。その理由は、バージョンアップや技術検証の手間を回避するためだったという。
例えば、システム連携の点で「APIがない」「シングルサインオンできない」システムは選定候補から除外した。当然ながら、「APIがない」というのは、他のシステムと連携できないからだ。
「日本ではよくパートナーやベンダーの営業さんが『システム連携できます』と言うが、『本当にできますか？』と聞くと、『いや、CSVです』とかいう話になる。それはシステム連携とは言わないし、『シングルサインオンって何ですか？』っていう状況になることもある」（中野氏）
また、海外でも同じシステムを利用できるという条件もかなり厳しいものだという。実はこの条件を設定すると、国産システムはほぼ候補から外れてしまう。
「将来的に、例えばインドやシンガポールに開発拠点やサポート拠点を移すとなった場合、英語で仕事ができるシステムなのかと考えると、その時点で国産システムはほぼ選べない。同時に、日本にサポート拠点がないようなシステムは導入に失敗しかねないことや2バイトコードへの対応といった問題もある。海外ではメジャーでも日本に拠点がないようなベンダーのシステムもリスクが高い」（中野氏）
図5
最終的に同社のシステム構成は、図5のようになった。Workdayでサービス間連携を実現しているが、ポイントはInformaticaによるデータ連携の部分にある。中野氏は、「WorkdayやSalesforceに関心を持つ企業は多いが、データ連携に興味を持つところは少ない。しかし終わってから振り返ると、ここが実はすごく重要なポイントだった」と話す。
同氏によれば、グローバルなシステムでは、デファクトスタンダードのシステムをいかに組み合わせて使い切るかがポイントになるというものの、システムの組み合わせる上でInformaticaが重要な役割を担っており、そのためにデータ連携の標準化も行ったという。また、全部クラウドのシステムで実現するという方針もあった。
