パッケージが7、スクラッチ（手作り）が3。
企業が目指すべき基幹系システム構築の“黄金律”が見えてきた。
パッケージを適用しやすい業務で使い、
残りをスクラッチで開発する単純な使い分けでは7：3を実践できない。
パッケージを中心に据えつつ、パッケージとスクラッチのいいとこ取りでシステムを実現する
「パッケージ・ベース開発」の考え方が不可欠だ。
7：3の理想形に向けた最前線を追った。
（島田 優子、田中 淳）
|
本記事は日経コンピュータ6月1日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集1」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。
なお本号のご購入はバックナンバーをご利用ください。
会計、販売、購買、生産、人事・給与といったヒト・モノ・カネを管理し、企業経営を下支えする基幹系システム。言うまでもなく、企業の屋台骨として欠かせない存在だ。
この基幹系システムをERP（統合基幹業務システム）のようなパッケージで開発するか。それともJavaなどの言語を使ってスクラッチ（手作り）で開発するか。システム部門は長い間、二者択一を強いられてきた。
このパッケージかスクラッチかの議論に終止符が打たれる。パッケージを中心として、パッケージとスクラッチのいいとこ取りをする開発方法が現実になってきたからだ。パッケージとスクラッチの境界はあいまいになる。1つのシステムのうち、ある部分をパッケージ、ある部分をスクラッチで作れる。
本特集では、この新たな開発手法を「パッケージ・ベース開発」と呼ぶ。パッケージ・ベース開発で企業が目指すべき新たな基幹系システム全体の理想形は「パッケージが7、スクラッチが3」だ（図）。
 |
| 図●企業の基幹系システムの変遷 [画像のクリックで拡大表示] |
現状ではパッケージ優勢
基幹系システムの構築にパッケージとスクラッチのどちらの方法を使うかという議論自体は、決着したかにみえる。IDCジャパンの調査によると、企業規模や業種を問わず、基幹系システムの構築にパッケージを利用、あるいは利用の意向を表明している企業は60％以上に達する。
基幹系システムはやはり手作り―最近まで、多くの日本企業がこの傾向にあると言われてきた。しかし調査結果を見る限り、優勢なのはパッケージのほうだ。システム部門の人員が減るなか、「パッケージを使ってシステム構築にかかる手間を軽減したい」と考える企業が確実に主流になっている。ERPパッケージの利用が日本で本格的に始まってから10年以上がたち、パッケージは基幹系の分野で完全に市民権を得たといえそうだ。
「当社は長い間、スクラッチで開発してきた。だが、自分で作ることには固執していない」。日清オイリオグループの田崎龍一 情報システム部長は言い切る。日清オイリオは日本オラクルのERPパッケージ「Oracle E-Business Suite（EBS）」で基幹系システムを2004年に刷新。1980年代から約20年続いたスクラッチ文化と決別した。
スクラッチ開発がいまだに大半を占める金融業界。ここでもパッケージを利用したいとの機運が高まっている。住友信託銀行はその1社だ。
「限られた要員をより戦略的なシステムに振り向けるために、パッケージの利用は効果的。特に会計業務は他社と大きく異なるわけでないので、パッケージを使いたい」と渡部信之 システム推進部副部長は打ち明ける。
スクラッチを選ばざるを得ない
一方で、スクラッチへのこだわりを見せる企業も少なくない。卸売業のパルタックKSはその1社だ。
同社にとって、大型物流倉庫の管理システムは重要な基幹系システム。その開発にパッケージの利用は困難だと主張する。執行役員の吉野英行 情報システム本部長がその理由として挙げるのは機能不足。「パッケージのバージョンアップの頻度が、倉庫業務の高度化に追いつかない」（吉野本部長）のである。「多い時は半年に1つ新しい倉庫を作る。そのたびに業務は新しくなる。このスピードに追いつけるパッケージは存在しない」と吉野本部長は話す。
ASP（アプリケーション・サービス・プロバイダ）形式で与信情報を提供するリスクモンスターは「ASPの支援システムは当社の競争力そのもの。パッケージは利用できない」（奥山昌幸 開発ソリューション部長）との考えだ。一方でASPサービスのなかでも「提供開始までのスピードを重視するケースでは、パッケージの利用を考えることもある」（同）という。パルタックKSとリスクモンスターはスクラッチを選んでいるが、パッケージを否定しているわけではない点で共通している。
では、アドオン（追加開発）ソフトの利用やソースコードを改変するモディフィケーションといったカスタマイズにより、パッケージに足りない機能を追加すればよいのだろうか。そうとは限らない。カスタマイズが多すぎると、システムの開発生産性や保守性が悪化したり、プロジェクトがつまずく要因になり得るのは周知の通りだ。
「アドオンはパッケージの機能を生かすために実施するもの。パッケージにない機能をアドオンで作り込むのには限界がある」。ライオン 統合システム部の宇都宮真利 副主席部員はこんな見方を示す。同社は2010年に向け、20年以上スクラッチで開発してきたシステムをパッケージとスクラッチの混在環境で刷新している最中だ。
パッケージ中心でいくしかない
パッケージ、スクラッチともに一長一短がある。だが、スクラッチが主流になるのはもはやあり得ない。IBMビジネスコンサルティングサービス（IBCS）バリュー・デリバリー・センターIIの中山裕之 執行役員は「日本企業を取り巻く環境は変わった。これからはパッケージを中心に考えていくしかない」と指摘する。
環境変化の1つがグローバル化だ。10カ国以上に関連会社を持つカシオ計算機 執行役員の矢澤篤志 業務開発部長は「英語だけでなく中国語、ロシア語など多言語をカバーし、現地の税制に自社で対応するのはスクラッチ開発ではムリ」と話す。同社は現在、会計や購買、販売管理などの基幹系システムに日本オラクルのERPパッケージ「JD Edwards」を利用している。
コンプライアンス（法令順守）も企業が直面している主要な経営課題である。今年4月に適用が始まった日本版SOX法（J-SOX）が代表例だ。J-SOXに対応するために必要な機能をユーザー企業1社で作り込むのは至難の業である。
続きは日経コンピュータ6月1日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
