検索結果

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

本コラムでは、BTABoKオペレーティングモデルの概念である「ステークホルダー」を取り上げます。 ステークホルダーは、ビジネスやプロジェクトに影響を与える人や組織であり、 その成功に関心や利害関係を持っています。彼らの関与は、プロジェクトの進行や成果に大きな影響を与える可能性があります。そのため、ステークホルダーを適切に理解し、関係を管理することはビジネスやプロジェクトの成功に不可欠です。 BTABOKにおいてもステークホルダーの重要性は記載されており、ITアーキテクトとの関係性やコミュニケーションの取り方について定義されています。以下に関単にその内容を紹介します。 １．ステークホルダーとは？ ステークホルダーとは、特定の目標、ビジネスケース、または課題に対して関心や関与を持つ個人や組織のことを指します。ステークホルダーは、課題の成功に対して既得の利益を持っており、その成功はステークホルダーに対して肯定的、否定的いずれの影響を及ぼします。ステークホルダーは、その影響力を使って課題の解決を促進し、支援することができますし、結果として得られるアーキテクチャがステークホルダーにとって否定的である場合、課題の解決を妨げることもあります。一部のステークホルダーは、イニシアチブに貢献することによって積極的な役割を果たすことがありますが、他のステークホルダーはより受動的な役割を果たすこともあります。 典型的なステークホルダーの例としては、顧客、経営陣、または会社の部門などがあります。 ２．ステークホルダーの重要性 ステークホルダーは重要です。なぜなら、彼らは課題の進行に影響を与え、場合によっては成功と失敗の違いを生むことがあるからです。異なるステークホルダーは、影響力と情報ニーズの度合いが異なります。 「あなたは常に一部の人々を喜ばせることができます、あなたは時々すべての人々を喜ばせることができます、しかし、あなたは常にすべての人々を喜ばせることはできません」 - エイブラハム・リンカーンに支持された詩人ジョン・リドゲートの言葉、 ステークホルダーの管理は多くの労力を必要とし、課題に多くのステークホルダーが関与している場合、これは非常に困難になることがあります。影響力のあるキーステークホルダーが満足していることを確認することで、課題の成功の可能性が大幅に高まります。 キーステークホルダーが課題に対してポジティブな影響を与えると、資金調達、キーパーソンのアサイン、その他のイニシアチブに対する優先度の向上など、大きな利点をもたらすことができます。 一方で、ステークホルダー自身がキーとなり、課題や提案されたアーキテクチャによってネガティブな影響を受けることがあります。例えば、レガシーシステムを置き換えるとき、レガシーシステムのオーナーはデータの移行においてキーとなるかもしれませんが、最新システムへの移行によって、ステークホルダーは影響力や予算を減らすことになるかもしれません。このような場合、否定的な影響を緩和する方法を見つけることが重要です。例えば、アーキテクチャに妥協をすることで、組織の再編や役割の変更など、有利な状況を作り出すことができます。 ３．意見の重要性 ステークホルダーは、自分にとって有利な方向に課題を解決させたいと思うでしょう。その一つの方法は、自分の意見をアーキテクトと共有することです。ステークホルダーからの意見を取り入れることで、課題への関わりを作り出すことができ、これによりステークホルダーの課題成功への関心が高まることがあります。 ステークホルダーは意見が衝突することがあり、多くのステークホルダーがいると、すべての意見に同じ注意を払うことは困難です。どの意見を満足させ、どの意見には少ない注意を払うかを選択する必要があるかもしれません。ここで重要なのは、どのステークホルダーが課題に最も好意的であるかを知ることです（パワー・インタレスト・グリッドを参照してください）。 ４．ステークホルダーとの合意形成 ステークホルダーの関心や関与は、活動動機から生まれます。活動動機とは、ステークホルダーの関心を引き出し、意思決定に影響を与える力のことです。個々の人々にとっての活動動機は、名誉、権力、安定性、スキルの向上などがあります。組織にとっての活動動機は、組織の文化や組織が行うビジネスの種類によります。組織の活動動機の例としては、成長、予算/売上の増加、スキルへのアクセス、コンプライアンス、競争優位性などがあります。 ステークホルダーの動機が何かを知ることで、ステークホルダーと課題との関係が明らかになり、ステークホルダーがアーキテクチャからどのように価値を得ることができるかを示すことが容易になります。ステークホルダーの活動動機は、アーキテクチャのさまざまな側面に対するステークホルダーの関心を評価するための基礎を提供します。ステークホルダーが何に動かされているのかを理解することで、課題やアーキテクチャの推進、およびステークホルダーがどのように価値を得ることができるかを示すことが容易になります。 ５．ステークホルダー間の調整 ステークホルダーの管理はバランスが必要です。ステークホルダー間には複雑な関係があり、ステークホルダーからの影響力と関心を得るためには信頼が鍵となります。これは微妙なバランスを保つ行為であり、一つのステークホルダーへのコミットメントが他のステークホルダーとの関係にネガティブな影響を及ぼす可能性があります。交渉、外交、紛争管理は、アーキテクチャのバランスを保ち、ステークホルダーの信頼を維持するための有用なスキルです。 ステークホルダーを管理するための労力は無限ではなく、ステークホルダーの狭い範囲に焦点を当てることで、いくつかの重要なステークホルダーを満足させることができます。しかし、これは広範なステークホルダーが課題に対する関心を失ったり、アーキテクチャに対するネガティブな傾向を始めたりする問題を引き起こす可能性があります。したがって、ステークホルダーに対する労力の管理において適切なバランスを見つけることが重要です。 ６．重要ステークホルダーの特定 特定のケースでは、特定のステークホルダーが課題の成功にとって重要です。ステークホルダーが特別なスキルやリソースを持っていたり、課題が依存している他のプロジェクト/製品の責任者である場合があります。課題の活動とそのようなステークホルダーとの間のキーとなる依存関係を特定することは、アーキテクチャの成功にとって不可欠です。 ７．ステークホルダーの背景を知る アーキテクチャを伝える際には、ステークホルダーが理解できる形でアーキテクチャが提示されていることを確認することが重要です。ステークホルダーはしばしば異なる背景を持ち、アーキテクチャに対して異なる関心を持っています。例えば、一部のステークホルダーはアーキテクチャの技術的な視点に関心を持つかもしれませんが、他のステークホルダーはビジネスの視点に関心を持っています。適切なステークホルダーに対して適切なアーキテクチャの視点を選択することで、情報が関連性を持ち、アーキテクチャの理解が深まります。 ８．ステークホルダーを味方にする ステークホルダーは強い意見を持つことがありますが、それらの意見に挑戦し、適切な方向性を選択するのはアーキテクトの責任です。意見や提案はすべて、最良の結果を得るために、異なるシナリオや状況でテストする必要があります。これにより、アーキテクトは提案された変更に納得感を得ることができ、単にステークホルダーの指示に従うのではなくステークホルダーの賛同を得ることができます。 ＊＊＊ いかがでしたか？これらのポイントを考慮することで、ステークホルダー管理はより効果的になり、プロジェクトの成功につながる可能性が高まります。ただし、これらはあくまでガイドラインであり、具体的な関係者や状況によっては異なるアプローチが必要となる場合もあります。それぞれのプロジェクトや組織に最適なステークホルダー管理の方法を見つけることが重要です。 Iasa日本支部は、日本国内においても実践力を備えたアーキテクトが広く認知され、活躍できるような業界にしたいと考えています。今回解説したステークホルダ管理は、プロジェクトを成功に導くために重要なスキルです。このようなスキルを有した成熟したアーキテクトが一人でも多くなるよう、これからの価値ある情報を発信していきたいと思います。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

本コラムでは、BTABoKオペレーティングモデルの概念である「ロードマップ」を取り上げます。 現代において企業ITシステムのロードマップの重要性は、ますます高まっています。その理由は、ビジネスとテクノロジーの迅速な変化に対応するためです。デジタル変革を進めるには、短期的な対応ではなく、将来に向けた全体的な戦略と計画が必要です。ロードマップは、企業が新しい技術を取り入れ、顧客に価値を提供する製品やサービスを開発する際の指針となります。これにより、計画的にリソースを配分し、優先順位を設定することで、変化に柔軟かつ効率的に対応し、競争優位性を維持することが可能となります。 BTABoKにおいても、長期的なビジネス目標や製品開発の計画を視覚的に示すロードマップの重要性を強調しています。ロードマップは、目標達成の計画を時間軸に沿って描いたものであり、企業価値を提供する大規模な活動の計画に用いられます。特に革新と変革の段階で利用され、新しいイニシアチブの計画、実行の追跡、重要な依存関係の特定に役立ちます。また、ロードマップは、リソースや予算に関する大まかな見積もりを立てる枠組みとしても機能し、ビジネスイニシアチブの実行可能性を評価する前段階として利用されます。詳細は、オペレーティングモデル - ロードマップをご覧ください。以下で、簡単にその内容を紹介したいと思います。 ＊＊＊ 1. ロードマップが必要な理由 企業は戦略的なイニシアチブの多くを長期計画し、ステークホルダー間で共通の理解を促進する必要があります。ロードマップは、それらの依存関係の可視化によりリスクを減らし、優先順位付けを支援し、予算やリソースの概算に役立ちます。進捗の可視化はステークホルダーのモチベーションを高めます。また、アーキテクトにとっては、時間を考慮したアーキテクチャの方向性を示し、代替アーキテクチャの選択肢を評価するツールとなります。 ２．ロードマップアプローチ 良いロードマップ作成のための重要な原則には、ロードマップの範囲を明確にし、ビジネス中心の計画を立てることが含まれます。ロードマップは長期的な視点を提供し、大規模な変化を計画するものであり、プロジェクト計画とは異なります。項目はビジネスの目標や目的に明確に貢献する必要があり、実現可能性の評価はプロジェクト計画で行います。また、ロードマップは範囲外の項目を避け、すべてのステークホルダー間で誤解のリスクを減少させるために、スコープを明確にする必要があります。 ３．戦略的ロードマップと製品開発ロードマップ ロードマップには戦略的ロードマップと製品開発ロードマップがあります。戦略的ロードマップは企業全体や製品ポートフォリオの長期計画を示し、広範囲に渡ります。これは組織の上位ビジネスパーソン向けであり、製品開発に関する成果物を含みます。一方、製品開発ロードマップは具体的な製品に関連する計画です。両者は密接に関連しており、戦略的変更が製品計画に影響を与え、その逆も同様です。この関係性を理解し、効果的に管理することで、リスクや依存関係を早期に特定し、負の影響を軽減できます。 ４．戦略的ロードマップ 戦略的ロードマップは、組織の戦略的目的や目標を達成するために、企業、ビジネス、インフラストラクチャの変化を含む一連の成果物を計画します。これらは、トランジションを通じて組織の初期状態から目標状態への移行を促し、組織内で変化のリンクを作成します。ロードマップ作成のプロセスは、ビジョンとスコープの合意から始まり、ワークショップを通じて目標、目的、期限を明確にし、移行を定義します。このアプローチにより、成果物の優先順位付け、依存関係の管理、ステークホルダー間のコミュニケーションが強化されます。 ５．製品開発ロードマップ 製品開発ロードマップは、特定製品の長期計画を示し、リリース、機能、イベントに焦点を当てます。リリースは製品のバージョンで、明確なスコープと目標が設定されます。このロードマップは、製品管理と開発チームに方向性を提供し、企業戦略との整合性を図ります。また、リリース計画では、開発サイクルの主要イベントやQAを含め、製品の要件を満たす機能（エピックとも呼ばれる）の開発を計画します。 ＊＊＊ 以上、ロードマップの記事の内容を概観しました。実際の記事では、多くの構造化キャンバスも紹介されていますので、みなさんにとって価値ある情報源になると思います。 さて、みなさんにお尋ねします。このようなロードマップが組織的に運用されている企業は、現実にどれだけあるでしょうか？多くの企業にとって、ロードマップを組織的に定義し運用する際の障壁が存在します。まず、明確なビジョンや目標の欠如が挙げられます。ビジョンや戦略的目標が不明確であると、ロードマップの方向性を決定することが難しくなります。次に、組織内のコミュニケーション不足や部門間の調整の欠如も障害となります。異なる部門やチーム間での目標の認識のズレや協力の不足は、組織全体での取り組みの一貫性を損なうことになります。また、適切な技術やツール、スキルの不足も、効果的なロードマップの作成と実行の妨げとなることがあります。これらの障壁を克服するには、組織全体での明確なコミュニケーション、共有ビジョンの確立、適切なリソースとスキルの確保が必要です。そしてアーキテクトこそ、そうした役割を担う最適なポジションにあるといえるでしょう。 Iasa日本支部は、このようなスキルを備えたアーキテクトが一人でも多く活躍できるような業界にしたいと考えています。今回解説したロードマップのスキルは、変化の時代に生きるアーキテクトに不可欠なものです。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

BTABoKといえば「エンゲージメント・モデル」ですが、その前身であるITABoKといえは「5つの柱と4つの専門領域」でした。もちろん現在もこれらは全て「コンピテンシー・モデル」としてBTABoKに受け継がれ、さらに加筆修正、新たな項目の追加が随時行われています。今回はBTABoKの「インフォメーション・アーキテクチャ」コンピテンシー・モデル、つまりITABoKでいうところの「インフォメーション・アーキテクチャの専門領域」に新たに加わった"Informat ion Usage" (「情報の使用」)を、仮訳のかたちでご紹介します。 情報の使用 解説 情報・ナレッジの管理は、自覚の有無に関わらず私たちが日常的に行っているあらゆるビジネス、職業、仕事の中核をなすものです。探している情報を見つけるのが簡単であればあるほど、顧客へのサポートやビジネスの強化、そして目の前の仕事をこなすことに、より多くの時間を費やすことができます。 インフォメーション・アーキテクト(IA)として、あるいはどの役割であれ、成功のためには誰が顧客なのか、現在、そして今後どのようなニーズがあるのかを知り、理解する必要があります。 これは文字通りすべてのアーキテクチャ分野をつなぐ架け橋たるIAにとって特に重要です。加えて私たちが顧客と向き合っているという事実の重みは、直接的あるいは間接的に顧客に影響を与えかねず、私たちの両肩に重くのしかかっています。しかし私たちはひとりではないことが救いです。私たちはさまざまな部署や顧客との架け橋となっているので、この重荷を背負う助けを得ています。私たちはすべての答えを持っている必要はありません。私たちに必要なのは、情報を分類・保管することで、パートナーが過去、現在、そして未来に生じる疑問や答えを見つける手助けをする司書としての知識と専門性です。最も成功したIAとは、デジタル・ランドスケープ全体のためのデューイ十進分類法のカスタマイズに留まらず、利用者がその分類法を活用し、必要な時に必要な場所で必要なものを、利用者が努力することなく見つけられるようにする能力を持つ現代のライブラリアンです。 「情報の使用」コンピテンシーの概要 「どのように」情報は用いられるか 今日の「do more with less data」という世の圧力と、人間が消費しやすい形へのデータ集約とは最も深刻なジレンマです。もし情報が目の前の問題や疑問の解決に役立たなければ、ステークホルダはその情報には価値がないと思い情報から離れていくでしょう。私たちはADD処理が多すぎる情報過多社会になりつつあり、長々とした説明ではなく即答を求めるあまり忍耐力も低下しつつあります。コンピュータとともに... あなたの役割や専門分野によっては、あなたが育む情報が人間だけでなく機械にも消費されることは驚くに当たらないでしょう。私たちがソリューション・アーキテクチャを考えるとき、もはや人間だけ、あるいは機械だけを顧客とすることはできません。私たちが暮らす電子の世界では、このふたつの境界線はあいまいです。将来的な情報活用の道を阻むことにならないよう、私たちのすることのすべては、その両方を考慮に入れなければなりません。そのためにはどうすれば良いのでしょうか？アーキテクトとしてご存知のように、答えは「何」ではない、「どのような」制約の中「どのような」方法で問題を解決してほしいかということです。アーキテクトとして、問題を「ひとくち大」に分解するのが一番だと私は考えます。それぞれの側面から問題を見て、最終的に両者が満足するようなインターフェースや抽象化レイヤーの存在を確認することです。 「いつ」情報は用いられるか 情報は私たちが思っている以上にさまざまな形で利用されていることがわかりました。今回のレッスンや今後のプロジェクトを通して、情報が「どのように」使われているのかを見逃さないようにしましょう。次に、情報が「いつ」使われるのかを詳しく見てみましょう。情報は私たちの日常生活で常に使われています。そのような内的プロセスは潜在意識が代行するので、私たちはほとんどそのときを意識することはありません。情報は、私たちのさまざまな感覚を通して、継続的なインプットとして、意思決定を行い、事実、仮定、プロセスをサポート・検証し、研究開発で興味深い分析を支援することに使われます。情報が「いつ」使用されるかは、朝の服装を決める、いい匂いのするドーナツを口に入れる、といった基本的なことから外れるとき、私たちのビジネス、そのために私たちが設計するソリューションにも同じことが当てはまるとわかります。 情報をいつ使うかは、アーキテクトとして常に間違いなく答えられる数少ない問いのひとつです。IAとしての私たちの役割は、情報を取得し、保存し、カタログ化し、さまざまな情報源が必要なときに利用できるようにすることです。同様に、情報の消費者がより賢明な決断を下し、彼らのイニシアチブを支援し、また重複作業を減らすことで研究開発を促進し、そして未知なるものへの認識を取り除く、そのような役に立つ情報が入手可能であることを、彼らに教え啓発することが、私たちの正しい仕事のやり方です。 「どこで」情報は用いられるか ここまでが前半です。私たちは情報が「どのように」使われるかをもっと注意深く見るべきです。情報は常に私たちの周りで使われているのでなお更です。それゆえ私たちは、情報を理性的に捉え共有することをより意識する必要があります。ここで、私たちが様々な形で備蓄し、さらに様々な方法で利用可能にしたこれらの情報を、私たちは「どこで」使うつもりなのか、という疑問が生じるはずです。合ってますか？インフォメーション・アーキテクトとして私たちは、すべてのアーキテクチャ・ドメインおよび、それに加えてビジネスのあらゆる側面の橋渡しをコントロールし、構築する責任を負っています。これらの橋は、部署や事業部門、時には国土や別の会社にまでまたがるものです。情報が「どこで」使われるかは、開発者のクリエイティビティによってのみ制約を受けます。情報とは、画家が真っ白なキャンバスに塗る絵の具のようなものだと考えましょう。その情報を使ってデータベースをデザインするアーティストもいるでしょう。 私たちが提供する情報は、DBは構造化・正規化され、水平にも垂直にもスケーラブルで、データをサブコンポーネントに分割でき、DBの消費者が必要なものを迅速かつ合理的に入手できるようにします。 また、私たちの情報がドキュメントの作成に使用される場合もあります。これらのドキュメントは私たちが提供する他のすべてと同様に、無限の形で存在します。あるドキュメントは財務分析用のスプレッドシートかも知れません。そのようなときに私たちが提供する情報は、私たちの資産、特許、著作権、商標を保護する法的な様式や、パートナーや潜在顧客との拘束力のある契約の裏付け資料などかも知れません。その一方で、人事部門が単に従業員の記録を作成するために使われるだけの情報もあるでしょう。 IAとしての役割によっては、情報はウェブベースのサイトやアプリケーションを設計する際のコア・ソースと考えるのが一般的でしょう。人間とのインタラクションのためのサイトやアプリのナビゲーションを、シンプルで楽しく、よく考え構築することや、インターフェイスをガタつきがなく、美的に魅力的に作ることなどです。 「なぜ」情報は用いられるか この時点で、情報がいつ、どこで、どのように使われるかについて、より包括的な認識が持てたことでしょう。でもなぜでしょう？ 私たちが使うものとして情報が重要なのはなぜなのでしょうか？私たちが情報を利用する一般的な理由としては、市場検証、ユーザビリティの実装、知識・コンテンツ・ドキュメントの共有・管理、そして最近取り上げたビジネス・プロセス管理などがあります。 市場検証は、ビジネス・アーキテクチャ・グループとエンタープライズ・アーキテクチャ・グループとの架け橋となる多くの理由のひとつです。あなたが彼らに提供する情報によって、彼らは様々なことを行う、または行わないビジネスケースを提示できます。企業の買収、製品・ソリューションの構築と購入の比較、企業のミッションの調整、新たな収益源への着手、既存の機能や製品ラインの更新や廃止などです。これらはあなたが他に提供した情報が、市場ベースの戦略や意思決定などの検証に使用される可能性がある多くの意思決定のほんの一部に過ぎません。 ユーザビリティはふたつのパスに分かれますが、どちらももう一方に大きく依存しています。どちらか一方を行うか、あるいは両方を行うかは、当然ながらチームや会社の規模や複雑さによって異なります。一方はデザインと実装のUX専門家です。もう一方は、ユーザビリティ・スタディの専門家たちで、ユーザビリティ調査の方法、内容、場所、時期、理由の策定だけでなく、実施された実験の結果を集計し、偏りのない意味が得られるようにします。最終的にこのふたつのグループが一緒になって、内部・外部に関わらず、私たちが提供する製品の使用を通じた、ユーザーの楽しくサクセスフルな経験に関係する情報アーキテクチャの基礎を作り上げます。このふたつのトピックは、それら自体が立派なトレーニングコースになります。 IAとして、当然ではあるものの、時に最も困難な責任のひとつ、そして最大の「なぜ」情報は用いられるかの理由のひとつがナレッジ・コンテンツ・ドキュメント管理です。目的はシンプルで、情報検索のコストを削減しリターンを最大化する一方で、情報作成の労力の重複を削減することです。シンプルですね。でも違います。スープにどんなスパイスを加えたらいい味になるか、それぞれの考えで調理しているコックがキッチンに多すぎることがよくあります。厳格なガバナンスと経営陣の賛同が、IAとしてのこの業務領域での唯一の希望です。営業担当者は自分の連絡先をサイロ化したがり、人事部は機密情報の漏洩を恐れて共有せず、ソフトウェア・エンジニアは「どのように」や「なぜ」を文書化しません。そしてもちろん「誰も私のやり方を知らなければ、私の仕事は安泰だ！」という標準的かつ典型的なメンタリティがあります。残念ながらこれは真実とはほど遠く、ナレッジの文書化や共有がなされていないため、その社員はその特定の仕事をこなせる唯一の人間となり、むしろ昇進やキャリアアップの妨げになります。これは非常に重要なトピックで、IAとしてそのチャンスや機会が与えられたら、この問題にどのように取り組めばより効果的なのか、そのヒントを提供するユースケース・シナリオをのちほど用意します。 ビジネス・プロセス・マネジメントは、ここで取り上げる「なぜ」情報が用いられるかの最後の例です。明らかに、そして願わくば、これまでのカリキュラムを通して、情報が使われる、あるいは使われる可能性がある他の理由をすでに皆さんが考えているように、私たちは十分な種をまいてきました。ビジネス・プロセスの作成、見直し、強化、最適化に情報を活用することで、直感や感覚ではなく、ファクトベースの意思決定を確実に実行できます。脊椎反射ではなく情報を活用し、時折発生する不具合ではなく、現実に基づいた最善のビジネ・プロセスを実現できます。理想的には、フィードバック・ループで不調なプロセスに情報を提供すれば、不具合は説明され、たとえ滅多に起きなくても、あなたや顧客に悪影響を及ぼすようなことはなくなります。 「情報の使用」コンピテンシー・モデル、いかがだったでしょうか。BTABoKをもっと知りたい方のために、IASA日本支部はBTABoK解説セミナーを開催しています。最新の開催予定、参加お申し込みはイベントページをご覧ください。ご参加お待ちしています！

明けましておめでとうございます。本年もIasa日本支部をよろしくお願いいたします。 さて今回はBTABoKのオペレーティングモデル内にある "Decisions" を紹介します。 中身に入る前にみなさまはアーキテクチャ設計を行う際に、何を基準に意思決定されていますでしょうか？また、意思決定された記録や根拠はどのように保管されていますでしょうか？ 個人的な印象ではありますが、今回の "Decisions" はそのような問いかけに対する答えを導く上での示唆を与えてくれるものと感じていますので、そのような視点でご一読いただけると幸いです。 "Decisions" の要約 Decisionsでは、アーキテクチャ上の重要な決定 (Architecturally Significant Decisions, 以下ASD) が組織全体に与える影響の範囲と重要性に焦点を当てています。また、決定の管理とその範囲、さまざまなレベルでの決定の種類、効果的な決定管理プロセス、さまざまな決定方法、認知バイアスの影響、決定の特性と方法、そしてプロジェクトライフサイクルにおける決定のタイミングとカスケード効果 (一つの決定が連鎖的に他の決定や出来事を引き起こす現象) について説明しています。これらの要素は、組織においてアーキテクチャの決定がどのように形成され、実行されるかを理解するのに役立ちます。 記載内容を要約したものが以下の表です。 表1：ASDについて アーキテクチャ決定の記録：Architecture Decision Record (ADR) について "Decisions" の中でも個人的に一人のアーキテクトとして重要視しているものの1つにADRがありますのでご紹介します。ADRは、ソフトウェア、データ、インフラストラクチャなどの重要なアーキテクチャ上の決定を文書化したもので、その目的は決定の理由、選択肢、考慮された要因を記録し、将来のプロジェクトメンバーなどの関係者が背景を理解できるようにすることです。 表2：ADRについて 私はITコンサルタントとしてさまざまなIT刷新プロジェクトでITシステムの構成図や仕様書を目にすることがありますが、それらのアーキテクチャの目的や今に至った経緯や背景を知るには、そのシステムの有識者に聞くことが多く、アーキテクチャの変更の影響度を把握する場合に時間を要することがあります。ADRがあればその辺りの時間の短縮も期待できますし、表2に記載のメリットも享受できます。ADRの記載例を表3に示します。 表3：ADRの記載例 (マイクロサービスアーキテクチャの採用) まとめ 今回はオペレーティングモデルの "Decisions" を紹介させていただきました。多くのアーキテクトのみなさんは、ITプロジェクトやビジネス部門からの相談を受ける中で日々奮闘しながら数多くの意思決定をされていると思います。場合によっては時間的・人的リソースなどの制約により必ずしもベストな意思決定ができないときもあろうかと思いますが、アーキテクチャの意思決定はプロジェクトのQCDなどに影響を与えるので制約がある中でもベストな意思決定をしたいものです。アーキテクチャの意思決定のスピードと質を向上させるための道具としてBTABoKの "Decisions" が多くのアーキテクトの一助となることを望みます。 ご一読いただきありがとうございました。 参考 Architectural Decision Records

今回はBTABoKのオペレーティングモデルの層にある品質保証 (Quality Assuarance) について、見ていきたいと思います。 以下にBTABoKの品質保証の章立てと内容のサマリを示します。 品質保証は言葉はシンプルですが、業種業界ごとの法的要求事項や求められる専門知識も多岐に渡ります。そのため、アーキテクトは1人または複数の品質保証の専門家や第三者のアーキテクトと協調しながら検証と妥当性の確認 (Verification & Validation, 以下 V&V) 実施することが求められます。 ITプロジェクトの場合、ソフトウェアの単体テストや結合テスト、総合テストなどを経て運用開始されますが、品質保証はテスト段階で確認するのではなく、設計段階から作り込むことが必要です。その考え方としてV&Vは有効ですし、その中で用いられるツール (例：トレーサビリティマトリクス) などを活用することで要求者と提供者のコミュニケーションも円滑に進み、要求変更の影響度も把握しやすくなります。 私自身、以前はIT構想企画から要件定義、設計、実装、テスト、運用開始後のフォローまでを担当することが多く、品質保証を意識する機会は多くありましたが、ここ最近はIT構想企画に軸足を置いて仕事をしていることもあり、品質保証の重要性に対する意識が薄まっているように感じます。 今回のコラムを書くにあたって品質保証について改めて見つめなおすことができました。品質保証に関する専門書を読むのは大変ですが、BTABoKは網羅的かつ簡潔にまとめられているのでアーキテクトとして理解を深める第一歩としてはちょうどよいと思います。 ご一読いただきありがとうございました！

今回はBTABoKのオペレーションモデルのひとつであるアーキテクチャライフサイクル（Architecture Lifecycle）についてのコラムです。 BTABoKでは冒頭で以下のようにArchitecture Lifecycleを紹介しています。 アーキテクチャのライフサイクル、つまりアーキテクチャ開発ライフサイクル (ADLC) は、アーキテクチャがその開始から廃止までを通過する段階です。 ADLC は、アーキテクチャ開発のためのガイド プロセスを提供し、アーキテクトがアーキテクチャの状態を理解し、伝達するのに役立ちます。 上図はADLCの段階を示しています。ADLCは、アーキテクチャが周囲の環境に合わせて発展・進化するための反復サイクルです。 ADLCのステージを以下に示します： 【イノベーションサイクル】 - ビジネスを変化させ、価値を得るための価値主導のアイデアの継続的なサイクル。これが継続的にアーキテクチャの進化を促します。 【戦略】 - 長期的なアーキテクチャの方向性を描き、ビジネスケースと課題の評価と優先順位付けを行う。その結果、アーキテクチャを開発するための要件が示されます。 【計画】 - 課題とアーキテクチャに関する要件が与えられ、アーキテクチャの基本的な設計図が作成されます。また、アーキテクチャ実務やチームは、アーキテクチャ変革を実現するために何が必要かという観点から評価されます。 【変革】 - 製品やソリューションなどの成果物を作成する際にアーキテクチャを使用し、スポンサーに期待価値を提供すること。これには、製品又はソリューションの開発中にアーキテクチャを改良することも含まれます。 【活用と測定】 - 成果物の配備後の実践におけるアーキテクチャの使用。これには、アーキテクチャがスポンサーに期待される価値を提供したかどうかを評価するための測定が含まれます。 【廃止】 - アーキテクチャの利用が一巡し、スポンサーに価値を提供しなくなった場合、アーキテクチャは廃止されるか、別のアーキテクチャに置き換えられます。 ADLCは、アーキテクチャの継続的な改善を目指すサイクルであり、アーキテクチャの測定がさらなる革新のためのフィードバックを提供します。 さて、ここで登場する「スポンサー」とはだれを指すのでしょうか？ 組織によりケースバイケースで、特定の人物ではないのでしょうが、その中のひとりはCIOと呼ばれる経営ボードでしょう。 CIOは情報システムのあるべき姿を維持、成長させることが使命のひとつとされています。そのためのアーキテクチャの継続的な改善を支えるADLCは、CIOにとっての有効で重要な手段となるでしょう。 また、スポンサーは、システムを設計し、構築するエンジニアたちでもあります。アーキテクチャの価値を一番身近に感じるのは彼らであり、ADLCはそのスポンサーであるエンジニアたちにも貢献することが求められます。 いづれにしても、ADLCを適用する際には、スポンサーの定義から行うことが重要となります。 さて、ADLCのステージの説明において、味わうべきは、アーキテクチャの【廃止】（廃止もしくは置き換え）のフェーズであります。 「当社にはアーキテクチャが無い」となげくCIOなど経営ボードがいますが、実際にはアーキテクチャが無いのではなく、良否はともかく描かれていないというのが実態と言えるでしょう。 現行AsIsのアーキテクチャを描いてみて、改善のサイクルを回すべきか、新たなイノベーションを起こし、現行のアーキテクチャは廃止し、新たなアーキテクチャに置き換えるべきかの決断から始めることが、求められます。そのうえで、ADLCを回していくことで、あるべきアーキテクチャに近づくことが出来るとBTABoKは主張しています。 BTABoKは、ADLCの必要性を以下のように述べています。 ライフサイクルが必要な理由 ADLCは、アーキテクトが高品質のアーキテクチャを開発するためのツール、成果物、プロセスを含む手法を提供します。ライフサイクルに標準的な段階を設けることで、アーキテクチャの開発におけるアーキテクト間の共通プロセスを提供します。アーキテクトがアーキテクチャの状況を伝え、ライフサイクルの各段階でアーキテクトに何が求められているかを知るのに役立ちます。 ライフサイクルは、アーキテクトがライフサイクルの適切な段階において、順序立ててアーキテクチャ活動を行うことを支援し、アーキテクチャ開発におけるプロセスの伝達方法を提供します。 ADLCそのものを開発することで、アーキテクチャ業務にアーキテクチャ開発の標準的な作業方法を取り入れることができます。これは、アーキテクチャ実務の反復的かつ継続的な改善を促進し、ガバナンスの基盤にもなり得ます。 ADLCを適用することで、自社のアーキテクチャをあるべき姿にし、そして情報システムを優位性のあるものとし、経営基盤を支えていくことになるでしょう。 自社のアーキテクチャの存在があいまいな状態の組織においては、道は遠いとも感じるかも知れません。しかし、まずは、あるがままに現行システムのアーキテクチャを描き、客観的に評価し、ADLCによりアーキテクチャを管理していくことで、情報システムの見える化が実現されます。重ねて申し上げますが、これが、経営戦略に基づいた情報システムとなり、いわゆるDXの実践に向かうことを可能にするのではないでしょうか？ ADLCは、活用してこそ価値があるものです。是非、原文を参考に適用を検討してみてください。 BTABoK／Architecture Lifecycleの原文は以下のサイトを参照ください。 Architecture Lifecycle - BTABoK (iasaglobal.org) IASA日本支部では、BTABoKの解説セミナーなどを定期的に行っています。 詳細については、https://www.iasa-japan.org/eventを参照ください。 奮ってご参加されることを願っております。よろしくお願いいたします。 以上

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

● 飯島先生　「エンタープライズオントロジーの勧め」 ＜講演概要＞ ・狭義のデジタルトランスフォーメーション（DT）はデザインの変革を言う ・DTには企業活動の本質を捉えるエンタープライズオントロジー（EO）が有効 ・EOの代表的理論（PSI理論、OMEGA理論、ALHA理論）の紹介 ・EOの実務的有効性についてモデリング方法論DEMOを用いた事例の説明 ＜感想＞ ・細部のITではなくビジネスシステムに向き合った芯を捉えた内容であった ・かねてからビジネスモデルの俯瞰図を模索してきたが間違いではなかった ・EOのモデル表記について2006年頃から世の中にあった事が興味深い ・“Ｘ線写真で皮膚を透過して骨格が見えるが如く”の比喩がたいへん絶妙 ・反面、抽象化度合いの高さに日本の企業人が追い付いていけるかが課題か ● 濱田さん　「システムアーキテクトの重要性とその育成について」 ＜講演概要＞ ・システムアーキテクト（SA）とは、経営、事業、技術の八咫烏的スーパーマン（IPA） ・SAに求められるスキルは、洞察力、コンセプチュアル、ヒューマンスキルが重要 ・SAに求められる考え方は、仮説推論、抽象化思考、アナロジーがポイントとなる ・SAが果たす役割は、業務要求からシステム要件に転換しビジネスアジリティに応える ・システムアーキテクトを育成する為には、コーチングとJOBローテーションが必要 ＜感想＞ ・社内のアーキテクト養成講座を担当されており、実践的な現場感が満載 ・一貫して「自分の頭で考える習慣をつけること」の重要性を訴えた点が印象深い ・現場30年の経験により培われたアーキテクト論は地に足のついたものであった ・所々に盛り込まれた隠し味的フレーズ「分業が分断を生む」がとても頭に残った ● 松井さん　「新時代のアーキテクトが拓くデジタルアドバンテージへの道」 ＜講演概要＞ ・アーキテクトの役割は曖昧さへの対処、創造性の発揮、複雑性のコントロールにあり ・近年、新たなアーキテクトの価値としてビジネス貢献、DXへの貢献が叫ばれる ・BTABOKのエンゲージメントモデル（個ではなく組織の力）の説明 ・BTABOKデジタルアドバンテージへの道（個からエコシステム）の説明 ＜感想＞ ・BTABOKがコンピテンシーからエンゲージネントへとスコープが拡大された点は納得 ・BTABOKの3層エンゲージメント「アーキチーム⇔組織⇔顧客」は分かり易かった ・アーキテクチャコンピテンシーを発揮する“チーム構成”に言及するに至った点を評価 ・アーキテクチャのビジネス効果測定の為の各種バリューモデルが興味深い ・顧客への価値提供などBTABOKモデル抽象度がかなり高いので今後具体例が望まれる ● パネルディスカッション　「デジタル変革の真実 ～ アーキテクトが果たす役割とは？」 ＜モデレータ＞小北 洋史 Iasa日本支部 理事 ＜パネリスト＞飯島 淳一 氏、濱田 潔 氏、中山 嘉之 Iasa日本支部 理事、末永 貴一、Iasa日本支部 理事 ■デジタル変革が企業にどう影響しているか、その真実 ・デジタイゼーション、デジタライゼーションはコロナ禍でAR、VRを用いて進んだ ・狭義のDXは、一部の企業では進んだ企業もあるが、進んでいかない企業も多い ・大企業は既得権益者が足かせになって進んでいないという面がある ■アーキテクトが果たすべき役割と、求められるスキルセット ・ビジネスドメイン知識とIT知識の両方を知ってソリューションを導くことが役割 ・日本の大学教育では情報系と業務系の分断が欧米より大きいという感じがする ■成功するために必要な人材の育成及び獲得方法 ・ITと業務がお互い分からないことは構わないが、知ろうとする意欲が必要 ・抽象化スキルをもってすれば知らない業務をモデル化することで知る事ができる ・スタートアップ企業の末永さんはデジタルが当たり前なのであえてDXと言わない 質問）CEOがビジネスアーキテクトであることが、日本と欧米との大きな違い？ ⇒建築系のCEOの場合は構造的に物事を捉えるのでDXが上手くいく事がある 質問）アーキテクト育成し継続する為には？ベンダーとユーザの関係はいかに？ ⇒アーキテクトを育成する人事制度、ベンダー⇔ユーザ企業が混じる流動化が必要 ★ 総合的な感想 ・それぞれ立場が異なる発表者からの講演は、どれもが今回のテーマ「Beyond Digital Transformation」に相応しい、視聴者にとって有意義な興味深いものであった。 ・2023年現在、DX推進が進んでいる企業とそうでない企業が二極化してきた感はあるも のの、一方でユーザ企業の人材流動化の兆候も出始めており、企業システムにおけるアー キテクチャの重要性、有能なアーキテクトの必要性についての認知度が高まる気配も感じられる。今後の産学でのアーキテクチャの取り組みに期待したい。 ・IASA-JAPANは引き続き日本企業のアーキテクチャ活動を支援していきたい。 以上。