――――――――――――――――――――
★第1部 DX構想の前提と全体像
――――――――――――――――――――
◆第1章 DX推進とスマートワーク
■1.1 スマートワークEAとは
●1.1.1 DXの大前提、スマートワークの推進
●1.1.2 スマートワークEAの概観
■1.2 多様化する“働き方”にどう対応するか
●1.2.1 コロナ禍による変化
●1.2.2 日本におけるDX認知の拡大・浸透
●1.2.3 デジタルネイティブ世代の台頭
【Column】デバイスに関するユーザの声
■1.3 OAからスマートワークへの役割進化
●1.3.1 OAの立ち位置
●1.3.2 DXによるOA大逆転
●1.3.3 OAからスマートワークへの進化
●1.3.4 スマートワーク基盤とは
●1.3.5 スマートワークの未来
【Column】スマートワークの定義について
【Column】EAにおけるWorkplace ExperienceとDEX
■1.4 アーキテクチャ設計上の目線
●1.4.1 ネットワークの進化
・1.4.1.1 モバイルと無線技術の進展
・1.4.1.2 仮想ネットワークやクラウドネイティブなサービスの発展
・1.4.1.3 クラウドネットワークの拡張
・1.4.1.4 ネットワークとセキュリティ
・1.4.1.5 ネットワーク自動化
●1.4.2 アーキテクチャ内におけるOAの立ち位置
●1.4.3 AIの目線
・1.4.3.1 ネットワーク構造におけるAI配置
・1.4.3.2 高度なAIを支える土台
■1.5 スマートワークEAが目指すもの
◆第2章 思いどおりに進まないDXの正体
■2.1 DXで変わらなければならないIT部門
●2.1.1 DXの本質
【Column】アーキテクチャは企業のDNA
●2.1.2 DX推進におけるIT部門の重要性
【Column】アーキテクトの必要性と思考特性
●2.1.3 複雑化するIT資産と向き合うIT部門
・2.1.3.1 基幹システムを中心としたアーキテクチャから分散型アーキテクチャへ
・2.1.3.2 企業体の拡大
・2.1.3.3 基幹システムから新領域への拡大
・2.1.3.4 選択肢の拡大
・2.1.3.5 EUC、EUDのデメリット
・2.1.3.6 複雑化の原因
■2.2 DXを推進するためには
●2.2.1 柱1:EAの構築
●2.2.2 柱2:IT戦略ガバナンス
●2.2.3 柱3:イノベーション機能(R&D)
●2.2.4 スマートワーク基盤
●2.2.5 データ利活用とアジャイルマインドによるサービス創出
■2.3 DXの「To-Be」に向けた新しいIT部門
◆第3章 DX時代におけるEAの再定義
■3.1 なぜ今アーキテクチャ設計か
●3.1.1 かつてのEA - IT主導の最適化ツールにとどまった過去
●3.1.2 DX時代の構造改革 - ビジネスとITの統合へ
●3.1.3 企業に求められる“構造としての未来地図”
■3.2 EA概要
●3.2.1 EAとは
●3.2.2 EAの歴史
●3.2.3 EAのガバナンス
●3.2.4 ユーザ側に必要となる前提
●3.2.5 EAフレームワークの目的
【Column】フレームワークを活用する意味とは
●3.2.6 DXとEAの関係性
■3.3 さまざまなEA構築アプローチ
●3.3.1 EAにおけるTo-Beアプローチ
・3.3.1.1 要件定義のTo-Beアプローチ
・3.3.1.2 EAのTo-Beアプローチ
【Column】問題と課題の違い
●3.3.2 BAドリブンとTAドリブン
・3.3.2.1 BAドリブンの基本構造
・3.3.2.2 TAドリブンの登場
●3.3.3 2つのEA構築アプローチの使い分け
■3.4 次世代のアーキテクチャ設計の要点
●3.4.1 自律分散型×ハイパースケール型のアーキテクチャ
●3.4.2 疎結合アーキテクチャ
●3.4.3 「攻め×ビジネスIT」と「守り×業務IT」の両立
●3.4.4 次世代EAが備えるべき全体像
■3.5 EA構築の進め方
●3.5.1 アーキテクチャパーティション
【Column】EAを継続するには覚悟が必要
●3.5.2 アーキテクチャパーティションとしてのスマートワーク
【Column】「絵に描いた餅」に立ち向かうために
――――――――――――――――――――
★第2部 スマートワークEA 検討編
――――――――――――――――――――
◆第4章 スマートワークEAの全体像と活用方法
■4.1 EAのTo-Beアプローチの構成
■4.2 ユースケースの前提
◆第5章 To-Be構築に向けたアプローチ
■5.1 BAの新たなビジネスドメイン「スマートワーク」
■5.2 アーキテクチャパーティション分割
■5.3 【STEP1】概要As-Is分析
●5.3.1 境界型アーキテクチャの限界
●5.3.2 事業継続性
・5.3.2.1 緊急時対応
・5.3.2.2 ITレジリエンス
●5.3.3 グループ・グローバル・他社連携を見据えた拡張性不足
・5.3.3.1 グループ内での重複業務
・5.3.3.2 グローバル拠点の分散運用
・5.3.3.3 他社連携における技術基盤の違い
■5.4 【STEP2】ハイレベルTo-Be
●5.4.1 ハイレベルTo-Beに向けたプロセス
●5.4.2 システム原則からのアプローチ
・5.4.2.1 システムの本質は抽象化
・5.4.2.2 スマートワークは抽象的なレイヤ
【Column】抽象と具体 ~システムを理解するための基本思考
【Column】抽象化と構造化と階層(レイヤ)の関係性
・5.4.2.3 全体最適化
●5.4.3 TAドリブン
・5.4.3.1 ゼロトラスト
【Column】Identity管理領域の定義
・5.4.3.2 SASE
【Column】ネットワークの未来像
・5.4.3.3 SAML認証
・5.4.3.4 シンクライアント(VDI)からの脱却
●5.4.4 BAからのアプローチ
・5.4.4.1 Purpose(存在意義)の具体化
・5.4.4.2 Values(共有すべき価値観)の展開
・5.4.4.3 Vision(中期的にめざす姿)の具体化
・5.4.4.4 中期経営計画との接続
【Column】Purposeとは
●5.4.5 スマートワークEA ハイレベルTo-Be
――――――――――――――――――――
★第3部 スマートワークEA 成果物編
――――――――――――――――――――
◆第6章 アーキテクチャビジョン
■6.1 スマートワークEA策定の背景と目的
●6.1.1 「スマートワーク」の定義
●6.1.2 「スマートワーク」の範囲
●6.1.3 背景
●6.1.4 目的
■6.2 ステークホルダー
■6.3 スコープ定義
●6.3.1 スマートワークEA策定時点のアーキテクチャ断面
●6.3.2 全社EAとの棲み分け
●6.3.3 全社EAとの関連の将来像
●6.3.4 全社EAにおけるドメイン
●6.3.5 全社EAドメインとスマートワークEAの関連
■6.4 プリンシプル
●6.4.1 全社EAにおけるプリンシプルとの関係
■6.5 スマートワークEAの構成・体系
●6.5.1 スマートワークEAの構成
●6.5.2 スマートワークEAの体系と目次構成
◆第7章 スマートワークEA 共通BA
■7.1 スマートワークにより達成したいGoal
●7.1.1 スマートワークが提供したいValues(価値)
●7.1.2 働き方をめぐる外部環境
●7.1.3 働き方をめぐる内部環境
●7.1.4 スマートワークにおけるCapability
●7.1.5 スマートワークEAにおけるドメイン
●7.1.6 スマートワーク推進における組織と役割
【Column】業務所管/開発所管の役割分担とDX時代の再定義
◆第8章 スマートワーク実現
■8.1 BA(スマートワーク実現)
●8.1.1 「スマートワーク実現」のために必要なドメイン(機能領域)
●8.1.2 「スマートワーク実現」における組織と役割
●8.1.3 ペルソナ別デバイス利用要件
●8.1.4 スマートワークにおける業務プロセス
・8.1.4.1 業務プロセス一覧
・8.1.4.2 Capability「スマートワーク実現」の実現を測る評価指標プロセスにおける接続先
■8.2 DA(スマートワーク実現)
【Column】全社EAにおけるDAとは
■8.3 AA(スマートワーク実現)
●8.3.1 働き方の変化とAAの進化
・8.3.1.1 これまでの働き方を前提としたアプリケーション概要
・8.3.1.2 これからの働き方を前提としたアプリケーション概要
・8.3.1.3 働き方を支えるアプリケーション構成の基本方針
・8.3.1.4 スマートワークにおけるアプリケーション
【Column】情報システム登録の重要性
●8.3.2 アプリケーションマップ
・8.3.2.1 スマートワークにおけるアプリケーション鳥瞰図
【Column】SaaSを活用する理由、AAでの登場
・8.3.2.2 Capability、業務プロセス、アプリケーションの関連
●8.3.3 業務機能とアプリケーションの関連
・8.3.3.1 業務フローと業務プロセスに紐づく業務・システム機能
●8.3.4 アプリケーション機能
・8.3.4.1 アプリケーション機能一覧
・8.3.4.2 機能詳細 クライアント基盤
・8.3.4.3 機能詳細 通信環境/その他ネットワークドメインのアプリケーション機能詳細 クライアント基盤
・8.3.4.4 クライアントごとの求める機能/機能特性
■8.4 TA(スマートワーク実現)
●8.4.1 システム全体構成
・8.4.1.1 ゼロトラストによる構造転換
・8.4.1.2 ゼロトラストにおけるTo-Be実現のためのテクノロジー
・8.4.1.3 セキュリティ概念
●8.4.2 システム構成
・8.4.2.1 ID/アクセス管理
・8.4.2.2 コミュニケーションツール
・8.4.2.3 メール送受信
・8.4.2.4 ドキュメント管理ツール
・8.4.2.5 資源配布
・8.4.2.6 ネットワーク
・8.4.2.7 クライアント基盤
・8.4.2.8 ネットワークセキュリティ基盤
・8.4.2.9 Web分離
・8.4.2.10 情報漏洩防止基盤(DLP)
・8.4.2.11 異常行動分析
・8.4.2.12 エンドポイントセキュリティ
・8.4.2.13 Webアクセス監視
・8.4.2.14 ログ分析
●8.4.3 ソフトウェア構成
●8.4.4 ハードウェア構成
●8.4.5 ネットワーク構成
・8.4.5.1 ネットワーク接続概要
・8.4.5.2 拠点内ネットワーク
【Column】SD-LANについて
【Column】SD-WANについて
◆第9章 事業継続
■9.1 BA(事業継続)
●9.1.1 災害時対応に関する要求
●9.1.2 システム可用性に関する要求
■9.2 TA(事業継続)
●9.2.1 設計方針
・9.2.1.1 災害時対応に関する設計
・9.2.1.2 システム可用性に関する設計
●9.2.2 長期将来構想
【Column】開発環境について
◆第10章 業務高度化
■10.1 BA(業務高度化)
●10.1.1 価値の流れ
●10.1.2 業務モデル
●10.1.3 効果と期待値
■10.2 AA(業務高度化)279
●10.2.1 アプリケーションマップの全体像
●10.2.2 主要アプリケーションの機能構成
●10.2.3 長期将来構想
■10.3 TA(業務高度化)
●10.3.1 構成概要
●10.3.2 セキュリティ構成
●10.3.3 ネットワーク構成
●10.3.4 長期将来構想
◆第11章 グローバル展開
■11.1 BA(グローバル展開)
●11.1.1 価値の流れ
●11.1.2 業務モデル
●11.1.3 効果と期待値
■11.2 AA(グローバル展開)
●11.2.1 アプリケーションマップ
■11.3 TA(グローバル展開)
●11.3.1 システム原則
●11.3.2 システム構造の潮流
・11.3.2.1 集中と分散の歴史・潮流
・11.3.2.2 グローバル環境における制約と設計方針
●11.3.3 システム全体構成
・11.3.3.1 SASE
・11.3.3.2 ID/アクセス管理
・11.3.3.3 コミュニケーションツール
・11.3.3.4 資源配布
【Column】日系企業におけるグローバル対応
◆第12章 グループ展開
■12.1 BA(グループ展開)
●12.1.1 グループ最適なアーキテクチャに対する理念
●12.1.2 共同化全体における観点
●12.1.3 BA共同化に係る課題と対応
■12.2 AA(グループ展開)
●12.2.1 AA共同化の考え方
●12.2.2 AA共同化に係る課題と対応
■12.3 TA(グループ展開)
●12.3.1 TA共同化の考え方
●12.3.2 TA共同化に係る課題と対応
●12.3.3 テクノロジー観点での考慮事項に係る課題と対応
・12.3.3.1 ID/アクセス管理、コミュニケーションツールおよびクライアント基盤の共同化方針
・12.3.3.2 SASEの共同化方針
――――――――――――――――――――
★第4部 アーキテクチャ推進編
――――――――――――――――――――
◆第13章 推進の格子
■13.1 アーキテクチャとプロジェクトの全体観
●13.1.1 EAの全体構造とガバナンス
●13.1.2 EAとプロジェクトの関係性
■13.2 アーキテクチャ推進
■13.3 アーキテクチャに基づいたプロジェクト推進
■13.4 MUFGの推進事例
【Column】超上流から上流まで3年をかけた意思決定
◆第14章 推進するために必要な思考
■14.1 思考の原理
■14.2 危機回避本能 - 本能的思考
●14.2.1 変化を「危険」とみなす脳の仕組み
・14.2.1.1 学生症候群 - 本能的な「先送り」
・14.2.1.2 総論賛成・各論反対 - 安全圏を守る心理
・14.2.1.3 手段の目的化 - 本能が隠れる理屈
・14.2.1.4 熱量がない人も、本能の構造にいる
●14.2.2 推進に時間がかかる理由 - 本能との共存設計
●14.2.3 熱量を維持するためには
■14.3 抽象化思考 - 理性的思考
●14.3.1 抽象化とは何か
●14.3.2 抽象と具体
●14.3.3 BAとの接続 - ストーリーの共有
【Column】体系化のススメ
■14.4 認知バイアス - 本能的思考と理性的思考の交差点
●14.4.1 重要な5つの認知バイアスと推進における焦点
●14.4.2 現状維持バイアスが生む「挑戦しない合理性」
●14.4.3 論理バイアスが生む「正しさの罠」
●14.4.4 作話が生む「変われない過去」
●14.4.5 認知バイアスを前提とした「推進設計」
■14.5 長期思考と短期思考の原理
●14.5.1 時間軸の構造 - 短期思考と長期思考の関係
●14.5.2 心理学の視点 - 確実性欲求と時間的自己効力感
●14.5.3 超上流工程における思考分担
・14.5.3.1 短期思考の構造 - 現実を守る力
・14.5.3.2 思考分担の設計 - 構想と実装のフェーズを分ける
●14.5.4 アーキテクチャ推進における条件
●14.5.5 チームが思考を現実に変える力
■14.6 組織力学を踏まえた変革推進の原理
●14.6.1 組織力学とは
●14.6.2 思考がつなぐ出会い
●14.6.3 ビジネスパートナーの支援
●14.6.4 組織を動かせるマネジメントの支援
●14.6.5 組織に根付く深層の価値観
【Column】構造化こそ万能なスキル
◆第15章 超上流工程
■15.1 超上流工程とは何か
●15.1.1 工程の意味
●15.1.2 先行投資概念
●15.1.3 単純更改の限界
●15.1.4 要件開発の重要性
●15.1.5 ゴール設定とクライテリア設計
・15.1.5.1 クライテリアの設計
・15.1.5.2 ExitとEntryを意識した超上流工程の進め方
【Column】アーキテクチャはドキュメンテーションが命
■15.2 効果とコストを見積もる
●15.2.1 超概算の意義
●15.2.2 長期視点での効果設計
●15.2.3 MUFGの実践
■15.3 超上流工程の設計コスト
●15.3.1 超上流工程は経費で実施すべき
●15.3.2 投資フェーズへの切り替えタイミング
■15.4 超上流工程の条件
●15.4.1 推進の立ち位置と体制構築
●15.4.2 思考の条件
【Column】アーキテクトは真のジェネラリスト、PMは軸をもつスペシャリスト
・参考資料(Web公開資料/書籍)