ESD21 オープンフォーラム

JFEスチールのビジネス改革の特徴
プロジェクト成功の要因を考える

2012年5月17日（木）ウインクあいち
エスエーシー代表
安保秀雄
hideo.ampo@gmail.com
1本日の概要 書籍「ITによる業務変革の正攻法

JFEスチールの挑戦」の概要

 記者として見たJFEスチールのビジネス改革の特徴
 基盤構築に利用した手法「概念データモデル設計法」――利用者の視点から表現
 JFEスチールの改革の成功要因

2

自己紹介
 1985年、日経マグロウヒル社（現・日経BP社）入社– 日経エレクトロニクス副編集長、日経コンピュータ副編集長、日経コンピュータグラフィックス編集長、日経ITプロフェッショナル編集長などを務める
 日経エレクトロニクス：“Japan as No1”時代と競争力を失っていく時代の電機業界を取材
 日経コンピュータ：最初に書いた特集記事が「IT業界のモラルハザード」（2001年）
 日経コンピュータ、日経ITプロフェッショナル：概念デー
タモデル設計法などを紹介
 2010年に独立。モデリング、システム開発などに従事
 2011年、 書籍「ITによる業務変革の正攻法 JFEスチールの挑戦」を執筆、日経BP社が出版
3

本日の概要 書籍「による業務変革
書籍「ITによるによる業務変革の業務変革の正攻法

JFEスチール
スチールのスチールの挑戦」
挑戦」の概

要 記者として見たJFEスチールのビジネス改革の特徴
 基盤構築に利用した手法「概念データモデル設計法」――利用者の視点から表現
 JFEスチールの改革の成功要因

4

書籍の概要（１）JFEスチールのシステム統合とその後の継続的な業務変革について、手法と手順を記録– 2001年、川崎製鉄とNKK（日本鋼管）が経営統合を発表– 2006年、新統合システムJ-Smile稼働、概念データモデル設計法を利用– 2009年以降、販売生産計画システム、工程進捗管理システムなどが稼働– グループ会社のシステム統合・刷新も実施

「正攻法」シリーズ3冊目– 三菱東京UFJ銀行のシステム統合– 東京証券取引所のシステム改革– JFEスチールの業務変革（システムとビジネスの統合・変革を達成）

経緯– 日経コンピュータに手島歩三氏が連載記事「ITを活用したビジネス改革」を執筆（2002年4～9月）– それを読んだJFEスチールの方々が手島氏に話を聞く– JFEスチールがシステム統合・業務変革に手島氏らの概念データモデル設計法を利用
5– JFEスチール・グループ会社の10年間の軌跡を出版

書籍の概要（２） 本書に記述した主な手法– 概念データモデル設計法• ビジネスを素直にあるがままに捉え関係者が共有できるようにする– アプリケーション・ポートフォリオ• 全社の業務と情報システムの関係を明確にする– SECIモデル• 暗黙知と形式知の相互スパイラルで組織を活性化する– 組織を連携する体制• 本社、営業、工場の役員と現場の連携を促進する組織を作る– 従業員の意識改革• 挨拶運動、場づくり、トレーニング

ビジネスを捉える 人・組織間の意思疎通ライバルだった川鉄とNKKを融合し顧客のための連携推進

6

本日の概要 書籍「ITによる業務変革の正攻法

JFEスチールの挑戦」の概要

 記者としてスチールの記者として見として見たJFEスチール
スチールのビジネス改革
ビジネス改革の改革の特徴
 基盤構築に利用した手法「概念データモデル設計法」――利用者の視点から表現 JFEスチールの改革の成功要因

7

JFEスチールのビジネス改革の特徴（まとめ） 改革前の川鉄とNKKの業務と基幹系システムは硬直化していた– 多くの企業と同様の状況からスタートしシステム統合を行う– だれもが利用可能な正攻法といえる手法を利用（珍しいが特殊なケースではない）– ただ当時は無謀と言われた
 業務とシステムの基盤固めから行った– 素直に業務を捉える– それを情報システムに反映する（当たり前のようだが、やろうとしても失敗することが多い） 人と組織を動きやすくする拠り所・軸を作った– 拠り所があるのでバラバラにならない– 開発中に「迷ったら原点に戻れ」と責任者（菊川氏）が指示（戻ることが可能な原点・基盤がある、しなやかさがある、拡張性もある）
8

JFEスチールも統合前はたいへんな状況だった

統合前の統合前の川鉄と川鉄とNKKのの状況– 情報システムが業務に合わない。分かっていても、システム構造が複雑なため変えられない– 仕様、価格、納期などの引合情報は営業担当者が抱えていて組織的に共有できない（工場は推測で生産計画立案）– 販売や設備投資などの計画立案に時間がかかり過ぎて、世の中の変化に追い付けない– 製品コスト／利益や生産ボトルネックが分からず収益を高められない– 製品仕様、コード体系、用語が工場ごとに異なる– 製造の進捗を営業が工場にいちいち電話しないと確認できず、顧客に納期を回答できない– 納入指示のファクスの文字がかすれていて、電話で確認しないとわからない
9当時の年）
当時の一般的な一般的な状況：
状況：多くの企業
くの企業が企業が問題に問題に直面（
直面（2000~2005年 スパゲッティ化
スパゲッティ化したシステム
したシステムがシステムが経営の経営の足を引っ張る– みずほ銀行がシステム統合失敗– 熊谷組、飛島建設の合併破綻，理由の一つがシステム統合困難– セミナー事業で顧客の統合管理ができず販促経費増大– 電機メーカーが複数事業部の部品購買一本化、環境考慮の商品開発・設計などを実施しようとしたが部品表の整備に手こずる– 電機メーカー事業部同士の合併時に部品調達一本化を一時断念– 通信事業者が加入者へ合算請求できず，年数十億円のコスト削減が予定通りにできなかった– 機械メーカーがシステムのせいで生産子会社分離という事業再編ができない– 行政システムの改修費用が肥大化（7000万円の拡張作業だったが影響範囲が広く総計3億7000万円に）– ERPを導入したため納期遅れ頻発– 電子自治体プロジェクトの不整合（独自仕様の乱立，ベンダー縄張り争い許す）
10

当時の一般的な状況：現場は身動きが取れない
銀行のシステム部長

–

現在のシステムは十数年近く使い続け、システム規模はとてつもなく巨大。新商品を出すときにツギハギで拡張してきたので、内部構造が汚い。新商品追加のためのプログラムは小さいけど、影響が広い範囲に及ぶようになったので、保守作業の時間とお金がかかりすぎる。本当はシステムを作り変えたいけど、新商品を出すための拡張作業が常にあるし、再構築できるだけの体力もありません。本当に困っています。

サービス業のシステム子会社役員

–

事業部が勝手にベンダーに発注しており、用語統一やプログラミング規則の順守は無理だ。データ辞書を作って統一を図っているが、監視の目は行き届かない。整合性のあるシステムを作る難しさを現場はいやというほど実感している。しかし、システムの現場を知らない経営者や経営企画部はその難しさを理解できない。システム部門がだらしないと言うだけだ。実態を議論の俎上にあげると、システム部門は損するだ
け。従来のまま、現場の頑張りに頼るしかない。
11

JFEスチールは改革を実行にうつす よくある企業の姿– ぼろぼろの土台の上につぎはぎでシステムを増築– 役員も業務担当者もシステム部員も動けない

 JFEスチール– 基盤から構築– 顧客を向いた改革を全社で実行
ぶれずに共有ぶれずに共有できる共有できる「できる「原点」、原点」、着実に着実に成長できる成長できる基盤できる基盤を基盤を設けた
12

JFEスチールが実行したこと（１）CIO（情報統括役員＝菊川氏）が原点、原理原則を明確にした
 「ITをどう考えるか」から検討開始（31ページ）– 最初はどう取り組むか「取っ掛かりさえ分からなかった」– 調べているうちにITの役割が変わったと認識した

13

JFEスチールが実行したこと（２） 基盤を作る– ビジネスとシステムを合致させる（39ページ）– ビジネスを明確にする（現場で何を扱いどう活動しているか）– ビジネスの安定な構造を抽出することで、ビジネス変化や拡張に対応しやすくした（従業員とともに自社が成長できる）

14

JFEスチールが実行したこと（３） ビジネスをあるがままに写し取る– もともと菊川氏は川鉄時代から“素のデータ” を重視していた。「データは全社共有で『素』で保有するのが基本」（36ページ）– 今回どう写し取ったか→概念データモデル設計法を利用（DOAやDFDは採用せず）

例１：販売計画と販売計画と生産計画の生産計画の同期をとるために同期をとるために必要をとるために必要な必要なデータ（データ（業務）業務）を図示（90～～91ページページ）
ページ）

15

JFEスチールが実行したこと（４）

例２：営業活動を営業活動を見える化
える化して工場して工場との工場との連携との連携に連携に活用– 営業の契約業務の3要素（商談、仕様設定、注文）をあるがままに捉える（42ページ）– 営業活動の効率化、生産の効率化が可能

16

JFEスチールが実行したこと（５）

ビジネスをあるがままにビジネスをあるがままに写をあるがままに写し取ったデータったデータ構造
データ構造の構造の基盤を基盤を作ったあとにアプリケーション・アプリケーション・システムをシステムを開発– 従来の開発手法と手順が逆（51ページ）。この違いは大きい17

JFEスチールが実行したこと（６）

ビジネスとシステムの全体像（アプリケーション・ポートフォリオ）を描く（70ページ）
ビジネス
管理

原料資材
財務経理
保全

販売

生産

物流

環境

研究開発
知財

戦略

業務１
業務２

業務３

戦術

業務４
凡例：
ITがあり機能している
業務５

実行

業務６
業務７

ITがあり課題あり

ITがないがない（がない（あるべき）あるべき）ITはないが不要
18

JFEスチールが実行したこと（７） 人と組織のコミュニケーションを図る– 合併時のプロジェクト開始時の言葉は、「まず挨拶しよう」（菊川氏）。さらに、「ストレス感じにくいプラス思考、笑顔、責任、信頼、自省、鵜呑みにしない姿勢」でモチベーションとコミュニケーションを重視する（174ページ）– 「業務部門出身者がITに自信を持つ」ようにして、情報システム部員と協調できるように心がける– 概念データモデル設計やSECIモデルによる形式知と暗黙知の相互スパイラルを通して、みんなが話し合える場を作る– 新統合システムJ-Smile導入時に700回、１万人のトレーニング実施。教育チームは女性10人（ピーク時）
19本日の概要 書籍「ITによる業務変革の正攻法

JFEスチールの挑戦」の概要

 記者として見たJFEスチールのビジネス改革の特徴
 基盤構築に基盤構築に利用した利用した手法
した手法「手法「概念データモデル概念データモデル設計法データモデル設計法」設計法」――利用――利用者の視点から視点から表現から表現 JFEスチールの改革の成功要因

20

概念データモデル設計法とは
 ビジネスをデータで捉える方法– ビジネスで扱う「もの」と「こと（活動）」をデータとして把握する– 捉え方の詳しさを「識別子」で明確にし、組織や専門による相違や共通点を明確にする– ビジネス全体を１枚の図の中で描く

概念データモデル設計のやり方が載っている本
手島歩三 監修・著「働く人の心をつなぐ情報技術 概念データモデルの設計」
白桃書房、2011年、2800円
21静的モデルの例
ビジネスで扱っている、あるいは管理している「もの」をみんなで認識
顧客
顧客名

品目（製品・製品・部品）
部品）
品目名

注文する

顧客注文品
顧客名
注文Ｎｏ
品目名

属する

注文を受ける

製品生産物
引き当てる

引当数量

引き当てられる

顧客名
注文Ｎｏ
品目名
製造番号

属する

生産を計画
する（製品）

注文数量
納期

引当品

図番

製造手順

品目名（製品） 計画数量
製造番号
完成予定日
完成日
完成数量

使う

品目名
工順
加工機能名

生産を計画
する（部品）

部品生産物
品目名（製品） 計画数量
製造番号
完成予定日
品目名（部品） 完成日
完成数量使用する

治工具・治工具・金型
治工具・金型名

作られる

投入品目
品目名
加工機能名
投入品目名

投入量単位

産出物
品目名
加工機能名
産出品目名

産出量単位

適用する

加工機能
品目名
加工機能名

投入する

段取時間
ｻｲｸﾙ時間産出する

使用する設備・設備・機械設備・機械名作業を担当する

作業者
作業者名

22

動的モデルの例「もの」の状態がどう変わるか、みんなで認識
生産計画
作成

工程Ａ
工程Ａ 加工（加工開始）
加工開始）

識別子：

識別子：

品目名（製品）
製造番号
品目名（部品）

品目名（製品）
製造番号
品目名（部品）
加工機能名
作業完了日時属性：
生産予定数量
完成予定日
仕様
・・・

生成（生成（登録）登録）

属性：
数量・・・・・・・・・

部品検査
（完成）
完成）

入 庫
（一括）
一括）

活動

識別子：

識別子：

品目名（製品）
製造番号
品目名（部品）
加工機能名
作業完了日時品目名（製品）
製造番号
品目名（部品）活動の活動の識別子と識別子と属性

加工開始

部品生産物

属性：良品数量
不良品数量

検査完了

属性：入庫先
入庫日時
入庫数量
・・・入庫済
（抹消）
抹消）

状態変化

識別子：品目名（製品）、製造番号、品目名（部品）引用（一部編集）：手島歩三「気配り生産システム」日刊工業新聞社

実体種類

23

概念データモデル設計法とは
 最初は少しわかりにくい– 「“もの”を描きましょうと言われたが、最初は戸惑った」（元設計者、126ページ）。ただし、業務に精通している人は、その業務についてはモデルをさらさら描けるようにすぐなる– 「頭のいつもと違うところを使う」（前JFEスチール シ
ステム主監の西川廣氏、239ページ）
これ以降
これ以降、以降、実際に実際に利用した利用した人した人の体験談で体験談で説明します
説明します

24

概念データモデルの体験談（１）
最初はよく最初はよく分はよく分からなかったが、からなかったが、やってみると自社やってみると自社の自社のビジネスをビジネスを俯瞰できるようになり、できるようになり、プロジェクトへのプロジェクトへの参加意識への参加意識が参加意識が格段に格段に高まる
「最初は、営業や工場の現場の業務担当者を、なぜこんなに多数参加させるのかと思ったが、なるほどこうやってビジネスをあるがままに写し取っていくのかと思った。いわば、みんなで会社の存在意義ややるべきことを考え、他の人の仕事や自分の会社のやり方・風土も見渡せるようになる方法
なので、プロジェクトへの参加意識が格段に高くなる。システムエンジニア
ではなく現場の業務担当者が主体になって、ビジネスの基本をしっかり押さえられるので、システム開発の確固とした拠り所ができる」（JFE建材フェンスの渡邊茂社長、125ページ）
25

概念データモデルの体験談（２）
営業や営業や工場の工場の現場の現場の人も情報システム
情報システム内部
システム内部の内部の処理が処理が分かる。
かる。異なる出身会社でも出身会社でも業務でも業務について業務について合意について合意が合意が得られる

「概念データモデルを作成することでお互いが重要と考える課題を共有できたのですが、業務部門出身のスタッフにとってもITに関する理解が深まりました。業務部門で扱うべきデータが明確になり、そのデータをITで共有したり更新したりするという情報システム内部の処理が分かるようになったからです。業務部門出身のスタッフが、自信を持ってITによる変革を議論できるようになりました。一方、IT部門出身者はモデルを通して業務を理解していきました」（菊川氏、176ページ）

「旧NKKと旧川鉄の営業担当者と生産担当者がそれぞれ集まって議論するとき、旧NKKと旧川鉄という形で対立することはほとんどなかった。営業と生産など部門間で意見が合わないことはしばしばあったが、そのとき同じ部門の旧NKKと旧川鉄の担当者は協力していた」（原田氏、39ページ）
26

概念データモデルの体験談（３）
基盤がしっかりしているので基盤がしっかりしているので、がしっかりしているので、変更に変更に対応しやすくなる対応しやすくなる。
しやすくなる。つまり自社つまり自社の自社のビジネスのビジネスの成長に成長に合わせて情報わせて情報システム情報システムをシステムを拡張することができる拡張することができる「アプリケーション・システムの開発を従来よりも柔軟に進められるようになった。従来は、最初に決めた要件を変えずに進めるウオータフォール型開発になりやすかった。しかし新統合システムの開発においては、システム要件が業務に合わないところは修正するように、と現場に伝えた。
迷ったら原点に戻れと指示をした」（菊川氏、50ページ）

「（概念データモデルを作成すると）嵐が来たときもう一度、港（モデル）に戻って考えようじゃないか、という気になる。モデルをもう一度見て、それからアプリケーション・ソフト開発を再スタートできる。時間がかかるように見えるが、アプリケーションの基盤部分（データベースと更新などの制御方法）はすでに概念データモデルで設計を終えている。
アプリケーションの手直しにそれほど時間がかからないので、戻る気になる。プロジェクトを進めるうちに、ビジネス環境の変化を考慮したり想定外の部分を加えたりして、着実にプロジェクトを進めることができるので失敗が少ない」。「概念データモデルを設計しておくと、リーダーが嵐を受け入れてやり直す余地が残る。こういう点で素晴らしい手法だと思う」（JFE建材フェンス社長の渡邊氏、125ページ）
27

概念データモデルの体験談（４）
当社の当社の本来の本来のビジネスとはビジネスとは何とは何かを考かを考え話し合い、それに向それに向かって力かって力を合わせて進わせて進むようになる「 “本来の姿”をモデルで描いていくという気持ちで議論したので、鉄鋼ビジネスはこうありたいという共通目標を関係者が共有でき、それに向かって進むことが可能になった」（JFEスチールの原田氏、39ページ）

「ビジネスモデルや事業の本質を見出しながら、現場で扱うデータ項目まで決めていくトップダウンのやり方は、概念データモデル設計法しかなかった」（ JFEスチールの渡部氏、38ページ）

「概念データモデルを描くことで、全体の仕組みと現場の業務が浮き彫りになる。（合併する２つに会社が）お互いの業務の違いを争うのではなく、JFEスチールという新しくできた会社のあるべき姿をモデルの設計を通して考えるようになった」（菊川氏、15ページ）

28

本日の概要 書籍「ITによる業務変革の正攻法

JFEスチールの挑戦」の概要

 記者として見たJFEスチールのビジネス改革の特徴
 基盤構築に利用した手法「概念データモデル設計法」――利用者の視点から表現 JFEスチール
スチールのスチールの改革の改革の成功要因

29

JFEの成功の要因（１）求心力ある場を作る
みんなが納得みんなが納得する
納得する拠する拠り所（軸）を作り共有したので共有したので求心力したので求心力が求心力が働く

経営者

業務担当者

システム部門システム会社参照

JFEののビジネスのビジネスの姿（安定な安定な構造、構造、拠り所）

ビジネスのビジネスの姿（全体像と全体像と基本）基本）を図式化
概念データモデル
アプリケーション・ポートフォリオ
・・・
行動基準も行動基準も自然にしっかりしてくる
自然にしっかりしてくる
全体の俯瞰
役割の認識
責任の自覚

30

JFEの成功の要因（２） 世間のよくある失敗【拠り所・軸がない場合がない場合 世の中の開発現場の開発現場の例】

やっつけ仕事
やっつけ仕事になりがち仕事になりがち 「どうせ業務の仕組みもシステムもすぐに作り直すのだろう」と思うので、力が入らない 最初は張り切っても仕様変更のたびに土台から作り直さざるを得ず疲れてしまうし、結局間に合わない。そのうち、その場しのぎのつぎはぎ構造で済ませてしまい、良心が痛む 発注者の丸投げ、多重下請け構造もあり、コミュニケーションのとりようがない
31

JFEの成功の要因（３） 拠り所・軸・場を作る【JFEスチール
スチールのスチールの場合】
場合】

安定した
安定した拠した拠り所・軸があるので段階的があるので段階的に段階的に成長できる
成長できる

サプライチェーン・・・
営業と工場の連携・・・
業務見える化、コード体系整備、システム統合・・・

積み重ねるようにビジネスねるようにビジネスとビジネスと情報システム
情報システムをシステムを成長させる
成長させる

32

静的モデルの例
ビジネスで扱っている、あるいは管理している「もの」をみんなで認識
顧客
顧客名

品目（製品・製品・部品）
部品）
品目名

注文する

顧客注文品
顧客名
注文Ｎｏ
品目名

属する

注文を受ける

製品生産物
引き当てる

引当数量

引き当てられる

顧客名
注文Ｎｏ
品目名
製造番号

属する

生産を計画
する（製品）

注文数量
納期

引当品図番

製造手順

品目名（製品） 計画数量
製造番号
完成予定日
完成日
完成数量

使う

品目名
工順
加工機能名

生産を計画
する（部品）

部品生産物
品目名（製品） 計画数量
製造番号
完成予定日
品目名（部品） 完成日
完成数量

使用する

治工具・治工具・金型
治工具・金型名

作られる

投入品目
品目名
加工機能名
投入品目名

投入量
単位

産出物
品目名
加工機能名
産出品目名

産出量
単位

適用する

加工機能
品目名
加工機能名

投入する

段取時間
ｻｲｸﾙ時間産出する

使用する設備・設備・機械
設備・機械名作業を担当する

作業者
作業者名

33

基盤の考え方（企業情報システムの概念構造）

比較的
安定
活動に活動に対応

商品開発

生産技術

販売

資材調達

製造

製品物流

オンライントランザクション処理（Mission Critical Application）

中核業務用データベース
中核業務用データベース
ものに対応
ものに対応
商品

設備
治工具

材料
部品

技術者

顧客

注文

生産物

ロジスティク
ス・アプリ
ケーション

安定
情報サービス機能
利用者A利用者B

エンドユーザ・コンピューティング（業務機能支援）「もの」もの」に対応して対応してデータベースしてデータベースをデータベースを設計し設計し、活動に対応して対応してトランザクションデータしてトランザクションデータをトランザクションデータを設計する設計する。
する。

情報要求は不安定！

34

基盤の考え方（アプリケーション実装）
追加拡張が追加拡張が容易（
容易（通信事業者の通信事業者の例）
基幹業務系の基幹業務系のデータをデータをモデリングでモデリングでしっかり作
しっかり作っておく↓
すると、すると、システムのシステムの変更拡張が変更拡張が左の図のように容易のように容易になる
容易になる↓
ビジネスのビジネスの変化、変化、成長に成長に合わせて情報システム情報システムをシステムを積み重ねるように無理なく無理なく着実なく着実に着実に拡張できる
拡張できる

池田、「変化に強い情報システムを作る」、日経
ITプロフェッショナル、2005年4～6月
http://itpro.nikkeibp.co.jp/article/COLUMN/20070
35
618/275015/?ST=system

基盤の考え方（レイヤ構造）
生産情報システム・アーキテクチャの枠組み
レイヤと視点

ビジネス・アーキテクチャ データ・アーキテクチャ
ＢＡ
ＤＡ

アプリケーション・アーキテクチャ ＡＡ

テクノロジ・
アーキテクチャ ＴＡ

ステークホルダ

企業間連携
アプリケーション

企業間連携の情報通信
アーキテクチャ経営者とその連合生産計画、注文管理
アプリケーションの運用

アプリケーション
連携パターン管理

事業
管理者

業務機能別
アプリケーション

統合分散処理とアプリケーション起動
順序管理

機能部門
管理者

スケジューラ、作業指示/実績把握
アプリケーション

統合分散OLTPとメモリーレジデント

作業
管理者

製品生産計画と資材供給計画生成A
アプリケーション

大容量かつ処理効率の高い
DBMS

資源供給
管理者

部品表・工程表等
管理アプリケーション（AP）

豊かな表現能力とカプセル型DBMS

製品/製造
技術
管理者

レイヤ6
企業関係

レイヤ5
ビジネス形態

レイヤ4
業務機能

レイヤ3
ビジネス活動

レイヤ2
ビジネス対象物

レイヤ1
種類と機能

企業ネットワークによる製造、系列

統合分散データ仕様とインタフェース仕様

生産・販売形態
ビジネスモデル

顧客注文と生産計画の関係付け

ビジネス・プロセスとその連携可能にする可能にする統合/分散データベース
可能にする

ビジネス活動の制御方法

スケジュール
実績データ

現物の識別と管理方法

生産計画/現物を捉えるデータ

チェッ
クし、可能にする製品構造と製造方法
生産技術

製品構造や製造方法を表すデータ

導出し、チェッ
ク

36

手島、大塚、日本生産管理学会誌、vol.14, no.2, 2008年3月
Copyright

NPO法人技術データ管理支援協会

まとめ JFEスチールは、10年間、ITを利用した業務変革を実施し、現在も継続中
 鉄鋼ビジネスの本来の姿や基盤を、自分で汗を流しながら考え、ビジネス全体を俯瞰、関係者が共有した みんなが納得できる安定した基盤と目標があるので、関係者はそれを拠り所に力を合わせて着実に進むことができる しっかりした基盤と目標を作る方法の一つとして概念データモデ
ル設計法を利用している

37

おわりに
 JFEスチールは、「企業の役割」や「顧客層とその顧客層に提供する製品やサービス」「ビジネスを進化させるための基盤」を考えた。
 同様に考えたほうがよい日本の企業は多いように見える。例えば、家電メーカは「企業の役割」や「顧客層とその顧客層に提供する製品やサービス」「ビジネスを進化させるための基盤」を、今どう捉えているのか・・・

38