今回のコラムはBTABoKのpeopleモデルの "Community" について取り上げます。私たちの日常でとかく起こり易いアーキテクトと他の実務家との間のコミュニケーション問題について、コミュニケーションを取れないケースにぶつかってもBTABoKでは分かり合えないと諦めずに、”Community”の存在を提唱しています。
コミュニティとは？
BTABoKでは、コミュニティという用語を、可能な限り最高のビジネスおよびテクノロジー戦略を実現するために協働しなければならない組織内外のアーキテクト、エクステンデッドチームメンバーのグループを指すものとして使用しています。コミュニティは、彼らを束ねる存在であり、センター・オブ・エクセレンスやプロフェッショナリズムなどと呼ぶ人もいるようです。
アーキテクチャコミュニティの目標は、共有するコンテキスト、スコープ、カバレッジに影響を与える全体的なアーキテクチャー能力を向上させ、彼ら自身と組織のために設定した目標を達成することです。
さらに、コミュニティは、アーキテクトの内部コミュニティだけでなく、外部コミュニティも含む、専門的実践のセンター・オブ・エクセレンス（卓越性の中心）です。
コミュニティが重要な理由
BTABoKでは、コミュニティという用語を、ゆるやかな結びつきを持つ人々のグループを指すのではなく、組織内および組織と関係のある専門家の実践的な集団 （ベンダーやサービスプロバイダーを含む)）という意味で使用しています。
BTABoKの信条
BTABoKのコミュニティに対する基本的な考え方は、次のようなものです。
コミュニティはフレームワークを打ち負かす
BTABoKは、アーキテクトの実務における真のプロフェッショナルモデルに基づいています。このモデルは、フレームワークやプロセスに従うのではなく、自分の仕事に対して完全に責任を持つ質の高い人材を育成することに主眼を置いています。コミュニティは、組織がアーキテクトの能力をフルに発揮するためのバックボーンになります。
専門性に基づく対立が、実務を破壊する
アーキテクトの実務を発展させるためには、アーキテクトという肩書きを持つ者と、その実務に共感する者（肩書きの有無にかかわらず）が協力して、実務的なモデルを構築しなければなりません。さもなくば全ての実践全体の価値を失うリスクがあります。このリスクはアーキテクチャーという用語の使用と、ステークホルダーコミュニティや組織戦略におけるその認識に関連します。
例えば、ビジネスアーキテクトがソフトウェアアーキテクトやソリューションアーキテクトと断絶していたり、対立していたりすると、アーキテクチャ実務全体の主要な目的を達成するために必要な価値の流れに構造的な断絶が生じます。さらに、アーキテクチャの全体的な価値、目的、使命について、多くの定義やニュアンスが提供されると、利害関係者は混乱してしまいます。多くの場合、この混乱はアーキテクチャ業務に対する全体的な不満に発展し、最悪の場合、アーキテクチャー業務はその一部または全部において価値を提供していないと考えるようになるかもしれまません。
コミュニティがアーキテクチャを定義する
前述の考え方を積極的に拡張すると、アーキテクトのコミュニティ（拡張チームを含む）は、良くも悪くも組織内としてのアーキテクチャーの定義になります。このコミュニティには、専門性、影響範囲、ドメイン領域に関係なく、すべての実務者、エクステンデッドチーム（肩書きを持たずにアーキテクチャを実践している人）、組織内部の利害関係者に影響を与えるベンダーやサービスのスタッフが含まれます。このようなコミュニティが、エンゲージメントモデルを設計し、実務の定義を提供し、個人のコンピテンシーを高め、ステークホルダーコミュニティを効果的に管理するために機能すれば、アーキテクチャ自体が組織にとって価値あるものとみなされます。価値を認めてもらうための第一の課題は、実践の外からではなく、実践の中からやってきます。
積極的に価値を見出す
アーキテクチャコミュニティの価値提案は、明確かつ客観的に数値化することが難しい。コミュニティがその価値提案を推進するために利用できる3つの主要な要素があります。これらは、組織のアーキテクチャに対する見方を大きく変える重要な要素です。
1. BTABoKのステークホルダー主導のアプローチを利用する。価値は認識である。その真偽にかかわらず、組織で信じられていることが真実である。企業内には、アーキテクト1人につき平均3～5人の利害関係者がおり、彼らはアーキテクチャ業務にとって深く重要であり、オーバーラップする部分も多い。これらのステークホルダーがチームを価値あるものと認識すれば、チームは価値あるものとみなされる。消極的にならず、積極的に行動してください。提供されたツールを使って彼らを分担し、彼らの仕事に変化をもたらしてください。それは必ずうまくいきます。
2. ガバナンス重視や協議重視ではなく、革新的でオーナーシップに基づいた目標を作成します。価値ある実践の目標は、どのステークホルダーにどのような価値を提供し、それをどのように測定するかに焦点を当てるべきです。再利用、コスト削減、リスク回避は企業の安定性に重点を置いています。イノベーションは、新規ビジネス、より高い収益、新規顧客、ミッションの成功、より迅速なサービスに基づきます。オーナーシップに基づく目標は、設計ではなく提供に重点を置いています。各メンバー、またはメンバーチームは、実践からどれだけの成功成果を生み出したでしょうか？
3. エンゲージメントモデルを明確にする。エンゲージメントとは、アーキテクトが業務をどのように捉え、どのようにサービスを提供するかを理解することです。社内のすべてのアーキテクトが関与し、エンゲージメントモデルを承認すれば、あとは、そのモデルを実装して実践することになります。これにより、価値提供における議論や意見の相違、摩擦を減らすことができます。チーフアーキテクトがアプローチを決定するのを待たないで下さい。プロフェッショナルな実践には、暗黙の合意ではなく、参加者の明示的な合意が必要です。あらゆるタイプやレベルのアーキテクトで構成されるエンゲージメント運営委員会を設立する以下のアプローチは、その一助となるでしょう。
コミュニティ・アプローチ
BTABoKでは、医師や建築家など、知識やコンピテンシーをベースとする専門職のモデルを模倣した、厳格な実践モデルを指す言葉としてコミュニティという言葉を使用しています。
実践コミュニティとセンター・オブ・エクセレンス
この組織は、単にコミュニティという言葉だけを使うのではなく、実践的コミュニティ（Community of Practice）、あるいは卓越したセンター（Center of Excellence）と考えるべきです。このようにコミュニティを発展させることで、チーム全体の責任感や目標の共有だけでなく、コミュニケーションや知識の共有の度合いも格段に高くなります。
成果を上げるためのコミュニティの構造化
アーキテクトコミュニティの構築には、a) レポーティング組織と、b) 役割と実践のリーダーシップという 2 つの側面があります。組織への報告や管理体制は、アーキテクトコミュニティが十分な支持と成熟を得るまでは、アーキテクトの手には負えないこともあります。役割、メンタリング、エンゲージメントの定義、その他の成果に基づくリーダーシップに関連する実践は、単純な実践コミュニティに基づいて実施することもできますし、完全なセンター・オブ・エクセレンスにまで拡大することもできます。ただし、このような年功序列制度は経験年数に基づくものではなく、能力と価値ある結果の卓越性のみに基づくものであり、これらは一般的にはまったく異なるものであることに留意する必要があります。例えば、成熟していない組織で長年肩書きを持っているアーキテクトを考えてみましょう。彼らは長年の経験を積んでいるかもしれませんが、コンピテンシーとスキルモデルの重要な側面について、多くの経験を問われることはなかったかもしれません。したがって、これらの個人が、「上級」アーキテクトと「下級」アーキテクトを区別するのは能力のみであることを認識することが重要です。
何年開発者として働いたとしても、ビジネス・テクノロジー戦略のスキルがない場合もあります。このことは、少なくともアーキテクトという職業において、メンタリングや役割分担の指針になります。必要であれば、経験ベースの資格であるIASA CITA-P/Dに合格させることで、このような役割を排除することができます。
専門分野とコミュニティの対立
異なる専門分野間での対立が最もよく起こるため、専門分野の活動や役割については、エンゲージメントモデルの初期段階で対処する必要があります。その違いを理解し、現場にとって対立がなぜ危険なのかを理解するには、医療の専門分野を思い浮かべるのが役に立つかもしれません。外科医と総合診療医、あるいはERに勤務する医師は、世界観が大きく異なることが多いですが、どちらも医師とみなされます。この違いは、ビジネスアーキテクトとソリューションアーキテクトやソフトウェアアーキテクトが効果的に協働できるような、アーキテクチャの実務を設計するのに役立つでしょう。
Question 1：実務には専門家が必要でしょうか？
多くの場合、小規模なプラクティス、ソリューションアーキテクト、エンタープライズアーキテクトには、平均的な企業製品やプロジェクトで成功するのに十分なビジネス、情報、インフラ、ソフトウェア、ソリューションアーキテクチャの知識を持つ、一般的な開業医に相当する人材が必要です。
大規模なチームや非常に複雑な領域では、専門化が存在し、その数も多くなる可能性が高いです。ビジネスモデル、製品の種類、業界へのデジタル浸透度などが、その業務にビジネスアーキテクトが必要かどうかを定義するのに役立ちます。例えば、ソフトウェア製品会社でビジネスアーキテクトが何人必要かは、大手銀行とは全く異なる答えになる可能性が高いです。アーキテクチャチームキャンバスを用いて、現在の業務モデルにスペシャリストが必要なのか、ジェネラリストが必要なのかを判断し、それに応じて採用、トレーニング、指導を行ないます。
Question 2：専門家のアサイン方法
すべての建築家をあらゆる場所に配置することは不可能であるため、割り当ての問題は特に難しいです。この記事では、アーキテクトの割り当てに関する詳細なガイダンスとツールを提供していますが、スペシャリストには特別な注意が必要です。もしインフラアーキテクトがいるのであれば、データセンターの再利用にソフトウェアアーキテクトを使っても意味がありません。専門性に基づいてアーキテクトを説明し割り当てるには、以下を使用してください。
1. 一般的に、ソリューションアーキテクトは、各専門分野にまたがる共有スキルに重点を置きます。ソリューションアーキテクトは、定期的なプロジェクトにアサインされ、製品/プロジェクトの健全性のために、必要に応じてスペシャリストにアサインされます。ソリューションアーキテクトは、ビジネスアーキテクトと協働し、バリューストリームを確実に提供します。
2. 大規模で複雑な領域に特化したプログラムは、その領域において上級なスペシャリストが率いるべきです。 これには 3 つの軸があります。1 つ目は専門性 (能力と経験の主な焦点)、2 つ目はドメイン（領域）の焦点 (医学ではサブスペシャリゼーションと呼ぶもの) です。たとえば、アーキテクトはモバイルおよび Web ベースのソフトウェアに関する深いスキルを持ち、小売ドメインに重点を置くソフトウェアアーキテクトである可能性があります。割り当てで考慮すべき3つ目の軸は、ビジネスと個人に対する価値です。多くのアーキテクトは特定のプロジェクトに情熱を傾けます。このモチベーションは、実践にさらなる品質とメリットをもたらします。
3. 専門スキルの深さから、非アーキテクトにアーキテクチャ業務のリーダーを任せるのは要注意です。アーキテクトは5つのコンピテンシー（行動特性）の柱に基づいていなければなりません。
拡張チーム：メンタリングとリーダーシップ
アーキテクトのコミュニティは、その奉仕者／リーダーとしての能力があってこそ成り立ちます。しばしばソフトスキルとも呼ばれ、習得が最も困難なスキルです。メンタリングとリーダーシップは、アーキテクトのキャリアの早い段階で教え、見直すべき実践的なスキルです。新しいアーキテクトは、適切な指導を受けることで、エンジニアリング、オペレーション、ビジネスなど、他の専門分野から入ってくることが多いです。アーキテクチャコミュニティは、リーダーシップとメンタリング プログラムを開発し、拡張チームを非常によく理解する必要があります。ET の記事では、この分野に関する直接的なガイダンスを提供しています。
人事・雇用への影響
人事調整は時間をかけて達成する必要があります。アーキテクトのキャリアアップのレベルは、主に2つの主な要因、つまり a) 能力と b) 経験のマイルストーンによって決まります。
SFIA+ などのコンピテンシーフレームワークは、多くの組織で従業員の管理に使用されています。しかし、アーキテクチャチームは、人事担当者が職務モデルやキャリアアップに組み込むことができる適応性のある能力モデルを提供する必要があります。コンピテンシーの向上は、卓越性の実証が昇進に必要な職種にとっては特に難しいことです。BTABoKのコンピテンシーは汎用的であるため、多くの技術環境に適応させることができます。BTABoKは、コンピテンシーフレームワークだけでなく、アーキテクトのキャリアを通じて学習し成長するための既定の職務記述書も提供しています。
経験のマイルストーンは、専門職のキャリアを次の段階に上げるための専門知識を提供する専門家協会の認定資格に倣う必要があります。社内の大組織であっても、次のレベルに成長するためには、こうした資格を揃えるのが最善です。
コミュニティ主導型アーキテクチャプログラムの実施
エンゲージメントモデル運営委員会（大規模チーム）
エンゲージメントモデルは、全アーキテクトの横断的な意見によって管理されるべきです。
共通の報告体制がない場合は投票で管理します
これには、顧客またはサービス担当のアーキテクトも含めるべきです
このグループは、アーキテクト組織全体の以下の事柄を定義します
· ビジネスとの連携の方法
· 成功のための自己評価の方法
· アーキテクトの価値と能力を全社的に向上させる方法
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
以上、BTABoKのpeopleモデルの "Community" について日本語化（一部意訳）してみました。とかく、アーキテクトといえば個人のテクニカルスキルにこだわり過ぎ、チームビルディングが疎かになりがちですが、ここではアーキテクト組織の重要性について謳っています。
私個人のユーザ企業時代のアーキテクト経験を顧みても、“いかに大勢のチームメンバー（個別プロジェクトも含む）がアーキテクチャモデルに関する共通の認識を持てるか？”が何よりも重要な成功要因であったかと、思い出します。
また、メンタリングとリーダーシップについては、アーキテクトのキャリアの早い段階で教え実践すべきスキルであると言っている点にも強く共感します。このことはアーキテチャチームが、CoE（Center of Excellence）となるために必要不可欠なのです。つまり単なる“技術オタク”ではエンタープライズアーキテクトは務まらないと暗に言っています。
本書では、企業内のアーキテクチャチームとそれ以外のプロジェクトチーム（ユーザ部門を含む）との間に生じる様々なコンフリクトを仕方ないものと諦めずに、地道に外部を巻き込んでIT部門を越える共通認識を持ったコミュニティを作り上げることを言っています。日本では未だにアーキテクト組織すら立ち上がっていない企業が殆どですが、巨大化、複雑化したシステムを抱える大企業ではこのアーキテクチャーコミュニティの設置はまさに急務です。
国内企業がアーキテクチャー組織を作ったあかつきには、ここに書かれている同様の課題にぶつかるので、ぜひとも参考すると良いのではないかと思います。
この度は、ご一読いただきありがとうございました。
Iasa日本支部では情報交換や勉強会の場を設けており、あるべき企業システムのアーキテクチャについて研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。
Comments