「アーキテクチャフレームワーク？ もうそういう時代じゃないでしょう」 勉強会の懇親会やSNSで、こんな声を耳にしたことはないでしょうか。フレームワークは古い、重い、アジャイルと相性が悪い、ドキュメントを量産するだけ――。言われてみると、なんとなく頷きたくなる気もします。 今回は、EAWheelに掲載されたEric Jager氏のブログ「Why Architecture Frameworks Matter（なぜアーキテクチャフレームワークが重要なのか）」を題材に、この「フレームワーク不要論」を、Iasa日本支部なりに少し面白がりながら検証してみます。 ※本稿は原記事を要約・解釈し、Iasa日本支部の視点を加えたものです。正確な内容は原記事を参照してください。 会議でいちばん大きな声は、たいてい経験者の声ではない 原記事はいきなり核心を突きます。フレームワーク批判は自信たっぷりに語られるが、フレームワークを長年うまく使ってきた人から出てくることはめったにない。多くは「部屋の中でいちばん声の大きい人」――まずい導入に振り回された人や、誰かの意見を受け売りしている人――から出てくるというのです。 「声の大きい人の意見が通る会議」。日本の職場でも、どこかで見た光景ではないでしょうか。 原記事の主張はシンプルです。フレームワークはアーキテクチャそのものでも、アーキテクトそのものでもない。アーキテクトが仕事をより一貫して進められるよう「支援する」実践知の集まりにすぎない。筆者はわざわざ「支援する（helps）」という言葉に注意を促しています。万能薬を期待して裏切られたのなら、問題はフレームワークより期待のほうにあったのかもしれません。 あなたの職場の「隠れフレームワーク度」チェック ここで少し、あなたの職場を診断してみましょう。次のうち、いくつ当てはまりますか。 • □ 設計判断を記録するExcelテンプレートがある（ファイル名は「決定事項_最新_v3_修正版」） • □ 月に一度、「アーキテクチャレビュー」と呼ばれる会議がある • □ 共有フォルダのどこかに「当社技術標準.pptx」が眠っている • □ 「その製品を使うなら○○部長の承認が要る」という暗黙のルールがある • □ 新しいシステムを作るとき、なぜか毎回同じ構成図の雛形から描き始める 3つ以上当てはまったら、おめでとうございます。あなたの組織はすでにアーキテクチャフレームワークを運用しています。名前と説明書がないだけです。 これこそ原記事が指摘する皮肉です。「うちはフレームワークを使っていない」と胸を張る組織ほど、テンプレート、レビュー会議、原則、標準、役割分担……と少しずつ積み上げ、数年後には自前のフレームワークを完成させている。原記事の言葉を借りれば、既存のものをテーラリングする代わりに、「再発明」する道を選んだだけなのです。 車輪も橋も、ゼロから発明しなくていい 原記事は橋の建設を例に挙げます。橋を架けてほしいと頼まれて、過去100年分の工学の知見を「古いから」と無視する技術者はいません。まず実績ある工法を学び、何がうまくいき何が失敗したかを知ったうえで、目の前の川に合わせて工夫するはずです。 アーキテクチャも同じです。私たちより前に、何千人ものアーキテクトが似た課題にぶつかってきました。TOGAF® Standardのようなフレームワークは、その集合知を「構造化された出発点」として提供してくれます。 原記事がうまいのは、「フレームワークを使うことは創造性を捨てることではない」と言い切る点です。繰り返し出てくる定型的な問いをフレームワークに任せられるからこそ、アーキテクトは自社ならではの課題に頭を使える。競争優位は、ガバナンスの手法を独自に発明することではなく、アーキテクチャをうまく実践することから生まれる。レビュー会議の運営方法を自社で一から発明しても、残念ながら株価は上がりません。 フレームワークはビュッフェである とはいえ、フレームワークの分厚い目次を見て「これを全部やるのか」と青ざめた経験のある方も多いでしょう。原記事は、それこそが最大の誤解だと言います。書かれていることを文字どおり全部やる必要はない。フレームワークはもともと、組織に合わせて仕立て直す（テーラリングする）ことを前提に作られている、と。 たとえるなら、フレームワークはビュッフェです。並んでいる料理を全部お皿に載せる人はいません（たまにいますが、たいてい後悔しています）。多国籍銀行と地域の医療機関、スタートアップと政府機関では、必要な料理がまるで違います。 原記事によれば、導入に失敗した組織の多くは「自分たちに本当に必要なものは何か？」ではなく、「どうすれば全部を実装できるか？」と問うてしまった。その結果手に入ったのはアーキテクチャではなく、官僚主義だった。悪いのは料理ではなく、取り方だったのです。 アーキテクトの「指差し確認」 どんなに小さな変革でも、業務プロセス、アプリケーション、データ、テクノロジー、セキュリティ、コンプライアンス、ステークホルダー、予算、リスク、依存関係……が絡み合います。どれほどのベテランでも、締め切りに追われていれば何かを忘れます。人間ですから。 そして原記事は、取り組みがつまずく原因の多くは「何かを間違えた」ことではなく、「何かをやっていなかった」ことだと指摘します。主要なステークホルダーに話を聞いたのが設計完了後だった。プロジェクト間の依存関係に気づくのが遅すぎた。目標アーキテクチャは美しかったが、組織の受け入れ準備ができていなかった。痛い失敗ほど、基本的なことの見落としから生まれるのです。 日本の鉄道や工場の現場には「指差し確認」という優れた習慣があります。ベテランの運転士でも、信号を指差して声に出す。未熟だからではなく、熟練者でも見落とすことを知っているからです。原記事が医師のガイドラインやパイロットのチェックリストを引き合いに出すのも、同じ理由でしょう。フレームワークは、アーキテクトにとっての指差し確認なのだと思います。 ここで大事なのは、筆者が「成果物のチェックリスト」ではなく「考慮すべきことのチェックリスト」だと強調している点です。アーキテクチャの良し悪しは、成果物の枚数ではなく、それが支える意思決定の質で測られる。成果物の厚さで評価されるなら、最強のアーキテクトは電話帳ということになってしまいます。 ガバナンスは「ハンコリレー」ではない 「ガバナンス」ほど評判を落とした言葉も珍しい、と原記事は嘆きます。承認委員会、長い会議、終わらない申請書類。日本の読者なら、承認印が何人もの机を巡る「ハンコリレー」を思い浮かべるかもしれません。 しかし原記事によれば、ガバナンスの本質はいくつかの基本的な問いに答えることにすぎません。 • 誰が、どの意思決定をする権限を持つのか • その決定をどう評価するのか • 決定が組織の目標と合い続けていることを、どう確かめるのか • 過去の決定から、どう学ぶのか ガバナンスは「ノー」と言う係ではなく、組織が自信を持って「イエス」と言えるようにする仕組み。以前のコラム「Extended Team」で紹介した、BTABoKの「Yes」を基盤とした文化とも重なる考え方です。また、決定の理由を残しておけば、担当者が異動しても知見は消えません。これは「BTABoK Decisions」の回で取り上げたADR（アーキテクチャ決定記録）の狙いそのものです。 設計するのは、フレームワークではなくあなた 原記事は「フレームワークはイノベーションを阻害する」という批判にも反論します。むしろ不要な不確実性を取り除き、イノベーションのための安定した土台になる、と。 フレームワークがアーキテクチャを設計するのではありません。設計するのはあなたです。フレームワークが組織の課題を解決するのでもありません。解決するのはあなたです。フレームワークは経験の代わりにはならず、経験がより大きな効果を発揮できるよう後押しするものだ、と原記事は語ります。 そして結びは、フレームワークは「目的地」ではなく「地図」だという言葉です。カーナビにたとえるなら、目的地を入力するのはあなたで、工事中の道を見て迂回を決めるのもあなた。それでも、地図なしで知らない街を走るよりは、ずっと遠回りが減るはずです。 まずは次の設計判断から 「フレームワークを導入しよう」と構えると大仕事ですが、次の設計判断で、次の3つを自問するところから始められます。 1. この判断で生み出したいビジネス上の価値は何か 2. まだ話を聞いていない関係者、見落としている影響はないか（指差し確認） 3. 誰が決め、何を根拠にし、後でどう見直すか もう一つ、ぜひ試していただきたいのが、自分の組織の「名前のないフレームワーク」の棚卸しです。共有フォルダに眠るテンプレートや暗黙のルールを並べて、既存のフレームワークと見比べてみる。足りないもの、やりすぎているものが、意外なほどはっきり見えてくるかもしれません。 ＊＊＊ フレームワーク不要論の多くは、実はフレームワークそのものではなく、「全部盛り」の導入や「ハンコリレー」型のガバナンスへの不満なのかもしれません。原記事が描く成功するアーキテクトは、テーラリングし、シンプルにし、状況に合わせ、そして「フレームワークは組織に奉仕するためにあり、その逆ではない」と理解している人たちです。 フレームワークを「守るべき聖典」にするのでも、「時代遅れの遺物」として捨てるのでもなく、現場の判断を少し良くするための地図として使いこなす。皆さんの組織の地図は、いまどんな状態でしょうか。 Iasa日本支部では、情報交換や勉強会の場を設けています。フレームワークとの付き合い方について、皆さんの工夫や悩みもぜひお聞かせください。Iasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。 参考 Eric Jager, “Why Architecture Frameworks Matter,” EAWheel, September 28, 2026 https://eawheel.com/blog/2026/09/why-architecture-frameworks-matter/ 「BTABoK Decisions ～ AI時代のアーキテクチャ意思決定 ～」Iasa日本支部 https://www.iasa-japan.org/post/btabok-decisions-ai-era 「BTABoK：Extended Team ～拡張チームで実現するデジタル変革～」Iasa日本支部 https://www.iasa-japan.org/post/btabok-extended-teams 「BTABoK / Tools ～「ツール」に使われるアーキテクトか、ツールを「武器」にするアーキテクトか ～」Iasa日本支部 https://www.iasa-japan.org/post/btabok-tools

アーキテクチャの設計や意思決定には、常に「不確実性（リスク）」がつきまといます。技術選定、非機能要件、移行方式、体制やスケジュール――どの判断にも、多かれ少なかれリスクが潜んでいます。本コラムでは、BTABOKの「Risk Methods」を手がかりに、アーキテクトがリスクとどう向き合うべきかをご紹介します。 はじめに 私たちは日常生活のなかでも、道路を渡るとき、はしごを登るとき、あるいは投資をするときに、無意識のうちにリスクを判断し、意思決定を行っています。多くの場合、それはほとんど無意識に行われており、自分がリスクを扱っていると認識することさえありません。 アーキテクトの仕事も、これと本質的には変わりません。異なるのは、その一つひとつの判断が、組織や顧客の事業価値に直接影響を及ぼすという点です。BTABOK（Business Technology Architecture Body of Knowledge）では、リスクを「回避すべき障害」ではなく、「アーキテクチャの意思決定を支える重要な要素」として位置づけています。 本コラムは、GRC（ガバナンス・リスク・コンプライアンス）の用語を網羅的に解説するものではありません。あくまで、アーキテクチャに関わる実践的なリスク手法の要点を、皆さまと共有することを狙いとしています。それでは、内容を見ていきましょう。 1. リスクとは何か（What is Risk） 「将来のある時点で悪いことが起こる可能性。危険を伴う、あるいは悪い結果をもたらしうる状況」 ― リスクの定義（オックスフォード辞典） ほとんどの事業活動や行動には、何らかのマイナスの影響が生じる可能性が伴います。リスクとは、もし顕在化した場合に、組織や個人にとって望ましくない結果をもたらすものを指します。 リスクの良い点は、結果が出る前に「識別」できるということです。事前に把握できるからこそ、対策を講じ、その影響を抑える機会が生まれます。アーキテクチャの取り組みにおいても、リスクを適時に識別し、適切なアクションで対処することが特に重要になります。 リスクを評価する3つの側面 アーキテクトがリスクの優先度と重大性を見極める際には、次の3つの側面が手がかりになります。 側面 英語表記 意味 発生可能性 Probability リスクが顕在化する「起こりやすさ」 結果（影響度） Consequence リスクが顕在化した場合の「結果の深刻さ」 軽減策 Mitigation 発生可能性や結果を「低減するために取りうる手段」 なお、一度顕在化したリスクは、もはやリスクではなく、現実の「課題（issue）」や「問題（problem）」になります。この違いを意識することは、リスク管理と課題管理を混同しないうえで重要です。 2. なぜリスクを管理する必要があるのか（Why do we need to Manage Risk） リスクはアーキテクチャ開発における意思決定に影響を与えるため、識別し、管理することが不可欠です。リスクを認識していれば、複数の代替案を前にしたときに、アーキテクトはより適切な判断を下すことができます。 リスクの識別と管理は、結果を予見し、悪影響を軽減するための行動を先回りして取ることを可能にします。また、多くのリスクは複数のステークホルダーに関係するため、彼らと協働して対処する必要があります。アーキテクトがリスクを管理し、他のステークホルダーへ伝達することは、見えていなかった影響、さらには新たな機会を明らかにすることにもつながります。 一方で、法律・政府・規制の変更など、組織の外部要因に起因するリスクは軽減が極めて困難な場合があります。しかしそうしたリスクについても、アーキテクトと組織がその存在を認識し、顕在化した場合に備えて計画を用意しておくことが重要です。 リスクは戦略・戦術、そしてアーキテクチャに波及する リスクは戦略と戦術に影響し、それがアーキテクチャに影響します。かつては許容できていたリスクが、状況の変化によって、あっという間に許容できないリスクに変わることがあります。その結果、戦術や戦略の変更が必要となり、標準技術の変更などを通じてアーキテクチャに大きな影響を及ぼすことになります。だからこそリスク管理は一度きりの作業ではなく、アーキテクチャのライフサイクルを通じて継続的に見直すべき営みなのです。 3. アーキテクチャにおける主要なリスク手法（Key Risk Methods） BTABOKは、アーキテクチャに関わる「主要なリスク手法」に焦点を当てています。前述の3つの側面（発生可能性・影響度・軽減策）を軸に、アーキテクトが実務で用いる一連の流れを整理すると、次のようになります。 リスクの識別（Identification）：意思決定や代替案の検討にあたり、どのような不確実性が潜んでいるかを、結果が出る前に洗い出す。 リスクの分析・評価（Analysis）：識別したリスクを「発生可能性」と「結果の深刻さ」の観点で評価し、優先度と重大性を見極める。 リスクの軽減（Mitigation）：発生可能性または影響度を低減する手段を検討・実行する。軽減が難しい外部要因のリスクには、顕在化に備えた計画を用意する。 監視とコミュニケーション（Monitoring & Communication）：許容したリスクも状況変化で許容できなくなり得るため継続的に監視し、関係するステークホルダーと共有・協働して対処する。 これらの手法は、GRCの専門用語を網羅することではなく、アーキテクチャの意思決定に直結するリスクを、実務のなかで扱えるようにすることを目的としています。 おわりに リスク管理というと、どうしても「問題を未然に防ぐための守りの活動」と捉えられがちです。しかしBTABOKが示すのは、より前向きな姿勢です。リスクを早期に識別し、発生可能性・影響度・軽減策の観点で評価し、ステークホルダーと共有することは、悪影響を抑えるだけでなく、見過ごされていた機会を見いだし、より良いアーキテクチャの意思決定を導く力になります。 そして忘れてはならないのは、リスクは顕在化した瞬間にリスクではなくなり、現実の課題へと姿を変えるという事実です。だからこそ、まだリスクである「今」こそが、アーキテクトにとって最も価値ある行動のタイミングだと言えるでしょう。 日々のプロジェクトのなかで、次の意思決定を前にしたとき、ぜひ一度立ち止まって問いかけてみてください――「このリスクの発生可能性はどれくらいか」「顕在化したら何が起きるか」「今、何ができるか」。その小さな習慣の積み重ねが、アーキテクチャの品質と、組織への貢献を確かなものにしていきます。良いアーキテクチャとは、どのリスクを取り、どのリスクを抑えるのかが、意識的に意思決定されているアーキテクチャなのです。 本コラムが、会員の皆さまの日々の実践において、リスクと向き合うための一助となれば幸いです。最後までお読みいただき、ありがとうございました。Iasa日本支部では、情報交換や勉強会の場を設けています。ぜひIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

生成AIに質問し、文章やプログラムを作ってもらう。こうした使い方は、すでに特別なものではなくなりました。ではAIが質問に答えるだけでなく、社内規程を調べ、データを確認し、複数のシステムを操作し、処理結果まで記録するようになったら、私たちの仕事はどう変わるのでしょうか。 この問いを考えるヒントになるのが、Iasa Globalが発行するArchitecture & Governance Magazineの「Agentic Process Transformation: A CIO Perspective」です。本稿では、このコラムが提示するAgentic Process Transformation（以下、APT）のエッセンスを、若手アーキテクトにも身近な言葉で紹介します。本稿は原記事および提供された日本語訳をもとに要約・解釈したものです。詳しくは原記事を参照してください。 「答えるAI」から「仕事を進めるAI」へ APTとは、自律型または半自律型のAIエージェントが、業務の最初から最後まで参加できるように、ビジネスプロセスを再設計することです。 AIエージェントは、単にプロンプトへ回答するだけではありません。目標を理解して仕事を分解し、必要な情報を検索し、業務システムやツールを呼び出します。情報が足りなければ人に確認し、リスクの高い判断は人へ戻し、経緯を記録しながら仕事を進めます。 たとえば出張規程について、チャットボットは「宿泊費の上限は1泊1万5千円です」と答えるでしょう。一方、エージェント型の仕組みであれば、規程を読み、申請者や出張先を確認し、申請額を照合し、申請データを作り、承認者へ回付し、承認後に記録システムを更新するところまで進められます。 原記事は、この変化を「タスクの自動化から、アウトカムのオーケストレーションへ」と表現しています。個々の作業を速くするだけでなく、成果に向けて仕事の流れ全体を動かす。ここに、従来のRPAやチャットボットとの違いがあります。 AIを載せるのではなく、仕事を組み直す 既存の業務にAIエージェントをそのまま載せればAPTになるのでしょうか。原記事の答えは明確です。古いプロセスの上にAIを置くだけでは、APTにはなりません。 たとえば買掛金管理では、AIエージェントが請求書を読み、発注書と照合し、支払案を作れます。しかし、高額な支払い、取引先マスターの変更、重複請求の疑い、規程外の例外までAIに任せてよいとは限りません。これらは人間の承認者へ回すべきでしょう。 アーキテクトが設計するのはAIモデル単体ではありません。「どこをAIに任せるか」「どこで人が確認するか」「例外時は誰へ戻すか」「最後に誰が責任を持つか」という境界です。 この境界を設計して初めて、プロセスは「速いが無謀ではない」ものになります。APTの本質は、AIによる人の置き換えではなく、人とAIエージェントの協働を前提に仕事を組み直すことなのです。 アーキテクトが押さえたい3つのポイント 原記事ではCIO向けに6段階のフレームワークが示されています。ここでは、アーキテクトの視点から3つに絞ります。 1．AIではなく、ビジネス成果から始める 出発点はモデル選定ではありません。処理時間、コスト、品質、顧客体験、リスクなど、何を変えたいのかを先に定めます。「最新のAIを使う」では成功を測れません。「精算時間を50％短縮する」のように、AIエージェントの行動と測定可能な価値を結びつけます。 対象には、手作業、待ち時間、部門間の受け渡し、反復判断、例外処理が多い業務が向いています。ただし、価値だけでなく、データの準備度やリスクも見なければなりません。 2．信頼できる情報と、安全な「手足」を用意する AIエージェントの信頼性は、利用する情報とツールの信頼性を超えられません。古い文書を大量に読ませるだけでは、業務で信頼できる仕組みにはなりません。情報の版管理やアクセス制御、訂正の仕組みが必要です。 また、申請の作成、レコードの更新、メール送信など、AIエージェントが使う「手足」は、安全なAPIと明確な権限を通じて提供する必要があります。原記事の重要な指摘は、「エージェントはシステム全体ではなく、ガバナンスされたアーキテクチャの一つの層にすぎない」という点です。 3．自律性を段階的に高める 自律性は、ゼロか100かではありません。原記事では、要約や推奨を行うレベル1から、人の承認を前提に実行案を作るレベル2、低リスクの操作を自律実行するレベル3、例外時だけ人が監督するレベル4、統制された領域で広く自律するレベル5までを示しています。 いきなりレベル5を目指すのではなく、実績と評価結果を積み上げ、得られた信頼に応じて自律性を高めます。「どこまでAIに任せるか」そのものが、重要なアーキテクチャ意思決定なのです。 ガードレールもアーキテクチャである AIが回答するだけなら、出力を人が確認すれば、多くのリスクを抑えられます。しかしAIエージェントがシステムを操作するなら、入力、判断、実行、記録までのループ全体を制御しなければなりません。 エージェントごとのIDと最小権限、高リスク時の人の承認、操作と判断の監査証跡、継続的な評価などが必要です。「プロンプトに禁止事項を書けば安全になる」わけではありません。権限、API、承認、監視を含む多層の仕組みとして安全性を設計することも、アーキテクトの役割です。 APTは「EA 2.0」への入口になるか APTを読み解くと、AI時代にもエンタープライズアーキテクチャ（EA）が重要であることが分かります。 ビジネスアーキテクチャは成果とプロセスを定義し、データアーキテクチャは信頼できる情報を整え、アプリケーション／統合アーキテクチャはAPIやツールの境界を設計します。テクノロジー／セキュリティアーキテクチャは、ID、権限、監視、実行基盤を支えます。 従来のEAが業務・データ・アプリケーション・テクノロジーの「構造」を可視化してきたとすれば、APTはそこに「誰が判断し、誰が行動し、どう学習するか」という動的な設計を加えます。この意味でAPTは、AI時代のEA、いわば「EA 2.0」を考える入口になり得るのではないでしょうか。 BTABoKで重要視されるアーキテクトの「意思決定」や、「拡張チーム」を中心とした組織のあり方もここにつながります。AIの自律性や権限は、記録・検証すべきアーキテクチャ意思決定です。またAPTは、業務、開発、データ、セキュリティ、法務、運用などを含むチームで取り組む必要があります。 まず一つの業務から 大規模なAI基盤がなくても、APTの検討は始められます。まず身近な業務を一つ選び、次の4点を書き出してみてください。 • 最終的に生み出したい成果 • 待ち時間、引き継ぎ、反復判断、例外が生じる場所 • 「AIが支援」「AIが実行」「人が判断」の分担 • AIを人へ戻す条件と、判断・操作の記録方法 「どこにAIを入れるか」ではなく、「どこで仕事が滞り、判断や例外処理が必要になるか」から考えることがポイントです。AIに何を任せ、何を任せないのか。これを関係者と合意できる形にすることが、これからのアーキテクトの仕事になります。 まとめ APTは、新しいAI技術の名前というより、人、システム、データ、意思決定を横断して、仕事の流れを再設計する考え方です。 原記事が最後に投げかけるのは、AIエージェントが企業に入るかどうかではありません。それが「断片的な実験」として入るのか、それとも自律性を安全で有用な価値へ変える「信頼できるオペレーティングモデル」を通じて入るのか、という問いです。 これはCIOだけでなく、これからのアーキテクト一人ひとりへの問いでもあります。まずは身近な業務を一つ取り上げ、人とAIの新しい協働の姿を描いてみてはいかがでしょうか。 最後までお読みいただき、ありがとうございました。 Iasa日本支部では、情報交換や勉強会の場を設けています。ぜひIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。 参考 Magesh Kasthuri, “Agentic Process Transformation: A CIO Perspective,” Architecture & Governance Magazine, July 9, 2026 https://www.architectureandgovernance.com/applications-technology/agentic-process-transformation-a-cio-perspective/ 「BTABoK Decisions ～ AI時代のアーキテクチャ意思決定 ～」Iasa日本支部 https://www.iasa-japan.org/post/btabok-decisions-ai-era 「BTABoK：Extended Team ～拡張チームで実現するデジタル変革～」Iasa日本支部 https://www.iasa-japan.org/post/btabok-extended-teams

昨年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日本支部のコミュニティ活動については、毎月発行のメールマガジンやホームページでお知らせしております。多くの方のご参加をお待ちしております。

要旨（Abstract） 本稿は、Iasaが公開するBTABoK（Business Technology Architecture Body of Knowledge）を参照枠組みとして、情報システム開発におけるITアーキテクチャ策定活動を『価値』『人』『運用』『成果』の観点から整理し、生成AI（大規模言語モデル：LLM）および、知覚→推論→行動→学習の循環を持つAgentic AI（エージェンティックAI）が、どの工程で有効に機能しうるかを具体的な利用シーンとともに示します。さらに、BTABoKの4フェーズ（Imagine/Become/Achieve/Maximise）とAgentic AIの4サイクル（Perceive/Reason/Act/Learn）を対応付けた『BTABoK×Agentic AI対応マップ（筆者整理）』を提示し、導入時に不可欠となるガバナンス設計（責任境界・検証・監査可能性）を論じます。 キーワード BTABoK, ITアーキテクチャ, 生成AI, 大規模言語モデル（LLM）, Agentic AI, エンゲージメントモデル, ガバナンス, 検証 １．はじめに 生成AI（大規模言語モデル：LLM）の普及により、要件解釈、意思決定資料の作成、設計レビュー、ドキュメント整備といった、アーキテクトの主要業務において、要約・分類・比較・文章化といった言語処理を業務へ組み込むことが現実的になってきました。一方で、LLMは確率的生成である以上、誤りや曖昧さを含む出力を返し得ます。そのため、アーキテクチャ策定に適用する際には、入力根拠の明示、検証プロセス、責任境界（RACI/権限）を運用設計として組み込むことが不可欠です。注 2 本コラムでは、ITアーキテクトの知識体系であるBTABoK（Business Technology Architecture Body of Knowledge）を参照枠組みとして、情報システム開発におけるITアーキテクチャ策定プロセスの中で、LLMおよびAgentic AIが有効と思われる領域と具体的な利用シーンを整理します。 ２．BTABoKの概要とエンゲージメントモデル（4フェーズ） BTABoKのエンゲージメントフレームワークは、Deming/ShewhartのPDCAに基づく循環モデルとして4フェーズに分割され、Imagine（Digital Customer）→Become（Digital Business）→Achieve（Digital Employee）→Maximise（Digital Operations）として説明されます。注 1 また、エンゲージメントモデルは、中心にアーキテクチャロールを置き、その周囲に People / Value / Operating / Outcomes の4サブモデルを配置して、概念形成から価値実現までをライフサイクルとして扱います。注 2 ３．ITアーキテクチャ策定における生成AI（LLM）の有効領域 BTABoKの活動を『価値』『人』『運用』『成果』の観点で捉えると、LLMは特に次のような領域で効果を発揮します。 表1　BTABoK観点別：LLM活用タスク（例） BTABoK観点 LLMに任せる作業（例） アーキテクトが担う判断・検証 Value（価値） 価値仮説の言語化、ビジネスケースの要約、代替案の比較観点生成 投資対効果/リスク/制約の妥当性確認、意思決定責任 People（人） ステークホルダー論点整理、コミュニケーション計画草案、役割定義案 利害調整、責任境界（RACI）の確定 Operating（運用） 要求/ASR抽出、トレーサビリティ表（RTM）草案、ADRドラフト、レビュー観点提示 要件の真正性、合意形成、設計トレードオフ最終判断 Outcomes（成果） KPI候補抽出、測定設計案、運用データの要約/傾向分析 指標の有効性、組織目的との整合、改善施策の優先度 たとえば、Traceability（VM-T）は、ビジネスゴールからアウトカム、要求、意思決定へ価値を紐付けて追跡する方法として定義されています。注 3 またRequirements（OM-R）では、要求をソースから最終アウトカムまで追跡し、RTMにより『満たす/満たさない』も含めて文書化することが求められます。注 4 ４．Agentic AI：知覚→推論→行動→学習サイクルと外部ツール連携 Agentic AIは、知覚（Perceive）→推論（Reason）→行動（Act）→学習（Learn）の循環を持ち、LLMを中核に外部ツール（検索、API、実行基盤など）と連携して、複数ステップのタスクを自律的に実行できる点が特徴です。一方、企業利用では『検証（validity）』—出力が要件・制約・規制・運用現実に照らして正しいこと—を担保する仕組みが成功要因となります。注 8 ５．BTABoK × Agentic AI対応マップ BTABoKの4フェーズとAgentic AIの4サイクルを対応付けることで、各局面で『何を観測し、何を推論し、何を実行し、何を学習として残すか』を議論しやすくなります。注 1 表2　BTABoK × Agentic AI対応マップ 知覚（Perceive） 推論 （Reason） 行動 （Act） 学習 （Learn） Imagine（Digital Customer） 顧客/市民の課題信号収集（VoC/ログ/調査） 価値仮説・顧客旅程コンセプト評価 探索プロトタイプ情報収集の自動化（検索/RAG） 仮説検証結果の知識化（メモリ）次の探索へ Become（Digital Business） 業務/能力の現状把握制約・前提収集 ビジネスケース代替案比較リスク整理 意思決定資料作成ロードマップ草案合意形成支援 KPI/指標の設計・更新判断基準の学習 Achieve（Digital Employee） 要求/ASR・ステークホルダー入力の観測 アーキ判断トレードオフ品質特性分析 設計成果物整備ADR/レビューテスト生成 利用状況・不具合傾向改善ループへ反映 Maximise（Digital Operations） 運用データ/変更要求監視・検知 影響分析優先度付けガードレール 自動化/DevOpsドキュ更新ツール実行 計測→改善技術的負債の最適化   ６．具体的な利用シーン （1）要求・制約・ASR抽出とトレーサビリティ 要件定義では、自然言語の要求からアーキテクチャ上重要な要求（ASR: Architecturally significant requirements）や制約を抽出し、ソース→要求→意思決定→成果物→測定指標へとトレース可能にすることが重要です。LLMは、会議メモ・RFP・既存仕様から要求候補を抽出し、要求分類（機能/非機能/制約/規制）や論点の抜け漏れチェックリストを生成できます。一方で、要求の真正性（誰が言ったか、合意されたか）と優先順位づけ・採否判断は、最終的に人間側が責任を持つ必要があります。注 4 （2）代替アーキテクチャ案生成とトレードオフ分析 BTABoKでは、最初に提示された解が必ずしも最適とは限らない前提で、代替案比較と意思決定支援を重視します。LLMは、同一の要求集合に対して複数の構造案を提示し、品質特性（性能、可用性、セキュリティ、運用性など）の観点で差分を説明する用途に適します。ただし、品質特性のトレードオフは組織の優先度と制約に依存するため、結論はアーキテクトが根拠（測定計画・運用条件・規制等）とともに提示することが必要です。 （3）設計成果物（ADR/レビュー資料）自動整備と検証 設計の価値は図そのものではなく、なぜその判断に至ったか（理由・根拠・前提・代替案）にあります。LLMは、レビュー観点の体系化、アーキテクチャ決定の記録であるADR（Architecture Decision Record）への落とし込み、差分要約などの“文書化”に強みがあります。さらにAgentic AIとして、変更検知→影響範囲推論→関連ドキュメント更新→テスト/静的解析結果の取り込み、といった整合性維持を支援できます。注 5 （4）運用データを用いた継続的改善（Measurement/Learn） Maximise（Digital Operations）の局面では、運用監視データ、インシデント記録、問い合わせ、性能指標などが『知覚』の入力となります。Agentic AIは、異常兆候の要約、一次切り分けの支援、既知手順の提案、必要に応じたチケット起票などを連鎖的に実行できます。ただし、マルチステップのタスクでは誤りが複合化しうるため、重要操作の前段に検証と人間承認を置き、段階的に自動化範囲を拡張するのが実務的です。注 7 注 8 ７．ガバナンス設計（責任境界・検証・監査可能性） Agentic AIは『行動（Act）』を伴うため、単なる文章生成よりもガバナンスの要求水準が上がります。そのため導入時には、(a)誰が何に責任を持つか（RACI）、(b)どの入力を根拠とするか（データ境界）、(c)どの検証を通過したら実行可能か（validity gate）、(d)監査可能なログ（入力・出力・差分・承認）をどこに残すか、をアーキテクチャとして明示する必要があります。注 6 注 8 ８．おわりに BTABoKは、価値創出に結びつくアーキテクト活動を体系化し、個の実践を組織能力へ接続する枠組みです。生成AI/Agentic AIはその活動を加速し得ますが、LLM出力の不確実性を前提に、検証・承認・監査可能性を設計しなければ組織的リスクを増大させます。本稿の対応マップとサブモデル別整理を起点に、Iasa日本支部コミュニティで実践知（パターン／失敗学）を蓄積し、読者の現場に適用できる形で共有していくことが重要です。 ご一読いただきありがとうございました。Iasa日本支部では情報交換や勉強会の場を設けており、アーキテクチャの実践的な活動についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。     脚注（BTABoK記載場所） 注1：BTABoK Engagement Frameworkの4フェーズ（Imagine/Become/Achieve/Maximise）とPDCA由来の循環モデルについて：  - Iasa Global, BTABoK Dictionary 2 - Framework – Outcome Phases and Outcome Spikes    https://iasa-global.github.io/btabok/dictionary.html#2---framework--outcome-phases-and-outcome-spikes - Iasa 日本支部  コラム, BTABoKが拓くアーキテクチャ実践の新時代   https://www.iasa-japan.org/post/new-era-of-architecture-practice 注2：エンゲージメントモデルがPeople/Value/Operating/Outcomesの4サブモデルで構成され、中心にアーキテクチャロールを置く構造について： -Iasa 日本支部  コラム, BTABoK Engagement Model（６）～エンゲージメントモデルでバリューストリームの実現を～ https://www.iasa-japan.org/post/valuestreamswithengagementmodels -Iasa Global. BTABoK Engagement Models    https://iasa-global.github.io/btabok/engagement_models_m.html 注3：Traceability（VM-T）の定義（価値をアーキテクチャ意思決定へ紐付けて追跡する）について： - Iasa Global, BTABoK Dictionary 6.5 - Traceability (VM-T):    https://iasa-global.github.io/btabok/dictionary.html 注4：Requirementsはソースからアウトカムまでトレースし、RTMで満たす/満たさないも含め文書化する点について： - Iasa 日本支部  コラム, BTABoK：Requirements ～ アーキテクチャ上重要な要求～     https://www.iasa-japan.org/post/btabok-requirements   - Iasa Global, BTABoK Requirements     https://iasa-global.github.io/btabok/requirements.html 注5：設計の価値は成果物そのものではなく、理由・根拠・トレードオフと要求へのトレーサビリティにある点について： - Iasa 日本支部  コラム,  BTABoK Design ～ デザイン（設計）とは何か ～  https://www.iasa-japan.org/post/btabok-design - Iasa Global, BTABoK Operating Model / Design   https://iasa-global.github.io/btabok/design.html 注6：ガバナンス（OM-G）が役割責任、意思決定、標準の監視、証跡（evidence）等を含む点について： - Iasa 日本支部  コラム, BTABoK 　Governance　～ガバナンスとアーキテクチャ～ https://www.iasa-japan.org/post/btabok-governance - Iasa Global. BTABoK Governance    https://iasa-global.github.io/btabok/governance_em.html 注7：MeasurementがKPIを識別しライフサイクルを通じて追跡する点について：  - Iasa Gloval, BTABoK Dictionary 3 - Outcome Spikes     https://iasa-global.github.io/btabok/dictionary.html#3---outcome-spikes 注8：Agentic AIの本質を「検証（validity）」とし、基盤モデル性能よりアプリケーションレベルの検証プロセスが重要という観点： - Chamudi Ezzat, Agentic AIの本質は「検証」である、大規模言語モデルはあくまで選択肢の一つ    https://qiita.com/chamudi/items/10645a56e4709f2b6322   参考文献 - Iasa Global: Business Technology Architecture Body of Knowledge (BTABoK) https://iasa-global.github.io/btabok/ - Iasa Global, BTABoK Engagement Model / Dictionary https://iasa-global.github.io/btabok/tag_engagement_model.html - Iasa日本支部 コラム, アジャイル型システム開発におけるBTABoKの活用について https://www.iasa-japan.org/post/utilizing-btabok-in-agile-system-development - Chamudi Ezzat: 「Agentic AIの本質は『検証』である」（Qiita, 2025-11-03 https://qiita.com/chamudi/items/10645a56e4709f2b6322

最近のシステム開発では、モデリング等の論理設計を省いていきなり実装とテストを繰り返しながらゴールに辿り着くという実装主義が、Z世代にとっては主流になりつつあるようだ。確固たる方法論に基づいた設計ありきの構築をしてきた設計主義のベテランアーキテクトは、この理屈にこだわらない開発手法に取って代わられることに、ある種の喪失感を感じざるを得ない。 この事はテクノロジーの進化によって詳細なロジックをカプセル化する事で、生産性と品質を追求した果てにたどり着くものである。これにより、エンジニアは自ら産み出したプロダクトによって職を失いかねないというジレンマに陥ることになる。とは言え、ことさら古いやり方の良さを吹聴し、技術の進化に対する危険性のみを主張する輩は見苦しい老害と言えよう。絶えず新しいテクノロジーを用いて生産性を追求することはエンジニアの取るべき道筋である。ではシニアアーキテクトは黙ってリタイヤすれば良いのだろうか。 この疑問が生じる背景には、良い道具さえあれば問題が解決するというツール至上主義がある。これが行き過ぎた場合には、ゆるぎないセオリーをも踏み外すことさえある。結果的に試行錯誤を繰り返すあまり、せっかくの自動化もかえって多くの時間とコストを費やしかねない。その典型的な例がAIである。AIは整理整頓が出来ていないビッグデータから高速に整理した結果を出力するパワーを秘めている。過去にセオリーを学んでいない人もそれなりの出力が期待できるので、ロジックを追求する必要は無駄だと考える。しかし、どんな優れたAIもGarbage in Garbage out であり、予期しない結果が出た場合には誤りの箇所を発見することに苦労することになる。 ベテランはこのようなアンチパターンを唯々見過ごすのではなく、嫌がられることを恐れずに優しくアドバイスを与える必要がある。また、一方のZ世代もベテランのアドバイスを鬱陶しいと拒絶するのではなく、時には耳を傾けることが必要である。企業内のIT従事者を30~60歳の従業員と仮定すると、過去30年間でIT従事者はほぼ全てが入れ替わったことになる。この間、IT（情報技術）は劇的な変化を遂げたものの、IS（情報システム）の本質的なロジックは普遍的なものが多い。にも関わらずZ世代の担当者にはISの普遍的ロジックを学ぶ機会が与えられてこなかった。 歴史の浅いIT業界の従事者は本質が変わっていないにも関わらず、道具が変わることで全てを一からやり直すというムダな時間を費やしてきた。これまでベテランが有するセオリーを伝承してこなかったソフトウェア開発も、建築、機械、電気といったハードウェアと同様に、設計図（モデル図）で次世代に継承することが求められる。進化し続けるITを用いたシステム開発は、全てをゼロベースからやり直すのではなく、モデルに立ち戻ることで効率的なリスタートが可能になる。また、根本的にモデルを変えるDXにおいては、なおさら現在のモデルとの対比を明らかにする必要がある。今日、行き過ぎた実装主義に警鐘をならし、論理設計を重視することは、若手、ベテランを問わず考えなければならない大きな課題である。 　Iasa日本支部ではITアーキテクチャに関する情報交換や勉強会の場を設けております。みなさんと一緒にアーキテクチャに関する学びを深めていければと思いますので、是非ともIasa日本支部の活動へのご参加、ご協力をよろしくお願いします。

新年明けましておめでとうございます。2026年、私たちのエンジニアリング環境は、生成AIの急速な進化によって劇的な変化の中にあります。あらゆる仕事の自動化が進み「人でしかやれないこと」との境界線が問われる今、アーキテクトにとって最も重要なテーマは、技術の選択を超えた 「意思決定」の本質 に立ち返ることではないでしょうか。本稿ではアーキテクチャ意思決定をテーマに、グローバルな知見であるBTABOK（Business Technology Architecture Body of Knowledge）を紐解きながら、これからのアーキテクトが担うべき役割を考察します。 参考 IASA Global, BTABoK – Decisions https://iasa-global.github.io/btabok/decisions.html ※本コラムはBTABoKの内容を要約・解釈したものであり、厳密な定義や詳細は原典を参照してください。   ・今なぜ意思決定が主要テーマとなるのか 昨今の生成AIの熱狂は、ソフトウェア開発の風景を一変させました。コード生成からデバッグ、ドキュメント作成に至るまで、AIはプログラマーの強力な代替、あるいは補完として機能し始めています。しかし、DX（デジタルトランスフォーメーション）の本質が「ビジネスモデルの変革」にある以上、真に重要なのは、個々のコードの良し悪しではなく、 「エンタープライズレベルでの重要な意思決定」 です。「AIが全ての判断を代行してくれる」という期待は、現時点では幻想に過ぎません。アーキテクチャ上の決定は、技術的な合理性だけでなく、組織の政治、予算、将来の拡張性、そして人間社会への影響といった複雑な要素が絡み合うからです。AI時代だからこそ、アーキテクトには、自動化できない「責任ある選択」を行う能力がこれまで以上に求められているのです。 ・アーキテクチャ意思決定の３階層モデル アーキテクチャにおける意思決定は、その影響範囲によって以下の3つの階層（スコープ）で捉えることができます。 戦略層（エンタープライズ・エコシステム）：  企業全体や、その顧客・サプライヤーを含むエコシステムに影響を与える決定です。ERPの選択やクラウド戦略、業界標準の採用などがこれに該当し、より低レベルの決定を導く「ガードレール」としての役割を果たします。 戦術層（バリューストリーム・ソリューション）：  複数の製品やサービスを支えるソリューションレベルの決定です。ビジネス価値を生み出すための一連の流れ（バリューストリーム）全体に影響を及ぼします。 実行層（製品・サービス・モジュール）：  特定の製品、あるいはシステムのサブコンポーネント（モジュール）に関する決定です。隣接するサービスには直接影響を与えない、局所的な最適化が含まれます。 アーキテクトは、今自分が行っている決定がどの階層に属し、どの範囲に影響を及ぼすのかを常に意識しなければなりません。重要なのは、これらが独立して存在するのではなく、 連鎖的に影響し合う 点です。上位の意思決定は下位の選択肢を制約し、下位の判断の積み重ねが戦略の成否を左右します。 ・アーキテクチャ意思決定の本質と原則（BTABOKの視点） BTABOKにおいて、アーキテクチャ上重要な決定（ASD: Architecture Significant Decisions）は、マーティン・ファウラーの言葉を借りれば「重要なもの」と定義されます。BTABOKによれば、ASDの目的は決定事項を明確にし、要件や設計の理由、結果と関連付けて追跡可能にすることにあります。 ここでは、アーキテクトが知っておくべき意思決定の原則を、BTABOKに基づき解説します。 ① 意思決定のトレーサビリティ 優れた意思決定には、ビジネスゴールから要件、設計理由、そして最終的な測定に至るまでの 一貫した追跡可能性（トレーサビリティ） が不可欠です。BTABOKでは、決定事項を「アーキテクチャ決定記録（ADR）」としてリポジトリに公開し、誰でも発見・追跡できるようにすることを推奨しています。 ② 認知バイアスとの戦い 意思決定は常に人間の弱さにさらされています。BTABOKでは、 「アンカリング効果」 （最初の情報に引きずられる）、 「確証バイアス」 （自分の意見を裏付ける情報ばかり集める）、 「サンクコストの誤謬」 （過去の投資に執着する）といった認知バイアスが誤った決定の根源になると指摘しています。アーキテクトは客観的なツール（意思決定バイアス校正器など）を用い、バイアスから意思決定を再構築する努力をしなければなりません。 ③ 「最後の責任ある瞬間」を待つ アジャイルな環境において、コードを書く前に全てを確定させる必要はありません。BTABOKは、 「可能な限り選択肢をオープンに保ち、必要な時、あるいは正当な理由がある時までコミットしない」 という原則を提示しています。これは先延ばしではなく、情報が増え、より賢明な判断ができる「最後の責任ある瞬間」まで代替案を保持し続けるという戦略的な忍耐です。 ④ 技術的プロダクトオーナーとしての責任 最終的に、決定が「価値、複雑性、構造的整合性、ステークホルダー」に影響を与える場合、アーキテクトは 「技術的プロダクトオーナー」 として機能すべきです。企業と顧客のために最大の価値を生むトレードオフが行われているかを確認する責任があるのです。 ・これからのアーキテクチャ意思決定モデル AI時代におけるこれからの意思決定モデルは、 「AIによる支援」と「人間による責任」のハイブリッド型 へと進化していくのでしょう。AIは、過去の膨大なデータから類似の事例を提示したり、スコアリング手法における数値計算を補助したりする点では非常に有益です。 しかし、BTABOKが強調するように、意思決定の本質は「ステークホルダーの管理」や「組織のダイナミクスへの対応」にあります。チームを納得させ、フィードバックを反映させ、企業に対する責任を果たすことは、人間にしかできません。 私たちは、AIを「より速く、より正確な情報を得るためのツール」として使いこなしつつ、最終的な 「価値のトレードオフ」 を担うアーキテクトとしての倫理と専門性を磨き続ける必要があります。 新年の一歩として、まずは身近な設計判断をADRとして記録し、自分の意思決定に潜むバイアスを疑ってみることから始めてみてはいかがでしょうか。その積み重ねが、AIには決して真似できない、真に「重要な」アーキテクチャを築く礎となるはずです。 最後までお読みいただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けております。そこで、みなさんと一緒にアーキテクチャに関する学びを深めていければと思いますので、是非ともIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

はじめに 今回のコラムでは、BTABoKにおけるバリューモデルの一つである Technical Debt について取り上げます。 Technical Debt（ 技術的負債）という言葉は日本企業でも広く聞かれるようになりました。しかし、現場での使われ方を見ていると「未完了の作業」「気になるコード」「バグ」「古いシステム」など実に幅広いものがすべて技術的負債と呼ばれています。 本来の意味が曖昧なまま使われることで、かえって問題が見えづらくなる場面も多いのではないでしょうか。本稿では、BTABoKの整理を土台にアーキテクトとして技術的負債をどう捉え、どう扱うべきかを考えてみます。 技術的負債とは もとはWard Cunninghamが示した比喩で、短期的に価値提供を優先するために、あえて最適でない設計を選ぶことを負債に例えたのが始まりです。本質は次の一点にあります。 短期的には便利だが、将来の変更を高価に、あるいはほぼ不可能にする構造的な選択であること。 コードをリファクタリングしてすぐに返済する限り、負債を一時的に抱えること自体は問題ありませんし、有益でさえあります。ところが実務の現場では、この「返済する」という後段が無視されがちです。返済前提の負債が、返済されないまま放置されていくことで、 変更がどんどん高価になる 機能追加が遅くなる 品質が不安定になる といった問題が積み上がり、技術的負債が組織にのしかかっていきます。 技術的負債と誤解されがちなもの 便利な言葉であるがゆえに、完璧でないものを技術的負債と呼ぶ傾向があり、本来負債と呼ぶべきでないものまで含まれがちです。以下の項目は一般的に技術的負債とは見なされません。 未完了のユーザーストーリー 単にやり残しであって技術的負債ではありません。 バグ（欠陥） すでに顧客価値を損なっている問題であり、負債ではなく今すぐ対処すべき品質問題です。 プロセスの欠如 プロセスの欠如自体は技術的負債ではありません。 ただし、プロセスの欠如、間違ったプロセス、またはプロセスに従わないことは結果として不必要な技術的負債を生み出す可能性があります。 未実装の機能 まだ実装されていない新機能は技術的負債ではありません。 ただし、初期要件が不十分なままギャップを埋めるための暫定対処を行うと、その近道が結果として技術的負債を生む可能性があります。 なぜ技術的負債は発生するのか 技術的負債は、必ずしも軽率な判断や不注意だけで生まれるわけではありません。多くの場合、ビジネスの現実に起因しています。 まず、ビジネスモデルが大きく変化し、急いで対応しなければ市場で生き残れない場面では、最適とは言えない技術選択を取らざるを得ないことがあります。 競合が激しく、顧客から新機能を求められるプレッシャーが強い場合も同様で、短期的な価値提供が優先され、結果として負債が積み上がります。 また、意外と見落とされがちな原因に「リライトやリプラットフォーム」があります。 新しいプラットフォームは新規顧客にフォーカスしますが、既存顧客は旧システムで長期間サポートする必要があります。この期間、IT部門は旧と新の両方に機能追加や保守を行う二重負荷を抱えるため、負債がむしろ増えてしまうことがあります。 さらに、M&Aも技術的負債の大きな要因です。 買収先の製品に内包された負債を意図せずそのまま引き継ぐことがあるためです。特にスタートアップ製品はスピード重視で作られるため、負債を内包していることが多く、それが後から顕在化します。 このように、技術的負債は単なる設計ミスではなく、 ビジネス環境・納期圧力・刷新プロジェクト・M&Aといった「ビジネスの現実」から自然に発生するものなのです。 技術的負債の種類ごとの向き合い方 技術的負債は放置しても自然には減りません。 しかし現実には、技術的負債を計画的に管理できていない組織も少なくありません。 加えて、技術的負債には種類があり、組織のどのレイヤで扱うべきかも異なります。 短期メリットと長期コストのトレードオフ（チームレベル） 短期の価値を優先するために、本来あるべき設計や実装を後回しにした暫定的な作りが発生するケースです。こうした負債は、記録・優先付け・リファクタリングによって、チームレベルで十分対応できます。 雪だるま式の負債（プロダクト／プログラムレベル） 技術的負債が積み重なり、製品全体の保守や拡張が難しくなる状態です。 この段階では、個別チームではなく、プロダクト／プログラム単位での改善施策や投資が必要になります。 時間とともに陳腐化する負債（事業部レベル） システムや製品が古くなり、得られるビジネス価値に見合う投資が難しくなる段階です。 この状態では、事業部レベルで投資を見直し、場合によってはシステムを廃止する判断が求められます。 レガシー負債（事業部〜会社レベル） 使われている技術やアーキテクチャが古く、サポートが難しくなっている一方で、そのシステムが提供する機能は依然として事業にとって不可欠な状態です。 このような負債には、慎重な移行計画や投資判断が求められ、事業部〜会社レベルでの意思決定が必要になります。安易なリプラットフォームは新たな複雑性を生むため、注意が必要です。 コードの肥大化（チーム＋全社IT原則） コードが無秩序に膨らんで複雑化していくタイプの負債です。 チームでの自律的な管理に加え、全社的なIT原則による統制が必要になります。 技術的負債への対応は、プロダクトの成熟度や組織の意思決定構造によっても変わります。 種類に応じて、どのレイヤで扱うべきかを見極めることがコントロールの第一歩です。 技術的負債は「可視化とガバナンス」がなければコントロールできない 金融負債と同じように、技術的負債も見える化しなければ適切に扱えません。 どれだけ負債があるのか 時間とともに増えているのか減っているのか どの負債がどのビジネス価値やリスクに紐づくのか これを判断するために、SonarQubeやSQALEなどで負債を定量化するアプローチがあります。 しかし、計測だけでは技術的負債をコントロールすることはできません。 大切なのは、技術的負債をどう扱うかについて組織としての期待を明確にし、その基盤を整えておくことです。 例えば、 完了の定義（DoD） コーディング標準 アーキテクチャの原則 技術的負債に関わる重要な判断を記録する仕組み（ADR：Architecture Decision Recordなど） といった環境を整えることで、不要な負債の発生を抑え、必要な負債だけを戦略的に負うことができます。 アーキテクトは「技術的負債というローン」を設計する役割を担う BTABoKでは、 Technical Loan Request Card というキャンバスが提示されています。これは、意図的に大きな技術的負債を負う決定を行う際に、ビジネス価値・影響範囲・返済コスト・返済計画をセットで記録するためのものです。 「なぜ今この負債を許容するのか」「いつ・どのように返すのか」を最初からワンセットで設計するイメージです。 アーキテクトはプロダクトオーナーやビジネス側と対話しながら「どの負債は戦略的に許容し、どの負債は即時返済するか」を設計する役割を担う存在とも言えます。 負債をゼロにすることが目的ではなく「ビジネス価値と将来コストのバランスが取れたポートフォリオ」にしていくことが狙いです。 技術的負債は複雑なテーマですが、その本質は「将来の変更性を損なう構造的な選択」にあります。 負債には種類があり、対処すべき組織のレイヤも異なります。そして何より、負債は返済計画がなければ雪だるま式に増えていきます。アーキテクトの役割は、この負債を見える化し、ビジネスと技術の両面から最適な判断を下すことです。技術的負債という概念を正しく使いこなすことが、ビジネス価値、将来のコスト、そして組織全体の持続的な変化能力のバランスを取るうえでの鍵となります。 ご一読いただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

2025年10月29日(水)、30日(木)の2日間に渡り開催された「アニュアル・カンファレンス2025」の各講演で使用した資料です。

ITサービスやシステムを開発するうえで、最も重要なのは“顧客が使って本当に満足するかどうか”です。どれほど新しい技術や綿密な構造設計があったとしても、実際にユーザが「使いやすい」「仕事が楽になる」「自分のニーズにぴったりだ」と感じる体験を生まなければ、サービスの成功にはつながりません。そのため、設計手法やプロセスを選ぶ場面でも常に「顧客目線」「ユーザ体験」を中心に据えることが不可欠です。 本コラムでは、BTABoKのCompetency Modelの Design の中にある Design Methodologies and Processesの内容をユーザ体験（UX）の向上を観点に解説します。 すべての開発プロセスを“顧客痛点”から始める システム開発を始める際に最初にやるべきはターゲットユーザの業務・生活・感情・習慣等の情報を“本物の声”として拾い上げることです。ユーザインタビュー、現場観察、アンケートを実施して情報吸い上げる試みをしますが、形式的なものではなく顧客が実際に何に困り何に価値を感じているかを“共感を持って深掘りする”ことが重要です。（ここが結構大変だったりしますが） この情報が明確になることで、どの設計手法を選び、どのプロセスに重点を置くかが決まります。 たとえば、ウォーターフォール型など計画型プロセスでは、初期要件定義でユーザの“真の痛点”を徹底的にヒアリングし、ドキュメントに反映させながら“将来の体験”を設計します。アジャイル・反復型の場合なら、短いスプリントやインクリメントごとに「現場で本当に使われているか？」を実地検証し、フィードバックを次サイクルへ素早く取り込むことで体験価値を高めていきます。 顧客体験の“動的設計”——変化と共に進化する手法 設計プロセスは、スタート時点だけではなくサービス提供の全期間で“ユーザ中心”の思考を一貫して持つことが重要です。 現代は顧客のニーズも業務環境も刻々と変化しています。だからこそアジャイル型、スパイラル型、リーン型など“反復・進化”を前提にした設計プロセスが、より良い顧客体験創出に向いています。（ただし業務領域やターゲットデバイス等の制約でこれらのプロセスが適用できない領域も存在するのも現実です） 具体的には、以下のような実践が有効です： ユーザストーリー深化 　設計時に単なる「機能要件」ではなく、「ユーザがこの機能を使って何を実現し、どんな気持ちになるか？」まで意識して文書化。サービスが顧客の日常の“どんな瞬間”を変えるかを設計メンバー全員が共有します。 プロトタイピングとユーザテスト重視 　設計途中でも画面やワークフローのプロトタイプを素早くつくり、実ユーザに使ってもらう。使いやすさや理解しやすさ、楽しさ、不満点などを直接会話・行動の中から収集します。その結果を即座に設計へフィードバックして変更・改良します。 パーソナライズ・カスタマイズ設計 　顧客の業務フローや好みに合わせてUI・機能・通知設定などを柔軟に調整できる設計思想を最初から組み込みます。多様なユーザの体験価値を守り、高めるための“個別最適”の仕掛けを設計思想に盛り込むことが不可欠です。 品質属性と現場の“ユーザ体験”を具体的に担保する ユーザが実際にシステムを使う現場では、「使いやすさ」「アクセシビリティ」「多言語対応」「カスタマイズ性」といった品質属性が体験価値に直結します。以前のコラムで 体験価値（UX）を高める品質とは - Usability, Localization, Accessibility, Personalization/Customizability の解説をしましたが、直接的にユーザが体験価値を感じやすいポイントでもあります。 使いやすさ（Usability）の追求 　直感的な操作、情報の整理、エラーレスな導線。ユーザの作業効率を上げ、“使って気持ちがいい”“すぐに覚えられる”設計を目指します。ユーザテストやA/Bテストで数値指標を使って“本当に使いやすいか”を可視化します。 アクセシビリティ（Accessibility）の徹底 　高齢者・障害者・さまざまな言語利用者など多様な顧客を想定し、誰もが同じレベルでサービス価値を受け取れる設計が必要です。ガイドラインやチェックツールの活用に加え、障害当事者のモニター参加・フィードバックを定期的に受ける仕組み作りがあると効果的です。 ローカライゼーション／パーソナライズ／カスタマイズ性 　ユーザの居住地域や業務内容に合わせて、画面表示やサポート内容、通知方法などを細かく切り替えられるように設計します。ユーザごとに設定できる機能・表示・権限・サポートを強化し、「一人ひとりのためのITサービス」を実現します。 顧客との対話と設計プロセスの融合 顧客体験を設計の中心に据えるには、企画者・開発者・運用担当が“顧客との対話”を設計プロセスに組み込むことが不可欠です。たとえば、設計段階で顧客の現場ワークショップを実施し、使い勝手やコミュニケーションフローの課題を一緒に分解してみます。 設計が進むごとに、「現場で本当にどう使われているか」を定期的にヒアリングし直しましょう。ローンチ後も運用部門やサポート部門が顧客の不満・要望を設計チームへフィードバックする体制を作り続けることで、サービスが“生きた顧客体験”として常に改善されていきます。 設計品質の記録と顧客体験ノウハウの継承 設計手法やプロセスの選択は、プロジェクトごとに異なりますが、“顧客体験にこだわった判断”とその結果は必ず記録・可視化します。設計レビューやユーザテストの記録、仕様変更の理由、リリース後の顧客満足度レポートなど、ノウハウを組織の知識資産として残すことで、次のプロジェクトにも活かせます。 特に「顧客の声にどう応えたか」「期待をどう超えたか」「反省すべき点はどこか」を設計ドキュメント・ナレッジベースに積極的にまとめることで新しいメンバーや後継チームが「顧客体験設計の意味」を理解し、失敗を繰り返さず、成功の型を活用できる組織になっていくでしょう。こうした“知恵の蓄積”こそが持続可能な体験価値の提供につながります。 どんな設計手法も、最終的には「顧客が本当に使って嬉しいか」という一点で評価されます。 顧客目線で設計プロセスを丁寧に選び、使いやすさ・アクセシビリティ・パーソナライズといった品質属性まで細部にこだわり、顧客との対話と記録を通じてノウハウを継承していくこと。これこそが「本当に使われるITサービス」を作り続ける組織に必要な力です。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！