「うちはフレームワークなんて使っていません」は本当か？～「Why Architecture Frameworks Matter」に学ぶ、“名前のないフレームワーク”との付き合い方～
「アーキテクチャフレームワーク？ もうそういう時代じゃないでしょう」
勉強会の懇親会や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
「BTABoK Decisions ～ AI時代のアーキテクチャ意思決定 ～」Iasa日本支部
「BTABoK：Extended Team ～拡張チームで実現するデジタル変革～」Iasa日本支部
「BTABoK / Tools ～「ツール」に使われるアーキテクトか、ツールを「武器」にするアーキテクトか ～」Iasa日本支部
コメント