これまでBTABoK解説シリーズとして、エンゲージメントモデルを構成するサブモデルを解説してきました。まずはおさらいを兼ねて、それぞれのサブモデルの概観を振り返ってみます。
アウトカムモデル
円環の外側にあるアウトカムモデルは、ビジネスの全構成員が達成したいことをまとめたもので、デジタルアドバンテージに関連するビジネス全体の目標です。
オペレーティングモデル
アーキテクチャの実践における主要な活動、技術、ツール、手法です。アーキテクトがより良い仕事をするための有用な情報源となります。
バリューモデル
価値分析や測定に関するビジネスとエンジニアリング双方の共通概念を扱います。
ピープルモデル
アーキテクト個人の能力（コンピテンシーモデル）を組織化するための手法、役割定義、ツールです。
アーキテクチャ実践
価値あるアーキテクチャの実践を定義します。エンゲージメントモデルの中核思想そのものです。
これらを昨年1年を通して見てきたわけですが、それぞれのサブモデルとその諸概念（プロセス、手法、ツールと技術）の情報量は膨大なので、より深く理解するにはさらなる学習と実践が必要となるでしょう。また、膨大な知識体系であるがゆえに、途方に暮れてしまう方もおられるかもしれません。Iasa日本支部では定期的に勉強会を開催し、参加者の皆さんとエンゲージメントモデルを学んでいますので、是非参加いただければと思います。一人だけでBTABoKのサブモデルや諸概念をバラバラに眺めていても見えてこないこともあります。本コラムでは、多くの方にとってのハマリポイントを解説したいと思います。具体的には以下の2つです。
・エンゲージメントとは、結局何なのかよくわからない
・多くの概念（プロセス、成果物、手法、ツールなど）があるが、どうつながるのかわからない
あらためてエンゲージメントモデルを俯瞰し、それぞれの問いを考察してみたいと思います。
＊＊＊＊
１．結局、エンゲージメントモデルとは何なのか
エンゲージメントモデルの目標とは、「ビジネス技術戦略を実現するためにアーキテクトチームの活動を最大限に活用すること」でした。扱われているのは、「アーキテクトチームの役割」「アーキテクトチームの活動、成果物、ツール」「その実行によってもたらされる企業が達成する成果」です。
ここで重要なことは、アーキテクトチームがデジタルトランスフォーメーションの主要な推進者ではありますが、唯一の当事者ではないという点です。デジタルトランスフォーメーションとは、組織レベルでの総合力戦です。少数の優秀なアーキテクトチームだけで、そのような変革を進められません。協調こそが必要です。そして、協調はエンゲージメントなくして成り立ちません。エンゲージメントとは、何かに対する参加や関与、信頼関係の構築、またはそのような関係を維持することを指します。BTABoKでは「エンゲージメントは、従業員や顧客など、さまざまなグループとの関係において重要である」と述べられています。エンゲージメントが高いグループは、より満足していると感じることが多く、その結果、より多くのエネルギーを注いで仕事やビジネスに取り組むことができます。また、エンゲージメントが高いグループは、より信頼関係が築けるため、協力関係を円滑にすることができます。 BTABoKはこういうことも述べています。「成熟度の低いアーキテクトチームはビジネス・リーダーとの関わりが薄く、ほとんど読まれたり参照されたりしないドキュメントや成果物を作成し、アーキテクト自身もビジネスとの接触が限られていることが多いことがしばしばである」。これは、国内組織の多くにもあてはまるのではないでしょうか。私自身も今まで多くの「孤立するアーキテクト」を見てきました。こうした歪みは、デジタルトランスフォーメーションを阻害します。 「エンゲージメントとは共感すること」「エンゲージメントの第一のルールは人に関わるということ」とBTABoKは述べています。逆の見方をすれば、エンゲージメントを声高に強調しないといけないくらい、多くの組織でエンゲージメントが危機的な状況にあるのかもしれません。
組織のあらゆる階層に、エンゲージメントは存在します。左図はあくまで私のイメージですが、BTABoKエンゲージメントモデルを俯瞰すると、３つのレベルでエンゲージメントを捉えているように思います。アーキテクトチームのレベル、組織全体のレベル（ex.ビジネス部門とテクノロジー部門）、対顧客のレベルです。ピープルモデルは第1のレベルであり、主要な概念に「Extended Team」があります。バリューモデルは第2のレベルが対象となり、「Objetives」「Value Methods」などで組織の共有価値を形成します。こうしたレベルのエンゲージメントが出来ていてこそ、オペレーティングモデルのアーキテクト手法やプロセスが組織全体のビジネス価値を志向し、その結果として顧客エンゲージメントを中心としたアウトカムモデルが具現化できます。BTABoKエンゲージメントモデルからこうしたエンゲージメントの連鎖を理解することが重要と考えますが、皆さんはいかがでしょうか。
２．諸概念（活動、成果物、ツールなど）を、どう組み合わせればいいのか？
エンゲージメントモデルには、アーキテクトがケイパビリティを開発し、成長するために役立つ多くの実践的な活動が含まれています。では、これらの活動の全てを実践する必要があるのでしょうか？
BTABoKはそれを推奨していません。BTABoKの考え方は極めてアジャイルであり、「Think Big, Start Small, Move Fast（大きく考えよ、小さく始めよ、早く行動せよ）」というアプローチを推奨しています。必要最低限な活動から開始すれば良いのです。とは言え、必要最低限な活動とはどこまでを含めるのでしょうか？結局は自分の頭で考える必要はあるにせよ、手引きは欲しいところです。
BTABoKでは、エンゲージメントモデルの特定の活動をThe Red Threadで例示しています。小規模なソリューションや製品の場合、製品が価値を提供し組織の技術戦略や成果と整合していることを確認するには、一般的にこの程度で十分と述べられています。ここではシーケンシャルなフローのように表現していますが、決してウォーターフォール型の活動と考えているわけではありません。これらの活動の多くは、複数のチームメンバーが指導・参加し、同時進行、反復的に行われると理解してください。以下で、それぞれの活動を簡単に説明します。
Threadは、トレーサビリティ、厳格な意思決定、実際のビジネス成果に対する価値管理を提供する最小限の活動のステップです。これは、最小限のサイズ/複雑さの要件をもつ企業内のすべての製品/プロジェクトに適用される最小限のアーキテクチャであるべきです。
特定のケイパビリティと企業に関する成功と目標の測定値を導き出すために使用される手法です。
製品/プロジェクトのメリット、コスト、考慮事項を体系化したものです。ITABoKでは、NABC（ニーズ、アプローチ、ベネフィット、考慮事項）と呼ばれるLeanなビジネスケースを使用しています。
アーキテクトが関心を持つのは、構造的な問題（主に品質属性）、価値（測定可能な利益とコスト）、制約（標準、コンプライアンス、リスク）に影響を与える要件です。 Options
BTABoKでは、設計に役立つオプションと技術的な影響を与える領域を含むモダンアーキテクチャランドスケープを用意しています。
意思決定はアーキテクチャの核心です。BTABoKは、意思決定をより簡単に、より適切に、よりタイムリーに行うことに重点を置いています。意思決定は、要件、品質属性、ビュー、構造、複雑さ、およびアーキテクチャの記述に関連します。
アーキテクチャの構造と品質属性要件に関連する、アーキテクチャの横断的な関心事です。
アーキテクトが意思決定や設計パラダイムを変えてアーキテクチャを見るための、さまざまな方法を提供します。ビューの利用は、優れたアーキテクチャ思考とコミュニケーションの特徴です。
BTABoKはアーキテクトが設計の前段階だけではなく、デリバリー時に積極的に関与することを推奨します。アーキテクトはビジネスチーム、プロジェクト、製品、価値の流れに積極的に関わるべきです。
BTABoKでは、システム展開後の振り返りにおいて、OKRに対するダッシュボードで測定された使用状況情報を評価することを推奨しています。
＊＊＊＊
昨年末の日本経済新聞で「エンタープライズアーキテクトが米国の人気職業として急上昇」という記事が掲載されました。また、IPAから公開のデジタルスキル標準では主要な人材類型としてビジネスアーキテクトがあげられています。このように世の中ではアーキテクトに対して、期待と注目が集められつつあります。アーキテクトはその期待に応えるべく、エンゲージメントを育み、ステークホルダーとの協働活動を充実させていきたいものです。Iasa日本支部では引き続き、BTABoKをテーマとした勉強会やガイダンスとなる情報発信を行っていきたいと考えています。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！