2024年11月7日(木)に開催された「アニュアル・カンファレンス2024」の各講演で使用した資料です。

Iasa日本支部 理事 中山 嘉之氏が自著「DXの大前提―エンタープライズアーキテクチャのセオリー」について解説する会員限定スペシャル動画5回シリーズの第4回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

デジタル変革が企業活動の中心的課題となる中、情報処理推進機構（IPA）が提唱する デジタルスキル標準 をご存じの方も多いでしょう。それには、ビジネスアーキテクトやデータサイエンティスト、デザイナーなど、さまざまな類型のスキルを有する人材が組織の競争力を支える存在として位置付けられています。これらの人材が専門的スキルを発揮しつつ、横断的なチームとして協働することで、企業の技術戦略や業務プロセスを高度化することが求められています。 今回紹介する「 拡張チーム（Extended Team） 」の考え方は、BTABOKピープルモデルの主要な概念であり、デジタルスキル人材の活用にも寄与すると考えます。拡張チームとは、正式なアーキテクチャチームの枠組みを超えて、開発リードやビジネスアナリストなどの役割を巻き込み、組織全体でアーキテクチャ実践を推進する手法です。このモデルは、スキルや知識を持つ個々の人材が、より広い視点で組織の技術的および業務的課題に取り組む場を提供します。 ＊＊＊ 拡張チームとは 拡張チームとは、正式なアーキテクチャチームに限定されず、組織全体のさまざまな役割を活用してアーキテクチャ実践を推進する取り組みです。このモデルは、開発リード、ビジネスアナリスト、プロジェクトマネージャーなど、他部門のメンバーを含め、組織全体の視点で課題解決と戦略実行を目指します。拡張チームは、アーキテクチャチーム以外の人材を含め、組織全体でアーキテクチャ戦略を形成し、実行するための取り組みです。これによって、次の利点が期待できます。 組織全体のカバレッジ向上： 専門チームのリソースを補完し、プロジェクトや能力ポートフォリオの広範囲なサポートを実現。 意思決定の分散化： 各部門やプロジェクトにおける迅速で適切な技術的意思決定を可能に。 自己指向型チームの育成： メンバーが自身の役割を超えて戦略的な視点を持つよう奨励。 拡張チームの重要性と課題 拡張チームモデルの重要性には、特に以下の点があげられます： リソースの不足に対応する柔軟性： 多くの組織ではアーキテクチャチームの規模が小さく、すべてのプロジェクトや活動をカバーするのは難しいのが現状です。拡張チームは、組織内のさまざまな役割を活用することで、リソース不足を補い、プロジェクトや能力ポートフォリオ全体を効果的にサポートします。 分散型意思決定の推進： アーキテクチャに関する意思決定を特定のチームや個人に集中させるのではなく、拡張チームを通じて分散化することで、迅速で適切な意思決定が可能になります。これにより、現場に近い視点を活かした判断が実現します。 統合的なアプローチの促進： 拡張チームモデルを導入することで、組織全体がアーキテクチャ実践に統合的に取り組む姿勢が育まれます。これにより、部門間の連携が強化され、デジタル変革の実現に向けた一致団結したアプローチが可能となります。 戦略的価値の最大化： 拡張チームにより、戦略的なアーキテクチャ能力を広範囲に展開し、技術投資や業務プロセス改革の優先順位付けを全社的な視点で最適化することができます。 拡張チームは、プロジェクトや能力ポートフォリオ全体をカバーするのに十分な数のアーキテクトがいないため、多くの組織で形成されます。特にアーキテクチャ成熟モデルの初期段階では、多くの組織が拡張チームモデルを採用しています。それにより、拡張チームとして課題を抱える可能性もあります。例えば、これらの組織では開発リードやアジャイルチームがプロジェクトのための技術投資を決定することがよくあります。局所的に最適化された成果物が生まれ、組織内で他の投資と重複したり、さらには同じような取り組みが繰り返されることもあります。その結果、膨大な作業の重複、複雑すぎるシステム、そして不適切な投資決定が発生することがあります。さらに、ほとんどの開発チームは、組織にとって何が最適かを正確に判断するためのビジネススキルに欠けています。他の拡張チームの役割も同様の課題に直面しています。例えば、PMO（プロジェクト管理オフィス）は、技術的な深みが乏しい個人によって決定されたビジネス目標に基づいてプロジェクトを優先する傾向があり、その結果、多くの重要な要素がロードマップから外されてしまうことがあります。 したがって、拡張チームモデルを成功させるには、組織がかなり高い成熟度に達していることが必要です。例えば、以下のような観点での成熟度が求められるでしょう。 分散型意思決定の観点： 意思決定をエンタープライズの末端に近づけることで、市場変化への迅速な対応や顧客ニーズへの適合が可能になります。ただし、従来のエンタープライズレベルでの説明責任や最適化が犠牲になるリスクもあります。拡張チームでは、パートナーがトレーニングや指導を通じてアーキテクチャスキルを習得し、迅速な対応と全社的な最適化を両立させる仕組みが求められます。 カバレッジとエンタープライズの観点： すべての重要な投資について情報に基づいた価値ある意思決定を行う能力が必要です。エンゲージメントモデルでは、意思決定プロセスを追跡可能にし、アーキテクチャ的な判断を組み込むことが目標となります。 ジャスト・イン・タイム・アーキテクチャの観点： 意思決定を可能な限り遅らせ、客観的証拠に基づいた選択を行う実践です。これにより迅速なシステム提供が可能になりますが、大規模なプロジェクトでは慎重な管理が必要です。経験豊富なアーキテクトをフルタイムで配属することが成功の鍵となります。 パートナーロールのエンパワーメントの観点： 成熟したアーキテクチャプログラムでは、他の役割を支援し、競争関係を排除します。このアプローチは、デジタル戦略やデリバリーへの集中を補完し、エンタープライズ全体の価値管理やイノベーションを強化します。 拡張チームへのアプローチ 拡張チームを構築する第一歩は、アーキテクト自身の実践者から始まります。そしてその一歩を拡張チームにつなげるためのアプローチを紹介します。 信頼性の構築： 拡張チームをチームの一部として扱い、組織内で信頼性と合意を構築する必要があります。信頼性が欠ける場合、隠れた敵意や対立が生じる可能性があります。リーダーを特定し、適切にトレーニングや指導を行うことが重要です。 構築し、所有し、統治しない： アーキテクチャは創造的な機能であり、監督プロセスではありません。拡張チームはイノベーションとデリバリーに集中し、ガバナンスやレビューの役割を最小限に抑えるべきです。 「Yes」を基盤とした文化の構築： 組織に対して「No」と言う場面を減らし、「Yes」と言える分野に焦点を当てることが重要です。信頼性と価値が認識されれば、投資と優先順位のバランスを取ることが可能になります。 アジャイルチームとの協働とデリバリー中のアーキテクトの役割： アジャイルとアーキテクチャは相互補完的であり、アーキテクトがチームに深く関与することで、デリバリーと価値創出の最適化が可能になります。価値あるアジャイルアーキテクチャ実践の条件とは以下のようなことです。 　- チームがアーキテクチャの価値を理解していること。 　- アーキテクトがデリバリーに深く関与していること。 　- アジャイルリーダーがアーキテクチャスキルを習得していること。 　- アーキテクトのプロジェクトや製品への明確な割り当て。 　- 強力な指導やパートナーシップモデルの存在。 　- エンゲージメントモデルの適切な成熟度。 拡張の原則： アーキテクチャは他の役割の上にあるのではなく、異なる機能を持つものです。エンゲージメントモデルでは、十分なスキルを持つ他の役割が責任をカバーする必要があります。 ＊＊＊ まとめ 拡張チームは、限られたリソースを補完しつつ、より多くの人材を巻き込み、戦略的なアーキテクチャ実践を実現します。組織がこのモデルを効果的に採用することで、技術革新と業務プロセスの高度化が促進されるでしょう。Iasa日本支部は、アーキテクト人材のスキル啓蒙やコミュニティ活動の拡大に積極的に取り組んでいます。このような活動を通じて、拡張チームモデルを導入する組織への具体的なサポートにも貢献できればと思います。このようにIasa日本支部の活動が、アーキテクト人材の育成とデジタル変革の加速に大きく寄与することをご期待ください。

さる11月7日、品川シーズンテラス・カンファレンスにて、「デジタル時代の融合アーキテクチャ」〜　ビジネス、データ、テクノロジーが創る未来　〜」と題し、Iasa日本支部のアニュアル・カンファレンスが開催されました。各界から有識者による４つの講演に、オンライン・オフラインとも多数ご参加された今年のイベントの様子をお伝えします。 講演 1. AI・DX時代の価値実現必須スキルとしてのビジネスアーキテクチャ IIBA日本支部理事、KITネットワークス株式会社代表取締役 藤重 茂 様 株式会社クリエビジョン　代表取締役 塩田 宏治 様 最初の講演はビジネスアーキテクチャがテーマ。前半は塩田様、後半は藤重様のお二人でのご講演でした。AIの進化に伴い、ビジネスアーキテクチャが今後ますます重要になる、というのが塩田様のメッセージです。 クラウドやAIの進展によって、エンタープライズ・アーキテクチャにおいても、プロジェクト・ライフサイクルにおいても、クリティカルパスはビジネスアーキテクチャへシフトしていきます。 つまり「AIが高度化するほど、コンテキストとしてのアーキテクチャが重要になる」と塩田様。まさにおっしゃる通り。AIで代替できない役割、それがビジネスアーキテクトですね。 続く藤重様のご講演は、ビジネスアーキテクチャの様々なドメインから、今回はケイパビリティとバリューストリームにフォーカスします。プロセスを実行するためには、それに対応するケイパビリティが不可欠です。ケイパビリティのオーケストレーションが、ビジネスの成功を左右する鍵となります。 ケイパビリティは中々日本語にしにくい概念ですが、最近ではジョブ型雇用も普及が進んでいることですし、そういうところからでも今後日本のビジネス社会のなかでも一般化が進んで行くと良いなあ、とこれは個人的な期待。 講演 2.　 データマネジメント視点によるアーキテクチャ考察 DAMA日本支部 理事、KPMGコンサルティング リードスペシャリスト 吉村 泰生 様 ビジネスに続いて次はデータがテーマです。データマネジメントの観点から、アーキテクチャ設計の重要性を吉村様に語っていただきます。 データは企業の重要な資産ですね。資産ですから価値があります。それを左右するのはその構造と意味、というところまではどなたもお分かりですが、問題はそれをどうやって行動に繋げるかですね。 そのような課題の解決に活用できるのがDMBOK。コンテンツはDAMAのホームページからダウンロードでき、引用を明記すれば商用利用も可、とのことなので、どんどん広めて活用をお勧めしたいと思います。 同音異義とか異音同義なんてどこでもお困りの方は多いでしょう。そこでデータモデルを描いてみることで、データの「構造と意味」を明らかにすることで「データで稼ぐ」ことが比喩ではなく現実に可能になるわけですね。AIのビジネス活用などでも正にそう。この辺りは先の塩田様のクリティカルパスにも通じるところがあります。 講演は吉村様の「データの名称と意味の定義に敏感であること」というメッセージで締めくくられます。私もおもわす「そうだ、そうなんだ！」とこぶしを握り締めてしまいました。 講演 3.　　　デジタルアドバンテージを強化するクラウドネイティブ技術とAIの融合 フェンリル株式会社 シニアクラウドコンサルタント 　　日置 幸宏　様 3番目はアプリケーションを取り上げます。クラウド技術、生成AIといった技術トレンドから、そのような昨今の状況におけるITアーキテクトの立ち位置、そしてその実行に求められるスキルセット (ケイパビリティと呼んでも良いかもしれませんね)と、日置様の博覧強記に裏打ちされた行動力には敬服することしきりです。 RAG (検索拡張生成) は吉村様も取り上げられていましたが、ガートナーによるともうハイプサイクルの頂点だそうで、世の中早く変わり過ぎですね。個人的にはArchiMateでグラフRAGやりたいなあ、なんて思ってましたが、やらないうちにRAGが死語になってしまうかも。でもグラフデータが無くなることはないし、もっとすごい技術がすぐにやって来るのでしょう。それもより安価で。 モノゴトの表層ではなくファクトに基づいて、本質を理解することこそが価値に繋がる。この「ファクトを知りたい・本質を理解ししたい」という内発的要求が大事なんですね。なんといってもここだけはAIでは代替出来ません。 個人的に一番刺さったのは、最後に照会された「新技術の情報収集を止めた途端に老害化が始まる」というモヒカンSlackからのメッセージでした。日置様のおっしゃる通り、いつまでも「変化を楽しむ」心を忘れないようにしたいものです。 講演 4. データドリブン経営の観点から見たイベントドリブンアーキテクチャの可能性 Solace Corporation カントリーマネージャー 山口 智之 様 最後の講演はテクノロジーがテーマ、イベントドリブンアーキテクチャを実現するソリューションのご紹介です。 お話を伺うにつれ、自分の考えはなんと呑気なんだろう、と何だか恥ずかしくなってきました。新入社員のエンロールメントに1日2日掛かる、それって意味有るのか？と言われても、「え、ダメなの？」と思ってしまう自分が居るわけです。 日本で失われた30年と呼ばれている年月に、欧米のビジネスは無形の資産からどう価値を生み出すかにこれほど真剣だったのか、と思い知らされますね。無形の資産とは「データ」だけじゃない。もうひとつ「時間」もそうだ、ということに気づかされました。 イベントはIasa日本支部の松井代表理事のご挨拶で締めくくられました。イベントのテーマである「ビジネス、データ、テクノロジーが創る未来」は、アーキテクチャを通じた融合によって実現する未来ですね。ビューポイントの違いは色々あれど、「よりよい未来」という思いは共通。なんといっても「アーキテクチャ」は「何らかの意思を以て作られた人工物の内部構造」ですからね。Iasa日本支部が、そんなアーキテクトが流派を超えて交流出来る場になれるよう、精進を続けていきたいと思います。

Iasa日本支部 理事 中山 嘉之氏が自著「DXの大前提―エンタープライズアーキテクチャのセオリー」について解説する会員限定スペシャル動画5回シリーズの第3回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

Iasa日本支部 理事 中山 嘉之氏が自著「DXの大前提―エンタープライズアーキテクチャのセオリー」について解説する会員限定スペシャル動画5回シリーズの第2回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

Iasa日本支部 理事 中山 嘉之氏が自著「DXの大前提―エンタープライズアーキテクチャのセオリー」について解説する会員限定スペシャル動画5回シリーズの第1回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

デジタルトランスフォーメーション（DX）が企業の競争力を左右する要因として定着して久しい中、私たちはさらなる変革の波を迎えています。AIの急速な進化、サイバー攻撃の脅威の多様化、そして持続可能な社会を実現するためのデジタルイノベーション。これらの動向は、ITアーキテクトに対して新たな課題と機会をもたらしています。   とりわけ、生成AIの普及により、業務の自動化やデータ解析の高度化が現実となりつつある今、ITアーキテクトはその変化をリードする存在として、組織全体のビジョンをデザインし、実現する責任を担っています。 また、デジタル・グリーン・トランスフォーメーション（GX）という新たな視点から、サステナビリティと成長の両立を図るデジタル戦略が求められており、これまで以上に多岐にわたる技術とビジネスの融合が必要とされています。   同時に、ビジネスを取り巻くリスクは複雑化・高度化しており、サイバーセキュリティの確保は企業活動の基盤としてますます重要になっています。ITアーキテクトは、これらの課題に対して、全社的な視点から最適なソリューションを設計し、実装することで、組織の持続的な成長を支える鍵となります。   本年度のカンファレンスでは、これらの最新トレンドを踏まえ、ITアーキテクトが果たすべき役割とその影響力を深く掘り下げていきます。業界のリーダーたちが集結し、最前線の知見と実践事例を共有するこの場で、未来を創造するためのヒントを得ていただければ幸いです。 カンファレンスの詳細については後日お知らせいたしますが、2024年11月7日（木）に会場での対面参加とZoomでのオンライン参加のハイブリッド形式で開催致します。 IASA日本支部設立から10周年となり懇親の場を用意する予定です。アーキテクトのコミュニティとしての10年間を振り返り、今後の展望を皆様と語り合える機会になれば幸いです。是非ともご参加いただくことを望んでおります。よろしくお願いいたします。   　　　　　　 ２０２４年度　アニュアル・カンファレンス　開催概要 開催日時： 2024年11/7(木) 　講演：13:00 ～ 17:00 　　Solace社、フェンリル株式会社、DAMA日本支部、IIBA日本支部 　　などからの講師陣を予定 　懇親会：17:00 ～ 19:00 　　会員は無料、非会員は2,000円（当日の会員登録も可能） 会場： 品川シーズンテラスカンファレンスB(東京・品川)

今回のコラムは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日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

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日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

今回のコラムはBTABoKのオペレーティングモデルの " Requirements " について取り上げます。 企業の持続的な成功と競争力の維持には、適切なアーキテクチャ上重要な要求（Architecturally Significant Requirements 以下ASRと略）の識別・管理が鍵となります。 本コラムでは、ASRの概念や識別方法・管理方法について解説させていただきます。 「要求」の大部分は、価値のために必要なものではない。それらは実際には、一人のシステム・ユーザーの好みに関するものなのだ。より良いシステムのために、ユーザーの嗜好よりも価値のマネジメントを今すぐ学び始めよう。【Paul Preiss】 IasaのCEO兼創設者であるPaul Preissが指摘するように、すべての要求が直接的な価値を持つわけではありません。つまり、個々のユーザーの好みを超えて、組織の成長と成功に寄与する要求が価値のために真に必要な要求と言えるでしょう。 では、アーキテクチャ上重要な要求（ASR）とは何なのでしょうか。 ASRはBTABoKで使用されている用語で「組織に対する価値の開発と提供に関連する一連の概念」とされています。少し抽象的なので言い換えると「組織全体の戦略的目標を支え、より大きなビジネス価値を生み出すために欠かせないアーキテクチャに関連する要求」ということです。 アーキテクチャに関連する要求は アーキテクチャ開発ライフサイクル(ADLC) の初期に収集する必要があるため決定することが困難です。組織はプロジェクトが進行するにつれて、初期の要求にさらに詳細な要求を加え、継続的に改善していく必要があります。要求に関するすべての決定が価値を持ち、追跡可能であることがASR管理の大きな目標とされています。 続いて、アーキテクチャ開発ライフサイクル(ADLC)の中でASRはどのように洗練されていくのか見ていきましょう。 イノベーション／アイデア 新しいアイデアや概念がASRとして提案され、ビジネスケースの形成に向けて展開されます。 ビジネスケース プロジェクトの費用と価値創出の可能性が評価され、ASRがより具体的な形で明確化されます。 エピック／ソリューションストーリー 詳細なプロジェクト要件としてのASRが整理され、アジャイルやリーンの手法を通じて実際のプロジェクト計画に統合されます。 詳細要求事項 このレベルのASRでアーキテクチャに関連すると考えられるものは少ないですが、アーキテクチャへの影響を確実に特定するために、アーキテクトが継続的にレビューする必要があります。 この際、アーキテクトは適切なアーキテクチャ要求を決定する必要がありますが、 「適切な」要求とは一体何でしょうか？ アーキテクチャに関連する要求が「適切」とされるのは、以下の要素を持つ場合とされています。 製品やフレームワークに深く影響を与える要求 管理された品質属性に影響を与える要求 組織の能力やロードマップに影響を与える要求 政治的要素や経営層の支持を受けた要求 革新的なビジネスモデルやアプローチを示唆する要求 ここまでASRの識別に関して綴ってきましたが、 ASRは識別して終わりではなく、適切な管理が必要です。 その理由は、適切な管理を通じてのみ、ASRが設計の意図した通りに機能し、システムの性能、安全性、拡張性などの基本的な品質要件を維持し続けることが可能となるからです。 よってASRが戦略的な目標に対して最大の価値を提供するためには、 ASRが以下の基準を満たしているか確認する価値のトレーサビリティが必要となります。 完全性 要件が完全に記録され、情報の漏れがないこと 追跡可能性 要件が利害関係者のニーズを満たすとともに、適切に文書化されていること 現行性 要件が常に最新の状態に保たれ、時代遅れになっていないこと 検証可能性 要件を実施した結果が、検査、デモンストレーション、テスト、分析を通じて客観的に評価されること 有用性 要件が実装されることで、測定可能な価値を組織に提供し、その効果が定量的に示されること これらの基準を確認することで価値のトレーサビリティが可能となり、組織の競争力を維持するための基盤を強化します。 今回はオペレーティングモデルの "Requirements" について紹介させていただきました。 アーキテクチャ上重要な要求（ASR）は企業の戦略的目標達成に不可欠な要素です。 ASRを適切に識別・管理することで、企業の技術的な挑戦に寄与し、持続可能な競争力を維持することができます。ASRの識別と管理には、ビジネスと技術のリーダーシップを連携させることが不可欠であり、アーキテクトはその橋渡しとして重要な役割を果たすのです。 ご一読いただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

今回のコラムはBTABokのコンピテンシーモデルの「Views and Viewpoints」について取り上げます。「コンピテンシー」とは高いパフォーマンスを発揮する人物に共通して見られる「行動特性」を表す言葉で、BTABokのコンピテンシーモデルはその行動特性をモデル化したものになります。ITアーキテクトには幅広い知識とそれを実践する行動力が求められます。そのアーキテクトの「行動特性」を学ぶことでITアーキテクトに必要な知識や行動を理解することができるでしょう。ここではコンピテンシーモデルの中の「Views and Viewpoints」についてみていきます。 基本的にソフトウェアはその構造を物理的に視認することができません。このため構造をステークホルダーに説明するために可視化する必要があり、その可視化によってステークホルダーにソフトウェアがどのような構造をとっているかを理解してもらうためにもわかりやすい可視化のアプローチが求められます。「Views and Viewpoints」は、直訳すると「見解と視点」ですがviewsとviewpointsの原則は異なる場所で若干異なる方法で定義されます。IASA によって採用された定義は次のとおりです。 viewsは、アーキテクチャの 1 つ以上の側面を表現したもので、 1 つ以上の利害関係者が抱く懸念にアーキテクチャがどのように対処するかを示します。 viewpointsは、1 つのタイプのビューを構築するためのパターン、テンプレート、および規則のコレクションです。 それは、その見解を構築するための視点、ガイドライン、原則、およびテンプレート モデルに懸念を反映する利害関係者を定義します。 例えば、ITオペレーションズチーム向けにビューを作成する際には、オペレーションズビューポイントを使用します。このビューポイントは、システムの運用に関する情報が含まれるテンプレートです。オペレーションズビューポイントを使用することでシステムの運用に関係する人々に提供されるビューを作成することができます。 ITアーキテクトは、views、viewpointsの概念を明確に理解し、それらの違いとアーキテクチャを記述する際の連携方法を理解する必要があります。そしてIT開発プロジェクトで典型的なステークホルダーグループを識別し、各グループの典型的な関心事を理解し、特定のプロジェクトの要件を満たすために必要なviewのセットを決定する能力を持っていなければなりません。 「Views and Viewpoints」ではアーキテクトの主要な責任の1つは、関心を持つステークホルダーにシステムのビジョンを提示することと示されています。最も単純なシステム以外では、1枚の図で効果的にこれを示すことは不可能であり、したがってviewsとviewpointsの概念が開発されました。多くのアーキテクチャ記述法は、主要なアーキテクチャ情報を含む一連のviewsとして構成されています。多くのアーキテクチャフレームワークでは、システムの機能構造、主要なデータ構造、ソフトウェア開発方法、およびソフトウェアのデプロイ方法に関するviewpointsが含まれます。 viewpointベースのアーキテクチャフレームワークに多数のフレームワークが存在し、その中にはソフトウェア集中システム向けのものもあります。例えば、Kruchtenの4＋1アーキテクチャビューモデルやV&Bアプローチ、Software Systems Architectureセットなどがあります。 図. 4+1 architectural view model 出典：Wikipedia 以上の図はKruchtenの4+1アーキテクチャビューモデルですが、それぞれのモデルには以下のような関係性があります。 論理ビュー：論理ビューは、システムがエンドユーザーに提供する機能に関係します。論理ビューを表すために使用される UML 図には、 クラス図、 通信図、 シーケンス図などがあります。 開発ビュー：開発ビューはプログラマの観点からシステムを示し、ソフトウェア管理に関係します。このビューは実装ビューとも呼ばれます。 UML コンポーネント図を使用して システム コンポーネントを記述します。開発ビューを表すために使用される UML 図には、パッケージ図が含まれます。 プロセス ビュー：プロセス ビューはシステムの動的側面を扱い、システム プロセスとその通信方法を説明し、システムの実行時の動作に焦点を当てます。プロセス ビューは、同時実行性、分散、インテグレータ、パフォーマンス、スケーラビリティなどに対応します。プロセス ビューを表す UML 図には、 アクティビティ図が含まれます。 物理ビュー：物理ビューは、システム エンジニアの視点からシステムを表します。これは、物理層上のソフトウェア コンポーネントのトポロジと、これらのコンポーネント間の物理接続に関係します。このビューは、展開ビューとも呼ばれます。物理ビューを表すために使用される UML 図には、 配置図が含まれます。 シナリオ：アーキテクチャの説明は、小さな一連の ユースケース、つまり 5 番目のビューとなるシナリオを使用して説明されます。シナリオは、オブジェクト間およびプロセス間の一連の対話を記述します。これらは、アーキテクチャ要素を特定し、アーキテクチャ設計を図示して検証するために使用されます。これらは、アーキテクチャ プロトタイプのテストの開始点としても機能します。このビューは 、ユース ケース ビューとも呼ばれます。 そのほかにもアーキテクチャを具現化、視覚化する「Views and Viewpoints」の解説がIASA GlobalのWebサイトに載っておりますので、原文を参照してみてください。 ITアーキテクトに限らずですが、システムを開発する、運用する、保守する、プロジェクトを推進する等の様々な場面でシステムを可視化した資料は重要になります。システムの視覚化は1つの観点だけでは十分ではなく、さまざまな場面やステークホルダーによっても使い分ける必要があり、あくまでそれを見る人が中心でなければなりません。このため「Views and Viewpoints」では様々な手法や視点を取り上げつつ、それらを組み合わせ、使い分けすることが必要だとしています。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！