オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年10月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/10 regular meeting of the presentation materials.

1. アーキテクチャ主導の
企業情報システムへ
２０１３．１０．２２ 要求開発アライアンス
今後の企業情報システムは、より俊敏にビジネスのＲＯＩへの貢献が求
められる。一方で、肥大化、複雑化したシステムはメインテナンス上の
多くの課題を抱えている。このような背景で、進化し続けるＩＴ－ＳＥＥＤＳ
の積極的な導入と、安定的なシステム運用を両立する為には、ＩＴアー
キテクチャ主導のシステム化に切り替えていく必要がある。
株）アイ・ティ・イノベーション ビジネス・テクノロジー戦略部
中山 嘉之
1

2. ＩＴアーキテクトとは？
2

3. ＩＴアーキテクトの定義
・ ＩＴアーキテクトとは・・・
「組織の情報戦略に基づき、ITシステム全体のアーキテクチャを
設計する人。さまざまな技術・製品から、ビジネス上の要求を満た
す最適な組み合わせを選び出すことが求められる。これにはビジ
ネスと情報技術の両方の広範な知識が必要となる。」
アーキテクチャ設計：日本国内において、システム開発工程の業務要件
定義の後、“どのようなＩＴを活用して、どのような構造で構築するかを決め
る”方式設計”がこれに近いが、システム化企画、構想段階から必要となる
意味でより広範囲である。
 業種は異なるが、製図や模型を用いてデザインする“建築士”が最も近い。
※近年、プログラムの構造に代表される一部の下流工程の設計に限定したアーキテ
クチャを言うケースがあるようだが、柱や壁や屋根の専門技師は建築士とは呼ば
ない。
3

4. ＩＴアーキテクチャ設計とは？
・ビジネスのＲＯＩ向上のため企業にとって最適なＩＴアーキテクチャを設計する
Business
ﾋﾞｼﾞﾈｽの
特性分析
Business
ＩＴの課題
Analyze
Describe
IT-Architect
ＴｏＢｅ
ＡｓＩｓ
MODEL(Blue-Print)
System
MODEL
MODEL
Migration Plan
4

5. ＩＴアーキテクチャ
不在の結末
5

6. ＩＴアーキテクチャ不在の典型例
手組みシステムの増改築で
Spaghetti化、無政府状態
システムｃ
ＭＳＴ
ｂ
ＭＳＴ
ＳＹＳＴＥＭａ
ＥＲＰ、パッケージ、手組みの
乱造によるＳｉｌｏ化、膠着状態
ＭＳＴ
ＴＲ
ＴＲ
ＴＲ
パッケージ
プロセスＡ１
プロセスＢ２
ｉ／ｆ
ＴＲ
ＴＲ
ＴＲ
ｉ／ｆ
ＴＲ
ｉ／ｆ
プロセスＡ２
プロセスＣ１
プロセスＢ３
ＴＲ
システムａ
ＴＲ
プロセスＣ２
ＴＲ
ＴＲ
ＴＲ
システムｃ
システムｂ
ＥＲＰ
パッケージ
ＭＳＴ
ＭＳＴ
ＭＳＴ
ｉ／ｆ
プロセスＡ３
ＴＲ
プロセスＢ４
ｉ／ｆ
プロセスＣ３
パッケージ
ＴＲ
ＴＲ
ＴＲ
ＭＳＴ
ＭＳＴ
6

7. EA(Enterprise Architecture)の成熟度
・あなたの会社はどのレベル？
Ｂ.競争力あり
C.悪戦苦闘
Ｄ.創世記
・まだビジネス
のＩＴ依存度合い
が低い
・ＩＴコストのコンロー
ルが不能
・ＩＴ部門は巨大なコ
ストセンター
・しばしばプロジェク
トが炎上する
・ＩＴコストはコントロー
ル下にある
・ＩＴがビジネス活動を
支えている
・ＩＴの青写真が存在す
る
・ＩＴガバナンスができ
ている
A.成熟状態
・ビジネスとＩＴが融合
している
・ＩＴアーキテクチャフ
レームワークがある
・ＩＴアーキテクチャ組
織が存在する
・ＩＴがビジネスに価値
をもたらす（プロフィット
センター化）
⇒少なくともＢランク以上にはなりたいもの！
7

8. ＥＡ（エンタープライ
ズ・アーキテクチャ）
8

9. ＥＡ（ｴﾝﾀｰﾌﾟﾗｲｽﾞｱｰｷﾃｸﾁｬ）と普遍性
• 普遍性（抽象的、概念的、本質重視）
ＢＡ
ＤＡ
ＡＡ
ＴＡ
ﾒｲﾝﾌﾚｰﾑ
“お金で調達”はできない
お金で“調達”は難しい
（汎化すれば可）
”調達”が可能
領域拡大中
ｵｰﾌﾟﾝ
ＢＡ
ＤＡ
Business Ａrchi.
Data Ａrchi.
ＡＡ
Application Ａrchi.
ＴＡ
Technical Ａrchi.
Ｗｅｂ
ｸﾗｳﾄﾞ
• 特殊性（物理的、視覚的、外見・操作性重視）
⇒ＩＴアーキテクチャの特徴は、表層部（ＴＡ）の移り変わりの早さにあり、ま
た、そこにパラダイムチェンジをもたらすパワーがある点
9

10. ＥＡとＩＴアーキテクチャの関係
• 普遍的なものを中核に据える必然性
⇒周辺は壊れても中心（柱）は保全
• 変化の多いものを中核に据えると
⇒周りも影響を受け全体が壊れる
ＢＡ
ＴＡ
ＡＡ
ＢＡ
ＤＡ
ＤＡ
ＡＡ
ＴＡ（ベンダー）中心モデルは
ユーザ企業では成立しない
ＴＡ
ビジネス（ユーザ企業）中心モデル
⇒ＩＴアーキテクチャを考える際に、変わらないものは頑丈（Rigid）に設計し、
周辺は柔軟（Flexible）な構造にしておく。その順序は、ライフサイクルの長
さに対応し、ＢＡ＞ＤＡ＞ＡＡ＞ＴＡとなる。
10

11. ビジネスからアーキテ
クチャへの落とし込み
11

12. 事業毎の共通コンポーネントの考慮
事業の類似性に応じ
たアプリ共有
事業競争力
【事業毎のアプリマップ例】
事業Ａ
営業
生産
販売
事業Ｂ
事業Ｃ
ＳＦＡ-ａ
ＳＦＡ-ｂ
ＳＦＡ-ｃ
ＳＣＭ-ａ
ＳＣＭ-ｂ
アプリより小さい
部品共有
【さらなる共通部品化】
SFA
共通
SCM
共通
会計
グループのガバナンス
強化を狙って統一
ガバナンス
人事
インフラ、ＯＡアプリ
⇒可能な限り大きな部品の共有を図ることで生産性、品質の向上を図る
12

13. ＢＡ（ﾋﾞｼﾞﾈｽｱｰｷﾃｸﾁｬ）の中のメリハリ
①コア業務／ノンコア業務の識別
販売
ＳＣＭ
ＳＦＡ
ＣＲＭ
プ
ロ
セ
ス
Ｒ＆Ｄ
ＳＦＡ
研究
ＣＲＭ
管理
PLM
ＳＣＰ*
債権
管理
開発・
安全性
SCE*
LIMS＊
購買
戦略
購買
調達
（製薬事業の例）
会計
管理会計
制度
会計
人事
人材管理
発令・
給与
計算
＊SCP（Supply Chain Planning）
＊SCE（ Supply Chain Execution）
＊LIMS（Laboratory InformationManagement System ）
コア
ノン
コア
業務ドメイン
競争力
強化
ガバナンス
強化
⇒実現方式（ﾊﾟｯｹｰｼﾞ/手組み、ｸﾗｳﾄﾞ/ｵﾝﾌﾟﾚﾐｽ）等の選択に活用！
②今後の経営が向う方向の確認
ガバナンス重視か／事業競争力強化か？どちらの軸か？
どの事業を伸ばし／どの事業を縮退の方に向うか？
⇒アプリ開発を実行する優先順位の決定に活用！
13

14. アプリ実現方式４象限（ＢＡ⇒ＡＡ⇒ＴＡ）
③自社の業務アプリを下記のような４象限にマッピング
変更が多い（コア）
カスタム・パッケージ
開発、
安全性
（バ
ガッ
バク
ナオ
ンフ
スィ
）ス
ＳＣＥ、
ＬＩＭＳ
調達
手組み
人材管理
ＰＬＭ、
ＳＣＰ
ＳＦＡ、ＣＲＭ
戦略購買
債権
管理
研究管理
フ
（ロ
競ン
争ト
力エ
）ン
ド
管理会計
非構造化データ
制度会計
文書管理
ＳＮＳ
発令・
給与計算
ＯＡ
ＢＩ
一体成型・パッケージ
汎用ツール
変更が少ない（ノンコア）
14

15. 理想的なアーキテク
チャの一例
15

16. 適材適所なアーキテクチャ
・日本古来の“アーキテクチャ：”適材適所“
・意味： 「人の能力・特性などを正しく評価して、ふさわしい地位・仕事につけること」
・英語： The right person in the right place.
⇒伝統的な日本家屋や寺社などの建築現場での木材の使い分けがその語源
☆豊富な森林に囲まれた日本では針葉樹・広葉樹など実にさまざまな木材
が建築に使われてきた歴史がある。
建物を支える柱や梁などにも、実に適切
で理にかなった使い分けがなされてきた。
例えば土台には腐りにくく耐久性の高い
檜(ヒノキ)や栗（クリ）を、内装の一部にな
る柱には木目の美しくやさしい肌合いの杉
（スギ）を、また屋根や二階以上の重量を
支える梁には強靭な松（マツ）をといった具
合である｡
また、家具であるたんすには桐（キリ）が
最適とされるのも同様である。
- Wikipediaより 16

17. Ｄａｔａ-Ｃｅｎｔｒｉｃな疎結合アーキテクチャ
・自社のデータモデルを中核とし、適材適所なアプリを疎結合する
・プロセス中心のアーキ
TA
APPL.4
（EXCEL）
APPL.5
（PaaS）
TA
Master
APPL.2
（ERP）
DATA1
ＭＤＭ*
APPL.1
AA
ＴＤＭ*
APPL.3
（Scratch）
Transaction
DATA2
Enterprise Data-Hub
APPL.１
（SaaS）
ＡA
DA
DA
DA
ＡA
APPL.6
（Scratch）
TA
＊MDM：Master Data Management
* TDM： Transaction Data Management （造語）
DATA3
DA
DATA4
DA
ＡＡ中心：サービスベンダー
のモデル
ＤＡ中心：ユーザ企業のモデル
17

18. 先端的ＴＡに対応したインフラ・アーキ
・クラウドとオンプレミスのハイブリッド環境を構築し、順次クラウドへ
各種クラウドサービス
Internet
共通認証ｻｰﾋﾞｽ
徐々にクラウドへ移行
HUB
自社DataCenter
On-Premise
企業のセキュ
リティポリシー
シーに基づき、
予め移行の順
序を決めおく
事が良い。
自社網
自社網からインターネット網へ移行
拠点
拠点
拠点
・クラウド移設の優先順は他システムとのＩ／Ｆの少ない順！
①インターネット共通認証サービスの加入
②オンプレにある各種ＯＡツール（電話含む）をクラウド化
③業務アプリを出し易い順からクラウド化（各Ｉ／ＦはＨＵＢ経由が好ましい）
18

19. マイグレーションプラ
ンニングの具体例
19

20. マイグレーション・プランニング（ＳＴＥＰ１）
【状態Ａ】手組みスパゲッティ化や、
ＥＲＰ、パッケージ等のサイロ化
【状態Ｂ】共通マスタを一元管理し
マスタデータガバナンスを確立
Package
ＭＳＴ
ＭＳＴ
Enterprise-Hub
ＥＲＰ
ＭＳＴ
Scratch
ＭＳＴ
ＭＳＴ
ＭＳＴ
ＥＲＰ
ＭＳＴ
ＭＳＴ
Office-Tool
ＭＳＴ
MASTER
TRANSACTION
自社のマスタモデル
⇒まずはマスターに着目しＭＤＭ環境を構築。
組織、アイテムなどの主要なマスタから１つずつ
中央のEnterprise-Hubに寄せて行く！
20

21. マイグレーション・プランニング（ＳＴＥＰ２）
【状態Ｂ】共通マスタを一元管理し
マスタデータガバナンスを確立
【状態Ｃ】共通トランザクションを一元
管理しデータガバナンスを完成
Package
ﾊﾟｯｹｰｼﾞ
Enterprise-Hub
MDM
Scratch
ＭＳＴ
Scratch
ＥＲＰ
ＭＳＴ
ＥＲＰ
ＴＲＮ
Office-Tool
Office-Tool
ＭＳＴ
ＴＲＮ
MASTER
TRANSACTION
ＴＲＮ汎化モデル
⇒次にTransactionに着目しＴＤＭ環境を構築。
複数アプリに跨る主要なTransactionを汎化し、
徐々に中央のEnterprise-Hubに寄せて行く！
21

22. マイグレーション・プランニング（ＳＴＥＰ３）
【状態Ｃ】共通トランザクションを一元
管理しデータガバナンスを完成
【状態Ｄ】Data-Centricで、Platformフ
リーな、Service疎結合の世界へ
Package
Package
Cloud-Service
Enterprise-Hub
ＭＳＴ
Scratc
h
ＥＲＰ
Cloud-Service
ＴＲＮ
Enterprise-Hub
Scratch
ＭＳＴ
ＥＲＰ
ＴＲＮ
Office-Tool
MODEL
ＭＳＴ
ＴＲＮ
MASTER
TRANSACTION
Office-Tool
Cloud-Service
自社でＫＥＥＰすべきもの
①適材適所にビジネスにマッチしたアプリケーションをマッピング。
②ベンダーロックインから完全に解放されたアーキテクチャ。
③Ｃｌｏｕｄをはじめ各種外部サービスを多用できるソーシングモデル。
22

23. ・企業システムの歴史は全てがマイグレーションの連続と言ってよ
いでしょう。しかし、向かうべき青写真があってこそ、最初の1歩
をどこに踏み出すかが決まります。
ＥＮＤ
23