​コラム

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

今回のコラムではBTABoKのPeople ModelでとりあげられているCommunityにおける内部コミュニティと外部コミュニティについての考え方を示しながら、Iasa日本支部におけるコミュニティ活動を紹介していきたいと思います。 　 BTABoKのPeople Model／CominityではIasaＧlobalの考える組織やコミュニティのあり方を述べており、BTABoKの記述の中でも、理解を深めておくべきところであると考えます。 　以下BTABoKの日本語訳を示すとともに、筆者の見解を加えていきます。 ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 コミュニティとは何か 　BTABoKでは「コミュニティ」という用語を、 組織の内部および外部の拡張チームメンバーのグループ を指し、最良のビジネスおよび技術戦略を実現するために協力しなければならないことを指しています。 　コミュニティはアーキテクトたちを結びつける存在であり、それを卓越性の中心地やプロフェッショナルの拠点、あるいはその他の言葉で呼ぶ人もいるかもしれま

要旨（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, エンゲージメント

最近のシステム開発では、モデリング等の論理設計を省いていきなり実装とテストを繰り返しながらゴールに辿り着くという実装主義が、Z世代にとっては主流になりつつあるようだ。確固たる方法論に基づいた設計ありきの構築をしてきた設計主義のベテランアーキテクトは、この理屈にこだわらない開発手法に取って代わられることに、ある種の喪失感を感じざるを得ない。 この事はテクノロジーの進化によって詳細なロジックをカプセル化する事で、生産性と品質を追求した果てにたどり着くものである。これにより、エンジニアは自ら産み出したプロダクトによって職を失いかねないというジレンマに陥ることになる。とは言え、ことさら古いやり方の良さを吹聴し、技術の進化に対する危険性のみを主張する輩は見苦しい老害と言えよう。絶えず新しいテクノロジーを用いて生産性を追求することはエンジニアの取るべき道筋である。ではシニアアーキテクトは黙ってリタイヤすれば良いのだろうか。 この疑問が生じる背景には、良い道具さえあれば問題が解決するというツール至上主義がある。これが行き過ぎた場合には、ゆるぎないセオリー

新年明けましておめでとうございます。2026年、私たちのエンジニアリング環境は、生成AIの急速な進化によって劇的な変化の中にあります。あらゆる仕事の自動化が進み「人でしかやれないこと」との境界線が問われる今、アーキテクトにとって最も重要なテーマは、技術の選択を超えた 「意思決定」の本質 に立ち返ることではないでしょうか。本稿ではアーキテクチャ意思決定をテーマに、グローバルな知見であるBTABOK（Business Technology Architecture Body of Knowledge）を紐解きながら、これからのアーキテクトが担うべき役割を考察します。 参考 IASA Global, BTABoK – Decisions https://iasa-global.github.io/btabok/decisions.html ※本コラムはBTABoKの内容を要約・解釈したものであり、厳密な定義や詳細は原典を参照してください。 ・今なぜ意思決定が主要テーマとなるのか 昨今の生成AIの熱狂は、ソフトウェア開発の風景を一変させました。コー

はじめに 今回のコラムでは、BTABoKにおけるバリューモデルの一つである Technical Debt について取り上げます。 Technical Debt（ 技術的負債）という言葉は日本企業でも広く聞かれるようになりました。しかし、現場での使われ方を見ていると「未完了の作業」「気になるコード」「バグ」「古いシステム」など実に幅広いものがすべて技術的負債と呼ばれています。 本来の意味が曖昧なまま使われることで、かえって問題が見えづらくなる場面も多いのではないでしょうか。本稿では、BTABoKの整理を土台にアーキテクトとして技術的負債をどう捉え、どう扱うべきかを考えてみます。 技術的負債とは もとはWard Cunninghamが示した比喩で、短期的に価値提供を優先するために、あえて最適でない設計を選ぶことを負債に例えたのが始まりです。本質は次の一点にあります。 短期的には便利だが、将来の変更を高価に、あるいはほぼ不可能にする構造的な選択であること。 コードをリファクタリングしてすぐに返済する限り、負債を一時的に抱えること自体は問題ありませんし、

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

設計手法やプロセスを選ぶ場面でも常に「顧客目線」「ユーザ体験」を中心に据えることが不可欠です。本コラムでは、BTABoKのCompetency ModelのDesignの中にあるDesign Methodologies and Processesの内容をユーザ体験（UX）の向上を観点に解説します。

今年のアニュアルカンファレンスは「秋のアーキテクチャ祭り」と題しまして、10月29日、30日の日程で開催されます。その中でIasaが推進する「BTABoK」の他に「TOGAF®」にも触れるセッション、ワークショップがありますが、本コラムでは、TOGAF®とは何か、その成り立...

知を深め、未来を描く二日間 ― 秋のアーキテクチャ祭り2025 エンタープライズアーキテクチャ（EA）やビジネスアーキテクチャ（BA）という言葉を耳にする機会は増えています。DX（デジタルトランスフォーメーション）の進展に伴い、企業の変革を支えるアーキテクトの役割は、ますま...