「アーキテクチャフレームワーク？ もうそういう時代じゃないでしょう」 勉強会の懇親会やSNSで、こんな声を耳にしたことはないでしょうか。フレームワークは古い、重い、アジャイルと相性が悪い、ドキュメントを量産するだけ――。言われてみると、なんとなく頷きたくなる気もします。 今回は、EAWheelに掲載されたEric Jager氏のブログ「Why Architecture Frameworks Matter（なぜアーキテクチャフレームワークが重要なのか）」を題材に、この「フレームワーク不要論」を、Iasa日本支部なりに少し面白がりながら検証してみます。 ※本稿は原記事を要約・解釈し、Iasa日本支部の視点を加えたものです。正確な内容は原記事を参照してください。 会議でいちばん大きな声は、たいてい経験者の声ではない 原記事はいきなり核心を突きます。フレームワーク批判は自信たっぷりに語られるが、フレームワークを長年うまく使ってきた人から出てくることはめったにない。多くは「部屋の中でいちばん声の大きい人」――まずい導入に振り回された人や、誰かの意見を受け売りしている人――から出てくるという...

アーキテクチャの設計や意思決定には、常に「不確実性（リスク）」がつきまといます。技術選定、非機能要件、移行方式、体制やスケジュール――どの判断にも、多かれ少なかれリスクが潜んでいます。本コラムでは、BTABOKの「Risk Methods」を手がかりに、アーキテクトがリスクとどう向き合うべきかをご紹介します。 はじめに 私たちは日常生活のなかでも、道路を渡るとき、はしごを登るとき、あるいは投資をするときに、無意識のうちにリスクを判断し、意思決定を行っています。多くの場合、それはほとんど無意識に行われており、自分がリスクを扱っていると認識することさえありません。 アーキテクトの仕事も、これと本質的には変わりません。異なるのは、その一つひとつの判断が、組織や顧客の事業価値に直接影響を及ぼすという点です。BTABOK（Business Technology Architecture Body of Knowledge）では、リスクを「回避すべき障害」ではなく、「アーキテクチャの意思決定を支える重要な要素」として位置づけています。 本コラムは、GRC（ガバナンス・リスク・コンプライアン...

生成AIに質問し、文章やプログラムを作ってもらう。こうした使い方は、すでに特別なものではなくなりました。ではAIが質問に答えるだけでなく、社内規程を調べ、データを確認し、複数のシステムを操作し、処理結果まで記録するようになったら、私たちの仕事はどう変わるのでしょうか。 この問いを考えるヒントになるのが、Iasa Globalが発行するArchitecture & Governance Magazineの「Agentic Process Transformation: A CIO Perspective」です。本稿では、このコラムが提示するAgentic Process Transformation（以下、APT）のエッセンスを、若手アーキテクトにも身近な言葉で紹介します。本稿は原記事および提供された日本語訳をもとに要約・解釈したものです。詳しくは原記事を参照してください。 「答えるAI」から「仕事を進めるAI」へ APTとは、自律型または半自律型のAIエージェントが、業務の最初から最後まで参加できるように、ビジネスプロセスを再設計することです。...

昨年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の公式アナウンスでは「強いユーザーレベルの互換性を持ちながら、前のバージョンからスムーズに移行でき...

Iasaの知識体系であるBTABoKにおいて、アーキテクチャの「Operating Model（運用モデル）」は非常に重要な位置を占めています。その中でも、今回取り上げる「Tools（ツール）」の章は、一見するとソフトウェアの選定ガイドのように見えますが、実はアーキテクトの本質的な「構え」を問う内容になっています。 1. BTABoKが定義する「ツール」の真意 多くの組織で「アーキテクチャ・ツールを導入しよう」という話になると、すぐに「どの製品（EAMツールやモデリングソフト）を買うか」という議論になりがちです。しかし、BTABoKの定義はもっと広義です。 BTABoKでは、ツールを「技法（Techniques）」と「デバイス（Devices）」の両方であると定義しています。つまり、高価なモデリングソフトだけでなく、ホワイトボードの前で行うワークショップや、意思決定のためのフレームワークそのものが「ツール」なのです。 ここで強調されているのは、ツールの目的は「資産の記録」ではなく、「複雑な構造を可視化し、ステークホルダーとの合意形成を加速させること」にあります。 2....