「アーキテクチャフレームワーク？ もうそういう時代じゃないでしょう」 勉強会の懇親会や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

このページへのアクセス権限がありません。 サイトに戻る アカウントを切り替える

btaboknoengejimentomoderuwoyomitokou-ni-engejimentomoderunochukakunifureyou-1 BTABoKのエンゲージメントモデルを読み解こう（３）～ピープルモデルを見てみよう～ * *

anual-conference-2021 アニュアル・カンファレンス 2021 DX時代のエンタープライズ・アーキテクチャ −　主　 題　− 「DX時代のエンタープライズ・アーキテクチャ」 〜　攻めと守りを新結合！ここにDXの本質がある　〜　 今年度は「DX時代のエンタープライズ・アーキテクチャ」を主題に国内外の豊富な活動実績をお持ちの方々を講演者としてお招きします。社会全体が本格的なデジタル活用と革新の時代を迎えつつある今、DXの根幹を担う「アーキテクチャ」の理解とその取組みが如何に重要かについて、各分野の有識者、実践者の方にその展望をご講演頂きます。DXに関心がある各分野の専門職の方から経営者層の方まで、この機会を是非お見逃し無く！ パンフレットはこちら 02:10 - 03:05 55分 講演 1. なぜEAがDXを加速するのか 〜　DXの本質とEAによる推進手法　〜 名古屋国際工科専門職大学 情報工学科 教授 名古屋大学 名誉教授 山本 修一郎 様 03:10 - 04:05 55分 講演 2. DX時代におけるCX/UXの重要性と事例紹介 〜　良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる　〜 エスディーテック株式会社　代表取締役社長 川端 一生 様 04:10 - 05:05 55分 講演 3. ‘BTABoK’はアーキテクチャの実践にどの様に変化をもたらすか？ 〜　ステークホルダー主導のアーキテクチャの実践のフレームワーク BTABoK　〜 IasaGlobal ファウンダー 兼CEO Paul Preiss 様