データ経営が日本を変える！

一般社団法人 日本情報システム・ユーザー協会（JUAS）
システム高度化プロジェクト編

「データ経営が日本を変える！」目次「“データ経営”が日本を変える！」エグゼクティブ・サマリー ................................................................... 1
Ⅰ章 はじめに ............................................................................................................................ 8
Ⅱ章 情報システムのあるべき姿.................................................................................................... 11
本章のサマリー ............................................................................................................................... 11
Ⅱ．1 「システム」とは何か？ ............................................................................................................. 11Ⅱ．2 情報システムの類型化 ............................................................................................................ 12
Ⅱ．3 情報システムのエンジニアリング .............................................................................................. 13
Ⅱ．4 経営と情報システム................................................................................................................ 15
Ⅱ．5 ビジネスのデジタル化 ............................................................................................................ 16
Ⅱ．6 情報システムの進化プロセス ................................................................................................... 18
Ⅱ．7 経営目標・戦略を実現する情報システムのあるべき姿 ................................................................. 19＜参考文献＞ ................................................................................................................................. 21
Ⅲ章 システム高度化へ向けた問題とその背景 ................................................................................. 22
本章のサマリー ............................................................................................................................... 22
Ⅲ．1 「データの重要性が経営に十分理解されていない」...................................................................... 23
Ⅲ．2 「攻めの IT への取組みが不十分」 ............................................................................................25
Ⅲ．3 「システム開発・維持管理における標準化が進んでいない」 ........................................................... 27
Ⅲ．4 「情報システムに柔軟性がない」 ............................................................................................... 28
Ⅳ章 日本らしさとは～日本の情報システムの有るべき姿 .................................................................. 30
本章のサマリー ............................................................................................................................... 30
Ⅳ．1 日本の特性 ............................................................................................................................ 30
Ⅳ．2 日本の「らしさ」の定義 ............................................................................................................ 34
Ⅳ．3 日本の情報システムの有るべき姿とは ...................................................................................... 35
Ⅳ．4 日本らしさを活かし世界と戦う ................................................................................................ 37
Ⅴ章 情報システムの高度化とは ................................................................................................... 38
本章のサマリー ............................................................................................................................... 38
Ⅴ．1 情報システムについて ............................................................................................................. 38
Ⅴ．2 情報システムの高度化とは ...................................................................................................... 43
Ⅴ．3 高度化に必要なこととは ......................................................................................................... 53
Ⅴ．4 持続的競争優位性を保持するために ........................................................................................ 57
Ⅴ．5 高度化における課題と解決策 .................................................................................................. 58
Ⅴ．6 いかに高度化するか ............................................................................................................... 60
Ⅵ章 継承すべきものと刷新すべきもの ......................................................................................... 61

本章のサマリー ............................................................................................................................... 61
Ⅵ．1 継承すべき「データ」と「ナレッジ」.............................................................................................. 61
Ⅵ．2 刷新すべき「データマネジメント環境」 ....................................................................................... 68
Ⅵ．3 随時刷新しておくべき「概念データモデル（データ設計図書）」....................................................... 75〈参考文献〉 .................................................................................................................................... 75
Ⅶ章 データの大切さ ................................................................................................................. 76
本章のサマリー ............................................................................................................................... 76
Ⅶ．1 ビジネスにおけるデータの意義 ................................................................................................ 77
Ⅶ．2 情報システムにおけるデータの位置づけ ................................................................................... 78
Ⅶ．3 国内の情報システムにおけるデータの課題 ................................................................................ 79
Ⅶ．4 データ中心による柔軟性の高い情報システム構築 ...................................................................... 79
Ⅶ．5 マスター・データとトランザクション・データ ................................................................................ 82
Ⅶ．6 高度なデータ活用を実現する組織の 6 箇条 .............................................................................. 83＜参考文献＞ ................................................................................................................................. 85
Ⅷ章 大切なデータを生かすデータモデルとは～データモデルの価値と課題 .......................................... 86
本章のサマリー ............................................................................................................................... 86
Ⅷ．1 データモデルの本質的価値 ...................................................................................................... 87
Ⅷ．2 データモデルとデータをつなぐ価値.......................................................................................... 88
Ⅷ．3 データの位置付けと扱い ......................................................................................................... 89
Ⅷ．4 データモデルの役割と価値...................................................................................................... 89
Ⅷ．5 データモデルはデータ活用のための基礎である ......................................................................... 90
Ⅷ．6 情報活用の 7 ステップとデータモデル...................................................................................... 92
Ⅷ．7 情報システム開発方法とデータモデル....................................................................................... 93
Ⅷ．8 ビジネスモデル・データモデル・プロセス（業務）モデル................................................................. 94
Ⅷ．9 データモデルなんて嫌い？ ...................................................................................................... 98
Ⅷ．10 データモデル普及の処方箋：データモデルの価値を知る三つのステップ .................................... 101
Ⅷ．11 データモデリングの三つの KSF（重要成功要因） ....................................................................104
Ⅸ章 IT 部門の役割 ................................................................................................................. 106
本章のサマリー ............................................................................................................................. 106
Ⅸ．1 組織発足からの経緯と技術的背景 .......................................................................................... 106
Ⅸ．2 人材育成を担う組織として .................................................................................................... 112
Ⅸ．3 データマネジメントを担う組織として ...................................................................................... 114
Ⅹ章 マネジメント業務のカイゼンとデータ統合のためのシステム開発方法論 ....................................... 115
本章のサマリー ............................................................................................................................. 115
Ⅹ．1 DOA は何を目指したか ........................................................................................................ 115
Ⅹ．2 マネジメント業務のカイゼンとデータ統合のためのシステム開発方法論 ....................................... 116

Ⅹ．3 情報システムエンジニアリングにおける職種とその役割 ............................................................. 124
Ⅹ．4 データの高度利用（DX）の本格化に向け何をすべきか ..............................................................126
参考：システムズアプローチ ............................................................................................................ 127
Ⅺ章 変化への対応力 ～レジリエンスとアジリティ ......................................................................... 130
本章のサマリー ............................................................................................................................. 130
Ⅺ．1 日本的経営とは ................................................................................................................... 130
Ⅺ．2 レジリエンスとは .................................................................................................................. 130
Ⅺ．3 アジリティとは ..................................................................................................................... 131
Ⅺ．4 情報システムはどうあればよいか ........................................................................................... 132
Ⅺ．5 レジリエンスとアジリティ....................................................................................................... 147＜参考文献＞ ...............................................................................................................................147
Ⅻ章 マネジメントに求められること ............................................................................................ 148
本章のサマリー ............................................................................................................................. 148
Ⅻ．1 システム開発を成功させるために経営者に求められる行動 ........................................................ 148
Ⅻ．2 トップマネジメントによる DX 推進 ......................................................................................... 150
Ⅻ．3 デジタル時代のマネジメント .................................................................................................. 154＜参考文献＞ ...............................................................................................................................154
XⅢ章 データ経営の実現と提言 ................................................................................................. 156
本章のサマリー ............................................................................................................................. 156
XⅢ．1 データに基づく経営マネジメントの推進 ................................................................................156
XⅢ．2 デジタルビジネスの継続的な創造 ........................................................................................ 157
XⅢ．3 データを中心としたシステム基盤の構築 ...............................................................................159
XⅢ．4 変化に追従できる俊敏なシステム構築 ................................................................................. 160
XⅢ．5 データ経営実現に向けた提言 .............................................................................................. 161
ⅩⅣ章 あとがき ..................................................................................................................... 163
プロジェクト活動概要 ................................................................................................................ 168
参画メンバー ................................................................................................................................ 168
開催概要 ...................................................................................................................................... 168

「“データ経営”が日本を変える！」エグゼクティブ・サマリー「Japan as No.1」と言われ、IT を駆使して世界をリードしていた日本は、なぜ国際競争力の低下傾向に歯止めがかからず、IT 後進国と言われるまでに凋落してしまったのか？
筆者らのプロジェクトの出発点はここにある。本書は、この問題に真正面から向き合い、日本らしさを強みとして活かしつつ競争力を高めていくために、何をすべきかについてメンバー全員の叡智を集約し提言としてまとめたものである。
情報システムの本質は、「データ」⇒「情報」⇒「知識」⇒「知恵」へとデータを上手に活用していくことで、“データ経営”につなげ、企業のビジネスを発展させ、競争力を高めていくことにある。このように企業の情報システム
を考えると、単にコンピューターシステムを対象とするだけでなく、「組織」や「人」を含めた集合体として、データの「経営戦略への活かし方」や「データマネジメント」までを対象として考えねばならない。
1960 年代から導入されてきたコンピューターシステムは、主に大企業で業務の効率化・省力化を目的として発展してきたもので、「ビジネスの写像」としての情報システムの特性を生かし、人と組織の意思決定と企業の目
標達成活動を支援する重要な役割を果たし、事業の継続性を担保してきた。一方、テクノロジーの進歩と IT 利
活用の多様化は、情報システムに新たな価値を生み出す力を与えてきた。情報システムから得られる知恵は、
新技術によるイノベーションとして企業変革を継続するアイデアを生み、企業の創造的破壊を支援するまでに至っている。このように情報システムを、「事実としてのデータ」から「意味ある情報」、「価値のある知識」、「意思決定の知恵」へと、Intelligence を生み出すサイクルとして機能させることで、DX（Digital Transformation）の要となる“データ経営”の礎ができ上がってくる。
情報システムの役割の変化と価値を以下に示す。
役 割

価 値

①

実世界の写像として、人と組織の意思決定、企業の目標達成活動を支援

事業の継続性担保②

新技術によるイノベーションとして、企業変革を継続するトリガー

創造的破壊の支援

情報システムの役割が変化してきたことにより、企業のビジネス価値の拡充と新たな価値の創造を促すために
情報システムの進化が必要となってきた。我々は、それを「システムの高度化」と定義する。
情報システムの高度化によってビジネスの発展と変革に寄与するのである。
「なぜ、日本は長期的に国際競争力が低下し、IT 後進国と言われるまでに凋落してしまったのか？」という課
題に戻ろう。
国際通貨基金（IMD）の世界競争力センターの「世界競争力ランキング」（図表Ⅲ-1 参照）では、ビジネス効率性に関する評価項目が際立って低く、企業の俊敏性、企業意思決定に関する指標を意味する「経営プラクティ
ス」、あるいは「生産性・効率性」「姿勢・価値観」といった項目が軒並みかなり低く評価されている。
1991 年からの 30 年間に、競争力を得るために世界中のあらゆる企業が積極的に導入してきた情報システ
ムの活用が、諸外国に比べ日本では不十分だったことが理由の一つに考えられる。この間、米国の IT 投資は3.6 倍と伸びているのに対し日本は 1.1 倍とほぼ横這いであったが、日本も継続的な投資は行ってきており、日本だけが新しい情報技術の導入を怠ってきたわけではない。
ではなぜか？努力の方向そのものに誤りがあったということが考えられる。高度成長期を経て世界有数の競1

争力を誇った時代が終焉し、我々を取り巻く環境が大きく変化しているにも関わらず、当時のまま、情報システ
ムの開発・改修を、「昔の通りに、変わらず続けてきてしまった」こと自体が原因ではないだろうか。過去の成功体験から脱却できていないことに大きな原因があったと考えている。一方、投資の内容としては、現行システムの維持管理（ラン・ザ・ビジネス予算）とビジネス価値創造のための予算（バリューアップ予算）との比率は、ほぼ
8 対 2 で続けられ、守りの対応に終始してきたとも言える。また、この間に顧客要望の厳格化やテクノロジーの進化などにより複雑化してきたビジネス環境に対応するため、情報システムの開発・改修を繰り返してきたことが、サボテン、スパゲッティと称されるように複雑なレガシーシステムを保有せざるを得なくなってしまった原因となっている。さらに、最近は改善されつつあると信じたいが、システム開発・維持管理を長期にわたって外部に「丸投げ」し、経営戦略の礎たるシステムの「ブラックボックス化」を進めてきてしまったことも挙げておきたい。
日本の国際競争力低下の原因と考える「システム高度化へ向けた問題」は、次の四つである。
（1）企業経営の根幹をなす「データの重要性が経営に十分理解されていない」（2）イノベーションのトリガーとなる「攻めの IT への取組みが不十分」（3）情報システムをレガシー化させない「システム開発・維持管理における標準化が進んでいない」（4）変化への素早い対応が求められる「情報システムに柔軟性がない」
この四つの問題が複雑に絡み合い、お互いに影響しあい、相乗的に悪化の道を辿ってきてしまったと考えられる。過去に、日本へ欧米流の EA（Enterprise Architecture）の考え方が導入されたときに、データの重要性とシステム構築の考え方を改める機会があったが、従来の POA（Process Oriented Approach）の考え方から DOA（Data Oriented Approach）の考え方へ脱却できず、「昔通りに変わらず、システムを構築・改修することを続けてきてしまった」ことが大きな問題だった。
特に、ビジネス環境が変化し続け、テクノロジーも進歩し続けている中では、企業経営を支える「情報システムに柔軟性がない」ことは致命傷となりかねないものである。先に掲げた「情報システムの高度化」の定義に柔軟性を付け加え、「変化への素早い対応により、企業のビジネス価値の拡充と新たな価値の創造を促す変革につなげる」ことを、システム高度化の使命とせねばならない。
システム高度化への道筋を考えていくときに、情報システムとその活用を単独に考えるのではなく、ビジネス戦略を支える武器として、情報システムをビジネスと密接に連携させていくことが必要である。そして、ビジネスと情報システムを連携させる役割を担うのがデータで、ビジネス、データ、プロセスを三つのモデルに分けて考え連携させていくアプローチをとることになる。
・「ビジネスモデル」：企業のビジネス全体を俯瞰しその戦略までを表したもので、超概要として表現すれば、製造業では顧客から「受注する―造る―届ける」の三つの活動の上で「収益」を得るモデルである。サービ
ス業では、「造る」を「サービス」と読み替えると理解しやすい。
この時の企業のミッションは、「収益最大化」と「顧客満足度」である。
・「データモデル」：ビジネスモデルで必要とされる「データ」と「その関連」を表すもので、ビジネス全体を俯瞰して重要なデータとその関連を表現する。これを抽象化して描いたものが「概念データモデル」で、企業のビジネスにとって普遍的なデータが存在することが見えてくる。
・「プロセス（業務）モデル」：従来のシステム開発で多用されてきた要件定義に基づく「業務フロー」や「業務要件」を表したもので、業務の自動化・省力化に多大な力を発揮した。しかし、ビジネスの実態をプロセスモデ
ルに写し取ることは、「抜け」や「漏れ」が生じることが多く、極めて難しい。
2

この三つを分けて考えることが重要で、ビジネスを直接プロセスモデルに表現するのではなく、概念データモ
デルに写し取り、これに基づいて必要なデータとプロセスの関係を表すことが必要なのである。この過程で「データ」を正しく定義（正規化）し、必要な「データ」と「プロセス（アプリケーション）」を正しく描くことができ、「実世界の写像」としての情報システムができあがる。このように、情報システムを「データ」と「アプリケーション」に分離して考える DOA（Data Oriented Approach）で構築することで、デジタル戦略の実現や DX（Digital
Transformation）対応の基盤を創りあげる。
DX を進めねば生き残っていけない現下の状況において、多くの重大な問題を抱えている日本であるが、筆者らは、決して諦めている訳ではない。課題も多いが良いところも沢山ある「日本らしさ」を武器にして、もう一度高い競争力を持って世界と伍していっていただきたいと思っている。
「日本らしさ」には、長所も欠点もあるが、その特徴として筆者らが考えてきたことは、（1）他国の文化・知恵を取り入れる能力に長けている
・自国の文化を残しつつ、他国の文化・知恵を取り入れる能力に長けている。
・但し、危機感から発せられる共通の目的意識がなければこの能力は発揮されない。
（2）危機に強い・危機が迫った時は、自身が正しいと思うことをストイックに実施する。
・その判断は自身のためよりも全体の協調を優先する。
（3）多能である
・器用であり多能である。但し、この点も目的意識がなければ過剰品質になる危険性がある。
（4）成功体験から離れらない・目的意識がなければ前例の成功体験に従う。他国の文化・知恵を上手に取り入れる能力は稀にしか発揮されないので、大抵は過去の成功体験に従っている。
欠点を認めたうえで正すべきものは正し、長所を生かして「日本らしさ」で世界と戦う覚悟を持って、DX に臨
まねばならないと考えている。以下のような戦略を提案したい。
・ DX に代表されるデジタル・ディスラプションが現実的な脅威であることを認識する。
・ デジタルという武器の実態は、「プロセス」ではなく「データ」であることを理解する。
（デジタル以外の武器もあるにはあるが、デジタルとまともに戦える武器はデジタル以外にない）・ 企業の本質をデータでデザインし、そのデータを発生・変更・消去するプロセスは、器用で多能な日本らしい能力を十分に発揮し、自由に作る。この時、データを保証することを忘れてはならない。
こ の 提 案 に は 、 今 ま で の POA （ Process Oriented Approach ） 的 な 発 想 で は な く 、 DOA （ Data
Oriented Approach）的発想が必要となる。過去の成功体験では戦えないことを認識し、最新技術を「日本らしく」自身の血肉にする必要がある。私たちはそれができる、数少ない国に生まれている。
本プロジェクトは、企業の「“データ”経営が日本を変える」と信じ、「情報システム高度化」が、変革を促す力になると考えて進めてきた。
・「企業価値を高めるシステム高度化」の使命は、繰り返すと、「ビジネス価値の向上に貢献し続けられる仕組みを素早く継続的に提供し、創出し続けること」である。これが変革へとつながっていく。
・この使命を果たすために、体系化された（企業経営のリソースとなる）要素の機動性を IT によって3

高め、あらゆる変化に対して柔軟に、迅速に対応できる状態であり続けることが重要となる。
・この時もデータが重要であり、「データ」を軸に経営の機動性を高めていくことが肝要となる。
その実現のためには、ビジネスと情報システムが一体化していなければならない。この際の情報システムは、
前述した二つの役割・効果の実現が可能であること、すなわちデータを活用し、「①システムで、実ビジネスを写像として把握でき、②新しい価値の創造が図れる」ことを可能とすることである。これを満たすことができて初めて「①②の礎として経営者や情報活用者が拠り所とするに足るデータを保証する」という情報システムが本来持つべき使命を全うすることになる。さらに、データ活用は当然であり、データ活用なくして企業の存続はありえな
いことを、経営者まで全員で認識し共有する必要がある。
その際に必要とされる方法論を EA（Enterprise Architecture）の視点から考えてみる。企業内・企業間
で情報システムが変化に対応するために必要なことは、データの正規化と連携を確保することである。つまりEA において DA（Data Architecture）がきちんと機能している状態を保証することである。
過去に日本では、上流の要件定義で“全てを決めてしまう”発想が強く、AA（Application Architecture）の中にデータを内包させてしまう剛構造（変化に対応するのが難しい）システムを作ってシステム品質を保証することが主流であった。結果として、複数の意味を持つ複合コードが多用され、同様類似のデータをシステム内
で分散・保有せざるを得ない状況に陥り、柔軟性を喪失させ、システムを複雑化させてしまった。その後の国際競争力を低下させる原因を基幹システムの中に内包させてしまったのである。
システムの柔軟性を得るためには、AA（Application Architecture）層からデータを分離し DA（Data
Architecture）層に保管し、変更してはいけないデータを守るためのアーキテクチャーとする必要がある。これ
により、データが正しく定義されて保護される環境が作られ、保証されたデータを得ることができる。これが、企業内で「正規化されたデータ」になり、企業活動を支える基盤が作り上げられる。
さらに情報システムの基盤として DA を下支えする「データマネジメント」 が組織として機能している必要があり、それを機能させるためにデータモデルに基づいた持続的データマネジメントが重要となる。情報システムの高度化を長期にわたって維持できるようにする組織であり、変化への対応の時に情報システムのアーキテク
チャーを崩させない（レガシーシステム化させない）ための組織でもある。
次に、情報システムの高度化をどのように進めるか、「継承すべきもの」と「刷新すべきもの」について論じたい。
企業が継承すべきものは何か。それは「データ」と「ナレッジ」である。即ちその企業が辿った歴史の「記録」であり、集った人が蓄えた「業務知識」である。情報システムに蓄積されたデータとナレッジは、IT 部門が預かり蓄
えた、継承すべき無形資産である。データ資産を継承し、データを中心に新たなビジネス戦略を発想する。ビジネス戦略が求める新たなデータを見定め、そのデータを得るために最適な手段を選択することが IT 戦略の立案となり変革への一歩となる。継承すべき「業務知識」は、経営のための「ナレッジ」で、システムに埋め込まれた
重要なビジネスルールを表した「データの要件」を見える化して、継承せねばならない。見える化で最も重要となるものが、データの「意味」と「その関連」を表現した「概念データモデル」と「その関連図書」で、常に最新の状態に維持し続けなければならない。
刷新すべきものとして取り上げるのが、「データマネジメント環境」である。情報システムの価値を高め、DOA
によりシステムを高度化するための重要なマネジメントとして位置付けている。
① 「プロセス（アプリケーション）領域(AA 層)からデータ領域(DA 層)を独立させるアーキテクチャー」
前述の EA の考え方に基づき対応するもので、さらに AA と DA を一緒に検討しながらもはっきりと分4離させる 3.5 層のアーキテクチャー（図表Ⅺ-4 参照）に発展させるアプローチを推奨したい。
② 「“データ経営”のためのビジネス価値を高めるデータ中心（DOBA）の方法論」
DOBA（Data Oriented Business Approach）として新たに定義した概念で、柔軟なシステムであるだけでなく、経営が求めるデータが何かを考え、システムから適切な情報を取り出せるようにする。
③ 「ビジネス価値を高めるデータ中心（DOBA）の組織・人材づくり」
DOBA を推進するに際して、「データモデリングスキルを持った人材の育成と維持」とビジネスを考え経営戦略と連動させる「データ中心型アーキテクチャーを維持する組織」が要件となる。
継承すべきものとしたデータは、企業活動にとって、ヒト、モノ、カネに続く第 4 の経営資源と言われるようになっている。また、ナレッジ継承のために最も重要となるのが、「概念データモデル」であることは前述のとおりであるが、さらに、「概念データモデル」は、データに記述された内容を他者へ伝達・共有するための説明書であり、DOA による改革を導くための「肝」ともいえるものになってきている。
特に、「概念データモデル」を描いた上で、DOA でシステムを構築すると、データとプロセス（アプリケーション）
を分離して考え、ビジネス全体を俯瞰して見るようになり、以下の優れた効果が得られる。
① 変化に強いシステムができること② 既存のビジネスが可視化しやすくなること「大切なデータを生かすデータモデルの価値と課題」については、執筆者全員の考えを個別レポートとしてまとめているので、Ⅷ章を参照していただきたい。また、システムのライフサイクルに比較すると、データのライフサイ
クル（図表Ⅶ-2 参照）は非常に長いので、システムの設計においてデータの設計（データアーキテクチャー）の良
し悪しは、より長期的に影響を及ぼすことに注意が必要である。ここでも「概念データモデル」を描くスキルと参画するメンバーのビジネスに対する理解度が試される。
これからの世界で、ビジネスを変革し企業が成長し続ける支援をする情報システムを高度化していくためには、データの果たす役割がますます重要になる。その時のマネジメント指針として、図表Ⅶ-6 に「データマネジメ
ント推進 6 箇条」をまとめているので、是非ご参照いただきたい。
本書で重要性を論じてきた DOA によるシステムの高度化とビジネス変革の流れと関連して、図表Ⅸ-1 に「企業システムの変遷」と題しシステム高度化のステージと開発方法論、標準化の流れを、図表Ⅸ-2 に「IT 企業の設立年」をまとめたが、対比してみると世界的に特異な情報子会社の設立によるアウトソース化の流れが強く出ている。1980 年代後半から 1990 年代前半の増加は顕著であり、皮肉にも DOA が紹介された時期と重なっていることが特徴的で、結果的にユーザー企業から、DOA を推進する核となる IT 人材が減少した時期となってしまった。
“データ経営”を目指す中で重要となるデータマネジメント人材を考える上で、IT 部門と情報子会社、さらにDX 推進部門との役割分担、連携の仕方、モデリングスキルの向上が今後のカギとなる。問題となるのは、これまでデータマネジメントの重要性を繰り返し訴えてきたが、情報子会社を含む IT 部門の役割に、多くの場合は
この「データマネジメント」という言葉が含まれていないことである。
さらに DX と同時に情報システムの高度化を進めるうえで、IT 部門のミッションに「ビジネス創造の支援」と「データマネジメント支援」を加え、DX 推進部門と IT 部門・情報子会社が連携して人材育成と課題の解決に取り組んでいくように、変えていかねばならない重要な時期にきていると考えている。
5

企業における情報システムの具備すべき要件として「変化への素早い対応力」が重要であるが、これを備えるために必要となるのが、「レジリエンス」と「アジリティ」である。
ここで言う「レジリエンス」は、過去に学びリスクを回避するナレッジをコンパクトに「継承」すること、「アジリティ」は、素早い判断でビジネス環境の変化に対応する「俊敏性」である。そのポイントは、① EA の「3.5 層のアーキテクチャー」（図表Ⅺ-4 参照）でビジネスの骨格を見える化して継承する
EA の中で、データ構造を示す「DA 層を“剛”」、プロセスや画面を含む「AA 層を“柔”」として、剛柔を併せ持ったアーキテクチャーを作り、BA 層のビジネスと TA 層の IT インフラを“データがつなぐ”構造にすることで、ナレッジの継承に威力を発揮すると考えている。
② 「データ中心の方法論」（DOBA）で、ビジネスを写し取った情報システムを俊敏に構築する求められるビジネスモデルの変革スピードにシンクロさせて情報システムを対応させるために、新たな価値の源泉となるデータを中心に置いてシステムを進化させ続ける方法論である。
ビジネスゴールを見据え、経営ナレッジを表現する重要データを概念データモデルで写し取ってから、
実装手段の柔軟な選択肢を得て、俊敏に構築する。
これにより、日本らしく高度化した情報システムは、「確実な継承」と「俊敏な改変」が可能となり、環境の変化に素早く柔軟に対応できるようになる。
次に、トップマネジメントに求められる行動規範について述べておきたい。特に、問題点として指摘した「データの重要性が経営に十分理解されていないこと」は、日本企業の抱える大きな弱点でもある。
システム開発、特に DX を成功させるために経営者に求められる 10 の行動規範を以下にまとめた。
① DX の重要性について社員にメッセージを発信する② 自らセミナーや研修に参加して DX や IT を積極的に学ぶ③

凝り固まった考え方をときほぐし多様性の高い組織をつくる④ 現場に顔を出す⑤ DX 先進企業のトップマネジメントと交流する⑥

ベンチャー企業との接点をもつ⑦

部下のはしごを外さない⑧

失敗を許容する懐の深さを身につける⑨

リスクから逃げない⑩ うまくいかなくても決して諦めずチャレンジし続ける「日本らしさ」を発揮して、国際競争力を高めていくために是非実行していただきたいと考えている。
最後に、「“データ経営”の実現と提言」をまとめておきたい。
・ 日本企業が抱える、システム高度化へ向けて解決しなければならない問題は、「データドリブン」の考え方を理解し、「データ経営」を実現することで全て解決する。
・ 「データドリブン」の考え方とは、「データにより、ビジネス環境の変化が把握できたり、変革を推進できた
りする」という考え方である。
◆ データにより環境の変化を把握する： 数値化されたりセグメント化されたりしたデータを、時系列や比率でグラフ化するなどして、定量的に環境の変化を把握できるようにすること。
6◆ データにより変革を推進する： 新たなゴール（ビジネスモデルやビジネスルール）をデータモデルで明示して、モデル上で変革ポイントが分かるようにして変革への道筋を示すこと。
・ 経営者は、変化の激しい経営環境を乗り切るために、データに基づく経営マネジメントを推進しなければならない。
・ 企業は既存ビジネスの効率化だけではなく、様々なデータを活用した新しいデジタルビジネスを継続的に創造していくとともに既存ビジネスとも連携させて価値を拡大させていく必要がある。
・ システム開発の高度化とシステム維持管理の標準化は、「データに基づく経営マネジメントの推進」と「デジタルビジネスの継続的な創造」の実現のために必要な基盤と認識すべきである。
・ システム開発は「モノ造り」ではないし、システムも完成品ではない。育て続けるものとして認識し、DOAなどを駆使し、変化に追従できる俊敏なシステム開発を行っていかなければならない。
以上から、我々が意識して進めることを示しておく。
・ DX の推進をデータ経営へシフトする好機と捉える。
・ レガシー刷新はナレッジ継承のための活動とみなす。
・ IT 部門のミッションに「ビジネス創造の支援」と「データマネジメント支援」を加える。
以下に、「システム高度化へ向けた課題」と「データ経営の実現」に向けての提言をまとめておく。

本書が、DX（Digital Transformation）を推進する多くの企業の参考になれば、幸いである。
日本人は、「危機に強い」類稀な民族である。復活の烽火を揚げる皆様のご活躍を期待している。
JUAS システム高度化プロジェクト一同7

Ⅰ章 はじめに野々垣 典男
わが国では 1960 年代より、主に大企業において業務の効率化・省力化を目的としたコンピューターシス
テムの導入が始まった。それから半世紀以上が経過した現在、身の回りにはコンピューターシステムが溢れている。企業では社員のデスクにはパソコンが置かれており、業務アプリケーションやメールシステムなどを使用して、業務のほとんどがパソコンにより遂行するように変わった。プライベートではスマートフォンを持ち歩き、いつでもどこでもシステムを使うことができる。また AI によって各種予想がはじき出され、工場にはセンサーなどによって IoT（Internet of Things）を実現している。さらに、かつては高額なコンピューターを購入したりリースしたりする必要があったが、今ではコンピューターシステムを所有する必要がなく、クラウドコンピュ
ーティングを活用して「使った分だけ」費用を支払うことも可能である。
このような時代背景では企業を経営するにあたって、「システム」が極めて重要なリソースになってきており、システムの成否が経営の成否に直結する、と言っても過言ではない。システムの特性も、業務効率化のツールから、商品やサービスを販売するためのシステムへと変化してきた。したがって、「経営」と「システム」は切っても切り離せない関係となっている。特にスタートアップ企業やベンチャー企業においては、インターネットやクラウドコンピューティングの活用をはじめとして、システムの導入は従来とは異なり初期コストがほとんどかからないこともあって、かつてよりもシステム導入のハードルが格段に低くなってきている。そのため新しい企業ほどシステムを上手に使いこなし、ビジネスに活用しているように見える。一方で歴史のある大企業はどうだろうか。
大企業は過去から順次システムを導入してきており、今では大部分の業務がシステム化されている。その結果、極めて複雑で大規模なシステム資産を保有することになったと同時に、システム同士が複雑にからみ
あい、長年の間の保守・運用によってプログラムにも手を加え続けている。いまや「スパゲッティ・プログラム」と称されるように、ロジックがからみあい、解読不可能なコード群と化している。また 1980 年頃からは徐々に
大手システムインテグレーターに開発全体を委託する、あるいは保守・運用業務を含めてアウトソーシングしてきたことを契機として、システム開発などにユーザー企業が徐々に直接関与しなくなっていった。その結果、ユーザー企業は大規模なシステム開発に対応できるノウハウやナレッジが欠如することになった。
2018 年 9 月に発行された「DX レポート」1では、「複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025 年までに予想される IT 人材の引退やサポート終了等によるリスクの高まり等に伴う経済損失は、2025 年以降、最大 12 兆円／年にのぼる可能性がある」という想定を根拠として「2025 年の崖」と表現されている。いわゆる「レガシーシステム」といわれる古めかしいシステム群を抱えながら、一方で最新のシステムも使わざるを得ない大企業は、「2025 年の崖」をどのように乗り越え、スピード感のあるシス
テム開発を行う新興企業やいわゆる「デジタルディスラプター」にどのように対抗していくのか？
大企業を中心に、歴史ある企業の多くがこの課題と直面している。
JUAS では過去から、システム開発を適切に行うためのさまざまな取組みを実施してきている。要件定義
を適切に実施するなどエンジニアリングに関わる調査・研究、システム開発に関わる統計情報に着目したソフ

1

経済産業省 デジタルトランスフォーメーションに向けた研究会
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/2018090
7_report.html
8トウェアメトリクス調査、「人」に着目して整理した「情報システムユーザースキル標準」2など枚挙にいとまがない。しかし、大企業を中心として現在のシステムへの取組みを見てみると、それらが効果的、効率的に適用されてきていないのではないのか、という疑問が沸き起こる。このような想いは、特に IT 部門、情報子会社において痛感されている。折しも「DX（デジタルトランスフォーメーション）にどのように取り組むのか」という難題が突きつけられており、早急に解決すべき喫緊の課題となっている。この課題を解決するには、これまでに取り組んできたようなテーマごとに解決策を提案するのではなく、それらを総合的に発動する方法の検討や、これまでのわが国のシステム開発や保守・運用の問題点などを浮き彫りにする必要性もある。そこで 2017 年
6 月に前述の課題を解決するための検討を行う「システム高度化プロジェクト」をメンバー10 人で立ち上げた。
プロジェクトではこれまで月 1 回の割合で検討会を重ねてきた。その会合は 5 年間で 48 回を数える。検討のテーマとしては、・レガシーシステムの問題点
・デジタル化による環境変化
・「システム」の本質・高度化につながるアーキテクチャー
・データモデルのあり方
・組織と人材・システムのレジリエンス
・今後どうあるべきかなど多岐にわたるが、「経営価値と結びつけ」、「高度化とは何か」、「高度化の構成要素」、「高度化における課題と解決策」などを中心において検討を進めてきた。
議論を深めるなかで、システム高度化のカギとして、特に「データ」の重要性に着目した。「ビッグデータ」という用語が表すように、企業などが保有する膨大なデータを解析してビジネスに活かし競争優位性を確立する、という方針でシステム開発を進めるのが主流になりつつある。しかし過去の多くの情報システムは、人が行う仕事をコンピューターに肩代わりさせるものであり、人が作業する「プロセス」をコンピューターの中で実現しようとした。つまりプロセス中心でシステム開発が行われたのである。長年の習慣を変えることは難しく、システムを設計する際にはいまだにプロセス中心で設計されることが多い。システム開発が失敗する原因の一つに、プロセス中心のシステム設計が挙げられ、正しいデータモデルを描くことがシステム開発の成功のカギに成り得る、という結論に至った。
ところで、日本企業の多くが抱えるシステム高度化へ向けた問題は、おそらく次の 4 点、すなわち、
1.

データの重要性が経営に十分理解されていないこと

2. 「攻めの IT」への取組みが不十分なこと
3. システム開発や維持管理における標準化が進んでいないこと
4. 情報システムに柔軟性がなく、ビジネスの変化に対応できないことに収斂されるであろう。
そして、これらの問題を解決するために企業はどうすべきか、については、「データドリブン」の考え方に基
づき、「データ経営」を実現すること、に尽きるであろう。具体的には、上記 1 から 4 に対応する形で解決策を表現すると、

2

独立行政法人情報処理推進機構より受託して調査を実施した。
9

1.

データに基づく経営マネジメントの推進

2. デジタルビジネスの継続的な創造
3. データを中心としたシステム基盤の構築
4. 変化に追従できる俊敏なシステム構築になると本プロジェクトでは結論づけた。ビジネスのデジタル化が必須であるとともに、データに基づく経営を行わない限り、企業を存続させることができない、ということである。
本書に記載されている内容は、主に企業が情報システムを開発、保守・運用する際に心がけるべきエッセンスであるが、いわゆる「ベストプラクティス集」ではない。それぞれの企業がこれまでのシステム導入で経験したことや組織風土などによって戦術や施策は異なる。したがって自社（自組織）に合うようにテーラリングする必要がある。そのような方法で本書を活用していただければ幸いである。
なお本書は、プロジェクトのメンバー10 人で共同執筆したものであり、基本的には各章の担当者を決めて執筆した。そのため、似通った表現が複数の章で重複するなど、冗長に感じられるところもあると思われるがご容赦いただきたい。メンバーは異なる企業に所属し、システムに関わるこれまでの経験もさまざまであることから、システムに対する「想い」は十人十色である。そのために、無理に表現を統一したり、全体調和を求めたりしていない。そのため、各章が独立したレポートであり、どの章から読んでも理解できる、とポジティブに考えていただけると幸甚である。
さて、本書は 2019 年 12 月頃から執筆を開始したが、ご存知のとおり、その後の新型コロナウイルス（COVID-19）の蔓延により、スムーズに進められたわけではない。それまでのように毎月定例で集まることができず、しばらくは休会が続いた。その後はリモートでオンライン会議を実施し、進捗の確認やレビューを行った。
社会に目を転じると、これまでに再三「緊急事態宣言」が発出された。2021 年春先からはワクチン接種が開始され、多少なりとも安心できる環境は整ったように思えたが、変異株であるデルタ株、オミクロン株の世界的な流行はなお不安が残る。多くの企業は少なからず新型コロナウイルスの影響を受けており、特に人の移動がこれまで経験したことがないほど制限されたため、鉄道、航空、宿泊、旅行などの観光産業が顕著に影響を受けている。また外出が制限されたことから、外食の機会が減り、飲食業も大きな痛手を受けている。
今回のようなレベルではないにしても、これまでもこのような景気後退期には、システム投資の削減や中止を行う企業が多かった。しかしその選択はますます企業の存亡を危うくする可能性があることを本書からご理解いただきたい。
なお、新型コロナウイルス対策として実施された特別定額給付金や持続化給付金の申請手続きをはじめ、メガバンクの度重なるシステム障害の発生から、さまざまな場面で日本の IT 化及び DX（デジタルトランスフォーメーション）の遅れや問題が指摘されており、菅前内閣の目玉であったデジタル庁の新設に注目が集まっている。今やシステムは経営にとって最重要のリソースであり、使い方によっては事業を大きく躍進させる
こともできれば、反対に市場からの撤退を余儀なくされることにもなる。
最後に、本プロジェクトの主査であり中心的な役割を担っていた小田滋氏が 2019 年 9 月 26 日の未明に急逝した。その前日は夕刻から月 1 回の本プロジェクトの会合があり熱く議論した直後であった。小田氏を亡くして報告書を作成できるのか、という不安が頭をよぎったが、本書はこれまでのプロジェクトでの議論の集大成であるとともに、小田氏の遺作として残ったプロジェクトメンバーで完成させることを誓った。小田氏が前職で CIO として活躍した際の取組みやそこから得られた知見は大変参考になり、本書の随所に織り込んでいる。小田滋氏のご冥福を祈っている。
10

Ⅱ章 情報システムのあるべき姿
野々垣 典男
本章のサマリー

本書は、情報システムの他にも、「組織」や「人」に着目し、それらを検討の対象とする。

DX を推進するには、従来からの SoR に加えて、SoE に分類されるシステムがカギになる。



わが国ではこれまで、システム開発はベンダーに委託する前提でユーザー企業の業務やベンダーの産業構造が構築されてきたことにより、ユーザー企業が主体性をもたずベンダーに「丸投げ」するケースが増加している。

DX を推進するには、ユーザー企業が開発プロジェクトに対して主体性をもつとともに、「意識」、「組織」、「制度」、「権限」及び「人材」の五つの企業内変革が求められる。

Ⅱ章ではシステムを定義し、企業経営における情報システムの重要性と今後どのようにしてシステムに対応すべきなのか、について検討し、情報システムのあるべき姿を描く。
「システム」という用語は、コンピューターシステムのことを指して使用されることが多い。しかし広辞苑では、「複数の要素が有機的に関係しあい、全体としてまとまった機能を発揮している要素の集合体。組織。系統。
仕組み。」と説明されており、コンピューターシステムに限定されているわけではないことがわかる。

Ⅱ．1 「システム」とは何か？
最初に「システム」についての定義を明らかにし、本書が対象とする「情報システム」の範囲を示す。

Ⅱ．1．1 システムズエンジニアリングにおける「システム」の定義
システムズエンジニアリングは、システムを成功裏に実現するための、学際的なアプローチおよび手段 （INCOSE, 2015）
である。
システムズエンジニアリングでは「システム」を、定義された目的を達成する要素、サブシステム、またはアセンブリが統合されたひとまとまり。これらの要
素には、製品（ハードウェア、ソフトウェア、ファームウェア）、プロセス、人、情報、技術、設備、サービス、
およびその他のサポート要素が含まれる（INCOSE, 2015）と定義している。
このように、コンピューターのハードウェア、電化製品や自動車のような目に見えるものに限らず、目に見えないソフトウェアやサービスなどについても「システム」ということができる。さらにいえば、人を要素とする「社会」や「政治」なども「システム」ということになる。
本書では前述した広義の「システム」について検討するものではなく、企業や組織における「情報システム」
を対象とする。
11

Ⅱ．1．2 本書が対象とする「情報システム」の範囲
一般的に「情報システム」は、情報の処理や保管、伝達などを行うためのコンピューターやネットワーク、ソフトウェア、ストレージなどのコンピューターシステムを指す用語として使用されている。しかし本プロジェクト
では、それに加えて「組織」や「人」も重要な要素であることに気づいた。
その理由としては、情報システムは購入してすぐに使用できる類のものではなく、開発・保守・運用・廃棄な
どのシステムライフサイクルの各局面において組織や人が関与し、その善し悪しも組織や人に依存するものだからである。
したがって本書では、開発・保守・運用・廃棄などの対象物としてのシステムに、組織や人を加えた集合体
を「情報システム」として定義し、議論の範囲とする。なおここでの「組織」や「人」は、システム（IT）部門やシス
テム（IT）人材のみを指すのではなく、業務（ビジネス、ユーザー）部門や経営者を含めたステークホルダーや組織も対象とする。

Ⅱ．2 情報システムの類型化
ここでは情報システムの類型化を試みる。類型化の体系としては、2011 年にジェフリー・ムーアが著作したホワイトペーパーである”Systems of Engagement and The Future of Enterprise IT: A Sea
Change in Enterprise IT”（Moore, 2011）を参考にする。
そこには情報システムの種類として、SoR（System of Record）と SoE（System of Engagement）
が挙げられており、まずその 2 種類について説明したい。
図表Ⅱ-1 SOR と SOE の比較イメージ

Ⅱ．2．1 SoR（System of Record）
大企業で情報システムが導入され始めた 1960 年代から脈々と引き継がれてきたシステムである。データや情報を正確に記録することを重視して設計されたシステムである。会計システムや人事システム、メールシ
ステムなど従来から長期にわたって使われてきた基幹システムは SoR に分類される。
図表Ⅱ-1 のように企業内部のユーザーが社内に設置されたサーバーにアクセスしてデータを入力したり、12データの閲覧や帳票を出力したりするような閉じたシステムをイメージできる。

Ⅱ．2．2 SoE（System of Engagement）
インターネットが出現した 2000 年以降、顧客やユーザーとの関係性やつながりを重視して設計されたシステムである。SNS やネット通販サイト、フリマアプリなどインターネットを介して多くの人や企業をつなぎ、情報を提供・共有して活用するシステムは SoE に分類される。
図表Ⅱ-1 のように、インターネット上で展開される様々なサービスを利用することができる。操作するデバ
イスは、パソコン、スマートフォン、タブレット、テレビに限らない。VR ゴーグルや自動車のパネルなど、多種多様なデバイスから操作が可能になる。IoT（Internet of Things）による様々なセンサーも接続されている状況が想定される。

Ⅱ．2．3 これからのビジネスを進めるうえで大切なこと
制度会計や管理会計、人事情報などのようにデータや情報を正確に記録することを目的とするシステムは今後も無くならない。つまり SoR に分類されるシステムは今後も存在し続ける。一方で、ビジネスで重要な売上を増やしたり、競争優位性を確立したりするには、「SoE」を強く意識したシステム戦略を策定すべきであり、その実践を行う必要がある。
この 2 種類のシステムをバランスよく適切に開発・保守・運用するには「バイモーダル」の発想、つまり SoRのための様式と、SoE のための様式を共存させる戦略が重要になる。過去から脈々と開発し続けてきた
SoR のシステムはすぐには廃棄できず、使い続けていくことになる。SoR のシステムで収集し保存してきたデータや情報を SoE のシステムでどのように活用するのか、あるいは SoE のシステムから収集されるデータを
SoR のシステムにどのように取り込むのか、がカギになる。また SoR のシステムを「レガシー化」させない方策を検討すべきである。
なお両システムの間で往来するのは「データ」であり、本書で繰り返し述べられるデータモデルの重要性がキーポイントになる。

Ⅱ．3 情報システムのエンジニアリング
現在わが国では、ほとんどの情報システムはベンダーに委託する形態で開発されている。その背景として、
1970 年代からシステムインテグレーター（SIer）にシステム開発を一括発注することが多くなり、ユーザー企
業はシステム人材を自社で抱える必要がなくなった。
その結果、図表Ⅱ-2 のとおり、米国ではシステム人材の約 7 割がユーザー企業に所属しているのに対して、日本ではその反対にシステム人材の約 7 割がベンダーに所属している（IPA, 2017）。
そのためシステム開発そのものはベンダーが実施しており、エンジニアリングの担い手はベンダーの人材
である。

13

図表Ⅱ-2 IT 関連人材の所属先の日米比較（単位：人、％）

IT関連人材の総人数
内

IT企業に所属

訳 ユーザー企業に所属

日本
人数
割合

米国
人数
割合

1,045,200 100.0

4,195,110 100.0

752,600

72.0

1,453,300

34.6

292,600

28.0

2,741,810

65.4

出典:独立行政法人情報処理推進機構（IPA）,2017

Ⅱ．3．1 情報システムのエンジニアリング上の課題
前述のとおり国内における IT 関連人材は、その多くがベンダーに所属しているが、ユーザー企業からシス
テム開発を受託した「元請業者」が単独でシステム開発を実施するわけではなく、開発規模が大きくなればな
るほど、より多くの下請け業者に再委託してシステム開発を行う実態がある。なお下請け業者は 1 社にとどまらず、さらにその業者は下請け（二次請け～孫請け）に再委託するような「多重下請け構造」を成している。
システム開発は歴史が浅いため、エンジニアリング面において業者間で開発標準の共通性が確保されておらず、「とりあえず動くプログラムを納品する」という意識で開発作業が行われることが多い。本来であれば発注者であるユーザー企業が開発標準を策定して、開発標準を遵守することをベンダーの受注条件にすることも可能である。しかし、これまでシステム開発はベンダーに依存しきっているため、開発標準を策定できるユーザー企業は極めてまれである。
このような事情から、多くのシステム開発プロジェクトはエンジニアリング面があまり考慮されていないことが多い。

Ⅱ．3．2 課題の対処方法
情報システムを含むシステム開発や、自動車などのプロダクト開発において最近目まぐるしく進化しているのが「システムズエンジニアリング」である。特にロケットや人工衛星などの宇宙開発の分野ではシステムズエ
ンジニアリングが標準として適用されている。例えばロケットは、エンジン、制御システムなど様々なモジュールで構成されており、モジュールごとに発注業者が異なる場合が多い。しかし一つのロケットとして整合性をとるためには、統一的なエンジニアリングが存在しないと目的を達成できない。
情報システムの開発は宇宙開発のレベルではないものの、徐々に大規模化、複雑化しているとともに、社会インフラとなるようなミッションクリティカルなシステムは高い信頼性が求められる。また昨今はシステムが単独で稼働しているのではなく、他のシステムと連携して稼働するようなシステムが増加している。システム・オブ・システムズ（System of Systems）の考え方はその一形態であり、システムがより大規模化、複雑化している事例である。図表Ⅱ-3 は輸送システムのイメージを図示したものである。輸送システムとしては、「航空輸送システム」、「陸上輸送システム」、「海上輸送システム」があり、「航空輸送システム」をさらに細分化すると、「航空管制システム」や「燃料供給システム」などがあり、各システムが有機的に情報連携していることを示している。この図はあくまでもイメージであるが、一例を挙げると、日々使用しているパソコンやスマートフォンは定期的にシステムのアップデートを行い、タイムサーバーと連携して日付や時刻を調整している。
14

図表Ⅱ-3 System of Systems の事例

出典：「Systems Engineering Handbook 4th Edition」P.8 に記載の図を日本語化

以上のことから、企業の情報システムは大規模化、複雑化しており、適切なエンジニアリングを行わない限り、目的を達成することはできない。その一つの手法がシステムズエンジニアリングである。

Ⅱ．4 経営と情報システム
情報システムは経営にとって無くてはならない重要な経営資源になっている。かつては業務の効率化のために人手で行っていた作業のシステム化を図り生産性を向上させた。昨今の情報システムは顧客との接点を確保し、顧客のエンゲージメントを高めるためのツールになっている。
一方で経営者の目から見て、あるいは経営者の日々の行動として、情報システムや IT 部門が身近なものになっているであろうか。例えば、社長はシステム開発を IT 部門長やベンダーに任せきりになっていないだ
ろうか。今後はこれまでにも増して、情報システムの重要性は高まってくるであろう。経営者がより一層、情報システムに関与する場面が増加し、経営にとって重要な資源になってくるはずである。
システム開発の成功要因に関する調査と研究から、経営と情報システムの関わりのなかで特に経営者の役割について考察する。

Ⅱ．4．1 調査：The Standish Group の CHAOS Report
1985 年に設立された IT 調査・アドバイザリー会社である米国 The Standish Group は、1994 年以降毎年 IT プロジェクトについて調査している。その調査項目の一つに「IT プロジェクトの成功要因」があるが、上位 10 項目は図表Ⅱ-4 のとおりである。
「経営者のスポンサーシップ」がトップにあることからもシステム開発を成功させるには経営者のサポートが必須であることがわかる。

15

図表Ⅱ-4 システム開発プロジェクトの成功要因
項目
1

経営者のスポンサーシップ

2

感情的成熟度3

ユーザー参加4最適化

5

熟練した人的資源

6

標準アーキテクチャ

7

アジャイルプロセス8

控えめな実行9

プロジェクトマネジメントの専門知識

10

明確なビジネス目標
出典：Standish Group,2015

Ⅱ．4．2．研究
システム開発の成否に関する数多くの研究を調査した McLEOD らによる研究によると、「多くのソフトウェア開発の研究ではトップマネジメントのサポートやコミットメント、理解の有無がプロジェク
トの成否の重要な決定要因として報告されている」（McLEOD・他，2011）と記されている。
さらに Nasir らによる研究では、システム開発の成否に関する 43 の研究のうち 22 の研究で、「トップマネジメントのサポート」が挙げられている（Nasir・他，2011）
としており全体の過半数を占めている。
これらの研究からもシステム開発を成功させるためには、経営者のサポートが必須であることが理解できる。

Ⅱ．5 ビジネスのデジタル化
これまで述べてきたように、情報システムは経営に密接に関わりを持つとともに、最も重要な要素と言っても過言ではない。昨今は「デジタルビジネス」や「DX（デジタルトランスフォーメーション）」が経営には必須であり、多くの企業がその実践に苦労している。

Ⅱ．5．1 情報システムの高度化と DX との関係性
本プロジェクトでは、情報システムの高度化は広義の DX と同義と位置づけており、DX の位置づけのイメージを図表Ⅱ-5 に図示する。

16

図表Ⅱ-5 ビジネス価値拡大へ～デジタル化を活かす視点～「ビジネス革新」

デジタル化
Digital Transformation（新しい価値）

ビジネス創造IT
Digital Innovation

ビジネス拡充IT（価値向上）（価値の拡充）

価値「既存ビジネスの拡充」

新デジタル・ビジネス
Digital Innovation

・データ連携・エコシステム

基幹システムエンタープライズIT

ビジネス拡充IT System of Engagement（スコープ拡大）（SoE）

System of Record（SoR）（既存の価値）「革新的な生産性向上」＜ビジネス軸＞

社内／社員＜システム視点＞

既存顧客（硬直／複雑）

グローバル
潜在顧客
新規顧客
システムの柔軟性＜要求されること＞ （柔軟）スコープ・デジタル化（SoE）を活かすのは、データモデルとデータ連携
これまでの基幹システムを中心とする情報システムに対して、価値の拡充と新たな価値の創造を促す必要があり、それを「高度化」と定義する。高度化によってビジネスの領域が拡充するのである。
なお、これまで本プロジェクトでは、DX のための情報システムを議論の対象としたのではなく、基幹システ
ムとの連携を中心に議論してきた。

Ⅱ．5．2 DX のために重要な要素企業において DX を推進するために必要なことは、システム開発や IT 部門にのみ求められるものではな
く、企業全体がデジタルイノベーションを推進できる「体質」に改善されることである。内山（2019）によると、「意識」、「組織」、「制度」、「権限」及び「人材」の五つの企業内変革が求められる、としている。

17

図表Ⅱ-6 求められる五つの企業内改革
経営層や現場の危機感と変革

意識 に対する意識づけ
専門組織の設置や既存組織の組織 役割の再定義
変革を促進させる制度の採用
制度 と阻害する制度の緩和
予算、人事、組織連携などに権限 関する権限移譲
デジタルイノベーション推進
人材 人材の確保と育成
出典：内山悟志(2019)p.187 に記載の図より作成

Ⅱ．5．3 DX を推進する情報システムの作り方
デジタルビジネスは、従来からのビジネスのように時間をかけて長期スパンで成長させていくようなスピー
ド感ではなく、アジャイル開発のように短期間で成果物をアウトプットし、顧客に寄り添って改善していくようなプロセスで進めていく。したがってスモールスタートであり、とりあえず動くプログラムを用意して、ビジネスの状況をウォッチしながら大きくしていくような開発手法である。
そのため従来のように最大アクセス数を想定してシステムのサイジングを行うのではなく、状況に応じて臨機応変に対応できるような柔軟性が求められる。そのためにはオンプレミスのシステムを用意するのではなく、クラウドコンピューティングが前提となる。
このようなビジネスのスピード感に合わせるためには、開発のスピードも上げる必要がある。またビジネスの変化が激しいため、情報システムは陳腐化して長く使えるわけではない。そのためには情報システムは「消耗品」の発想をもつ必要があるのかもしれない。このようなビジネス環境においては、従来のような長期的なシステム投資計画を策定することが困難なため、システム投資資金をコントロールすることが難しい。したがって個別のシステム投資を極力落とさないと、経営が立ち行かなくなる。
またこのような状況においては、低コスト、短期間で新たなサービスを提供するための IT 環境を構築する必要性が高まってくる。例えば、競争優位性の高い事業領域はオンプレミスのシステムを保有するものの、それ以外の事業領域はスクラッチ開発をやめ、既存のパッケージソフトやネットワークサービス、決済サービスなどを適切に組み合わせてビジネスを成立させるようなシステム開発手法を取り入れることも検討するとよい。

Ⅱ．6 情報システムの進化プロセス
情報システムの役割として、次の二つが挙げられる。すなわち、①業績向上：日常のオペレーションを効率化する②イノベーション：新たなビジネスモデルを実現するの二つである。①は主に前述の SoR が、②は主に前述の SoE が該当する。①から②への進化プロセスを検討する。
18

Ⅱ．6．1 アーキテクチャー要件を満たす
情報システムを開発する際に考慮すべき事項にアーキテクチャーがある。その策定における要件として次の 5 項目が挙げられる。
①構造化され、可視化されている②データとプロセスが分離されている③データはキー構造が明確になっている④プロセスとの関係が CRUD 図で明示されている⑤プロセスを担う組織が明確になっている
情報システムを正しく開発するには、この要件を満たしている必要がある。

Ⅱ．6．2 パフォーマンス測定と意思決定あるビジネスモデルが維持、継続されている中では、前述のアーキテクチャー要件を満たして情報システムが稼働している必要がある。その際にはパフォーマンスが正しく測定されなければならない。ミドルマネジメン
ト（部課長級）はそこで測定されたパフォーマンス情報をもとにしてさまざまな意思決定を行うからである。

Ⅱ．6．3 創造的破壊へのプロセス
さらにトップマネジメント（経営層）はビジネスそのものを評価して、創造的破壊を行う役割を担う。ここで言う「創造的破壊」とは、新規事業に進出あるいは新たなビジネスモデルに移行することを意味する。トップマ
ネジメントはその判断を通して、新たな情報システムを構想し、経営戦略に沿った IT 戦略を策定し展開する。

Ⅱ．7 経営目標・戦略を実現する情報システムのあるべき姿
Ⅱ章の最後に、経営目標・戦略を実現する情報システムのあるべき姿を、「情報システム」、「組織」及び「人」に着目して描く。ここでは概要にとどめ、Ⅲ章以降で詳細を述べる。

Ⅱ．7．1 情報システム
基本的な方針として、企業などの組織は「システム資産を極力保有しない」という経営目標を掲げるとともに、その考え方に準拠した戦略を策定すべきである。そのためのシステムインフラは、すでにクラウドコンピュ
ーティングなどで実現可能である。またソフトウェアについても、自社のみで利用可能なアプリケーションをス
クラッチ開発するのではなく、ERP などのパッケージソフトを極力ノンカスタマイズで導入する。あるいはクラウドベンダー等から提供されているサービスやオープンソースのシステムを機能ごとに適宜適切に採用して、対象業務やサービスに求められるシステムを実装する。
開発手法はこれまでのウォーターフォール型ではなく、アジャイル型などでイタレーショナルに繰り返して開発する手法を採用する。ここで重要なポイントは、「データ重視」でシステムを開発することである。これまでの国内のシステム開発は業務効率化を目的とするものが多かったため、業務プロセスを重視して開発されてき19た。その結果、データを切り口にしてシステムを分析すると、データの流れが分断されたり、データの流れを把握できなかったりするシステムになっていった。これではデジタルビジネスの根幹となる「データ」を有効活用することができない。したがって、データ重視でシステムを設計する手法に切り替えることが急務である。

Ⅱ．7．2 組織
企業へのシステム導入のこれまでの歴史を振り返ってみると、ユーザー企業はシステム開発をベンダーに委託するのが常識になってしまった。その結果、歴史のある大企業においては、本体にシステム部署があるものの、実態的には情報子会社やベンダーにシステム開発が委託され、極端な場合には「丸投げ」になるケースも多い。また、本体のシステム部署や情報子会社の社員の役割は、システム開発や保守・運用を「管理する」
ことが主な業務になり、ベンダーの社員やその下請け会社（パートナー）が実質的に業務を行うことになった。
デジタルビジネス、あるいはデジタルトランスフォーメーションの文脈で先進的な企業の取組みとして昨今特徴的なのは、システムの「内製化」である。つまり、従来は外注していたシステム関連業務を自社内で実施できるように組織・体制を再構築している。具体的には事業部門（ユーザー部門）にシステムメンバーを配置
し、ユーザーと一緒になって業務の効率化や改善、あるいはイノベーション、新規ビジネスの創造を行っている。その結果として、ビジネス展開のスピードが加速するとともに、システム化のナレッジを社内に保有し醸成することができている。これは一朝一夕に実現できるものではなく、変革意識を強くもったイノベーションリー
ダーのもとで、紆余曲折があっても断念せず継続した結果である。

Ⅱ．7．3 人ユーザー企業ではこれまで本業のビジネス領域における業務知識が重要であり、システムの知識やスキル
は IT 部門の専門領域とされ、ビジネスを推進する上では軽視されてきた。しかし昨今は「デジタルビジネス」といわれるように、ビジネスとシステムとが密接に関係しており切っても切れない関係である。したがって、ビ
ジネス部門においても一定程度のシステム知識が必要とされるようになった。
一方でシステム開発も大きく変わってきた。従来からシステム開発はプログラミングのような専門知識が必要であったが、最近ではソースコードをコーディングすることなく、簡単な設定のみでシステムを構築することも可能になった。つまりシステム開発はかつてほど特別な専門知識がなくても実施できるようになり、極めてユーザーフレンドリーに変わってきたのである。
これらの変化は、人材育成にも影響する。システム要員に対する人材育成は、かつてはシステムに関する専門知識の習得が中心であったが、これからは自社や自部門のビジネスに対してどのようにシステムを適応させるのか、あるいはどのようにイノベーションを想起するのかなどが重要になってくる。またシステム開発プ
ロジェクトは、かつてはユーザー部門対 IT 部門の構図で体制が構築されてきたが、アジャイル開発の一形態である「スクラム」に代表されるようなワンチームで体制が構築されてきていることから、コミュニケーション力が重要になってきている。このように人材育成を含めて「人」に関わる重要性が顕著になってきた。

20

＜参考文献＞
INCOSE (2015) Systems Engineering Handbook 4th Edition（西村秀和監訳（2019）『システムズエンジニアリングハンドブック第 4 版』慶應義塾大学出版会）
Moore, G.(2011) Systems of Engagement and The Future of Enterprise IT
A Sea Change in Enterprise IT, AIIM
IPA（2017）『IT 人材白書 2017』 独立行政法人情報処理推進機構（IPA）
The Standish Group (2015) CHAOS Report
McLEOD, LAURIE and MacDONELL, STEPHEN G.（2011）「Factors that Affect Software
Systems Development Project Outcomes: A Survey of Research」, 『ACM Computing
Surveys』43(4), Article24, ACM．
Nasir, Mohd Hairul Nizam and Sahibuddin, Shamsul（2011）「Critical success factors forsoftware projects」,『Scientific Research and Essays』 6 (10), pp.2174-2186．Academic
Journals.
内山悟志（2019）『デジタル時代のイノベーション戦略』技術評論社

21

Ⅲ章 システム高度化へ向けた問題とその背景
三谷 慶一郎
本章のサマリー近年、日本企業の国際競争力は低下傾向にある。この理由の一つに、情報システムの活用の仕方が不十分であることが考えられる。具体的には以下のような四つの問題がある。
経営層において、データの重要性が十分理解されていないこと。
企業の IT 投資において「攻めの IT」を実現、推進するための取組みが不十分であること。
システム開発や維持管理についての標準化が進んでいないこと。
情報システムに柔軟性がなく、ビジネスの変化に対応できないこと。

近年、日本企業の国際競争力が急激に低下している。国際通貨基金（IMD）の世界競争力センターでは、30年以上前から、毎年国ごとの競争力を比較する「世界競争力ランキング」を発表している。これを見ると 1990
年代前半には日本は連続して 1 位になっており、まさに Japan as No.1 の時代だったことがわかる。一方、2000 年代以降かなり評価が悪くなっており、2021 年版では世界主要国 64 か国中 31 位にまで落ち込んでいる。詳細内容をみると特に、ビジネス効率性に関する評価項目が際立って低いことが目につく。その内訳をみると、企業の俊敏性等、企業意思決定に関する指標を意味する「経営プラクティス」、あるいは「生産性・効率性」「姿勢・価値観」といった項目が軒並みかなり低く評価されている。
図表Ⅲ-1 IMD 世界競争力ランキングにおける日本の順位
1

1

2

3

4

4

16

17
20

21

21
23

24

17
21

22

23

24

25

24

27

27

26

27

27

26 26

25
30

31

2021年

2020年

2019年

2018年

2017年

2016年

2015年

2014年

2013年

2012年

2011年

2010年

2009年

2008年

2007年

2006年

2005年

2004年

2003年

2002年

2001年

2000年

1999年

1998年

1997年

1996年

1995年

1994年

1993年

1992年

1991年

34

出典：IMD World Competitiveness Centre

これほどの凋落が生じた理由は恐らく複数の要素が絡むものであろう。ただしその中に、この間、競争力を得るために世界中のあらゆる企業が積極的に導入してきた情報システムの活用が、諸外国に比べ日本では不十22分だったことが含まれていると十分に考えられる。ただし、我々の肌感覚からみても 1990 年代と 2000 年代以降を比較して、日本だけが新しい情報技術の導入を怠ってきたわけではないし、IT 部門も精一杯頑張って情報システムの活用を進めてきたはずだ。だとすると、考えられるのは、努力の方向そのものに誤りがあったということだ。高度成長期を経て世界有数の競争力を誇った時代の情報システムの使い方を、我々を取り巻く環境が変化しているにも関わらず、「昔の通りに、今でも変わらず行い続けてきてしまった」こと自体が原因ではないだ
ろうか。
以上のような現状認識を前提として、本章では、国内企業における情報システムおよびそれをマネジメントしている IT 部門に関して我々が現状感じている基本的な問題意識について提示する。この問題意識が、今回我々が集まり、このプロジェクトを組成し、長期にわたって議論を繰り返してきた理由である。言うまでもなく、いずれの問題も、長年各企業の中に存在してきたもので、根が深く容易には解決できるものではないことは十分自覚している。ただ、経済産業省の DX レポートにもある通り、現状のまま日本企業の情報システムへの取組み状況を放置しておくことは、近い将来社会全体として莫大な損失の発生につながる可能性が高い。本格的なデジタ
ル時代の実現に向けて、今の段階でこの問題を総括しておくことは有意義なことだろう。

Ⅲ．1 「データの重要性が経営に十分理解されていない」
一つ目の問題は、経営層において、データの重要性が十分に理解されていないことである。
現代の企業経営においては、データがとても重要な資源に位置付けられていることは改めて述べるまでもない。ビッグデータというキーワードが流行り始めていた 2011 年に刊行されたマッキンゼーのレポートでは、データを活用することによって以下のような効用が生まれるということが述べられている。


経営やビジネスにおける実験を容易に繰り返すことができる

細かい顧客セグメンテーションが可能になり、ニーズに沿ったカスタマイゼーションが容易になる



洗練された分析、自動化されたアルゴリズムによって、人の意思決定の質的向上をサポートできる

新しい製品・サービス、ビジネスモデルを創出するために活用できる

同レポートによれば、データを活用することにより、米国のヘルスケア産業は、年間 3000 憶ドルの価値を創出
でき、小売業の営業利益は 60％改善するという（Big data: The next frontier for innovation,competition and productivity を元に加筆）。
映画「マネーボール」を例に出すまでもなく、意思決定においてデータを活用することはとても重要である。イ
ェール大学の経済学者イアン・エアーズは、著書の中で、「我々は今、馬と蒸気機関の競争のような歴史的瞬間にいる。直感や経験に基づく専門技能がデータ分析に次々に負けているのだ」と述べている。いわゆる GAFA等のデータを独占的に保有している企業群に対しては、その強大さゆえに、世界中からこれらの企業の力を規制でいかに封じるかという議論さえ行われている。間違いなくデータは近代経営の武器になるのだ。
しかし、日本は諸外国と比較して驚くほどデータを活用する意識が低い。GE の実施している調査によれば、「イノベーションのためにデータ活用を行う」ことに対して「同意する」と回答した企業の割合は、韓国、サウジアラ
ビア、シンガポールなどが上位に並ぶ中、日本はずば抜けて低い評価を示している。昔から言われてきた「KKD（経験・勘・度胸）」によるマネジメントがまだまだ強い力を持っているのだ。そしてその背景にはやはり過去の成功体験を忘れられないことがあるのだろう。
23

図表Ⅲ-2 イノベーションのためにデータ活用を行っている企業

出典：GE グローバルイノベーションバロメータ

日本企業の経営において、データが重要視されていない理由の一つとして「供給者起点、技術起点の考え方が強すぎる」ということをあげたい。
企業が対峙する消費者が今現在何を欲しているのか、それはどのように変化しているのかを理解するところ
からスタートする「消費者起点」あるいは「ニーズ起点」の考え方が、先進国に比べると日本では歴史的に弱いよ
うに見える。それよりも、「よいモノを高品質でできるだけ安く作ること」という供給者起点の考え方が優先されている。「よいモノを作れば、お客様は必ず買ってくれる」ということを宗教のように信じているとも言えるだろう。このような考え方に基づけば、モノをより効率的につくることが企業の最大のミッションになるのは自明であり、消費者を理解することは後回しになる。マーケティングデータを収集・分析し、消費者動向に基づく事業戦略を立てるというモチベーションは残念ながらあまり生まれない。消費者の行動や需要変動を把握するよりも、工場の稼働率を維持し、製品の在庫を切らせてしまうことがないように神経を使うようになる。リーマンショックが起こった時、グローバルに展開している日本の大手製造業はかなり大きな痛手を被った。その理由として、マーケットの環境が変化し需要が落ちてきていることを認知するのにかなりの時間が必要だったからだと、ある経営者から聞いたことがある。このあたりにデータを重視しない経営が行われている背景があるように思える。また、よりよい製品をつくるのが最優先になるということは、モノづくりの現場がより強くなることにつながる。相対的にビジネス全体をマネジメントする機能や組織の力が弱くなるのもうなずける。
市場が拡大している時代においては、消費者は行列を組んでモノを買うのを待っている状態にある。このときに「よいモノを効率的に作る」ことを第一に考えてビジネスを行うのはとても自然なことだろう。しかし、今は、市場は成熟しきっており、顧客ニーズも多様化している。加えて少なくとも国内においては少子高齢化によって市場そのものは確実に縮小していく。このような状況を見据えれば、一日も早く、日本企業の経営層がデータを前提とするマネジメントに取り組むことが望まれる。

24

Ⅲ．2 「攻めの IT への取組みが不十分」
企業内における IT 投資において「攻めの IT」を実現、推進するための取組みが不十分であることも大きな問題である。「攻めの IT」とは、「従来の社内業務の効率化・利便性の向上を目的とした IT 投資にとどまることな
く、中長期的な企業価値の向上や競争力の強化に結びつく」（「攻めの IT 経営銘柄」より引用）投資であり、ITを活用することによって、新しいサービス（いわゆる「デジタルビジネス」）などを生み出すことである。
日本企業は以前から IT 予算の多くを現行システムの維持管理に費やしている。JUAS の「企業 IT 動向調査」によれば、予算に占めるビジネス価値創造のための予算（バリューアップ予算）は、22～23％程度とあまり多くなく、近年ほとんど変化がないようだ。さらに言えば、現行システムの維持管理（ラン・ザ・ビジネス予算）の割
合が 90％以上を示す、ほとんど維持管理だけを行っているような企業が全体の 4 割弱をも占めている。
図表Ⅲ-3 IT 予算におけるラン・ザ・ビジネス予算とバリューアップ予算

出典：企業 IT 動向調査報告書 2022 に加筆（JUAS）

図表Ⅲ-4 「現行ビジネスの維持・運営（ラン・ザ・ビジネス）」予算の割合・現状

出典：企業 IT 動向調査報告書 2022（JUAS）

25

九州大学の篠崎先生の研究によれば、日本と米国において IT 投資による生産性向上効果を比較すると時代毎に明確な違いがあるという。1980 年代、つまり企業が本格的に情報システムを導入しはじめた時代においては、米国では IT 投資に対してあまり生産性向上効果が表れていなかった（ソローズ・パラドクスという）。一方、同時期の日本では、かなり大きな効果が表れている。これは我々の想像ではあるが、日本企業は当時から現場にいる人材の総合的な能力が米国に比べて高かったのではないだろうか。この頃の情報システムは省力化・自動化を目的としており、日本の現場はそれを上手に活用していたということだ。
図表Ⅲ-5 米国と日本における時代毎の IT 投資と効果（％）

1980年代2000年代0.4

0.8

労働生産性（ＡＬＰ）

1.5

2.6

全要素生産性（ＴＦＰ）

0.4

1.0

1980年代2000年代0.4

0.4

労働生産性（ＡＬＰ）

3.7

1.5

全要素生産性（ＴＦＰ）

1.6

0.4

米国
投資 ＩＴ資本深化効果

日本
投資 ＩＴ資本深化効果

出典：いずれも「情報技術と経済成長」（篠崎彰彦）

しかし、2000 年代以降に入りこの状況が一変する。この時代になると、日本企業の IT 投資に対する生産性向上効果がほとんど表れなくなっている。米国はというと、ちょうどニューエコノミーが騒がれていた時代に被ってくることもあって、投資は活性化し、それに対してかなり大きな効果が創出されている。
年代の違いはあれ、情報技術そのものが抜本的に変わったわけではない。だとすると、2000 年代以降、新しい IT 活用方法が生まれたと考えるべきだろう。これこそが先に述べた「攻めの IT」なのである。IT を活用して新たなサービスを創造し、ビジネスモデルを変革していく、この「攻めの IT」に米国企業は競うように取組みだし、大きな成果を創出している。他方、日本においては、今まで通りの IT 活用を延々と続けている。当然ながら企業における省力化・効率化の効用は既に刈り取られてしまっており、それ以上の効果は容易には出ない。これが考えられるストーリーではないだろうか。
電子情報技術産業協会の調査結果を見る限り、どうやらこの仮説は当たっているように見える。米国においては「IT による製品／サービス開発強化」や「IT による顧客行動／市場の分析強化」といった攻めの IT 投資が活発である反面、日本企業においては、「IT による業務効率化／コスト削減」を中心とした守りの IT 投資が中心になっている。

26

図表Ⅲ-6 IT 投資の用途に関する日米比較

出典：一般社団法人電子情報技術産業協会「日米企業の DX に関する調査」（2021））

先にも述べた通り、日本が急成長してきたのは、より低コストで高品質のモノづくりを行うというビジネスモデ
ルによってである。この流れに沿えば、企業経営において重視されるのは「効率性」一辺倒ということになる。いかに現在の業務を効率よく行い、よいモノを作っていくかということのみにフォーカスされていたわけだ。そして、業務を省力化・自動化するための道具である情報システムを日本企業はうまく使ったということだ。
そして、日本企業はこの大きな成功体験を忘れ去ることができておらず、効率化を延々と追求し続けている。
今までと異なる「攻めの IT」に何とかして取組み始めなければならない。

Ⅲ．3 「システム開発・維持管理における標準化が進んでいない」
システムの開発や維持管理のための、マネジメントの仕方、タスク内容、あるいは関連するドキュメント記述などについての標準化が十分に進んでいないことも問題である。
そもそも、標準化とは「実在の問題または起こる可能性がある問題に関して、与えられた状況において最適な秩序を得ることを目的として、共通に、かつ、繰り返して使用するための記述事項を確立する活動」と日本工業規格において定義されている。標準化の目的には、一般に以下のようなものがある。
製品の互換性・インターフェースの整合性確保
生産効率の向上
適切な品質の確保
正確な情報伝達、相互理解の促進
情報システムにおいても当然ながら必要なことであり、日本では、企業単位あるいは産業全体として過去に何27

度も推進活動が行われてきている。例えば EA（エンタープライズアーキテクチャー）は、1987 年のザックマンモ
デルをベースにしながら米国などにおいて発展してきたシステムを可視化するためのフレームワークである。
2002 年頃から経済産業省を中心として強力に推進されており、政府機関や民間企業においていくつか検討はなされてきたが、残念ながら産業全体への浸透には程遠い状況である。
その目的や意義は理解されながら、標準化がなぜ浸透しなかったのか、いくつか理由があるように思える。まず、日本企業において、社内にあるナレッジやノウハウを形式知化し、標準化しようとするモチベーションが諸外国に比べてそもそも弱いことがあげられる。これは日本社会において、企業間をまたがる人材流動がとても少ないためだろう。学校卒業とともに新卒として一律に入社し、年功序列型賃金をベースに終身雇用を行うという日
本社会の特徴が、就職というより生涯一つの会社に所属するという「就社」に近い状況を生んでいる。その結果、「社員はずっと社内にいる」ことが前提となるので、わざわざ社員の持つナレッジを整理して標準化する必要がなくなる（何かあったらその人に聞けば全部わかるのだから）。同時に、企業を跨った人材流動が少なく、多くの人材がずっと同じ企業にいるということは、社会全体としての標準化が行われていなくても大きな問題にはならないことにつながる（逆に、標準化が行われていないから人材流動が起こりにくいとも言えるかもしれない）。
残念ながら高度成長期に維持してきたこの環境は、これからは大きく変わっていくだろう。団塊の世代が一斉退職する 2007 年問題からもはるかに時間は経過してしまい、昔からある手作りで情報システムを開発した人たちはもうすでに、社内には残っていない。これが、情報システムがブラックボックス化するいわゆる「レガシーシ
ステム化問題」が起こっている要因にもなっている。
また、日本企業においては一般的に現場が強いことも標準化が進まない要因だと考えられる。各現場が効率化を追求し、TQC 活動などを経て、より独自に業務プロセスを進化させているという歴史を持っており、結果として、それぞれの現場ごとに（例えば製造業であれば工場ごとに）特有の仕事の仕方が存在している。企業全体として最適化・標準化を行おうとしても、自らの業務プロセスに自信を持つ、強い現場を納得させるのは容易ではない。
また、現場ごとに業務プロセスが異なることは、バラバラの情報システムが生まれることに直結する。現場ごとに異なるシステムが存在し、それを作った人間はもう社内にはいない。かなり末期的な状況だと言っていい。
ただし、社員をできる限り社内に長く所属してもらう状況をつくること、あるいはモノづくりの現場を強い存在にしていくことはいずれも、確立されたビジネスをより効率化していくという目的に対しては役に立っているのも事実である。組織の求心力を上げ、いつものメンバーの「あうん」の呼吸で業務を回していく状態をつくり、強力な現場の力によってカイゼン活動を続けていくこと。それは間違いなく一時期の日本の競争力を支えていたことでもある。ここに、この問題の根の深さがある。
デジタルトランスフォーメーションの方向性の一つとして、ドイツが提唱している「Industry 4.0」の本質は、「国全体を一つの賢い工場」にすることにある。人材流動が盛んで、職業体系や必要なスキルの標準化、業務プ
ロセスの標準化が進んでいるドイツだからこそ目指せる魅力的なビジョンだといえるが、日本がこの域に達するにはまだまだ時間がかかるだろう。

Ⅲ．4 「情報システムに柔軟性がない」
最後に述べたいのは、IT 部門の方々が口々に言われる、国内企業の情報システムには柔軟性がない硬直的28

なものが多いということである。時代とともに、企業を取り巻く経営環境が変化し、それに対応していく形でビジネスのスタイルも変化し続けている。しかし、それをサポートするはずの情報システムが硬直的であり変化に追いついていけないということだ。日本企業では、現場固有の業務プロセスが、情報システムにそのまま組み込まれてしまっているために、多くのシステムが変化させにくい構造になっていることはよく指摘される。さらにこれからの将来を考えれば、環境変化はますます激しくなっていくだろうし、情報システムにはより強く柔軟性が求められるはずだ。
我々は、この「情報システムに柔軟性がない」という問題の背景には、我々も含め日本企業の多くの人々が、情報システムを硬直的な「モノ（製造物）」と認識しすぎているからではないかと考えている。モノづくり大国の日
本では、情報システムもモノとしてつくり、モノとして取り扱っているということだ。例えば開発工程（そもそも製造工程と呼ぶことすらある）で最もよく使われるのはウォーターフォール型開発というプロセスであるが、これは、要求される機能を整理し性能を規定するところからはじまり、工程が進む中で品質を作りこんでいくというまさにモノづくりのアプローチに他ならない。開発が完了したシステムは完成品とみなされ何よりも品質が重視される。情報システムに関する信頼性へのこだわりは、日本は世界でトップクラスだろう。バグを不具合と呼びこれが発生することを異常なまでに避けたがる。これもモノづくりの特徴を引きずっていると言えるだろう。ちなみに、品質への過剰なこだわりが、情報システムに関する大きなコスト増につながっていることもかなり重要な問題である。
さらに、日本のユーザー企業とベンダー企業の関係もこれに関連する。つまり、「情報システムというモノをユーザー企業はベンダー企業に作ってもらう」「ベンダー企業はユーザー企業から要求があったシステムを作ることを請け負う」というまさにモノづくりの構図である。よく問題視される「ユーザーがシステムを丸投げする（開発に関与しない）」というのもこの構図から生まれてくると考えるとわかりやすい。このような状況が生まれる理由には、IT エンジニアの多くがベンダー企業側に所属しており、ユーザー企業には少ないという日本固有の環境があげられる。先に述べたウォーターフォール型開発は、ベンダー企業とユーザー企業とのシステムをモノとして作るときの責任分解点を明確にする上ではとても役に立つ。さらに、瑕疵担保責任や、減価償却のしくみについても、情報システムはモノとして扱われている。モノとして扱われること、完成品となった後の変化を想定していないこと、これが作り上げられた情報システムに柔軟性がなくなることに結び付くのだ。
情報システムがモノとして扱われていることのもう一つの弊害が、段階的な大規模開発にある。銀行などではよく見られるが、「第〇次オンライン開発」と言われるように、数年おきに大きなシステム開発プロジェクトが行われる。これは開発をベンダー企業に投げることをより効率的にするために、何年か追加仕様を貯めておいて一気にそれに対応していくということから生まれたものだろう。このやり方ではビジネスの変化へのシステム側の対応にはどうしても時間がかかってしまう。もう一つ、ある時期にベンダー企業側に大規模なマンパワーが必要になってしまうことも社会全体から見ればあまり合理的ではない。

29

Ⅳ章 日本らしさとは～日本の情報システムの有るべき姿
森 弘之
本章のサマリー

日本「らしさ」とは、器用で多能であるが、危機感がないとその能力を過剰品質に発揮してしまう。また、明文化されたロジカルな状態よりも、「和を以て貴しとなす」を好む傾向がある。



このような「らしさ」で世界と戦うには、以下の戦略が必要である。
・DX に代表されるデジタル・ディスラプションが現実的な脅威であることを認識する。
・デジタルという武器の実態は「データ」であることを認識する。
・企業の本質をデータでデザインし、そのデータを発生・変更・消去するプロセスは、器用で多能な能力を十分に発揮し、好き勝手に作る。



上記活動は今までの POA 的な発想ではなく、DOA 的発想が必要となる。過去の成功体験では戦えないことを認識し、最新技術を日本「らしく」自身の血肉にする必要がある。

我々はこれまで、世界の真似をしていては世界に勝てない、日本「らしさ」を武器にしなければ勝てないことを合意事項とし、さまざまな角度から議論を重ねてきた。また、このような観点に関する書籍を調査すると、日本が世界で優位に立った時は日本「らしさ」を武器にしていた時であることも分かってきた。
本章では、日本「らしさ」を定義し、それを活かした情報システムの有るべき姿を考察する。

Ⅳ．1 日本の特性
日本は、日本人は、他の国と比較してどのような特性を持つのだろうか。ここでは、本プロジェクトで議論してきた内容や書籍などから、日本の特性を探ってみる。いわゆる出羽守（でわのかみ）のように、海外と比較し日本の遅れのみを指摘するのではなく、良いところも悪いところも挙げることとする。

Ⅳ．1．1 就職ではなく就社という職業観
米国などとは異なり、日本には独特の職業観がある。仕事や業務に対し、日本の場合は「天職」などの言葉に代表されるように、天から与えられた神聖な勤め、という意識がある。海外では仕事は自己実現の手段として捉えられているので、スキルを磨いて転職するのが主流である。雇用形態も日本の場合は終身雇用が前提なので、人材が固定的であるがゆえに業務に対するノウハウが暗黙知であっても成立する。

30

図表Ⅳ-1 勤続年数における日米比較

出典：労働政策研究・研究機構 国際労働比較 2018

ただし、以下の点に注意が必要である。
日本では、終身雇用制を前提とした、文書化しない、暗黙知化させたままでも大丈夫、という文化がある。
だがそれも崩れつつある。そもそも終身雇用制は、日本古来の文化でも、日本人固有の特性でもない。原型をたどっても、第二次世界大戦以前には存在しなかった歴史の浅いビジネス慣行だ。ドキュメンテーション・
コストより人件費が安い。紙に書かせるより一生雇っておくほうが安い。という計算が成り立った、一時代の慣行である。あるいは、Japan as No.1 と謳われて以来、ホワイトカラーの生産性が凋落の一途を辿ってい
るのは、この低付加価値の「書かないビジネス慣行」に自らを縛り付けているからかもしれない。これも後述
する成功体験から抜けられない一例である。
ムンバイや深センはどうしているのか。IT を手にして以降に先進国の仲間入りを目指したインドや中国の人達は、そんな「低生産性のビジネス・モデル」に興味はない。彼らはどんどん書き残し、自らの責を果たすと軽々とジョブホッピングを成し遂げる。これが彼らのビジネス文化となり、社会全体も次々に新たなビジネス・モデルにチャレンジできているのだと解釈できないだろうか。
全てを捨てて、もう一度彼らの列の後ろに並び直すことを勧めているのではない。発想の切り替えで、新たなチャンスにチャレンジできる環境に移行することは可能なのである。我々は、日本らしく絞り込んだ概念データ領域 1に集中して確実に見える化をすることで、遠回りをすることなく次に駒を進めることができる。

Ⅳ．1．2 几帳面で器用日本人は、ロングタームで計画を立てるのは苦手だが、目の前の作業に関しては実直に、主体的に、時には目的を忘れ、器用にこなすことができる。過剰品質と言われるのものこの国民性があるからである。欧米系のトップダウン企業において従業員は指示によりトップの意向を実現する者だが、日本の企業においての従
業員はトップの意向よりも自分が直面している（と感じている）課題を自分なりの方法で解決する者であるこ
とが多い。

1

この領域が、「データ×意味」の領域である。具体的には、概念 ER 図であり、エンティティ説明書であり、データ項目説明書である。ここにビジネス・ルールが書きこまれ、データ・カタログに反映される。
31

Ⅳ．1．3 器用であるが故に多能化ができる
欧米では「マルチタスク」は危険である。多彩なそれぞれの能力についてペイメントが発生してしまう。単能工で単価は安いが福祉は厚くする、というモデルが成り立たなくなる。管理職は多能工であるが、単価が高い。
日本のおもてなし精神を活かそうとすると、シングルタスクの寄せ集めではコストが高すぎる。多能化をう
まく活かすことで初めておもてなし精神が成り立つ。
しかし、なんとなくこの人は「こんなことができるよ」ではなく、ロールはきちんと定義してあげなければならない。それで初めて良い意味での多能工化が成立する。「オールマイティ」ではなく「多能」なのである。
この「多能」であることを示唆するものとして、経済複雑性指標が挙げられる。経済複雑性指標は日本が 1位。輸出品目が多様化していることと、高度なものが多いからである。2 位がスイスで 3 位がドイツ。工芸品が有名な国々である。
経済複雑性指標（Economic Complexity Index 以下 ECI）は、国家全体など巨大な経済システムの生産力の特徴を測る全体的な指標である2。
図表Ⅳ-2 経済複雑性指標

順位

国

ECI値

1 ⽇本

2.25

2 スイス

2.10

3 ドイツ

2.05

4 スウェーデン

1.89

5 アメリカ

1.80

6 韓国

1.74

7 フィンランド

1.74

8 シンガポール

1.73

9 チェコ

1.70

10 オーストリア

1.65

出典： Observatory of Economic Complexity, MIT 2014

Ⅳ．1．4 IT システムの開発方式は基本手作り
IT プロジェクトの主体は、米国では利用する企業自身であるが、日本では主に IT ベンダーとなっている。
また、開発方式も米国では ERP やパッケージを活用するのに対して、日本はスクラッチ開発、ERP を使ったとしてもアドオンを多用し、最終的にはスクラッチ開発と同様ものとなる場合が多い。これは、業務効率化のため、手作業をコンピューターに代替させてきたからである。手作業の自動化が目的なので、パッケージで2

ECI は MIT メディアラボのセザー・ヒダルゴとハーバード大学ケネディスクールのリカルド・ハウスマンにより提唱された。ECI は国家の多様度と輸出品目の遍在性の 2 点を考慮に入れているため、その国家がいかに多様であるか、またその国家の産業がいかに洗練されているかの両方を測定できる。
ある国家の ECI が「高い」ということは、その国家の輸出品目が多岐にわたっており、かつそれらが遍在性の低い（例えばロボットアームなどは開発できる国が限られており遍在性が低いといえる）品目であり、またそれらが多様性の高い国家で生産されている、と解釈される。
32

代替できるわけはなく、細かなチューニングには技術力が必要なため、業務にも IT 技術にも精通した専門業種が必要となった。

Ⅳ．1．5 危機に強い
日本は、危機を感じ取った時に冷静な戦略を立てることができる。それはロジカルに計画立てられたものではなく、抽象的なアイデンティティに支えられたものである [ジャレド・ダイアモンド, 2019]。
抽象的なアイデンティティとは、幕末から明治初期においては、西洋列強から押し付けられた不平等条約から脱却すること。そのために漢字や天皇制などの自国文明を残しつつも西洋文明を積極的に取り入れた。
このようなことについてはドラッガーも「日本の近代社会の成立と経済活動の発展根底には、日本の伝統における知覚の能力がある。これによって日本は、外国である西洋の制度や製品の本質と形態を把握し、それらを再構成することができた [P.F.ドラッガー, 1994]」と記している。
2011 年の東日本大震災時の対応が世界から賞賛されたことや、2020 年以降の新型コロナウィルスによる感染者数が少なく済んでいることなどからも、危機に強い国民であることが分かる。
また高度成長期においては、敗戦からの復興と世界一になることをアイデンティティとし、奇跡的回復を実現した。ここでも自国の良さを残しつつ、他国の文化を積極的に取り入れている。業務のコンピューター化もこの時期に相当している。
コンピューターとも危機とも直接の関係はないが、海外の知見と自国の知見の組み合わせの代表例として
漢字、ひらがな、カタカナから混成される文字を発明したこと、宗教の扱いなどが挙げられる。以下に、宗教に関しての考察を述べる。
キリスト教、イスラム教、仏教など一神教を取り入れる国に対して、日本は多神教と言われることが多い。しかし、日本人は多神教というよりも多宗教を受け入れていると考えた方が正しい。ライフイベントで考えると、誕生して 1 カ月が経つとお宮参りをし、数年経過すると七五三を祝うが、これらは神社で行う。結婚式は本人もしくは親族に神前か教会かの選択肢がある。そして死亡すると仏教の葬式を執り行い仏壇の中に入る。
年間のイベントでは、お盆は仏教、クリスマスはキリスト教で、クリスマスが終わると 1 週間も経たず神社に初詣に出かける。日本における多神教は、さまざまな神様がいるだけでなく、他の宗教が崇めるものも取り込んでいるのである。無宗教と言いたくもなるが、時々に応じて神頼みはしている（クリスマスにキリストのミサを行っているわけではないが）。この国民性は、ロジカルな発想ではなく、ロングスパンで計画を立てるわけでもなく、目の前の事柄に対して、その場その場を乗り切る DNA に依存している。
この DNA の正体は、聖徳太子が定めたと言われる十七条憲法の第 1 条「和を以て貴しとなす」に通じるものがあると考えられるのではないだろうか。「和を以て貴しとなす」は、「仲良く争わず協調することは何よりも尊いことである」「何事も話し合って決めなさい」という意味である。それぞれの良さを認識した上で協議して物事を決めるという考え方は、漢字、ひらがな、カタカナから混成される文字にも表れるし、前述した明治初期の言動や第二次世界大戦後の復興にもつながる。

Ⅳ．1．6 成功体験から脱却できない
しかし危機感を感じ取れない時は、過去の成功体験から離れられない。成功のためには試行錯誤が必要
33

なこと、他から学ばなければいけないことを忘れてしまう。
明治維新では徹底して他国から学び、それが日清戦争、日露戦争に勝利した大きな要因となった。しかし、勝利した成功体験のみが強く印象に残り、それを忘れられず他から学ぶことなく太平洋戦争に突入した経験
や、高度成長期を経て GDP が世界第 2 位になった成功体験を忘れられず、革新を怠り現在に至る経験などが相当する。

Ⅳ．1．7 ケーススタディ；日本にウォーターフォールが根付いた理由
アジャイルや IoT など最新技術に後れを取っている日本において、なぜ同じく当時は最新技術だったはずのウォーターフォールが根付いたのか。
歴史的に考察すると、先行した一部の大企業を除く大方の企業において、1980 年代は業務コンピュータ
ー化の黎明期であった。何もないし、何の知識もない。発行間もない当時の『日経コンピュータ』[日経コンピ
ュータ, 1981.10.5 号（創刊号）～1982.12.27 号]を読むと、国内の IT ベンダー、コンピューターメーカー
でさえ潤沢なコンピューター知識を持っていたとはいいがたい。だが、業務の一部をコンピューターに代行させることにより、業務を効率化することで人員不足は解消できることは分かっていた。
そのような状態で、ウォーターフォールは受け入れられたのである。ウォーターフォールが根付いたのには、
大きく二つの理由がある。
1 点目は分かりやすさである。ウォーターフォールの進捗を表現する代表的なチャートはガントチャートである。このガントチャートは、コンピューターの素人にも分かりやすいもので、万人に受け入れやすいものであった。目に見えないソフトウェアを作る作業が目に見えるこのガントチャートで表現されることは容易に日本に受け入れられた。
進捗の遅れを表現する稲妻線も、厳密にはどれくらいの遅れなのかが説明できてはいないが、感覚的に理解できるものであった。
2 点目はウォーターフォールの欠点を日本の国民性がフォローできた点にある。1975 年に出版された『人月の神話』[フレデリック・ブルックス,1975]で既にウォーターフォールの欠点が指摘されている。ウォーターフォールの欠点とは、「後戻り」である。上流から下流にフェーズが流れていくので、テストフェーズで欠陥が見つかった場合、設計フェーズまで戻らなければいけない場合がある。契約社会である欧米では役割分担が明確なので、「後戻り」の責任者も明確である。ゆえに、ウォーターフォールの欠点も明確となり、その欠点をカバーする新しい開発方法論が登場する。日本では役割分担をあいまいにし、明確な定義をしない場合が多い。そして、責任分担を忘れ何とかこなしてしまうのである。欠点として認識されにくいどころか、成功したプロジェクトにカウントされてしまう。
まとめると、素人にも分かりやすい、責任分担が明確ではないので「後戻り」が大問題にはならない、ことによりウォーターフォールが根付いたと考えられる。そして前述した通り、成功体験を得るとそこから抜け出すことはしないので、次回も次々回もウォーターフォールが重宝されるのである。

Ⅳ．2 日本の「らしさ」の定義
上記をまとめ、日本の「らしさ」を定義する。
（1）他国の文化・知恵を取り入れる能力に長けている
自国の文化を残しつつ、他国の文化・知恵を取り入れる能力に長けている。ただし、危機感などか
34

ら発せられる共通の目的意識がなければこの能力は発揮されない。この能力が発揮されるのは稀である。
（2）危機に強い危機が迫った時は、自身が正しいと思うことをストイックに実施する。その判断は自身のためよりも全体の協調を優先する。
（3）多能である
器用であり多能である。ただし、この点も目的意識がなければ過剰品質になる危険性がある。
（4）成功体験から離れらない
目的意識がなければ前例の成功体験に従う。他国の文化・知恵を上手に取り入れる能力は稀にしか発揮されないので、大抵は過去の成功体験に従っている。

Ⅳ．3 日本の情報システムの有るべき姿とは
これまでの考察から、世界と戦える情報システムの有るべき姿は、過去の成功体験が通じない状況で、危機感を感じた状態で共通の目的意識を持てば、後は多能な能力を信じて好きにさせるとおのずとでき上がってくる、と考えられる。
現在の日本において危機感とは何か、共通の目的とは何なのだろうか。

Ⅳ．3．1 危機感
危機感は、経済産業省が「DX レポート」で煽っている。「DX レポート」は、（日本の）既存企業が（海外及び日本の）新興企業によるデジタル・ディスラプションにどう立ち向かうかを説いている。デジタル・ディスラプシ
ョンを、デジタルによる創造的破壊と訳している書物があるが、ディスラプションは disruption であり、「破壊」である。
DX の正体はデジタル・ディスラプションであり、何も手を打たないと企業存続が破壊される危機が迫って来ている。米国ではその被害にあった老舗企業が何社もあることは周知の事実である。デジタルという武器で、自企業を効率化するだけではディスラプションとは言えない。既存業務をデジタルにより自社他社、国内外問わず、ディスラプションしているのである。仕掛ける側が「創造」をつけたくなる気持ちは分からないでもないが、ディスラプションされる側にとってそれが創造的であろうがなかろうがどうでも良いことである。
これに対抗するためには、戦略はイノベーティブでなければならず、それを今までとは比較にならないスピードで実現しなければならない。「和を以て貴しとなす」国なので、本来であれば行いたくはないが、デジタルにより同業他社、異業種をディスラプションしなければならないのかもしれない。そうしないと、淘汰される側になってしまうのかもしれない。
デジタルという武器を持った新興企業は、思いついてから数か月で新しいサービスを提供し破壊してくる。
数か月のスピードを出すためには、過剰品質を諦め、多少不具合があった状態でもシステムを機能させる場合がある。
日本はコンピューターにおいて 1980 年代のメインフレーム＋COBOL＋ウォーターフォールで成功して以降は、最新技術を武器にして戦えていない、世界に発信・輸出できていないことを認識すべきである。
私達の技術は日本固有の技術であり、世界では通用しないと諦める必要はない。マクドナルドはハンバー
35

ガーを輸出したのではなく、ファストフードと言う文化を輸出したのだ。星野リゾートは、お客様とホテルがあたかも主人と奴隷のような欧米系の形態を真似て世界に進出しようとはしていない。客と仲居の関係を輸出しようとしている。
1990 年代の C／S 以降、主に米国の IT を輸入してはいるものの、そのどれもが根付いていないことを認識すべきである。例えば、2000 年代の Web 全盛期においても、メインフレーム＋COBOL＋ウォーターフォールは健在であった。だからと言って、これらではもう勝てない。新たなテクノロジーとしてこれらを再び輸出するのは現実的とは言えない。
このことを強く認識し、現在の最新技術（例えば IoT、AI など）を表面的に模倣するのではなく、そのテクノロジーを日本「らしく」取り入れる必要がある。それは決して簡単ではないが、歴史はそれが可能であることを証明している。

Ⅳ．3．2 共通の目的
DX に話を戻すと、戦うための武器はデジタルでありその正体はデータである。Amazon は購買履歴を全て取得し、その動向に応じてサービスを逐次改定することで売上を伸ばしている。データの有効活用が成長の肝である。
つまり共通の目的とは、確たるデータ（またはそのモデル）を設計し、それを有効に活用することでビジネスに貢献することである。データを定義し、データ間の関連により企業の本質を表すことができれば、ここに向かうことで、全員の足並み・パワーが揃う。
少し脱線して、ここで POA と DOA について再考してみる。POA は Process Oriented Approach、
DOA は Data Oriented Approach の略である。業務をプロセス（作業）中心に考えるか、データ中心に考えるかが両者の違いである。
POA 的発想では、データはプロセスをつなぐ糊である。DOA 的発想では、プロセスはデータを創出・加工・追加・変更・消去するものである。
前述した 1980 年代の輝かしいコンピューター黎明期では、業務の自動化が目的だったので、POA 的発
想で情報システムを構築してきた。これはこれで正しい。しかしデジタルという武器を手に入れるためには、
欲しいデータをどう作っていくかが目的となるため、DOA 的発想で情報システムを構築する必要がある。

Ⅳ．3．3 情報システムの作り方
データはビジネスの写像であり、プロセスはそのデータを変化させるものである、と考える。
プロセスは各人の業務そのものをコンピューターに移植する従来の発想ではなく、あくまでもデータをどう発生させていくか、変えていくか、消去していくかという観点で設計する。
データは企業の本質を核としてトップダウンで設計する。これは簡単なことではない。また、絶対的な正解や模範解答があるものでもなく、自身・自社で考える必要がある。突き放したもの言いをしたので、事例を挙げる。例えば小売業の場合、店舗販売がネット販売へ、決済方法が現金からキャッシュレスへと変化を遂げている。このような変化を遂げても変わらないものがあるはずである。それがここで言う企業の本質であり、データとして定義するものである。
36

プロセスは柔軟性のあるものとすべきである。前例に従うと、現金決済がキャッシュレス決済に変わる（もしくは両方を扱う）よう、プロセスは変化が求められる。この時に、柔軟性を欠いた情報システムだとスピードが出ない。器用で多様性に優れた国民性を活かし、人が行なった方が効率的なものは人に任せる。何もかもをコンピューターに行わせることで柔軟性が失われるのなら、時には割り切りが必要である。
繰り返すと、企業の本質を核として設計されたデータはビジネスの写像であり、それは貴重な資産である。
このデータを変化させるという観点でのみプロセスを設計することで、ビジネス変化に柔軟に対応できるシステムとなる。また、プロセスの全てをコンピューター化する必要はない。柔軟性の方が重要である。
企業の本質を核としないデータ設計、プロセスを中心としてそれらプロセスを連携する手段としてのデータ
設計は、データの乱立を招く。データが乱立した状態のシステムは柔軟性を欠き、ビジネスを取り巻く環境変化の対応に時間とコストがかかることは皆様も経験済みなのではないだろうか。

Ⅳ．4 日本らしさを活かし世界と戦う
本章では、日本の「らしさ」をこれまでの議論や書籍から考察し、そこから導き出される情報システムの有るべき姿を論じてきた。
日本「らしさ」とは、器用で多能であるが、危機感がないとその能力を過剰品質に発揮してしまう。また、明文化されたロジカルな状態よりも、なぁなぁな状態の居心地が気持ちよく感じられ、それらは「和を以て貴しとなす」に収束する。
このような「らしさ」で世界と戦うにはどのような情報システムが好ましいのか。まずは DX に代表されるデ
ジタル・ディスラプションが現実的な脅威であることを認識すること。デジタルという武器（デジタル以外にも武器はあるが、我々はデジタルとまともに戦える武器はデジタル以外ないと確信している）の実態は「データ」である。企業の本質をデータでデザインし、そのデータを発生・変更・消去するプロセスは、器用で多能な能力を十分に発揮し、好き勝手に作る。
これは今までの POA とは発想が逆なので、過去の成功体験では戦えないことを認識し、最新技術を日本「らしく」自身の血肉にする必要がある。私たちはそれができる、数少ない国に生まれている。

＜参照文献＞
P.F.ドラッガー (1994) 『既に起こった未来』 ダイヤモンド社
ジャレド・ダイアモンド (2019) 『危機と人類』 日本経済新聞出版社
フレデリック・ブルックス (1975) 『人月の神話』丸善出版『日経コンピュータ』 (1981.10.5 号（創刊号）～1982.12.27 号) 日経 BP37

Ⅴ章 情報システムの高度化とは
赤 俊哉
本章のサマリー

システム高度化に向けた現状の課題解決には、全社的アーキテクチャーの構築とデータガバナンスが有効に機能するデータマネジメントの実現が重要である。



システムには、ダイナミックなシステムとスタティックなシステムという、両立すべき二つの系がある。そのいずれにも共通するのがデータとデータモデルであり、データモデルに基づいた持続的データマネジ
メントが重要となる。



システムには、迅速性（ダイナミックなシステム）と安定性（スタティックなシステム）の両立を可能とする
アーキテクチャー（拠り所）を構築し、データマネジメントの観点から「分散」と「集中」のめりはりをつける。「分散」は「迅速性」に、「集中」は「安定性」に対して効果を発揮する。



現状を把握した上で、システムにより求めるべき方向を定め、進めていく必要がある。



計画及び計画と実績との差異分析、差異が生じた場合は、計画を変更しながら、大きな方向性は変えずに、進路を定めて進めていく。



これらの実行のためには、経営層やユーザー部門の理解を得るための情報発信を IT 部門から行うとともに、システム更新時に高度化に向けた仕組みを埋め込むチャンスを逃さない企画力を養う必要がある。そのためにデータマネジメントなどの知識・スキルを養うとともに、社内外のリソースをうまく「オーケストレーション」する能力（組織）が求められる。

今回、約 5 年にわたり本プロジェクトにて、情報システムの高度化に対する議論を行ってきた。本章では、前章までの内容を参考に、その議論の内容について具体的に記述していくことにより、高度化そのものの姿を明らかにしていく。

Ⅴ．1 情報システムについて
高度化に関して語る前にまず企業における情報システムの役割の変化について記述する。

Ⅴ．1．1 情報システムの役割の変化
企業における情報システムの果たす役割は、時代とともに変遷している。ここで、黎明期から現在に至る
情報システムの役割を俯瞰しつつ、記述する。
コンピューターの黎明期は、ハードウエアに関しては大型のメインフレーム(大型電算機)を導入する以外の選択肢はなく、導入した企業は「業務の省力化」を目的として情報システムを構築していった。
大型の電算機はそれまで考えられなかった計算のスピードを保持しており、この能力を最大限に活かして構築された情報システムは充分に目的を果たしていたといえる。さらにⅣ章でも説明した通り、この考え方、構築方法が日本人にあっていたのか 1980 年代当時はビジネス視点において一定の効果を出すこと38

ができた。
業務の省力化はプロセスの自動化、省力化を中心に行われた。当然の如く個々のプロセス中心に物事を考えて「いかに自動化、省力化するか」を検討し、システム化が行われた。
こうして個々のプロセスの最適化、部門レベルの部分最適化は充分に行われビジネスに貢献した。
時は 21 世紀になった。テクノロジーの進化とともにコンピューター改め IT は、飛躍的な進歩を遂げた。
大型のメインフレームを導入しなくても安価な PC サーバーを組み合わせて、従来以上の能力を発揮できるようになった。集中処理のみに頼ることなく分散処理が可能になった。そして現在は、SaaS（Software
as a Service）やクラウドの活用で、それらを所有することなく「使う時だけ使う」ことが可能になった。
当然 IT を技術基盤として構築される情報システムの役割も変化してくる。
情報システムは、技術の進化に合わせて従来の「省力化」だけでなく、何らかの「価値創造」が求められるようになった。技術を基盤としている以上、技術の進化とともに進化していかなければ、情報システムはその存在価値を失うともいえる。
ここで述べた価値創造とは大きく分けて二つの観点から考えられる。「意思決定」と「創造的破壊」である。
このいずれにおいても従来の単なる部門レベルの自動化、省力化だけを考えて構築された情報システムでは対応できない。全社的な取組みとして情報システムを捉える必要がある。必然的に、これまでの「部分最適」から「全体最適」へ、思考を転換する必要がでてきた。
このような状況になってしまうと、「プロセス中心（POA）」の考えで構築された情報システムは、行き詰まることになる。新たな役割を果たすことができない。さらに、当時システム開発を担い徹底的な部分最適化に貢献した開発スタッフはもういない。
「どこをどう最適化したのかわからない…」、「どこをどう変えればいいかわからない…」「新しいシステムと古いシステムをどう連携させたらいいかわからない…」「そもそも、どうすれば価値ある情報システムを構築できるのか、わからない…」
ではどうすればよいのだろうか。これに対する回答が情報システム高度化の推進である。本書では、高度化を実現するための重要施策としてまず「データ」に着目した。
全社最適を実現するためには「データ」の重要性を認識し、見える化した上で、つながりを確保することが重要になる。これを実現することこそが、情報システムの高度化の第一歩であり、現在そしてこれからの情報システムの役割を果たすことにつながる。
そのためには当然のことながら従来のプロセス中心（POA）からデータ中心（DOA）への思考の転換が必須になる。
以下に、情報システムの高度化を考える上で、最優先すべき「データ」の重要性について説明する。
図表Ⅴ-1 では、事実を表す「データ」は、意味付けされて「情報」となることを表している。
「情報」は時間的概念を有し、他との関連性を持ち、ものごとの内容や事情を表す。
「情報」は、そのパターンやトレンド、関連性、仮説を持たせることで価値のある「知識」となり、それを人が活かすことで、意思決定のための「知恵」となる。
「情報」を取り扱う「系」として「情報システム」は、実ビジネスを写像するとともに人と組織の意思決定を支援する役割を果たしていると言える。

39

図表Ⅴ-1 データが知恵へと進化する

出典：「DMBOK」資料を基に加筆、改変

少し表現を変えると、情報システムは Intelligence を生み出す力としてのサイクルとして考えることができる。このサイクルは「事実としてのデータ」を「意味のある情報」「価値を生む知識」「意思決定の知恵」と形を変えていく。サイクルの起点であり、根幹となるデータが、意味内容まで定義されて正確にシステムに反映されることが最も肝要である。
また「情報システム」が人や組織の意思決定を支援する役割を果たすためには、「適切なタイミングに適切な人（場所）が適切な品質の情報をインプットすることにより、必要なタイミングに必要な人（場所）へ必要な品質の情報をアウトプットすること」が大きな使命であるともいえる。
情報システムを役割から考えてみると、「ビジネスの写像」として、組織が企業の目的を達成するために行う活動（オペレーション、マネジメント、意思決定など）を支援することが、第 1 の役割として位置付けられ、各企業において重要な役割を果たしてきた。
一方、テクノロジーの進歩と IT 利活用の多様化により、企業の情報システム活用が果たす役割には、性質の異なる第 2 の側面が存在するようになってきた。新しいテクノロジーを組合せてビジネスを創造したり、データ・情報から生まれたアイデアを具体化・実現化するなど、ビジネス創造のトリガーとして IT を活用するといった大きな変化が起きてきている。
結果として、情報システムは、二つの重要な役割と効果をもたらすに至っている。
役 割

効 果

①

実世界の写像として、人と組織の意思決定、目標達成活動の支援

事業の継続性担保②

新技術によるイノベーションとしての企業変革を継続するトリガー

創造的破壊の支援第一の役割は「人と組織の意思決定、目標達成活動の支援」であり、生み出した価値の継続を可能にすることにより、事業の継続性を担保する効果を生む。
第二の役割は「新技術によるイノベーションとしての企業変革を継続するトリガー」であり、新たな価値を生み出すことにより、創造的破壊を支援する効果を生む。
情報システムに関わる考察では、この二つの役割と効果を意識しておく必要がある。
図表Ⅴ-2 は、情報システムの果たす役割の変化について企業経営における価値の向上の視点から示した も の で あ る 。 情 報 シ ス テ ム か ら 得 ら れ る 知 恵 は 、 企 業 変 革 の ア イ デ ア と し て 、 Marketing やInnovation のための Intelligence として活用され、経営の高度化に繋げられていることが分かる。
40

図表Ⅴ-2 情報システムの果たす役割の変化と価値

図表Ⅴ-3 は、企業の経済活動を支えるシステムの存在意義に関して、ドラッカーの経営論をベースにまとめたものである。コトラーのマーケティング、マイケル・ポーターの戦略論、シュンペーターの創造的破壊、スティーブ・ジョブスの創造的破壊の実践を俯瞰するとき、Intelligence の重要性が浮かび上がる。
図表Ⅴ-3 企業の経済活動を支えるシステムの存在意義

Intelligence の重要性を考えるとき、経営の高度化にもさまざまな種類・領域はあるものの、どの領域においても情報・知的財産の活用は不可欠であり、その推進力（実現手段）の一つが情報システムであるといえる。
情報システムをこの Intelligence を生み出す力として活用するのであれば、第 1 の役割である「人と組41

織の意思決定の支援」として、データ・情報をマーケティングや企業戦略に活かして業績を向上させ、事業を継続的に成長させていくことができるし、第 2 の役割である「企業変革を継続するトリガー」として、デー
タ・情報を新たな価値を生み出し、創造的破壊を支援し Innovation に結び付けていくことができる。
役割を果たすためには企業全体を俯瞰して情報システムをどのように活かしていくかを考え続けることが重要である。さらに、その源となるデータ・情報・知的財産を正しく収集して分析することが不可欠である。

Ⅴ．1．2 よいシステムとは
以下に、独立行政法人情報処理推進機構（IPA）による「第 4 次産業革命における「知」のシステム化対応の実態調査」にてまとめられた「よいシステム」の持つべき条件を掲載する。これを参考に、経営に貢献するシステムについて考えてみたい。
■「よいシステム」の持つべき条件
・作られた理念が明確に理解でき、出来ること出来ないことの境界がはっきりしている。
・ユーザーにとって使いやすく、十分目的が達成される。
・システムの全体構成が理解しやすい。
・運用がしやすく、故障への対処が容易である。
・拡張可能性がある（scalability）。
・環境の変化に応じて進化できる。
・利害関係者（ステークホルダー）の多くを満足させることができる。
・堅牢で十分な持続可能性がある。
・システムの構築コスト、運用コストが安い。
上記条件は、一般論として情報システムそのものが「良い」ということに関しては正解ではあるが、それぞれの企業で現在抱えている問題・課題に対しては、ヒントとしては有用であるものの、すべてに対応することが解を与えてくれているとは思えない。
むしろ、情報システムの持つ価値や果たすべき役割から「あるべき姿」を考えてみたい。
内容としては前述した内容とは若干重複するものの情報システムの高度化を考える上で重要な観点なので再度ここに記述する。
①人と組織の意思決定の支援⇒生み出した価値の継続 ⇒事業の継続性担保②企業変革を継続するトリガー ⇒新たな価値を生み出す ⇒創造的破壊の支援
情報システムを活かすことは、『「事実としてのデータ」⇒「意味のある情報」⇒「価値を生む知識」⇒「意
思決定の知恵」のサイクルとも考えられる。まさに Intelligence を生み出すための推進力（実現手段）とす
ることに通じ、企業の業績を向上させ事業を継続させるとともに、新たな価値を生み出し創造的破壊を支援する』ことである。
企業を取り巻く環境やテクノロジーの進化、新しい商品・サービスの創造、新ビジネスの創造などに対応
して、上記二つの役割を果たすために、情報システムが変化（進化）することである。
42

上記の内容を踏まえて以下に情報システムの高度化に関する議論の内容を改めて図表Ⅴ-4 に示す。
図表Ⅴ-4 情報システムの高度化～全体像

Ⅴ．2 情報システムの高度化とは
Ⅴ．2．1 高度化の意味
情報システムは、ビジネスの価値／効果を創出し続け、さらにビジネスの変化に対して対応可能であり続けることにより初めて意味を持つ。逆にビジネスに貢献しない仕組みはいくら高度な技術的要素を持とうとも意味を持たない。
情報システムの高度化とは、ビジネス価値／効果を創出し、変化への対応を可能とする情報システムのあり方を指す。
企業にとって高度な情報システムの条件とは、どのような変化にも迅速に対応できることである。
対応しなければならない変化とは以下の 5 点である。
・社会の変化（経済環境／法的規制／顧客の嗜好／・・・）
・会社の変化（経営環境／事業戦略／
・組織の変化（組織目的／

・・・）／構成の変化／・・・）

・人の変化（社員／顧客／スキル／・・・）

・技術の変化（CPU／ソフト／AI／IoT／

・・・）
43

情報システム開発・保守のなかに経営環境の変化をいかに取り込んでいくかが、大きな課題であり、これを複雑にならず変化させられるようにすることが「情報システムの高度化」である。つまり、情報システムの高度化を実現するためには、経営のスピードに対応可能な内部構造を持つことが絶対条件となる。
高度化について語る際には仕組みだけでなく組織についても留意する必要がある。
企業にとっての大きな仕組みが変わるときには組織も変わるものである。組織を変えながら、IT システムを変化させていく、つまり両者をシンクロさせていくことが「高度な情報システムづくり」に不可欠である。
その際に、企業における情報システムとして、保有しなければならない要件は以下である。
・作られた理念と目的が理解され、目的を達成するに十分な機能・構成である。
・環境の変化に素早く対応して、進化できる。
・事業の継続性（生み出した価値の継続）を保障（担保）している。
・創造的破壊（新たな価値を生み出すこと）の支援ができる。
少し視点を変えて、企業価値の向上という視点からシステムの高度化を考えてみる。
企業経営における価値の向上とは、Marketing（市場創造）であり、Innovation（経営革新）であり、Intelligence（情報・知的財産）を向上させることである。
こ の こ と に よ り 、 企 業 は 、 （ 社 会 的 存 在 価 値 ） Admired Company 、 （ 地 域 社 会 貢 献 ） Social
Company、（従業員優遇会社）Peoples Company、（高財務・収益体質）Excellent Company として社会的な価値を持つ。その際に必要なシステムの高度化は、Data（データ・情報）、Application（実現手段）、Technology（基盤技術）の視点から考える必要がある。
つまり、企業価値を高めるシステムの高度化とは、図表Ⅴ‐5 に示すような意味を持つと考えられる。
図表Ⅴ-5 企業価値を高める情報システムの高度化の意義

・「企業価値を高めるシステムの高度化」の使命とは、何らかのビジネス価値の向上に貢献し続けられる仕組みを継続的に提供し、創出し続けることである。
・また、仕組みへの投資は、差別化にどう貢献するかで正当化されるべきものであり、資本主義だけではな
く、価値主義への転換を支援する役割も担う。
44

・この使命を果たすために、体系化された（企業経営のリソースとなる）要素の機動性を IT という技術要素
によって高め、あらゆる変化に対して柔軟に、迅速に対応できる状態であり続けることが重要となる。
高度化を実現するためには、ビジネスと情報システムが一体化していなければならない。
その際の情報システムの目的とは、前述した通り、二つの役割と効果の実現・あるべき姿の実現が可能であること、すなわち「情報を活用し①実ビジネスの写像把握②新しい価値の創造」を可能とすることである。
この目的を満たすことにより初めて「①②の礎として経営者と情報活用者が拠り所とするに足るデータを保証する」という情報システムが本来持つべき使命を全うすることになる。
さらに、高度化を考える上で、情報システムのあるべき姿として、今後、データ活用は当然でありデータ活用なくして企業の存続はありえないことを意識する必要がある。
その際に必要となる方法論を EA（エンタープライズアーキテクチャー）の視点から考えてみる。
企業内・企業間で情報システムが変化に対応するために必要なことは、データ（情報）連携の確保である。
つまり EA において DA(データアーキテクチャー)がきちんと機能している状態である。
図表Ⅴ-6 EA モデルの欧米と日本の違い

日本では、欧米で発想された EA モデルを参考にしつつも、AA（アプリケーションアーキテクチャー）の中で DA（データアーキテクチャー）が意識されずに構築・管理されてきた。データモデリングとプロセスモデリ
ングとの関わりを捉えつつ、分け方はさまざまあるとしても、変更してはいけないデータをまもるためのDA・AA を厳然と整理し、守る必要がある。
さらに情報システムの基盤として DA を下支えする「データマネジメント」1が組織として機能している必要がある。ちなみに図表Ⅴ-6 の左が欧米で発想された EA モデルであり、右が日本的発想に基づく EA モデ
ルで、AA と DA が一体化していると考えられる。詳しくは後のⅥ章とⅪ章で説明する。
この観点から考察すると、変化に迅速に対応できるために必要なシステム高度化の要件は、以下の通り
1

データマネジメントとは、データと情報資産の価値を獲得し、統制し、保護し、提供し、向上させるためのポリシー、実践、プロジェクトについて計画を立てて実行することを意味する。（『データマネジメント知識体
系ガイド第二版』より）
45

になる。
1. 技術変化に対しては、グローバルな視点で活用可能な膨大なデータと最先端 IT の機能を活用し、その威力を企業の競争力として素早く取り込めること
2. 事業変化に対しては、グローバルに敏感に反応・変化する経済・事業動向に対して、商材・サービス・事
業形態など、素早く柔軟にシステム対応できること

Ⅴ．2．2 DOA の再定義
情報システムの高度化にあたりデータの重要性について整理していく。まず以前よりシステム開発の手法として考えられていた DOA(Data Oriented Approach)について図表Ⅴ-7 に再定義する。
DOA とは、Data Oriented Approach(データ中心アプローチ)の略であり、業務システムの設計手法の一つで、システムの扱うデータの構造や関係を定義し、それに合わせて処理や手順の流れを決めていく方式である。
図表Ⅴ-7 DOA（Data Oriented Approach）の再定義(1)

情報システムの高度化を考える上で、DOA を DOBA、DOCA の二つに再定義する。
DOBA とは Data Oriented Business Approach、つまりビジネス視点においてデータ中心指向で考えることを指し、DOCA とは Data Oriented Computing Approach、つまりコンピューター視点においてデータ中心指向で考えることを指す。
従来、巷間で唱えられてきた DOA とは、システム開発の方法論としての DOCA であり、システムのビジネス・経営に対する価値が飛躍的に高まってきた今日において、経営に対し重要な要素となる Data とBusiness の関係を再定義した DOBA の重要性を改めて認識する必要がある。
データがつながることでビジネス・経営に対する価値を生み出せることが明らかな時代になってきた今、「つながったデータ」にこそ価値がある。このことをビジネスと IT システムの両輪で意識していくことが必要
で あ る 。 そ れ に よ り 、 デ ー タ ド リ ブ ン 経 営 へ の 道 筋 を つ け る こ と に も つ な が り 、 Business DataManagement の重要性を再確認することになる。これこそが高度化を実現する DOA のあり方である。
DOBA、DOCA は DxBA、DxCA と表現することも可能である。この場合、「ｘ」は解釈によって「Centric」「Driven」「Oriented」などを当てはめることになる（図表Ⅴ-8 参照）。
46

図表Ⅴ-8 DOA（Data Oriented Approach）の再定義(2)

データの重要性を語る上で少し視点を変えて考えてみる。
パッケージを使えば「ある程度の高度化」（セキュリティ面など）は自動的にやってもらえるはずである。しかし、自社業務のイノベーションに関することまでは面倒をみてくれる訳がない。絶対に他者にはやってもらえない、と考えた方がよい。自ら行うべきである。
ビジネスの最終目標は競争に勝って生き残っていくことである。ERP は基幹システムであり、横並びで導入する限り競争優位性はあまり得られない。競争に勝つためには、勝つための仕組みを別に作る必要がある。そのための武器がデータである。
それに加えて、今後はコントロールしきれない領域のデータが増えてくる。例えばセールスフォースに入れた営業日報などはデータ構造に関与できない。しかしビジネス価値の高い情報は、他のデータ構造に入っている情報（この場合は営業日報）と売上データをリンクさせるなどしないと導き出せない。
こういったことは、DOA に基づいた確たるデータモデルを自分達で持っていれば、適切な判断ができる
はずである。
また経営と情報システムとは不可分ななかで、データモデルを作成する際にはデータ資源管理台帳をきちんと作成することが必要になる。人・モノ・カネ・データが経営の 4 資源と言われて久しいが、残念ながら
データ台帳が（まだ）ない企業が多い。
人もモノもカネも、組織図、設備配置図、BS と PL など、階層構造化された一覧や構造図で全体が把握できるようになっている。本来データ台帳も同じレベルで作成されていなければならない。その際に作成するデータ台帳は単なる一覧ではなく、階層構造化されていて、全体の構造が見て取れるような状態まで持って行って、初めて台帳化されたと言える。
さらに、データを台帳で管理するということは、その出し入れもしっかり管理できていなければならない（例えば人事台帳を参照しても、いつの間にか社員が辞めたり増えていたり、社員数が数えられない会社はない。それに比べてデータはどうか）。
データの出し入れを管理するならば、管理単位が明確になっていなければならない。どのようなデータが入ってきたら、どの管理単位に属するのかがわかっている状態でなければならない。例えば SNS を言語解
析して自社の評判の分析をしたら、それは商品に対してなのか、従業員に対してなのかを識別したうえで属
性ごとに管理可能であり、IoT でデータを取得したら、それは製品に関してなのか、製造装置に関してなの
47

かが識別可能であり、かつ登録可能でなければならない。すなわち、データモデル2においてエンティティ3と
キー4とリレーションシップ5が明確になっている状態を指す。

Ⅴ．2．3 高度化の二つの視点
情報システムの高度化を以下の二つの視点で捉えてみる。
図表Ⅴ-9 情報システムの高度化の二つの視点による価値（1）情報システム構造を保証し続ける（マネジメント）「変化への対応」が迅速に行えるように、プロセス／データ／情報活用を分けてマネジメントできる構造を構築する。そのための必須条件として、AP(アプリケーション)と DB（データベース）の分離を行うこと、を忘れてはならない。
情報システムの高度化を実現するためには、先ほどの組織のあり方とともにアクター（経営者・IT 部門・業務部門）の役割定義も重要になる。アクターの役割をきちんと考えていく必要もある。アクターの役割としては以下が考えられる。

2

データモデルとは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤を指す。
3
エンティティとは、データモデルにおいて実体を表す。例えば「顧客」「商品」「注文」など。
4
キーとは、エンティティを一意に識別することを可能とする識別子。例えば「注文№」「顧客コード」など。
5
リレーションシップとは、エンティティ同士の関連を表す。エンティティの間を線でつなぎ、その線の種類、方向、定義により関係性を表す。
48

(ア) IT 部門は、変化への対応の時に、情報システムの構造を崩さない、つまりレガシー化させない方策を講じる。
(イ) IT 部門（ユーザー）はシステム開発・改修の時に「変えられること、変えてはいけないこと」を明らかにして現場(エンドユーザー)にきちんと理解してもらう（理解させ守らせる）。もし不幸にも変えてはいけないところを変えてしまっている場合は、構造を見直していく（ブラックボックスの解消もしくは修正をあてる）。変えてはいけないところを守れているなら、それをどう維持していくかを考える。
(ウ) 経営者・業務部門は、新しい価値を創出するためにビジネスプロセスを進化させる必要があるとき、何がやりたいのかを明確に提示する、つまり情報要求を明確にする必要がある。
なぜ、情報システムの高度化を語る上でアクターにこだわるのか。
それは本書では、情報システムとは、コンピューター（電源を抜いたらとまる）＝IT システムではなく、人・体制まで含めた IS こそが「情報システム」である、と考える故である。
情報システムの高度化とは、コンピューターシステムだけが対象なのではなく、人や組織を含んだ情報を扱う業務の仕組み、すなわち情報システムを見える化し、運用し、時に根本的に作り替えることができるよ
うになることである。
（2）情報システム構築（開発）マネジメント
システム開発を正しく行うためのシステムズエンジニアリング実施には、まずは各アクターが情報要求を明確にし、データ中心指向アプローチで情報システムを開発することが第一歩になる。
「企業価値を高めるシステムの高度化」の使命とは、何らかのビジネス価値の向上に貢献し続けられる仕組みを継続的に提供し、創出し続けることである。
また、仕組みへの投資は、前述した通り差別化にどう貢献するかで正当化されるべきものであり、資本主
義だけではなく、価値主義への転換を支援する役割も担う。
この使命を果たすために、体系化された（企業経営のリソースとなる）要素の機動性を IT 技術によって高め、あらゆる変化に対して柔軟に迅速に対応できる状態であり続けることが重要となる。

Ⅴ．2．4 高度化の 2 軸の視点
情報システムの高度化の姿をより明らかにするために、その特性について、次の２軸で考えてみる。
・軸 1（縦軸）：でき上がった仕組みの戦略（目的）適合性が高いか。
ビジネス構造において有用性・競争優位性が高い、意思決定のプロセス、人の関わりといった、戦略（目的）適合性・有用性の軸・軸 2（横軸）：内部構造がエンジニアリング的にできているか。
作り方が高度、よくできている、高級品である、構造が明確でしっかりしている、分解・組
み立てしやすい、変化に強い、部品化しやすい、といったシステムの内部構造の軸49図表Ⅴ-10 情報システムの高度化の二つの軸による考察

図表Ⅴ-10 の縦軸は「戦略適合性・有用性」を、横軸は「システム構造」を表している。図中の矢印は情報システムの高度化を目指す上での道筋を表している。高度化を実現するための道は一つではない。ただし、図中の 1 番左の点線の矢印が表すように、当初はシステムの内部構造を考慮せずに、スピード迅速性を重視し、後から内部構造を整えるようなやり方は本書の対象外とする。その時点でシステム自体が構造的に高度化を確保できない状態を作り上げるのは避けたい。企業により縦軸、横軸のウエイトは異なれど両者は両立するものであり、すべきものである。
横軸の追求の視点としてアーキテクチャーに着目してみると、特にシステムアーキテクチャーにおいて、ビジネスロジック、データ、画面表示系、データアクセス系をシステム上きちんと分けることにより、柔軟性が確保できる。併行してシステム構造のアーキテクチャーをしっかり決めて、逸脱がないようにガバナンスしていければ柔軟性も機密性も同時に高められる。
データアーキテクチャーを考える上で、ここでもデータモデルが重要である。
データモデルは堅牢であるほど柔軟性は増すことを忘れてはいけない。データモデルが堅牢であるほど硬直性が増すと勘違いしている人が多いが、データモデルは堅牢であればあるほど柔軟性に富む。そのためには、モデルの抽象度をどこまで上げて現実的に落とし込めるかが柔軟性確保の鍵になる。
内部構造は、横軸の左に寄るほど硬直し、右へ寄るほどデータモデルが堅牢で、ビジネス変化への追従が柔軟にできるイメージになる。堅牢とは、システム（アプリケーション）に対してではなく、データに対してであり、アプリケーションに従属することなくプロセスからの独立性が高いデータモデルを活用して、柔軟にビジネスに対応できるイメージである。
ビジネス貢献においては、内部構造重視が求められるシステムと、戦略（目的）・有用性重視でスピードが求められるシステムとがある。基盤系のシステムなど安定性にシステム価値を置く場合は、内部構造を追求することになる。早くビジネスフィールドに出し、一刻でも早くビジネスに貢献させることにシステム価値を置く場合は、内部構造をあまり重視せずに「瞬間価値」としての効果を求める俊敏性重視のシステムになる。
内部構造は後から整備する、あるいは使い捨てでも良いからその瞬間ごとで最大の価値を生んでくれればよい。ただし、それにも限度があると本書では考える。図表Ⅴ-10 の 1 番左の点線の矢印ではシステム内部構造の整備に時間がかかりすぎてしまう。あくまで内部構造を崩さないレベルを見極める必要がある。
例えば顧客分析などを行おうとすると、ある程度内部構造が整備され、ある意味「美しい」データ構造が存在しなければ対応できない。今後社内の業務データ、IoT 経由のデータ、コントロールできないデータ
50

（SNS 経由など）など非構造化データも分析対象になっていく。それらを何らかの形で経営に貢献するデータとして閲覧可能にしなければビジネスニーズに応えられない。スクラッチ、パッケージなどのシステム形
態はどうでもよい。どのようなデータがアウトプット可能なのかを、把握できるようにすることが重要である。
やはりデータマネジメントの考えを全面的に取り入れる必要があるといってよいだろう。データのエンゲージ
メントを柔軟に行い経営ニーズに応えられることがシステムの高度化であるとも考えられる。
そう考えると、いままで IT 部門がケアしてきた基幹系システム（決算・会計システムなど）とは異なる、戦略＝競争優位性確保のためのシステムが必要だということになる。
「戦略（目的）適合性・有用性」と「システムの内部構造」の 2 軸は、情報システムの高度化において、以下の 2 点を考える上で、常に存在すると考えてよい。
１． 「情報システムを作り上げるとき」と「でき上がった情報システムをどう高度化していくか(でき上がったシステムは常に変わる・進化する）」
２． 情報システムの二つの役割である「①（昨日と同じ今日を作り出す）生み出した価値の継続＝事業の継続性担保」と「②（昨日と違う今日を作り出す）新たな価値を生み出す＝創造的破壊（イノベーション）の支援」
システムを作り上げること（プロセス）と、でき上がったシステムをどう捉えるかは異なる。2 軸（戦略・目的／内部構造）をベースに考え続ける上で、「作るためのプロセスや組織体制の高度化」と「でき上がったシス
テムの高度化」とを分けて考えていく必要がある。
作り上げるための仕組み（ウォーターフォールやスクラッチ、V 字開発、DOA など）は、でき上がった仕組
みとは関係がない。どのようなやり方で作り上げようと問題にならない。作り上げるプロセスではなく、でき上がったシステムが「戦略（目的）適合性・有用性」を満たし、高度化されていればよい。ただし、本書では高度化を可能にする「作り上げる仕組み」として DOA を中心にデータがシステムの価値を左右することを認識した上で、システム開発を経営、技術両面から考えていくことを推奨している。
これは、作るための高度化、でき上がったシステムの高度化のいずれにおいても、必要なベース（基盤）は DOA の考え方を包含した「データマネジメント」が重要であることを意味している。データマネジメントの考え方を開発プロセスに組み込むとともに、的確なデータマネジメントを継続的に推進する組織のあり方を考えていく必要がある。
また、でき上がったシステムの高度化には「情報システムの維持」を視野に入れる必要がある。コンセプトを引き継いだ人たちが整合性の取れた状態を維持できるように成長させていくことが重要である。日本の場合、情報システムが理解できないようなトップばかりであてにできないことがよくある。その場合、ミドルア
ップでやっていくしかない。ミドルアップを機能させてシステムの整合をとることは高度で難しいことだが、日本の場合は強みになるのではないか、と本書では考える。

Ⅴ．2．5 アーキテクチャー
高度化についてより詳しく説明する上で、Ⅴ．1 に記述した内容を元に少し違った視点から、内容の重複
51

を承知の上で情報システムの役割について考えてみる。
【情報システムの役割】
１． 日常のオペレーションを効率化する：構造化されたアーキテクチャーが支える。
２． 新たなビジネスモデルを実現する：経営の意を汲んだプロジェクトが実現する。
技術面においては「アーキテクチャー」と「開発方法論」があるが、まず「アーキテクチャー」がどうあるべきかを明確に語ることが重要である。情報システムの高度化を実現するアーキテクチャーの要件は以下の通りである。
・構造化され、それが見える化できている（ブラックボックスではない）。
・データとプロセスが分離できている。
・データはキー構造が明確である（ER 図 6があることが望ましい）。
・データとプロセスとの関係が CRUD 図 7で明示されている。
・プロセスを担う組織が明確になっている。
経営戦略を具現化した「アーキテクチャー」を考える上で、以下の問い掛けに回答可能できなければならない。
・経営戦略はあるか？
・情報要求 8はあるか？
・経営戦略を実現する「開発方法論」とは？
・どんなアーキテクチャーなら良いか？
・アーキテクチャーは既にできているか？
・できていなければ何を足してどう作り直せばよいか？
・必要とされる新たなアーキテクチャーはどんな形か？
・新たなアーキテクチャーを実現するにはどんな IT が必要か？
（その IT を活用する組織やプロセスも同時に構造化して保証する）
あるビジネスモデルが維持・継続されているなかでは、上記アーキテクチャー要件を満たした情報システムが稼働していることで、パフォーマンス測定ができ、中間上位層（部課長級）は日常的な意思決定ができるようになりミドルアップを機能させることが可能になる。
更にその上位層（経営層）、トップはビジネスモデルそのものを評価して、創造的破壊を行う（＝新事業に進出あるいは新たなビジネスモデルに移行）するかどうかを判断（これはシステムで判断するようなものではない。経営層の専権事項）し、新たな情報システム（すなわち業務の仕組みでありビジネスモデル）を構想する。考え抜かれた経営戦略に沿った IT 戦略を展開することが可能になる。トップダウンを可能な限り機能させることが重要になる。

6

ER 図とは、エンティティ・リレーションシップ関連図のことを指す。データを実体（エンティティ）と関連（リレーションシップ）、属性（アトリビュート）という三つの要素出表すモデル図である。
7
CRUD 図とは、当該データに対するプロセス・機能が行う操作、すなわち生成（C）、参照（R）、更新（U）、削除（D）を表したマトリクス形式の図である。データライフサイクルの管理が可能になる。
8
情報要求とは、直面する問題を解決するために必要な情報を入手したいとする欲求である。Ⅹ章にて詳しく説明する。
52

Ⅴ．2．6 価値の転換
グローバル経済の進展やビジネスのデジタル化に伴って、情報システムは「社内業務を効率化するツール」から「顧客に価値を提供するもの」へと変化していった。この変化に対応するためには次のような情報シ
ステムの高度化を行う必要がある。
・サイロ化した機能別組織から、プロダクトやサービスごとのプロジェクト組織へと変化させる。
・組織階層を極力フラット化し、現場に権限委譲する。
・システム資産は極力保有せずクラウドコンピューティングを活用する。
・システムは極力開発せず、パッケージや既存のサービスなどを結合して業務フローを構築する。
・必要とされるシステム形態に応じてマイクロサービスを活用し、より疎結合化してシステムを構築する
ことによって、変化に対して柔軟に対応する。
・プロセス中心ではなく、データ中心でシステムを設計する。
・バイモーダルを確立し、迅速性と正確性の両方を満たす。併行して結果的にデータ経営の要件を満たすシステムであることを保証する。そのためのアーキテクチャーの確立は必須条件である。
・情報システムの高度化とは、IT システムだけが対象なのではなく、人や組織を含んだ情報を扱う業務の仕組み、すなわち情報システムを見える化し、運用し、時に根本的に作り替えることができるようになることであると認識する。
・データ台帳を持ち、組織分担がなされ、多能工がそれを支え、ミドルアップダウンの発想で維持改善を続けながら、時に仕組み全体すなわちビジネスモデルそのものをも自ら作り替えることができる方法も持ち合わせている状態になることである。
系が自らを作り替える力を持つことは、CMMI などではレベル 5 とされた。自ら作り変える力とはレジリエンスを意味する。レジリエンスとは自己修復性であり環境耐性である。
・ブラックボックスから脱却し、見える化されたアーキテクチャーで現在を定義すること。その上でアーキテク
チャーの変革を行い、創造的破壊を行う力を持つことで、情報システムの高度化は完成する。
社内業務の効率化から顧客価値の提供へとビジネスの考え方が変わってきているので、システムもそれに呼応できるようなシステムのあり方・開発方針などに変わっていくことを可能にするのが高度化である。
繰り返しになるが前提としてはデータ経営の要件を満たすシステムであることが必須である。

Ⅴ．3 高度化に必要なこととは
Ⅴ．3．1 高度化の構成要素
あらゆる変化に対し「情報システムの使命 9」を果たせる柔軟な構造を有するために必要な高度化の構成要素として、以下が考えられる。

9

適切な時（タイミング）に、適切な人（場所）が、適切な（品質の）情報をインプット（入力）することにより、必要な時（タイミング）に、必要な人（場所）へ、必要な（品質の）情報をアウトプット（出力）すること。
53

【構造が具備すべき性質】
・変化への対応の迅速性（アジリティ）
・多様な企業・団体外と接続・連携可能な多様性（システム・ダイバーシティ）
・ デ ー タ の RASIS 【 Reliability （ 信 頼 性 ） 、 Availability （ 可 用 性 ） 、 Serviceability （ 保 守 性 ） 、Integrity（保全性）、Security（機密性）】【構造の基本的な考え方】「情報システムは成長・変化し続ける」という前提に基づき、普遍的なものと、変化するものとを分けて考え構造を決定する。
①普遍的なもの＝ビジネスに不可欠な情報の体系／データ②変化するもの＝企業活動（ビジネス）／アプリケーション／インターフェイス
情報システムは「系」である。企業活動の要素（ヒト・モノ・カネなど）を体系づけて根幹とすれば、企業活動（ビジネス）に現れる価値が変わっても柔軟に対応できる。インターフェイス（紙やハンドなども含む）は、時宜にあわせて変えればよい。業務と一体になる部分（②変化するもの）と、業務と無関係にしておくべきところ（①普遍的なもの）とを、分離しておくことで、常にビジネスとの一体化を実現できる。
【変化への対応に必要なこと】
データ（情報）連携保証と変化への適応能力が必要になる。
そのためには以下の事項を実現する必要がある。
・システム構造が「疎結合」…データとアプリケーションの分離、モジュール化 など・データが保証され、データマネジメントが的確…データモデルで保証 など
・システムとデータのガバナンスができる組織・人材・スキルの確保と継承【データ（情報）の性質とその持ち方】
・企業の情報システムで保有されるデータ（情報）は、極力ビジネスの本質で体系化されている必要がある。
・体系化の手段として、普遍的なデータに着目して議論する「概念データモデリング」がある10。
・SoR と SoE に対応するものではないが、ビジネスで扱うデータには、スタティックなものとダイナミック
なものとがあり、両者は明確に分けて考える必要がある。
データには鮮度を価値とみなすダイナミックなデータと精度・信頼性を価値とみなすスタティックなデータがある（図表Ⅴ-11）。

10

概念データモデルには、関連する概念の集合体としてデータ要件の概要が取り込まれる。ここには、特定の領域や業務機能に関する基本的で重要なビジネスエンティティ（管理対象の実体）のみが含まれ、各エンティティの説明とエンティティ間のリレーションシップ（関連性）が含まれる。概念データモデリングとは、この概念データモデルを書くことを指す。（『データマネジメント知識体系ガイド第二版』より）
54

図表Ⅴ-11 データの持つ二つの側面

各企業の業態や置かれている環境にしたがってダイナミック／スタティックの面積は異なるが、どの企業にも存在する。
ビジネスで扱う情報がスタティック／ダイナミックかにより、対応策は大きく変化する。スタティック／ダイ
ナミックそれぞれに適したシステムの作り方の一例を以下に挙げる。
・ダイナミックなビジネス情報を扱うシステム→例）段階的なアジャイル
・スタティックなビジネス情報を扱うシステム→例）DOA
いずれにおいても POA(プロセス指向アプローチ)から DOA（データ指向アプローチ）への変換は不可
欠であり、システム開発を成功に導くためには、ビジネス上普遍的なデータに着目することが重要になる。
【情報（データ）の体系化】
企業活動に必要な要素は、厳密かつ柔軟に体系化されている必要がある。この体系化は、現時点の活動（アプリケーション）やテクノロジーをベースにしたものではなく、企業の本質で体系化される必要がある。
つまり、上記観点で抽象化された概念データモデル（データとその関連を示したもの）を備えることになる。
概念データモデルを作成する上で、ビジネスで扱うデータにも、スタティックなものとダイナミックなものとがあり、両者は分けて考える必要があることは前述した通りである。
さらには、きれいなデータを守り続けるデータガバナンス（データマネジメント）が、企業組織として有効な状態にあることが求められる。それにより、情報システムに求められる高度化の優先順位（迅速性か安定性か）を定め、実行できる。
一方で、徹底的な分散型でビジネス価値を実現する高度化の形もある（スピードが求められる中で、分散しているデータの必要な部分だけを直して使う方法）。高度化の方法・手段は一つではないことは考慮しておく必要がある。
どのような方法を用いようとも高度化を語る上でやはりデータモデルは避けて通れない。データモデルにおいては、概念データモデルの後に作成することになる論理データモデル* 11 と物理データモデル 12 は整合
11

論理データモデルは詳細なデータ要件が表現されたものであり、通常、アプリケーション要件のような特定の使用シナリオに適応する。技術や具体的な実装上の制約から独立している。論理データモデルは概念
データモデルの拡張として始まることが多い。（『データマネジメント知識体系ガイド第二版』より）
12
物理データモデルは詳細な技術的ソリューションを表す。このモデルは論理データモデルを出発点として作成されることが多く、そこからハードウエア、ソフトウエア、ネットワークツールを組み合わせた環境に適応するように設計される。（『データマネジメント知識体系ガイド第二版』より）
55

性を確保すべきである。論理モデルと物理モデルの整合性を確保していない場合、論理モデルの内容を保証できない物理モデルになっていることが問題になる。
データモデルに限らず、プロセスモデルをも包含した ERP のひな型があって修正するとデータモデルの影響度合いが全部わかるような仕組みがあれば、ERP のレガシー化に悩んでいる日本企業にとってはありがたいだろう。そのようなひな型が業態ごとにあれば、ひな型の組み合わせにより日本人らしいおもてなし
精神にきちんとついていける情報システムの構築が可能になるし、レガシー化の最大要因であるアプリケー
ションのソースコードがスパゲティ状態になることもない。そういった情報システム開発を可能とするプラット
フォームがあると日本の IT を活用した情報システム全体の底上げにつながる。理想論かもしれないが高度化への近道かもしれない。
このように考えるのは日本特有のおもてなし精神を反映することが情報システムの高度化を考える上で避けられないと考える故である。
日本のおもてなし精神を活かそうとすると、シングルタスクの寄せ集めではコストが高すぎる。多能工をうまく活かすことで初めておもてなし精神がシステム上成り立つ。マルチタスクを実現するシステムを実現する上でも高度化は大きな意味を持つ。
その際には、なんとなくこの人は「こんなことができるよ」ではなく、ロールはきちんと定義してあげなければならない。ロールを明確にすることで良い意味での多能工化が成立する。
「オールマイティ」ではなく「多能」なのである。全然違う仕事なのだけれどこれとこれをバックアップできる、というような人を支援するシステムが必要になる。これも日本ならではの高度化が必要とされる一因である。

Ⅴ．3．2 SOR と SOE
SOR と SOE の違いはシステム構造ではなくスコープの違いであり、その境界は曖昧である。ビジネス価値を高めることが、両者に共通する本質的な目的であり、システムライフサイクルを全うするシステム（SOR）と、その瞬間のビジネス価値を高めるシステム（SOE）とを共存可能とする仕組みを、高いレベルで実現できることが、「システムの高度化」である、とも考えられる。経営者としては戦略・合目的性も内部構造もスピードも求めたくなる。それらを上手に束ねられることが求められる。
SOE は戦略適合性を優先しがちだが、たとえば SOE で取得した口コミと、自社の顧客リストとが紐づかないと商品開発には役立てられない。その紐づきはプロセスではわからない。データモデルでしか認識できない。
SOE はエンゲージメントさえできて、ある程度の戦略適合性があればよいのかもしれない。ただし、SOEを作っただけでは、企業の競争優位性は担保できない。経営への説明や経営判断を導き出したり、企業価値を高める情報が取り出せなければならない。
SOR であろうと SOE であろうと企業の競争優位性は「データ」に左右される。「データ」の価値を最大限に大きくする情報システムこそが企業の競争優位性に寄与する。

56

Ⅴ．3．3 トップダウンとボトムアップ「高度化」を、違った視点から考えてみる。例えばシステムをアップグレードしていく話と、データをどう活用するかの話は別の話ではあるが、システムを使う側に問題があるとうまくデータを活用できないから、両者は両輪の話であるといえよう。
「高度化」が必要とされることの意味の中には、「システム技術的な」ことというよりは、「意識」や「文化」が育ちきっていないという、むしろ人間的な話が大きなウエイトを占めるのではないかという問題提起がある。
文化、意識における高度化が技術的な高度化と併行して必要である。
その際に大切なのはインテグリティである。トップダウンは楽であるがボトムアップであってもインテグリテ
ィが担保できれば良い。ただ、現在の日本の情報システムの現場においてはボトムアップの現場の声が公平に吸い上げられているかは疑問がある。
声の大きい人の意見が反映されがちでそれが例外処理の組み込みにつながることもある。無用な複雑化を仕様として取り入れることにより、レガシー化が始まる。そうならないためには声の大きさでインテグリ
ティが覆されないボトムアップの仕組みがあるとよい。
トップダウンでシステム化した場合においても、新しい情報要求が生まれてシステム改修する場合にはミドルアップになる。データをうまく捉えられている会社では、データモデルを軸として常にビジネスを考えているため、ミドル層の情報要求にブレがなく、このようなサイクルがうまく回る。そのためにはデータモデルから整合性が一目でわかることが重要である。

Ⅴ．4 持続的競争優位性を保持するためにシステム高度化のために実行すべきことは何であろうか？以下に考え得る事項を記述する。
1.

自社の「現在」と「将来」の競争優位性の定義

2. 競争優位を創出・維持する事業機会の発見
3. 競争優位に組み込む「仕組み」としてのシステムの役割定義
4. 構造投資：「システム機能への投資」ではなく、「システム構造改革への投資」
変化に素早く対応するための IT 変更リソース（人員・工数）の捻出・確保も含む
・運用工数削減（RPA を活用した IT 運用付帯業務の効率化など）
・さまざまな外部リソースの参入を可能にするアプリケーション構造や開発言語（オープンソース化など）
5. 常に成長・変化し続けるシステムへ：「完成したシステム」を稼働させることから、「ずっと作り続けるシステム」を稼働させることへと考え方をシフト
6. 企業組織のあり方に適合したアーキテクチャー、方法論
企業活動（アプリケーション）が変化するとシステム（要素の体系）も変化する場合がある。システムが変化しない場合もありうる。ただし、アプリケーションは必ず変化する。その場合、変化点を可視化された体系（概念データモデル）、つまりデータ軸で捉える。変化をアプリケーション軸で捉えると、次の変化、その次の変化へのスピードが叙々に遅くなる。これは要素の体系化が崩れていくためである。
7. データガバナンス（マネジメント）の徹底と保守
8. 多様な企業・団体外と接続・連携可能なオープン化（国際標準への準拠など）
57

9. ビジネスと IT を橋渡しできる人材（CIO）や組織の設置
10. 組織改革
例：マイクロサービスを前提とした DevOps を可能とし「迅速性」（革新）を求める組織と「安定性」「正確性」（安定、効率）を求める組織、それを統括するデータマネジメント組織を整備する。
11．必要な人材の育成

Ⅴ．5 高度化における課題と解決策
Ⅴ．5．1 課題と解決策
以下に高度化における課題と解決策を記述する。
（1）サイロ化されたレガシーシステムの問題「JUAS デジタル化の取り組みに関する調査(2017）」によれば、約 8 割の企業がレガシーシステムを保有し、約 7 割の企業がレガシーシステムがデジタル化の足かせになっていると回答している。
サイロ化されたレガシーシステム、分散化されたデータベースは、企業全体を鳥瞰し体系化されたシステ
ムが可視化（データモデル化）されていなかったか、それを無視したかのいずれかが原因である。個別最適が企業の競争力を生み出していた時代には有効であったが、データ連携には不向きな状態といえる。
＜解決策＞
変化を体系化された要素であるデータで捉え、アプリケーション軸に重きを置かないようにする。データ
モデルは企業全体を鳥瞰し、体系化された要素とその関連なので、これを無視した変化は柔軟性と迅速性を損なう。上記をきちんと理解した上で対応をとっていく。
・「統合」から「分離」へ：大きなシステムを作らず、小さなシステム・機能群へ小分けする。
どの単位で分離するかは「変化のタイミングが異なる領域」ごとに分離を基本とする。
・API 化：社内外のデータ・機能を組み合わせられるように、個別機能を API 化する。その際、全社レベ
ルでの API 化の統制を行い、主管部門の組織化とガバナンスを徹底する。
・紐づけ：社内外のデータを紐づけて顧客理解とサービス提供ができるように、「お客さま」や「契約」の紐づけを行う基盤と業務を用意する。この場合、「紐付け」の方法を確立する必要がある。キー体系のあり方などを検討し、紐付け業務を確立していく。
・緩衝層：SOE と SOR の世界の相互影響を最小限にする緩衝層を用意する。緩衝層のスコープ・設計
方針を確立し、アーキテクト集団による検討を実施する。

（2）分散化しているデータベース問題
個別最適重視であったシステムとともにデータベースもサイロ化・分散化している。そもそも自社・グループ内に存在するシステムとデータに、どのようなものがあるかが不明な場合が多い。
＜解決策＞
・主要なシステムとデータとそれらの関連（疎／密結合）を棚卸しし、台帳化する。
58

・DMO（データマネジメントオフィス）を組織化し、データガバナンスを実現可能とするデータマネジメントを実施する。
・データ連携のスピード重視で、分散化しているデータベースを塩漬けにして活用する解決策もある。

（3）ビジネス（企業活動）として「やりたいこと」「やらなければならないこと」が不明確で、システム・データ資源の活用戦略が不在
As-Is と To-Be ビジネスモデルに適した活用戦略を作り、求められる仕組みや品質、構造を設計できて
いない。
＜解決策＞
・企業活動の To-Be を不明確と捉えるのではなく、スタティックな To-Be を描くことをやめ、To-Be は変化し続けることを前提にすると世界感が変わる。したがって、情報システムも、ずっとスタティックなシ
ステムと、ダイナミックに変化するシステムとの 2 局面があり、後者は完成することなく常に成長・進化し続ける前提で設計していく必要がある。また、To-Be がスタティックな企業活動を支援する情報システ
ムは、実ビジネスの写像の役割が主で、経営戦略に基づいて情報戦略が存在する構図であったが、To-Be がダイナミックに変化する中においては、情報戦略そのものが経営戦略となりうる。
（4）経営層やユーザー部門の理解の問題
ROI が見えづらく投資や現場の理解が得づらい。
＜解決策＞
・危機感と効果とをビジネスの言葉で IT 部門から発信するとともに、業務改革やセキュリティポリシーによるシステム更新のチャンスを逃さずに高度化へ向けた取組みを埋め込む。

（5）システム高度化を推進・実施する IT 要員・スキル・工数確保の問題
守りの業務（運用・保守）に追われる「運用ロックイン」状態にあり、攻めの業務に振り向けられない。
＜解決策＞
・「データマネジメント」を実現可能とする人材の知識・スキルの育成または調達。
・社外・社内のリソース（人・機能含め）は自前で全部グリップできないのを前提として、うまくつないでいく。システムをオーケストレーションする、ハーモニナイゼーションするほうが日本の風土に合っているのではないか。

Ⅴ．5．2 課題と解決策（まとめ）システム高度化に向けた現状の課題解決には全社的アーキテクチャーの構築とデータガバナンスが有効に機能するデータマネジメントの実現が重要である。システムには、ダイナミックなシステムとスタティックなシステムという、両立すべき二つの系がある。そのいずれにも共通するのがデータモデルであり、データモ
59

デルに基づいた持続的データマネジメントが重要となる。
迅速性（ダイナミックなシステム）と安定性（スタティックなシステム）の両立を可能とするアーキテクチャー（拠り所）を構築し、データマネジメントの観点から「分散」と「集中」のめりはりをつける。「分散」は「迅速性」に、「集中」は「安定性」に対して効果を発揮する。現状を把握した上でシステムにより求めるべき方向を定め、進めていく必要がある。
計画及び計画と実績との差異分析、差異が生じた場合は、計画変更しながら、大きな方向性は変えずに、進路を定めて進めていく。
これらの実行のためには、経営層やユーザー部門の理解を得るための情報発信を IT 部門から行うとともに、システム更新時に高度化に向けた仕組みを埋め込むチャンスを逃さない企画力を養う必要がある。
そのためにデータマネジメントなどの知識・スキルを養うとともに、社内外のリソースをうまく「オーケストレー
ション」する能力（組織）が求められる。

Ⅴ．6 いかに高度化するか
実際に高度化を実現するために必要な事項、意識すべき事項について、次章以降に具体的に記述していく。
本書では、従来のように「日本は駄目、欧米（特に米）が全て正しい」といった偏った論調に楔を打ち、欧米の真似ではなく日本だからこそ実現可能な情報システムの高度化について議論した結果を記述し、停滞している日本の情報システムに一石を投じたいと考える。本章にて多面的な高度化のあり方を記述した。
以降の章で、変えてはいけないものと変えなくてはいけないもの、データの大切さ、更に大切なデータを生
かすデータモデル、EA（アーキテクチャーの重要性）、変化への対応、それを実現する IT 部門の役割、マネ
ジメントに求められることを明らかにした上で高度化のゴールともいうべきデータ経営と今後のあるべき姿にふれていく。

60

Ⅵ章 継承すべきものと刷新すべきもの
三輪 一郎
本章のサマリー 「データ」は、財務会計制度では捉えられていない、重要な無形資産である。
 継承すべき「データ」が認識出来れば、それを得るための手段である「アプリケーションや IT インフラ」は選択・改廃が可能な手段となり、システムを柔軟にできる。
 継承すべき「ナレッジ」の見える化は、「概念データモデル（データ設計図書）」で行う。
 アーキテクチャーは、「データをアプリケーションから分離した構造」に刷新する。
 方法論は、データを知識や知恵にして経営の価値を高め、ビジネス変革につなげる DOBA（Data Oriented
Business Approach）の考え方で、アジャイルにもウォーターフォールにも対応できるアプローチに刷新する。
 組織と人材は、データ分離アーキテクチャーを維持し DOBA 方法論を使いこなせる体制を維持する。
 「概念データモデル（データ設計図書）」を最新の状態に維持し続けることが、DX の基礎となる。

本章では、情報システムの高度化に向けて、継承すべきものと刷新すべきものについて論じたい。
企業が継承すべきものは何だろうか。それは「データ」と「ナレッジ」である。すなわちその企業が辿った歴史の「記録」であり、集った人が蓄えた「業務知識」である。情報システムに蓄積されたデータとナレッジは、IT 部門が預かり蓄えた、継承すべき無形資産である。
そこで本章では、「データ」と「ナレッジ」というキーワードで、継承すべきものを論ずる。また刷新すべきものとして「データマネジメント環境」に着目し、データとナレッジを継承しつつ、新たなビジネスを創出し続けるため企業システムの「アーキテクチャー」と「方法論」を取り上げる。
また、随時刷新すべきものとして、概念データモデルを最新状態に維持することを挙げる。

Ⅵ．1 継承すべき「データ」と「ナレッジ」
本節では、「データ」と「ナレッジ」というキーワードで、継承すべきものを論ずる。

Ⅵ．1．1 データの継承
継承すべき IT 資産の価値は、正しく認識できているだろうか。
現在の財務会計制度では、IT 資産の価値は測れない。計上対象は、「アプリケーションシステムや IT インフラ」だけだ。これを製造業になぞらえれば、生産設備や輸送設備だけ。重要な資産である材料や製品にあたるはずの、「データ」が漏れている。
「データ」の例として、取引実績データについて考えてみよう。BS／PL に直結する事実の記録である。計上基61

準が変わってしまうと、会計の継続性が保たれないだけでなく、経営判断も誤ってしまう。創業以来の売上高や、お得意様との取引の歴史が正確に記録できていないということは許されない。
上記に限らず、あらゆる業務はデータを残す。それは自部門、自社、自国のためだけではない。データは記録され、伝達されて、次工程や他部署、時には得意先や仕入先、同業他社や他国にも連携される。財務データに基づく会計報告に誤った記載があってはならず、同時に継続性が求められる。安定した財務会計基盤は、企業存続の必須条件である。
今や、周辺他社・他国とのサプライチェーンの確立が企業活動の前提である。連携する取引データは、自社の都合や思い付きで変えられるものではない。自社の組織やプロセスは変えることができても、取引データとその品質（定義）は、今後も保証し続けなければならない。
我々は、システムの実装環境をホスト（メインフレーム）からクラサバ、オープン系、クラウドへと、次々に変化させてきた。UI やプログラム言語も同時に変化し、伝達手段も口頭、郵便、電話から、FAX、VAN、インターネッ
トへと変遷した。だが伝達している「データ」は変わらない。むしろ、いかにデータを変えずに新しい手段に移行するかに注力してきた。
基幹システムという器が形になる以前から、我々が守り、引き継いできたのは「データ」だった。IT の世界で、材料や製品に当たる「データ」は、いくら貯めても課税されず、コピーをしてもなくならない無形資産である。
GAFA の企業価値には、多様な手段で収集した「データ」の価値が色濃く反映されている。上記のような取引データに限らず、ソーシャルデータのような非構造データも併せて収集し、これらをすべてビジネスに活かしている。
最近になって、コンビニのレジから「年代・性別キー」が消えた。多くのデータに、押しやすい位置のボタンのデータが記録されていたためである。経営判断に必要な、購買記録ごとの購買者層というデータは今、会員カードの属性から取得している。求めるデータが明確であれば、データを得るための手段は新たなものを選択できる。
今や、継承すべき IT 資産の中心は「データ」である。「アプリケーションシステムや IT インフラ」は、ビジネスが求める「データ」を得るための、選択可能な手段だ。
デ ー タ 資 産 を 継 承 し 、 デ ー タ を 中 心 に 新 た な ビ ジ ネ ス 戦 略 を 発 想 す る ア プ ロ ー チ が DOBA （ Data
Oriented Business Approach ）であり、データドリブン経営を支える。戦略が求める新たなデータを見定
め、そのデータを得るために最適な手段を選択することが IT 戦略の立案であり、DX へのアプローチなのである。

Ⅵ．1．2 ナレッジの継承
あらゆる組織は、その継続のために、蓄積したナレッジを継承する。
以前聞いた、ある銀行の基幹システム統合後の講演では、一定期間の後、意図的に基幹システムの再構築を行い、ナレッジを継承したという。これは、日本各地に伝わる「式年遷宮」の儀式を想起させる。IT の領域においても、ナレッジの継承を行う価値は一部で既に認識され、実践されているものと考えてよいだろう。ただしまだ、
62歴史の浅い情報システムの分野においては、業務知識をブラックボックス化させたレガシーシステムを作り上げてしまった旧来のノウハウを、継承すべきナレッジだと認識しているきらいがある。これは大きな誤りといえるだろう。
ナレッジの継承に際して我々に求められるのは、既存のシステムから業務知識を取り出して見える化し、改修可能な形で継承するノウハウである。
（1）「概念データモデル」による業務知識の見える化
決算数値の確からしさすら、今や検証できない企業があると聞く。一部の EXCEL エキスパート社員や IT ベンダーに任せ過ぎた代償として、重要な「業務知識」がシステムに埋め込まれたままブラックボックス化してしまったためだ。
では改めて見える化し、継承すべき業務知識とは何か。
継承すべき業務知識は、顧客との取引実績データに基づく値引き率計算のロジックや、物流ルートにおける輸送手段選定の条件式、商品・部門毎に異なる正確な利益率計算のロジックや、経営が意思決定に用いる数値の計算式や判定式など、経営のためのナレッジだ。これは結果として、得るべき「データの要件」として定義される。EXCEL の操作手順やハンコの押印順序などは「プロセスの要件」だ。変わりゆくツールの操作方法や業務の実施手順に、継承すべき価値はないだろう。
継承すべきナレッジは、「データの要件」として取り出すことができる。ところがレガシーシステムでは、プロセスとデータが分離されていなかった。そこで、システムに埋め込まれた重要なビジネスルールを継承するために、継承すべき「データの要件」と、移ろいやすい「プロセスの要件」を分離して棚卸しする。
New-Oil と言われて久しいデータについて考えてみる。原油は、精製により種類と量が明らかになる。データを精製する、すなわち意味的なデータの要件を整理する方法は「正規化」である。扱うデータを正規化した上で、「概念データモデル（データ設計図書）」を用いて「データ要件」を定義すれば、種類も量も、見える化できる。
また「データの要件」は、システム開発の工程に対応して、概念データモデル、論理データモデル、物理データモデルで定義される。中でも、データの「意味」と「その関連」を表現した「概念データモデル」が最も重要である。
それをプロジェクトの初期に作成し、データ設計図書として活用していく。
「概念データモデル（データ設計図書）」は、「E-R 図」、「エンティティ定義書」、「データ定義書」で構成される。
図表Ⅵ-1 概念データモデル（データ設計図書）の構成「概念データモデル（データ設計図書）」の構成
・E-R 図・エンティティ定義書
・データ定義書63

【E-R 図】
「概念データモデル（データ設計図書）」の筆頭に挙げられる「E-R 図」は、コンピューターの内部構造を表す
図ではない。自社にはどんなデータがあり、どのような単位でどこに記録されているのかを示す、“データ資産管理のための地図”である。
図表Ⅵ-2 E-R 図の例（図中の箱がエンティティ、データ項目はその中に列挙する）

作図時にはまず、管理すべき対象を表す「エンティティ」を四角い箱で書く。エンティティの名称を箱の表題として添え、箱の中に「データ項目」を列挙する。エンティティ同士の 1:n の関係を表す「リレーションシップ」は箱と箱を結ぶ線で描き、1:n の n 側に●印を付ける。この事例のように、関係の意味を書き添える場合もある。
「E-R 図」には、代表として挙げた E-R 図法の他にも、TH モデル、T 字モデル、IDEF1X など複数の記述方法が存在するが、基本要素は共通している。
（記述方式の詳細は、各種ガイダンスが発行されて64

いるのでそちらを参照されたい。）
継承すべきナレッジとしての「E-R 図」に求められる要件として、「可読性」を挙げておく。企業あるいは特定の事業単位で管理すべきデータの全体像を表現すると、エンティティは数百になり、データ項目においては千のオーダーになるからだ。
「可読性」に直結するのは、図法の選択ではない。エンティティの配置ルールだ。筆者が推奨するのは、TH モ
デル由来の図表Ⅵ-3 に示す配置ルールである。リソース系（マスター系とも呼ばれる）とイベント系（トランザク
ション系とも呼ばれる）のエンティティは上下に分離して配置し、リソース系とイベント系の領域をまたぐ線は表
記を省略する。また、リソース系のエンティティとイベント系のエンティティはそれぞれ、下図のようなルールで配置する。（図表Ⅵ-2 の事例ではさらに、配置領域を示す補助枠を赤文字・赤枠で書き添えている。）
図表Ⅵ-3 エンティティの配置ルール

リソース□ 社内組織□ 社外組織

□ 物

□ その他

大

大

大

大

小

小

小

小

◇ 各種関連リソース

イベント■ イベント親
発生順子

可読性を高めておけば、作図した本人以外でも目的とするエンティティやデータ項目がすぐに見つけられる。
データ資産を継承する歴代の担当者は、追記・修正しても迷うことなく維持更新ができる。

65

【エンティティ定義書】
例えば、社員を管理する目的は何か。社員番号で管理される社員に、出向社員や役員は含まれるのか。初期の採番は誰が行うのか。それは応募時なのか入社時なのか。再入社した社員には新しい番号を与えるのか、旧番号か。退社時の扱いや開示範囲はどう定めるのか。「エンティティ定義書」は、こうしたナレッジを継承するために役立つ。
図表Ⅵ-4 エンティティ定義書の例

エンティティ定義書
エンティティ番号
エンティティ名称

FD－01000
社員

定義者
承認者
更新者
エンティティの種類
スーパータイプ/サブタイプ

(カナ)

シャイン

○○ ○○
○○ ○○

定義書作成日
定義書承認日
最終更新日

20XX.6.25
20XX.6.29

リソース
-

独立/従属
責任部署

独立
人事部（部長）

意味/目的
管理対象範囲当社に在籍する社員の個人データを管理する。
社員とは，役員および従業員を指し、出向者を含む。
在籍する社員を一意に識別し、人材配置の検討と勤務形態 一時雇用者及びパート・アルバイトを除く。
に基づく休養計算※など、人事にかかわる業務遂行のために用いる。
加えて、役員であるか否かや出向元の確認にも利用する。
※役員は役員規程を適用。出向者は、出向元会社の給与計算ロジックを適用する。
ライフサイクル（発生～消滅のタイミング）
新卒・中途の応募を経て、内定通知時点で発生（「FD01090：採用候補者」から抽出）する。
退職後も、一定期間は保持する。

構成データ項目
データ項目番号データ項目名称
DD-00100
社員番号DD-00101
社員氏名
DD-00102
入社年月日
DD-00103
所属部署コード・・・

セキュリティ要件
社外秘。参照は社内のみ。
社内全部署：役員/社員/出向社員区分、氏名、郵便番号、
勤務地コード、メールID
人事部内・部長職以上：その他項目を含む全項目※退職後は人事部内のみ
登録・更新には、人事部、課長職以上の権限が必要。

Key構成
主Key

F-Key

・
・
・

参照エンティティ

FD-01300

部署「エンティティ定義書」を使って、企業が管理する資産としての説明、すなわち、エンティティを管理する意味/
目的、範囲やライフサイクル（発生／更新／消滅する場面）などを詳しく見える化する。

66

【データ定義書】
データの品質を保証するためには、利用者（情報システムのユーザー）視点でのデータの説明が最も重要である。「データ定義書」は、そのデータ項目が属するエンティティの意味／目的を引き継ぎつつ、コード体系や発番／廃番ルールを明示し、全社的に共有するナレッジとする。取り得る値を例示しておくことも重要だ。
図表Ⅵ-5 データ定義書の例

データ定義書
管理番号
データ項目名DD－00100
社員番号

定義者
承認者
更新者
データタイプ定義域(カナ)

シャインバンゴウ

○○ ○○
○○ ○○

定義書作成日
定義書承認日
最終更新日

20XX.6.25
20XX.6.29

指示
コード

基本/加工

基本

意味/目的
当社に在籍する社員を一意に識別するための番号。
社員とは，役員および従業員を指し、出向者を含む。一時雇用者及びパート・アルバイトを除く。
データ形式
参照データ
Null値可/不可

数値
－
不可

数量単位

コード説明
コード体系

入社年度(西暦4桁)＋連番(4桁)ー

発番/廃番ルール

上4桁は入社年度（西暦4桁）、下4桁は年度内連番（0001～9999）。
人事部により内定通知時に採番され、退職後も保持する。欠番の転用は行わない。
再入社する社員が発生した場合は、旧番号を引き続き利用する。

値の上限/下限
列挙値

連番は0001から始まる“20210011”、“20220101”

こうして「概念データモデル（データ設計図書）」は、ビジネス部門とシステムの専門家が共通理解を得るための、有効なコミュニケーションツールとなる。
近年の企業システムでは、連携すべきシステムが増え、取得すべきデータ、管理すべきデータが増えている。
しかし旧来は、サイロ型システムの弊害として、データ定義がばらばらに乱立しているという問題があった。
例えば、同じ「社員番号」でも、人事システムでは「入社年度+連番」、営業成績管理システムでは「支店番号+連番」といったように番号体系が違ったり、支店によってはアルバイト店員も登録しているなど、今までは、「データの品質」がバラバラだった。そのため、システムを連携させようとするたびに、読み替えと変換が必要だった。
管理すべきデータが増えているのに品質がバラバラでは、活用はおぼつかない。それを見える化し、まとめていくのが「概念データモデル（データ設計図書）」である。エンティティとデータ項目の定義ができていれば、デー
タの「品質」が保証できる。全社レベルで定義書を共有するアプローチをとれば、構築時期も適用するツールも開発ベンダーも異なるシステムを相互連携させることができるようになり、拡張も容易になる。
こうしてプロセスとデータを分離し、データ中心の「DOBA：Data Oriented Business Approach 」で、継承すべきナレッジを明らかにする。このようなアプローチに挑戦することを、強くお勧めする。
67

（2）【コラム：既存データの継承（データ移行）】
他システムとの連携を意識しない「閉じた領域」でスマートフォンやタブレットを活用するだけのシステムを開発するのであれば、サイロ型の情報システム化で培った過去のノウハウだけで十分である。だが今は、連携すべき既存システムと、継承すべき既存データがある。求められるのは、新たなデータを既存システムに蓄積されたデータと連携可能な形で加え、事業を継続しながらビジネスを拡張していくノウハウである。
データ項目を既存のデータ構造にどのように加えるのかは、「概念データモデル」を使ってプロジェクトの初期に検討する。またどうやって既存データを新システムに移行し、新データと連携させるかを検討するタス
クも、同時に実施する。そのために、既存システムの中に埋め込まれた業務知識を「概念データモデル」を使って見える化し、データ項目を定義する。この定義書を新たな IT 領域を担当するベンダーとも共有し、既存システムとの連携を図る。これにより、ビジネスを止めずに、新システムへの継続的な移行を実現する。
このノウハウは、改修や延命の経験からは得られない。規模の大小にかかわらず、ゼロから一通り全てをこなす生みの苦しみの経験や、新たな要求を理解してデータ構造に組み込むノウハウである。
「概念データモデル」を用いたデータ中心型ビジネスアプローチ（DOBA：Data Oriented BusinessApproach）により、プロジェクトの初期にデータ資産を継承する（データを移行する）方法を議論すること
で、ビジネスの継続性とシステムの拡張性が得られる。

Ⅵ．1 では、「データ資産（既存システムのデータ）」と「ナレッジ（E-R 図と定義書）」の継承を謳った。継承すべきは「データ」と「ナレッジ」であり、品質を保証する「概念データモデル（データ設計図書）」である。これらの継承を、システム高度化の必須事項として認識していただきたい。

Ⅵ．2 刷新すべき「データマネジメント環境」
本節では、データを重視し、継承するための「データマネジメント環境」に着目し、刷新すべきものを議論する。
企業システムの「アーキテクチャー」と「方法論」に加えて、これを支える「組織・人材づくり」についても触れる。
情報システムをマネジメントするということは、経営における情報システムの価値を認識・評価し、維持・向上
していくことである。すなわち、情報システムの価値を保証しつつ、より高めていくことである。
情報システムの価値は、「アプリケーションシステムや IT インフラ」だけでなく、内包した「データ」の価値との和であろう。内包物であるデータと器であるシステムは分離して認識し、管理しなければならない。そのための「アーキテクチャー」は、データがプロセスから分離されたものでなければならない。
また情報システムは、いつまでも同じ形であっては価値が逓減する。経営環境の変化にシンクロして常に進化させることで、価値を維持・向上する。そのための「方法論」は、データを中心に置いて継承しつつ、システムを柔軟に変化させ得るものでなければならない。
またこれらを支えるには、データ中心のノウハウを承継していく組織・人材づくりが重要である。
そこで我々は、情報システムの価値を高める環境を「データマネジメント環境」であると捉え、アーキテクチャ
ー、方法論、組織・人材づくりの 3 点から考察する。
68

図表Ⅵ-6：情報システムの価値を高めるデータマネジメント環境

情報システムの価値を高めるデータマネジメント環境
1.プロセスからデータを独立させるアーキテクチャー
2.データドリブン経営のためのデータ中心（DOBA）の方法論
3.データ中心（DOBA）の組織・人材づくり

Ⅵ．2．1 プロセスからデータを独立させるアーキテクチャー
情報システムの価値を高める「データマネジメント環境」が要求するのは、既存データの継承と連携を保証しつつ、新たなビジネスモデルに対応できる柔軟な拡張性を持ったアーキテクチャーである。「データ」を「アプリケーションシステムや IT インフラ」から分離したアーキテクチャーに移行することで、データを継承しつつ、新たな機能や機器の追加改廃が行える環境を構築する。
システム化の初期の段階を支えたガイドでは、システムの要件は固定的に捉えられ、変化への対応は意識されていなかった。そのため、個々に設計した画面の項目からデータベースを作るといった手法が一般的であり、データはその画面（アプリケーション）の従属物になっていた。
欧米では、「アプリケーション領域（AA 層）」から「データ領域（DA 層）」を分離するモデル（図表Ⅵ-7 の中央）が提唱され一般化したが、日本では、初期の成功体験に基づく従来型のガイドに従って、すべての要素を固定的に定義することを是としてきた。その結果、AA 層が DA 層を内包し、「全体を一体で固定する（要素が独立していない）モノ」になっていた（図表Ⅵ-7 の左側）。構築されたシステムは強固になったが、機能や機器の追加改廃が自由に行える“柔軟なシステム”という命題を果たせなかった。
そこでまず、欧米で先行したデータ分離の思想を取り入れ、さらに、建築業界が地震の多い日本で高層ビルを実現するために、剛構造から柔構造にアーキテクチャーを進化させた発想をアナロジーする。
アプリケーション領域（AA 層）に内包されたデータを「概念データモデル」で描き出して分離した上で、DA 層を心柱に見立てて堅牢に設計し、AA 層や TA 層に柔軟性を持たせる、柔構造への切り替えである。
目指すべきビジネス・モデル（BA 層）をデータ（DA 層）で写し取り、これを実現するアプリケーション（AA 層）
やインフラ（TA 層）を手段として分離し組み合わせる、3.5 層のアーキテクチャー（図表Ⅵ-7 の右側）を採用することで、システム全体を柔軟な構造に移行する。

69

図表Ⅵ-7 データ内包型からデータ分離型へ、さらに日本型 EA モデルへ
EAモデル
（日本の現状）ビジネス
領域

情報システム領域

ITインフラ領域

EAモデル（欧米の認識）

BA

BA

AA

DA

DA

AA

TA

TA

日本的発想に基づく
3.5層のEAモデル

ビジネス
領域

BA
DA
TA

AA

データ
領域
アプリケーション領域
ITインフラ領域

これは、ビジネス領域のユーザーがデータ管理者と直接接点を持ち、「概念データモデル（データ設計図書）」を共有することにより、画面などのアプリケーションを介さずにデータの意味と構造を理解できるようにすることで実現できる。
DA 層が AA 層から分離できていないとどうなるか。例えば、E-コマースサイトを新たに構築したものの、データの形式が合わずに既存システムとつながらない。結果、多大な手作業と改修費用が必要になった。これは典型的な、つながらない SoE の事例だ。
図表Ⅵ-8 つながらない SoE「概念データモデル」で連携に必要なデータの意味と構造を切り出し、SoE 開発ベンダーと共有しておけば、
スマートフォンやタブレットで生成した受注データをそのまま既存の SoR に連携して活用することができる。新
たなデータの取込み口が確立すれば、SoR 側にあった受注機能を SoE 側で全面代替するなど、データ（DA 層）を継承しつつ、AA 層／TA 層の入れ替え（既存システムの改廃）ができる。

70

図表Ⅵ-9：柔軟なシステム構造（概念データモデルの共有により、AA 層、TA 層の入れ替えを可能にする）

こうして「BA 層と DA 層」を実装システムから分離した新しいアーキテクチャーに移行することにより、レガシ
ー化した既存システム（「AA 層と TA 層」）を柔軟に改廃できるようにする。
（3.5 層の日本型 EA モデル応用の考え方は、Ⅺ章で解説する。）

Ⅵ．2．2 データドリブン経営のためのデータ中心（DOBA）の方法論
情報システムの高度化において、新たな方法論に求められるものは何だろうか。
過去においては、「一体として完成された“モノ”としてのシステム」を、効率的に構築するための方法論が求められた。
だが今、経営に求められるのは、「データ」を「アプリケーション」から分離することで部分的な改廃が容易に行える、「柔軟な構造体としてのシステム」を、効果的に刷新し続けるための方法論である。
経営(BA)を直接支える情報資産は「データ(DA 層)」である。
SoE や IoT、SNS などは、新たに拡張された「データの入口」であり、これらの「アプリケーションシステムやIT インフラ（AA 層や TA 層）」は、得られたデータを変化・遷移させ、データドリブン経営の指針となる「データを得るための手段」である。
データが知識や知恵になって経営の価値を高め、ビジネス変革につなげる新たな方法論に必須の条件は、DOBA（Data Oriented Business Approach）によって、堅牢なデータ（DA 層）を中心とした見える化ができ、AA 層／TA 層が柔軟に改廃できる（レガシー化しない）アーキテクチャーを実現することである。
71この方法論には、ビジネスモデルの変化にシンクロするスピードが求められる。重要なのは、どんなスピードが求められた場合も、データを中心に置いてアプローチできることだ。
変化が常態化した現在の経営環境で、企業を支える IT の領域に見直しが求められるタイミングは不定期化している。昨今のアジャイル開発手法は、ビジネスの変化が非常に激しい場合に備え、ウォーターフォール型方法論よりも俊敏にアプリケーションシステム（AA 層／TA 層）を作り替える方法として登場した。ただし、企業のビジネスモデル変革の周期や頻度に応えることを目的とするのであれば、あらゆる場合にアジャイル開発手法が必要になるとは限らない。再構築の際、スピード偏重でデータの見える化をないがしろにしてしまうと、「新品のレガシーシステム」が出来上がってしまう。これでは、システムを進化させ続けることはできない。
フィードバックを得るための試行錯誤の段階など、急いで作るシステムはアジャイル開発手法でスピーディに提供するが、時間をかけることが許される場合はウォーターフォール型手法でしっかり作って長く使う。そしてそのどちらの場合にも、データ中心型の DOBA アプローチができる方法論を持たなければならない（求められる方法論の詳細は、Ⅹ章・Ⅺ章で解説する）。

Ⅵ．2．3 データ中心（DOBA）の組織・人材づくりシステムの高度化を支える IT 組織は、企業戦略やビジネスモデルの変化に関する情報を早期に捉え、組織改変やリテラシーの向上スピードに合わせて既存システムを進化させ、情報システムの価値を高めていく必要がある。そのために、データ中心のアーキテクチャーを守り、育てながら、システムの重要性に照らして生産性とのトレードオフを見据え、アジャイルかウォーターフォールか、あるいはその組み合わせかを判断して実行する。
企業の IT 部門がデータ中心の方法論を使いこなし、新たなアーキテクチャーの上でプロジェクトをやり遂げる実力を持つことが必要である。我々はこれを「データ中心(DOBA)の組織・人材づくり」の要件として、以下に整理した。
図表Ⅵ-10 「データ中心(DOBA)の組織・人材づくり」の要件「データ中心（DOBA）の組織・人材づくり」の要件(1)データモデリングスキルを持った人材の育成と維持(2)データ中心型アーキテクチャーを維持する組織（1）データモデリングスキルを持った人材の育成と維持
本書で我々が重視するスキルは、「データモデリングスキル」である。データモデリングスキルの内訳には、以下の 3 点が含まれると認識して欲しい。
・データの抽象化・正規化スキル・ビジネスと業務（データを発生・変移させるプロセスを含む）の知識
・概念整理＆命名のスキル
DA 層は、ビジネスと IT をつなぐ位置にあって、システム全体を安定させる心柱となる。新たな人材には、ビ72

ジネスルールの骨格を表すためのツールと認識して「概念データモデル（データ設計図書）」を書き上げ、これを使ってユーザー部門の方と新たなビジネス像を共有できるスキルが必要だ。
そのためには、教科書に載っている「データの抽象化・正規化スキル」だけでは物足りない。ユーザーが話す
業務の説明やその意味を理解するための「ビジネス・業務の知識」も前提になる。だが、それだけではない。三つ目のスキル、「概念整理＆命名のスキル」が必要である。
そこで、一般にも知られる一つ目と二つ目のスキルの解説は他に譲り、最重要と思われる三つ目のスキル、「概念整理＆命名のスキル」について解説する。
典型的な例は、「取引先」を「得意先」と「仕入先」に分類するスキルだ。販売システムにも購買システムにも「取引先マスター」があり、両システムの担当者はどちらも「取引先」だと主張する。だがそれぞれに登録されているのは「得意先」と「仕入先」だった。そこで「取引先」は、両者の総称とした。
別の例も挙げる。「お客様平均年齢」の値が合わない。チケット販売部の試算と会場アンケートの結果が合わないのだ。同じ「お客様」といっても、チケット購入者本人が来場するケースもあれば、親名義で買ったチケットを持った子供が来場する場合もある。「お客様」には、二つの意味があったのだ。この例では「お客様」を、「購入者」と「来場者」に分けて別々に命名・定義し直した。二つの計算値には改めて、「購入者平均年齢」と「来場者平均
年齢」という名称を与え、共有した。
予約語問題で命名に苦労することもある。「予約語問題」とは、特定の用語がその組織特有の慣用句（予約語）になっていて、語句本来の意味と別の意味になってしまうために使えない、という問題である。
ある組織では、数日程度の作業をプロジェクトと呼ぶことが慣例化しており、本来の規模（数か月以上の期間を要する活動）の管理をルール化する際、プロジェクト管理という用語が使えなかった。そこで「案件」という用語を定義し、「案件管理システム」という名称を与えてシステム化した。
システムは、範囲を拡げて連携していく。システム間連携や企業間連携などの際には、双方が用いる用語の意味・内容が異なり、整合性を保てないことも多い。また、新ビジネスを構想する際には、新たに生まれた概念を的確に理解し、客観的に理解可能な呼称を与え、意味・内容を定義する力も必要である。
データモデリングを行う際には、事業部と事業部、部と部、時には課と課を跨いだだけでも発生する「同音異義語（ホモニム）／異音同義語（シノニム）」の問題を的確に捉えて解決し、意味・内容まで新たに定義し直して、新たな呼称を与えなくてはならない。
三つ目のスキル、「概念整理＆命名のスキル」とは、高い語彙力とロジカルな理解力を持ち、新しい概念に皆が納得のいくネーミングと説明を与える力である。
（2）データ中心型アーキテクチャーを維持する組織
データ中心型アーキテクチャーを維持する組織は、以下の 3 点を念頭に実現する。
・全社データマネジメントを実現する組織
・新たな方法論の目的を理解して使いこなすスキル
・データ中心(DOBA)の重要性を社員・経営層に理解させる説明力
一つ目の、「全社データマネジメントを実現する組織」は、全社の各システムのアーキテクチャーを、DA 層を73

分離した新しい形に変え、全システムのデータを横串で管理する組織だ。この組織にはまず、「データモデリングスキル」を持った人材を配置する。そして各プロジェクトが、アプリケーションにデータを内包させたサイロ型のシステムを作ってしまわないようにコントロールする役割を果たす。
DOBA は、短期的にはコスト高に映る。全体最適を捨てて個別最適に走るサイロ型システムの方が安価に開発できるからだ。だが先程の「つながらない SoE」の事例では、安く上げたはずのサイロ型システムが、追加コス
ト発生の原因となった。
実際のプロジェクトは、QCD のバランスがせめぎあう現場で実施されている。データマネジメントを実現する組織には、データモデリングスキルを持った人材に加えて、長期的なコスト／効果バランスを意図してプロジェクトを運営できる人材の配置も必要である。
二つ目に、各プロジェクトを実施する要員には、「新たな方法論を使いこなすスキル」が必要だ。このスキルはまず、プロジェクトの初期にビジネス／データ／IT の専門家が知恵を出し合う新たな方法論の意図を理解し、それぞれの専門家を招集して全体像を取りまとめる“ファシリテーション力”だ。これは、各社の IT 部門に配属されているベテラン社員が担えるだろう。ただし、開発部門と運用部門が明確に分かれている場合や、ユーザー部
門とのコミュニケーションが希薄になっている場合は、それぞれの分野のエキスパートが参集して協力する必要がある。
加えて、ビジネス変化のスピードにキャッチアップするための内製をこなす“アジャイル開発力”も必要だ。初期には、個々人のスキルを高めるために、開発ベンダーから常駐者を招いて徐々にスキルを得ていくなど、具体的な対策も必要だろう。
三つ目が、「データ中心(DOBA)の重要性を社員・経営層に理解させる説明力」である。データマネジメント
は長期戦だ。DOBA を支えるアーキテクチャーを維持するには、開発フェーズだけでなく、保守維持フェーズでも注意が必要だ。末端ではちょっとした改修要望に見えても、全社データモデルにインパクトを与える新規要件かもしれない。これをサイロ型の視野で判断してしまうと、つながらない SoE の事例のように、後々の高い買い物になりかねない（このために維持管理すべき 3.5 層の日本型 EA モデル応用の考え方は、Ⅺ章で解説する）。
これを防ぐデータマネジメントの組織は、適切なスキルを持った要員を長期にわたって確保し、開発フェーズから保守維持フェーズまでを恒常的にサポートし続ける必要がある。一般には、データマネジメント組織を立ち上げても、プロジェクトの終了と同時に解散してしまったり、あるいは数年で解散してしまい、DOBA の成果を得る前に元の状態に戻ってしまう例が多い。責任者の方には、データマネジメントを牽引する組織を構築し、世の中の変化に対応し続ける体制を維持し、開発フェーズから保守維持フェーズまでを守り続けて欲しい。そしてその重要性を、経営層に是非訴えて頂きたい。

74

Ⅵ．3 随時刷新しておくべき「概念データモデル（データ設計図書）」
本章の最後に、DX に取り組むにあたり随時刷新しておくべきものを挙げて補足しておく。
経営層のニーズは、BI システムからの出力方法や見せ方など、分析用データへの要望となって表れる。分析
用データは、売上データなどのイベント系データを、組織や商品などのリソース系データで集計して作られる。
「概念データモデル（データ設計図書）」があれば、どのようなイベント系データが、どのようなリソース系データで集計可能かが見える化できる。
避けるべきだがよくある誤りは、ある管理者が組織別の成績集計を見なくなった年度のシステム改修で、それまで“組織別×商品別”で起票されていた伝票を“商品別”にまとめてしまうような例だ。こうすると伝票の枚数が減り、事務処理の手間やトランザクション処理の負荷は下がる。だが元となるデータの単位が粗くなってしまい、
組織別に分類したり集計したりすることができなくなってしまう。
基礎となるデータの単位は安易に変えてはいけない。変えて良いのは集計処理を行うアプリケーションだ。粗い単位に集計し直すことはアプリケーションでできる。集計単位の変更や表示するグラフの形式変更などはアプ
リケーション層（AA 層）の役目だ。
時々のニーズに合わせて行うデータの分析・集計は、基礎となるデータが変わらず利用できることで容易になる。データは変えず、できるだけ細かい単位で収集しておき、時々のニーズには、集計やグラフ化の方法を変えることで対応することをお薦めする。
一方、IoT の導入により、製造ラインから不良品データが新たに取得できるようになった場合はどうだろう。その不良品データがどの製品ロットと紐づけられるかは、「概念データモデル（データ設計図書）」に追記・反映することで明らかにしておくべきである。
また例えば AI で、SNS の投稿と売上データから商品の評価データが得られるようになった場合も同様だ。
その評価データが、どの商品のどの時期の売上と紐づけられるのかも、「概念データモデル（データ設計図書）」があれば明示的に整理できる。
IoT や AI など、新たな取組みにより新たなデータを得た場合は、全社データ構造（DA 層）のどこに追加改廃が起こったかを認識し、「概念データモデル（データ設計図書）」を刷新しておく。
随時刷新しておくべきは、「概念データモデル（データ設計図書）」そのものである。全社データ資産の最新状
況を随時把握できることが、次なるチャレンジの基礎となるからだ。

〈参考文献〉
ジョナサン・ハスケル、スティアン・ウェストレイク （2020）『無形資産が経済を支配する』東洋経済新聞社
椿正明（1994）『データ中心システム入門』オーム社

75

Ⅶ章 データの大切さ
海老原 吉晶本章のサマリー

データは、ヒト、モノ、カネに続く第 4 の経営資源と言われるようになった。



データとは現実世界を電気信号に写した写像であり、データを通じて現実を可視化できる。



新しく出現したオープンデータやソーシャルデータに比べ、以前からある社内データはあまり注目されないが、自社の事業活動を写像する社内データは自社独自の資産であり、独自のナレッジや競争力になりえるものである。



システムのライフサイクルに比べてデータのライフサイクルは長いので、システムの設計において、データの設計（データアーキテクチャー）の良し悪しは、より長期的に影響を及ぼす。



国内においてはプロセス中心アプローチ開発（POA）が主流であったことがシステムを硬直化させ、レガシーシステム化の一因となったが、より柔軟性が高いシステムを構築するには、データ中心アプローチ（DOA）
が有効である。



現実をデータに写像し、写像から現実を読み取るための説明はデータ説明図書（E-R 図とデータ定義書）に記述される。



概念データモデルとは、データに記述された内容を他者へ伝達・共有するための説明書である。



マスター・データに比べてトランザクション・データの方が発生するデータ件数が多いが、システムに蓄積される情報の量はマスター・データの方が多いため、より適切な運用が求められる。



高度なデータ活用に向けた『データマネジメント 6 箇条』を提示する。

ビジネス活動の多くの場面において、データの活用を通じた新たな潮流が訪れている。また GAFA に代表される破壊的イノベーターの多くは、大量のデータを保有し活用することによって成り立っている。Maas（Mobility as a service）や CASE(Connected、Autonomous、Shared & Services、Electric)といったキーワードに代表されるモビリティ変革も、その本質はガソリンエンジンが電気モーターに代わることではな
く、ネットワークに常時接続された自動車が端末となり、自動車の領域に限らずに様々なサービスと連携し、位置情報や移動の履歴などを組み合わせることによって新たな顧客価値を創出するところにこそ破壊的な革新がある。英国エコノミスト誌は 2017 年のコラムで『世界で最も価値のある資源はもはや石油ではなくデータである』と 論 じ 、 今 後 の ビ ジ ネ ス に と っ て 、 デ ー タ は 最 重 要 な 経 営 資 源 の 一 つ で あ る と 述 べ て い る （ The
Economist(2017）)。
今日、「データは、ヒト、モノ、カネに続く第 4 の経営資源である」というテーゼに対して“ノー”と言える経営者は少ないだろう。しかしながら、図表Ⅶ-1 に示す通り、第 4 の経営資源であるデータに対する具体的なマネジメントが行われているケースは稀であり、データの価値を理解し経営資源としてマネジメントし、競争力の源泉となる活用ができている例は極めて少ないのが実状である。
本章では、事業におけるデータの価値を紐解き、今後の経営資源として活用するために企業が行わなければならない取組みについて論じる。
76

図表Ⅶ-1 第 4 の経済資源としてのデータ

今日的なテーゼ『企業活動にとって、データとは、ヒト、モノ、カネに続く第４の経営資源である』
一般的な実態ヒト

社員名簿／職歴／賞罰／考課／ＣＰＤ開発計画

モノ

在庫棚台帳／たな卸し／引き当て／物流トラッキング／デマンド予測

カネ（PL、B／S）／予算／実績／見込み予測／修正予実予測

データ

？？？

Ⅶ．1 ビジネスにおけるデータの意義
言うまでもなく、ビジネスにおいてデータが価値を発揮するのは、データを構成する物理的な電子信号ではな
く、データに記述された内容によるものである。データに記述される内容とは、過去、現在および将来における現実世界であり、データとは現実世界を電気信号に写した写像であると言える。つまりデータによって、より鮮明な現実世界の写像を手に入れることができれば、より確実性の高い判断や将来予測に資するものとなる。分かりやすい例として、国内で急速な普及を見せている RPA（Robotics Process Automation）を導入した後に“プロセスマイニング“を通じた詳細な業務分析を行うことで、より高度な業務改革が行われる例があげられる。
RPA を導入する当初の目的は業務プロセスの自動化・省力化であったが、RPA 上に蓄積された業務履歴データを分析することによって、業務プロセスのボトルネックや無駄な待ち時間を見つけ出し、業務プロセス改革につなげるというものである。これは、業務プロセスの遂行結果という現実をデータに写像し可視化することによって、従来の稼働分析やワークサンプリングでは補足し得なかった新たな発見や知見が見出される典型的な例と言える。
今日、IoT（Internet of Things）と言われるように、産業機器のみならず、日常的な家電製品を含めたさま
ざまなデバイスがネットワークに接続され、現実を写し取るセンサー技術の発達もあいまって、収集可能なデー
タの種類と量は指数関数的な拡大を見せている。また SNS 上に流通するソーシャルデータなど、かつては入手不可能だった様々なオープンデータが、マーケティング分野を中心に活用されるようになってきた。従来には無かったという面からこれらの新しい種類のデータは脚光を浴びているが、一方で前述の RPA や各種の社内システムから発生する業務データにはあまり注目が集まっていないように見える。しかしながら、自社の企業活動
77を写像した社内データが、より直接的に自社のビジネスを推進・改善する上で重要な役割を担うのは自明なことである。また忘れられがちであるが、自社内で発生するデータは、自社独自の資産であり、どんなに費用をかけても社外のどこからも手に入れることはできないものであることを忘れてはならない。仮に同じ ERP パッケージを使っていたとしても、そこで発生した業務データは自社独自に蓄積された資産であり、この社内業務データを適切に管理・蓄積することは、自社独自のナレッジとなり、競争力になり得るものである。

Ⅶ．2 情報システムにおけるデータの位置づけ
情報 シス テム におけるアプリケー ションとデータの位置づけを 考える時、DMBOK 第 1 版（ DAMAInternational,2009）に描かれているデータライフサイクルとシステム開発ライフサイクル（SDLC：System
Development Lifecycle）との対比は示唆に富む。SDLC は情報システムの企画－構築－維持・運用に至る一連のプロセスである。SDLC と対比したデータライフサイクルで最初に目につくことは、データライフサイク
ルが SDLC よりも“長い”ことである。これは、アプリケーションやインフラを入れ替えたとしても、データは継続して使用され運用されることを示している。アプリケーションやインフラは新しい環境にマイグレーションすることでリセットできるが、リセット後のシステムにおいてもデータは継承される。このことからもデータライフサイクルにおける「計画（Plan）」、「仕様確定（Specify）」といった上流の設計を誤ると、その弊害は極めて長期にわたって悪影響を及ぼしてしまうことが分かる。企業情報システムにおいて、データの設計がリセットできるのは、製造業がサービス業に事業転換するような、ビジネスモデルが根本的に変わるときであるが、その場合でさえ、顧客や従業員が継承されるのであれば、そのデータは継承される。このことから、情報システムの設計においてデー
タの上流設計（データアーキテクチャー）が、より長期的に事業遂行に影響を及ぼす重要なものであることが分かる。本書のⅤ章、Ⅵ章およびⅪ章において、EA の中における DA 層の位置づけを AA 層よりも BA 層に密接なものと定義する所以である。
図表Ⅶ-2 DMBOK 第 1 版によるデータライフサイクルと SDLC の対比

データライフサイクル
計画（Ｐｌａｎ）

仕様確定（Ｓｐｅｃｉｆｙ）

使用可能化（Ｅｎａｂｌｅ）

登録と入手（Ｃｒｉａｔｅ ＆Ａｃｑｕｉｒｅ）

維持と利用（Ｍａｉｎｔａｉｎ＆ Ｕｓｅ）

アーカイブと復旧（Ａｒｃｈｉｖｅ ＆Ｒｅｔｒｉｅｖｅ）

消去（Ｐｕｒｇｅ）

計画（Ｐｌａｎ）

分析（Ａｎａｌｙｚｅ）

設計（Ｄｅｓｇｉｎ）構築（Ｂｕｉｌｄ）

テスト（Ｔｅｓｔ）

配備（Ｄｅｐｌｏｙ）

維持（Ｍａｉｎｔａｉｎ）

システム開発ライフサイクル（ＳＤＬＣ）

78

Ⅶ．3 国内の情報システムにおけるデータの課題
国内企業において情報システムが利用されるようになったのは、1970 年代前半に遡ることができる。初期の情報システムは、専ら作業の自動化による効率向上を主たる目的として導入されてきた。まだ SAP のような業
務アプリケーションパッケージ（ERP）の無かったこの時代の情報システムは、それまで人手で行われていた業
務プロセスをできるだけ忠実に反映したプログラムを内製することによって開発・実装されてきた。この頃に作られた情報システムの主役は業務プロセスを自動化するための「プログラム」であり、「データ」は個々のプログラ
ムに対して次の手続きを伝達するための脇役とみなされてきた。さらには、データの中でもより長期的かつ広範囲に影響を及ぼす「マスター・データ」より、手続きを伝達する「トランザクション・データ」が重視され、データの設計も主に紙の伝票に記載される項目を元にして設計されることが多かった。
こうした初期の情報システムの良し悪しに対する評価は、遅滞なく正確に“業務プロセスを遂行する”ことであったため、業務を担当するユーザーにとって分かりやすいことが何より重要であった。このため、異なるユーザーが担当し、かつ先行・後続関係のない業務を横断したデータの共有はあまり考慮されなかった。このことによって、情報システムに格納されるデータが同じ実体（エンティティ）に対してであっても、業務ごとに異なる呼び方・
定義・設計が行われ、多くの「方言」が存在する状況を生み出し、似て非なるデータと類似のデータベースを保有してしまった。
こうして構築された情報システムは、個々のプログラムが個別に定義したデータを使用し、プログラムとデータが相互に「密結合」した構造となってしまった。密結合な構造の情報システムの問題点は、業務プロセスの変更に応じてプログラムを修正する際、多くのケースでデータ定義にも変更が必要となるため、変更の工数と時間が大きくなることである。システム開発で「手戻り」が発生した時に一番ダメージが大きいのは、データベース設計の変更を伴う場合である。こうして作られた密結合な構造で変更しにくく硬直化した情報システムは、今日ではレガシーシステムと呼ばれるようになり、ビジネス変革への足枷となる厄介者とみなされるようになった。
一方、レガシーシステムに格納・蓄積されたデータは、個々のプログラムの都合を優先して作られているため、他のデータとの関連付けや比較が困難であることが多く、このことによって事業横断・プロセス横断での分析・活用が進まない一因ともなっている。

Ⅶ．4 データ中心による柔軟性の高い情報システム構築
前節では、プロセス中心によるシステム開発の結果、硬直化したレガシーシステムが作られてきた経緯を解説した。本節では、より柔軟性が高く、より現実世界を正しく写像してビジネスに役立つ情報システムを構築するアプローチであるデータ中心アプローチ（DOA：Data Oriented Approach）について、そのポイントを説明する。
Ⅴ章に述べられているとおり、本書では、DOA を DOBA（Data Oriented Business Approach）と、DOCA（Data Oriented Computing Approach）の二つに再定義している。ビジネスに対する価値を生み出すためには、コンピューターへの実装の視点である DOCA ではなく、ここではビジネスの文脈でデータを捉える DOBA を前提として述べる。
79

Ⅶ．4．1 データとデータに写像される現実世界をつなぐデータ説明図書
写真や映画は、現実世界に反射した光を、レンズを通すことによってフィルムに写像している。このときフィル
ムに写像されるものは「光」である。一方データに現実世界を写像するのはデータに記述される「内容（content）」である。内容は実際に手で触れることのできない概念的なものであり、データに記述された内容を他者へ伝達・共有するためには、記述された内容に対する説明が必要である。この内容に対する説明は、Ⅵ章に述べるデータ説明図書（E-R 図とデータ定義書）として記述される。データ説明図書がより正しく現実世界を反映しているとき、データはより正しく現実世界を写像する。そして、データ説明図書を記述する際には、DOBA の視点からビジネスの文脈を反映することで、データをよりビジネス価値につなげられるようになる。

Ⅶ．4．2 概念データモデルの役割
精度の高いレンズが、光をより正確にフィルムに写像するように、現実世界の内容をより正しくデータ定義に反映するには、現実世界を正しくデータ定義に映し出すレンズとなるデータ説明図書が必要である。データモデルの開祖の 1 人であるピーター・チェン（CHEN,1977）は、現実世界とデータ定義（データ設計）の関係を、図Ⅶ-3 のように表している。ここで物理スキーマ（原書では User schema）と記されているものが、今日で言うところの「データの物理設計」である。データに記述される内容（content）は概念的な存在であるので、レンズが「光」を通すように、現実世界に対する認識のフレームワークである概念スキーマ（原書では Enterprise
Schema）を通すことによって内容を正しくデータ定義に反映できる。概念スキーマは、今日では概念データモ
デルとして記述様式が確立しており、データ説明図書の構成要素の一つとして記述される。
図表Ⅶ-3 現実世界とデータの関係

出典：ピーター・チェン(1977)”Enterprise Schema as an intermediate step in database design”を元に作成

同じ対象物をさまざまな異なるレンズを使って撮影するとさまざまな形の映像ができてしまうように、同じ現実世界に対してさまざまな概念データモデルを作ってしまうとさまざまな内容でデータが記述されることになり、どのデータ内容が正しく現実世界を写像しているのか分からなくなってしまう。このため、同じビジネススコープについて考えるとき、統一された概念データモデルの中にそのビジネススコープの中の全ての要素（エンティティとエンティティ間の関連）を記述し、同じ写像が得られるようにする必要がある。ビジネススコープはビジネスモデ
ルの単位であることが一般的であり、大企業では事業部の単位であることが多い。

80

図表Ⅶ-4 データに写像される現実世界と概念データモデル

Ⅶ．4．3 概念データモデルを作る際の視点
概念データモデルの記述様式として、今日では E-R 図が普及・定着している。E-R 図は幸か不幸かリレーショナルデータベース（RDB）が物理設計書として極めて使いやすかったため、多くの場面で概念データモデルと物理データモデル（物理設計書）はないまぜに捉えられていることが多い。
しかしながら、図表Ⅶ-3 に示しているように概念データモデルと物理データモデル（物理設計書）の整合性を担保しておく必要はあるものの両者の役割は異なるものであり、たとえ同じ E-R 図という記述様式を使っていたとしても明確に使い分けなければならない。なぜなら、物理設計書には、データベースのアクセス速度やストレージ効率、ネットワークの制約を加味したチューニングなどが必要であり、現実世界を正しくデータに写像するという目的以外の偏向が入ってしまうからである。このため、概念データモデル本来の役割である「データに記述された内容を他者へ伝達・共有する」ことに対して無用なバイアスをかけてしまう恐れがあるからである。
また、データをビジネスの価値につなげるには、DOBA（Data Oriented Business Approach）の観点が不可欠であることを前述したが、DOBA を実際に行うには、概念データモデルがデータベース設計のためのものではなくビジネスとデータをつなぐためのものであるという認識と観点が必要である。このことは、概念データ
モデルの作成を IT 部門やシステム開発会社、コンサルタントのみに任せるのではなく、ビジネスと経営の意思決
定者自らが参画しなければならないことを意味している。

81

Ⅶ．5 マスター・データとトランザクション・データ
業務システムに格納・蓄積されるデータは、大きく「マスター・データ」と「トランザクション・データ」に分けられる。マスター・データには当該のビジネスで必要となる Who, What, Where, When, How の 4W1H に関する単一の台帳である（水谷、2016）。
マスター・データに記述される代表的なものとして以下が挙げられる。
・Who（顧客、サプライヤー、従業員、組織など）
・What（製品、商品、部品、サービスなど）
・Where（事業所、倉庫、棚、座席番号など）
・When（日時、時差、年度、月度など）
・How（値引率の適用レベルなどのルール）
一方、トランザクション・データは、取引やビジネスの各プロセスで発生した処理の手続きデータである。言い換えれば、マスター・データは、システムを動かす前から入れておく必要のあるデータであり、トランザクション・
データはシステムを動かすことによって発生し蓄積されていくデータと言える（佐々木、2018）。
また、トランザクション・データは一度発生したら後からの変更は行わないことが鉄則であるが、マスター・データは絶えず最新の状態に追加・更新・メンテナンスしなければならないものである。
Ⅶ．３において、国内企業の情報システムの課題として、より長期的かつ広範囲に影響を及ぼす「マスター・データ」よりも、手続きを伝達する「トランザクション・データ」が重視されてきたことを問題として指摘した。ここでは、マスター・データの重要性について詳しく説明したい。
一般的に、マスター・データとトランザクション・データを比べたとき、データの件数は圧倒的にトランザクショ
ン・データの方が多いが、システムに蓄積された情報の量は、圧倒的にマスター・データの方が多いことはあまり認識されていない。例として、図表Ⅶ-5 に卸売店の受注データの例を示す。
図表Ⅶ-5 問屋の受注データに占めるマスター・データ情報
フィールド名

データ

①

受注番号

A001356②

受注日

2020/10/15

③

商品コード

P00356④

商品名

携帯ポット500ml

⑤

単価

3,800

⑥

数量

20

⑦

顧客ID

CUS00578⑧

顧客名

BOUドラッグストア

⑨

納入先ID

A001356-8⑩

納入先名

ゲートシティ高輪駅前店

トランザクション・データとして発生するもの

商品マスタから引用するもの

顧客マスタから引用するもの

これを見ると、受注データを構成する 10 項目のうち、太字で書かれている 7 項目はすべてマスター・データ
であり情報の 7 割がマスター・データであることが分かる。
82

Ⅶ．5．1 マスター・データ管理の重要性と注意点
前述のとおり、トランザクション・データは発生したら後から変更しないことが鉄則であるが、マスター・データ
は常に最新の状態に追加・更新・メンテナンスが必要である。ここにデータ品質を保つ際の落とし穴がある。トラ
ンザクション・データに誤りがあったときは、業務プロセスを遂行する中で金額や数量、納期などの誤りによる不都合が生じるため、データ品質（正確さ）の責任は自然とデータ入力者が負うことになるが、マスター・データの入力・更新の責任者はしばしば曖昧になってしまうことがある。これは、トランザクション・データとマスター・デー
タにおけるオーナーシップの性格が異なるために生じるものである。トランザクション・データのオーナーは業務プロセスの実行者（部門）であるのに対し、マスター・データのオーナーは対象となる物や事柄の管理責任者（部門）である。プロセスの実行者（部門）は仮にルールや決め事が無かったとしても、そのプロセスが実行されている限り実行者は自明であるが、管理責任者（部門）はルールや決め事として意図的にアサインしなければならない。 さらに管理責任者（部門）は、マスター・データが更新されなくても実務上困らない場合がある。 例えば、物流業務でも使用される商品マスターが、本来なら商品事業部（プロダクト・マネジメント部門）がオーナーであっても、当該の商品事業部としては月次で商品別の流通量が集計できれば事足りていて、一方、物流部門にとっては今この瞬間に注文と商品を引き当てなくてはならないといった状況があるとき、現場作業の都合から商品
マスターの更新作業だけが物流部門に移管されてしまい、いつのまにか商品マスターを決める主管部門が物流部門に移ってしまうといったケースが散見される。
このケースでは、本来なら商品戦略の写像である商品マスター・データの実際的なオーナーが商品事業部から物流部門へ移ってしまったのである。こうした事態は欧米に比べてジョブディスクリプション文化が薄い日本企業において顕著であり、データドリブンや DX を推進する際のボトルネックになっているケースも珍しく無い。
ⅩⅢ章で述べるデータ経営を実現するためのボトルネックを排除する意味においても、企業の中で見落とされがちなマスター・データのオーナーとなる管理責任者（部門）のアサインと適切な運用体制を整備しておくことが重要である。

Ⅶ．6 高度なデータ活用を実現する組織の 6 箇条
ここまでで述べたように、これからの世界でビジネスを変革し成長し続けて行くために情報システムの高度化を進めるためにはデータの果たす役割が大きい。そして情報システムを高度化するにあたっては、DOBA を中心に据えたアプローチが必要であり、その中では、データが価値を生み出すためにビジネスの実体を正しくデータに写像する概念データモデルが重要であることを解説した。
JUAS では 2012 年よりビジネスの文脈におけるデータの役割と、より高度なデータ活用を行うためのフレームワークを研究する「ビジネスデータ研究会」が続けられている。この研究会の中では、データ活用で大きな成果を上げている成功企業の事例を分析し、そこに共通している要素を抽出することによって、「データマネジメン
ト推進 6 箇条」をまとめている。以下に、その内容を紹介する。

83

図表Ⅶ-6 データマネジメント推進 6 箇条

其の一

概念データモデルを作るべし！

・ＥＲ図を書くことが目的ではない！全社員が見て納得する絵・共通の認識を持つ事が目的！
・ビジネスモデル単位に作成せよ！

其の二

データ維持管理の専門組織を作るべし！

其の三・マスタデータの一元管理、各システムへの自動配信が理想！

・維持運用プロセスの継続も行うべし！

データ基盤環境を整備せよ！

其の四

同音異義語、異音同義語が整理されたデータ辞書を整備せよ！

其の五

データ・システム・業務を理解した人が不可欠！

其の六

各部署の利害関係をブチ破れるような強いリーダーシップが必要と心得よ！！

・ユーザーが自由に閲覧できる項目説明されたWiki的なもの。

・データスチュワード。人に注目し、育てることが重要！

其の一：概念データモデルを作るべし！
成功企業に共通している特徴として最初に見出されたのは、概念データモデルを作成することよって、データ設計の一貫性とデータの意味に対する組織内の共通認識・理解を担保しているということであった。多くの場合、
データモデルを作成することはデータベース設計書としての ER 図を作成することと同義に思われているが、ここでの概念データモデルは、DOBA（Data Oriented Business Approach）の観点に基づいて論理モデル
よりも抽象度の高いレベルで事業全体を俯瞰した一気通貫のモデルを描写することである。概念データモデル
は組織・団体が保有するビジネスモデル毎に作成されるものとなる。
其の二：データ維持管理の専門組織を作るべし！
組織内・団体内でデータ利活用を発展させるためにはデータを扱う組織体制が求められる。特に形骸化しがちなマスター・データの管理責任部門の明確化が重要である。更に、より高度なデータ利活用を行うフェーズにおいては、専任組織によるデータ管理体制を構築することによって、より俊敏なデータ利活用が可能となる。
其の三：データ基盤環境を整備せよ！
組織内に散在するデータを統合する過程は、データライフサイクルの、より上流で行うことによって後続のプロセスの工数と時間を削減することが可能である。一説にはデータサイエンティストが行う作業時間の 90%は、必要なデータの収集、結合・統合、クレンジングといった前準備に費やされていると言われている。データの利活
用をより高速に効率的に行えるようにするには、より上流段階でのデータ整備による効果が大きい。
其の四：同音異義語、異音同義語が整理されたデータ辞書を整備せよ！
多くの組織・団体では、データの発生元である業務システム毎にデータ定義がなされている。それらのデータ
84

を結合・統合して利活用する際に、組織全体で共通のデータ辞書が整備されていれば、分析・利活用の作業を軽減するだけでなく、データの意味を誤って認識することによる誤った分析結果を招くリスクを回避できる。通常、分析の過程は分析者に委ねられるため、分析者が誤った認識のもとで行った分析結果に対して、分析対象となったデータへの理解が誤っていることを判別するのは非常に困難である。
其の五：データ・システム・業務を理解した人が不可欠！
データを活かすためには、「業務」、「データ」、「分析」の三つの知識・スキルを同時に投入しなければならない。
ここでは分かりやすく”人”と表現しているが、これは必ずしも一つの人格が兼ね備えなければならないものではなく、三つの知識・スキルを保有するステークホルダーによる「チーム」として実施するのが現実的である。
其の六：各部署の利害関係をブチ破れるような強いリーダーシップが必要と心得よ！！
成功事例の共通点として最も印象的なものは、ここで挙げている「強いリーダー」の存在である。明確なビジョンを持ち、データの果たす価値を理解したリーダーが信念と情熱を持って取り組んだ結果、組織内の関係者や経営者までを動かし、洗練されたデータの利活用を実現しているのである。
特に部門間でシステムとデータがサイロ化している状態からの脱却においては、組織を横断した強力な推進力が必要である。

＜参考文献＞The Economist(2017) The world’s most valuable resource is no longer oil, but data：May
6th 2017 edition
https://www.economist.com/leaders/2017/05/06/the-worlds-most-valuable-resourceis-no-longer-oil-but-data
PETER PIN-SHAN CHEN（1977）The entity-relationship model- A basis for the enterpriseview of data,national computer conference,Pages 77-84
DAMA International(2009) The Dama Guide to the Data Management Body of Knowledge（データ総研訳(2011)『データマネジメント知識体系ガイド 第一版』日経 BP)
喜田昌樹 編著、JUAS ビジネスデータ研究会 編（2018）『経営のためのデータマネジメント入門』中央経済社
水谷哲（2016）JDMC 会員リレーコラム『【Vol.35】「MDM の 4W1H とパナマ文書」』、https://japandmc.org/?p=6304
佐々木真（2018）「分かりそう」で「分からない」でも「分かった」気になれる IT 用語辞典『マスタデータ(master data)』、PCS（Piyopiyo Create Service）、https://wa3.i-3-i.info/word12917.html
85

Ⅷ章 大切なデータを生かすデータモデルとは～データモデルの価値と課題

本章のサマリー

データモデルの本質的価値とは、「データから意味のある情報を生み出す」「情報から知識（形式知、暗黙知）を創造する」「知識を人の知恵にして社会に価値をもたらす」ことである。



データモデルの役割とは、「現実世界とデータをつなぐ翻訳者（インタープリター）」と「ビジネスモデルの形式知化」である。



企業の中でビジネスモデルを理解し共有化してビジネス戦略に活かしていくために、データモデルを描く。
「ビジネスモデルを形式知化する」していくとともに、「現実世界をデータで表現する」ことで、ビジネス・デー
タ・プロセス（業務）の全体観を把握する。



データモデルはデータ活用のための基礎である。データモデルを作成することは、効率的にシステム開発を行うだけではなく、社会や企業のデータ活用をより容易にする。自社のビジネスそのものの理解が進むことにもつながるし、できあがったデータモデルは自社内でビジネスを語る上での共通言語にもなりえる。



データモデルを上手に抽象化することにより、他社、他部門との共通点が見つかることがある。共通点を見つけられた場合、それは業務の本質に近づいたことを示している。



情報システム開発方法とデータモデルにおいて、DOA では、全体を俯瞰し「あるべきデータモデル」を書く。
これを基にシステムや業務を考え直すことができる。



情報システムの中に業務プロセスを埋め込み固定化してしまうこと（POA）を防ぎ、データとプロセス（アプリケーション）を分離する DOA により、情報システムを柔軟に開発・維持していくことができる。



一方で、データモデルの価値は必ずしも正しく理解されていない現実がある。
データモデル普及のためのステップは、次の三つと考えられる。
①体験を伴った思考訓練に相応の時間を割く②業務知識とその深い理解を得る③作り手の目線でものづくりに関り、情報の素材とは何かを体感する

・ データモデリングの重要成功要因（KSF）は、次の三つと考えられる。
【KSF 1】まずビジネスから考え、ビジネスクエスチョンやユースケースを定義する【KSF 2】データモデリングはサブジェクト指向で考える【KSF 3】データモデリングは、汎用化と抽象化が重要である

86

Ⅷ．1 データモデルの本質的価値

野々垣 典男

Ⅳ章において、「データ」を「情報」に、さらに価値ある「知識」にし、いかにして意思決定のための「知恵」に結び付けていくかが情報システムの役割として重要であることを述べてきた。図表Ⅷ-1 にその流れを示す。

図Ⅷ-1 データを集め解析する意義「いかにしてデータを知恵につなげていくか」が重要であり、大量のデータを保有することに価値があるのではない。データから意味のある情報を生み出し、知識を創造し、人の知恵にすることにこそ価値がある。そして、
データとその関連を論理的に表現することがシステム開発では不可欠であり、この構造を表現したデータモデ
ルが重要になる。データモデルはシステム開発の上からも、データを知恵に結び付けていくプロセスをたどるた
めにも基本となるものであり、良いシステム、良い知恵を生み出していく要となる設計図であり、モデリングは要の技術である。
データモデルの価値について、まとめたものが図表Ⅷ-2 である。ここでのポイントは、データモデルを、正しくシステム開発を行うための「ソフトウェア工学」の観点から論じるのか、あるいはビジネスからバリューを生み出すという「経営」の観点から論じるのかによって大きく異なる。
ソフトウェア工学の観点からは、対象となるアプリケーションを適切に設計するために、システムでやりとりされ
るデータ構造を明らかにすることを目的とする。一方で、経営の観点からは、ビジネスを「システム」として捉え、バリューチェーンや組織などでやりとりされるデータを可視化するとともに、データがビジネスで適切に活用されることを目的とする。
このように、データモデルは「ソフトウェア工学」と「経営」という二つの観点から捉えることができるが、その本質的な価値は両者ともに、前述のとおり、・データから意味のある情報を生み出す・情報から知識（形式知、暗黙知）を創造する
・知識を人の知恵にして社会に価値をもたらすである。
87

図表Ⅷ-2 データモデルの本質的価値

Ⅷ．2 データモデルとデータをつなぐ価値

金 修

データモデルやデータをつなぐことの価値や意味は、暗黙知と形式知の SECI モデルで説明できる。

図表Ⅷ-3 SECI モデル（野中郁次郎氏提唱）

KKD（経験、勘、度胸）によって高度成長時代を乗り切れたのは、追いつけ追い越せの目標があり、特にそれらを形式化する必要性も感じずに、典型的な暗黙知である KKD（経験、勘、度胸）意思決定ができたからなのかも知れない。
新たな価値創造を迅速に求められる時代においては、目先に明確な目標（事例）があるわけではなく、自らその目標（価値）を定めることが求められている。そのために、SECI モデルの「共同化」「表出化」のための「データモデル」の作成が必要であり、その作成したモデルは改善・改革の基準となる。モデルを作成することにより、データをつなぐなど「連結化」のニーズやアイディアが誘発される。
88

その結果でオペレーションすることにより、新たな暗黙知が得られ(内面化)、これを形式化（表出化）する
SECI モデルシーケンスを繰り返す。
このようにデータモデルは「業務や意思決定の見える化」と言える。計測できない、見えないものには手が打てない。KKD を全面否定するものではなく、「KKD+D（Data）」がこれからのマネジメントスタイルの王道と考える。これまでの Processing 本位から、Data 本位に注力すべきである。

Ⅷ．3 データの位置付けと扱い

金 修

情報システムの黎明期では、EDP（Electronics Data Processing）と言われてきたが、各種作業の自動化に絶大な威力を発揮したこの時期から情報システムにおいては、Data よりむしろ Processing に重きが置かれてきた。
そもそも、データが何をするにも源流である。
コンピューター処理能力に制限があった時代は、いかに必要最小限のデータでサクサク動くかというパフォー
マンス重視の設計が主流であった。コンピューターの処理能力（メモリーと処理速度）の指数関数的な発達により、処理パフォーマンス重視から、データの持つ価値とその活用へと注目が集まるようになった。ビックデータやAI など、大量のデータをベースに、あたかも非論理的な処理ができるようになり、研究ベースではなくつながりが実務に供されるようになった。業務処理など、その業務の中で扱うデータや処理モデルの場合と、諸々のデー
タを非論理的に扱い、予測など意思決定の補助としてデータを扱う、所謂情報系とではデータの持つ位置付けは異なる。

Ⅷ．4 データモデルの役割と価値

海老原 吉晶データモデルが果たしうる役割は、大きく以下の二つに分類される。
1.

現実世界とデータをつなぐ翻訳者（インタープリター）

2. ビジネスモデルの形式知化Ⅷ．4．1 現実世界とデータをつなぐ翻訳者（インタープリター）
概念データモデルは、現実世界とコンピューター上のデータの物理設計を橋渡しするものである。言わば、情報システムを活用する現実のビジネスと、データの間に立つ翻訳者の役割を持つ。
（1）「現実世界 → データ」方向の翻訳
現実世界をデータに正しく写像するために、ビジネスモデルやオペレーションの構成要素であるエンティティとエンティティ間の関連（リレーション）を、そのビジネスの「主観」を反映するように抽象化してデータモデルを作成することによって、より適切なデータ設計ができる。
実際にデータモデルを作成してみるとわかることだが、エンティティを並べるだけなら当該の業務の中で使用
89

される用語を、例えば使われている伝票の記入項目や画面の入力項目から拾い上げて列挙することによって、ある程度網羅することはできる。しかし、エンティティ間の関連（リレーション）を合わせて記述しようとしたとき、その業務の背景や意図といった現実世界の文脈（コンテキスト）が理解できていないと記述できないことが分かる。つまり、データモデルは、自らの業務やビジネスの意図を正しくデータに写像するためのデータ構造と定義を記述したものと言える。
（2）「データ → 現実世界」方向の翻訳
単に固定した手続きをプロセス間で伝達するだけであれば、データに対して人間的な理解や解釈を必要としないかもしれない。しかし、データに写像された現実世界を読み取り、意思決定やビジネス改革を行おうとすれ
ば、人間がデータから意味を理解しなければならない。そのとき、データを人間が理解するためにデータの内容を説明するものがデータモデルのもう一つの役割である。
例えばそのデータ上に記述されている「顧客」は個人なのか法人なのか、あるいは個人と所属する法人の関係も含めているのかについて説明を得ることによって、はじめて人間はデータ上に記述された現実世界を正しく理解・解釈できる。

（3）ビジネスモデルの形式知化
一般的な用語である「顧客」や「商品」でも、ビジネスモデルの主観によって現実世界の捉え方は異なる。
BtoC か BtoB か？、個数売りかバルク売りか？、などの違いは、エンティティの定義（特に識別子）とエンティテ
ィ間の関連の違いとなって現れる。ビジネスモデルをデータモデルに記述することによって解釈のゆらぎを無くした形式知化し、誤解なく共有できる。
データモデルに表現されるものは数学的な定理ではなく、ビジネスモデルの主観の上に立ったそのビジネスオーナーの意志である。したがって、業務システムを設計する場合はその業務の責任者、ビジネス全体のシステムを設計する場合は経営者がデータモデルの作成に参画すべきである。
もし、ビジネスモデルをデータモデルに記述できない部分があるとしたら、それはビジネスオーナーの意志がまだ固まっていない部分であり、決断をするか、あえて保留してトライアンドエラーの余地として残すかの意思決定をしなければならない。

Ⅷ．5 データモデルはデータ活用のための基礎である

三谷 慶一郎Ⅷ．5．1 新型コロナ禍で露見したデータ活用上の課題
新型コロナ禍は世界中に広がり、多くの人々への健康面の被害と、莫大な経済面の被害の両面を同時に巻き起こしている。これに対応し、「非対面・非接触」で経済活動を継続していくために、テレワーク、オンライン診療、
オンライン教育など、デジタル技術の活用がさまざまな領域で行われている。新型コロナ禍は、ある意味では世界中をフィールドとした大規模なデジタル社会実験が半ば強制的に行われているとも表現できる。そして、現状、
デジタル技術の活用によって一定の成果があがっていると考えていいだろう。
しかし、日本においては、データ活用がうまくいかなった事象も少なからず見受けられている。法制度や業務
90

プロセスが、紙ベース・対面ベースで作られているため、テレワーク中に、ハンコを押すためだけに出社する様子は多くみられた。また、感染状況のモニタリングにおいて、FAX 利用や手作業が残っていたために感染者数の集計に誤りが発生したこともあった。さらには、せっかくの個人への給付金が、電子申請を利用したにもかかわらず実際に届くまでにかなり長い時間を要してしまったことも記憶に新しい。残念ながら今回の厄災で「データ活用が上手ではない」という日本の欠点が見事に露呈してしまったと言える。
データを活用すること。これは、データの所在をつかみ、必要なデータを必要なタイミングで収集しつなぎあわせ、これを分析することによって、新しい「知見」「知恵」を得るという一連のプロセスである。今回の事象をきちんと総括し、日本の企業あるいは社会においてなぜデータ活用がうまくいかないのか、どうしたらうまくいくのかをじっくり考える必要がある。

Ⅷ．5．2 データモデルによるデータ活用力の向上
さて、本章で論じている「データモデル」とは何を目的として作成されるものであろうか。
一般的には、効率的にシステム開発を行うためと言われている。現状の業務をデータの視点から見て、その構造を可視化し、データを起点として設計していくことによって、業務プロセスとデータとを分離することができる。これによって、業務プロセスが、情報システムのなかに埋め込まれ、固定化してしまうことを防ぎ、柔軟なシステム開発が可能となる。これらのことが大きな効用を生むことは間違いない。
しかし、データモデルを作成することは、それだけではなく、先に述べた社会や企業の欠点であるデータ活用をより容易にするという側面を持つことにも注目すべきだろう。
同じ内容なのに組織によって異なる名称を持つような同音異義のデータ、あるいは違う名称なのに同じ内容を意味するような異音同義のデータなどを無くし、企業内のあらゆるデータを正規化できるようになる。これらによって、必要なデータを見つけ出し、それを抽出することを容易にすることができる。あらゆるデータを誤りなく
いつも最新の状態で維持する。あるいは複数のデータ間の関係性を明確にし、参照・利用しやすいようにする。
これらは全てデータモデルを作成することによって得られる、データ活用上のメリットになる。
また、データモデルを作成することによって、自社のビジネスそのものを正確に理解することにもつながるし、できあがったデータモデルは自社内でビジネスを語るうえでの共通言語にもなる。これらの間接的なメリットも、企業内でのデータ活用を後押しすることにつながる。
データを活用することが今後のビジネスにおける生命線であることは間違いないし、先に述べた通りデータ活用力を向上させることは企業や社会にとって極めて重要な課題である。データ活用を促進させるという観点か
らもデータモデルに再注目すべきである。

Ⅷ．5．3 データ活用のためにさらに必要なこと
ただし、企業のデータ活用力を高めていくための方策は、データモデルを作成することのみではないことも理
解しておきたい。
一つには、データを活用しやすい仕組みや環境をつくっていくこと。例えば、標準的な API（Application
Programming Interface）を設計することによって、企業内のデータにアクセスしやすい仕組みを整えること。
あるいは昨今話題になっているローコード・ノーコードでの開発環境を整備・解放し、より容易にデータ活用を行
91

えるようにすることなどは有効な施策となろう。
データ活用スキルを持つ人材を増やすことも重要だ。経営管理やマーケティングを支援する専門的なデータ
サイエンティストを育成・確保するだけでなく、社内のあらゆる組織に所属するより一般的な人材に対し、研修などのデータ活用スキル向上の機会を与え、企業全体のデータ活用力を底上げしていくことはとても重要だろう。
さらには、純粋な技術の話だけでなく、データ活用を阻害するようなプロセスやルールの変更に着手することも考えられる。部分的に手作業を残すのではなく、一気通貫でデジタルネイティブなプロセスを再設計することは早急に行うべきアクションだ。また、プライバシーやセキュリティといった観点への配慮も行いつつも、可能な限り
データ活用しやすいルールを整備していく必要もある。
企業のデータ活用力を向上させることは、今日における IT 部門のミッションの一つである。だとすれば、デー
タモデルの作成だけでなく、これらのすべての方策に対して、IT 部門は何かしらの形で貢献していく必要があると考えるべきだろう。

Ⅷ．6 情報活用の 7 ステップとデータモデル

赤司 浩文

某社の IT 部門は、情報活用の 7 ステップとして下記のように定義しているが、概念先行で実務レベルでの実展開は進んでいない。
①

データを生み出す→手書きからデジタル入力へ＆センサーの活用②

データを保管する③

データの正確性を保つ→集中管理、データ監査④

データを守る→データセキュリティ⑤ データを流通させる→システム間連携⑥

データを情報に変換する→分析、ＡＩ、予測⑦

情報の活かし方を考える→モデル化、抽象化、事例共有、横展開

上記に特に異論はないが、「データモデルの本質的な価値／データをつなぐ価値」を体感するのは、太字で記載した⑤以降のステップになると考えられる。正攻法で積み上げてたどり着くには、個々のステップでの苦労が多く、ハードルが高いと考えられる。
また、上記概念を企業内でどのような粒度(個別製品、個々の事業、会社全体)で考えるのかに関しても重要なポイントであるものの決めることは容易ではなく、まずは何かやってみよう・・・、が実態だろう。ただ、24 時間
テレビの「動く」のコンセプトと同じで、進め方としてはアリだろうが、道のりは長い。
なお、それに気づく人財が出てきていることで現状打破に向けての兆しは出てきたと思われるが、ボトムアッ
プでの積み上げではハードルが高い。価値や効能を錦の御旗にトップダウン的に対応するために、トップ層の共感を得る必要があるものの、たどり着けていない。
このように、データモデルやデータ連携ができてないことに起因するダメ出しやできない理由(言い訳)といった「HOW」は挙げられるが、できた際の価値や効能といった「What, Why」が一言で語れず、周囲を腹落ちさせられないという課題認識でおり、本章の目的に対する自分の方向性はまだ見えていない。

92

Ⅷ．7 情報システム開発方法とデータモデル

森 弘之【POA と DOA について】
情報システムを設計する際、POA と DOA という考え方がある。POA は Process Oriented Approach、
DOA は Data Oriented Approach の略である。POA では業務をプロセス中心に考え、DOA では業務をデータ中心に考える。
プロセスを中心に考えることとデータを中心に考えることの違いを、簡単な図を元に説明する。
POA では、業務をプロセス中心に考えるので、先にプロセスを検討し、その後データを検討する。結果として、『データはプロセスをつなぐ糊』のような働きをする。

図表Ⅷ-4 データはプロセスをつなぐ糊

DOA では、業務をデータ中心に考えるので、先にデータを検討し、その後プロセスを検討する。結果として、『プロセスはデータを追加・変更・消去するもの』である。

図表Ⅷ-5 プロセスはデータを追加・変更・消去するもの

POA 的発想がなぜ生まれたかというと、約 30 年以上前に、人件費削減、作業効率化のためにコンピュータ
ーが部署最適な形で使用され始めたからである。あとになって異なる部署をつなごうとした時、その糊としてデータが存在した。しかし時代は変わり、企業として IT をどう活用し武器にしていくかという時代においては、
POA 的発想はあまり好ましいものではない。DOA 的発想で、企業が保持するデータをまず設計し、それを追加・変更・消去するプロセスは何か、という手順で考えないと、まとまったものにはならない。
DOA では、全体を俯瞰し「あるべきデータモデル」を描き、これを基にシステムや業務を考え直す。
例示した二つのモデルにおいて、（記述はしていないが）注文された製品、在庫、売上計上などを追加した場
合、どちらが容易に変更できるのかは確認するまでもない。

93

Ⅷ．8 ビジネスモデル・データモデル・プロセス（業務）モデル

菊川 裕幸

Ⅷ．8．1 ビジネスモデルとデータモデル
我々は、本書で情報システムの高度化のために概念データモデルの重要性について述べてきているが、企業活動を進める上で重要なのはビジネスモデルをどのように捉えてシステムに組み込み、企業として活動していくかであり、そのための概念データモデルとなっていなければならない。企業存続のためには、拡大再生産を保証する収益と、顧客からどのように評価されるかという顧客満足度がミッションとして組み込まれ、それを高める活動の一環として、情報システムの高度化を位置付けていただきたい。
図表Ⅷ-6 は、（1）製造業のビジネスモデル（超概要）と（2）製造業の超概念データモデルを示したものである。

図表Ⅷ-6

製造業のビジネスモデル（超概要）と 製造業の超概念データモデル

製造業におけるビジネスモデル（超概要）は、図表Ⅷ-6（1）に示したように、顧客から「受注する―造る―届ける」という三つの活動の上で企業存続の基盤たる「収益」を得ていることが分かる。そのミッションは、「収益最大化」と「顧客満足度」と表現され、製造業の全体像が捉えられる。
サービス業においては、「造る」を「サービス」と読み替えることで、同様のものとなると考えている。
この活動に必要とされるデータは、三つの活動「受注する―造る―届ける」に対応して収集され、プロセスに応じて遷移しながら活用される。概念データモデルとして表したものが図表Ⅷ-6（2）である。営業部門では、商品カタログを用いて商品の紹介を行いつつ、顧客要求を聞き出して、注文内容を伝える。製造部門は、顧客要求に対応する製造条件にて、製品を製造し、納入条件（荷姿）に対応した加工を施す。納入（物流）部門は、物流条件を加味して、顧客要求に対応した納入時期・場所にお届けする。この企業活動の結果としての対価を得ることで、収益の最大化と顧客満足度の向上の努力を払っている。
ビジネスモデル（超概要）に対応した超概念データモデルを表したが、これに連携したデータが多く存在した上で、企業活動が成り立っていることは、十分にご理解いただけると思う。
94

Ⅷ．8．2 プロセス（業務）モデルとデータモデル
日本の情報システムは「実世界の写像」として構築され、1980 年代の日本企業の競争力を高める役割を果たしてきた。業務モデルをプロセスモデルとして描き、ウォーターフォール型のシステム構築により、プロセスの自動化・省力化を果たし大きな成果を得てきた。
しかしながら、社会・経済環境の変化や IT 技術の進歩に応じて変化させねばならない企業の情報システムにとっては、このようにプロセス中心（POA）でシステム構築・改修を繰り返してきたことが肥大化・複雑化・ブラックボックス化につながる大きな落とし穴になってしまった。EA（Enterprise Architecture）の視点からビジネ
スモデル・データモデル・プロセスモデルをきちんと分けて考え、システムを変化に素早く対応させるものとすることができてこなかったと考えている。
以下に POA と DOA をモデルの観点から論じる。
ウォーターフォール型システム開発では、業務部門と IT 部門が共同でビジネス要件をまとめ、プロセス（業務）モデルを描く作業を長年にわたって実施してきたが、実際のビジネスをプロセスモデルに写し取ることは図表Ⅷ-7 に示すように極めて難しい。
図表Ⅷ-7 は、プロセス（業務）モデルの描き出し時に起きやすい問題の一例を表したものである。

図表Ⅷ-7 プロセス（業務）モデルの描き出し時に起きやすい問題

実際の業務をしている方と一緒にプロセス（業務）モデルを描くと、・ 複数の業務担当者の話を繋ぎ合わせないと全体がわからない。
・ 業務担当者にとって重要なことが強調され、本来の業務の重要なポイントが抜けやすい。
・ 『 何故そうしているか 』（業務の目的やゴール） が不明瞭なことが多い。
・ 要件をまとめても「漏れ」「不備」があれば、開発工程で手戻りとなる。
・ システム改修の時は、全体のプロセスを確認しないと不具合の原因となる。
など、ビジネスをプロセスとして写し取り、システムに落とし込むことの難しさが存在している。また、プロセス（業務）内容を「要件定義」として表すことの難しさ、限界が生じていたと考えている。

95

一方、ビジネスに不可欠なデータに着目し、データモデルを描いていくと・ ビジネス（業務）プロセスは変化しても、ビジネスに必要なデータが普遍的に存在することが理解でき、データの関連性が見えてくる。
・ 業務プロセス（アプリケーション）が、最終的に必要となるデータの「創出・加工・追加・変更・消去」のために存在することが見えてくる。
・ データとプロセス（アプリケーション）を分離して考えられるようになる。
・ データの意味内容まで議論することで、そのデータがなぜ必要か、何のために必要か、どのように使われるかなど、各々のデータの位置づけが明確になり、ビジネスに対する理解が深められる。
➡システム構築で必要となる「データ定義やデータの正規化」が図れるようになる。
EA（Enterprise Architecture）の考え方に則り、言い換えると、概念データモデルに則って DA 層で保有するデータは、BA 層のビジネスの目的やゴールを写し取って AA 層に確実に伝達するとともに、担当者間で共有されてプロジェクトの理解を深める役割も果たしている。TA 層も含めて考えてみると、データは、ビジネスからプロセス（業務）や IT への橋渡し役になっているとも言える。
求めるデータで合意できれば、データとアプリケーションを分離することができ、お互いが自由になることで、システムの柔軟性が上がる。普遍的なデータを共有しているので、組織の役割分担や実施順序などの業務（アプリケーション）の自由度が増し、変化にも追随しやすくなる。さらに TA 層における IT の自由度が飛躍的に向上し、パッケージ／サービス／スクラッチの選択や、IT インフラの種々の組み合わせが容易になる。パッケージと業務の食い違いをアドオンで修正するのではなく、データモデルが一致しているか否かで評価し、適正なものに導くことが可能になる。
このように、データモデルを描いてシステム構築する DOA の方が、プロセス（業務）モデルを描いてシステム構築する POA よりもいくつかの点で優れていることは明らかである。
DOA の優位性を整理し直すと、次の二つにまとめることができる。
①

変化に強いシステムができること

・日本企業では、固定的なビジネスモデルで、それにあったプロセスができ上がっていた状態で、「プロセスを省力化すること」を目的に情報システムを導入してきた。
・要件定義は、既存のプロセスをトレースすることそのものを意味していた。
・できあがったシステムは省力化には効果を上げたものの、既存プロセスに張り付いたシステムであるため変化への対応力が弱くなってしまった。
・BPR のような既存プロセス自体を変えようとする場合、さらには DX のようなビジネスモデルを変革するような場合には大きな足枷になってしまう。
・しかし、DOA で作られたシステムは、このような変化への対応がしやすくなる。
②

既存のビジネスが可視化しやすくなること

・日本企業のビジネス現場のオペレーションは、とても属人性が高く、日々の仕事がどのように行われているか、なぜそのように行われているか、という根本的なところがかなり曖昧だった。
96

（終身雇用を前提として雇用流動性が低いことが背景にあり、曖昧であることはデメリットばかりではなく、自分の守備範囲を少し超えるような作業をバックアップしあうことで、高品質を維持することができたともいえる）
・曖昧なビジネス現場に、情報システムを導入しようとしたとき、要件定義で業務プロセスを書く
こと自体が大変で、結果として抜け漏れも多く出てしまった。
（要件定義のみに頼ってシステム構築することの限界もこの辺りにあったと考えている）
・ここに DOA を導入することで、現在実施しているビジネスの本当の意味が関係者全体で理解・共有化
しやすくなった。ビジネスの可視化が容易になり、結果的によい設計ができる。
筆者も、大企業 2 社の合併に際し、新たな統合システムを構築するプロジェクトに携わった経験を持つが、統合 2 社のプロセス（業務）を一つにしてシステム構築をしようとして行き詰った経験がある。従来の POA によるアプローチを続けていれば、システム統合プロジェクトの破綻を経験することになったと今も考えている。この時、新会社のミッションは何かを整理し「ビジネスモデル」を考え、両社の担当者で「概念データモデル」を描くことで、仕事の言葉やプロセス（業務）は異なっていても、ビジネスで使われる「データ」は普遍的に存在することに気づかされた。そして「概念データモデル」を情報基盤に据えて新統合システムを構築したことで、両社の業務担当者の理解が深まり、成功裏にシステム構築を完成させた経験を持つことができた。
この時に作った「概念データモデル」は、その後も情報基盤担当者によって綿々と維持管理され、15 年以上経過した今も基幹システムのデータモデルとして使われ、世の中の変化に素早く対応できている。振り返ってみると、「変化に強いシステム」ができ上がり、「既存のビジネスを可視化できていた」ことにつながっていた。DOA の重要さを深く味わった経験でもあった。
1970 年代から 50 年（半世紀）にわたって POA（プロセスモデルを描き要件定義）でシステム構築をしてきた多くの方々にいきなり概念データモデルを描いて DOA 開発を提言しても受け入れ難いとも言われるが、筆者の POA 開発から DOA 開発に切り替えて成功した経験から、愚直に取組むことで習得できると断言できる。
デジタル化や DX の時代を迎え、データの重要性が増す中、DOA は不可欠のものになってきているだけにビジネスモデルをデータモデルに写し取り、プロセス（業務）モデルにつなげていくことは、益々重要になってきていると考えている。

Ⅷ．8．3 プロセス（業務）モデルとデータモデルを共存させてデータを大切にプロセス思考で仕事をしてきた方にいきなり「要件定義は止めろ」とまでの暴言は吐かないが、であるならば、プロセスモデルとデータモデルを一緒に描くことは是非お勧めしたい。そして、そこで描いた概念データモデルを大切にしていただきたい。
そこで得られる価値は、以下のようなものである。
・システム実装のデータベースの基礎ができ、安定したデータベースが得られる。
（＊）「概念データモデル」⇒「論理データモデル」⇒「物理データモデル」
・業務部門と IT 部門で一緒にデータモデルを確認することで、課題の共有化ができる。
⇒ 業務系スタッフのシステムへの理解が深化し、ビジネス変革につなげやすくなる。
97

・意識変革に威力を発揮する。
⇒ 自信を持って変革課題を議論できる。
情報システムは、社会・経済環境の変化や IT 技術の進歩に応じて変化・進化させていかねばならないという宿命を負っている。情報システムの中に業務プロセスを埋め込み固定化してしまうことを防ぎ、データとプロセス（アプリケーション）を分離する DOA により、柔軟なシステムとして開発・維持していくことが可能となる。
このことを肝に銘じて、データを活かす情報システムへの高度化に取り組んで頂きたいと願っている。

＜参考文献＞
安保秀雄・著、日経コンピュータ・編（2011）『IT による業務改革の正攻法～JFE スチールの挑戦』
日経 BP

Ⅷ．9 データモデルなんて嫌い？

赤 俊哉

ここからはあえて乱暴ともいえる考え方を展開する。データモデルというものが置かれている現状、さまざまな立場にある人達がデータモデルをどう捉えているか、そして今後どのように進めていくべきか考察していく。

Ⅷ．9．1 デジタルマーケティングと情報システムの乖離
デジタルマーケティング界隈でよく使われている「データドリブン」の「データ」とデータモデルの「データ」は同
じものを指しているのだろうか？
デジタルマーケティングをテーマとした著名なマーケッターの講演を聴きに行ってもデータモデルの話が出てくることはない。マーケティング関係者はデータモデルの価値が全くわかっていないのではないか？価値がないと思っているのか？それともそんなものがあること自体知らないのか？
データモデルがデータのつながりを確保するために有効であり、経営に大きな価値をもたらすと理解しているのはあくまで一部の IT 担当者だけに過ぎないのではないか。もしそうだとしたら、このような現状ではデータモ
デルの価値に対して一部の人が声を上げても残念ながらほとんどの経営者に響かない。本当にデータの本質、
データモデルの価値を理解している経営者しかデータモデル作成にコストと時間をかけるまでの価値を認めない。根回しがうまい CIO がうまく予算を取り付けてくれば良いのだが、そこまでデータモデルに価値を見出している CIO は少ないだろう。
本来、マーケティングにおいても今まで以上に行動データと属性データの結びつきを深めることによりデータの価値は増大するはずである。しかし Web ベースで取得できるレベルで充分と思っている人がほとんどではな
いか。
・・・これが日本の「データ」に関する真実、でも事実ではない。では我々は事実をどのように世の中に突きつけたうえでそれを真実として理解してもらえるようにすべきか、もう一度再考すべきである。
➡マーケティングと情報システムが「データ」を通じて融合することにより、増大する価値の追求が可能になる。

98

Ⅷ．9．2 モデル・・・面倒くさい
随分前の話になるが DOA という開発手法が流行った時にデータモデルは設計図面として少しだけもてはやされた。ただ実践しようとした人が、興味持って勉強しようと書店で書籍を探してみると、多くのデータモデルマ
ニアが大して変わりがないのに我流の記法を主張しあっている書籍ばかりしかなく、立ち読みでパラパラページ
をめくっているだけでも何が何だかわからなくなって止めてしまった、という話をよく聞いた（バランスがとれているのは真野正さんの『実践的データモデリング入門』くらいか）。そうこうしているうちに DOA ブームは何とな
く尻つぼみになっていった。
・・・「どれも大して変わらないのに、おおげさに自分の正当性ばかりをアピールする姿にうんざり」
特にドメスティックな記法は混乱の元である。データモデルの記法は IE、IDEF、もしくはクラス図に統一すべきではないか。
・・・また「概念データモデル」という言葉も意味するところが人によって違う。これも混乱の元である。グローバルという言葉は個人的には好きではないが、用語の意味に関してはグローバルを指向すべきではないか。つまり「概念データモデル」の意味付けは DMBOK に準ずるべきと考える。
その後、モデルはオブジェクトモデルに主役の座を譲った。記法は UML で統一されて、モデリングが銀の弾丸になるのではと期待を寄せられた。
ところがオブジェクト指向開発の失敗が続いたことにより、その失敗の原因がモデルそのものにあるかのような空気ができ上がっていった。こうしてオブジェクトモデルは一部の高度な技術を持つ「マニア」のものになっていった。
・・・一般のシステム屋がモデルに対して感じているアレルギーは我々が考えている以上に大きい。おそらく、面
倒な割に「成果」が見えないという誤解、つまりきちんと価値が理解されていないことによる。
次にもてはやされたのがアジャイルである。アジャイル宣言を都合よく解釈して「設計ドキュメントなんて残さな
くてよい」、「モデルなんか書くよりどんどんソースを書こう」という風潮ができ上がった。もちろんこれはアジャイ
ルの本質とは異なるのでこういったエセアジャイルのほとんどは失敗する。そうなると「やっぱりアジャイルなんて駄目」という意見もまた一部でささやかれるようになった (これはモデルの話としては余談です) 。
・・・モデルはシステム開発の現場では脇役になってしまった？

Ⅷ．9．3 アジャイル・・・そしてマイクロサービス
アジャイル、クラウドベース開発、DevOps と共にもてはやされているのがマイクロサービスである。当初は「SOA の現実解」ともいわれていた。現実解を追求しようしているマイクロサービス界隈の人達は最初から全体を鳥瞰可能とするデータモデルなんて書く必要性を感じていない。データに関しては、後でサービス同士の連携
99

を図ればよい、といった感覚しかない。アジャイル、マイクロサービスの真っただ中でサービスを開発している人は自分達のサービス範囲のデータにしか興味がない。またそれでなんとかなっている。

Ⅷ．9．4 IoT、AI、データサイエンス
IoT、AI といったトレンドはまさにデータの世界。ところがこの二つを活用するためにデータモデルがどのように役立つのか誰もきちんと語っている人がいない。書籍でも上記トレンドについてデータモデルをどう活用していくか記述しているものは私の知る限りではない。
データサイエンスの世界でも積極的にデータモデルが語られることはない。分析する前にデータをきれいにするのが大変である、といった話ばかりである。

Ⅷ．9．5 業務分析手法としてのデータモデル
業務分析を行う際、どこから手をつけるべきであろうか。ほとんどの場合は、何らかの AsIs、そして ToBe の業務フロー作成から始めることだろう。つまり業務という視点で捉えた場合、どうしてもプロセス中心に考えることになる。業務分析と謳いながら業務フローをはじめとするプロセスモデル中心の分析になることがほとんどである。特に業務改善を目的とした場合は顕著である。
業務分析においてデータモデルが重要であると声高に主張しても再構築含む何らかのシステム開発の機会がなければ、データに着目してデータモデルが作成されることはない。
ビジネス、業務を「見える化」し、新たな価値を創出するためにプロセスモデルとともに、データモデルが不可欠であるということをアピールし、さらに業務分析においてもデータモデルを書くべきである、という考えが世の中で当たり前にならないと、データモデルはあくまで情報システム関係者のための、開発用、データベース定義
用言語という捉えられ方しかされず、業務分析の際に顧みられることはない。また残念ながらプロセスモデルとデータモデルを駆使して業務分析を行うことができる人材もいない。
データモデルを書ける経営、業務コンサルタントが一人でも増えることを切に願う。

Ⅷ．9．6 「エンタープライズ」「データ」はベテラン男性の世界!?
エンタープライズ系、所謂基幹系システム担当者、データモデラーに共通しているのは「比較的高齢」「男性」
であること。この多様性の時代に限られたセグメントの中にしか価値を理解し、かつ実践できる人がいない。
データがつながる価値と共に、それを見える化することによる価値、そしてデータモデル自体の価値、これらはエンタープライズ視点で物事を見る立場でなければ理解できない。そうだとすると、現状「高齢」「男性」中心になるのはやむを得ないか？
・･・何故「若者」「女性」はデータモデルの世界に足を踏み入れないのか、日本の情報システムの未来のために真剣に考える必要がある。

100

Ⅷ．9．7 今後の展望案
案 1：データモデル＝おっさんの世界？ と割り切るか。おっさんはおっさんなりに我が道を行くか？
（シニア技術者のサバイバル手段として…レガシーのお守りとデータモデルはリタイア後のセカンドキャリ
アとして確立する、これも人生 100 年時代において有効な考え方かもしれない）。
案 2：若者にデータモデルのすばらしさを理解してもらって習得してもらうか？
案 2 を実現するのは今となってはとても厳しい道のりである。でも案 1 しかないと諦めたくもない。
ただ、いずれの場合においてもデータモデル自体がなくなることはない。それならばデータがつながることによって新しい世界が広がることを今まで以上に強く継続してアピールしていくしかない。
➡「データモデルってものを書くと、そんな新しい世界が一目でわかるようになるんだぜ。」
データモデル屋さんは「口べた」でアピールがへたな人が多い。もっと饒舌になって欲しい。
本書では理論として、データ経営に必須であるシステムの高度化を実現するには、データのつながりを確保することが「データ活用の推進」の観点からも極めて重要であること、そのためにデータモデルの作成が不可欠であることをアピールすることになる。もし次の機会があるならば、徹底的にデータモデルを使ってデータのつながりを確保していくことが更なる価値を生み出すことを強くアピールするとともに、その実践方法について世の中に提起してみたい。マイクロサービス、クラウド、IoT、AI といったトレンドキーワードにデータモデルを武器としてどう切り込んでいくか、その実践方法とともに、実践することにより生み出される価値を見せつけることが必要である。
「そこまでやれば、本書が、システム屋によるシステム屋のための、そして経営者にも理解可能な、日本の DX
を正しい方向に導くために価値ある IT 書になるのではないか」とあくまで私見ではあるが強く感じている。

Ⅷ．10 データモデル普及の処方箋：データモデルの価値を知る三つのステップ

三輪 一郎

データモデルの価値を一度理解してしまえば、その有効性を疑う余地はないかもしれない。ただし、未だ理解に至っていない者にとっては大変難しく、データモデルが何を表しているのか、そこから何を読み解くことができるのかは理解できないだろう。
そこで、データモデルがなぜ解りにくいのかを、打ち手と共に考えてみたい。

Ⅷ．10．1 データモデルの価値が感じられない？
ケミカルの素養を持ち訓練を受けた技術者が、データモデルを容易に理解した話をよく聞く。そもそもケミカ
ルは、元素記号の組み合わせで物質の特性を表現し、理解する。小さくて目には見えなくても、素材（元素）の組
み合わせから発揮する機能を見通し、創造する訓練を受ける。そしてそれを理解できた者だけがケミカルの技術者となる。素材系の技術者も同様だ。溶解炉に投入されたごく少量の炭素や硫黄が金属の特性にどんな影響を与えるかを幾度となく考察し、検証し、実証する。物質が発揮する特性は、素材と構造で決まるという事実を101

理解するには、体験を伴う思考訓練が必要なのである。ケミカルの素養がなく訓練も受けていない一般人にとって、化学式は、古代遺跡の文様か、モダンな壁紙の絵柄にしか見えない。
データモデルは情報の部品表であり、ビジネスの元素表である。だが相応の訓練を受けていない者にとっては、一般人の目に映る複雑な化学式のようなものでしかないだろう。
➡体験を伴った思考訓練に相応の時間を割けば、データモデルが理解できる。

Ⅷ．10．2 データモデルからは動いた様が見て取れない？
データモデルはそもそも、静的な表現を担う図面である。動的な説明図ではなく、静的な部品表である。動いている水車の映像ではなく（組み上がった水車の画像でもなく）、バラバラの木片達の三面図である。
動作している様が想像できない者にとって、動作していない部品の説明は、詳しいほど解かりづらい。貴重なはずの部品の意味も、どこに取り付ければ価値を発揮するかも、動作と組み合わせて表現されなければ理解できないだろう。
【業務知識不足】
自動車の運転を見たことがなければ、ハンドルですら、用途不明の円形の物体である。ビジネスの部品である
データが動作する場面を想像できない者、すなわちそのデータを必要とするビジネスシーンが想像できない者には、データモデルは意味をなさない。
【業務理解不足】
運転ができても、衝撃でエアバッグが動作している様が想像できなければ、爆弾と風船が自動車に必要不可
欠な部品であることは理解できない。
データモデルはビジネス情報の部品表である。だが動作する様と動作のバリエーションを理解し、どのシーン
でどの部品が結果にどう関わるのかを熟慮するようなドライバーでなければ、部品表からその車の良し悪しは評価できない。業務知識があり、かつ深く理解している者でなければ、データモデルで新システムの良否が判断できることは、理解できないだろう。
➡業務知識とその深い理解を得れば、データモデルに表現された、データの価値が理解できる。
【コラム：「もの」と「こと」を組み合わせてビジネスの動きを読み取る】
データモデルからビジネスやプロセスが動いた様子をどう読み取るか？ 二つの方法があると考えている。
一つ目は、描いたデータモデルを用いて、プロセス（業務）が成り立つかを検証することである。システム開発の過程ではこれを、業務部門と一緒に行う「ウォークスルー」と呼んでいる。特に、データが遷移する過程を追っていくと、どのアプリケーションがどのデータの「創出・加工・追加・変更・消去」を司っているかが良く分かる。
Ⅵ章で提案した日本型 3.5 層の EA モデルで AA 層と DA 層を同時に考える検証が行われ、分離したデータモデルを用いてビジネスの動きが読み取れるのである。データの遷移が、データモデルの動きとして理解102

できるようになる方式として、ビジネスシーンを想像しながら行う「ウォークスルー」をお勧めする。
二つ目は、動的概念データモデルを描くことである。図表Ⅷ-8 にその標記法と例を示す。
描いた静的概念データモデルから「要のこと（データ）」を選び、その遷移に関わるプロセス（アプリケーショ
ン）を連携させながら、遷移の過程を描くことで、動的概念データモデルが表現できる。
図表Ⅷ-8 動的概念データモデルの表記法と例
動的モデルの表記法

動的モデルの例（顧客）状態変化の過程（活動をおよその⽣起順に並べる）
活動名
活動の識別⼦
活動の属性

〜
状態変化

実体種類名

顧客登録

属性変更

取引終了

識別⼦
顧客名

識別⼦
顧客名

識別⼦
顧客名

属性
住所
代表者
与信限度

属性
住所
代表者
与信限度

属性
取引終了

⽣成

属性値を
変更

取引終了
（抹消）

顧客
識別⼦：顧客名

識別⼦

参考：『働く人の心をつなぐ情報技術 概念データモデルの設計』より

このモデルでも、アプリケーションがデータの遷移を司っていることが分かり、ビジネスの動きが検証できる。
「動的概念データモデル」は、静的な「もの」と動的な「こと」を分離し、組み合わせて表現する手法として、Ⅺ章で紹介する「CRUD マトリクス」とともによく知られている。どちらも、「もの」（データ）と「こと」（アプリケーショ
ン）を明確に分離し、組み合わせて描いていることがポイントである。
➡データモデルは、静的な部品表としての価値だけでなく、「ウォークスルー」を行うこと、もしくは「動的概念データモデル」を描くことで、動的要素も表現でき、ビジネスの動きが読み取れるようになる。
＜参考文献＞
手島歩三 監修・著 小池俊弘・松井洋満・南波幸雄・安保秀雄 著（2011）『働く人の心をつなぐ情報技術 概念データモデルの設計』白桃書房

Ⅷ．10．3 データモデルの理解はデータ加工の経験を求めるのか？
新型コロナ禍である。昨日までジャガイモの種類に興味などなかった旦那衆が、にわかにポテサラには男爵だ、
カレーにはメークインだと語り始めた。
103おおむね人は、加工プロセスに関わって初めて、素材の重要さに思い当たる。今までカレーの具などに興味がなかった旦那衆も、自炊を始めたとたんにジャガイモの品種の違いに興味を持ち始める。
さて、情報である。材料がなければ料理はできないのと同様にデータがなければ情報を創ることはできない。
データモデルはスーパーの棚だ。男爵がない？隣町のスーパーまで行ってみよう！データを加工して情報を創ったことがなく、でき合いの画面ばかり見せられてきたユーザーに、この発想は浮かばない。何をどう加工すると何ができるのか。それを知って初めて、必要な材料に思いを馳せるのだ。必要な材料に思いを巡らせるようにな
るには、加工の経験が必要だったのである。
サラダとサンドイッチではダメだ。加熱処理により様変わりする素材の変化を知って欲しい。エクセルではダメだ、せめてアクセスで、複数のテーブルからさまざまな画面が作り出せることを体感して欲しい。
➡作り手の目線でものづくりに関わった経験が、データモデルの価値を教えてくれる。
なぜデータモデルの価値が解らないのか、解ってくれないのか。気付きのステップとして以下を踏む体験が、
データモデルの価値を教えてくれると考えている。
ステップ 1．体験を伴った思考訓練を受け、抽象化能力と想像力を目覚めさせる。
ステップ 2．業務知識とその深い理解を得て、本当に必要なものは何かを考える。
ステップ 3．作り手の目線でものづくりに関り、情報の素材とは何かを体感する。
これは筆者の体験に基づく推奨プランである。老若男女を問わず、本書の主張の根底にある「データモデルの価値」が共有できる仲間を、是非増やしていただきたい。

Ⅷ．11 データモデリングの三つの KSF（重要成功要因）

金井 啓一

筆者は、製造業、ネット企業、金融業など、各業界のビジネス部門や IT 部門に対してデータ経営に関わるコン
サルティングを行っているが、ここ数年、特にデータ統合、データマネジメント、データモデリングの案件が多い。
この分野は 20 年以上前のデータウェアハウス・ブームの頃から行われた活動だったが、実は今ほど真剣に取り組む企業は多くなかった。
コネクテッドカーから上がってくるテレマティクスデータや工場 IoT データ、SNS データなど、データ種およびデータ量が膨大になってきた現在、サイロ化したシステムやスパゲッティ状態になったデータやシステムを何とかしなければならないと、多くの企業がようやく考え始めたと思われる。
しかし、どうアプローチしたら良いか途方に暮れる企業が多い。前出した DOA（DOBA・DOCA）を実施するにしても、具体的にどうしたら良いのか、三つの KSF を挙げてみる。
【KSF 1】まずビジネスから考え、ビジネスクエスチョンやユースケースを定義する
・Think Big, Start Small という言葉がある。これは DOA にも当てはまる。ビジネス全体を俯瞰し、発生するデータを見渡し、業務に捉われず“データ”を見る。
104

・DOA により概念データモデルを作成すると言っても、全ビジネスを対象に一遍に作成するのは難しい。ビジ
ネス的に重要度の高い業務エリアから取り掛かるのが良い。
・優先度の高い業務エリアから、業務で発生するビジネスクエスチョンやユースケースを定義し、その業務で使用するデータ種を把握するところから始める。
・データモデルは、ビジネス（実世界）をデータで表現したものなので、本来 IT ユーザーのものではなく、ビジネスユーザーのもの（使うべきもの）である。従って、データモデリングに当たっては、特に概念データモデル、
論理データモデル作成時はビジネスユーザーの参画は必須であり、むしろリードすべきである。
【KSF 2】データモデリングはサブジェクト指向で考える
・利用目的によるデータ整理ではなく、データの主題（サブジェクト）・領域視点で整理する。例えば、販売管理システムを構築する場合、販売管理用のデータモデルを作るのではなく（これは“オブジェクト指向”）、どんな利用（業務）にも使えるデータモデルを作るべきである。
・サブジェクト指向という考え方は、複数の業務アプリケーションで使用できるように、データを主題ごとに保持し、業務から独立させることが目的であり、正に DOA である。
・そうでないと、例えば販売データは販売管理システムでも経理システムでも使うが、それぞれのシステム用にデータモデルを作成すれば二重持ちになり、管理上、コスト上、無駄が発生し、データの不整合が発生する可能性が高くなる。
・統合 DWH の場合だけでなく、業務系システム構築の際もこの考え方は有効であり、システムは業務ごとに構築したとしても、データモデルが統一されていればデータに関わる不整合などの不具合は無くせる。
【KSF 3】データモデリングは、汎用化と抽象化が重要である
・データモデリングを行う際、汎用化と抽象化を意識して行うべきである。それらを行うことにより、ビジネスモ
デルが変わらない限り、長期間使える。
・汎用化は、業務ごとにデータモデルを作らないことであり、業務アプリケーションが変わっても、データモデルは変更不要にすることである。アトリビュート（データ項目）は増えても、基本的に ER 図は変わらない。変わっても若干の修正レベルに留まる。
・抽象化は、例えば個人、社員、組織、自社、取引先などは一括して、PARTY というサブジェクト（エンティティ）で表し、一意性を担保する。“顧客”という概念で言うと、消費者も社員も取引先も顧客になりうるので、別個には持たない。

105

Ⅸ章 IT 部門の役割
赤司 浩文
本章のサマリー

一般的なユーザー企業における IT 部門について、組織発足時から現在に至る経緯の中で、いつ頃からどのような役割を担うようになったかを技術的要素を交えて時系列的に振り返る。その過程で浮かび上がる
課題や軌道修正の内容と対策を論じる。



IT 部門が、前述の軌道修正に際しての使命として、人材育成と日本らしさを継承する為のミドル層活躍の場を提言する。

IT 部門がその重要な役割として果たさねばならいデータマネジメントを担う組織としての意識付けを行う。

日本のユーザー系企業の現在の IT 部門の役割は、一般的には以下の五つに分類できる。
（1）IT 戦略・システム企画（2）業務システム（基幹システムほか）の構築・運用・保守（3）基盤インフラ（サーバー、ネットワーク、セキュリティ、デバイス関係）の構築・運用・保守（4）サポート・ヘルプデスク（5）上記を担う人材の育成

Ⅸ．1 組織発足からの経緯と技術的背景
本プロジェクトでは、企業システムの変遷を整理し、図表Ⅸ-1 のようにまとめた。
現在の IT 部門は営業部門、人事部門、経理部門に比べると新しい組織体で、企業が IT 活用を開始した
1960 年代半ばの発足に遡る。

106

図表Ⅸ-1 企業システムの変遷

出典：飯島雅氏による整理

まずは企業における IT 部門の発足から現在に至る経緯の中で、いつ頃から重要な役割を担うようになったかについてハードウェア、ソフトウェア、開発方法論などの技術的要素を交えて時系列的に振り返ってみる。

Ⅸ．1．1 1960 年代～ 第 1 ステージ
コンピューターが従来の手作業の機械化を担ったこの時代は、業務部門のベテランから業務プロセスを聞き出し、プログラム仕様にしてシステム開発することが IT 部門の主たる役割であった。コンピューターは、合理化、省力化、コストダウンを担うこととなり、経営者が経営企画の一部を担う組織として新設した IT 部門は、脚光を浴び各部門の精鋭が集まって、新しいことや最先端を行く機運に満ちていた。
このステージの特徴は、業務部門のプロが参画するため、業務要件を誤認した実装など起こる余地が無かった点と、技術面では開発したシステムを安定稼働させるために、当時は極めて高価であったコンピューターリソ
ース(メインフレーム)での集中処理だったため、キャパシティにも配慮した設計がなされていたことである。
この時代のシステム化は、きめ細やかな日本人の手作業の機械化やプロセスの自動化をしていくなかで個別の QC 改善活動と結びつき、日本企業の競争力強化に大きく貢献し、「Japan as No.1」と呼ばれる一時代を築く原動力となった。
このプロセスの自動化自体は究極の個別最適であり、後ほどⅩ章で詳細を述べる EA（EnterpriseArchitecture）の構成要素である DA／AA 未分離アーキテクチャーの上で丁寧すぎる作り込みによる機械化・自動化が成功体験として強く刷り込まれた。一方、個別最適が故に経営視点での全体最適・標準化には結びつかず、ボトムアップかつ職人気質により、後に「レガシーシステム」と呼ばれるものにつながっていった。
107

Ⅸ．1．2 1990 年代～ 第 2 ステージ
1980 年代後半のバブル経済から 1990 年代は技術面では超高額なメインフレームから、安価なオープン系
サーバーへ移行することでのコストダウンが進むとともに Windows PC が台頭した。1 人 1 台の PC 利用が進んだのがこの時期であり、分散処理化が進んだ。更に我々が提唱する DOA でデータを格納するデータベース
である RDBMS(Relational Database Management System)が実用レベルになって来たのもこの時期である。方法論としての DOA と実装する RDBMS は本来同時セットで習得し適用する必要があったが、バラバラに展開されたことは振り返ってみると大きな転換点を見逃したのではないだろうか。
この技術変化に伴い IT 部門の要員スキル転換が議論された時期でもある。オープン系への移行による分散処理化に伴い幅広い知見を有する専門性の高い人材が必要となるが、社内リソースが不足していた。そこで、ベンダーへの発注やグループ内での専門要員育成を目的に、経営者は情報システム部門を子会社化し、アウトソース化を始めた時期でもある（図表Ⅸ-2 IT 企業の設立年を参照。1980 年代後半から 1990 年代前半の増加は顕著である）。
構築する情報システムは、部門レベルから部門横断の事業レベルへと拡張し、業務プロセスの見直しなどが行われ始めたが、システムは第 1 ステージの開発方法を継続し、前述のようにサイロ型の DA／AA 未分離のアーキテクチャーによりプロセス中心（POA）で設計され、構築され続けた。
このステージの特徴は、バブル時代の求人難やその後の採用抑制により要員増強が思うに任せぬ中、PC の現場展開によりエンドユーザーサポートやヘルプデスク機能など、IT 部門が新たな役割を担い始めたことである。更に、システム数とシステム間連携の増加により、既存システムの維持管理に人手がかさむ一方、機能追加
や改修・改善に際しては影響範囲が拡がり、改修時に調査に要する負荷が大きくなっていった。その結果、その場しのぎのつぎはぎ対応にならざるを得なくなり、システムのスパゲティー化が進み、益々時間とコストを要する
悪循環に陥った。かつ旺盛なシステム化ニーズに応じるマンパワーの慢性的な不足と業務部門からの要望(要件として整理されていない)の丸投げに対する防衛反応が働き、IT 部門が積極性を失い「言われたことに対応するだけの組織風土」へ変化し始めた。

108

図表Ⅸ-2 IT 企業の設立年

出典：森弘之氏による整理

Ⅸ．1．3 2000 年代～ 第 3 ステージ
コンピューターの2000年問題を契機に、従来の自社の業務だけに特化した事業レベルの手作りシステムから、社内の基幹業務をERP（Enterprise Resource Planning）と称するパッケージを、会社全体あるいはグループ企業全体のシステムに切り替える流れが2000年以降に始まった。また、技術面ではインターネットの発展に伴い、ネットワーク中心の新しい形の集中処理になっていった。具体的には、1台のPCで色々なシステムが利用できるようになっていったので、利用者からは統合されたように見えたが、システムは従来通り第1、第2ステージで作ったサイロ型システムの単位で保持され、一部がERPに置き換わったものの全体構造を見直すことは行われていなかった。
このステージの特徴は、従来はIT部門や情報子会社は、ベンダーと役割分担を決めて社内システムを構築・運用していたが、経営者がIT部門へERP導入と共に社内の業務プロセス見直しや標準化のコンサルタント的な役割を担うことを期待するようになっていったことである。この時期、EA（Enterprise Architecture）モデ
ルを4階層（BA／DA／AA／TA）で認識する考え方が普及し、ERP導入においてはBPR（Business
Process Reengineering）を旗印にしたBA（Business Architecture）領域の見直しを目指した。しかし、ERPで固定された3層（DA／AA／TA）に業務プロセスを合わせる方向にナビゲートすることの矛盾により混乱し、最終的にはERP導入が目的化されるという結末になった事例が多い、という事実は忘れてはならない。
結果として、日本のERPには、多くのアドオンが存在するという結果を招き、バージョンアップを難しくすると同時にERPパッケージを複雑化させてしまった。
109

4階層（BA／DA／AA／TA）のEAモデルに関しては、Ⅹ章、Ⅺ章で詳細を述べる。
また、毎年の情報システムに関わる費用増から、IT戦略やシステム企画などがIT部門でウェイトを増し、主に実務レベルでの役割は情報子会社やベンダーにアウトソースする流れが加速していった。

Ⅸ．1．4 2010 年代～ 第 4 ステージ
自社でハードウェアやデータセンターを有することなく、必要な時に必要な規模の社外リソースを使うことで、利用者がコンピューター資源を意識せずにサービスが受けられるクラウドコンピューティングの時代になってくる。業務システムもSaaS型のクラウドサービスで提供されるようになり、エンドユーザーが直接利用することも可能となり、経営者は「自社の競争優位に向けたITの提供」という幅広い役割をIT部門に期待するようになっている。
このステージの特徴として、まずサービス利用は中身がわからないだけでなく考えもせず「使うだけ」になっていったことが挙げられる。また、IT 部門にとっては、既存で抱えていたレガシーシステム（SoR）が、変更に多大な手間のかかるブラックボックスとなり、また、手間をかけても直せない ERP の維持管理も重くのしかかる。身動きが取れない状態のもと、企業固有の戦略情報システムの本来的な要件である「情報システムは、その企業特有の戦略の変化に合わせて進化するべし（レジリエンスを発揮すべし）」に合わないものとなってしまったことがこのステージの最大の課題であろう。さらに、多くの IT 人材のスキルは、「ブラックボックスは作り直せない、
新しいものは買って使うだけで、オリジナルの戦略情報システムをゼロから設計・実装するスキルがない」という状態になってしまったのではなかろうか。

Ⅸ．1．5 振り返りのまとめ
冒頭に掲げたIT部門の五つの役割を、ここまでの振り返りを通して図表Ⅸ-3にまとめる。
図表Ⅸ-3 IT 部門の役割の振り返り
時間軸
IT部門の役割

第1ステージ 第2ステージ 第3ステージ 第4ステージ 第5ステージ(1960年代) (1990年代) (2000年代) (2010年～) DX(戦略=IT)
POA
DOA
EA,BPR､ERP クラウド

(1)IT戦略・システム企画

担い手

企業IT部門

標準化/コンサル

事業戦略の理解とDAへの展開(2)業務システムの構築・運用・保守(3)基盤インフラの構築・運用・保守

情報子会社／ベンダー
メインフレーム

オープン系

クラウド

情報子会社／ベンダー(4)サポート・ヘルプデスク

情報子会社／ベンダー(5)上記を担う人材の育成

企業IT部門
現在110

第2ステージ以降のIT部門は、経営者の期待する姿に応じて役割を追加し変化させているが、自らの意思ではなく与えられる役割を受け身的にこなす対処療法的に取り繕ってきたと言える。また、役割を果たせている面と必ずしも果たせてない面とがあり、共に宿題を抱えていると考える。
整理すると、第2ステージでのIT部門のオーバーフローに対する救世主として第3ステージにERPが登場し、矢継ぎ早に導入が進んだが、でき合いに任せるという発想により、データモデリングスキル不要論が広がり、ER図を描ける人材が育たなかった。この結果、第2ステージからの宿題だったDA／AA分離の機会を逃したのではなかろうか。また、競争優位領域にはパッケージが適用できないことは気づいていたはずであるが、これも見過ごされ、第4ステージで述べた通り競争優位性を生むその企業独自の事業戦略に沿ってDA／AAを設計し、TAを選択、実装する力が育っていないという現実が、今現在のIT部門の実態であろう。
では、IT 部門はどこで道を見失い身動きが取れなくなってしまったのか？
この視点で改めて図表Ⅸ-3 を眺めると、前にも述べているが、第 2 ステージで DOA という設計手法と
RDBMS という実戦ツールが揃って整ってきたにもかかわらず、第 1 ステージのシステム開発における多大な成功体験から抜け出せず、かつ POA（Process Oriented Approach）でのシステム開発の実務部隊を情報子会社へアウトソース化したことと相まって、内部構造の DA／AA 分離による EA の理解に基づくブラック
ボックス化回避の道よりも、ブラックボックス型サイロ型システムへの入り口を選んでしまったところが、道を逸れ現在に至る始まりであったと考えられる。
ついては、一度そこまで戻って、内部構造を理解し作り替えられるスキルを取り戻さなければならない。
戻ってでも得られる功能はこれまで我々が述べた内容でありご参照頂きたい。
なお、立ち戻る際に IT 部門を狭義(企業内組織)と広義(情報子会社やベンダー)に分けて役割分担するのであれば、DOA の論理データ設計スキルと物理 DB 実装スキルの二面について前者は狭義の IT 部門であり、後者は広義の IT 部門の役割である。具体的には、BA 層で議論されたユーザー企業の事業戦略を最初に写し取るのは、BA 層と DA 層が接する面、すなわち論理データの設計スキルである。物理 DB への実装スキルは、
精鋭のスクラッチ部隊となる情報子会社のエキスパート社員や、パッケージベンダーの技術者に期待すればよいだろう。
もう 1 点述べておきたいのだが、経営者は最終的には「自社の競争優位に向けた IT の提供」という役割を期待しているが、現在の身動きが取れない状況は、それが IT 部門の役割なのか？という認識を経営者に植え付けてしまったのではないだろうか？ その結果、企業内で DX 部門が IT 部門とは別に立ち上げられることにな
り、競争優位な戦略実現という役割は DX 部門に課せられ、IT 部門とは別に活動するか、DX 部門の傘下に
IT 部門を吸収する組織体が現在の主流であり、DX 推進を担う役割は基盤系や実装を除き、現在の IT 部門には期待されていないのが現時点の最大の課題と考える。
この課題に関しては、企業システム・オープン化の最大の失敗要因となった「EUC（End User
Computing）」を思い出していただきたい。実務に精通しているが IT スキルの不足したエンドユーザーにシス
テム構築を委ねたことにより、ブラックボックス化へ突き進んでしまった失敗である。システム構築を担ったベテラン社員の退職やドキュメントの散逸・不備により、システム修正や維持管理もできなくなり、多くの EUC シス
テムが廃棄せざるを得なくなってしまった問題である。余談ながら、現在導入が進んでいる RPA（Robotic
Process Automation)に EUC と似た匂いを感じることを付記しておく。
111

本論に戻って新たに設置された DX 推進部門がこの轍を踏まないことを祈るばかりである。DX 推進は企業にとって最優先課題となっている今、DX 推進部門、IT 部門ともに、以下の対応力を身につけることを考えて頂きたい。
① DX 推進部門は、IT リテラシーを高めるとともに、今までの失敗を教訓として情報システムの EA の理解とデータの重要性の理解を進めていただきたい。業務部門の精鋭が集まる DX 推進部門だけで進めるのが難しいのであれば、IT 部門とのより緊密な連携をとるようにしていただきたい。
② IT 部門は、自社の競争優位に向けた IT の姿・経営戦略に資する情報システムの姿を描き、DX 推進への貢献を果たしていくことを期待したい。ビジネス戦略を理解し DX 推進を担う情報システムに結び付けていくことが難しいのであれば、経営戦略部門や DX 推進部門との緊密な連携をとることに最大限の努
力を払っていただきたい。
情報システムのあり方にとって最大の危機でもあり、この危機を乗り越えていかねば、将来的に企業の経営危機に結び付いてしまうことを指摘しておきたい。
さらに、これまでの経緯や背景を通じてIT部門が全てを能動的に担う組織にはなり得ないことはDX推進を一例に述べたが、経営者自身が自ら一歩前に踏み出す重要性をⅫ章で論じる。

Ⅸ．2 人材育成を担う組織として
前節での振り返りから、失われたスキルと組織力を取り戻す必要性を提言したが、図表Ⅸ-3 のステージに宿題と対策・スキルをマッピングし、図表Ⅸ-4 に示す。
図表Ⅸ-4 IT 部門の宿題と対策

IT部門の役割

時間軸
方法論 他

第1ステージ 第2ステージ 第3ステージ 第4ステージ 第5ステージ
POA

DOA

EA,BPR､ERP

クラウド

DX(戦略=IT)

担い手(2)業務システムの構築・運用・保守

情報子会社／ベンダー(5)上記を担う人材の育成

企業IT部門宿題と対策・スキル
POAの理解→POAサイロ型システム構築スキル
DOAの理解→データモデリングスキル（①）

企業IT部門4層EAの理解→BAをBPRするスキル（②）

情報子会社／ベンダー

ITを選択するスキル→DA(論)でDA(物)/AA/TAを選ぶスキル③）

情報子会社／ベンダー

ビジネス戦略をITで実現するスキル→事業戦略をDA(論)で写し取るスキル④）

企業IT部門現在

以下に図の内容を説明する。
①第 2 ステージで取組み損ねた DOA のスキルを身に着けることにより DA／AA を分離する。
②第 3 ステージで対応し損ねた EA を使いこなすスキルを身に着けることにより BA と AA／TA を DA で112

つなぎ構造を理解する。
③第 4 ステージでは、BA／DA／AA／TA の構造のうち、外から借りる（広義の IT 部門）のは AA／TAに絞ること。すなわち BA／DA は自社（狭義の IT 部門）で守るスキルを持つことを実現する。
④今後の第 5 ステージでは、この構造体系の理解とこれを維持・発展させられるスキルと組織を構築する。
補足すると、以下のような進め方となる。
・DOA がわかる人材育成と組織作り【①、②】
システムの内部構造を分離して認識し、見える化できる人材を育成する組織作りを推奨する。
・BA を理解し DA を通じて AA／TA を構築・選択できる人材の育成【②、③】
ビジネス理解をデータモデルで表現でき、データ要件に基づいて必要なアプリケーションパッケージやSaaS を選択でき、実装先としてクラウドなどの必要な IT インフラを選べる人材育成が必要である。
これらのステップに関する具体的内容は、Ⅴ章、Ⅹ章、Ⅺ章などで述べているのでご参照頂きたい。
一方、④の今後の実践に関しては少し論点を変え、以下の様に考える。
・ミドルアップダウンの意思決定（プロジェクト体制）【④】
今後、これらの組織と人材を生かす方法として、我々は日本的情報システムの高度化のために、ミドルアップ
トップダウンでビジネス変革の意思決定を行うことを推奨する。
オフショア、ニアショア、内製化と連なるキーワードは何を表しているのだろうか。1990 年代に始まった情報
システムの子会社化に続き、国際的な分業にまで至ったオフショア開発など、現在の IT 部門の組織は、役割分
担が行き過ぎた状況にあるのではなかろうか。個々人がそれぞれの持ち場を担いながらも、多能工として相互補完的に力を発揮するという日本人の特性に逆行する組織分担が進み過ぎたのではないか。多くの企業が採用した子会社政策にも、行き過ぎた分業による負の側面が含まれていたのではないか。
内製化が叫ばれるに至った背景には、行き過ぎた分業を再度統合し直す必要性が表れているのではないだ
ろうか。失った価値に気付き、過度な分担や分断から脱却する発想に至ったと考えられる。
では実際にはどうするか。我々は、ミドルアップトップダウンというキーワードに照らして新システム企画の際の意思決定を行うことが重要と考える。
情報システムの高度化は、経営層から管理職まで、すなわち CIO（情報システム部長）から課長、係長まで、あるいは日本では現場の一人ひとりまでが協力して成し遂げるべき課題である。
情報システムを作り変える際、何をどう変えるかのアイデアは、トップからエンドユーザーまでが心を一つにして結成するプロジェクト・チームのメンバー全員から集め、これを現場に近いミドル層が統合し、経営層が戦略に照らして評価する。この結果を概念データモデルで写し取り、新たなアーキテクチャーの上に構築する新たな仕組み（データ／組織／プロセス）に配置して、ビジネスモデルを完成させる。
ミドル層がユーザー部門の中心となってデータマネジメント部門と協力し、全社的な整合性を取って経営層に提言し、理解を得る。これは担当者レベルでは引き受けることのできないミッションである。
データ中心で日本的情報システムの高度化に挑む際は、ユーザー部門のミドル層に、重要な役割を果たしていただきたいと考える。

113

Ⅸ．3 データマネジメントを担う組織として我々はこれまでデータマネジメントの重要性を繰り返し訴えてきたが、前節でお気づきの通りIT部門の役割に、多くの場合はこの言葉が含まれていない。
これは従来の情報システムがプロセス中心で設計され構築してきたことに因るが、企業によっては、オーナー
シップ制としてシステムオーナー(IT部門)／プロセスオーナー(業務部門)を社内組織で役割分担する企業がある。しかしながらデータに関するオーナーシップを定義している企業は少ない。これは、前述の第2ステージで取組み損なったことの一つである。
今後、デジタルビジネスやDX化といった時代の流れに沿うために、プロセス中心設計からデータ中心設計に変革する提言を各章で論じてきたが、その推進はIT部門の役割であり、設計手法としてのDOAの展開とⅪ章で論じる設計図書の維持管理を含めたデータマネジメントを担う必要がある。また、XⅢII章で述べる「データ経営」実現の根幹を担う実データをガバナンス視点でマネジメントする意義をIT部門が十分認識し、今度は受け身ではなく自ら発信する必要があると考える。
また、さらにXⅢ章ではIT部門へ新たに付け加えるミッションを提言させて頂いたのでご参照頂きたい。

114

Ⅹ章 マネジメント業務のカイゼンとデータ統合のためのシステム開発方法論
飯島 雅
本章のサマリー
本章は、DOA を中核にした基幹系システムの開発方法論について以下の論点で解説する。


1990 年代、情報システムの開発環境はネットワークコンピューティングや GUI（Graphical User
Interface）、RDBMS（Relational Database Management System）といった新しい技術に急激に移行した。同時に、これらの開 発環境を活かすための開発方法論の DOA（Data Oriented
Approach）や、データベースに蓄積されたデータの品質管理方法の DM（Data Management）な
どの技術も輸入された。



しかし、前者の開発環境は広く適用されたが、後者の開発方法論 DOA（Data Oriented Approach）
やデータ管理技術 DM（Data Management）はほとんど適用されることがなく、開発された膨大なシステム資産は「サイロ型システム問題」といった負の遺産として DX（Digital Transformation）など
データの高度利用の障害になっている。



DOA が実装のための技術であれば、DOA を適用したアプリケーションパッケージを導入すれば「サイロ型システム問題」は解決するはずであった。しかし問題は解決せず今に至っている。



本章では、DOA は基幹系システム開発の最上流の概念設計工程における情報要求分析にこそ適用すべき技術であり、概念設計のコンセプト（概念データモデル）を論理設計から物理設計、運用までのシス
テムライフサイクルを通して継承させるための基盤技術であること、データ管理はこのコンセプトの維持管理を目的していることなどを論じる。

Ⅹ．1 DOA は何を目指したか
本書では企業活動における情報やデータの重要性について論じてきた。本章では企業活動をマネジメント
しコントロールする管理者や担当者など、データの高度利用者のためのシステム（以下「基幹系システム」）の開発方法論について解説する。
本章で論じるシステム開発方法は、Ⅸ章の「企業システムの変遷」の第 2 ステージ（1990 年代）において、基幹系システムの開発に適用され、その有効性が確認された DOA（Data Oriented Approach）をベースにしたものである。
第 2 ステージ（1990 年代）のシステム開発は、リレーショナル理論を基にするリレーショナルデータベースに蓄積されるデータの活用に焦点が当てられた。中でも基幹系システムは、マネジメント業務（経営管理から部門管理、事業管理、現場業務管理まで）の多様で複雑な「情報要求」への対応を可能にするとともに、マネジメント業務のカイゼンや高度化を果たす役割を担った。
しかし現状は、サイロ型システムと言われるように特定業務の処理はできても、マネジメント層が要求する情報がタイムリーに入手できなかったり、人手によるデータの収集や加工が必要になったりといったデータの高度利用には程遠い状況にある。
115

また、マネジメント業務は提供されるデータを基にしており、これを正しく機能させるためにはデータベースに蓄積されるデータの品質を保証する「データ管理機能」の組織化が必要であった。 残念ながら当該機能の組織化はほとんど進んでおらず、会議においてそれぞれの部門から提出されるレポートの集計値が異なるといった稚拙な問題がしばしば発生している。
このような問題意識をふまえ、本章で紹介するシステム開発方法論は、エンジニアリング手法として DOAを中核に据え、大規模な基幹系システム開発プロジェクトをコントロールするためのプロジェクト管理フレー
ムワークとして EA（Enterprise Architecture）と SE（Systems Engineering）を組み合わせたものである。

Ⅹ．2 マネジメント業務のカイゼンとデータ統合のためのシステム開発方法論
エンジニアリング手法として DOA を中核に、プロジェクト管理フレームワークとして EA（EnterpriseArchitecture）と SE（Systems Engineering）を組み合わせたシステム開発方法論（図表Ⅹ-1 参照）―「情報システムエンジニアリング(「ISE」：Information Systems Engineering)」―を紹介する。
図表Ⅹ-1 情報システムエンジニアリング（ISE：Information Systems Engineering）

情報システムエンジニアリング（ISE）の要点は、・概念設計における、マネジメント層の多様で複雑な情報要求の正確な定義方法
・論理設計における、定義された情報要求を正確に構築につなげるための設計方法
・物理設計における、設計内容を正確かつ効率的に実装するための構築方法
・マネジメント業務を正しく機能させるためのデータ品質の保証方法
・大規模なシステム開発プロジェクトを効率的に遂行するためのプロジェクト管理方法などである。
116

なお、ISE はスクラッチ開発を想定した方法論であるが、概念設計はそのままで、論理設計以降の工程を工夫することにより、パッケージ導入や SaaS（Software as a Service）の利用などにも応用できる。

Ⅹ．2．1 情報システムエンジニアリングにおける二つの管理フレームワークについて
情報システムエンジニアリング（ISE）に適用する二つの管理フレームワークのうち、SE（Systems
Engineering）は情報システム開発プロジェクト工程の V 字モデルとして広く知られ活用されるもので、ISE もこの管理フレームワークを適用している（章末の「参考：システムズアプローチ」を参照）。
もう一つの EA（Enterprise Architecture）は 1980 年代後半にザックマン（John A.Zachman）が提唱した情報システム開発の管理フレームワークである（図表Ⅹ-2）。
図表Ⅹ-2 エンタープライズアーキテクチャー（EA：Enterprise Architecture）

ISE では EA の四つのフレームワークを相互に独立した専門工学領域として扱い、専門性の高い技術者による作業の効率化や作業品質の向上、さらに作業の並行化（コンカレントエンジニアリング）による開発期間の大幅な圧縮を狙った。

Ⅹ．2．2 ER モデル（Entity Relationship Model）によるデータ品質の保証
エンジニアリング手法として採用した DOA（Data Oriented Approach）のモデリングアーキテクチャ
ーは、リレーショナル理論を基にした ER モデル（Entity-Relationship モデル）である。
ER モデルは、正規化ルールにより、対象の系（ここでは基幹系システム）全体の中で唯一のものとしてデータ属性を定義することを要求する。この定義により同音異義語や異音同義語の発生を抑える効果がある。
また、マネジメント層が要求するデータの精度（売上データの集計元期間や有効桁数など）をデータ属性の要件として定義することで基本的なデータ品質を保証する。

117

Ⅹ．2．3 三つのタイプの ER モデルによるシステム全体構造の整合性維持
ISE では開発工程に沿って概念データモデル、論理データモデル、物理データモデルの三つのタイプのER モデルを適用している。各モデルの目的や特徴は図表Ⅹ-3 の通りである。
図表Ⅹ-3 情報システムエンジニアリングにおける三つのタイプの ER モデル

ISE では原則として、概念データモデルと論理データモデルに正規化ルールを適用し大規模な基幹系シス
テム全体の整合性の維持を図っている。また、アプリケーションの特性やパフォーマンスなどの必要性から冗長化などの対策をした箇所は、物理データモデル上で明確にした上で DM（Data Manager）が管理する。
ISE では、マネジメント層の情報要求分析の品質を最も重視する。前述のように、正規化ルールをベースに設計される概念データモデルは一定の品質を確保することができるが、ここではマネジメント層の情報要求の網羅性が重要である。下流工程における設計変更の原因の多くは、上流工程（概念設計や基本設計）
におけるユーザーの「情報要求」の分析の不備によるものである。日本では、作業の自動化のために業務プ
ロセスの「要件定義」に重きを置いてシステム構築を進めてきたが、マネジメント業務の定義が曖昧で、「情報要求分析」の精度低下の原因になっている。
SE（Systems Engineering）の V 字モデル（図表Ⅹ-参考 1）における下流工程のシステムテストで発現する不具合の多くは「情報要求」の分析の不備に起因するもので、大きな手戻りや再設計が必要となり、
開発プロジェクト全体の QCD（Quality、Cost、Delivery）に多大な影響を及ぼしてきた。
概念設計を「粗い設計」と捉える向きもあるが、これは大きな間違いである。曖昧な業務の「要件定義」の精度を高めるために多大な努力を払うよりも、むしろマネジメント層を巻き込み、マネジメント層の要求を網羅し、整合性の取れた概念データモデルの「精緻な設計」を行うことの方が重要である。そのためには、モデリングとファシリテーションのスキルを併せ持つ SA（System Analyst）と DM（Data Manager）の配置が不可欠である。また、マネジメント層ユーザーを含めたプロジェクト体制を一定期間組む必要がある。
論理設計～物理設計では、DA（Data Architecture）層を中心に置き、BA（BusinessArchitecture）層や AA（Application Architecture）層、TA（Technical Architecture）層の設計レベルと合致させるように、DA 層を連携する各層間のハブとして機能させ、全ての層の足並みを揃えさせることが重要である。
並行作業の管理上の問題の一つは「設計変更」への対応である。ISE では対策の一つとして DA 層を設
118

計変更のハブとして機能させることにより、システム全体の整合性の維持を企図する。
具体的には、BA 層や AA 層、TA 層の設計変更は連携する DA 層に通知され、モデルに変更（属性やアトリビュート追加変更など）があれば DM（Data Manager）の承認のもと、論理データモデル、開発用物理
データモデルの順でモデルを変更し、データとアプリケーションの関係が表現される CRUD 分析表を基に関連する AA 層、BA 層、TA 層に通知され、それぞれの領域で設計変更が実施されるといった手順により変
更管理を行い、足並みを揃えさせるというものである。
また、運用工程でも論理データモデルと物理データモデルは継続的に維持管理されなければならず、シス
テムの修正改善も変更管理とほぼ同様の手順により実施される。そのためには DM（Data Manager）とDBA（Database Administrator）技術者で構成されるデータ管理チームはプロジェクト終了と共に解散
するのではなく、パーマネント組織としての組織化が必須であり、データ管理機能の組織化の一形態である。

Ⅹ．2．4 概念設計～マネジメント層の多様で複雑な情報要求の定義の進め方～「概念設計」は、SA（System Analyst）をファシリテーターとして USA（User’s System Analyst）
が中心になって進められ、「概念設計」の成果は「論理設計」工程に引き継がれる（図表Ⅹ-4）。
図表Ⅹ-4 概念設計の進め方と論理設計への連携「概念設計」における「情報要求分析」は、ミッション遂行のためにユーザーが必要とする「情報要求の収集」と、正規化ルールによるデータ項目の概念データモデル構築の順で進められる。「情報要求分析」の精度を高めるためのポイントは「管理帳表サンプル」で、ユーザーが独自に作成した Excel 帳票や手書き帳票、あるいは情報伝達のために使われているメモやイラストなど、実務で使われているモノの収集である。
「概念設計」の作業は、USA（User’s System Analyst）と SA（System Analyst）の協働作業により進められ、両者の連携こそが概念設計の品質向上ばかりでなくプロジェクト成功の鍵となる。概念設計の119

品質は USA の選任と管理帳表サンプルに大きく左右される。経験的に、USA は現場管理者や経営層の要求を熟知して経営層に情報を提供しているミドルマネジメント層が最も相応しい。
「概念設計」の成果物は「論理設計」の各専門領域の並行作業（コンカレントエンジニアリング）に引き渡される。
一般的に、組織のミッションと達成目標を定義し、目標の達成状況を可視化するために、KGI（Key
Goal Indicator）や KPI（Key Performance Indicators）などの測定指標を設定する。上位のミッションに「収益目標」や「顧客満足度」を設定する。ミッションを分割し、分割した各ミッションに「受注目標」や「生産目標」などの目標を割り当てる。各ミッションは目標を達成するためにさまざまな KPI を設定しこれをコントロールする。これがマネジメント業務であり、情報要求はミッション達成をコントロールするために必要な情報のことである。
分割されたミッションは相互に連携して上位のミッションの目標を達成する。分割されたミッションは BA（Business Architecture）層に引き渡され、作業レベルまで分割され業務フローや業務マニュアルが実装される。
情報要求を構成するデータ項目を抽出し正規化ルールに基づきデータ間の関係性により概念データモデ
ルを構築し、データ定義要件と共に DA（Data Architecture）層に引き渡す。論理設計で論理データモデ
ルの設計とコードやデータを定義し、物理設計で物理データモデルを設計し、開発用データベースと本番用
データベースを実装する。
情報要求のタイミングをもとに操作するデータ項目と、それぞれのデータ項目の生成、蓄積、加工、活用、消去などのデータの変化・遷移などの機能要件を AA（Application Architecture）層に引き渡しアプリ
ケーション機能を設計し実装する。
ユーザーが利用する UI 要件（デバイスの選択なども含む）や開発環境要件などの非機能要件（インフラ要件）を TA（Technical Architecture）層に引き渡し開発環境や本番環境を構築する。
「情報要求分析」作業は管理帳表サンプルを基にした SA（System Analyst）による USA へのヒアリン
グにより進められる。ヒアリングで確認する内容は、管理帳表サンプルを活用する業務名や活用の目的、タイ
ミング、利用者、帳票サンプルを構成するデータ項目の意味や計算式、データ項目の識別子、データとデータの関係性などである。
SA は管理帳表サンプルのヒアリングを行いながら、その場で概念データモデルを作成していく。
この協働作業を通して USA のシステムへの理解を、SA はビジネスへの理解をそれぞれ深めることができる。概念データモデルを描く過程で、現プロセス（業務）の矛盾や現行システムの課題を明らかにし、理想とするビジネスとシステムの検討につなげる。
システムのユーザーである USA は IT の専門家ではないため、概念データモデルを理解できないという見解もあるが、ミドルマネジメント層は自分たちが扱うデータの発生元やデータの条件、データの加工手順などを熟知する業務のプロフェッショナルであり、これを可視化する概念データモデルを理解することができるだけでなく、その場でモデルの不備を指摘することもできる。プロジェクトを進めていくほど協働作業で理解を深めてきた効果が表れてくる。参加する USA が概念データモデルを理解できない場合には、USA の力
量不足（業務におけるデータの意味や活用方法の理解不足）や担当する SA のファシリテーションスキル不足について再考すべきである。USA も SA もビジネスをデータの管理構造で表現する概念データモデルを描く努力をすることが、DOA（Data Oriented Approach）による基幹系システム開発の「肝」である。
120

概念設計の品質を担保するためには、SA がデータモデルを作成しながらその場で、正規化ルールを基に情報要求の妥当性や、ビジネスルールの矛盾や問題を指摘し、USA に問題を伝えその解決を依頼することが重要である。
また、SA は指摘した問題や定義しきれない問題を概念データモデル上で可視化しておく。概念データモ
デルを引き継いだ DM は、論理設計終了までに全ての問題の解消（実装しないという意思決定も含め）を見届ける必要がある。

Ⅹ．2．5 概念設計～サブタイプを活用した情報要求の正確な定義～
概念データモデル上に記述されるエンティティ（情報の管理単位）は、マネジメント層の多様な情報要求のために複雑な表記とならざるを得ないことがある。この時は、業務共通のデータを扱うスーパータイプと、業務毎の固有データを扱うサブタイプに分けて表現することで USA が概念データモデルを理解しやすくする
ことができる。
例えばある会社では、「正社員」を管理するシステムは人事部門がオーナーの「人事システム」として、「派遣社員」を管理するシステムは派遣社員の契約管理部門がオーナーの「派遣社員管理システム」として、それぞれ開発されていた。
ところが、入退室や情報システムへのアクセス管理の厳格化といったセキュリティ管理上の要求や、電子メールのアドレス管理、災害発生時の緊急連絡網管理など、正社員と派遣社員を共通で管理する必要性が生じ、総務部門がオーナーとなり「社員」を管理する「社員管理システム」の新たな開発が必要になった（図表Ⅹ-5）。
図表Ⅹ-5 新たな管理要求による「正社員」と「契約社員」、「社員」の関係の変化

図表Ⅹ-6 は、サブタイプとして「正社員」と「派遣社員」を定義し、スーパータイプとして「社員」を定義する
ことで、それぞれの管理要件を満足しつつ、新たな管理要求に応えるモデルの例である。サブタイプを活用して表現することで、マネジメント層の多様で複雑な情報要求を正確に定義・表現できる。
121

図表Ⅹ-6 は、図表Ⅹ-5 の「新たな管理要求」を表現した概念データモデルである。スーパータイプの「社員」エンティティは、「正社員」と「派遣社員」に共通する属性を管理する。サブタイプの「正社員」と「派遣社員」の各エンティティでは、それぞれに固有の属性だけを管理すればよい（スーパータイプの属性はサブタイプに継承される）。
例えば「社員」を識別する「社員番号」と、「正社員」を識別する「正社員番号」、派遣社員を識別する「派遣社員番号」の発番ルールの違いや、既存の「正社員」と「派遣社員」の「氏名」の入力可能文字数の違いなどが確認された場合、SA が USA（ユーザー部門）と協力して、「社員」に統合するための対応方針の検討を検討する。
図表Ⅹ-6 スーパータイプとサブタイプ（例）このようにして、マネジメント層による複雑で多様な情報要求が、サブタイプを用いて定義され正確に描くことができる。
経営環境の変化による管理要件の変化はデータの管理構造に影響し、システム構築や再構築の契機にもなっている。例のような簡単な事例でもわかるように、概念データモデルは言葉だけでは定義しきれない複雑な管理要件を明確に可視化し、整合性のとれた管理業務の設計を可能にする。
管理要件の見直しは関係部門だけで進められ、IT 部門へは検討結果が引き渡されるといった手順が一般的であるが、IT 部門は「情報要求分析」技術を武器に管理要件の見直し活動に直接参画するべきであり、そこにこそ IT 部門の新たな価値があると考える。

122

Ⅹ．2．6 概念設計～概念データモデルを活用した概念設計の深め方（例）～
概念データモデルでは、言葉だけでは定義しきれない複雑な管理要件を明確に可視化でき、整合性のとれた管理業務を設計できる（図表Ⅹ-7）。
図表Ⅹ-7 概念データモデルを基にした概念設計の深め方（例）

図表Ⅹ-7 は、検討が進み、緊急連絡先情報は社員の登録意思の確認（「緊急連絡先登録フラグ」）と、社員本人による「緊急連絡先」登録の追加要件を、サブタイプにより表現したものである。「緊急連絡先登録フラグ」によって、その社員に緊急連絡先の登録の有無もわかるようになった。
RDBMS（Relational Data Base Management System）も RDBMS を操作・制御する国際標準のデータベース言語である SQL（Structured Query Language）も ER モデルもリレーショナル理論（代数理論）を基に開発されており、ER モデルは SQL を記号（図面化ルール）で表現したものということができる。さらに付け加えると、ユーザーの正しい情報要求を基に設計した概念データモデルであれば、
RDBMS と SQL による高い実装可能性があるといえる。これもデータモデルの価値の一つである。

Ⅹ．2．7 情報要求を正確に実装する～論理データモデルと物理データモデル設計の留意点～
論理設計工程では、DM（Data Manager）が概念データモデルを引き継いで論理データモデルを設計
し、物理設計工程では、DBMS の特性や実装環境、セキュリティ、パフォーマンスなどを考慮して DBA（Database Administrator）が物理データモデルを設計する。
開発プロジェクトでは DM と DBA は責任範囲を明確にした上で DM をリーダーとする一つのチームとして活動する体制が必要である。
123

論理設計工程と物理設計工程で最も重視すべき点はユーザーの情報要求を具体化した概念設計の内容を確実に継承して実装することであり、論理データモデル、物理データモデル設計における留意点は以下のとおりである。
論理設計のスタート時には、EA の各階層の専門技術者が概念データモデルの管理構造を理解するための対策が不可欠である。
次に、概念データモデルで定義した制約条件を確実に論理データモデルに引き継いでいくことが重要である。DM（Data Manager）は SQL で最適化された論理データモデル（主キーのコード設計や冗長化の検討なども含む）を設計する。
一方、AE（Application Engineer）は概念データモデルの制約条件の下で、イベントがあるたびにデー
タを変化・遷移させていくアプリケーションを設計する。言い換えれば、アプリケーションはビジネスの変化をデータとして正しく表すための手段と言える。
概念データモデルから論理データモデル、物理データモデルへ設計していくプロセスにおいて、データを中
心に EA（Enterprise Architecture ＝ BA、DA、AA、TA）を完成させていくことが肝要である。

Ⅹ．3 情報システムエンジニアリングにおける職種とその役割
情報システムエンジニアリングにおける各工程の職種と役割を図表Ⅹ-8 に示す。
図表Ⅹ-8 情報システムエンジニアリングにおける職種とその役割

124

Ⅹ．3．1 職種とその役割


USA（User’s System Analyst）：情報要求の検討、業務課題・ルールの改善や業務の設計

SA（System Analyst）：情報要求分析を担当し情報要求の分析と概念データモデルの設計

DM（Data Manager）：論理データモデル設計やコード設計、データ定義

DBA（Data Base Administrator）：物理データモデル設計、開発用・本番用データベース構築

AE（Application Engineer）：アプリケーションの設計、ソフトウェア要求定義

SWE（Soft Ware Engineer）：ソフトウェア設計と構築TE（Technical Engineer）：開発環境、本番環境の設計と構築



PM（Project Manager）：プロジェクトの計画及びプロジェクトの遂行管理
これら職種の多くは認知され活躍の場も明確になっているが、SA（System Analyst） と DM（DataManager）を明確に規定し活躍の場を設けている IT 部門は少なく、第 2 ステージで確立されたはずの第4 の経営資源としてのデータ品質を保証する「データ管理機能」の未整備やサイロ型システム問題の主要因になっている。
SA（System Analyst）、DM（Data Manager）、DBA（Database Administrator）には ER モデ
ルの設計スキルは必須である。特に、SA、DM は ER モデルの設計スキルだけではなく、卓上に広げたモデ
ルを挟んで、マネジメント層やミドルマネジメント層とあるべきデータの管理構造や、情報要求の妥当性、ビジネスルールのあり方などについて会議をファシリテートするスキル（方法論の知識や会話力だけでなく、業務を理解して矛盾を指摘する力）も不可欠である。
データの高度利用を目的にした DX システムの開発投資が本格化するなか、SA（System Analyst）やDM（Data Manager）の不在が、DX プロジェクトの最大のリスクの一つであることを認識して対策すべきである。

Ⅹ．3．2 PM（Project Manager）について
基幹系システム開発プロジェクトを統括する PM（Project Manager）の役割は多々あるが、図表 Ⅹ8 にはプロジェクトの進捗に沿って管理の粒度を詳細化させるローリングウェーブコンセプト1による計画・管理手順を記載した。なかでも重要なポイントは開発に着手するか否かの意思決定が行われる概念設計終了
時の見積精度であり、ISE では概念データモデルと情報要求定義をベースに開発規模を見積る。
情報要求からアウトプット機能数を、概念データモデルのエンティティからデータインプット機能数（サブタ
イプはメインの機能から分岐するサブ機能）を、エンティティ間のリレーション数により処理の複雑性を想定し、一定レベルの B／Q（開発工数：Bill of Quantities）値を見積もる。

1

ローリングウェーブコンセプト（Rolling Weave Concept）：計画作成の基本となる情報が十分そろってはじめて高い計画が立案される。したがって、精度の低い情報しか得られない段階で、遠い将来の作業に対して詳細な計画を作成するのは無意味である。プロジェクトスタート段階ではプロジェクトの全てをカバーする大きなレベルを計画し、詳細な計画の基となる正確な意思決定やリソースアローケーションが可能になった段階でそれに対応する部分を詳細化する。このような時間経過に伴い細部展開する考え方は、海岸で見える波は、遠くは大きなうねりが、足元では小さな波の景色になぞらえローリングウェーブコンセプトと呼ばれるようになった。（『エンジニアリングプロジェクト・マネジメント用語辞典』）
125

Ⅹ．4 データの高度利用（DX）の本格化に向け何をすべきか
多くの日本企業は、サイロ型システム問題などを置き去りにしてきた。高度なデータ活用を目的とする新たな DX システムの構築に着手する前に（あるいは並行して）、この問題の解決を図らなければならない。
Ⅸ章の「企業システムの変遷」を見ていくと、システム開発の目的と開発方法論、エンジニアリングの中核
技術はセットで扱う必要があることに気付く。「SCM（Supply Chain Management）」や「CRM（Customer Relationship Management）」などシステム名に「マネジメント」を冠したシステムや、DX
システムのようなデータの高度利用を目的にしたシステムであれば、エンジニアリングアーキテクチャーとして
DOA を選択することは必然であると考える。
日本企業の情報システムは海外企業と比べ周回遅れとか 2 周遅れとかいう話を聞くが、一向に解決する
方向に動いているようには見えない。1990 年代に解決していなければならなかった問題の先送りはもう終
わりにすべきである。
やるべきことは明確である。DOA スキルを持つ SA や DM の育成と、新規システム開発プロジェクトにおける DOA の実践である。情報システムにおけるデータの重要性・価値を再認識して、日本の競争力向上につなげる DX に取り組んでいただきたいと望む次第である。

126

参考：システムズアプローチ「システムズアプローチ」は宇宙開発や大規模プラント建設、社会問題や経営問題などの問題解決といった、不確実性の下における、複雑な選択問題の意思決定を助け、問題解決を図るための体系的なアプ
ローチをベースとしている。また、システムズアプローチは、システムズエンジニアリング、システムズアナリ
シス、システムズマネジメントといわれる三つのメソッドで構成される。

1．システムズエンジニアリング（Systems Engineering）
システムズエンジニアリングは 1960～70 年代の米国における宇宙開発プロジェクトにおいて開発されたエンジニアリング手法で、当初は宇宙開発プロジェクトや大規模プラント建設プロジェクトに適用されたが、その後環境問題などの複雑な問題解決プロジェクトにも適用されるようになり、今では情報システ
ム開発はもとよりさまざまなプロジェクトにおいて広く適用されるようになっている。情報システム開発がベースとしている V 字アプローチモデルもシステムズエンジニアリングに基づくものである。
システムズエンジニアリングは、図表Ⅹ-参考 1 のような V モデルで知られている。
図表Ⅹ-参考 1 システムズエンジニアリングの V 字モデル（SE：Systems Engineering）

システムズアナリシス（Systems Analysis）
システムの目的や目標を明確にすることにより要求機能を明らかにするとともに、システムの適用条件
や関連する他システムとのインタフェース条件など、システムの制約条件を定義する。これにはシステム
ライフサイクルを通してシステムに要求される機能や性能、安全性、信頼性、保全性などが含まれる。
127

分割（Decomposition）

システムアナリシスプロセスで定義されたシステムを機能要素に段階的にモノとして製作可能なレベルまで分割作業を繰り返す。一般的に、分割プロセスはシステム設計（サブシステム分割）、サブシステム
設計（コンポーネント分割）、コンポーネント設計（製作設計）の 3 ステップで進められる。分割プロセス
では、分割された機能要素毎に機能要件と機能要素間のインタフェース要件をベースに機能要素が設計される。設計内容は前ステップで定義された要求事項をベースラインとして設計の妥当性が評価される。また、分割された設計要素の仕様からシステム全体のインテグリティーや、システムズアナリシス
プロセスで定義されたシステムの要求機能を満たしているかについても合わせて評価される。この評価の結果によっては、前ステップの再検討も必要になる場合がある。


製作・統合（Integration）プロセス
製作されたコンポーネントは分割プロセスと逆のプロセスで、設計要素毎に統合と試験を繰り返し、最終的にシステムとして運用状態の試験を経て運用に供される。各試験において問題が発生した場合のフィードバック先は該当する分割（設計）プロセスとなる。問題解決は、各分割プロセスの担当者が実施する。



運用・監査（Operation/Audit）プロセス

完成したシステムは運用されるとともに維持管理される。また、運用を通してシステムが期初の目的を達成しているか否かの視点でプロジェクトを評価する。

2．システムズマネジメント（systems management）
システムズアナリシスによる代替案の選択から、システムズエンジニアリングによる設計～制作～実用化までの全ての事項を管理運営するのためのメソッドで、プロジェクトのライフサイクルマネジメントともいわれる。プロジェクトマネジメントはシステムズマネジメントにおける実現化段階（投資段階）を対象とした
マネジメントである（図表Ⅹ-参考 2）。

128

図表Ⅹ-参考 2 システムズマネジメントと PPP（Phase Project Planning）の例

段階的プロジェクト評価手法（PPP：phase project planning）
プロジェクトはシステムズエンジニアリングの V モデルに示す九つのステップで進められるが各ステップの成果物とステップの完了判定基準（criteria）が規定され、完了判定基準がクリアされない限り原則的に次フェーズに進めない。この原則を実現するための手法として段階的なプロジェクト計画管理手法（PPP：Phase Project Planning）が用いられる。PPP はプロジェクトをいくつかのフェーズに分け、各フェーズで行うべき作業と成果物を定義し、フェーズ終了時に成果物を評価し、次フェーズへの移行
可否を判断する手法である。プロジェクトの遂行はプロジェクトマネジャーに委ねられるが、フェーズ終了時の評価と次フェーズ計画の承認（GO／NO－GO）はあらかじめ規定された開発投資管理プロセ
スにより決定される。

129

Ⅺ章 変化への対応力 ～レジリエンスとアジリティ
三輪 一郎
本章のサマリー

日本らしい経営、そしてビジネス・モデルは、長期継続型のモデルである。



企業を永く支えるシステムに求められることは、「変化へ迅速な対応力」、すなわち「柔軟性」であり、そのためにこそ、レジリエンスとアジリティを追求する。



レジリエンスは、過去に学びリスクを回避するナレッジをコンパクトに「継承」すること。



アジリティは、素早い判断でビジネス環境の変化に対応する「俊敏性」である。



Ⅵ章で提唱した、ビジネスゴールを考えながら DA 層と AA 層を分離させつつ連携させてデータモデルを描く「3.5 層のアーキテクチャー」は、目指すべきビジネスの骨格を概念データモデルで見える化して「継承」
し、試行錯誤によるロスを最小化することで「俊敏性」をもたらす。



レジリエンスとアジリティを発揮するための二つのポイントは次のとおりである。
① 「3.5 層のアーキテクチャー」でビジネスのゴールを明示・継承する。
② 「データ中心の方法論」で情報システムを俊敏に構築する。



これにより、日本らしく高度化した情報システムは、「確実な継承」と「俊敏な改変」が可能となり、環境の変化に柔軟に対応できるようになる。

本章では、注目を集めつつある「レジリエンス」と「アジリティ」というキーワードに着目し、確実で俊敏な変化への対応を可能にするための、日本的な対処方法を考える。また、これを支える方法論の、あるべき姿を明らかにする。

Ⅺ．1 日本的経営とは企業が 100 年、1000 年と継続する力を持っていることが「日本らしさ」であるとすれば、それを支える「業務の仕組み」すなわち情報システムを日本らしく再構築することが、日本らしさを活かす DX への処方箋であろう。
高松建設グループの傘下にある金剛組は、世界で最も永く続いている日本の企業だ。創立は 578 年とされ、1400 年を超える歴史を持っている。常に新たな取組みを続け、途絶えず、衰えず、末永く事業を継続するモデ
ルを、日本的経営の規範としたい。
日本らしさを活かす経営、日本らしいビジネス・モデルは、欧米型の一攫千金モデルではなく、長期継続型のモデルだ。我々が目指すべき、「日本らしく高度化した情報システム」は、これを支えるものである。

Ⅺ．2 レジリエンスとは2012 年、国際標準化機構（ISO）の「社会的セキュリティ技術委員会（TC233）」により ISO22301（事業継130続マネジメントシステム、BCMS）が発行された。2015 年、関連する TC を統合して設置された「セキュリティとレジリエンス技術専門委員会（TC292)」に管轄が移り、7 年ぶりの改訂が行われ、2019 年、ISO22301 の2019 年 版 （ Security and resilience — Business continuity management systems —Requirements）が発行された。
我々は、事業継続のための ISO 規格に盛り込まれた「レジリエンス（resilience）」というキーワードに注目した。探査衛星などに応用され飛行中の問題を解決した仕組みを、一般の活動にも応用できるように整備するための概念だ。
レジリエンスは一般に、「復元力、回復力、弾力」と訳される。 人の想定の積み重ねによりリスク・マネジメントをしながら、様々な制約下における対処法をあらかじめその仕組みに組み込んでおく。最終目的を達成できるよう、予め起こりうるトラブルを想定したナレッジを組み込んでおこうというものだ。
ポイントは、スタディや経験則から得た、組織が生き抜くためのナレッジを、いかにコンパクトに整理し、新たな仕組みの中に「継承」するかということである。

Ⅺ．3 アジリティとは本書を通じて目指す我々の目的の一つは、高度な情報システムがビジネス・モデルの変革スピードを高めることに寄与することである。すなわち、企業活動そのもののアジリティを高めることだ。
この思想は、1994 年に S.L.ゴールドマンらによって著され、日本でも 1996 年に「アジル・コンペティション―「速い経営」が企業を変える」として紹介されたものである。本章のタイトルで用いた「アジリティ」は、この思想に基づく企業の「俊敏性」を意味する。
翻って、狭義のシステムの領域では、アジャイル開発手法が注目を集めている。アジャイル開発手法は、ビジ
ネス・モデルの変革に求められるスピードが速まることを想定し、ウォーターフォール（WF）型以外の選択肢として、2001 年の「アジャイルソフトウェア開発宣言」によって登場した。
アジャイル開発手法は、トヨタが確立した「リーン生産方式」のエッセンスをソフトウェア開発の領域に応用したシステム開発手法の一つであり、EA における AA 層と TA 層の改変に効果を発揮する。少人数の精鋭チーム
がユーザーとの密接なコミュニケーションを維持しながら自由に開発できる環境では、狭義のシステムの改変ス
ピードを高める効果が認められている。
ただし現在では、新たな情報システムを手に入れるためのその他の手法として、パッケージの導入やローコー
ドツールの活用、SaaS の利用なども選択可能である。ローコードツールの活用でもシステム開発期間は短縮
できるし、SaaS なら開発そのものが不要となるため、企業がアジリティを発揮するために必要なリードタイムはさらに短くできるかもしれない。我々は、企業が求める変革のスピードに合わせて多くの手法を使いこなし、情報システムを改変する方法を選べるようになっている。

131

Ⅺ．4 情報システムはどうあればよいか
企業の情報システムに携わる我々に課された課題は、レジリエンスとアジリティを念頭に、企業経営を継続させるためのナレッジを意図的に継承しながら、これを俊敏に実現することだ。
では、企業経営を継続しつつ、俊敏に変化に立ち向かうにはどうすればよいか。
企業がレジリエンスを発揮するためには、①「3.5 層のアーキテクチャー」でビジネスのゴールを明示・継承すること。また、アジリティを発揮するには、②「データ中心の方法論」を採用して情報システムを俊敏に構築することの二つのポイントが重要だ。
図表Ⅺ-1 レジリエンスとアジリティを発揮するための二つのポイント

レジリエンスとアジリティを発揮するための二つのポイント① 「3.5 層のアーキテクチャー」でビジネスのゴールを明示・継承する② 「データ中心の方法論」で情報システムを俊敏に構築する

逆境に挑み、ディスラプションレベルの改革（業務改革、ビジネスモデル改革）に取り組む場合にこそ、「3.5 層のアーキテクチャー」で情報システムに蓄積された「データ」と「データ要件」というナレッジを確実に継承し、「データ中心の方法論」により、俊敏に新たなシステムを構築する。

Ⅺ．4．1 「3.5 層のアーキテクチャー」でビジネスのゴールを明示・継承する組織のナレッジは情報システムの要件となる。要件は一般に、「プロセス要件」と「データ要件」に分けて整理される。
例えば、売掛金の焦げ付きリスクを回避する与信管理のナレッジだ。与信管理の要件は、担当者→係長→課長→部長が順に審査するという「プロセス要件」だけで継承できるだろうか。否、与信管理の本質は、取引先企業の規模や過去の取引履歴に応じた与信額の計算方法という「データ要件」で表現される。担当者→係長→課長→部長というプロセス要件（手順）は、現行組織の構造に合わせるための手段だ。継承すべきナレッジの本質
は与信の考え方であり、「データ要件」である。
企業の情報システムがナレッジを継承し、レジリエンスを発揮できるようにするためには、「データ要件」を中心としてナレッジを継承できる構造（アーキテクチャー）で、ビジネスのゴールを明示することが肝要である。本書
では、Ⅵ章で提示した「3.5 層のアーキテクチャー」で、企業の姿を捉え直すことをお薦めする。
ここで論じるアーキテクチャーは、一般に EA（エンタープライズ・アーキテクチャー）と呼ばれる、「企業の構造（業務の仕組み）」の全体を示すモデルだ。一般的な EA のモデルを図表Ⅺ-2 に示す。
このアーキテクチャーには、ビジネス・アーキテクチャー（BA）層、データ・アーキテクチャー（DA）層、アプリケ
ーション・アーキテクチャー（AA）層、テクニカル・アーキテクチャー（TA）層のすべてが含まれる。

132

図表Ⅺ-2 一般的な EA のモデル

一方で、「データ」に着目する情報システム化のアプローチとして、DOA（Data Oriented Approach）が謳われてきた。
しかし我々は、システムを構築してきた立場から、これまではコンピューターの仕組みづくりのためのアプロー
チ、「DOCA（Data Oriented Computing Approach）」に終始していたと反省している。
本書が目指す「高度化した情報システム」は、コンピューターの仕組みだけでなく、システムを活用する人や組織のふるまいを含む業務の仕組み全体を視野に入れている。情報を活用してビジネスを支える「業務の仕組み」
そのものである。
我々は、この考え方を DOCA と対比して、データ中心でビジネスを構築するためのアプローチ、「DOBA：
Data Oriented Business Approach」と称して提言する（図表Ⅺ-3 参照）。
企業の構造（業務の仕組み）全体を「広義の情報システム」と捉え、この高度化を謳う我々は、DOBA を念頭に、今後の情報システムのあり方を示す。
図表Ⅺ-3 DOBA の守備範囲

これまで、情報システム化のノウハウは、業界の標準に少しずつ書き加えられてきたが、過去に整備された方法、すなわち、「上流工程で “全てを決めてしまう”要件定義重視の方法（プロセスもデータも、画面も帳票も、画面展開すらも含む全てを決めてしまう方法）」には、違和感を覚える。上流の要件定義で“全てを決めてしまう”
133

ことでデータとプロセスを層別して扱うという視点を失ってしまい、データがプロセス（アプリケーション）に内包されるシステム構造（強固だが分離不能な剛構造）になってしまった。これにより、「変化への迅速な対応力」が持てなくなってしまっているからである。
日本らしい「情報システムの高度化」を推し進めるにあたっては、いつの間にかでき上がってしまった「全てを決めてしまう剛構造の発想」による標準を見直し、永く継続するために何らかの“しなやかさ”を持つ「柔構造の発想」への転換が必要と考えるからだ。
【コラム：日本の高層建築を支える「柔構造」のアプローチ】
柔構造で作られた日本初の高層ビルである霞が関ビルは、最新の機能を追加しながら今でも一線級の価値を発揮し続けている。日本で高層ビルを建てるには、地震に耐える柔構造のアーキテクチャーが必要だったた
め、工法（方法論）もまた、新たなものが必要だった。
情報システムの価値を高める「方法論」は、継承すべき DA 層を心柱に見立てた「柔構造」のアプローチにより、AA 層や TA 層に柔軟性（柔軟に改変できる）を持たせたものとする。

我々の提案は、データ構造を示す「DA 層を“剛”」、プロセスや画面を含む「AA 層を“柔”」として、剛柔を併せ持ったアーキテクチャーを作り、BA 層のビジネスと TA 層の IT インフラを“データがつなぐ”構造にすることだ。そのためにはまず、AA 層に内包された「データ」を分離しなければならない。
図表Ⅺ-4 に、日本で良く用いられてきた「データ内包型 EA」と「4 層の欧米型 EA」、さらに我々の提起する「3.5 層の日本型 EA」を対比して示す。
図表Ⅺ-4 4 層の欧米型 EA と 3.5 層の日本型 EA
ビジネス
領域

情報システム領域

ITインフラ
領域

ビジネス
領域

BA

BA

BA

AA

DA

DA

AA

TA

TA

TA

データ内包型EA

4層の欧米型EA

3.5層の日本型EA

DA

AA

データ
領域
アプリケーション領域
ITインフラ領域

日本の初期のシステム化では、プロセスを記述するプログラムの一部として画面や帳票の入出力処理を定義していたため、データ要件はプロセス要件の一部として捉えられていた。消費税に対応した際、プロセスの途中で消費税計算が登場する度に、プログラムに 0.03 という数字を書き込んでいたアプローチである。
今やその失敗は克服され、プロセス要件とデータ要件の分離は当たり前になった。しかし当初の発想がプロセス中心だったため、古いシステム程、この分離ができていない。残念なことに、この古いシステムを扱った技術者が、期せずしてプロセス中心の（データ内包型の）アーキテクチャーを当たり前のものとして身に付けてしまった可能性がある。
そこで我々は、プロセスとデータは同時に発想するが、分離して設計するアプローチを提案する。考え方は、以下である。
134

・従来は、データを内包したアプリケーションをプログラムしていた。これを分離する。
・分離したいが、今までは要求定義をするときにデータを先に定義するのが不得意だった。
（初期に”全てを決めてしまう“要件定義でシステム開発することが主流であったため、プロセス要件の中でデータ要件を表現するプロセス中心の方法論（POA）しか身につけてこなかった）・そこで、プロセスと同時にデータを考えながら、DA 層と AA 層を分離させ別々に定義する。
（同時に考えるが、担当やチームを分けて責任分担をはっきりさせ、各々が定義する。）
・そのうえで、CRUD マトリクスを使い、データを変化・遷移させる AA 層との整合を取る。
これが我々が提唱する、日本的発想に基づく「3.5 層の日本型 EA（Enterprise Architecture）」の考え方である。
具体的にはこうだ。新たなビジネスを発想・検討する際、プロセスから発想することは敢えて否定しない。新たなビジネスの手順を模したポンチ絵や、業務フローに代表されるプロセスモデルを描くことは良しとする。但し、並行して、「概念データモデル」を必ず作成する。ポイントは、ポンチ絵や業務フローの途中で登場する画面や帳票のイラストを、今までより少し詳しく描いてみることである。清書や確定は目的ではないので、イラストを描く方
法はホワイトボードで十分だ。気を付けていただくべきは、これがあったら新しい業務が実施できそうだと思える「データ項目が含まれているか」である。
項目の並び順や色遣い、文字の大きさやボタンの位置などは気にしなくてもよい。だが「こんなデータがあれば（表示もしくは入力できれば）新業務は回る」と思える項目が洗い出されたかには、こだわりを持って議論していただきたい。
検討チームは、プロセス検討チームとデータモデリングチームに分けておく。データモデリングチームは、イラストから得たデータ項目を既存の E-R 図にプロットし、データ構造（DA 層）の変化を捉える。プロセスチームは、
データモデリングチームが示した利用可能なデータを変化・遷移させるアプリケーション（AA 層）を考える、という分担だ。
データモデリングチームは、検討開始前にあらかじめ用意しておいた既存システムのデータ要件で描いた ER 図に、上記のイラストから得られたデータ項目をプロットしていき、差分があれば反映していく。上記のイラスト
から、概念データモデリングを行うには十分な情報が得られるため、データモデリングチームは検討の初期から始動することができる。
プロセス検討チームは、データモデリングチームが用意した E-R 図を基に、先行するプロセスが生成したデー
タを利用することでそのプロセスが実施できるかを検討していく。プロセスを実施するために必要なデータがE-R 図に無い場合は、先行するプロセスのどこかでそれをインプットするよう、プロセスを変更する。
これを繰り返すことで、データ構造の検討を中心に置いて半歩先行させつつ、並行してプロセスの実現可能性を確認しながら、新たなビジネスを設計していく。要件定義の段階から CRUD マトリクスを使うことで、新たなデータと新たなプロセスの整合性を担保していくのである。分離したデータとプロセスの整合性を取るツールとして、従来型アプローチより早くから CRUD マトリクスが役に立つのは、この方法の特徴である。

135

図表Ⅺ-5 要件定義工程で作成する CRUD マトリクスの例（コンピューターを使わない業務（グレーの列）や、帳票・画面も記載する）
このアプローチに慣れない組織では、イラストを書き起こす時間とチーム間のコミュニケーションの手間に違和感を持つかもしれない。だがイラストを描く作業の工数は、詳細設計までの期間にいずれ発生するものである。
チーム間コミュニケーションの手間も、データ移行設計や開発チーム間の分担、他システム I／F の設計などで必要になるものである。発想を変えれば、例えば移行設計では、データモデルの新旧対比を通じて移行可否の検討が終わっていることになる。先憂後楽のアプローチだ。
またプロセス検討チームには、アジャイル開発やプロトタイピングに挑戦しても構わない。ただしこの場合も、
データモデリングチームが並行して「概念データモデル」を作成するという体制だけは必ず守っていただきたい。
E-R 図があれば、CRUD マトリクスも有効に活用できるだろう。これにより、アジャイル開発では、リファクタリン
136

グの負荷が軽減されるだろう。
我々の提案は、従来方式かアジャイル開発かに関わらず、やがて発生する工数や手間を早めに投下することである。総量を増やすのではなく、新たな方法が必要とする順番に組み替えて実施することである。これによってデータをプロセスから分離し、システム構造に剛柔のメリハリをつける「DOBA：Data Oriented BusinessApproach」に乗り換えることである。
この考え方に基づいて、プロセス検討チームとデータモデリングチームを分ける組織体制上の分担が、腹に落ちてしまえば、DOBA が、ことさら難易度の高い技術やスキルを要求するものではないことがご理解いただけるのではないだろうか。
こうして、剛構造の「データ内包型 3 層アーキテクチャー」からデータを分離し、さらに、データが心柱となってアプリケーションに柔軟性を持たせる「日本型の 3.5 層アーキテクチャー」に転換していく。
「データ」を中心に企業の構造（業務の仕組み）を見える化し、必要な部分だけを柔軟に作り直したり拡張した
りできるようにする。それは、企業の情報システムを 3.5 層の日本型 EA モデルで捉え直すことであり、これをベースにビジネス要件を明示・継承することで、情報システムの改善・改革を柔軟に行えるようにすることである。
【コラム：日本の「システム化」はどこで間違ったのか】
初期のシステム化では、目の前にある紙の文書を機械化することに終始していた。また同時期に、プロセス改善を目指したデミング賞へのチャレンジが流行していた。プロセス中心でシステム化に取り組んだ日本の失敗は、この副作用だった可能性がある。アメリカもこれは同じだったが、後にパッケージ文化を受けいれた際、データを分離する考え方が身についたのではなかろうか。日本はパッケージの導入に際しても、研ぎ澄ませた
目の前のプロセスから離れられなかった。システム領域では、プロセス偏重の癖が悪く作用してしまった可能性が考えられる。加えて日本では、プロセス改善ばかりに熱中し、エンドユーザーレベルの「カイゼン」に終始していた。これは当初、功を奏したが、業務の仕組みを鳥瞰する「マネジメント&コントロール」の意識は薄かったものと思われる。組み立てラインの動作のカイゼンは行ってきたが、業務全体の流れを見直す活動には至らなかったのである。
ある時代において最適だった方法が、環境の変化により効き目を失った。変化した環境では、次にどんな手を打つか。成功体験に縛られた状況から突破口を見つける必要がある。「現場の知恵」は捨てがたいが、全体
から汲み上げて全体に還元するところが弱い。日本の良さを活かすなら、現場のミドル層が持つビジネスナレ
ッジをデータ要件で明示・継承し、データマネジメント組織を通じて全社展開する、ミドルアップ＆ダウンのアプ
ローチが良いだろう。
我々は、4 層の欧米型 EA を 3.5 層で捉え直すことで、日本の良さを活かしながら次に進む起爆剤にすることを提案する。1990 年代の欧米は、日本の QC をマネジメントに生かした。2020 年代の日本は、ナレッジの汲み上げに再度 QC を使う。日本では現場力重視。サービス業もマニュアルレスだ。手書き帳票をデータ要件で分析し、現場にいる“ミドル層のナレッジ”をデータモデルで汲み上げる。
だが組み立て直すのはやはり難しい。初期の SAP は壁いっぱいのデータモデルを持っていたが、HANAで見直した（内部構造を完全に見直した）ため、移行に手間取っている。ドイツの SAP も、内部にサイロがたくさん入っていたのかもしれない。それを HANA でやり直して、データの構造を一新したのではないか。
137

新しい価値創造という場面でも、やることは同じだ。アーキテクチャー（構造）重視である。その際に是非、データ中心型の「レジリエンス」を意識して欲しい。

次に図表Ⅺ-6 で、先に示した「DOBA の守備範囲」と「3.5 層の日本型 EA」の関係を示す。BA 層が業務の仕組みを、TA 層が IT インフラを代表するものとして表現した。DA 層と AA 層から成る情報システム領域は、その中間にあって、両者を橋渡ししていると解釈できる。
図表Ⅺ-6 DOBA／DOCA の守備範囲と EA の関係

このアーキテクチャーにより、企業の情報システムは、心柱に支えられた五重塔のような柔構造となり、レジリ
エンス（自己修復性）を発揮する。経営環境の変化を柔軟に受け止め、改善と改革により、業務の品質を向上しながら、IT の刷新にも対応する。
更に図表Ⅺ-7 では、情報システム領域を、明示・継承すべきビジネス上の「ナレッジ」と、選択・変更が可能な「手段」の領域に分離して捉え直した（DA 層と AA 層も「ナレッジ」と「手段」に分かれる）。情報システム領域に蓄積された要素にも、継承すべき「ナレッジ」と、代替可能な「手段」があると認識したものである。
図表Ⅺ-7 ナレッジ／手段と 3.5 層の EA モデル

実際に情報要求分析を行う際には、データとプロセスは同時に議論する。結果を DA 層と AA 層に分離して、それぞれの要件として定義する。
「DA 層／AA 層」が「ナレッジ／手段」に分割されたことにより、情報システムに蓄積された継承すべき資産は、「ナレッジ×DA 層」の部分、すなわち図中の縦縞の平行四辺形の部分に当たる「概念データモデル」に集中
138

することがわかる。AA 側、図中の横縞△の部分には、UI が相当する。ユーザーエクスペリエンスの質を左右す
るナレッジの一部だが、実装技術に都度合わせるべき柔の部分である。UI は日本の「おもてなしの精神」が発揮されるところであるが、継承すべき資産としての価値は、「概念データモデル」の方が高く、「UI」は相対的に低くなるだろう。
4 層の欧米型 EA に縛られず、3.5 層の日本型 EA を念頭に「企業の構造（業務の仕組み）」を捉え直すこと、
加えて、継承すべきナレッジを表現する「概念データモデル」を重視することが、レジリエンスを発揮して永く経営を支える、日本流の情報システム高度化の一つ目のポイントである。

Ⅺ．4．2 「データ中心の方法論」で情報システムを俊敏に構築する
上述の「3.5 層の日本型 EA」では、企業が継承すべき「ナレッジ」と代替可能な「手段」を切り分けて認識し、「概念データモデル」を「“剛”の要」として認識した。
加えて情報システムは、企業が発揮すべきアジリティのスピードに応える必要がある。ただしこの場合も、急いだがために「概念データモデル」を用いた「データ中心型ビジネスアプローチ（DOBA：Data Oriented
Business Approach）」が実現できない、といった対処方法を選んではいけない。
変化の激しいビジネス環境において、高度化した情報システムを支える方法論に求められることは、「データを剛」、「プロセスを柔」として情報システム全体を柔構造化することにより、情報システムの価値を高め続けることである。
これらの要件を満たす方法論を得て、既存システムの価値を継承し、積み上げていく。あらゆる企業に求められるビジネス・モデル変革のスピードにシンクロさせるために、新たな価値の源泉となるデータを中心に置いてシステムを進化させ続けられる方法論が必要である。
では、このアーキテクチャーを前提に、システムを俊敏に作り直していくにはどうすればよいか。
情報システムへの投資には、新たな経営戦略の実現が求められる。新たな経営戦略を実現するためには、新ビジネスのゴールを実現するためのアイデアを「新たなナレッジ」として獲得し、「As-Is のナレッジ」を継承して補完したうえで、「ナレッジの To-Be モデル」を見える化して、それを新たな IT 環境で実装する、というアプロー
チが必要だ。
これを図示すると、図表Ⅺ-8 に示すようなマトリクスになる（⓪は、①～③の活動を補完する準備活動）。

139

図表Ⅺ-8 「ナレッジの To-Be モデル」を創造するアプローチ

As-Is

新ビジネス
ゴール/実現
アイデア
①

企業の
ナレッジ

「現状概念データモデル」、「現状の組織分担」等

実装の手段

ナレッジのTo-Beモデル②「新概念データモデル」、「新たな組織分担」等✖

「新業務フロー」「新画面定義書」、「新操作マニュアル」、「新テーブル定義書」等③

As-Isのナレッジ

To-Be

⓪

「現状業務フロー」「現状画面定義書」、「現状操作マニュアル」、「現状テーブル定義書」等①「新たなナレッジ」を獲得する
新ビジネスのゴールを実現するアイデアを獲得し、「概念データモデル」で整理する。
②「ナレッジの To-Be モデル」を完成する「現状概念データモデル」に「新たなナレッジ」を加えた「新概念データモデル」を作成し、「ナレッジの To-Be モデル」を明示する。
③最適な IT 環境で新システムを実装する「ナレッジの To-Be モデル」を実装する最適な IT 環境を選択し、新システムを構築する。
（⓪「As-Is のナレッジ」はあらかじめ抽出しておくシステムに蓄積された「As-Is のナレッジ」は「現状概念データモデル」で抽出しておく。
As-Is だけを写し取るのは実は難しいが、例えば数年前に作成した「概念データモデ
ル」があれば、これに当たる。）「ナレッジの To-Be モデル」の骨子は、「新概念データモデル」で表現できる。例えば、配送料金の割引を行う
優待顧客のランク付けを、過去 1 年間の取引回数と取引金額の関係で決める。あるいは、隣り合う営業テリトリ
ーで自社のセールスマン同士に敢えて客の取り合いをさせることで、競合他社に対する競争力を高める、などだ。
これらは手順やプロセスなどの動的なルールではない。“静的なビジネスルール”であり、「データ要件」で表現すべきものである。
このように、「概念データモデル」には、顧客・商品・販売拠点の定義や、社員・配送・回収との紐づけ方などの静的なビジネスルールが表現できる。システムがパッケージでできていたとしても、画面やデータ連携テーブルなどの外部 I／F に着目することで、概念的な構造は写し取ることができる。
上記の③や⓪は、外部の IT ベンダーやコンサルタントに任せることもできるだろう。だが①や②は、ビジネス・モデル変革の推進力そのものである。ユーザー企業の経営層の方や現場のミドル層、あるいはエンドユーザー
諸氏が自ら行うべきタスクだ。
また、図中の赤い「×印」のルートは「単コン（単純コンバート）」と呼ばれる、サーバー入れ替えなどの際のショ140

ートカットルートだ。ただし、俊敏さが求められる環境においても、ビジネス価値の向上を同時に目指す限りは推奨できない。このルートでも、画面の見栄え改善や操作性の向上は期待できるかもしれない。だが IT ベンダーにリード役を任せられる反面、新たなビジネス・モデルを構成する要素を組み込んだ To-Be 像の実現は期待できないからだ。
残念なことに、今や当たり前のように行われているクラウド環境への移行を、この「×印」のルートで行っている事例が数多く見受けられる。投資に見合う経営上の成果を得るためには、安易に「×印」のルートに乗らず、上記の①→②→③のアプローチを採用することが重要である。
このアプローチのベースとなる「ナレッジ／手段×As-Is／To-Be」のマトリクス1（図表Ⅺ-8）は、新たな戦略の実現と同時に、新たな IT 環境への柔軟かつ俊敏な移行の可能性を示唆している。
ただし、いささか抽象的だったかもしれない。そこで少し、具体的な説明を加えて補足したい。
これまでの情報システムは、図表Ⅺ-9 のようにサイロ型のシステムを林立させる形でカバーする領域を拡げてきた。例えば「人事システム」には、社員マスターや異動履歴、「資格管理システム」には資格マスターや取得
履歴といったデータがある（図中、「C」,「c」は任意のシステムやデータ）。
図表Ⅺ-9 サイロ型システムの林立

人事Sys.

人事Sys.

資格管理Sys.

人事Sys.

資格管理Sys.

Sys.C

社員ﾏｽﾀ

社員ﾏｽﾀ

資格ﾏｽﾀ

社員ﾏｽﾀ

資格ﾏｽﾀ

C

異動履歴

異動履歴

取得履歴

異動履歴

取得履歴

c

ある日、取り扱う資格の種類を増やし、人事戦略にも活用するプロジェクトが立ち上がり、資格管理システムのサーバーの保守切れに合わせて再構築を行うことになった。
資格管理システムは周辺のシステムと連携している様子だが、全体の構造は誰も把握していない（前述の⓪が行われていない）ため、図表Ⅺ-10 に示すようにシステムの単位は変えないまま、「新資格管理システム」が再構築された。
図表Ⅺ-10 システムの刷新
新ビジネス
ゴール/実現
アイデア

人事Sys.

資格管理Sys.

Sys.C

人事Sys.

新資格管理Sys.

Sys.C

社員ﾏｽﾀ

資格ﾏｽﾀ

C

社員ﾏｽﾀ

資格ﾏｽﾀ

C

異動履歴

取得履歴

c

✖
異動履歴

1

取得履歴

c

“ナレッジ／手段”を“論／物”と捉え、「論／物×現／新マトリクス」と呼ぶこともある。
141

一般には、これを繰り返すことで全社システムの部分々々が更新されていく。ただしこれでは、部分最適化の繰り返しにしかならない。既存システムの単位や機能が足かせとなり、ビジネス・モデル全体を新しく組み直すことができなくなっている状態である。
そこで、「ナレッジ／手段×As-Is／To-Be」のマトリクスに立ち返り、推奨するアプローチを適用する。
マトリクスに示されたアプローチを辿れば、上記の再構築プランは、図表Ⅺ-11 のように展開されるだろう。
図表Ⅺ-11 「ナレッジ／手段×As-Is／To-Be」のマトリクスに沿ったアプローチ

類似性
認識
社員ﾏｽﾀ 統合？ 資格ﾏｽﾀ新ビジネス
ゴール/実現
アイデア
①
C

②
異動履歴

取得履歴

c

リソース
人事共通ﾏｽﾀ
イベントa

イベントb

イベントc

異動履歴

取得履歴

c

⓪

③

人事Sys.？

資格管理Sys.？

Sys.C？

社員ﾏｽﾀ?

資格ﾏｽﾀ?

C?

異動履歴?

取得履歴?

C

MDM Sys.
人事共通ﾏｽﾀc?

C

人事Sys.

新資格管理Sys.

Sys.c

異動履歴

取得履歴

c

①から取り込んだ新たなアイデアは、⓪で分析された「As-Is のナレッジ」と合わせて「ナレッジの To-Be モデル（新概念データモデル）」で明示・継承され、資格マスターを統合した新たな人事共通マスターに反映される。
新資格管理システムは、新たに構築される MDM Sys.（Master Data Management System）に実装された人事共通マスターを参照する形だ。実装されるシステムは、「ナレッジの To-Be モデル」が示したものと同じ構造となる。
ただしこのプランだと、関連する周辺の 3 システムを全て同時に再構築することになってしまい、多大な時間と費用がかかるとともに、刷新のリスクも大きなものになることが予測される。データ中心型のアプローチを採用することで、システム改変のスピードが却って鈍化することになりかねない状況だ。
そこで改めて、③で行った実装設計を見直し、下図に示す「実装手段の選択肢 2」を得た（図表Ⅺ-12 参照）。
人 事 マ ス タ ー の 統 合 は 人 事 シ ス テ ム の 改 修 で 実 現 し 、 新 資 格 管 理 シ ス テ ム は API （ Application
Programming interface）を通じて人事共通マスターを利用する。選択肢 2 では、コストを抑えつつ、初期案と同様のビジネス価値が俊敏に得られる。

142

概念データモデルによりナレッジの To-Be モデルを明示・継承する 3.5 層のアーキテクチャーを採用し、ナレ
ッジ領域と手段領域を分離（“論／物”分離）するアプローチをとることにより、実装手段の選択ミスなどを含む
試行錯誤のロスを経ることなく、実現可能な選択肢を得ることができた。
図表Ⅺ-12 実装手段の選択肢 2

類似性
認識
社員ﾏｽﾀ 統合？ 資格ﾏｽﾀ新ビジネス
ゴール/実現
アイデア
①
C

②
異動履歴

取得履歴

c

リソース
人事共通ﾏｽﾀ

C

イベントa

イベントb

イベントc

異動履歴

取得履歴

c

⓪

③
実装の選択肢２
人事Sys.
新資格管理Sys.

人事Sys.？

資格管理Sys.？

Sys.C？

Sys.C

社員ﾏｽﾀ?

資格ﾏｽﾀ?

C?

人事共通ﾏｽﾀ

資格ﾏｽﾀ

C

異動履歴?

取得履歴?

c?

異動履歴

取得履歴

c

概念データモデルの構造は、他システムと連携する API で実装した（図の右下部分）。
近年、実装手段の選択肢として、既存システムの「データ」に着目し、これを継続利用可能な情報資産と見なして汎用 API を通じて新システムでも利用できるようにするといったアプローチが盛んになっている。これは、我々が提唱するアプローチの延長線上にあるものとして評価している。
俊敏性を重視して、一旦は図表Ⅺ-12 のように実装しても、ゴールの概念として図表Ⅺ-11 の構成を目指す
ことに変わりはない（Sys.C の改修時期に合わせて MDM Sys.を実装するなど）。図表Ⅺ-11 の構成を目指す
過程では、マイクロサービスを活用するというようなアプローチも選択肢となり得るだろう。
3.5 層のアーキテクチャーを適用して概念データモデルを切り出し、かつ、“剛”とする部分、すなわち「ナレッジの To-Be モデル」を分離して実装することで、実装手段（AA 層／TA 層）が「柔」となり、俊敏に実現可能な方法も含めた案が選択できるようになった。
経営環境の変化に対応してビジネス・モデル全体を自ら描き直しながら、ナレッジを継承しつつ、最適な実装
手段を柔軟に選択できる方法論を持つこと。これにより、高度化された情報システムは、俊敏にレジリエンスを発揮することができるようになる。

143

【参考：データ中心型情報システム開発方法論「AxSEM®」】
参考に、本章担当の筆者が所属する組織が提案するデータ中心型情報システム開発方法論「AxSEM®：
Axiomatic Systems Engineering Methodology」の一部を紹介する。
AxSEM®は、コンセプトの中心に「データモデルによる全体像の早期把握」を据え、その他のコンセプトの多くを日本型の生産技術である「リーン生産方式」に求めた。広義のシステム全体を対象としながら、アジャ
イル型開発にも対応した方法論である。図表Ⅺ-13 に、AxSEM®の全体工程を示す。
AxSEM®の工程は、ゴール共有フェーズ、移行フェーズ、検証フェーズから成る。特徴は、ゴール共有フェーズの段階で、ビジネスが求めるデータ構造から実装アーキテクチャーまで、すなわち、EA の全層を同時に議論することにある。
図表Ⅺ-13 AxSEM®の全体工程

Act.A

Ph.G ゴールの共有フェーズ
Act.B

予備調査と
コンセプティング

Act.E

情報要求と
優先順位付け
Act.C

Act.A

Ph.T 移行フェーズ

実現単位のシナリオ決定Act.C

開発統制（要求変更、Prj使命へのシナリオ改定、バックログ管理）

システム
監査と評価

要求との整合

Act.D

実現性検証

Ph.V 検証フェーズ

アジャイル開発

ソフトウェア実装
方式設計＆開発

初期実現単位準備
Iteration群

Bk.C概念設計ブロック開始
Iteration群

発展
Iteration群

安定化
Iteration群

Act.A

サブシステムと概念データ設計

最適化実現単位強化実現単位
試行ブロックアジャイル開発

試行実現単位

全体設計
Act.B

Act.C

システム機能とアーキテクチャ見直し

全体リファクタリング

一般的なウォーターフォール型の V 字アプローチでは、業務要件を考えた後に IT 要件を抽出して実装要件を検討する。ビジネスを構想し終わってから IT を考えることになり、ビジネスと IT の検討に時間的なズレが生じやすかった。これまでもこの時差を最小化するために多くの工夫を盛り込んで応用してきたが、V 字アプローチの基本構造に従う限り、限界があった。
そこで発想を転換し、プロジェクトの初期に EA の全層を同時に検討する（リーン生産方式の「大部屋」に倣った活動）。
AxSEM®のゴール共有フェーズでは、各層の専門技術者が一堂に会し、ビジネスの全体を鳥瞰できる「概念データモデル」を軸に新システムの実現可能性を議論した後、プロセスや UI、内部処理などは、移行フェーズで実施するアジャイル開発型のイテレーション・アプローチで組み上げる。
ゴール共有フェーズで作る「概念データモデル」は、対象とするビジネス領域で扱うすべてのエンティティを洗い出し、データ構造の全体像を明らかにするまでを必須とする。付帯的かつ物理実装要件に係るデータ項
目の定義は、アジャイル開発フェーズで行う。
図表Ⅺ-14 では、一般的なウォーターフォール型のアプローチと比較するために、V 字アプローチの工程
144

配置をベースに AxSEM®の工程を配置した。「実現性検証」で実装に早期着手するというアジャイル型開発の特徴に加え、プロジェクトの初期に BA 層と DA 層の検討を明示的に必須としている点に特徴がある。
図表Ⅺ-14 V 字アプローチと AxSEM®の骨格比較

情報システム化

情報システム化

ビジネス
ゴール設定

システム
運用

要件定義

ユーザ
テスト

基本設計

IT導入
詳細設計

データ
設計

開発統制

情報シス
テム運用

IT移行

システム
テスト

実現性
検証

プログラ
ミング

一般的なV字アプローチ

妥当性確認

イテレーション1
イテレーション2
イテレーションｎAxSEM®のアジャイルアプローチ

業務アプリケーションは、ビジネス変革に要求されたスピードに合わせて俊敏にリリース（移行）していく。
妥当性確認フェーズで、スピードも含めた投資効果を評価することは、IT 投資手法の現実解として必須のものだ。

以上を基に、レジリエンスを発揮する俊敏な情報システムの高度化を支える二つ目のポイントである「データ中心方法論」について、求められる要件の骨子を整理する。
一般的なシステム刷新プロジェクトでは、大切なナレッジの継承や新たな付加価値の取り込みが実現されず、IT の更新だけにとどまる傾向が強い。これを図にすると、図表Ⅺ-15 のようになる。
図表Ⅺ-15 IT 更新プロジェクト

これを、上記のコラムで示した方法論の構造に照らしてみると、「ビジネスゴール設定」と「データ設計」という重要なタスクが行われないことがわかる（図表Ⅺ-16 参照）。

145

図表Ⅺ-16 IT 更新で実施されるタスク

我々が取り組むべきは、企業がそのナレッジを概念データモデルに結集してレジリエンスを発揮し、長期的に市場で生き残っていくためのアプローチであり、下記の図表Ⅺ-17 のようになる。
図表Ⅺ-17 レジリエンスを発揮するプロジェクト実施されるべきタスクは情報システム化において想定されるすべてのタスクとなり、「ビジネスゴール設定」と「データ設計」が必須のタスクとなる。現状を 3.5 層のアーキテクチャーで写し取って As-Is のナレッジを継承しつつ、新ビジネスのゴールを To-Be のナレッジ（概念データモデル）で明示して実装に継承する考え方は、次の図表Ⅺ-18 に示すように本書のアプローチと同様だ。
図表Ⅺ-18 レジリエンスとアジリティを発揮する「データ中心の方法論」に必須のタスク構成
新ビジネス
ゴール/実現
アイデア
ビジネス
ゴール設定

BA
DA

AA

TA

データ
設計

情報システム化

開発統制

妥当性
確認
情報シス
テム運用

IT移行
実現性
検証

イテレーション1
イテレーション2
イテレーションｎ

本書で推奨するアプローチは、詳細な手順やタスクを縛るものではない。上記の考え方を基に、是非皆さん
自身で、現場の進め方に応用していただきたい。
146

Ⅺ．5 レジリエンスとアジリティ
日本らしく、長期に継続するビジネスを支えるシステムに求められることは、「変化へ迅速な対応力」、すなわ
ち「柔軟性」であり、そのためにこそ、レジリエンスとアジリティを追求する。
下図では、冒頭で示した「レジリエンスとアジリティを発揮するための二つのポイント」に、文中で加えた論点を追記した。これを改めて確認し、本章のまとめとしたい。
図Ⅺ-19 レジリエンスとアジリティを発揮するための二つのポイント

レジリエンスとアジリティを発揮するための二つのポイント①「3.5 層のアーキテクチャー」でビジネスのゴールを明示・継承する－DA 層と AA 層を並列で捉え、DA 層を剛、AA 層を柔とする－DA 層のモデルの一つである概念データモデルでナレッジを継承する②「データ中心の方法論」で情報システムを俊敏に構築する－ビジネスゴールのアイデアを、概念データモデルで写し取る－ナレッジの To-Be モデルから、俊敏に実現可能な選択肢を得る

上流工程で新ビジネスのゴールを設定し、それを実現する方法を「3.5 層のアーキテクチャー」で具体化すること。新ビジネスの要件を「概念データモデル（データ設計図書）」で写し取り、俊敏に実現可能なシステムの設計に展開できる方法論を得ること。
この二つは、企業がレジリエンスとアジリティを発揮するために情報システムに「柔軟性」をもたらす、「DOBA：Data Oriented Business Approach」の必須要件である。

＜参考文献＞
スティーブン・L. ゴールドマン, ケネス プライス, ロジャー・N. ネーゲル （1996）『アジル・コンペティション―「速い経営」が企業を変える』日本経済新聞社

147

Ⅻ章 マネジメントに求められること
野々垣 典男
本章のサマリー

筆者の研究から、システム開発プロジェクトを成功させるために、発注側経営者に求められる行動特性として、「①当事者意識」、「②学習意欲」、「③ビジネスと IT との関連性理解」、「④IT 組織・体制構築」、「⑤IT 人事・IT 人材育成」、「⑥プロジェクトマネジメント」及び「⑦ベンダーとの信頼関係」の 7 要素が抽出された。



トップマネジメントが DX 推進に関わるためには、日々どのように行動すればよいのかについて、次の 10の行動を例示する。
①DX の重要性について社員にメッセージを発信する②自らセミナーや研修に参加して DX や IT を積極的に学ぶ③凝り固まった考え方をときほぐし多様性の高い組織をつくる④現場に顔を出す⑤DX 先進企業のトップマネジメントと交流する⑥ベンチャー企業との接点をもつ⑦部下のはしごを外さない⑧失敗を許容する懐の深さを身につける⑨リスクから逃げない⑩うまくいかなくても決して諦めずチャレンジし続ける

デジタルビジネスや DX を推進するには、システムの高度化を行う必要がある。Ⅲ章において、日本企業の多くが抱えるシステム高度化へ向けた問題は、・データの重要性が経営に十分理解されていないこと
・「攻めの IT」への取組みが不十分なこと・システム開発や維持管理における標準化が進んでいないこと
・情報システムに柔軟性がなく、ビジネスの変化に対応できないこと
であることを確認した。この 4 点を根本的に解決することが重要であり、その解決策は次章で示す。その前に本章では、システム高度化へのベースとして、マネジメントに求められる事柄を具体的に検討する。

Ⅻ．1 システム開発を成功させるために経営者に求められる行動
筆者は 2017 年 4 月から 2 年間慶應義塾大学大学院で、IT プロジェクトを成功させるために発注者が配慮すべき事項や実施すべき行動を経営者視点から研究し、具体的な配慮事項や行動内容を、主に発注側経営者の立場の方々に提言した。ここではその研究の概要を説明したい。

148

Ⅻ．1．1 研究の背景と目的
私達の周囲は「IT」が満ち溢れており、企業のビジネスは情報システムに支えられている。今後も企業にとって情報システムの重要性はますます高まっていくと考えられる。しかし IT プロジェクトの成功率は 30％か
ら 50％程度と低く、開発が頓挫して中止に追い込まれた IT プロジェクトは少なからずあり、ユーザー企業とベンダーとの間で訴訟に持ち込まれる事案も増加している。
IT システムへの依存度が高いビジネスにおいては、IT プロジェクトを成功裏に開発完了することは経営者にとって重要な関心事であり、IT プロジェクトの成功率を高めることができれば社会的な意義をもつ。国内において、IT プロジェクトの成否要因に着目した研究を調査したところ、その多くは受注者である IT ベンダーの立場からの研究であった。一方で、発注者であるユーザー企業の立場からの研究はわずかである。国内ではシステム開発業務はベンダーへの依存度が高いことがその背景にあり、発注者の立場でシステム開発成功率を高めるための研究を行うケースは極めて稀である。
このようなことから、大規模 IT プロジェクトを成功させるために発注者であるユーザー企業が配慮すべき事項や実施すべき行動を経営者視点で明確にしようと研究した。

Ⅻ．1．2 研究方法
これまで、発注側経営者が行うべき具体的な行動については明らかにされておらず、少なくともベンダーに依存せざるを得ない国内においては言語化されたことが無かった。そのため本研究では質的研究方法であるインタビューによって研究対象者の発言を言語化してその記録を質的に分析することとした。
インタビューは、IT プロジェクトに関わるさまざまな立場の方々から、幅広い視点で、より多くの発注者の行動特性を採取するために、ユーザー企業の立場から 8 名、ベンダーの立場から 8 名、さらに両者を中立的な立場で評価していただける方を 4 名選定し、合計 20 名について 2018 年 5 月から 8 月にかけてイン
タビューを実施した。ユーザー企業の立場の方々は IT について経営者視点で理解しており、過去に大規模
IT プロジェクトを率いてそのプロジェクトを成功裏に完了させた方々である。
インタビューの方式としては、予断を与えず、発注者が備えておくべき行動特性を、暗黙知を含めて広く収集する主旨から、特定の行動特性への誘導を避けるために、実際に取り組んだ IT プロジェクトについて自由に発言していただく「非構造化インタビュー方式」で実施した。

Ⅻ．1．3 発注者行動特性の要素抽出
発注者行動特性の要素を抽出する手順としては、インタビューの記録をもとにして大規模 IT プロジェクトを成功させるために発注者が配慮すべき事項や実施すべき行動を示している思われる発言部分を採取した
ところ、抽出された発言数は全部で 250 件に達した。その後 250 件の発言の内容を、KJ 法にしたがって分類作業を行ったところ、最終的に 7 つのグループに統合された。
その結果、大規模 IT プロジェクトを実施するにあたり、発注者が配慮すべき事項や求められる行動を構成する七つの要素である「発注者行動特性 7 要素」を抽出した。具体的には、次の 7 項目である。
・当事者意識・学習意欲・ビジネスと IT との関連性理解
149

・IT 組織・体制構築
・IT 人事・IT 人材育成
・プロジェクトマネジメント
・ベンダーとの信頼関係

Ⅻ．1．4 考察システム開発プロジェクトにおいて、この 7 項目のすべてを経営者自身が実行している、ということではない。IT プロジェクトを成功する企業の経営者はどのようなことに配慮し重要と考えているのか、を研究したものである。
7 要素は個別にみると特に目新しさは無く、どの経営者も「重要と考えている」と考えがちである。大切なのは、本人の思い込みではなく、実際に行動で示しているかどうか、が大切である。本研究から、本人の想いではなく、周囲が気づいているかどうかが重要になることがわかった。
開発プロジェクトが立ち上がったら、「後はよろしく！」と考えて IT 部門任せにする経営者が多いが、本研
究からはシステム開発の成功率を高めるための行動として、「プロジェクトに積極的に関わる経営者像」が明らかになった。

Ⅻ．2 トップマネジメントによる DX 推進
システム開発を成功させるために経営者に求められる行動は、これまでの IT プロジェクトに限定されない。
これまでの「IT」と同様に、今では「DX」に取り組まなければ経営が成り立たない状況である。したがって、前述の研究結果は、DX に対して経営者に求められる行動にも共通するはずである。
さて、ほとんどの企業において、デジタルビジネスや DX の推進は喫緊の課題である。これまでは課題ごとに担当部署に任せておけばよかったが、DX はトップマネジメント自ら当事者意識をもって積極的に関与する必要がある。しかし残念ながら、いまだに「DX は IT 部門の課題である」と考えている経営者は多い。もちろん IT 部門も関与するが、事業部門の課題であり、さらにいえば「経営者自身」の課題である。
ここではトップマネジメントが DX 推進に関わるためには、日々どのように行動すればよいのか、について、次の 10 のポイントに着目して、具体的な行動を例示する。
ポイント 1：DX の重要性について社員にメッセージを発信するポイント 2：自らセミナーや研修に参加して DX や IT を積極的に学ぶポイント 3：凝り固まった考え方をときほぐし多様性の高い組織をつくる
ポイント 4：現場に顔を出す
ポイント 5：DX 先進企業のトップマネジメントと交流する
ポイント 6：ベンチャー企業との接点をもつポイント 7：部下のはしごを外さない
ポイント 8：失敗を許容する懐の深さを身につけるポイント 9：リスクから逃げない
ポイント 10：うまくいかなくても決して諦めずチャレンジし続ける
150

Ⅻ．2．1 ポイント 1：DX の重要性について社員にメッセージを発信する
最初にやることは、DX の重要性について社員にメッセージを発信することである。メッセージは一度発信すればよいわけではなく、イベントやマイルストーンごとにその時点のトピックスや課題を含めて幾度となく発信すべきである。
これまでのトップマネジメントはスタート時点にはメッセージを発信するものの、それ以降は「後はよろしく！」と担当部署任せにすることが多かった。しかし DX はトップマネジメントが関与し続けるテーマである。したがって、事あるごとにメッセージを発信し続ける必要がある。
発信する内容は、プロジェクトそのものについて語ることはもちろんであるが、「自社にとっての DX は何か」が大切である。DX は固定的なものではなく、業態や事業、企業によって異なる。そのため、自社にとってのDX を定義し、それを伝え続けて社員に「腹落ち」させる必要がある。
発信する手法としては、会議や朝礼など直接語りかける他に、社内報やイントラネットでの文書、メールな
どのメッセージなどあらゆるメディアを駆使して伝える必要がある。さらに自社の DX の重要性や取組みを対
外的に広報することで社内により強く「覚悟」を醸成することができる。
社内に対してトップマネジメントの「本気度」を伝えることが重要である。「今回の DX は今までとは違う」ということを強く認識させることに真意がある。

Ⅻ．2．2 ポイント 2：自らセミナーや研修に参加して DX や IT を積極的に学ぶ
DX 推進の要素として「IT」は必ず関連するが、IT が苦手なトップマネジメントが多い。苦手であることが問題でなく、「知ろうとしない」ことが問題である。IT にはプログラミングやネットワーク設定のような技術的側面がある一方で、ある技術がビジネスに活用できるのか、売上増にどのように寄与するのかなど経営的側面がある。トップマネジメントにはプログラミングを知っていたり出来たりすることを期待されるのではなく、経営的側面からの見識が期待されるのである。そのためには DX や IT を積極的に学ぶ姿勢を身につけていただ
きたい。
具体的には、DX や最近話題の技術を経営層に対して解説するセミナーや研修に参加したり、業界団体の経営者の会合などに参加したりする機会を積極的に作る。また経営会議のようなトップマネジメントが一堂に会する場で IT や DX をテーマにしたセミナーを実施するなど、トップマネジメントの IT センスを高める機会
を定期的にもつことも有効である。

Ⅻ．2．3 ポイント 3：凝り固まった考え方をときほぐし多様性の高い組織をつくる
歴史ある名だたる企業ほど古い考え方が組織を動かしている。DX はイノベーションの側面をもっているため、凝り固まった考え方ではイノベーションを起こせない。つまり歴史ある名だたる企業ほどイノベーションが苦手な傾向をもつ。しかし中には歴史ある名だたる企業であってもイノベーティブな発想を失っていない企業がある。それらの企業はトップマネジメントがイノベーティブな発想を持ち続けていると思われる。
DX を推進するには、凝り固まった考え方をときほぐし多様性の高い組織をつくる必要がある。そのヒントとして、「若者、バカ者、よそ者」という言葉がある。「若者」は新しいものを受け入れるのに抵抗がない。企業の中でも若手社員はこれまでの柵（しがらみ）がなく上に忖度する必要がない。「バカ者」は常識に囚われない思考形態をもっているため常識人とは異なる視点から発想することができる。「よそ者」は組織文化や風土、151

因習を受け継いでいないので、新たな発想を提起することができる。
このような視点で組織をつくるには、年齢、性別、国籍などの属性の他に、これまでの経験や性格などの観点からも多様性の高いメンバーで構成する組織が DX には欠かせない。

Ⅻ．2．4 ポイント 4：現場に顔を出す
トップマネジメントは忙しいが、少しでも時間が空けばとにかく現場に顔を出してほしい。前述のⅫ．2．1 で述べた公式なメッセージは重要であるが、現場に顔を出してミドルマネジメントやスタッフに一声かける、という非公式な接点が、DX 推進には意外と効果がある。これはトップマネジメントが DX にかける想いや本気度を示す格好の場である。
このことをあるトップマネジメントに伝えたところ、「何を話せばよいのか」と質問されることがあった。ここでは特に話すことはない。むしろ現場の話を聴いてほしい。何をしているのか、困っていることは何か、どのような状況なのか、などで、それに対して回答したり解決したりすることが目的ではなく、とにかく聴くことが目的である。トップマネジメントに話を聴いてもらうことで、現場はモチベーションが上がるうえ、トップマネジメントとしても情報収集する効果がある。

Ⅻ．2．5 ポイント 5：DX 先進企業のトップマネジメントと交流する
DX 推進やイノベーションの手法の一つとして「エコシステム」がある。いわゆる「協業」のことで、もともとは生態系の用語であったが現在はビジネスや IT の世界で使われることが多い。業界や国境を超えて、企業同士が共存していく仕組みを意味する。系列の異なる企業同士やライバルが手を取り合うこともある。自社の強みと協業企業の強みをうまく活かして新たな価値を創造するのである。
エコシステムによる DX 推進は、トップ同士が接点をもつ必要があり、特に DX で先進的な取組みを行っている企業であれば、相手の胸を借りてビジネスを進めることができる。したがって、トップマネジメントは DX
先進企業のトップとの接点づくりを常に模索することが成功への近道になる。
なお実際に新たなビジネスにつながらなくても、相手会社の DX 推進の仕組みや取組みを聴くことで参考になることが多い。トップ同士のつながりをきっかけとして、双方の現場同士で交流会を開催する機会にもなる。

Ⅻ．2．6 ポイント 6：ベンチャー企業との接点をもつ
歴史ある名だたる企業とは異なり柵（しがらみ）が無く、ゼロベースの発想でビジネスを進められるのがベンチャー企業のメリットである。ベンチャー企業は新たなプロダクトやサービスを創出することを重要と考える。
組織の歴史が浅いためにオープンな組織文化であるとともに、比較的フラットな組織構造を持ち意思決定が速い。歴史ある企業は過去に縛られる傾向をもつためイノベーション発想を発揮しづらいが、ベンチャー企業との協業はアイデアを得るチャンスとして活用できる。
大企業は取引先にも歴史や信頼、成熟度を求める。ベンチャーは歴史が浅く経済基盤が脆弱な企業が多いために、大企業が取引先として選定しないことがある。しかし大企業の苦手な部分を補完する役割でプロジェクトにベンチャー企業を参画させベンチャーが得意とする部分を取り込むことで、イノベーション・プロジ
152ェクトを成功に導く手段を考えてもよい。もちろんリスクが伴うためにリスクマネジメントを考慮する必要がある。

Ⅻ．2．7 ポイント 7：部下のはしごを外さない
DX を推進しイノベーションを起こすために社内に組織を作ったり、新たなプロダクトやサービスのアイデアを募集したりする取組みを行っている企業は多い。そのようなトップマネジメントの想いに呼応してアイデアを応募した社員からは、せっかく応募しても簡単に却下されてしまった、という不満を漏れ聞くことがある。話を聴いてみると、これまでのビジネスの基準で販売数や販売額の目標が設定されたり、利益目標を議論されたりするために、なかなかトップマネジメントが満足するような計画が策定できず、その結果「却下」されてしまうようである。
DX やイノベーションをキーワードとする取組みは、小さな投資で「まずやってみる」ことが重要である。取組
みを推進する手法としては「アジャイル」である。そのイテレーションを回しながら徐々に成果をあげていく手法である。もちろんすべてが成功するわけではないので、予め撤退基準を示しておく。そのプロセスは取り組んでいるメンバーが納得する形で進めていくべきである。決して理由がわからないような形で却下する、つまり「はしごを外す」ことのないようにしなければならない。はしごを外された部下は、二度とアイデアを提案しようとはせず、場合によっては会社を去る決断をすることもある。

Ⅻ．2．8 ポイント 8：失敗を許容する懐の深さを身につける
既存の事業におけるプロダクトの製造やサービスの提供では、そのプロセスが確立されており、決められたルールにしたがって進めればよい。また新規開発を行う場合でも、製造物は異なるものの過去に行った手順を参考にして実行すればよい。しかしデジタルビジネスやイノベーションでは、これまでにやったことがないプロセスを初めて行うことや、それまで接点のなかった新規企業と協業することもあるので、計画どおりに進められないことがほとんどである。そもそもプロジェクトの特徴として独自性や不確実性があるために、「100％確実に成功させる」ことはできない。つまり失敗がつきものである。したがって、失敗への対処の仕方が大切である。
プロジェクトが失敗したときのトップマネジメントの振る舞いが試される。単刀直入に言えば、失敗を許容する懐の深さ、つまり「大目に見る」ことができるかどうかが試される。失敗を責められると、失敗しないようにすることを考える。例えば、できない理由をいろいろと並べ挙げてチャレンジしなかったり、失敗した理由を外的環境や他部署、他人のせいにしようとしたりする。このような行動はデジタルビジネスにとってマイナスになる。そうならないためにはトップマネジメントは失敗を許容する懐の深さを身につけ、失敗を大目に見る必要がある。任せきっていたものが失敗すると不満が残るが、経営者も関わっていて状況を随時把握しているプ
ロジェクトであれば、「仕方ない」と思えるようになる。懐深さを身につけるコツは、「深く関与する」ことである。

Ⅻ．2．9 ポイント 9：リスクから逃げない
デジタルビジネスやイノベーションは推進する必要があるが、失敗する可能性があることを前提にして進めることになる。そこで重要なのがリスクマネジメントである。「リスクがあるからやらない」というのであれば、デ153

ジタルビジネスやイノベーションはできない。
リスクマネジメントで重要なのは経験のみに依拠した自己流で行うのではなく、「リスクの特定」、「リスクの評価」、「リスクへの対応」及び「リスクの管理」を体系的に実施することである。この中でリスクの特定が大切である。リスクの洗い出しは網羅性が重要なため、リスク・チェックリストを用意しておけば、プロジェクトごとにチェックリストに基づいてリスク項目を比較的容易に特定することができる。
またリスクが顕在化したことを発見するように気をつけないといけない。そのためには現場からの情報収集が大切であり、「ヒヤリ・ハット」のような事象を気づいたときに、すぐにアラートを発しやすい組織風土を醸成する必要がある。仮に完璧にリスクを特定したとしても、それが顕在化したことに気づかなければ意味がない。
リスクマネジメントの一連の活動を実施できる体制をトップマネジメントが責任をもって構築すべきである。

Ⅻ．2．10 ポイント 10：うまくいかなくても決して諦めずチャレンジし続ける
デジタルビジネスやイノベーションには失敗はつきものである。そのために初めに全体を計画してからプロジェクトを始める「ウォーターフォール」ではなく、一部から順次イテレーティブに進めていく「アジャイル」で開発を進める。期待する成果が出ないこともよくあるが、失敗の原因を分析しやり方を変えて再度チャレンジする。
アジャイルの進め方で興味深い点は、初めに目指したゴールとは異なった、より良い成果物になることがある。それはアジャイルのメリットの一つでもあるが、イテレーションを進めているときの失敗から気づきを得て、より面白い成果物やアイデアを思いつくことがある。当初計画を軌道修正することにはなるが、結果的には市場から多くの支持を得られるソリューションになる。
うまくいかないときにそれまで進めてきたものを捨ててしまいゼロベースで検討をやり直す方法をとることがあるが、そのやり方は間違っている。アイデアを発想する手法に「デザイン思考」があるが、そのプロセスは
アイデアそのものを直接的に想起するのではなく、コンセプトやインサイトを大切にして、それらをぶらさない
ように試行錯誤するのである。軸足を固定してもう片方の足を動かす「ピボット」である。
なおこれは「ビジネス」なので、撤退基準を決めておき中止・中断する勇気も必要である。

Ⅻ．3 デジタル時代のマネジメント
1960 年代から始まった高度経済成長を端緒とするこれまでのビジネスの進め方やマネジメント手法では効果を上げられなくなって久しい。今求められているデジタルビジネスや DX、イノベーションには、全く異なる手法によって成果をあげる時代、いわゆる「デジタル時代」が到来した。
その時代を生き抜くために企業のトップマネジメントはどのように振る舞うべきなのか、その具体的な事例を本章で述べてきた。記述した内容はあくまでも事例であるが、参考にしていただければ幸いである。

＜参考文献＞
ベイカレント・コンサルティング（2016）『デジタルトランスフォーメーション 破壊的イノベーションを勝ち抜く
デジタル戦略・組織のつくり方』日経 BP154

ベイカレント・コンサルティング（2017）『3 ステップで実現する デジタルトランスフォーメーションの実際』日経 BP
村山誠哉・大屋雄（2018）『イノベーションの壁』クロスメディア・パブリッシング
内山悟志（2019）『デジタル時代のイノベーション戦略』技術評論社
真壁昭夫（2012）『若者、バカ者、よそ者 イノベーションは彼らから始まる！』PHP 新書
前野隆司編著（2014）『システム×デザイン思考で世界を変える 慶應 SDM「イノベーションのつくり方」』日
経 BP

155

XⅢ章 データ経営の実現と提言
三谷 慶一郎
本章のサマリー

日本企業が抱える、システム高度化へ向けて解決しなければならない問題は、「データドリブン」の考え方を理解し、「データ経営」を実現することで全て解決する。



経営者は、変化の激しい経営環境を乗り切るために、データに基づく経営マネジメントを推進しなければならない。



企業は既存ビジネスの効率化だけではなく、さまざまなデータを活用した新しいデジタルビジネスを継続的に創造していく必要がある。

システム開発・維持管理の標準化は、「データに基づく経営マネジメントの推進」と「デジタルビジネスの継続的な創造」の実現のために必要な基盤と認識すべきである。



システムを完成品ではなく、育て上げるものとして認識し、DOA などを駆使し、変化に追従できる俊敏なシステム開発を行っていかなければならない。



最後に、データ経営実現に向けていくつかの提言を示す（DX の推進をデータ経営へシフトする好機と捉える／レガシー刷新はナレッジ継承のための活動とみなす／IT 部門のミッションに「ビジネス創造の支援」を加える）。

本章では、これまで論じてきたことを再整理し、システム高度化の最終的な目的として、企業が目指すべき「データ経営」について論じていく。データ経営とは、自らのビジネスの現状やマーケットの環境を、データを通じて可視化し、それに基づいて戦略を立案し推進していく経営スタイルのことをいう。
Ⅲ章で述べたように、日本企業が抱えるシステム高度化へ向けて解決しなければいけない問題には、「データの重要性が経営に十分理解されていない」「攻めの IT への取り組みが不十分」「システム開発・維持管理における標準化が進んでいない」「情報システムに柔軟性がない」という大きく四つが存在する。そして、この四つは全て「データドリブン」、つまりデータを起点とし、データを駆動しながらビジネスを進めるという考え方を理解し、データ経営を実現することで解決すると我々は考えている。「データドリブン」の考え方こそが日本企業を救うのである。

XⅢ．1 データに基づく経営マネジメントの推進「VUCA の時代が到来した」と言われて久しい。VUCA とは、Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の四つのキーワードの頭文字を合わせた言葉で、企業を取り巻く環境が、我々が過ごしてきた時代の延長上ではなく、全く予測がつかないような状況へと、急激にかつ連続して変化し続けていることを意味する。経営学ではこのような不確実性の高い環境を「Turbulence」つまり「乱気流」に例えることもある。
156

このような環境において、最初に自覚しなければいけないのは、「今までの経営のセオリーが全く通じなくなる」ということだ。リンカーンは、「静穏な過去に適用したドグマ（教義）は乱気流渦巻く将来には機能しない」という言葉を残している。そして、このことは長期にわたって存在しているいわゆる大企業であるほど大きなインパクトを与える。先輩から引き継ぎ、マネジメント層が長い時間をかけて体得してきた経営の進め方、ビジネスの極意が全く役に立たなくなること、これは想像以上に企業に対して大きな影響を与えることであろう。特に、日本企業
においては、社長職は欧米のように、経営管理のスキルを保有し、複数社の経験を蓄積しているスペシャリスト
ではなく、社内のあらゆる組織の内情に精通し、実績を積み上げてきた人物が就くことが多い。つまり、その企業が歴史的に持つ経営のセオリーを誰よりも上手に使いこなし、成果を出してきた人材が社長になるのである。
その人物が過去に成功した経験を忘れ、それをもたらしたやり方を捨て去ることは言葉でいうほど容易ではな
いことは理解できる。しかし、繰り返しになるがもう今までのセオリーは通じないのだ。
変化が不連続でかつ激しい乱気流の環境下で、企業経営はどのように舵取りを行っていくべきなのだろうか。
先の見えない状態で唯一よりどころになるのは、「データ」であろう。
まず、自社のビジネスモデルのパフォーマンスを可視化し、リスクを最小限に抑えるためのデータを取得し管理することが必要になる。一般的な財務会計、管理会計の範疇に留まらず、自らのビジネスの状況を把握するための CSF（主要成功要因）に相当するデータを見出す必要がある。変化の激しい環境下であることを考えると、
遅滞なく可能な限りリアルタイムにデータを取得することも必要になる。
さらに重要になるのは、マーケットの環境を把握するためのデータ、具体的な顧客の状況を可視化するデータである。市場の成熟化とともに、顧客ニーズは多様化し、マスマーケティングの視点だけではその変容の本質は捉えることは難しい。解像度を上げて、ひとりひとりの顧客がどのように振舞っているかを理解するためのデータを取得しなければならない。
そして、収集したこれらのデータを分析することによって、現在実施している戦略を評価し、さらに新たな戦略を作り出す、この仮説・検証を伴うルーチンを高速に回すことが求められる。これこそが、データに基づく経営マ
ネジメントである。
「データの重要性が経営に十分理解されていない」という課題に対しては、経営者自身にこれまで述べたストーリーを、腹の底から納得してもらうしかない。国際通貨基金（IMF）のゲオルギエバ専務理事は「不確実性の高まりが続いていくことこそが新しい常態（ニューノーマル）である」と述べている。新型コロナ禍だけでなく、世界中の政治、経済情勢の先行きは不透明であり、変化の激しい経営環境はまだまだ続くだろう。この状況下で、データなど経営に不要だと考え続ける経営者がいるのであれば、もはや退場していただくことをお薦めしたい。

XⅢ．2 デジタルビジネスの継続的な創造
新しいサービスが求められる時代が訪れている。その背景には、市場が成熟化し個々人のニーズが多様化し始めていることがある。既存の製品やサービスのコストを下げたり、品質を向上させたりすることだけでは顧客は満足しない。過去にどこにもなかった新しいサービスを創造することは今、あらゆる企業に与えられている命題だと言っていい。
そして、これに呼応するように、デジタル技術が指数関数的な発達の結果、単なる効率化の道具ではなく、新しいサービスを生み出すための武器になりはじめている。世界中で生み出され続けている新しいサービスの多157

くは、デジタル技術によってできあがったデジタルビジネスである。
図表 XⅢ-1 示したデジタルビジネスを構成する要素としては、「デバイス」「推論・学習」「アクチュエーター」の三つがあると言われている。「デバイス」とは、センサーなどのいわゆる IoT によって、リアルな人やモノの存在、状態をデータとして読み取り、これを収集、蓄積する機能を意味する。つづく「推論・学習」では、蓄積されたデータを分析することによって、固有の状況に応じた対応策を編み出すことを、さらに「アクチュエーター」は、得られた対応策を再びリアル世界にフィードバックさせることを示す。これらの機能に欠かすことができないのがまさし
く「データ」である。デジタルビジネスを駆動させるためのエネルギーの源がデータなのである。
2017 年 5 月に発刊されたエコノミスト誌の表紙では、データを「世界で最も重要な資源」と表現している。
Google や Amazon、Uber といったデジタルビジネスを先導する世界的企業が、さながら原油のようにデー
タを掘り出しているイラストが描かれている。『日経ビジネス』では、ヒト、モノ、カネに並び、データが企業の資本になる時代がやってきていることを「データ資本主義」という言葉によって示している。新しいデジタルビジネスを創り続けることができないかぎり、企業は競争力を維持していくことができない。そのために、必要となるデータを取得し、管理していくことは不可避なのである。
図表 XⅢ-1 デジタルビジネスの構成要素

また、デジタルビジネスの成功事例を見る限り、その成功の秘訣は「アップデートすること」にあるように思える。
いきなり完成度の高いサービスを構築するのではなく、提供したサービスによる顧客の反応をリアルタイムに観察しながら、よりよいサービスにアップデートし続けていく形態をとっていくことが重要なようだ。個々の顧客の挙動を把握し、フィードバックするためにも、データが必要不可欠になる。
Ⅲ章で述べたように「攻めの IT への取り組みが不十分」という課題が生じた背景には、昔からずっと「既存のビジネスを効率化すること」が企業のミッションだったからに他ならない。DX の重要性が叫ばれている状況においてさえも、デジタル技術を既存ビジネスの効率化に向けることが優先されてきている。しかし残念ながら、既に158

効率化だけで企業が付加価値を出していくことは限界に来ている。さらに、今回の新型コロナ禍によって、既存ビジネスの継続自体が危ぶまれている企業も増えている。新しいビジネスを始めるための最大の障壁が既存ビ
ジネスの存在だったのであれば、もう躊躇する必要はない。
新型コロナ禍という新しくかつ世界共通の社会課題が目の前に山積しているこの環境は、新しいビジネスを生み出すためには極めて適していると考えられる。社会的な逆境が新しいイノベーションを誘発することは歴史上珍しいことではないのだ。

XⅢ．3 データを中心としたシステム基盤の構築
Ⅲ章で示した「システム開発・維持管理における標準化が進んでいない」という状況が生まれた最大の理由は、標準化を行うコストに見合ったパフォーマンスが期待できないということだと考えている。標準化自体に意味がないわけではないにせよ、それに必要となる膨大な工数に対する経営上の説明は確かにつきにくい。将来におけるメンテナンスコストの削減も効果にはあげられるだろうが、それだけでは不十分だろう。他企業とのビジネス連携に伴う情報システムの接続などに対しても効果はあるだろうが、日本企業における連携は長期的で固定的な場合が多く、あまり標準化の恩恵は大きいとはいえない。
我々は、システム開発・維持管理における標準化は、先に揚げた「データに基づく経営マネジメントの推進」「デジタルビジネスの継続的な創造」の二つを実現するための基礎として行うことだと整理すべきだと考えている。先述した通り、この二つが企業にもたらす恩恵は計り知れないもので、標準化にかけるコストにも十分見合うものである。
そして、標準化は、データを起点としたアプローチで行うべきである。具体的には、企業のビジネスをシステムの中に写し取る「概念データモデリング」を全社的に適用することが有効だと考える。ビジネスに関する業務プロ
セスは、状況に応じて変動が激しく、これに沿ってシステムを構築することはメンテナンス規模の拡大を招き決して効率的とは言えない。一方、ビジネスに関わるデータは、企業におけるビジネスモデルが大幅に変わらない限
り、長期間にわたり普遍性があるため、これを前提とした開発を行うことによって、柔軟性の高いシステムを手に入れることができる。
ただし、そのためには、部署ごとにバラバラなデータ管理が行われている状況を打破する必要がある。同一のデータは同一の名称で語られなければならないし、マスターデータも一元管理できていなければならない。さらには、データそのものの最新性、正確性も常時確保されている必要がある。
また、データを中心とするシステムであっても、一度作り上げてしまえばそれで完成するものではない。システ
ムが変化していくことによって正常なデータ管理ができなくなることを避けるために、データを管理するための専門組織を IT 部門の中につくる必要がある。この専門組織は、概念データモデルを維持していくことを目的として、データ管理に関する一切の権限を持つ部署である。社内で保有しているデータへアクセスするプログラムは、
この組織の了解がないと利用できないようにすべきだ。専門組織はデータ管理のみならず、企業内のナレッジ、
ノウハウを維持するための組織だともいえる。経済産業省の「DX レポート」の中でも述べられている通り、レガシー化しているシステムをモダナイズすればこの問題が解決するわけではない。何も管理しなければ時間とともに、再度システムはレガシー化してしまうのだ。これを避けるためにも、データ管理するための専門組織は役立
つだろう。
159

XⅢ．4 変化に追従できる俊敏なシステム構築
最後に残る「情報システムに柔軟性がない」という課題は、少し捉えなおす必要がある。情報システムは、ビジネスの写像である。つまり情報システムに柔軟性がないのは日本企業のビジネスプロセス自体が柔軟性を持たない、もしくは持つ必要がなかったからだろう。日本企業は長い歴史を持っているところも多く、ビジネスモデル
をあまり変化させずに業務を続けていることも少なくない。このような状況で業務プロセスをそのまま写し取った情報システムが柔軟性を持たないのはある意味当然だと考えられる。
しかし、ビジネスのスピードは年々高速化し、経営環境は激しく変化し続けている。柔軟性のあるシステム構
築が、今後必要不可欠になるのは間違いない。
また、柔軟性がない情報システムが生まれる背景には、日本企業では、情報システムを「モノ（製造物）」と認識しすぎているということがあるとⅢ章で述べている。この考え方を脱却し、「情報システムとは日々育て上げるもの」だと認識しなおすことも必要だろう。そもそもソフトウェアの最大の特性は「書き換えられる」ことにある。情報システムを「完成品」として見ずに、「永遠のベータ版」だとみなすことが必要だろう。
変化に追従できる柔軟なシステムを構築していくためには、データオリエンテッドな開発手法（DOA）などの採用が有効である。また、俊敏にシステムを変更させていくためには、ウォーターフォール型ではなく、アジャイル型の開発を指向する必要もある。加えて、より緊急的な状況においては、いわゆるローコード・ノーコードといった技術を活用しながら、利用者が自らの手で簡易なプログラムを作成することで対応していくこともあり得る。
ただし、全ての情報システムに対して、同じような柔軟性が必要だとは言えない。対象となる情報システムの目的、機能によって求められる柔軟性が異なることにも注意が必要である。
データを中心とするシステムを構築するということは、「変化することを前提としてシステムをつくる」ことである。柔軟性を持ったシステムは、企業にとって効率面からみてもあるいは戦略面からみても有効な武器になるだ
ろう。

160

XⅢ．5 データ経営実現に向けた提言
データ経営の重要性を語ってきたが、実際の企業において、これを実現するためのハードルは高い。今までの経営スタイルを変えることは経営者自身が優秀であればあるほど容易ではない。データ管理を適正に行うためのレガシーシステムの刷新には大きなコストがかかりかつ成功率も高くはない。デジタルビジネスが必要だとしても、それを IT 部門が自ら創り出すことは難しい。この状況を打破するための一歩を踏み出すためには、読者をはじめとする IT 部門が自ら考え行動することしかない。
本項では、データ経営実現に向けた企業への提言を提示したい。IT 部門が、経営者を説得するための材料として活用していただければ幸いである。
図表 XⅢ-2 に、「システム高度化へ向けた問題とデータ経営の実現」をまとめた。
図表 XⅢ-2 システム高度化へ向けた問題とデータ経営の実現

XⅢ．5．1 DX の推進をデータ経営へシフトする好機と捉える
DX は、既にあらゆる企業における経営上の大きなテーマになりつつある。しかし、経営者から「DX を推進せよ」という掛け声は聞こえるものの、具体的に企業において何をどのように進めるべきかという方向性については曖昧なままで、結果として DX がうまく進んでいないような状況も少なからず見受けられる。
我々は、これまで述べてきた、「データドリブンでビジネスを推進する重要性を理解し、データ経営を実現する」ということこそが、DX の本質だと考えている。既存ビジネスをそのままデジタル化することは DX ではないし、AI や IoT といった技術を使うことだけでは DX は実現しない。重要なのはデータを起点とし、データを駆動しながらビジネスを進めていくという思想を持つことである。
本章で述べてきた四つのメッセージ、「データに基づく経営マネジメントの推進」とは DX 推進のために必要なガバナンスを構築するという位置づけになるし、「デジタルビジネスの継続的創造」は、DX によって新しい顧客体験を創り出すことそのものを意味する。そして「データを中心としたシステム基盤の構築」「変化に追従できる
161

俊敏なシステム構築」の二つは、DX 推進を容易にするためのシステム環境の方向性を示すことだと言える。
新型コロナ禍においてさらに強く認識され、加速し始めている DX への追い風をうまく利用して、「データ経営とは、DX の本質そのものである」「DX 推進上、データ経営へのシフトは必要不可欠である」というストーリーを組み立て経営者に掲げることをお薦めしたい。

XⅢ．5．2 レガシー刷新はナレッジ継承のための活動とみなす
レガシーシステムの刷新を行うことには大きなコストが必要になることも多い。また、刷新プロジェクト自体の難易度も高く、時間もかかる。さらには成功したとしても、機能面からみれば現状維持であることも多く、システ
ムの利用者側からみたときに満足度が上がるようなものではない。
「DX レポート」にある通り、将来の DX 推進のための基礎となるアクションであることは間違いないのだが、経営者からみればまだ見えない DX への投資は必ずしも積極的にはなれる案件とは言えない。
このレガシーシステム刷新の目的に「自社のビジネスに関するナレッジを継承する」ということを加えてはいかがだろうか。ブラックボックス化しているシステムを見えるようにすることを、自社で暗黙知になっている知識や経験を、形式知化する行為とみなすのだ。人材流動化が進むこれからの将来に向けては優先度の高いアクションだと言えるのではないだろうか。
さらに、レガシーシステム刷新は、IT 部門の人材のスキルを大幅に向上させるチャンスだとも言える。伊勢神宮で 20 年ごとに社殿を移す「式年遷宮」の目的には、経年変化による老朽化対策ということだけでなく、次世代へ神殿造りの技を伝承させることもあるそうだ。レガシーシステム刷新もこれと同じ効果が期待できるはずだ。

XⅢ．5．3 IT 部門のミッションに「ビジネス創造の支援」を加える
新しいビジネスを、指数関数的に発展しているデジタル技術を活用することで生み出すことが可能になっているのは前述のとおりである。デジタル技術を社内で最もよく理解している IT 部門に、この「デジタルビジネスを創出すること」を命じることはある程度自然なことではある。しかし、現場の要求事項に沿って情報システムを開発することを生業の中心としてきた IT 部門にとって、新しいビジネスを創りだすためのケイパビリティは残念ながら持ち合わせてはおらず、ハードルはかなり高い。とはいえ、ビジネス部門にデジタルビジネス創出のすべての機能を持たせることは、デジタルビジネスを実現させるためのシステムと IT 部門が管理している既存システ
ムとの距離を遠ざけることにつながる可能性も高く、お薦めはできない。
我々は、IT 部門が、デジタルビジネスをビジネス部門が創造するためのプラットフォームを提供する役割を担えばよいのではないかと考えている。つまり、デジタルビジネスを生み出しやすくするための環境や基盤（デジタ
ルビジネスの構想検討を支援する、PoC の立ち上げを支援する、システムを実装するなど）を提供するわけである。
IT 部門は、黎明期から「既存ビジネスを推進する支援」を、情報システムを通じて行っていた組織である。デジタル時代を迎えるにあたって、これに新たなミッションとして「新規ビジネスを創造する支援」を加えたい。

162

ⅩⅣ章 あとがき
海老原 吉晶「システムは動いて当たり前、止まればこっぴどく責められる』と言う言葉は、多くの企業情報システム担
当者にとって聞き飽きた（言い飽きた）嘆きだろう。システムが止まらないことに心血を注げば、今度は「守りばかりでなく攻めの IT 部門になれ』と煽られる。ICT の活用がビジネスの雌雄を決するこの時代にあって、
なぜこんな不条理が続くのか？どうしたらこんな状況から脱却して、日本企業が成長を取り戻すキーファク
ターとしての ICT の価値を再生させることができるのか？という想いで議論を重ねてきた。本書は、そんな袋小路から抜け出し、システムを真に企業価値へ資するものへと高度化するための、システムの作り方と使い方をまとめたものである。ここで、「作る・使う」の主語は、IT 部門だけではなく、組織と経営であることを注記しておきたい。

森 弘之
思い返すと 2017 年から 5 年この議論に参画している。5 年前の問題提起は「日本の情報システムが抱える課題」であった。メディアなどでは、欧米との比較で日本の遅れを指摘し続けているが、その活動が成果を出せていない事実。私としてはこの問題に向き合った 5 年間であった。問題の根源にあると思われる日本の IT 企業の実態を知るため、さまざまな経験をされてきたメンバーと議論を重ねたり、200 社を超す IT 企業のホームページを調査したり、「日経コンピュータ」を創刊号から読み返したりした。その結果見
えてきたものが、本報告書にはちりばめられていると実感している。本報告書を契機にさまざまな議論が巻き起こり、ビジネスを真に支える IT になることを期待したい。

野々垣 典男
少なからずシステム開発の失敗を経験し、長らく「なぜうまくいかないのか」と考えていたのが 57 歳で大学院に通い始めたきっかけとなった。そこで出会った知識領域が「システムズエンジニアリング」。かつて米国 NASA が宇宙開発で失敗が続いた時期があり、失敗から救ったのがシステムズエンジニアリングに基づく開発であり、それによって成功率が高められた。私にとって「高度化プロジェクト」はその延長線上にあり、データに基づく経営、データ中心の開発が、システム開発を成功に導くカギとなる。大学院では組織マネジメントの研究室に所属していた。それは、私のもう一つのテーマ、すなわち「組織の不条理」について研究したかったからだ。システム開発はエンジニアリングだけでは解決できず、「システム開発が成功する組織」に変革しない限りうまくいかない、というのも修士研究から得た知識だ。組織の不条理さ、理不尽さが
どこからくるのか。それは組織によって原因が異なる。それらを見つめ直し対策することでシステム開発は成功する。それにはトップマネジメントの影響力が大変強く、「トップマネジメント次第」といっても過言ではない。本報告書が少しでも参考になれば幸いである。

163

金井 啓一DOA という言葉は古い言葉である。データマネジメントもデータモデリングもしかり。しかし、昨今これだけ注目されてきたのは、DX がきっかけの一つだろう。DX 成功のキーは言うまでもなく、データ活用だ。
そのため、多くの企業が取組み始めた。しかし、データマネジメントやデータモデリングは、それらに取り組
んでも ROI が計れず、効果が簡単に出ないところに難しさがある。しかも短期ではなく長期で取り組まねばならない。なかなかトップの方々が真剣にならない所以だが、この取組みはもはやコストではなく、未来への投資と考えるべきだ。取り組まねば市場から退場となるだろう。
また、日々お客様と会話して感じることは、現場の“データリテラシー”が低い企業が多いことだ。データ
教育、業務プロセスにデータ活用を組み込む活動など、やるべきことは色々あるが、近道は無く地道に活動を重ね、企業文化に昇華させねばならない。今後もそのためのお手伝いができればと思う。

赤 俊哉
下請けプログラマーとして IT の世界に入り、ベンダー、ユーザーの IT 部門、ユーザー部門、さまざまな立場から情報システムに関わってきた。そんな経験を通して気づいたことがある。それは、システムライフサ
イクル全般において経営に資する「データ」と、そのデータをハンドリングする「プロセス」、そしてその関連性をきちんと管理していくことこそが情報システムの価値を増大させるということである。今回、素晴らしい
メンバーの方々と情報システムの高度化について議論し、報告書としてまとめる機会に恵まれた。約 5 年間の議論を通して、私なりの気づきが私だけの独りよがりではなく、これからの日本の情報システムを考える上で間違いなく意味を持つことを改めて確認できたのは大きな喜びであった。テクノロジーはますます「データの繋がり」を指向していく。この大きな流れの中で情報システムはどうあるべきか。そして「データ経営」をどうやって実現していくのか。本書が、不確かな世界を生き抜くために必要となる、日本人ならではの
情報システム及びデータ経営のありかたについて考えるきっかけになればこれに勝る喜びはない。

飯島 雅
議論の中で、情報技術と情報化技術の適応領域や適用方法がカプセル化されているのではないか、そしてその延長として、データや情報の統合化を狙う基幹系システムの開発は 1990 年代に確立された EA（Enterprise Architecture）や DOA（Data Oriented Approach）、スキルセットとしての ITSS（IT
スキル標準）の適用が不可欠であると考えるようになった。
筆者のまわりでは 2000 年前後に情報システムエンジニアリングアプローチにより開発したシステムの再構築が動いているが、当時作成した To-Be モデルが再構築に向けた As-Is モデルとして再構築議論のスタートになっている。議論のなかで当時のビジネス環境と現状のビジネス環境の変化が、マネジメント＆コントロールプロセスに確実に影響を与え、マネジメント＆コントロール方法を様々な形で変化させていることを目の当たりにしているところである。また、過去の BPR では As-Is モデルの構築から開始された
が、As-Is モデルがある現状ではむしろ、AS-IS モデルの前提になったビジネス環境の再認識と現状の課題についての議論が中心になっており、超上流フェーズの在り方も変化していると実感している。情報シス
テムエンジニアリングの第 2 サイクルの適用結果をフィードバックする機会があればと考える次第である。

164

三輪 一郎本プロジェクトの活動は、予想に反して長期にわたることとなった。だがこれは、本活動が流行やバズワー
ドに左右されないしっかりとした土台の上で議論され続けたことを、期せずして証明したと考えている。議論の土台とした EA（Enterprise Architecture）や DOA（Data Oriented Approach）という概念
は、色褪せることなく DX を支える基礎となっている。また、SoR とも呼ばれたエンタープライズ系の IT は、
SoE やマイクロサービスという拡がりをもってなお、企業間を結ぶ基幹業務を支え続けている。活動の初期に掲げた「高度化」というキーワードは、企業内あるいは企業間の組織と業務を結ぶ仕組みの高度化を指すと考える。我々がデータに着目したのは、データにこそ、これらを結ぶ力があるからである。データはまた、GAFA を代表とする高付加価値企業が共通して蓄積した、無形の資産として注目された。新たな資産としての、データの価値が認められたのだ。データの持つ、結ぶ力と価値、またそのデータをどう手なずけてゆくかの経験知が、本レポートを通じてできるだけ多くの皆様に伝わることを願っている。
最後に、本活動を立ち上げ、指揮しつつも、道半ばにして他界することとなった小田滋氏に感謝と哀悼の意を表して、あとがきを締めくくることとしたい。

金 修
そもそも論から議論が始まり、結構な時間を要したが、参加メンバーの熱意と見識に裏打ちされた意見は、過去自らが行ってきた IT 化の進め方の反省を促される場面も多くあった。そして、パンデミックが、他国と比較してわが国の商慣習の特異点、業務の非効率なやり方、そして IT 化の遅れなどを顕在化させた。
今後、産業構造やビジネスモデルなどが大きく変化することは明らかである。IT という強力なインフラを有効に活用していくための扇の要は、「データ」である。多くの企業や組織にとって「データ経営」は必須であり、IT 活用のこれまでの遅れを取り戻すためにも、本報告書は大きな参考になると確信している。当初リーダーとしてとりまとめを行い、会議終了後も遅くまで一献傾けながら熱い議論を行っていた小田氏が、志半ばで急逝した。本報告書完成が何よりのご供養と思う。心からご冥福をお祈りいたします。

赤司 浩文
若い頃から JUAS の活動に参加させて頂いたことがキッカケで、知識・経験が豊富な今回のメンバーと出会うことができ、会議室や場を移しての議論を通じてたくさんの気づきや学びを持てたことに感謝すると共に、自分自身のこれまでの仕事を振り返ることにもつながりました。我々の議論が今後のユーザー企業
での情報システム高度化への一助となることを祈念しております。
最後になりますが、学校の先輩であり同業界のシステムに関与され、時に弄られた小田様の急逝はとてもショックでしたが、ここに報告書が完成したことで志の幾ばくかは達成できたと思います。ご冥福をお祈りいたします。

三谷 慶一郎私は故小田リーダーからお誘いを受けて 2018 年からこのプロジェクトに参加させていただいた。「日本における情報システムのあるべき姿を「システム高度化」として、企業価値と情報システムの二軸で面積を拡大する方向で議論したい」という小田さんの想いにどこまで貢献できたかはわからないが、さまざまな視点を持つメンバーの方々との濃厚なディスカッションを行う機会をいただきとても感謝している。今般の新型コロナ禍で顕在化した事象も含め、日本における情報システムを取り巻く課題はまだまだ多く存在する。
そして大事なのは、課題を整理するだけでなく、「それらの課題がなぜ今日まで解決されず残っているか」ということを、それに少なからず関係してきた我々の世代自身が総括することだと思う。本書で示した「データ経営」という考え方が、そのヒントになればとても嬉しい。
165

菊川 裕幸システム高度化プロジェクトを企画したきっかけは、① 日本の情報システムはなぜこれほど複雑化・レガシー化してしまったのか？
② デジタル化・DX 推進が重要課題となる中で、このままで良いのか？
という率直な疑問・問題意識であった。志を同じくするメンバーが集まり議論をするなかで、この問題を解きほぐし、レポートとしてまとめることで、日本企業の競争力の復活につなげられるのではないかと考えるに至った。本プロジェクトをスタートさせた 2016 年頃は、デジタル化に注目が集まっていた時期でもあり、当初はバズワード化の懸念もあった「デジタル化」は時代の要請に応えて大きく進歩・発展し、DX 時代を迎えるに至っている。
デジタル化の進展の中で最も懸念したことは、企業の重要情報が基幹システムの中に存在している事
実とその活用を十分に考えないまま AI、IoT、ビッグデータの活用などに突き進んでしまうと、日本の情報システムの複雑化をますます助長させてしまい、むしろ企業の競争力を削いでしまうのではないか、ということであった。
また、一昔前に EUC（End User Computing）という言葉に踊らされ、ユーザーのノウハウだけでシステム構造や維持管理の仕組みを考えないままシステム化し、その改修ができなくなってしまったり、廃棄に至たらざるを得なかったシステムを再現させてしまうのではないかという恐れもあった。
プロジェクトを始めるにあたって、情報システムの歴史とその意義と役割の再考から始めた。その中でDX を発展させるために必要なことの一つが、企業の基幹システムを変化に対応して成長できる姿にすることではないかと考えるに至った。技術革新、IT の進歩、経済環境の変化など、我々を取り巻く環境は常に変化にさらされており、情報システムはそれに迅速に対応していかねば存在する意義を失ってしまう。この変化への対応が素早くできず、無理に情報システムを改修してきたことが、システムを複雑化・レガシー化させてきた原因であると考えるに至った。
変化に対応して何を変えれば良かったのか、何を変えてはいけなかったのか、その答えは、レガシー化してしまったシステムを分析すると見えてくる。企業活動と一体となったシステムで変化が起きているのはプ
ロセスとテクノロジーであり、企業活動に必要なデータはほとんど変化していない。しかしプロセスに対応するアプリケーションがデータと密接に結びついていたシステムであったために、必要に駆られて同様・類似のデータやデータベースをシステム改修のたびに作らざるを得なかったことが最大の問題であった。テク
ノロジーとアプリケーション、さらにデータ（データベース）とビジネスを体系的にとらえるシステム構造としておく必要があったと考えている。
すなわち① データの持つ意味をしっかりと定義すること＝データの正規化＝② 正しいデータの持ち方とデータ間の関連を明確にすること③ それをデータモデルとして分かりやすく標記し、システムに写し取ること
これを EA の考え方に基づき「BA―DA―AA―TA」を疎結合で結ぶアーキテクチャーとして再構築すべきであり、そのために概念データモデルをしっかり描いていく必要があることを提言したく、本レポートをまとめてきた。
DX はデータをどのように収集し、それをどのように活かしていくかが重要であり、その達成レベルが企業の死命を制する時代になっているといっても過言ではない。AI の進歩により、世の中は加速度的に進歩してきているが、この AI でも正しいデータを与えることができなければ、誤った答えに行きつき、進むべき方向を間違えてしまう。企業を発展させていくために DX に取り組むことが必須となっているからこそ、自社の情報システムから正しいデータを迅速に取り出し、活用していくことを真剣に考えていただきたい。本
レポートが皆様の参考になることを望む次第である。
166

最後に、本プロジェクトの発足当時からのメンバーで、座長を務めていただいていた小田滋氏が 2019年 9 月に急逝された。前日まで本プロジェクト会議で議論をして、会議後も場所を変えて色々なお話をしていた翌日の訃報であり、残念でならない。小田氏の志を継いで仕上げた本レポートが皆様のお役に立つことを願いつつ、小田氏のご冥福をお祈りいたします。

平山 貴子
情報システムで企業を、日本を、より良くしたいというメンバーの皆様の熱い想いが形となったことに、敬意と感謝を申し上げたいと思います。私自身は情報システムの開発や運用保守に直接携わった経験はありません。そこで勝手にエンドユーザー代表の気持ちで参加しておりました。そこで感じたことは、情報シス
テムの高度化、というと何だか専門的で難しそうだけれども、思想の根っこはとてもシンプルだということです。「物事の本質は何か」「普遍的なものをよすがとして、このピンチや変化をどう乗り越えようか」。しかしシンプルだからこそ、結果を出し続けるには覚悟がいる、ということも百戦錬磨のメンバーの方々の経験をお聞きして強く感じたことです。
経験と慧眼と、厳しい中にもあふれる優しさでこのプロジェクトをけん引してくださった小田座長、今頃天 国 で目 を細 めてご覧 になっているでしょうか。そしてこのプロジェクトに携 わる機 会 を与 えてくれた
JUAS、そして菊川さんに改めて感謝申し上げます。

167

プロジェクト活動概要

参画メンバー（氏名 50 音順・順不同。所属・役職は現時点と一部プロジェクト参加時点のものである）

赤司 浩文

AJS 株式会社 常務執行役員

飯島 雅

富士通エンジニアリングテクノロジーズ株式会社 執行役員
ソリューション事業本部 本部長補佐

海老原 吉晶株式会社リアライズ マーケティング営業本部 マーケティング＆ブランディング担当部長

金井 啓一

日本テラデータ株式会社 コーポレート・エバンジェリスト／エグゼクティブ・コンサルタント

金 修

株式会社ビジネスクリエーションラボ 代表

赤 俊哉

IT エンジニア

野々垣 典男

プロメトリスト 代表

本間 理陽司東京ガス i ネット株式会社 電力 CIS 部 myTOKYOGAS
グループマネージャー（2017 年度ご参加）

三谷 慶一郎株式会社 NTT データ経営研究所 執行役員 エグゼクティブ・コンサルタント

三輪 一郎

株式会社プライド 執行役員 シニア・システム・コンサルタント

森 弘之

JFE システムズ株式会社 執行役員

＜事務局＞
小田 滋

一般社団法人日本情報システム・ユーザー協会 主席研究員
本プロジェクト主査（2019 年 9 月ご逝去）

菊川 裕幸

一般社団法人日本情報システム・ユーザー協会 主席研究員

平山 貴子

一般社団法人日本情報システム・ユーザー協会

開催概要
2017 年度

全 8 回開催2018 年度

全 11 回開催

2019 年度

全 11 回開催（新型コロナウィルス感染拡大の影響により 2 回中止）

2020 年度

全 13 回開催（オンライン開催）

2021 年度

全 5 回開催（オンライン開催）

168

データ経営が日本を変える！
2022 年 3 月 31 日

初版

著者・編者・発行・制作

第 1 刷発行
一般社団法人

日本情報システム・ユーザー協会（JUAS）

システム高度化プロジェクト編〒103-0012 東京都中央区日本橋堀留町 2-4-3
日本橋堀留町 2 丁目ビル 8 階
印刷・製本©一般社団法人

株式会社サンエー印刷
日本情報システム・ユーザー協会（JUAS）2022※本書並びに HP にて公開している PDF データ等、すべてのコンテンツの著作権および版権等の各種権利は、当協会及び関係する公官庁・団体・企業に属しています。ただし、研究・教育・文化的利用を目的とした非営利の使用を認めます。詳しくは当協会
HP をご確認ください。