検索結果

明けましておめでとうございます。本年もIasa日本支部をよろしくお願いいたします。さて今回はBTABoKのオペレーティングモデル内にある "Legacy Modernization" を紹介します。 現代のビジネス環境では、技術の進化が急速に進んでおり、企業はその変化に迅速に対応する必要があります。しかし、多くの企業は依然として古いシステム（レガシーシステム）に依存しており、これがビジネスの柔軟性や効率性に制約を与えることがあります。 本コラムでは、レガシーモダナイゼーションの重要性とそのアプローチについて詳しく解説します。企業がどのようにして古いシステムを最新の効率的なソリューションに変えることができるかを探り、具体的な戦略や実施時期、アプリケーションポートフォリオ管理の手法について触れます。これにより、企業が競争力を維持し続けるための実践的な方法を提供します。 レガシーモダナイゼーションとは すべてのシステムにはライフサイクルがあり、システムの構築と開始から始まり、システムの保守を経て、最終的にはライフサイクルの終わりに廃止されます。ライフサイクルの間、システムは組織やその顧客に価値を提供し、その価値提供を維持し、さらに多くの価値を生み出すことが望まれます。システムが適切に保守されていても、周囲の世界は常に変化しています。例えば、新しい技術の発見、法律や規制の変更、ビジネスの進め方の変化などです。 システムの寿命を延ばすために、持続可能性を確保しながら適切な変更を行う必要があります。持続可能性とは、「システムが提供する価値が、財務的なコストや労力に対して大幅に上回ること」と定義できます。 モダナイゼーションは、システムが「目的に適合」し、価値提供とコストのバランスを維持するためにシステムを変更するプロセスです。 レガシーとは、古い技術を使用している既存のシステムや、組織の業務に合わなくなった機能を指します。システムが依然として重要な価値を提供している場合でも、効率的でないことがあります。レガシーモダナイゼーションは、レガシーシステムに変更を加えて、組織にとってより最新で効率的なソリューションを提供するプロセスです。 なぜレガシーモダナイゼーションが必要なのか 高いレベルのアジリティ（機敏性）を持つ組織は、競争上の大きな優位性を持ち、周囲の環境に迅速に対応し、変化することができます。高いレベルのアジリティを達成するためには、組織を支えるシステムも周囲の環境に迅速に対応し、変化する必要があります。レガシーシステムは、変更が難しいことやビジネス活動を効率的にサポートできないことが多いため、アジリティに制約を与えます。システム設計時には存在していた技術的制約が現在は存在しない場合や、もはや関連性のない特定の業務手順のために設計されたシステムということもよくあります。 レガシーモダナイゼーションは、レガシーシステムを変更または置き換えることで、組織をより効率的かつコスト効果の高いものにします。これにより、既存のビジネスプロセスを最適化するだけでなく、新しいビジネスチャンスを開くこともできます。 またセキュリティは、レガシーモダナイゼーションの重要な推進要因です。サイバー攻撃は一般的であり、時間とともに高度化しています。システムのセキュリティは時間とともに低下し、レガシーシステムは現代の攻撃手法を防ぐために必要なサポートや技術を持たないことが多く、ハッカーにとって容易な標的となります。これは組織にとって重大なビジネスリスクを意味します。 レガシーシステムが古くなると、技術的な制約によりパフォーマンスに制約が生じることがよくあります。これにより、システムの処理時間や容量が制限され、組織の価値提供能力に影響を与えます。レガシーモダナイゼーションは、容量を増やしたり、他の非機能的特性（高可用性、回復力など）を改善したりする方法を提供することができます。 レガシーモダナイゼーションのアプローチ １．持続可能性の促進 持続可能性は、システムの寿命を延ばすための重要な品質属性です。アーキテクチャが持続可能であることを保証することは、現在の期待に応えつつ、将来の期待を損なわないことを意味します。これは簡単ではありませんが、適切な技術選択を行うことが重要です。例えば、新しい興味深い機能を持つ最先端技術を選択することは短期的な利点をもたらすかもしれませんが、数年後にサポートがなくなると持続可能性を損なう可能性があります。 ２．価値を見極め、過去の投資に拘らない  システムや技術の価値は、組織がビジネス価値を効果的に提供するのをどれだけサポートするかということです。一部の組織は、システムの開発と保守に多額の投資を行っています（「サンクコスト」とも呼ばれます）。システムがもはや価値提供を効果的にサポートしなくなると、システムに投資された金額のために廃止や移行に対する抵抗が生じることがあります。これは政治的な動機であり、組織内の特定の利害関係者にとってデリケートな問題となることがあります。しかし、システムが期待される価値を提供しなくなった場合、それは過去の投資に関係なく、ビジネスにとって重荷であり、コストでしかありません。 ３．変化を受け入れる  モダナイゼーションは技術やシステムだけでなく、組織内の人々がこれらのシステムに基づいたスキルやプロセスで働いていることも含まれます。これらの人々がモダナイゼーションの計画に参加し、スキルを更新し、新しい方法を学び、新しいプロセスや技術を形成することが重要です。これにより、最新の技術や新しいシステムへの移行が容易になります。これがうまく処理されない場合、人々が排除されたと感じ、抵抗が生じる可能性があります。さらに、モダナイゼーションは既存のプロセスを真に再考する機会を提供します（既存の[レガシー]技術によって制約されることが多い）。既存のソリューションの制約から解放されると、顧客にとってより速く、安価で、効果的な方法や、他の改善を提供する方法が見つけることができるもしれません。 システムがモダナイゼーションを必要とする時期 モダナイゼーションの計画において重要なのは、システムがレガシーと呼ばれる限界に達していることを認識することです。これをできるだけ早く認識することで、リスクを軽減し、行動を起こすための時間を確保できます。以下は、システムがレガシー状態に達し、モダナイゼーションが必要になる可能性が高いことを示すいくつかの指標です。 １．技術サポート  最も簡単に見分けられる属性の1つは、使用されている技術のサポートが終了されていることです。ほとんどの主要な技術には、サポートのロードマップがあり、サポートが終了される予定日があります。これは、技術の特定のバージョンに適用される場合もあれば、技術そのものの完全な終了になる場合もあります。例えば、オペレーティングシステム、データベース、開発プラットフォームのサポートです。技術プラットフォームを選択する際には、この側面を考慮することが重要です。サポートがすぐに失われるプラットフォームを選択すると、モダナイゼーションの必要性が近い将来に発生します。また、市場の技術を常にチェックし、潜在的なモダナイゼーションを適時に計画することも重要です。 ２．スキルの調達  システムをさらに開発または保守するために必要な適切なスキルを持つ人々を見つけるのが難しい場合、これはレガシー技術の指標となることがあります。これは単に、必要なスキルを持つ人々が市場に少なくなっていることを意味し、これによりこれらの人々を雇うコストが非常に高くなります。 技術が古くなると、エンジニアコミュニティは新しい、よりエキサイティングな技術を好み、古い技術のスキル市場は縮小し始めます。多くの企業がこれらの古い技術を使用して重要なコアビジネスシステムを運用しているため、これらの古い技術に対する需要が依然として高いことがよくあります。例えば、多くの組織がコアビジネスサポートの一環としてCOBOLベースのシステムを運用しています。市場が縮小し、限られたリソースに対する需要が続くと、採用やコンサルティングのコストが増加します。組織が使用する技術に対して健全なスキルベースがあることを確認するために市場を監視することは大切です。利用可能性の問題がある場合やコストが大幅に上昇している場合は、モダナイゼーションを計画します。 ３．セキュリティ  古くなるシステムは、年を重ねるごとにセキュリティを確保するのが難しくなります。上記のように、ハードウェア、オペレーティングシステム、アプリケーションのベンダーからのサポートが終了され、セキュリティアップデートやパッチが提供されなくなります。さらに、スキルに関するポイントに関連して、スタッフがシステムを管理し、セキュリティを確保することができなくなると、システムは未知で管理不能な状態に陥る可能性があります。セキュリティリスクレベルを監視し、組織のリスク許容度に沿って緩和策や管理策を講じることができなくなる前に、システムをモダナイゼーションの計画に組み込む必要があります。 ４．業務上の負担 競争力を維持するためには、一定のレベルの価値提供を維持する必要があります。市場は静的ではないため、競合他社は常に価値レベルを引き上げており、組織は市場に適応する必要があります。これには、ビジネスの進め方を変更することが含まれる場合があります。組織内のシステムは、価値提供をサポートし、促進します。システムの寿命がくる前に、組織の業務手続きが変わることがありますが、以前の業務手続きのために設計されたシステムはそのまま残ります。これにより、競争力のある価値提供を確保するために、ビジネスサイドで多大な努力が必要になることがあります。例えば、システムを業務慣行に合わせるためにルーチンや回避策が実行されたり、特定の作業活動が異なる技術でつなぎ合わされたり、手動で計算やレポートをEXCELで実行するなどです。 これは、本来ビジネス価値を生み出す活動に向けられるべき努力を必要とします。ユーザビリティ調査、要件の収集、または定期的なフォーラムを通じて情報を収集することで、業務で負担すべき内容を特定し、システムが組織のプロセスとどれだけ一致しているかを示すことができます。システムがビジネスのニーズと一致していない場合、モダナイゼーションを計画してシステムをビジネスに再調整することを検討しなければなりません。 ５．変化に対応する能力  組織とそのビジネスは時間とともに変化するため、組織内のシステムも変化し、効率的なビジネスサポートを提供する必要があります。システムの変更にかかるコストと時間は、組織にとって重要です。組織のシステムは、ビジネスと同じくらい迅速に変化に適応する必要があります。システムの変更が遅くなったり、コストがかかるようになったりすると、システムがモダナイゼーションの候補であることを示す指標となります。これは、システムのコスト（OPEXおよびCAPEXの両方）を監視することで特定できます。変更の仕様から変更の提供までの時間も監視できます。時には、システムに重いリリースサイクルを強いる制約がある場合があります。例えば、システムは年に1回または2回しかリリースを提供できません。これにより、ビジネスが変化に対応する能力が制限されます。 ６．ボトルネック  システムの全景には多くの現代的なシステムが含まれることがありますが、単一のレガシーシステムが価値の流れやビジネスプロセスにボトルネックを作り出すことがあります。作業の流れの中で、上流のレガシーシステムの存在は、下流のモダナイズされたシステムの利点を妨げるか、減少させる可能性があります。作業と努力がボトルネックに集中し、サポートと性能が優れた他のシステムが利用されなくなります。現代のシステムがその完全な性能で使用されていないことに気付くことは、上流にレガシーの問題があることを示す指標となるかもしれません。これらのボトルネックを特定することは非常に重要です。ボトルネックは、下流のシステムがその完全な潜在能力を実現するのを妨げます。 ７．許容量の制限  技術は急速に変化し、処理能力やストレージの容量に関して技術の許容量は絶えず進化しています。古い技術には、特定のプラットフォームやハードウェア向けに設計されているため、制限がある場合があります。これは、管理できるデータの量や、組織がイベントに対応する速度（例えば、販売注文や販売データの分析）に関して、組織に制限をもたらします。組織が情報をタイムリーに利用できない場合や、作業項目が遅れて処理されている場合、これはレガシーシステムの指標となることがあります。 アプリケーションポートフォリオ管理 アプリケーションポートフォリオ管理の手法は、アプリケーションの状況を監視し、コストと価値を評価するために使用できます。アプリケーションの運用費用（OPEX）と資本支出（CAPEX）を監視することで、アプリケーションの運用コスト（OPEX）と開発などの投資（CAPEX）を比較することができます。コストが価値に見合うかどうかを評価するために、一連の指標を使用して各システムを評価できます。アプリケーションを評価するために使用できる典型的な指標は次のとおりです： 使いやすさ 将来性のある技術 サポートの可用性 スキルの可用性 ユーザー数 ビジネスの重要性 これらの指標で低い評価を受けると、アプリケーションやシステムが寿命に近づいていることを示すことがあります。この情報を使用して、アプリケーションのモダナイゼーションや廃止の計画を立てることができます。レガシーモダナイゼーションの戦略的な監視と計画に使用できる方法の1つが、TIMEモデル（Gartner）です。 TIMEモデルは、ポートフォリオ内のアプリケーションを示し、それらがサポートするビジネス能力に配置します。アプリケーションは次のように分類されます： Tolerate（許容） ：アプリケーションが価値を提供しており、移行や置き換えのコストが高すぎるため許容されるが、投資は正当化されない。これらのアプリケーションは、再設計によるモダナイゼーションの対象となる場合があります。 Invest（投資） ：アプリケーションが高い価値を提供しており、投資の対象となる。 Migrate（移行） ：アプリケーションの機能が価値を提供しているが、もはや効果的でない場合、機能やデータを最新のプラットフォームに移行することでモダナイゼーションを実現できる。 Eliminate（廃止） ：アプリケーションがもはや価値を提供しておらず、廃止される。アプリケーションは完全に別のアプリケーションに置き換えられる場合があります。 以下の図は、Tinkelman Coffee Shopに基づくTIMEモデルの例を示しています。 上記の例では、いくつかのアプリケーションがTinkelmanのビジネスをサポートしています。同じアプリケーションが複数の機能をサポートすることがあることに注意してください。これは、ある機能でアプリケーションを移行または廃止しても、別の機能でアプリケーションに投資を続けることができることを意味します。 COFI-BIZは、いくつかの機能で広く使用されているビジネスシステムです。しかし、COFI-BIZの物流モジュールはもはやサポートされておらず、物流システムLOGI-GOに移行されます。いくつかのコーヒーショップでは、古い会計システムA-COUNTがまだ使用されています。これはCOFI-BIZに移行されます。POS 80の販売時点管理システムは社内で開発されましたが、システムを維持するスキルがもはや利用できないため、SALE-POINTシステムに置き換えられます。ROBO-PACKおよびAD-DESIGNシステムは許容されており、移行や置き換えの投資には値しませんが、ROBO-PACKは一部のモジュールを再設計することでモダナイゼーションが可能です。 TIMEモデルは、アプリケーションポートフォリオを評価し、レガシーモダナイゼーションのための取り組みを計画するために使用できます。このモデルは、ポートフォリオの視覚的なステータスを提供し、レガシーシステムが効果的に管理されることを保証します。 レガシーモダナイゼーションの戦略 【リ・エンジニアリング】  レガシーシステムのリ・エンジニアリングは、システムの大部分を再設計または変更する大規模な技術的改修を伴うことが多いです。システムの機能が依然として組織にとって価値があるが、保守コストが高い場合や技術サポートが不足している場合に有用な戦略です。実際には、以下のような結果が得られることがあります： レガシープログラミング言語を最新のプログラミング言語に移行する 特定の機能やモジュールの完全な再設計 プラットフォームやサードパーティコンポーネントのモダナイゼーション アーキテクチャ層のモダナイゼーション（例：データ管理やプレゼンテーション） リ・エンジニアリングは非常に費用がかかることがあります。自動化ツールを使用してシステムをリ・エンジニアリングすること、例えば、あるプログラミング言語から別のプログラミング言語に変換したり、新しいプラットフォームに移行したりすることができます。自動化ツールの使用はリ・エンジニアリングプロセスを短縮化しますが、実装の品質を向上させる可能性は低いです。 【ラップアップ】  レガシーシステムを完全にリ・エンジニアリングするのは費用がかかりすぎるが、依然としてビジネスにとって価値のあるコア機能やデータを含んでいる場合があります。問題は、レガシーシステムが組織のアジリティに制約を与えていることです。一つのアプローチは、レガシーシステムを最新技術を使用してファサードでラップし、最新技術の相互運用性を利用してレガシー機能やデータにアクセスすることです。 例えば、レガシーシステムをAPIでラップし、レガシーシステムからデータを仲介して最新のアプリケーションに公開することができます。この技術を使用すると、レガシーシステムのデータをAPI経由で使用し、フロントエンドとして最新のアプリケーションを提供することができます。 この戦略には制限があります。特にパフォーマンスや容量が問題となる場合、レガシーシステムをラップすることでパフォーマンスが向上することはなく、追加のオーバーヘッドが発生することさえあります。レガシーシステムとの通信プロトコルも制約され、リアルタイムでの通信が制限されることがあります。 【クラウドマイグレーション】  レガシープラットフォームを改善するための一般的な戦略は、アプリケーションをクラウドベースのプラットフォームに移行することです。ハードウェアや運用担当者に関連するコストを削減することが目的とされることが多いです。クラウド環境でシステムを運用するもう一つの利点は、ニーズに応じて容量を容易にスケールできることです。 クラウド移行の重要な側面は、法的およびセキュリティの影響を考慮することです。組織は、システムに機密データ（例：個人情報、患者記録、財務情報）を保存することがあります。このような情報は、GDPR（EU）などの規制の対象となる場合や、データが発生した国によって法的に管理される場合、または単に組織にとって機密性が高い場合があります。したがって、情報が物理的にどこに保存されているか、クラウドサプライヤーがどの管轄下で運営されているかを把握し、第三者や外国政府によるデータアクセスを防ぐことが重要です。 【データマイグレーション】 一般的なモダナイゼーション戦略は、レガシーシステムを最新のシステムに移行することです。これは、レガシーシステムに含まれるデータが依然として組織にとって非常に価値がある場合に行われます。新しいシステムを購入または開発し、レガシーシステムからのデータを最新のシステムに移行します。この戦略は、レガシーシステムからの貴重なデータを保持しながら、最新の技術を備えた新しいシステムを提供します。 新しいシステムの購入または開発には多額の投資が必要であり、かなりの時間がかかります。レガシーシステムから新しいシステムへのデータ形式を変換するための移行ツールが必要であり、移行はデータの一定の割合でしか成功しない場合があるため、手動での移行が必要になることがあります。また、レガシーシステムと新しいシステムが一定期間並行して稼働する場合があり、これにより二重の保守コストが発生することがあります。 【廃止とリプレース】  場合によっては、レガシーシステムが単に寿命を迎えることがあります。過去に蓄積されたデータはほとんど価値がないと見なされ、システムは組織が必要とする機能を提供する最新のシステムに単純に置き換えられます。レガシーシステムは廃止され、アーカイブされます。レガシーシステムからデータが必要な場合は、アーカイブから取得できます。 この戦略は、レガシーシステムを迅速にリプレースする方法を提供しますが、組織が新しいシステムに適応するまでに時間がかかることがあります。新しいシステムの導入には、担当者の大規模なトレーニングが必要になる可能性があります。初期の期間中、組織はアーカイブと新しいシステムの両方からデータを取得する必要があるかもしれません。これには、時間のかかる手動プロセスが必要になることがあります。   まとめ レガシーモダナイゼーションは、企業が競争力を維持し、効率的にビジネスを運営するために重要です。古いシステムを最新ソリューションに変えることで、柔軟性を高め、セキュリティリスクを軽減し、ビジネスの価値提供を最適化できます。適切な戦略と計画を立てることで、企業はレガシーシステムの制約を克服し、変化する市場環境に迅速に対応できるようになります。これにより、顧客に対してより良いサービスを提供し続けることができるでしょう。 ご一読いただきありがとうございました。Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

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

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