「服に体を合わせるか，体に服を合わせるか」。業務パッケージ導入を検討する際に，よく出る議論だ。パッケージ（服）に業務（体）を合わせれば，エンドユーザーの使い勝手が著しく落ちることがある。業務にパッケージを合わせようとすれば，カスタマイズが多く発生して，開発やメンテナンスの工数が膨れ上がる。
これが，業務パッケージ導入の難しさとして一般に語られることだ。しかし，パッケージ導入の現場を数多く取材するにつれ，パッケージと現行の業務の間にギャップが多いか少ないか，と，導入の難易度の高さとは，あまり関係がないと思うようになった。
カスタマイズの工数は予測可能
それは，パッケージ導入の現場でSEが何に苦労しているかを見れば分かる。
もちろん，冒頭に挙げたギャップがあるために，SEはエンドユーザーとの折衝には苦労する。Baanのビックバン導入を7カ月で成功させたデンセイ・ラムダの執行役員 情報システム本部長 熊澤壽氏が「社内のあつれきは相当なものだった」と語った言葉には実感がこもっていた。
ただ，カスタマイズの有無は，原則として要件定義フェーズである程度確定させるため，開発フェーズ以降にどの程度の工数が必要になるか予測が付く。カスタマイズが予想以上に膨らんでも，開発の初期段階であればリソースの再配分もしやすい。
また，エンドユーザーが開発プロジェクトに参画していれば，全体最適などパッケージの良さも理解しやすいため，業務の変更も受け入れやすい。そのため，エンドユーザーとの折衝に失敗してプロジェクトが大きく遅延してしまうケースはあまり多くないのである。
それよりも，突発的に発生してプロジェクトを遅延に追い込むことが多いのは，「性能確保」と「データ移行」の作業なのである。この2つをクリアすることが，パッケージ導入の本当の難しさであり，SEが苦労する点なのである。
同じ業務でも使い方次第で性能が変わる
ここでは性能確保について，例を挙げて説明しよう。パッケージはどんな企業でも汎用的に使える機能を提供している。しかし，その機能を実現するソース・コードやデータベース（DB）のテーブル構成は，特定の使い方をする企業に対して最適化して書かれている。
例えばOracle E-Business Suiteには，
SELECT 品目マスター・テーブル. 品目コード, 製造メーカー・テーブル. 製造メーカー名, 製造メーカー・テーブル. 製造メーカー・コード FROM 品目マスター・テーブル, 製造メーカー・テーブル…
というSQL文を発行するプログラムがある。DB技術者なら分かるように，このプログラムは品目マスターと製造メーカーという2つのテーブルをジョインしている。
レコード件数が少なければ問題ないが，それが10万件に達するような使い方をすれば，レスポンスは非常に悪くなってしまう。そのため使い方によっては，片方のテーブルにフィールドを追加してジョインを避けるなどの改造を行った方がよい。これは，アルファパーチェスのシステム構築を手掛けた新日鉄ソリューションズが実際に行ったものである。
もし，こういうことを知らずに，パッケージの機能をそのまま使ってしまうと，ユーザーは性能の悪さに悩まされる。テストやレビュー時，場合によっては稼働後に作り直すハメになってしまう。NTTコムウェアが開発したNTTの人事・給与システムや電通国際情報サービスがSI受託した丸善電機の業務システムなど成功事例としてメディアなどで紹介されているシステムでも，プロジェクトの過程ではこれに類する壁に何度かぶつかっている。
カタログやホワイト・ペーパーからは分からない
こうした壁は，カタログやホワイト・ペーパー上で，パッケージと業務の適合率をいくら分析しても分からない。ギャップがなくてもカスタマイズが必要になることがあるし，その逆もある。ソース・コードやDBのテーブル構造などパッケージの仕組みをSEがどれだけ理解しているかが，プロジェクトの成功を左右する。
「パッケージはブラック・ボックスだから，そんなことは分からない」というのは誤解だ。アプリケーションのソース・コードやDB構造を公開しているメーカーは多いし，パッケージに含まれるミドルウエア部分の挙動などもネットワークやサーバーを監視していれば，ある程度のことは分かる。
つまり，他人が作ったシステムをプログラミング・レベルで解読する眼と，それを最適化する腕が必要なのである。当然のことながら，DBやネットワークなど基本スキルを身に付けていることが前提だ。その意味では，スクラッチ開発よりも高いスキルが必要と言えるだろう。
感覚的に言えば，一つの業務パッケージに精通することは，新しいプログラミング言語を一つ覚えるくらいのスキルに相当する。実際，業務パッケージ導入を成功させた会社の情報システム部には，人材斡旋会社から電話がかかってくることが少なくないそうだ。
（尾崎 憲和＝日経オープンシステム）
