弊社のご紹介
商号株式会社 三城ホールディングス
PARIS MIKI HOLDINGS Inc.
創業
1930年10月10日
設立
1950年1月27日
本社所在地 東京都品川区北品川
資本金59億107万5千円
連結売上高 562億9900万円
三城ホールディングス（持株会社）

株式会社 三城株式会社 金鳳堂「パリミキ」「メガネの三城」「オプトレーベル」等、国内
眼鏡小売専門店チェーン
店舗数1,020店
従業員 2,789名「金鳳堂」店舗、百貨店店舗における国内眼鏡小売事業
店舗数 26店舗
従業員 237名

海外事業
子会社

株式会社
グレート

１１ヶ国
１４会社

店舗開発・管理・内装事業

弊社のシステム化の経緯
年

システム名・概要・受賞

主使用開発言語

１９８３

情報システム部門分離、設立（汎用機 ACOS‐2導入）販売・在庫管理システムリリース

COBOL

１９８６

会計システム、人事管理システム等、管理系システム整備（オフコン ITOS）

COBOL

１９８７

全店舗にＰＯＳシステムを導入（N5200 PTOS）

COBOL

１９８９

業容拡大によりメインフレームアーキテクチャ更新（ACOS‐2 ⇒ ACOS‐4 ）１９９０

取引先と店舗を結ぶ商品納期問い合わせ・発注システム（MIKI‐NET）リリース（ACOS‐4）

COBOL

１９９１

インターネット利用開始（ＪＵＮＥＴ）ｍａｉｌ、ｎｅｗｓ
顧客情報システム開発・リリース（ＵＮＩＸ）

Ｃ、COBOL

１９９３

ＡＩを使った商品デザイン・コンサルティングシステム開発・リリース
Ｗｅｂサイト設置

Ｃ、Ｐｒｏｌｏｇ
ＨＴＭＬ

１９９４

ＡＩを使った商品デザイン・コンサルティングシステム『ＮＩＣＯＧＲＡＰＨ』論文賞受賞

１９９６

インターネット通販開始

Ｐａｒｌ、ＪａｖａSｃｒｉｐｔ

１９９７

ＰＯＳシステムのＷｉｎｄｏｗｓ化（ＮＴ3.1）

ＶＢ４

１９９８

ＩＡ（インテリジェント・エージェント）システム研究開発、推論エンジン開発

ＪＡＶＡ1.1、Ｐｒｏｌｏｇ

２００１

ＥＲＰ導入会計システム更新、即時経費管理システム開発・リリース

ＪＡＶＡ、ＶＢ６

２００２

ＩＡ（インテリジェント・エージェント）システムが日経ＢＰ社『情報システム大賞』受賞

２００４

納期問い合わせ・発注システム（MIKI‐NET）のオープン化（Ｌｉｎｕｘ）

２００５

ＭＩＫＩ‐ＮＥＴが経済産業省『情報化月間』情報化月間推進会議 議長賞２００９

納期問い合わせ・発注システム（MIKI‐NET）のクラウド化
メインフレームのアーキテクチャ更新（ACOS‐4 ⇒ Ｌｉｎｕｘ）

ＪＡＶＡ1.4

ＪＡＶＡ２
COBOL

ＩＴ環境の変化【最近のキーワード】
クラウドコンピューティング、シンクライアント、Webアプリケーション、ブレードサーバー、ｉＰａｄ、ネットブック､スマートフォン､Ａｎｄｒｏｉｄ、ＨＴＭＬ5、Windows7、ＩＰｖ6、グリーンＩＴ、ＡＳＰ、ＴＣＯ、マイグレーション、リビルド、ＳａａＳ、国際会計基準・・・ ｅｔｃ【メインフレームの今後】
億円
億円 7,000
7,000
Super
Super Computer
ComputerBusiness
ServerBusiness
Server
6,000
6,000
RISC
RISC Server
Server

5,000
5,000
4,000
4,000

IA64
IA64 Server
ServerMainframe
Mainframe

3,000
3,000

メインフレーム市場は縮小傾向
x86サーバ市場は拡大傾向

2,000
2,000
1,000
1,000

x86
x86 Server
Server00
2007年
2007年

2008年
2008年

2009年
2009年

2010年
2010年

2011年
2011年

2012年
2012年

2013年
2013年

Source: IDC Japan's Japan Quarterly Server Forecast CY2009Q1

メインフレームの特徴とメリット・デメリット【メリット】
・高い信頼性により業務の継続性にすぐれる・スケーラビリティに優れ業務の幅広い性能要求に対応
・COBOL等過去資産の継承
・ベンダの手厚いサポート【デメリット】
・メインフレームは信頼性は高いがそれだけに運用管理コストも高い
・ベンダ依存構造
・運用が自社のみでは困難（ベンダのテクニカルサポート要）
・メインフレーム技術者の不足
・多様化するユーザー部門の要求に柔軟に対応するのが難しい「ＩＴ維持コスト」削減し新規ITに十分な投資を行う為、メインフレームシステムのオープン化を決断メインフレームのオープン化の経緯【目的】①

ＩＴ運用コストの全体的削減
オープンに共通化し、運用の効率化とコストの削減を目指す（目標３割減）
ＴＯＣ削減の中で汎用機（ACOS）の運用のコスト削減もひとつの手段②

オープン系他システムと連携し易く柔軟性のあるシステム構成への移行
旧機器を維持するリスクの排除と、情報統合出来る環境づくり【メインフレームオープン化の過去の経緯】①

過去（1998年頃）にメインフレームのＵＮＩＸサーバーへの移行を検討したが、技術的問題、移行コスト（メインフレーム交換より高額）等により断念②

既にハードおよびＰＰは償却済、機能も一部過去に切り出して（顧客情報等の集配信等）オープン化を実施済により、全面的なオープン化に着手

ＣＯＢＯＬ資産継承のメリット・デメリット【メリット】① 四則演算のみでファイル処理が中心の処理系であればＣＯＢＯＬで十分ファイル処理を中心としたシステムではまだまだ現役② 基本的な処理系に大きな変化が無く、ＣＯＢＯＬ資産が多数ある場合はそのままの利用出来、ソフトウェア開発再投資の必要が無い【デメリット】① ブラウザを使ったＷｅｂ系の処理、ＧＵＩを重視したクライアントの処理には不向き、今後、ＣＯＢＯＬだけでは全ての処理をまかないきれない② ＣＯＢＯＬを熟知したプログラマーは激減（新規開発のマンパワー不足）③ システム構成は複雑になり、従来のようにコーディング上のエラーだけでなく、複数のＰＰが関係する問題が発生する（特にＤＢ）マイグレーション対象システムと規模【対象システム】
弊社の基幹システム（在庫管理/販売管理システム）※ ＳＣＭのための受発注システムは６年前にLinux/Javaでデータセンターのシステムをオープン化済であり、Ｌｉｎｕｘでミッションクリティカルな業務を実行することに不安は無かった※ 目的オリエンテッドに考えた場合、リビルドではなくマイグレーション【システム規模】
移行元

移行先

資産規模

ACOS-4

Linux（MC Linux＝ミッションクリティカルLinuｘ）
ＲｅｄＨｕｔ5.1

COBOL,COBOL/S → COBOL2002
JCL→ Cシェル
帳票→ SVF
画面→ VB
RIQS→ Oracle

520本
500本
50帳票
100画面
250ファイル

システム構成概要
【更改前】

【更改後】
高可用Linuxプラットフォーム

ACOS-4

言語処理(COBOL,COBOL/S)
AP共通基盤

言語処理(COBOL2002)

バッチ基盤(JobCenter/SORTKIT)

帳票基盤

Windowsプラットフォーム

データベース (Oracle11g)

帳票基盤(Ｒａｋｕform)

CLUSTERPRO X for MC Linux

バッチ基盤(JobCenter)

高可用基盤ミドルオンライン基盤(VIS)

本番環境

AP共通基盤オンライン基盤(TPBASE)RHEL5

Windows 2003

バッチ基盤(JOB管理/標準ファイル）

データベース(RIQS)
Linuxプラットフォーム
言語処理(COBOL2002)

開発環境

AP共通基盤

ACOS-4

オンライン基盤(TPBASE)
バッチ基盤(SORTKIT)

リホスト

Windowsプラットフォーム

データベース (Oracle11g)

帳票基盤(Ｒａｋｕform)

RHEL5

Windows 2003

＊一部Windowsプラットフォームを含む

ソフトウェア構造
ﾕﾆｯﾄ（機能）ｺﾝﾎﾟｰﾈﾝﾄ

ＡＰ開発

トランザクション処理
画面制御
VB2005OLTP
PARTNERCOBOL２００２
COBOL２００２(資産移行)
資産移行)

バッチ処理

データベース
処理

COBOL２００２
COBOL２００２
C shell(資産移行)
資産移行)

COBOL２００２
COBOL２００２(資産移行)
資産移行)
Pro*COBOL

帳票
出力ファイル連携

WebSAM
Rakuform ★

ﾕﾆﾘﾝｸ社製
全銀TCP/IP
全銀TCP/IP(Windows)

ミドルウェア基本

TPBASE ★

WebSAM
JobCenter ★

OracleＯＳ
ＨＷ運用

WebSAM SystemManager ★

ﾊﾞｯｸｱｯﾌﾟ

NetVault

高可用

CLUSTERPRO X ★

基本RHEL5

サーバ

Express5800/A1040 ★

ｽﾄﾚｰｼﾞ

iStorage D1 ★

(ｵﾝﾗｲﾝ、ﾊﾞｯﾁ）★印 ＮＥＣ製資産移行方式とツール【ＡＣＯＳ-4】
AP資産の移行【Ｔｏｏｌ】【Ｌｉｎｕｘ】

COBOL,COBOL/S,IDLⅡ

APMS/SRC(*1)
APMS/SRC(*1)※VIS/JCL/DB/帳票の※VIS/JCL/DB/帳票のAPI変換含む
API変換含む

ＣＯＢＯＬ２００２

画面（MFDL)OLTPPARTNER画面移行ツール

VB.NET（CL製品)

資産移行サービス(FORMEX変換サービス)

SVF

バッチ帳票（FORMEX有/無)Windows
帳票マイグレーション
for Rakuform

Rakuform

オンライン（MFDL）帳票
ＪＣＬ

データの移行

帳票移行ツールfor SVF

SVF

APMS/JCL(*1)

Cシェル

Ｏｒａｃｌｅ

ADBS/RIQS/VSASAPMigratS/DataConverter(*2）
標準ファイル

標準ファイル(*1)マイグレーションサービスの中で使用する内部ツール群総称(*2)データ移行支援ツール

実装例１【帳票制御 例】
ＡＣＯＳでは帳票AP

COBOLコンパイラが以下を行う
・改行/改頁制御（改行/改頁用ヘッダの付加）
・プリンタ制御コードの付加

帳票レコード定義

書式/用紙情報（FORM,FORMSET,MEDIA等)

スプール
プリンタ出力

帳票出力ロジック

ユーザアウトファイル

オープンでは帳票製品に合わせた形式出力に作り変え
フォーム

帳票AP
帳票製品

帳票レコード定義
帳票出力ロジック

ASA形式
ファイル

Rakuform(Win)

プリンタ出力帳票APの帳票定義/ロジック、書式定義(FORMEX定義等）より帳票製品のフォーム定義をツールにて作成

実装例２【オンライン処理 例】
ＤＢバッチ・オンラインサーバ−
ＰＣ-ClientStorage

Oracle InstanceOracle Listener

Oracleｸﾗｲｱﾝﾄ

PC

OracleCOBOL実行環境

Windows

TPBASECOBOL TPP（移行）OLTPPARTNER

DB機能

TP-Listener OLF/TP-UＴ

VB(ｵﾝﾗｲﾝ画面）

オンライン機能iStorageD1

TPBASEadm(SV)Oracle EnterpriseManager
Database Control

LinuxLinuxHW

HW

iStorageManager

ﾌﾞﾗｳｻﾞ

ﾌﾞﾗｳｻﾞ

運用Client

TPBASEadm(CL)WindowsPC

マイグレーションで使用したＣＯＢＯＬプロダクト【本番環境】COBOL2002 Net Server Runtime(64)COBOL2002ACOS互換セット／マクロ機能 for LinuxSORTKIT(x64版) Ver1.1【開発環境】COBOL2002 Net Server Suite(64)SORTKIT(x64版) Ver1.1※ Ｌｉｎｕｘへのマイグレーションを契機に新規開発されたプロダクト
開発元はＨＩＴＡＣＨＩ【帳票・運用・バックアップサーバ】
Open COBOL Factory 21/インストールキット Ver5.4

資産移行スケジュール【プロジェクトのスケジュール】（予定作業期間）① 2008年4月よりマイグレーション方式の検討開始② 移行検討と実証検討• パイロット変換 2008年11月〜12月• 移行設計2008年11月〜2009年1月• 本格変換2008年12月〜2009年3月③ 構築作業• 設計• 構築• 検証/運用

2008年11月〜2009年1月
2009年1月〜2009年2月
2009年3月〜2009年7月④ 総合評価2009年3月〜2009年7月※ 実際にはこの予定の３〜４ヶ月遅れ

プロトタイピング
サンプルプログラム抜き出しと実行検証、確認

導入効果【コスト削減効果】①

Ｈ/Ｗ・ＰＰ、ＳＩ，ソフトウェア移行費用等の総額は、ＡＣＯＳ−4そのままのアップグレードした場合の金額の２／３程度に､運用費用は約３／４程度に※

HP‐UX（ＵＮＩＸサーバー）へのマイグレーション見積もりでは要望に収まらず（特にHW費用）② ハードウェアコストの削減効果 ⇒ コスト内訳 （HW/OS/PP）：SI = ４：７【運用効果】① 他のオープン系システムとＤＢ（Ｏｒａｃｌｅ）連携とクライアントＰＣとの親和性② ハードウェア性能の向上、高速化による処理時間の大幅な短縮③ 開発言語の継続的な利用とソフトウェア資産の継承

プログラム言語の使い分け【適材適所】（弊社の場合）
ＪＡＶＡ： ＷｅｂブラウザやＪＡＶＡ Ｗｅｂ Ｓｔａｒｔを用いたクライアントＡＰを対象とした大規模ネットワークシステムやＷｉｎｄｏｗｓクライアント（ＶＢ）向けクライアント／サーバー型のサーバー側ＡＰ

ＶＢ．ｎｅｔ ： ユーザー数が数百人規模までの中小規模システム、ＩＥを前提とするクライアントＡＰのＷｅｂ系システム（ASP.net ＩＩＳ利用）
Ｃ： デバイスを直接コントロールしたい場合、グラフィックス等の高速化をしたい場合など、機能目的がハード寄りで明確である場合

ＣＯＢＯＬ : 処理体系、データ構造に大きな変化が無く、ＧＵＩは別途にファイル処理を中心として四則演算だけで処理出来る場合
Ｐｒｏｌｏｇ ： ＡＩ（人工知能）、エキスパートシステムを開発する場合（Minerva）

システム移行検討フロー（ご参考）ＹｅｓＮｏ

自社の業容はこれから先もあまり変化しないと考えられ、現在の処理系を将来的にも変える必要が無い
自社に新しい技術を採用するのにあまり抵抗感は無い

システム部門は決まった業務を決まった通りに実行するのが仕事システム開発をするスタッフが少なく、運用要員しかいない

マイグレーションの経験豊かなＳＩベンダーと強い取引関係・協力関係がある
社内はＷｉｎｄｏｗｓエンジニアのみで、UNIX、Ｌｉｎｕｘは全く知らない

会社にはお金があり、システムのコストの制約は少ない

ＷｉｎｄｏｗｓＯＳでトラブってもＭＳに太いパイプがあり解決出来る

ユーザーのリテラシーが高く、業務処理の変更に抵抗感が無い
社内の業務プロセスは既に効率化され整理されているシステムの信頼性は支払うハード・ＰＰのコストに比例する？

自社のデータ処理を第三者に任せるのに抵抗感は無い
メインフレーム
現状維持

オープン化
ＥＲＰ導入

ＳａａＳ
に丸投げ

メリットが得られるなら、多少リスクあっても有望な技術に挑戦をすべきＵＮＩＸＬｉｎｕｘWindows

マイグレーション

マイグレーション

ダウンサイジング

むすび

ＩＴの世界に当てはめると・・・
クラウド
ＢＩ＋コックピット
ＥＲＰ
ＳａａＳ

ＴＳＳ
ＭＩＳ、ＳＩＳ、ＤＳＳ
業務パッケージ
委託データ処理 ・・・ｅｔｃ

米国流商業主義的シノニム

コンピュータは所詮道具、プログラムは所詮手段マイグレーションは特に新しい事ではなく、得体の知れない事でもない目的オリエンテッドに、目的を達成するための一つの方法、手段