JFE 技報 No. 14（2006 年 11 月）p. 21–24

J-Smile を支える IT イノベーション（テクノロジ）
̶大規模基幹システムへの Web 技術適用̶
Web Technologies Applied for Large-scale Information System原田敬太 HARADA Keita

JFE スチール

IT 改革推進部

主任部員
（部長）

森本哲也

MORIMOTO Tetsuya

JFE スチール

IT 改革推進部

主任部員
（副部長）

大川浩志

OHKAWA Hiroshi

エクサ

第一事業部

鉄鋼システム第一開発部基盤チーム

チームマネージャー

要旨
新統合システムの開発・稼働基盤構築の過程では，開発生産性，システム品質，パフォーマンス，稼働後の環境変化に対する柔軟性など，多くの解決すべき課題があった。これらに対し，グローバルスタンダードの積極的採用，最適な稼働プラットフォームの選定，全面的な Web システム化，java フレームワークの整備，開発フェーズ全般の標準化などにより，当初の課題を解決した。

Abstract:
In the process of platform construction of a new integrated system, many tasks such as the productivity ofdevelopment, system quality and its flexibility were tackled. These were solved by adopting the global standard,improving java framework, standardizing developmental phases, and selecting the optimum platform.

基盤として実現すべき価値

1. はじめに2 社のシステム基盤統合

大規模基幹システムの短工期開発

柔軟なシステム構造実現

JFE スチールの本社業務のほぼ全領域にわたる大規模基IT 動向
・コンピュータ能力の向上
・技術の標準規格化進展

新統合システムの基盤方針…最新 ITを積極的に採用

幹システムの再構築を短期間に高品質で実現し，かつ今後の環境変化に迅速に対応し得る柔軟性を確保するための，開発・稼働基盤整備に注力した。JFE グループで過去に例がない大規模なシステム再構築に対し，多少チャレンジングな要素もあったが積極的に最新の技術や製品を採用し，設計方法論

開発・実装

プラットフォームシステム結合基盤

・データモデル重視の設計
・独自フレームワークの整備

・java など標準技術を積極採用
・リアルタイム化を志向
・実装フェーズの標準化

・3 階層構造・DB はメインフ
レームに一元化・AP, PKG サーバ
は特性に応じて選択・EAI パッケージを導入
・旧システムとのコンバート処理を集約

Fig. 1

プロジェクト全体の目標達成に基盤面からも寄与すること

Revolution of IT infrastructureができた。
持ったコンピュータを新たに導入して対応した。

2. 開発・稼働基盤の構築方針

設計，開発・実装のほぼ全フェーズの標準化を行うとともに，java 言語での開発生産性，品質向上を目的としたフ基盤領域ではコンピュータの能力向上を十分活用しつレームワーク整備を行った。

つ，グローバルスタンダードを積極的に採用することで，既存周辺システムとのデータ授受では現行インタフェー所期の目標達成を図った。Fig. 1 に基盤領域構築の考え方

ス仕様を保証する必要があり，新旧コード間の変換処理がを示す。
システム全体のリアル処理化ニーズ，利用者の利便性向上，および最新技術適用容易性や将来性を考慮し，新統合システムは Web ベースの java アプリケーションとすることを基本とし，3 階層構造のシステムとした。java アプリケーションは従来の COBOL アプリケーションの数倍のコンピュータ資源を必要とするが，必要十分な能力と拡張性をIBM，AIX，WebSphere，MQSeries，AIX，DB2，z/OS，および，zSeries は，IBM Corporation の商標である。
Microsoft，Windowsは，Microsoft Corporation の米国およびその他の国における商標である。
UNIX は，The Open Group がライセンスしている米国およびその他の国における登録商標である。
Solaris，Java，および，すべての Java 関連の商標およびロゴは，SunMicrosystems, Inc. の米国およびその他の国における商標または登録商標である。
Curlは住商情報システム株式会社の登録商標または商標である。

− 21 −

J-Smile を支える IT イノベーション（テクノロジ）̶大規模基幹システムへの Web 技術適用̶

分離
一部の修正が全体に影響を及ぼさない重視した観点

実現手段・プラットフォームとAP の分離・AP 間の分離

フレームワーク整備
J2EE 準拠

計画サーバ（i2, Oracle/Solaris）

COBOL 区画MQ
ファイル転送COBOL Application
EDI

柔軟性

局所化

・AP 修正の局所化
一事実の修正は ・AP と DB の分離
一個所を修正・データ保有の局所化
すればよい
・コード修正の局所化

モデル重視
モデルが全体を制御

Fig. 2

製鉄所
製造所

RDB

処理パターン化DB アクセスクラス
DB 正規化，コード設計

Java 区画× 2

Java Application

EAI サーバ（webMethods/Windows）

WebServices

ブラウザ
IE, Curl

電子帳票サーバ（SVF, FiBridge/AIX）

社内ユーザ

WebSphere・アプリケーションモデル 概念モデルでの統制の重視
処理パターンによる可読性向上
・データモデルの重視
ビジネスモデル層の一元管理

商社
需要家

統合
セキュリティシステム

zSeries 990（zOS）

Internet

Policy for flexible structure
Fig. 3

ブラウザ
IE, CurlSystem structure必要である。また，システム間接続の切り替えにも柔軟にメインフレーム（z/OS）およびサーバ（AIX）とするなど，対応可能とする必要があった。これに対しては，独自開java アプリケーションのハードウェアプラットフォームか発とせず，enterprise application integration（以下，EAI）らの独立性を実現できている。

パッケージを導入することで対応した。

計画系，経理系システムはパッケージ製品を導入しておFig. 2 に示すとおり，システムの柔軟性実現に対しては，り，これらはそれぞれ独立した UNIX サーバにて運用して特に「適切なモデリングとその具現化」が重要なポイントいる。また，電子帳票サーバ，EAI サーバなどの周辺系もと認識し，初期の分析・モデリングフェーズの作業に重点UNIX，Windows サーバとするなど，それぞれの特性に応を置くとともに，モデルを実装段階で崩さないために，デーじて適材適所の稼働プラットフォームを選定した。

タベース（DB）設計〜実装を専任で担当する体制の整備，多データ項目を扱うことに起因する JVM（Java 仮想マシ

開発工程の各種標準化などの施策を講じた。また，「適切ン）のメモリ不足の対応には苦慮したが，必要以上にメモな分離と局所化」もキーポイントと考え，独自フレームワー

リを消費しているアプリケーションをチューニングするとクの整備に加えて，処理のパターン化，DB アクセスルー

ともに，各機能の特性や同時利用者数などを考慮して JVMルの徹底などを行った。の分割，アプリケーション配置を調整した。この結果，販売・生産・物流系のシステムは，最終的にはリアル処理用3. 採用技術の紹介
3.1

JVM31  2 個（クラスタ構成），バッチ処理用 JVM18 個の実行環境としている。

ハードウェア，基本ソフトウェアアーキテクチャ

3.2

Web システムのクライアント

新統合システムの大半は Web ベースであり，java 言語でJFE グループ内外合わせた利用者は 4 000 名以上の規模開発した。稼働プラットフォームは，プレゼンテーションであることから，新統合システムは基本的には Web ブラウ層，アプリケーション層，データベース層からなる 3 階層

ザのみで利用でき，クライアントパソコンへのプログラム構造を採用している。

配信は不要な方式とした。ただし，詳細な鋼材仕様を入出データベースは，パフォーマンス面，安定性，将来的な力する複雑なユーザインタフェース（仕様設定業務）は，継続性の点で優位であることから，メインフレームコン

HTML や javascript での実現は困難であったため，リッチピュータ上に一元的に保持している。java アプリケーショ

インターネットクライアントの実現手段として Curl を採用

ンを稼働させるアプリケーションサーバ（WebSphere）は，した。Fig. 4 は Curl で開発した画面例である。

規模やシステム特性を考慮し，販生流系システムはメイン

Curl 採用は複数のリッチクライアント実現手段候補から，フレームで，経管系システムは UNIX サーバで運用してい要件の実現性，開発・保守生産性，稼働環境からの独立性る。システム構成を Fig. 3 に示す。
販生流系システムの主要機能を稼働させているメインフ
レームコンピュータ（zSeriez 990）は，java アプリケーショ
ン用 2 区画，COBOL アプリケーション用 1 区画の計 3 区
画 か ら な る ク ラ ス タ 構 成 と し， 可 用 性 向 上 を 図 っ た。
COBOL アプリケーション用区画は，対製鉄所，対商社など他システムとのデータ授受機能も担っている。
後 述 のアプリケーションフレームワークをプラット
フォームへの依存性が極小となるよう整備し，開発・テス
トはパソコン（Windows），サーバ（AIX）で行い，稼働はJFE 技報 No. 14（2006 年 11 月）− 22 −

Fig. 4

Example of the screen developed by CurlJ-Smile を支える IT イノベーション（テクノロジ）̶大規模基幹システムへの Web 技術適用̶

統合セキュリティシステム

新統合システム

IntraportalExtraportal

Firewall・ユーザ認証・ポータル表示Internet

切なものを選択し，この枠組みの中でプログラムを組み立て，個別／固有処理部分を穴埋め式で記述することで，アプリケーションを開発できる。これにより統一性を持った

社内 NW

社内ユーザリケーションの設計・開発者は，パターンカタログから適Reverseproxy

利用者情報
権限管理 DB・電子証明書による
クラアイント認証
・データ暗号化LDAPアプリケーション構造になることから，稼働後においても高い保守性，柔軟性を実現できている。
画面パターンはアプリケーション全体で共通的と想定さ社外ユーザれる画面要素（業務メニュー画面，検索＆一覧画面，単票・社員情報連携
人事システム画面，帳票出力画面など）を抽出し，雛型のプログラム

Fig. 5 Outline of integrated security system

ソースコードを準備したものである。処理パターンは，ビ（アプリケーションサーバに非依存であること），アプリケー（チェック処理，項目編集処理など）を抽出しパターン化しションフレームワークとの親和性などの観点から評価し総たものである。パターン一覧は処理パターンカタログとし合的に判断した。クライアント PC には Curl 実行環境をイて整備し，設計書雛型，ソースコードテンプレートも合わンストールする必要はあるが，Curl アプレット（プログラせて提供することで，開発生産性向上を図った。

ジネスロジックのうち共通的に扱えると想定される処理ム）は自動的にダウンロード，実行されるので配布の仕組みは不要である。

その他，処理パターンの中から呼び出されて使用される，カレンダ機能，採番機能などの共通部品系，ルール管理な

ユーザ管理については，JFE グループ共通の基盤としてどのテンプレート系の共通機能部品を整備している。また，構築済みであった，統合セキュリティシステムを利用するログ，ダンプ，トレース出力機能など，アプリケーションことで，ユーザ ID/ パスワードの一元管理，共通ポータルが直接意識しないインフラ系共通機能も組み込み，テスト・メニューからのシステム利用，シングルサインオン，JFEチューニング作業の効率化を図った。

スチール外から接続時の電子証明書によるクライアント認

デ ー タ ベ ー ス ア ク セ ス は data access object（ 以 下，証，データ暗号化を実現している。Fig. 5 は統合セキュリDAO）と呼ぶ共通部品のみを介して行うことを大原則としティシステムの概要である。て徹底し，個々のアプリケーションが直接 SQL を発行する3.3

ことは認めていない。DAO はデータベースの実装を専任で独自フレームワークの構築担当するメンバが管理しており，全体整合性や品質を保証

java アプリケーションフレームワークは，高品質なシスしている。
今回構築したフレームワークは，バッチ処理を java で実テムを高生産性で開発できるよう，struts（オープンソースの Web アプリケーションフレームワーク）をベースに独自現するための仕組みも実現した。これにより，オンライ開発にて構築した。複数の市販フレームワーク製品の比較

ン／バッチ処理間で処理ロジックが共用できるため，開発評価も行ったが，データモデルの忠実な実装，鉄鋼業務へ量抑止，稼働後のメンテナンス負荷軽減に寄与している。の親和性，開発・保守生産性などの観点から独自開発が適3.4切と判断した。

システム間接続への EAI 導入

Fig. 6 にフレームワークの基本構造を示す。既存システ

本社側システムは新システムの稼働にともない，各種ムや業務内容の分析などを通じ，新統合システム構築のコードを新体系で運用するが，製鉄所をはじめとする既存ベースとなる基本パターン（30 の処理パターン，12 の画面他システムには旧コードで運用しているものが多い。このパターン）と 49 個の共通機能部品を事前に準備した。アプため，システム間のデータ授受に際し，新旧コード間の変換／逆変換が必須であった。また，品種・機能ごとに段階

Strutsプレゼン
テーション層

ビジネスロジック層
スケルトン提供 共通機能＆フロー管理
ルール
処理パターン管理

ビジネスモデル層
DAO
論理クラス

リソース層

テーブル

合 シ ス テ ム で は，Fig. 7 に 示 す よ う に，EAI ツ ー ルから分離するとともに，システム間の接続箇所を集中させることで，この課題に対応した。システム切り替え時に共通部品は，一時的に大量のデータコンバート，DB セットアップ作業が発生するが，このコンバート処理も EAI サーバにてインフラ系機能網掛部をフレームワークとして整備

Fig. 6の切り替えを円滑に行えるようにする必要もあった。新統
webMethods を導入し，変換ロジックをアプリケーション処理パターン処理パターン的に実施するシステム移行時や今後の既存システム刷新時

DAO: Data Access Object実行した。
コンバート処理ロジックの部品化と再利用により，高い

Structure of application framework− 23 −

JFE 技報 No. 14（2006 年 11 月）

J-Smile を支える IT イノベーション（テクノロジ）̶大規模基幹システムへの Web 技術適用̶新統合システム
EAI サーバ ×4 台
DB

webMethods

FTP
アダプタ

UNLOAD
DB
アプリ

RDA

FTP
アダプタ

アダプタ

来のメインフレーム製品同様，比較的早期に原因究明，バ

他システム

グフィックスが提供された。また絶対的な能力の高さ，堅DB

牢性はメインフレームならではの安定感があるなど，基幹LOADシステムのプラットフォームとして妥当な選択であったと

アダプタ

アダプタ

DBBr

考えている。

MQ
コンバート
ロジック

MQ

アプリ

新統合システム全体を見ると，メインフレーム，分散系

IS

サーバ，複数ベンダのソフト製品，ネットワーク，proxy
FTP: File transfer protocol
RDA: Remote database access
MQ: Message queueing

Fig. 7

Br: Broker
IS: Integration server

サーバなどの経路上の構成要素，PC 環境のバリエーションなど，動作環境の組み合わせは膨大である。このような

EAI System

複合環境で発生する障害について，問題箇所の切り分け，開発生産性と品質の向上 , 均一化を実現するとともに，部原因究明，対策を行うには，各分野に精通した多くの専門品単位，部品間のテストも効率的に実施することができた。

システムエンジニアが必要であったが，それを機能させる複数の開発単位（たとえば，品種ごと）の段階的本番化や，ための体制，指揮命令系統も有効に働いた。

結合テスト，運用テスト，本番の複数環境にまたがる検証，

java アプリケーションの稼働に必要なコンピュータ資源切り替え，データ移行に対しては，複数の PC サーバにのキャパシティプランニングも大きな課題であった。早期EAI を配置し，アダプタ（接続部品）を用いた接続環境をにプロトタイプを開発し，COBOL で開発した従来型アプ整備することで，同時複数接続，短時間での切り替えを実リケーションと java アプリケーションで CPU 資源の使用現した。

量比較を行い，最終的な必要資源量を約 3 000 MIPS と見積もった。これに対し実績は 10％増程度の範囲に収まって4. 評価おり，問題ない精度であったと評価できる。

新統合システムは従来のシステム構築手法と異なる部分

5. おわりにが多く，さまざまな局面で新たな標準化とその徹底が必要であった。このような背景から基盤分野の検討，環境整備

開発生産性向上，高品質なシステム構築，稼働後の環境は業務設計やアプリケーション設計に先行して実施し，開変化への柔軟な対応，さらには継続的な業務改革という命発チームをリードする形となった。初期フェーズで実施し題に対し，最新の IT を適切に活用した新統合システムのたデータモデルの構造が崩れないように維持しつつ，柔軟開発・稼働基盤構築の取り組みについて述べた。
JFE への経営統合前の準備段階から，約 3 年間の基盤整構造を実現するため，基盤チームによる全体統制を徹底し，標準から外れた構造のアプリケーションの排除に努めたこ

備活動は一旦完了したが，今後のビジネス環境および ITとで，プロジェクト全体の目標達成に大きく貢献できた。

動向の変化に対し，システム稼働基盤も適切な対応を継続

フレームワーク，共通部品を整備したことにより，アプ的に行っていくことが重要と認識している。また，今回得リケーション構造の均一化，処理ロジックの粒度統一，プられた成果物やノウハウを JFE グループ各社のシステム化

ログラムの可読性向上，品質の均一化・向上に貢献できたに展開し，グループ全体の IT 水準の向上を図っていきたと評価している。このアプリケーションのコンポーネント

い。

化をベースとして一部機能の Web サービス化を実現するな
ど，今後の service oriented architecture（SOA）への発展につながる試みも一定の成果を得た。また，基礎となるデータ構造，データベースの構築を専任チームが担う体制としたことで，一貫性を保ったシステム構造を実現することができた。
今回，メインフレーム上で販生流系 java アプリケーションを稼働させたことは本システムの大きな特徴である。
種々のソフトウェアは最新バージョンを採用したこともあり，テスト当初は DB，アプリケーションサーバなどのベンダ提供製品のバグに遭遇することも少なくなかったが，従JFE 技報 No. 14（2006 年 11 月）− 24 −

原田 敬太

森本 哲也

大川 浩志