【システム導入の背景】ITによる顧客との密接な連携を目指し、メインフレームからオープンへ。  日本ペイントがどのようにシステム更新を行なったのか、その状況を日本ペイント情報システム部部長の神原謙一氏に伺った。 日本ペイントはメインフレームの導入も早く、昭和40年代前半からのユーザだという。IBMがSystem/360を発売し、メインフレームの歴史の始まりとされているのが昭和39年（1964年）なので、まさに創生期からのユーザということになる。このことは逆に、古いシステムに制約されてしまう面があることも意味する。実際、更新前のメインフレーム・システムでは、30年前に設計されたモジュールが部分的に残っていたほどだ。 日本ペイントの中核事業は自動車用／建築用／構造物用／船舶用／金属素材用／電気機器用／産業機械用／道路用／家庭用などの各種塗料全般の製造／販売である。当然、顧客には自動車メーカーなどが顔を揃える。自動車メーカーといえば、トヨタのカンバン方式など、緻密な物流／調達の制御で有名だ。こうした顧客と密接に連携してビジネスを行なっていくためには、ITシステムの連携も求められてくる。 しかし、日本ペイントの場合は、販売店／販売会社を介して顧客に納入している関係で、顧客と直接情報共有する体制にはなっていなかった。そのため、顧客からは直接の取引相手である販売店／販売会社の情報は取得できるが、その背後にいる日本ペイント本体の情報が分からない、という問題が生じた。例えば、在庫状況などを知ろうにも、販売店／販売会社の在庫はわかっても、日本ペイントの在庫状況は全くわからない。販売店／販売会社が持っている情報が全てという、何とも中途半端だったという。この状況に対して顧客からも「何とかならないか」という声が上がり始めたことが、システム刷新に取り組む直接的なトリガーとなった。 そもそも、日本ペイントでは10年ほど前に情報企画プロジェクトが発足し、情報システムのあり方を検討するという活動に取り組んでいた。これも直接の発端は外部との接続性に欠ける点を問題視したためだという。「当時の情報システム部では、メインフレームのシステムを守るという発想に支配されており、ユーザに対して何かを提供しようという姿勢が希薄なのではないかと感じた」（神原氏）という状況下で検討を続けて得た結論は、「今後のシステムを考える際のキーワードは『オープン化』だろう」ということだった。 ページ先頭へ 【サンを選択した理由】共通機能を抽出し、共有可能にするサーバ・ファームのプラットフォームにサンを選択。  オープン化の方針は経営会議での承認も得られたため、情報企画プロジェクトのメンバーが数人情報システム部に異動して、次世代情報システムの構築に携わることになった。実は、神原氏も情報企画プロジェクトのメンバーであり、このときに情報システム部に加わったとのことである。

日本ペイント株式会社 情報システム部 部長 神原 謙一 氏 株式会社CSK 西日本事業本部 ソリューション事業部 第一開発課 主査 小寺 吉裕 氏 株式会社CSK 西日本事業本部 製造システム事業部 第一開発課 主事 茶木 勝和 氏

しかし、10年前のタイミングは、ちょうど基幹システムに対する大規模な改修が終わったばかりという時期であり、すぐにオープン化に着手するのは難しかった。顧客企業から接続性の欠如について指摘され始めた2年前に、改めて経営会議からの指示があり、新しいインフラ整備がスタートした。情報企画プロジェクトの発足から8年を経て更新プロジェクトが開始されたわけだ。

「すぐに新システムの構築に取りかかれなかったことが幸いし、長期的な視点でシステムのあり方を考えることができた。」（神原氏）ということで、外部との接続性に富み、柔軟性の高いシステムをどう構築すべきかを、様々な情報を収集しながら検討していったという。

その間、IT業界のトレンドはメインフレームを中心にしたホスト・コンピューティングからクライアント／サーバ・モデル、そして分散システムへと変遷していった。その過程を見ながら検討したした結果、選定されたのはUNIXマシンを中心にしたオープン・システムである。ただし、「単にハードウェアをメインフレームからUNIXマシンに置き換えればよいわけではないこともわかっていた。」（神原氏）そうだ。

そしてSIパートナーであるCSKの協力も得ながら、議論を重ねる中でできあがったのが「サーバ・ファーム構想」と呼ばれる基本アーキテクチャである。

CSKは、サーバ・ファーム構想を具体化する際に大きな役割を果たした。CSK西日本事業本部 ソリューション事業部第一開発課主査の小寺吉裕氏と、製造システム事業部第一開発課主事の茶木勝和氏に伺った。

「2001年頃から、次世代インフラ構想を作り始めた。これがサーバ・ファーム構想だ。この構想では、ITインフラに関しても機能ごとに要求仕様を明確化し、単にアプリケーションが動きさえすればよいのではなく、インフラ層の機能のモデル化を徹底し、各アプリケーションで共通する機能をインフラ側に用意しておくことで、変化に強いインフラが構成できると考えた。このインフラ機能をサービスとして提供する、ユーティリティ・コンピューティングの方向性も考慮されている」（小寺氏）。

実際の構築作業は2002年から開始したが、「インフラだけを構築しても価値を生まない」（小寺氏）という事情から、アプリケーションの開発と同時に並行して作業を進めた。

まず最初に更新されたのは物流システムで、この開発に合わせて対応するインフラ部分をまずは小さな形で構築したという。その後、開発が進行するにつれてメインフレーム上で実行されていたアプリケーションが順次新インフラに移行し、それに伴ってインフラ側の拡張も行なわれてきた。

日本ペイントが希望したITインフラとはどのようなものであったのか、CSKの立場から整理してもらった。

日本ペイントが求めるインフラとは、あくまでもユーザ側が主導権を維持するものだった。メーカーによって囲い込まれたりするのは好ましくないという考え方だ。メインフレームでは基本的に1社独占の形になってしまうので、それに対してオープンに自由にユーザがよいものを選べるインフラにするということを念頭に置いた。

また、「スタンダードなコンポーネントを使用していく、という意識が強かった」（小寺氏）という。特殊なコンポーネントを使用することで、将来的にその部分が足かせになることに対する警戒が強かったそうだ。ユーザが主導権を持ち、必要に応じて自由に変更できるインフラとするためには、特殊性を排除して標準品／汎用品を用いて構築する必要があった。例えば、RDBならOracleを選ぶし、UNIXならSolarisを選ぶ、といった具合である。これは当然、将来システムの保守管理を担当する業者が変更されても全く支障がないように、という配慮もある。

「スタンダードを別の言葉で表現すれば、『長く生き続けるもの』ということだ。出来合いのパッケージ・アプリケーションを導入した場合、開発元の体制によっては、OSのバージョンアップさえも『動作保証されていないのでできない』ということが起こり得る。こうしたリスクを最小限にとどめるためにも、標準的なコンポーネントを使用することに留意した。」（茶木氏）

サーバ・ファーム構想の基本的な考え方は、「システムに必要となる共通機能を抽出し、共有可能にする」ということであり、基本的な設計方針は、オブジェクト指向的な考え方にある。ITインフラが持つべき機能をオブジェクトのように定義し、その処理内容とインタフェースを明確化しておく、というイメージで捉えればよいだろうか。こうすることで、特定の機能に変更を加える場合でも他の部分に与える影響を最小限にとどめ、変化に対して柔軟に対応可能なシステムとすることができる。

クリックで拡大
	サーバ・ファーム構想の機能モデル 必要な機能とその連携を論理的に定義した。

コンセプト・レベルの基本設計であるサーバ・ファーム構想を実際のシステムに落とし込んでいく際には、構成要素となる「機能」を「製品」にマッピングしていき、求める機能が実現されるように組み合わせていく必要がある。

こうした背景を受け、Sun Java Enterprise Systemを導入することを決断させた直接のきっかけは、ポータル・サーバの構築コストだったという。神原氏によれば、もともと日本ペイント社内の塗料開発のための研究開発部門では、サンのシステムが利用されていたという。そこで実績のある評価も踏まえ、基本的なプラットフォーム・アーキテクチャは UNIXのデファクト・スタンダードであるSPARC[R]／Solarisを使用することが決定された。

サンの価値を構成するファイナンス・ソリューション

またサン・マイクロシステムズ・ファイナンス株式会社が日本ペイントの予算とコスト・コントロールに沿ったファイナンシャル・サービスを提供してくれたこともサンを選択する大きな理由となった。結果、導入コストの支払いを翌年度に繰り延べ、予算への不可を軽減するとともに、早期導入が可能となった。またユーザ主導でシステム開発を行えることも大きな魅力だった

ページ先頭へ

【システム導入の効果】新アプリケーションの開発期間を短縮でき、端末の設置場所やOS環境の制約からも解放。 

システムの開発作業を行っている途中の段階で、Sun Java Enterprise Systemが発表され、そこにメリットを見いだした結果、急遽Sun Java Enterprise Systemで新しいオープンシステムのミドルウェア製品群をカバーするという対応になったという。それは、最初に構築を完了した物流システムが稼動開始したときに見えてきた問題に起因している。

使っていくうちに、さらに拡張していくためにはサンの他のソフトウェア製品、具体的にはMessaging ServerやCluster、Portal Serverなどが必要になることが見えてきた。そこで、個別にいくつかのソフトウェアを購入して検証が開始されたのだが、そこで意外にコストがかさむことが問題になった。

Portal Serverは、新技術のメリットを期待して導入されたブレード・サーバ上で実行されることになったが、当時ブレード・サーバも出荷が始まったばかりで、 Portal Serverを動作させた実績に乏しく、1枚のブレードでどのくらいの負荷に耐えられるのかのデータもなかったという。全ユーザからのアクセスをまとめて受け付けるPortal Serverのパフォーマンスの低下は、業務に影響を及ぼす重大な問題だが、Portal Serverとしてブレードを何枚割り当てればよいか、事前に確実な予測を行なうことは困難だったわけだ。

それに加えて、「Portal Serverソフトウェアはどのベンダーの製品もかなり高い」（神原氏）という問題があり、予算の問題もあってむやみやたらに購入することもできなかった。「データがないので何台のサーバが必要かわからないし、Portal Serverを何ライセンス購入すればよいかも判断できなかった」（神原氏）のである。

実際に稼動を開始したあとで実は処理能力が不足しているとわかっても、Portal Serverを追加購入すると予算オーバーになってしまいかねない状態だったという。そこに、Sun Java Enterprise Systemが登場した。このサーバ・ソフトウェア・ソリューションは従業員数に応じたライセンス料を支払えば、実際にどのソフトウェアを何台のサーバで使っても構わない。これなら、コストの心配なしに、必要に応じて自由にサーバの台数を増やしていくことができる。「これでかなり気が楽になった」（神原氏）というのもよくわかる話だ。Sun Java Enterprise Systemの導入のきっかけは、そのコスト・パフォーマンスの高さにあったことがわかる。

また、Sun Java Enterprise Systemに関しては、「サンのソフトウェア・ビジネスは『素材提供型』というべきスタンスだと思う。他社では、ポータル1つとっても『Portal Serverはこれ、DBはこれ』といったひとかたまりのセットで持ってくるのだが、サンではあくまでも素材として位置づけ、うまく組み合わせて使ってくれという感じだ。だからこそ、Sun Java Enterprise Systemという形で素材がまとめて提供されるのは、使う側にとっても大きなメリットだ」（小寺氏）という評価も聞かれた。

システムの導入においては、「標準的な、スタンダードなコンポーネントを」という意向から、例えば運用監視システムひとつをとってみても、シェルスクリプトなど、標準的な技法のみで実現するよう工夫している。これも、いざデータセンターを移転したいとなった場合に足かせになるような要因を持ち込まない、というポリシーからくるもので、「ユーザの自由な選択肢」を確保し、ユーザ主導のシステム開発を実現するための策のひとつである。

日本ペイントのITインフラ刷新はまだ進行中のプロジェクトだが、ここまでの段階でも大きな成果を上げ始めている。

メインフレームで稼動していたシステムでは、外部の接続性に制約があることや、社内のユーザからの要望に応じて改修を行なうのも困難だった。例えば、現場から「こういう帳票を出力できるようにしてほしい」という要望があっても、開発を行なって実際に提供できるのは2カ月後、といった状況が当たり前だったという。こうした状況を改善し、接続性に富み、柔軟な変更に対応可能なITインフラを構築することを目指した日本ペイントのシステム更新は、基本的にはメインフレーム上で動いているシステムを全て新しいITに載せ替え、まずはインフラ部分の刷新に集中する、という方針で実施された。

システムの業務ロジック部分には大きな変更はないのだが、ITインフラが変更されたことでメリットも生じている。例えば、クライアント・アプリケーションがWebベースになったことで、ユーザが使用する端末の設置場所やOS環境などの制約を受けなくなったなどだ。

サンは、UNIXのデファクト・スタンダードであるSPARC／SolarisとSun Java Enterprise Systemでメインフレームのオープン化を推進する日本ペイントをこれからも支えていく。

ページ先頭へ

クリックで拡大		クリックで拡大
受発注／在庫管理システムの構成図 3階層モデルに基づいたレイヤ構造で、サーバはほぼ全てが二重化されている。 ネットワークも、SolarisのIPMP機能を利用して二重化される。		データセンターに置かれたサンのサーバ群。 高速ネットワーク配線が先行配線された使いやすいラックに、余裕を持たせてサーバを配置する。

Sun Java Enterprise Systemとは

サンは、2003年10月に、200種類以上にものぼるソフトウェア製品や関連サービスを整理し、新たにSun Java Systemとしてパッケージに統合した。Sun Java Enterprise System、Sun Java Desktop System、Sun Java Mobility System、Sun Java Studio、Sun Java Card Systemである。なかでもSun Java Enterprise Systemは中核的な存在で、エンタープライズ・システムを集約したものだ。

具体的な内容は、これまで独立した製品として販売されてきた各種のミドルウェア製品などのソフトウェアで、多数の製品をワンパッケージにまとめたものである。

Sun Java Enterprise Systemの特徴は、パッケージに含まれるソフトウェア・コンポーネント間で整合性と最適化が図られており、あらかじめ予定されたスケジュールに従ってバージョンアップが行なわれるという点だ。同時にリリースされる各コンポーネントは互換性検証を受けており、組み合わせて利用する際に不整合を起こすことがないようあらかじめ十分なテストを受けて出荷される。このため、ユーザ側で検証を行なう負担が大幅に軽減される。

ライセンスにも工夫が凝らされている。Sun Java Enterprise Systemでは、サーバの台数やプロセッサ数といった基準ではなく、ユーザ企業のユーザ数に応じて価格が決定される。具体的には、従業員1人あたり年間 1万1,000円となる。従業員100名の企業なら年間110万円、従業員1,000人の企業であれば年間1,100万円という具合だ。このため、負荷が高まったとかサーバの台数を増加したといった利用環境の変化があっても、支払額は一定に維持できるので、コスト管理が容易になる。しかも、多くの場合は従来の個別ライセンスの合計額よりも安価になるように設定されている。

ユニークな価格設定で話題を集めたSun Java Enterprise Systemだが、昨年発表されたばかりということもあり、導入実績ができあがるのを待っている状況だったが、国内で最初に運用に踏み切ったのが日本ペイントということになる。

本記事は、月刊オープン・エンタープライズ・マガジン2004年7月号「Industry＆Enterprise」の原稿をもとに、再編集・加筆したものです。

本誌の全部または一部をサン・マイクロシステムズ株式会社の許可なく、無断で転用することは禁止します。

© 2006 Sun Microsystems, Inc. All rights reserved. ●Sun、Sun Microsystems、サンのロゴマーク、Solaris、Solarisのロゴマーク、Java、Java Coffee Cupのロゴマーク、Sun Fireは、米国Sun Microsystems, Inc.の米国およびその他の国における商標または登録商標です。●すべてのSPARC商標は、米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は、米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。●本文中に記載の各社の社名、製品名は、各社の商標または登録商標です。

ご意見・ご感想をお聞かせください

この記事は参考になりましたか？ 参考にならない   参考になった   非常に参考になった コメントがございましたらご記入ください

ページ先頭へ