TOGAF ADM：トップ10の技術 – 第5部：移行計画技術

TOGAFにおける移行計画技術は、企業アーキテクチャの実装および移行を評価・計画するための構造化されたアプローチを提供する。これらの技術を活用することで、アーキテクトは計画が包括的であり、ビジネス目標と整合していることを保証するとともに、実装に影響を与える可能性のある制約や依存関係も考慮できる。

各技術にはそれぞれ特定の目的があり、移行計画プロセスの異なる段階で使用できる。たとえば、実装要因評価および帰結マトリクスは、実装に影響を与える要因を特定および文書化するのに役立ち、ビジネス価値評価技術は、さまざまな選択肢に関連する価値とリスクを評価するのに役立つ。

これらの技術を組み合わせて使用することで、アーキテクトはすべての関連要因を考慮した包括的な移行計画を策定でき、企業アーキテクチャの成功裏な実装を確保できる。

TOGAF ADM 実装要因評価および帰結マトリクス

TOGAF ADM 実装要因評価および帰結マトリクスは、企業アーキテクチャ計画の実装に影響を与える要因を特定および評価するために使用されるツールである。このマトリクスは通常、以下の3つの列で構成される。

1. 要因：この列には、アーキテクチャ計画の実装に影響を与える可能性のあるさまざまな要因がリストアップされる。これらの要因には、リスク、課題、仮定、依存関係、行動、影響、またはその他の関連する要因が含まれる。
2. 説明：この列は各要因について簡潔な説明を提供し、それが何であるか、また計画策定時に考慮すべき重要な理由を説明する。
3. 帰結：この列は、各要因に基づいて行うべき帰結を示す。これらの帰結は、実装計画を策定する際に考慮すべき行動や制約を示す。

たとえば、マトリクスに掲載されている要因の一つが「リスク」であると仮定する。説明列では、この要因は「実装計画の成功に影響を与える可能性のある否定的な出来事や状況」と定義されるかもしれない。帰結列では、特定されたリスクは評価および優先順位付けされ、適切なリスク軽減戦略が講じられるべきであると示されるかもしれない。

全体として、実装要因評価および帰結マトリクスは、実装計画を策定する際、すべての関連する要因が考慮されることを保証し、潜在的な問題や制約に対処するための適切な対応が取られるようにするための有用なツールである。

—

以下は、インスタントメッセージングへの移行を前提としたマトリクスの再構成例である。

要因	説明	帰結
技術の変更
メッセージセンターの閉鎖	メッセージセンターの閉鎖を決定し、インスタントメッセージングを主な通信チャネルとして切り替える	閉鎖が人員およびプロセスに与える影響を評価する 人員がインスタントメッセージングを効果的に使用できるようにするための訓練計画を策定する 閉鎖による潜在的なコスト削減を検討し、それに応じて優先順位を設定する
人員	計画の実施に関与する人および変更の影響を受ける人	実施に関与する人員の役割および責任を特定する 変更が人員に与える影響を評価する 必要に応じて人員の訓練または再配置の計画を策定する
インスタントメッセージング	実装計画の一環として導入される新しい技術	インスタントメッセージングを主な通信チャネルとして使用する際の利点と欠点を評価する インスタントメッセージングを効果的に使用するための人員のトレーニング計画を策定する コスト削減策としてインスタントメッセージングを優先する
コスト	実施計画の財務的影響	計画の実施に関連するコストを評価する インスタントメッセージングの使用など、コスト削減策を検討する 実施過程全体にわたりコストを監視および管理するための計画を策定する

再度述べますが、これは更新された技術に基づいて行列を再生成する可能性のある方法の一つであり、行列で使用される実際の要因、説明、および導出は、取り組んでいる特定のビジネス状況に依存します。

 

統合されたギャップ、解決策、および依存関係マトリクス

統合されたギャップ、解決策、および依存関係マトリクスは、TOGAFアーキテクチャ開発プロセスで使用される技術であり、アーキテクチャ分野におけるギャップを特定・グループ化し、潜在的な解決策およびそのギャップへの依存関係を評価する。

この技術は、アーキテクトが作業を優先順位付けし、解決策が最も大きな影響を与える領域を特定するのを支援する。ギャップをまとめてグループ化することで、アーキテクトはそれらの間の関係をよりよく理解し、複数のギャップを同時に解決する解決策を特定できる。

このマトリクスは、計画および作業パッケージの作成にも役立つ。特定された依存関係は、アーキテクチャ開発プロセスのフェーズEおよびFにおける移行計画の策定を支援し、プロジェクトが適切に優先順位付けされ、ビジネス目標と整合していることを保証する。

全体として、統合されたギャップ、解決策、および依存関係マトリクスは、アーキテクトがアーキテクチャ開発プロセス全体で使用できる貴重なツールであり、ギャップや解決策、依存関係を特定し、作業を優先順位付けし、効果的なプロジェクト計画と実行を推進できる。

例

統合されたギャップ、解決策、および依存関係マトリクスがどのように使用できるかの例を以下に示す：

アーキテクチャ開発プロセスのギャップ分析フェーズにおいて、アーキテクチャチームが現在の状態アーキテクチャにいくつかのギャップを特定したと仮定する。これらのギャップは以下の通りである：

1. 顧客データ用の中央集積型データリポジトリの欠如
2. 事業部門間でのデータ定義の不整合
3. CRMと注文処理システム間の統合が限定的

統合されたギャップ、解決策、および依存関係マトリクスを作成するには、アーキテクチャチームはこれらのギャップをまとめて、潜在的な解決策と依存関係を評価する。たとえば：

以下は、最初の列に番号を追加した例である：

#	ギャップ	潜在的な解決策	依存関係
1	顧客データ用の中央集積型データリポジトリの欠如	顧客データ用のデータレイクを導入する	データ定義の不整合の解決に依存する
2	事業部門間でのデータ定義の不整合	データガバナンスフレームワークと共通データモデルを構築する	データレイクの実装に依存する
3	CRMシステムと注文処理システム間の統合が限定的	リアルタイムデータ交換を可能にするため、エンタープライズサービスバス（ESB）を導入する	データガバナンスフレームワークと共通データモデルの実装に依存する

この例では、マトリクスは、顧客データのギャップを解消するには、データの不整合を解消し、データレイクを実装し、データガバナンスフレームワークと共通データモデルを構築し、最終的にリアルタイムデータ交換を可能にするESBを導入するという複数ステップのアプローチを必要とすることを示している。

このマトリクスは、ワークパッケージの計画、依存関係の特定、フェーズEおよびFのプロジェクトの優先順位付けに使用できる。たとえば、アーキテクチャチームは、データガバナンスフレームワークと共通データモデルの実装を、特定されたギャップを解消する最初のステップとして優先し、これはデータレイクとESBの実装の両方に依存するためである。

アーキテクチャ定義インクリメント表

アーキテクチャ定義インクリメント表は、オープングループアーキテクチャフレームワーク（TOGAF）で使用される技術であり、アーキテクトが企業アーキテクチャの開発を時間の経過とともに計画および追跡できるようにする。この表は、アーキテクチャの開発に貢献するさまざまなプロジェクトをリストアップし、各プロジェクトに、時間の経過に応じて段階的に完了される具体的な成果物を割り当てる。

この表の目的は、開発プロセス中に特定の時点で達成されるアーキテクチャの中間状態であるトランジションアーキテクチャの計画された順序を示すロードマップを作成することである。各トランジションアーキテクチャは、前の段階よりも完成度が高く、最終状態に近いアーキテクチャの段階を表す。

開発プロセスを段階的な成果物に分解し、それらを特定のプロジェクトとタイムフレームに割り当てることで、アーキテクチャ定義インクリメント表はアーキテクトが以下を実現するのを支援する：

1. 企業アーキテクチャの開発を構造的かつ管理可能な方法で計画する
2. 各プロジェクトが適切な順序で実施され、各インクリメントが適切な時期に完了されることを保証する
3. 異なるプロジェクト間の潜在的な依存関係や衝突を特定する
4. 開発プロセスの明確な概要を提供し、ステークホルダーと共有することで、プロジェクトの目標とスケジュールについて全員が一致していることを確認する。

全体として、アーキテクチャ定義インクリメント表は、複雑な企業アーキテクチャプロジェクトを管理し、成功裏にかつ期限内に完了させることを可能にする強力なツールである。

以下は、インクリメントと開始時期の情報を統合した更新されたアーキテクチャ定義インクリメント表である：

プロジェクト名	インクリメント1 – 開始時期	インクリメント1	インクリメント2 – 開始時期	インクリメント2	インクリメント3 – 開始時期	インクリメント3	インクリメント4 – 開始時期	インクリメント4
CRMシステム	2023年Q1	コンセプチュアルアーキテクチャ	2023年Q2	ロジカルアーキテクチャ	2023年Q3	フィジカルアーキテクチャ	2023年Q4	完全稼働システム
データウェアハウス	2023年Q1	コンセプチュアルアーキテクチャ	2023年Q2	ロジカルアーキテクチャ	2023年Q3	フィジカルアーキテクチャ	2023年Q4	完全稼働システム
ECプラットフォーム	2023年Q2	コンセプチュアルアーキテクチャ	2023年Q3	ロジカルアーキテクチャ	2023年Q4	フィジカルアーキテクチャ	2024年Q1	完全稼働システム
モバイルアプリケーション	2023年Q2	コンセプチュアルアーキテクチャ	2023年Q3	ロジカルアーキテクチャ	2023年第4四半期	物理アーキテクチャ	2024年第1四半期	完全運用可能システム

この更新された表では、各プロジェクトに4つのインクリメントがあり、各インクリメントには四半期と年で表された開始時刻が設定されています。これにより、アーキテクトは遷移アーキテクチャのシリーズを計画し、各プロジェクトの完全運用可能システムの達成に向けての進捗を追跡できます。

たとえば、CRMシステムプロジェクトは2023年第1四半期に開始され、その後の各インクリメントは次の四半期に開始されます。表には、完全運用可能システムのインクリメントが2023年第4四半期に予定されていると示されています。これにより、アーキテクトはCRMシステムプロジェクトの完全運用可能システムの達成に向けての計画と進捗を追跡できます。

同様に、表は他の3つのプロジェクトの各インクリメントの開始時刻を示しています。これにより、アーキテクトは各プロジェクトの完全運用可能システムの達成に向けての計画と進捗を追跡でき、また異なるプロジェクト間の潜在的な競合や依存関係を特定できます。

遷移アーキテクチャ状態進化表

遷移アーキテクチャ状態進化表は、The Open Group Architecture Framework（TOGAF）で使用される技術であり、TOGAF技術的参照モデル（TRM）などの定義された分類体系を用いて、組織のアーキテクチャのさまざまなレベルにおける提案される状態を示すものです。この表は視覚的ツールであり、企業で使用されている分類体系内のサービスを特定し、それらのサービスに対する遷移アーキテクチャおよび提案される変換をリストアップするのをアーキテクトに支援します。

この表には、すべてのソリューション構成ブロック（SBB）のリストを含め、それらがリストされたサービスにどのように影響を与え、どのように実現するかを説明する必要があります。また、SBBは企業アーキテクチャの進展を示すためにマークされるべきです。たとえば、新しい機能が導入される場合、表では「new」または「retain」とマークされます。機能が新しいソリューションに移行される場合、「transition」とマークされ、機能が置き換えられる場合は「replace」とマークされます。

遷移アーキテクチャ状態進化表は、組織のアーキテクチャが時間とともにどのように変化するかを明確に示します。アーキテクトは、提案された変更が組織のサービスにどのように影響するか、そして組織が目標状態へとどのように進むかを把握できます。この表を使用することで、アーキテクトは提案された変更が組織の目標や目的と整合していることを確認でき、効果的に実装できるようにできます。

例

以下は、あなたが挙げた列に基づいた遷移アーキテクチャ状態進化表の例です：

サブドメイン	サービス	遷移アーキテクチャ1	遷移アーキテクチャ2	遷移アーキテクチャ3
営業	注文管理	現在状態	遷移状態	目標状態
営業	顧客管理	現在状態	遷移状態	目標状態
財務	支払債務	現在の状態	移行状態	目標状態
財務	未収金	現在の状態	移行状態	目標状態
人事	給与計算	現在の状態	移行状態	目標状態
人事	福利厚生管理	現在の状態	移行状態	目標状態

この例では、最初の列には組織内のサブドメイン（例：営業、財務、人事）がリストアップされています。2番目の列には各サブドメイン内の具体的なサービス（例：注文管理、支払債務、給与計算）がリストアップされています。残りの列は、さまざまな移行アーキテクチャを表しており、現在の状態、移行状態、目標状態を含む可能性があります。

テーブル内の各セルには、そのサービスおよびアーキテクチャに該当する関連情報を記入します。たとえば、注文管理と現在の状態の列のセルには、注文を管理するために現在使用されているアーキテクチャの説明が記載される可能性があり、注文管理と目標状態の列のセルには、将来の注文管理のための提案されるアーキテクチャの説明が記載される可能性があります。

ビジネス価値評価手法

あなたが説明したビジネス価値評価手法は、さまざまなビジネスイニシアチブやプロジェクトを評価および優先順位付けするための有効な方法です。価値とリスクという次元を持つマトリクスを使用することで、企業は戦略的目標や目的と一致する客観的な基準に基づいて選択肢を評価できます。

価値インデックス次元（原則への準拠、財務貢献、戦略的整合性、競争的地位を含む）は、プロジェクトが企業にもたらす潜在的な利益や機会を判断するのに役立ちます。リスクインデックス次元（規模と複雑さ、技術、組織の能力、失敗の影響を含む）は、プロジェクトが直面する可能性のあるリスクや課題を特定するのに役立ちます。

例

各基準に個別の重みを割り当てることで、企業は意思決定プロセスにおける各基準の相対的な重要性を把握できます。これにより、最も重要な要因が評価プロセスでより重視されることが保証されます。

 

最後に、選択肢が明らかになる前に意思決定基準を確立することが重要です。これにより、評価プロセスが客観的かつ一貫性を保ち、すべての選択肢が同じ基準に基づいて評価されることが確保されます。また、バイアスや個人の好みが意思決定プロセスに影響を与えるのを防ぐにも役立ちます。

要約