BTABoK Community ~ アーキテクトの内部コミュニティと外部コミュニティ ~
- 西山 達也

- 18 時間前
- 読了時間: 14分
今回のコラムではBTABoKのPeople ModelでとりあげられているCommunityにおける内部コミュニティと外部コミュニティについての考え方を示しながら、Iasa日本支部におけるコミュニティ活動を紹介していきたいと思います。

BTABoKのPeople Model/CominityではIasaGlobalの考える組織やコミュニティのあり方を述べており、BTABoKの記述の中でも、理解を深めておくべきところであると考えます。
以下BTABoKの日本語訳を示すとともに、筆者の見解を加えていきます。
↓↓↓↓↓↓↓↓↓↓ 以下 BTABoK原文(翻訳)↓↓↓↓↓↓↓↓↓↓
コミュニティとは何か
BTABoKでは「コミュニティ」という用語を、組織の内部および外部の拡張チームメンバーのグループを指し、最良のビジネスおよび技術戦略を実現するために協力しなければならないことを指しています。
コミュニティはアーキテクトたちを結びつける存在であり、それを卓越性の中心地やプロフェッショナルの拠点、あるいはその他の言葉で呼ぶ人もいるかもしれません。
アーキテクチャコミュニティの目的は、共有するコンテキスト、範囲、対象領域に影響を与えるアーキテクチャ能力全体を向上させるとともに、コミュニティ自身および組織のために設定した目標を達成することにあります。
さらに、アーキテクチャコミュニティはアーキテクト内部のコミュニティだけでなく外部コミュニティも含め、専門的実践の卓越性の中心地にもなっています。
↑↑↑↑↑↑↑↑↑↑ 以上 BTABoK 原文(翻訳) ↑↑↑↑↑↑↑↑↑↑
拡張チーム(Extended Team)とは、正式なアーキテクチャチームの枠組みを超えて、アーキテクチャ活動を実践する組織です。企業などで組織を越えたワーキングチームを作ったり、個人的に外部のコミュニティに参加してチームとして活動することでアーキテクチャ能力を高めることが出来ます。
ここで述べられている外部コミュニティのひとつが、Iasa日本支部でもあり、アーキテクトの皆さんに貢献すべく、日々活動を続けています。
具体的な活動では、
「エンタープライズアーキテクチャ実践についての情報交換の場」
「ビジネスアーキテクトへの道を目指す研鑽の場」
「若手アーキテクトへの啓蒙の場」
などがあり、それぞれが着実に活動を行って参りました。
IASA日本支部では、2026年度においてもこれらのコミュニティをより多くのアーキテクトに参加いただけるよう体制を準備しております。
それでは、BTABoKにおけるコミュニティについての目的や活動の進め方などを以下に示していきます。
↓↓↓↓↓↓↓↓↓↓ 以下 BTABoK原文(翻訳)↓↓↓↓↓↓↓↓↓↓
なぜコミュニティが重要なのか
BTABoKでは、「コミュニティ」という用語を、単なる緩やかな人々の集まりではなく、組織内および組織とつながりのある専門家集団(ベンダーやサービスプロバイダーを含む)を指すものとして用いています。
BTABoKの信条
以下の信条はBTABoK全体におけるコミュニティへの基本的なアプローチを説明しています。
机上のフレームワークは、現場のコミュニティには敵わない
BTABoKはアーキテクト実務における真のプロフェッショナルモデルに基づいて構成されています。このモデルは、フレームワークやプロセスに単に従うのではなく、自分の仕事に完全に責任を持つ質の高い人材を育成することを目的としています。コミュニティは、アーキテクト能力を最大限に提供するための基盤となります。
専門分野に基づく対立が実践を破壊する
アーキテクチャ業務を発展させるには、「アーキテクト」という肩書きを持つ人々と、その業務に共感する人々(肩書きの有無にかかわらず)が協力して、実用的なエンゲージメントモデルを構築する必要があります。そうしなければ、実践全体の価値を失うリスクを負うことになります。このリスクは、「アーキテクチャ」という用語の使用、そしてステークホルダーコミュニティと組織の戦略におけるその認識に関連しています。
例えば、ビジネスアーキテクトとソフトウェアアーキテクトやソリューションアーキテクトが分断されていたり、意見が対立したりする場合、アーキテクチャ業務全体の主目的を達成するために必要なバリューストリーム(アーキテクチャ)に断絶が生じます。
さらに、アーキテクチャ業務の全体的な価値、目的、ミッションについて、ステークホルダーはあまりにも多くの定義やニュアンスが提供されると混乱してしまいます。多多くの場合、この混乱は、アーキテクチャ・プラクティスに対する全体的な不満へと発展し、さらに悪い場合には、アーキテクチャ・プラクティスの一部または全体が価値を提供していないという認識に至る可能性があります。
コミュニティがアーキテクチャを定義する
前の原則を一歩進めて考えると、アーキテクトのコミュニティ(拡張チームを含む)そのものが、良くも悪くも組織のアーキテクチャを形づくっていると言えます。コミュニティには、専門分野、影響範囲、ドメイン領域に関係なくすべての実務者、拡張チーム(肩書きを持たないアーキテクチャを実践する者)、および内部組織の関係者に影響を与えるベンダーやサービススタッフが含まれます。
このコミュニティが、自らの関わり方のモデルをうまく示し、実践の具体的な姿を明確にし、個々のスキルを高め、さらにステークホルダーとの関係を適切にマネジメントできていれば、アーキテクチャは組織にとって価値あるものとして認識されるようになります。そして、その価値が認められるかどうかの最大の課題は、外部ではなく、実はこの実践の内部にあります。
自分の価値を積極的に見極めましょう
アーキテクトコミュニティの提供する価値(価値提案)は、明確かつ客観的に定量化するのが難しいものです。コミュニティが価値提案を推進するために利用できる主要な要素は三つあります。これらは組織のアーキテクチャに対する見方を劇的に変える重要な要素です。
BTABoKのステークホルダー主導のアプローチを活用してください。価値とは認識によって決まるものです。組織がそう信じていることが、事実かどうかにかかわらず、その組織にとっての“真実”となります。一般的に、1人のアーキテクトにつき3〜5人程度、アーキテクチャ実践において非常に重要なステークホルダーが存在し、その多くは互いに重なり合っています。これらのステークホルダーがチームに価値を感じていれば、そのチームは価値あるものとして認識されます。受け身ではなく、主体的に動くこと。提供されているツールを活用してステークホルダーを適切に分担し、彼らの業務に貢献していくことが重要です。
ガバナンス重視や協議的な目標ではなく、革新的でオーナーシップに基づく目標を設定しましょう。価値ある実践の目標は、どのような価値が提供され、どのステークホルダーに、どのように測定されるかに焦点を当てるべきです。再利用、コスト削減、リスク回避は企業の安定性に焦点を当てています。イノベーションは新規ビジネス、高いリターン、新規顧客、成功したミッション、迅速なサービスなどに基づいています。オーナーシップベースの目標は、設計ではなく提供に重点を置いています。各メンバーやメンバーチームがこの実践からどれだけの成功した成果を生み出したのでしょうか?
エンゲージメントモデルについて明確にしましょう。ここでいうエンゲージメントとは、アーキテクトが当該プラクティスをどのように認識し、いかなる方法でサービス提供を行うかに関する在り方を指します。社内のすべてのアーキテクトが関与し、エンゲージメントモデルを承認すれば、彼らはそれを実装し、実践します。これにより、価値提供における議論や意見の相違、摩擦が減ります。チーフアーキテクトがアプローチを決めるのを待たないでください。専門的な実践には、参加者同士の明示的な合意(暗黙の合意ではない)が含まれます。以下のアプローチは、あらゆるタイプとレベルのアーキテクトで構成されるエンゲージメント運営委員会の設立に役立ちます。
↑↑↑↑↑↑↑↑↑↑ 以上 BTABoK 原文(翻訳) ↑↑↑↑↑↑↑↑↑↑
ここまでは、アーキテクトにとってのコミュニティの意義を述べています。BTABoKでは、それぞれのアーキテクトが現場で十分に活躍できることを重視しており、そのことが実現できる環境となるコミュニティにすることを提案しています。
Iasa日本支部のコミュニティ活動においても、メンバーが対等に議論し、互いに学び合い研鑽することにより、多くの仲間が共有できる成果を生み出せることを目指しています。
次に、BTABoKはどのようにコミュニティを形成し、価値を生み出すかについての取り組みを述べています。
↓↓↓↓↓↓↓↓↓↓ 以下 BTABoK原文(翻訳)↓↓↓↓↓↓↓↓↓↓
コミュニティアプローチ
BTABoKは「コミュニティ」という用語を、医師、建築士、その他の知識・能力に基づく専門職が用いる専門職モデルをある程度模倣した厳格な実践モデルを指すために用いています。
実践コミュニティとセンター・オブ・エクセレンス(CoE)
単に「コミュニティ」という言葉を使うのではなく、組織はそれを実践のコミュニティや集約された知見の中心(CoE)と考えるべきです。このようにコミュニティを発展させることで、コミュニケーションや知識の共有、そしてチーム全体の責任感や共通の目標の意識が大幅に向上します。
成果を達成するためのコミュニティの構築
アーキテクトコミュニティの体制構築には、a) 組織への報告、b) 役割と実践におけるリーダーシップという2つの側面があります。組織への報告やマネジメント構造は、実践が十分な支持と成熟度を獲得し、それらに影響を与えるまで、アーキテクト自身の判断で決定できない場合があります。役割、メンタリング、エンゲージメント定義などに基づくリーダーシップといった実務の実施に関しては、単純な実践コミュニティに基づいて実施することも、本格的なセンター・オブ・エクセレンス(CoE)までに拡大することも可能です。
ただし、こうしたシニア制度も経験年数ではなく、能力と価値成果における実証された卓越性のみに基づくべきであることに留意が必要です。例えば、あるアーキテクトが長年この肩書きを持っていた、あまり成熟していない組織で、その影響力で肩書きを求めてきた場合を考えてみましょう。彼らは長年の経験を持っているかもしれませんが、能力やスキルモデルの重要な側面で多くの期間で挑戦を受けていないかもしれません。
したがって、これらの個人は能力こそが「シニア」アーキテクトと「ジュニア」アーキテクトを区別する唯一の境界であることを理解することが不可欠です。開発者として何年働いても、ビジネステクノロジー戦略のスキルがない人もいます。また、少なくともアーキテクト職内でのメンタリングや役割配分にも影響します。必要に応じて、経験に基づく認定であるIasa CITA-P/D(注1)に合格することで、これらの役割をふるいにかけることができます。
↑↑↑↑↑↑↑↑↑↑ 以上 BTABoK 原文(翻訳) ↑↑↑↑↑↑↑↑↑↑
IASAにおける認定資格については、IASAGlobalに直接申し込むことも可能ですが、アジアパシフィックの研修体制の一環として日本でも受講できるようにしていくことを検討中です。詳細が決まりましたら、ご案内いたします。
次に、BTABoKはコミュニティが遭遇するであろう課題と対応策について述べています。
↓↓↓↓↓↓↓↓↓↓ 以下 BTABoK原文(翻訳)↓↓↓↓↓↓↓↓↓↓
専門分野とコミュニティ間の対立
専門化活動や役割は、異なる専門分野間でしばしば衝突が生じるため、エンゲージメントモデルの早期段階で対処する必要があります。医学の専門分野を考えると、その違いや内部抗争がなぜ医療機関にとって危険なのかを理解するのに役立つかもしれません。外科医と一般開業医、ERで働く医師はしばしば世界観が大きく異なりますが、どちらも医師と見なされています。この区別は、ビジネスアーキテクトとソリューションまたはソフトウェアアーキテクトが効果的に協働できるアーキテクチャ実務体制を設計する上で役立つでしょう。
質問1:専門家の必要性は?
小規模な組織では、ソリューションアーキテクトやエンタープライズアーキテクトが、一般医に相当する役割を担うことが多くなります。彼らはビジネス、情報、インフラ、ソフトウェア、ソリューションアーキテクチャについて十分な知識を持ち、平均的な企業の製品やプロジェクトを成功に導くことが出来ます。
大規模なチームや高度に複雑な領域では、専門性が存在し、その数も多くなる傾向があります。ビジネスモデル、製品タイプ、業界へのデジタル浸透度などは、専門家が必要かどうかを判断する上でしばしば役に立ちます。例えば、ソフトウェア製品会社と大手銀行では、必要なビジネスアーキテクトの人数が大きく異なるでしょう。アーキテクチャチームキャンバスを活用し、現在のエンゲージメントモデルに専門家かジェネラリストが必要かを判断し、それに応じて採用・育成・指導を行ってください。
質問2:専門家をアサインする方法は?
アーキテクトのアサインは、あらゆる場所にすべてのアーキテクトを配置することは不可能であるため、特に難しい問題です。アサインに関する記述ではアーキテクトのアサインについて詳細なガイダンスとツールを提供していますが、専門家には特別な配慮が必要です。インフラストラクチャアーキテクトが在籍しているのに、データセンターの再構築にソフトウェアアーキテクトを充てるのは非効率的です。以下の内容を参考に、専門分野に基づいてアーキテクトの役割を定義し、アサインを行ってください。
1 一般的に、ソリューションアーキテクトは専門分野を横断する共通スキルに焦点を当てます。彼らは通常のプロジェクトにおける主要な担当者とされ、製品/プロジェクトの健全性のために必要に応じて専門家から支援を受ける自由を持つべきです。ビジネスアーキテクトと連携し、バリューストリームの提供を確実に行います。
2 大規模で複雑なドメイン特化型プログラムは、当該分野の非常に経験豊富なスペシャリストが主導すべきです。この際考慮すべき軸は3つあります。
1つ目は専門性(個人の能力と経験の主な焦点)、2つ目はドメイン特化(医学で言うサブスペシャリゼーション)です。例えば、小売ドメインに特化したソフトウェアアーキテクトであり、モバイルおよびウェブベースのソフトウェアに深いスキルを持つアーキテクトが該当します。配置において考慮すべき3つ目の軸は、ビジネスと個人への価値であります。多くのアーキテクトが特定のプロジェクトに情熱を注ぐ、この動機付けが実践にさらなる品質と利益をもたらします。
3 専門分野における深い知識を理由に、アーキテクトではない人材をアーキテクチャ業務のリーダーに任命することには注意が必要です。アーキテクトは、5つの能力の柱に基づいていなければならず、そうでない場合、その業務にはアーキテクトによる直接的な支援が必要となります。
↑↑↑↑↑↑↑↑↑↑ 以上 BTABoK 原文(翻訳) ↑↑↑↑↑↑↑↑↑↑
上記にある5つの能力とは、以下のようなことになります。
1抽象化思考力: 抽象的な視点で問題を捉え、全体の構造を理解することが重要です。
2仮説を立てて自力で絵が描ける能力: 問題解決のための仮説を立て、具体的な解決策を自力で考えることが求められます。
3俯瞰し・ゼロベースで考える能力: アーキテクトは新しい世界をゼロベースで構想できる力が必要です。新しいものを生み出すために、自分を固定観念から解放することが求められます。
4変革期に必要な新しい思考回路をインストールする能力: ニューノーマルの時代には、これまでの勝ち パターンが通用しないため、新しい思考回路を身につけることが重要です。
5これらの条件を満たすアーキテクト人材は、ビジネスの川上において特に必要とされ、その力は抽象化 思考力として発揮されます。
アーキテクト人材には、ゼロベースで抽象度の高い全体構造を構想する能力、 新しい問題を解決するために、既存の枠組みを超えて考えることが求められます。専門知識の深さゆえに非アーキテクトをアーキテクチャ活動のリーダーに任命するのは慎重であるべきです。
最後に、多様な人材のコミュニティを円滑に運営していくためのアーキテクトのソフトスキルについて述べています。
↓↓↓↓↓↓↓↓↓↓ 以下 BTABoK原文(翻訳)↓↓↓↓↓↓↓↓↓↓
拡張チーム:メンタリングとリーダーシップ
アーキテクトコミュニティの質は、その奉仕者/リーダーとしての能力に比例します。しばしばソフトスキルと呼ばれるこれらの能力は、習得が最も困難な場合があります。メンタリングとリーダーシップは実践的なスキルであり、アーキテクトのキャリア初期段階で指導・評価されるべきです。新規アーキテクトは、適切なメンタリングのもと、エンジニアリング、運用、ビジネスなど他分野の専門家から転身するケースが多いのです。
アーキテクトコミュニティは、リーダーシップとメンタリングプログラムを成熟させ、拡張チーム(Extended Team)について深く理解する必要があります。拡張チーム(ET)の考え方はこの分野に関する直接的な指針を提供しています。
↑↑↑↑↑↑↑↑↑↑ 以上 BTABoK 原文(翻訳) ↑↑↑↑↑↑↑↑↑↑
冒頭のBTABoKの記述にあるように、「BTABoKでは「コミュニティ」という用語を、組織の内部および外部の拡張チーム(ET)メンバーのグループを指し、最良のビジネスおよび技術戦略を実現するために協力しなければならないことを指しています。」というコミュニティに関する捉え方に鑑みると、IASA日本支部が外部の拡張チームの位置づけと言えるかと思います。
IASA日本支部での活動は必ずや皆様のお役に立てると考えております。IASA日本支部のコミュニティ活動については、毎月発行のメールマガジンやホームページでお知らせしております。多くの方のご参加をお待ちしております。



コメント