「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」で紹介されていた「Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (English Edition)」をざっと読んだという話。
『Enterprise Architecture as Strategy』Jeanne Ross、Peter Weill、David Robertson著（Harvard Business Review Press、https://lethain.com/notes-on-enterprise-architecture-as-strategy）は、ソフトウェア（当時の言葉では「IT」）の進化、企業内での成熟度、事業部門間の結合と統合に関する戦略の選び方を扱っており、一読の価値があります。
- エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定 25.2 書籍、より
この記事は、技術指導者であり元CTOのWill Larson氏が、2006年に出版された書籍『Enterprise Architecture as Strategy』（邦題：『エンタープライズ・アーキテクチャ・アズ・ストラテジー』、Jeanne W. Ross / Peter Weill / David C. Robertson 著）を読み、その核となる理論と現代における有用性をまとめた書評・要約です。
出版から20年近く経っており、事例自体は古いものの、「複数のビジネス部門を持つ企業が、どのようにITとビジネスプロセスを統合・調整すべきか」という現代的な課題に対して、非常に実践的で整理されたフレームワークを提供しているとLarson氏は高く評価しています。
- 実際に読んだ感想
- 各章の覚書
- 1: To Execute Your Strategy, First Build Your Foundation
- 2: Define Your Operating Model
- 3: Implement the Operating Model via Enterprise Architecture
- 4: Navigate the Stages of Enterprise Architecture Maturity
- 5: Cash In on the Learning
- 6: Build the Foundation One Project at a Time
- 7: Use Enterprise Architecture to Guide Outsourcing
- 8: Now—Exploit Your Foundation for Profitable Growth
- 9: Take Charge! The Leadership Agenda
実際に読んだ感想
まず、もっとも重要なのは本書が（一般的な）エンタープライズ・アーキテクチャすなわち、BA・DA・AA・TAの四層で構成されるEAの本ではないということだ。本書で扱われるのはより抽象的な企業アーキテクチャ、もしかすると現代ではビッグピクチャーなどと言われるようなものを中心とした議論である。
その上で20年前の書籍という古さはあるけれど、ビジネスを中心に企業の構造を（ITも含めて）どう統合し調整していくべきかという現在も未解決な課題を扱っているという点では学びは多いという印象だ。この記事では紹介しないが当時の基準で先進的な企業のアーキテクチャがダイアグラムとして紹介されており参考になる。
マイクロサービスもクラウドもない時代であるが、本書が取り扱う抽象度であれば影響は受けていない、そういう点でも興味深い本だというのが感想だ。
各章の覚書
1: To Execute Your Strategy, First Build Your Foundation
戦略を実行するために、まず実行基盤を築く
- 実行基盤とは：ITインフラのことではない。ITインフラと企業のコア能力を自動化するデジタル化されたビジネスプロセスのこと
- 実行基盤を構築するために必要な3つの要素
- オペレーション・モデル
- エンタープライズ・アーキテクチャ
- ITエンゲージメント・モデル（ITとビジネス目標の整合性を保つガバナンスメカニズム）
2: Define Your Operating Model
オペレーション・モデルを定義する
- ビジネスプロセスの「標準化（他部署と同じやり方をするか）」と、「統合（データをどれだけ他部署とリアルタイムに共有・連携するか）」の強弱（2×2のマトリクス）によって、企業のオペレーティング・モデルは4つに分類される
- 協調（Coordination） ［標準化：低 ／ 統合：高］：共有するシステム実装は少ないが、データは高度に共有されるモデル。
- 統合（Unification） ［標準化：高 ／ 統合：高］：共通のシステムを使い、ビジネスユニット間でデータも密に結合しているモデル。
- 多様化（Diversification） ［標準化：低 ／ 統合：低］：ビジネスユニット間での共通点がほとんどなく、一部の共通サービス（人事など）を共有するだけのモデル。
- 複製（Replication） ［標準化：高 ／ 統合：低］：標準化されたシステムを各ユニットに個別に展開するが、ターゲット顧客が異なるため、ユニット間でのデータ連携はほとんど行わないモデル。
3: Implement the Operating Model via Enterprise Architecture
EAを通じてオペレーティング・モデルを実装する
- EAを企業全体におけるビジネスとテクノロジーのイニシアチブを整合させるための強力な管理ツールとして使用する。これは、IT部門が主導するITアーキテクチャ設計のアプローチとしては異なる。
- 経営層が理解しやすいように、本書では「コアダイアグラム」と呼ばれる1枚絵を用いる。コアダイアグラムには以下を表現するする
- コアビジネスプロセス
- コアプロセスを推進する共有データ
- 主要なリンクおよび自動化技術
- 主要顧客
- 2章で紹介された4つのオペレーション・モデル別の事例
- IT部門に任せてEAを作成するのではなく、上級管理職を中心としたオペレーション・モデルの議論から始めるべき
4: Navigate the Stages of Enterprise Architecture Maturity
EA成熟度の段階をナビゲートする
- 企業におけるエンタープライズ・アーキテクチャの成熟度には以下の4つの段階があり、これらは「飛び越えて進化することはできない（必ず段階を踏む必要がある）」
- ビジネス・サイロ（Business silos）：個別の部門がそれぞれ独自のITを最適化している状態。
- 標準化されたテクノロジー（Standardized technology）：技術プラットフォームやインフラを全社で共通化し、効率を高めている状態。
- 最適化されたコア（Optimized core）：全社規模でデータやコアなビジネスプロセスを共通化・共有化している状態。
- ビジネスのモジュール化（Business modularity）：ビジネスプロセスが再利用可能な「モジュール」になり、変化に対して高い機敏性（アジリティ）を持っている状態。
5: Cash In on the Learning
学びから利益を得る
今日のマネージャーは、フォードが行ったように、現代の情報技術の可能性を活用するために、自社を再設計しなければなりません。エンタープライズアーキテクチャの設計は、新技術の利点を提供できる実行の基盤を構築する第一歩です。しかし、アーキテクチャ設計図から利益の実現へと移行するには、マネージャーはビジネスの進め方について異なる考え方をする必要があります。
6: Build the Foundation One Project at a Time
段階的に基盤を築く
- ビッグバン形式での実行基盤の移行はリスクが高い。よって、段階的に移行していく必要がある
- 段階的に移行するためにはガバナンスメカニズムが必要となる
- 三層からなるITエンゲージメント・モデルが有効。業績の良い企業はこういったモデルを用いて、段階的な移行を実現している
- 全社レベルのITガバナンス：意思決定と説明責任の枠組み
- プロジェクトレベルのITガバナンス：成果物標準化とフェーズゲートを含むプロジェクト管理手法
- 連携メカニズム：インセンティブを調整し、PJレベルの活動を全体的なITガバナンスに結びつけるプロセスおよび意思決定機関
- エンタープライズアーキテクチャをコンパスとして活用し、企業を意図したオペレーションモデルへと導く。航路を保つために、ITエンゲージメント・モデルを用いる
7: Use Enterprise Architecture to Guide Outsourcing
EAを活用してアウトソーシングを推進する
- アーキテクチャがアウトソーシングの意思決定の指針となる
- アウトソーシングの三類系
- 戦略的パートナーシップ
- 共同調達（管理責任の共有）
- 取引関係（外注）
8: Now—Exploit Your Foundation for Profitable Growth
基盤をから成長を生み出す
9: Take Charge! The Leadership Agenda
リーダーへのアドバイス
- 10原則
- 実行基盤へのコミット
- 変革はトップダウンから始める
- コアを育成するための「実験」を行う
- アーキテクチャを「羅針盤」かつ「コミュニケーションツール」として活用する
- 段階をスキップしない
- 基盤構築は1プロジェクトずつ進める
- アウトソーシングを活用する
- 人材に投資する
- 「全社的な視点」を評価し、報いる
- 「実行基盤」で従業員に権限を委譲する
