BTABoKの中には、アーキテクチャの成熟度を評価するための「成熟度モデル」が含まれています。IasaグローバルのBTABoKの成熟度モデルについては、「Maturity Model」( https://btabok.iasaglobal.org/maturity-model/ )を、価値ベースの成熟度モデルの概要については、Iasa日本支部のコラム「BTABoK Maturity Model ～価値ベースの成熟度モデルの概要～」（ https://www.iasa-japan.org/post/maturity-model )をご参照ください。
今回は、BTABoKの成熟度モデルのレベルと評価尺度の例、およびTOGAF（The Open Group Architecture Framework）との比較について紹介します。
１．成熟度モデルの目的
成熟度モデルの目的は、組織がビジネスとテクノロジーのアーキテクチャの成熟度を自己評価し、その結果に基づいて改善を図るためのガイドラインを提供することです。これにより、組織は現在の状態を理解し、望ましい将来の状態に向かって計画的に進むことが可能になります。BTABoKの成熟度モデルでは、価値提供の観点から組織を評価することにより、アーキテクトがチームとして機能していることを確認すること、およびアーキテクチャの安定した段階を通じて組織を成長させることとしています。
２．ソフトウェアアーキテクチャの成熟度モデルのレベル
BTABoKの成熟度モデルでは、価値のデリバリーの観点から組織を見ており、アーキテクトがチームとして機能し、アーキテクチャのフェーズを経ながら組織が成長することを10の評価項目で評価しています。BTABoKの成熟度モデルではレベル0（低い成熟度）～レベル3（高い成熟度）が設定されています（注1）。ここでは、ソフトウェアアーキテクチャの成熟度レベルを、業界標準のCMMI（Capability Maturity Model Integration）の成熟度レベルに対応させてみました（【第1表】参照）。
注1：Iasa Global「Maturity Model」( https://btabok.iasaglobal.org/maturity-model/ )
【第1表】ソフトウェアアーキテクチャの成熟度レベル
成熟度レベル# | 成熟度レベル | 特性 |
レベル１ | 初期（Initial） | アーキテクチャのプロセスや実践が体系化されておらず、個人やプロジェクトごとに異なる。管理も不十分で、プロジェクトごとに異なるアプローチが採用される。 |
レベル２ | 反復・中核化（Repeatable, Managed） | 基本的なアーキテクチャのプロセスが確立されており、類似プロジェクトで反復的に使用される。その結果、一貫性が向上する。 |
レベル３ | 標準化（Defined） | アーキテクチャプロセスが標準化され、全組織内で一貫した方法論として使用される。ドキュメント化と教育が行き届いている。 |
レベル４ | 定量的管理（Quantitatively Managed） | データに基づいた管理プロセスが取り入れられ、定量的な管理や品質保証メカニズムが存在する。パフォーマンスと効率が高い水準で維持される。 |
レベル５ | 最適化（Optimizing） | 継続的な改善プロセスが導入され、最新技術とベストプラクティスに基づいて最適化が行われる。アーキテクチャのプロセスは高度に洗練され、革新が推進される。 |
出典：Iasa Global「Maturity Model」( https://btabok.iasaglobal.org/maturity-model/ ) 及び
CMMI Institute,「CMMI Performance Solutions, Appraisals」（ https://cmmiinstitute.com/learning/appraisals/levels ）を参考に作成。
３．成熟度評価の意義
成熟度を評価することにより、以下のような意義があると考えられます。
（１） 診断と評価： 組織が現在の成熟度レベルを把握し、強みと弱みを特定する。
（２） 計画と成長： 目指すべき目標レベルを設定し、ロードマップを構築する。
（３） 経営判断の支援： アーキテクチャがビジネスの目標と整合しているかを評価し、経営層に情報を提供する。
４．実装のステップ
成熟度を評価し、成熟度のレベルを向上させるために、以下のような実装のステップを踏み、これらを継続的に繰り返すことが重要と考えられます。
（１） 現状評価： 現行のアーキテクチャのプロセスと実践をレビューし、現状の成熟度レベルを評価する。
（２） 目標設定： 組織が達成したい成熟度レベルを定義する。
（３） ギャップ分析： 現状と目標レベルの間のギャップを特定し、そのギャップを埋めるための具体的なアクションプランを策定する。
（４） 実行と監視： アクションプランを実行し、継続的に進捗をモニターする。
（５） 継続的改善： 定期的に評価と改善を行い、アーキテクチャの成熟度を向上させていく。
BTABoKの成熟度モデルは、組織がビジネスとテクノロジーアーキテクチャの整合性を確保し、競争力を高めるための重要なツールとして機能します。繰り返しの評価と改善を通じて、組織の能力を高め、ビジネス上の目的達成に向けた堅固な基盤を築くことができると考えられます。
５．成熟度モデルの評価尺度の例
成熟度モデルの具体的な評価尺度は、組織やモデルにより異なる場合がありますが、以下に、共通して利用可能と考えられる典型的な評価尺度とその例をいくつか挙げます。
（１）プロセス管理
a. 定義と標準化： プロセスがドキュメント化され、組織全体で標準化されているか。 （例）定義されたアーキテクチャフレームワークの有無、ガイドラインやテンプレートの利用。
b. プロセスの反復： プロセスが繰り返し実行されているか。
（例）継続的なプロジェクトで同じプロセスが使用されているか。
（２）プロジェクト管理
a. プロジェクト計画とスケジュール： プロジェクト計画がどれだけ効果的に作成され、管理されているか。
（例）プロジェクトマネジメントツールの使用、進捗の追跡、リソース管理。
（３）リソースとスキル
a. 人的資源： アーキテクトと関連プロフェッショナルのスキルと経験のレベル。
（例）認定資格、研修プログラム、専門知識の宝庫。
b. テクノロジー資源： 必要な技術資源の整備状況。
（例）最新の開発ツールやプラットフォームの利用。
（４）ガバナンスと監査
a. ガイドラインとポリシーの遵守： ガイドラインや開発ポリシーが遵守されているか。
（例）コードレビュー、アーキテクチャレビュー、コンプライアンスチェック。
b. 監査メカニズム： プロジェクトが内部・外部監査メカニズムを実施しているか。
（例）第三者評価、外部監査、内部監査チームの存在。
（５）リスク管理
a. リスク特定と管理： リスクが特定され、効果的に管理されているか。
（例）リスクレジスターの存在、リスクマネジメントプロセス、リスク緩和策。
（６）コミュニケーション
a. 情報共有： アーキテクチャ情報が効果的に共有されているか。
（例）ドキュメント管理システム、チームミーティング、ステークホルダーへの定期的な報告。
b. ステークホルダー管理： ステークホルダーがプロジェクトにどう関与しているか。
（例）ステークホルダーマッピング、関与度の評価。
（７）継続的改善
a. パフォーマンス評価： プロセスやプロジェクトのパフォーマンスがレビューされ、評価される頻度。
（例）定期的なパフォーマンスレビュー、フィードバックメカニズム。
b. 改善策の導入： 改善提案が実際に採用・実行されているか。
（例）ベストプラクティスの導入、教訓の共有、プロセス改善の実施。
（８）イノベーションと技術採用
a. 技術導入の迅速さ： 新しい技術やツールを迅速に導入できるか。
（例）パイロットプロジェクトの実施、技術評価チーム。
b. イノベーションの促進： 革新的なアイデアや方法を積極的に採用する文化。
（例）ハッカソン、イノベーションラボ、研究開発投資。
これらの評価尺度を用いることで、組織の現在のアーキテクチャの成熟度を詳細に分析し、改善点を特定する参考になると思われます。組織はこうした評価尺度に基づいて、プロセスや実践を進化させるための具体的なアクションプランを策定し、成熟度を向上させることができるでしょう。
6. BTABoKの成熟度モデルとTOGAFのフレームワークとの比較
BTABoK成熟度モデルとTOGAFは、どちらもアーキテクチャの実践に焦点を当てていますが、その範囲、目的、焦点は異なります。BTABoK成熟度モデルは、ソフトウェアアーキテクチャの成熟度評価と改善を目的としているのに対し、TOGAFはエンタープライズアーキテクチャの開発と管理のための包括的なフレームワークです。ここでは、2つのフレームワークを比較し、その概要を【第2表】に記してみました。
【第2表】BTABoK成熟度モデルとTOGAFの比較
比較項目 | BTABoK 成熟度モデル | TOGAF |
1．目的 | 価値提供の観点から組織を評価することにより、アーキテクチャがチームとして機能していることを確認すること、およびアーキテクチャの安定した段階を通じてプログラムを成長させる。 | エンタープライズアーキテクチャフレームワークであり、エンタープライズアーキテクチャを開発・管理するための方法論とツール群を提供する。ビジネスアーキテクチャ、情報システムアーキテクチャ、エンタープライズアーキテクチャなど、広い範囲をカバーしている。 |
2．対象範囲 | 主に組織のソフトウェアアーキテクチャを評価し、改善することに焦点を当て、組織内のソフトウェアアーキテクチャの実践に対応するように調整されている。 | ソフトウェアアーキテクチャだけでなく、エンタープライズアーキテクチャのさまざまな側面をカバーする包括的なフレームワークであり、ビジネス戦略とIT戦略の整合化を目指す組織に適している。 |
3．成熟度レベル | 組織がソフトウェアアーキテクチャ能力を評価し、改善するために使用できる成熟度レベルに構成されている。 | エンタープライズアーキテクチャを確立し、発展させるための詳細な方法論とガイドラインのセットを提供する。 |
４．採用実績 | ソフトウェアアーキテクチャ能力の強化に重点を置く組織で使用されている。 | エンタープライズアーキテクチャのフレームワークとして広く採用されている。TOGAFには多くの実践者コミュニティがあり、エンタープライズアーキテクチャへの構造化されたアプローチを確立しようとしている組織でよく使用されている。 |
５．柔軟性 | 組織固有のニーズと状況に基づき、ソフトウェアアーキテクチャを評価し、改善するための柔軟性を提供する。 | 構造化された方法論を提供するが、異なる組織のコンテキストや要件に適応するためのカスタマイズも可能である。 |
出典：Iasa Global「Maturity Model」( https://btabok.iasaglobal.org/maturity-model/ ) 及び
The Open Group Japan「オープン・グループ・ジャパンホームページ」（ https://www.opengroup.or.jp/togaf.html ）を参考に作成。
7. BTABoKの成熟度モデルとTOGAFのフレームワークとの統合について
BTABoK成熟度モデルとTOGAFを統合することで、両フレームワークの強みを活かし、アーキテクチャプラクティスを強化する包括的なアプローチを提供することができると考えています。
まず、2つのフレームワークを組み合わせることで、ソフトウェアアーキテクチャとエンタープライズアーキテクチャの領域をより包括的にカバーすることができ、IT戦略とビジネス戦略の整合性を確保することができると考えられます。また、TOGAFのエンタープライズアーキテクチャフレームワークのコンテキスト内でソフトウェアアーキテクチャ能力を強化するためにBTABoK成熟度モデルを使用することにより、ソフトウェアアーキテクチャの実践をより広範なエンタープライズアーキテクチャ戦略と整合させることも可能ではないかと思われます。さらに、BTABoKの成熟度レベルを使用して、TOGAFのエンタープライズアーキテクチャスタンダードに対するソフトウェアアーキテクチャの実践を評価し、比較することができ、この統合により、ソフトウェアレベルとエンタープライズアーキテクチャレベルの両方におけるギャップと改善の機会を特定することもできると考えられます。
BTABoK成熟度モデルとTOGAFを統合することで、ソフトウェアアーキテクチャの成熟度評価と改善をエンタープライズアーキテクチャ開発のための構造化された方法論と組み合わせることができ、アーキテクチャプラクティスを強化するための強固なフレームワークを提供することができると考えられます。この統合は、IT戦略とビジネス戦略の間のより良い整合性を達成し、アーキテクチャ能力を向上させ、組織全体でアーキテクチャイニシアティブを成功に導くのに役立つでしょう。
しかしながら、統合プロセスにおいての考慮点もあります。まず、両フレームワークにはそれぞれ複雑さと奥深さがあり、統合プロセスを複雑にする可能性があるため、それぞれのフレームワークの異なる概念、方法論、ガイドラインを理解し、整合させるには、慎重な計画と調整が必要です。また、BTABoK成熟度モデルは、主にソフトウェアアーキテクチャに焦点を当てていますが、TOGAFは、エンタープライズアーキテクチャの幅広い領域をカバーしているため、これらのフレームワークの適用範囲と優先順位を整合させ、互いに補完し合うようにすることは、難しい面もあります。さらに、それぞれのフレームワークには、独自の用語、プラクティス、文化的側面があるため、これらの違いを統合することは、利害関係者間の混乱につながる可能性があり、用語や概念の共通理解と整合性を確保する努力が必要になると考えられます。
このような課題を克服するために、統合プロセスを慎重に計画し、利害関係者を効果的に関与させ、適切なトレーニングとサポートを提供し、明確なガバナンス構造を確立し、統合フレームワークを継続的に監視して適応させることで、アーキテクチャの実践を強化することが可能になるのではないかと考えます。
ご一読いただきありがとうございました。
Iasa日本支部では情報交換や勉強会の場を設けており、アーキテクチャーの実践的な活動についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。
Comments