Workdayのファイナンスにクラウド版Informatica、壮絶な“初物導入の舞台裏”全部見せます：怒濤の5並列プロジェクトを振り返る（7/8 ページ）

» 2019年07月04日 12時00分 公開
前のページへ 1|2|3|4|5|6|7|8 次のページへ

パッケージ間のデータ連携に一苦労

　今回のプロジェクトでは、パッケージ単体の導入と並んで、各パッケージ間のデータ連携も新たに設計し、実装する必要があった。この点について、「プロジェクトの初期段階で、データ連携についてもっと深く議論するべきだった」と指摘する声も挙がった。開発を担当したパートナー企業のプロジェクトメンバーからは、以下のような声が挙がった。

　「今回のプロジェクトではWorday、Salesforce.com、ServiceNowと複数のパッケージアプリケーションを使いましたが、当然のことながらそれぞれの製品ごとにデータベースのデータ項目もコードも異なります。ですから、本来はパッケージ製品間のデータ構造の違いを、早い段階からすり合わせるべきでした。そこを曖昧にしたままプロジェクトを進めてしまった結果、いざ、データを連携させる段階になって、そう簡単に実現できないことが判明しました。

　例えば、同じ『取引先』という名前のデータ項目でも、製品ごとに微妙に意味や扱い方が違うんですね。そういう点を考慮せずにデータを連携させてしまった結果、おかしなことになってしまい、慌てて対処するということが現場でたびたび起こりました」（クックパッドのIntegration担当者）

　白川氏によれば、こうした問題はこれまで同氏が担当したプロジェクトでもたびたび発生してきたという。その最大の原因として、同氏は「異なるパッケージ製品のデータ構造を把握している人がいない」ことを挙げる。

　「同じような問題は、旧システムから新システムへデータを移行する際にもよく起こります。データ移行元のシステムと移行先のシステムのデータ構造を両方把握している人がいれば、こうした問題は起こりません。データ連携も同様で、連携する複数のシステムのデータ構造を、1人の人間が全て把握できていれば、認識の食い違いも発生しないのですが、実際にはそういう人はめったにいません。ましてや、今回のように初物の製品ではなおさらです。

　そこで、事前にあらかじめ各システムの担当者が集まって、データ構造のすり合わせをしておく必要があるのですが、それでも全ての問題をあらかじめ洗い出すのは困難です。というのは、1つのシステムのデータ構造しか知らない人にとって、例えば『取引先』というデータ項目の扱いが別のシステムではまったく異なることなんて、事前には想像がつかないからです。

　実際にはデータを移行し、連携させてみて、初めて互いの認識の違いが発覚します。従って、私はそういう問題が後になって出てくるのは避けられないと考えています。そこで、その手の問題が発覚したときに『いかに素早く対処するか』に力点を置くようにしています」（白川氏）

　なお、今回のプロジェクトでは、アプリケーション同士で直接データを連携するのではなく、データ連携製品を介してデータ連携を実装する方式をとっている。これには、中野氏のデータ連携に対するこだわりが反映されているという。

　「基幹システムの構築について語る際、『ERP製品はどれを選べばいいか』『人事システムには何を使えばいいか』といった話はよく出るのですが、データ連携の話はあまり出てきません。しかし、一定以上の規模の業務システムになると、システム間のデータ連携を手動で行うわけにはいきません。必ずデータ連携を実装しなければならなくなるのに、あまりデータ連携について語られることがないことには違和感を覚えますね」（中野氏）

　なお、一部のプロジェクトメンバーからは「本来はデータハブを持つべきだったのではないか？」との意見も出ており、これに対して今回のプロジェクトで導入したデータ連携製品の担当者（Informatica）は、「今思うと、もっといいやり方があったのかもしれない」と当時を振り返る。

　「中央にデータハブを配置して、疎結合のデータ連携アーキテクチャを採用していれば、こうした問題の大半は回避できたかもしれません。そうした提案が、当時、できなかった点は、反省材料だと思います。今後、クラウドサービスがさらに普及すると、クラウド側のデータ構造の変更にデータ連携製品もいち早く対応していかなくてはならなくなります。そうなると、今後ますますデータ連携製品の重要性は増してくると考えています」（Informaticaの導入担当者）

グローバルシステム特有の「時差」の問題

　グローバルで運用するシステムに付き物なのが、「時差をどう捉えるか」という問題だ。

　例えば日本国内でシステムを運用する限りは、日本の夜間にバッチ処理やメンテナンス作業を問題なく実行できるが、これがグローバルシステムになると、時差の関係で日本の夜間が他国の日中になることもあるため、そう簡単にシステムを止めたりバッチを流すことができなくなる。こうしたグローバルで運用するシステムに固有の運用の在り方について、「当初は考慮が足りなかったのではないか」と指摘する声が挙がった。

　また、日本と他国で日付がずれるタイミングもあり、それが業務やシステム運用に混乱をもたらすケースも考えられる。こうした課題について、製品ベンダーの担当者は以下のように指摘する。

　「今回、導入していただいた弊社の製品はクラウドアプリケーションで、本社のある米国西海岸時間を基準に稼働しています。アプリケーションそのものは、この標準時間を基準にしているので、特に何の矛盾もなく動作します。しかし、グローバルな運用環境で、外部との連携を図ろうとした途端に、いろいろと面倒なことが起こります。

　例えば、アプリケーションが『4月1日に公開される社内情報』を管理していたとします。日本では、日本時間の4月1日0時をもってその情報を参照可能になりますが、米国ではその時点ではまだ3月31日なので情報を参照できません。こうしたズレが生じることが多々あるので、グローバル環境で運用する際にはこうした課題を念頭に置いたルール作りが求められます。今回のプロジェクトでは、実装段階になってこうした問題が顕在化しましたが、本来はもっと前の段階で意識を合わせておくべきだったと思います」（Informaticaの製品ベンダー担当者）

前のページへ 1|2|3|4|5|6|7|8 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ