グローバル・プロジェクトの実務ノウハウ

五嶋仁

高木右近日向

前回は、現地の専門家たちと上手に付き合う方法を取り上げました。今回は、海外プロジェクトでは通用しない「日本独特」のIT技術についてを見ていきます。

日本と同様のアドオン開発ができるエンジニアはいない

パッケージソフトに対する追加開発において、日本より長けている国は他にありません。

私たちがよく利用するOracle E-Business Suite（EBS）を例に挙げると、各テーブルに追加できる項目は15までと決まっていますが、それだけでは足りないことが多く、各項目のなかを“｜”（パイプ）で区切って、さらに細分化することさえあります。これは「付加項目」（ユーザー業務で利用する標準以外の項目を追加できるよう、あらかじめパッケージが用意している項目）ですので、問題はないのですが、しかしそこまでする国は、私たちの知る限りでは日本だけでしょう。

日本のERP技術者にとっての腕の見せ所は、パッケージソフトにいかに上手にアドオンを組み込むかだといえます。また設計者や開発者も、それぞれのパッケージへのアドオン手法やルールを蓄積し、洗練させてきました。

ところが海外では、一般的にアドオン開発を避ける傾向にあります。

1つはITエンジニアの流動性が高い、つまりすぐに転職してしまうので、その会社固有のアドオン仕様についてのノウハウが引き継がれない恐れがあるからです。

また、これは日本でもよく言われることですが、運用・保守のコストが高くつくからです。ERPパッケージのメジャー・バージョンアップがあると、アドオン開発した部分の見直しやテストが発生します。

とはいえ、海外でも業務上の都合でERPパッケージを改修することがあります。この場合、海外にはアドオン開発ノウハウがないので、日本では逆に御法度になっていることをします。例えば、DBトリガーを利用（すなわちデータベースに直接アクセス）したり、パッケージに対してハードコーディングをしたりするのです。

これを私たちはアドオンと区別するためにモディファイと呼んでいますが、パッケージベンダーの保証範囲でなくなるので絶対に避けなければならないことです。

グローバル・プロジェクトでERPパッケージに手を加えたい場合には、海外では日本と同様のアドオン開発ノウハウを持ったITエンジニアは基本的に存在せず、無理に要求すると日本では考えられない方法で実装しようとすることを踏まえておきましょう。そのうえで、しっかりとした方針を立てるべきです。

海外では複雑なジョブスケジューリングは行わない!?

バッチジョブをジョブスケジューラーで自動実行するのは、日本も海外も同じです。しかし、日本人が考えるようなジョブスケジューリングが海外でも必要になるかというと、そうでもありません。

日本のジョブスケジュールは、樹形図のように細かくさまざまな条件分岐をしながら、各プログラムが正しい順序で実行されるように精緻に組み上げられています。それ自体がやや複雑なプログラムのようで、名人芸といっても過言ではありません。

ところが海外では、このような精緻なジョブスケジュールが作られることはまずありません。日次・週次のサイクルと開始時間でプログラムがグルーピングされている程度です。日本人が見ると、実行されない処理があったり、データベースに矛盾が出たりするのではないかと心配になりますが、そのようなことがあっても、ジョブの実行頻度を上げることで、次で拾えればいいという思想が根底にあることを認識すべきです。

日本のジョブスケジュールが複雑になる理由は、それだけではありません。海外、特にアメリカでは、請求後30日以内に支払いといった形態が多いのに対して、日本では月末締め翌月末払いという形態が普通のため、月次バッチ処理が大量で複雑にならざるを得ないのです。月次処理は請求処理だけではなく、その他にもたくさんあるので、より一層複雑になります。

一方、海外では、会計処理のために月末集計を行うぐらいなので、エラーが発生してもやり直せばいいだけという考え方になります。

日本と海外ではシステム運用の思想が根本的に違うところがあります。少なくとも海外では特定の職人的な運用管理者の存在を前提とせず、誰にでも運用できることに重きをおきます。

グローバル・プロジェクトの運用設計を考える際には、このことを考慮に入れておく必要があります。

<<[第6回]を読む  [第8回]を読む>>

サービス・ソリューションに関するお問い合わせ