検索結果

昨年7月、次期ArchiMateの草案として「ArchiMate NEXT Specification, Snapshot 1」が公開されましたが、前回の記事で触れた通り、なかなか大掛かりな変更の予告でした。 そのArchiMate 4が、2026年4月に正式リリースされました。The Open Groupの公式サイトでは無償の評価ライセンス（90日間）または非商用の永久ライセンスで仕様書をダウンロードできます。 スナップショット1から何が変わった？ 一番気になるのは「プレビューから正式版にかけて何が変わったか」ですよね。 結論から言うと、大筋はスナップショット1の通りに着地したようです。ArchiMate Forum ChairのJean-Baptiste Sarrodieは「コンセプト数を約30%削減し、60超の要素から40に絞り込んだ」と述べており、これはスナップショット1の時点で予告されていた「42要素」とほぼ一致します。 The Open Groupの公式アナウンスでは「強いユーザーレベルの互換性を持ちながら、前のバージョンからスムーズに移行できるよう設計されている」とされています。 スナップショットから正式版への主な変更点 The Open Groupは正式リリースと同時に「Motivation for Changes in ArchiMate® 4（W262）」という変更理由をまとめたホワイトペーパーも公開しています。スナップショット1のパブリックレビューを経て、コミュニティフィードバックが反映されているはずですが、現時点で把握できている内容を踏まえると、主なポイントは以下の通りです。 変わらず正式採用されたもの： - Common Domainの新設（振る舞い要素、ロール、パスの汎用化） - Hexagonionフレームワーク（「レイヤーのマトリクス」から「ドメインの六角形」へ） - コンポジション・リレーションの廃止 - カーディナリティの追加 - 要素数の約30%削減 互換性への配慮： スナップショット1の段階で一部懸念されていた「既存モデルへの影響」については、正式版は「継続性と実世界への適用可能性」を優先したとThe Open GroupのCEOが言及しており、不必要な混乱なくアーキテクチャ実践を強化できるよう設計されているとされています。 改めて「何がうれしいか」を振り返ると 前回の記事では「シンプルになった」「AI時代にマッチした」という点を個人的な所感として挙げましたが、正式版リリースのインタビューでもその点は強調されています。 Sarrodieは「使いやすく、学びやすくすることが、ArchiMate 4における主要な課題の一つだった。表現力を失わずに小さくすることを目指した」と語っており、まさにスナップショット1のインプレッションそのものです。 Hexagonionフレームワークが従来の矩形のレイヤーマトリクスに替わって採用されたことで、ドメイン同士が上下関係ではなく対等なピアとして並ぶ構造になり、ヒトとソフトウェアとAIが同じレベルで動く現代のハイブリッド企業を表現しやすくなっています。前回記事で「縄張り感が薄まった」と書きましたが、それが正式版でも貫かれた形です。 ツールはどうなる？ 前回記事の最後に「ツールでの実装がどうなるか気になる」と書きましたが、商用ツールでは Visual Paradigm がプレリリース段階から積極的に対応しており、正式版への追従も期待できます。 一方、無償のオープンソースツールとして多くのユーザーに親しまれているArchi®については、現時点（2026年6月）で公式サイト・GitHubともArchiMate 4対応についてのアナウンスは見当たらず、最新版Archi 5.9.0（2026年4月リリース）も引き続きArchiMate 3.2対応のままです。 ただし、心強い事実もあります。ArchiはPhil BeauvoirとJean-Baptiste Sarrodieの二人によって開発・メンテナンスされているのですが、このSarrodie、実はArchiMate Forum Chairとして今回のArchiMate 4策定をリードした人物その人です。「ArchiMate 4を作った人が、Archiも作っている」——対応は時間の問題ではないかと思われますが、続報を待ちたいところです。 また、The Open Groupのフォーラム側でも、今後ツールの適合要件（conformance requirements）の策定に取り組んでいくと表明しており、ツールエコシステム全体の整備はこれからが本番という段階でもあります。 まとめ スナップショット1の段階で「かなり大掛かりな変更」と感じた内容は、おおむねそのまま正式版に着地しました。コミュニティレビューを経て「互換性への配慮」がより丁寧になった印象ですが、哲学的な方向性は変わっていません。 ArchiMate 4はモデルの構造がよりシンプルで機械可読性も高く、生成AIとの連携や自動化ツールとの統合という観点でも、ますます注目される存在になっていくことが期待されます。 仕様書はThe Open Groupのサイトから無償でダウンロードできます。前回の記事でスナップショット1を読んだ方なら、差分確認という意味でも目を通してみる価値はあると思います。人知れず（?）着実に進化を続けるArchiMate、今後もウォッチしていきたいと思います。 【おまけ】勤め先の社外ホームページで連載始めました！ シリーズコラム「オントロジストというしごと」 参考リンク - [ArchiMate Licensed Downloads — The Open Group](https://www.opengroup.org/archimate-licensed-downloads) - [The Open Group Announces ArchiMate® 4 Specification](https://www.opengroup.org/The-Open-Group-Announces-ArchiMate%C2%AE-4-Specification) - [Discussing the Release of the ArchiMate® 4 Specification — The Open Group Blog](https://blog.opengroup.org/2026/05/20/discussing-the-release-of-the-archimate-4-specification/) - [Archi — Open Source ArchiMate Modelling](https://www.archimatetool.com/)

Iasaの知識体系であるBTABoKにおいて、アーキテクチャの「Operating Model（運用モデル）」は非常に重要な位置を占めています。その中でも、今回取り上げる「Tools（ツール）」の章は、一見するとソフトウェアの選定ガイドのように見えますが、実はアーキテクトの本質的な「構え」を問う内容になっています。 1. BTABoKが定義する「ツール」の真意 多くの組織で「アーキテクチャ・ツールを導入しよう」という話になると、すぐに「どの製品（EAMツールやモデリングソフト）を買うか」という議論になりがちです。しかし、BTABoKの定義はもっと広義です。 BTABoKでは、ツールを「技法（Techniques）」と「デバイス（Devices）」の両方であると定義しています。つまり、高価なモデリングソフトだけでなく、ホワイトボードの前で行うワークショップや、意思決定のためのフレームワークそのものが「ツール」なのです。 ここで強調されているのは、ツールの目的は「資産の記録」ではなく、「複雑な構造を可視化し、ステークホルダーとの合意形成を加速させること」にあります。 2. 私の視点：ツールが「重荷」になる組織の共通点 BTABoKの記事の中で私が特に注目したのは、「ツールは可能な限り軽量（Lightweight）であるべきだ」という原則です。 実務において、アーキテクチャ・リポジトリ（設計情報の保管庫）を完璧に維持しようとして失敗する例を何度も見てきました。情報を入力すること自体が目的化し、肝心の意思決定が遅れてしまうのです。これは、ツールが「アーキテクトの武器」ではなく「管理のための足枷」になっている状態です。 3. 私の考え：アーキテクトの「手なずけ方」 ここで、BTABoKの記述をベースに、日本企業におけるアーキテクチャ・ツールの活用についての私の考えを述べます。 私の考え：ツールの価値は「蓄積した情報の量」ではなく「情報の代謝の速度」で決まる 優れたアーキテクトは、ツールを「情報の墓場」にしません。むしろ、以下のような使い分けをしているのではないでしょうか。 結局のところ、どんなに高度な自動化ツールを導入しても、それを運用する側の「何を、なぜ可視化するのか」という目的意識が欠けていれば、ツールはただの箱に過ぎません。 4. まとめ BTABoKが教える「ツール」の本質とは、特定の製品に依存することではなく、「自分の組織のスピード感に合った、最適な思考の道具箱（ツールキット）を構築すること」にあると言えます。 ツールに振り回されるのではなく、自らのアーキテクチャ活動を加速させるための「軽やかな武器」としてツールを再定義すること。それが、変化の激しい現代においてアーキテクトに求められる真のスキルではないでしょうか。

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

bijinesuakitekuchabenkyokai-bizboksamaribanworindokushiyou-1 [ビジネスアーキテクチャ勉強会 第２回] 「BIZBOKサマリー版を学習しよう」 * *

dai1kai-archimatenokisowomanabou-zen12kai-1 「ArchiMateの基礎を学ぼう (全12回)」第2回 * *

iasanipponshibu-archimatebenkyokai-edgyttenan-zen6kai [Iasa日本支部 ArchiMate勉強会]「上流って何？」(全6回)」 * *