「TOGAFを導入しようとして途中で止まった」――そんな組織を、私はこれまで何度も見てきた。

EA（エンタープライズアーキテクチャ）を推進していると、必ずといっていいほど話題に上るのがTOGAFだ。これからEAを目指す人にも、すでに推進している人にも、一度は向き合わなければならないフレームワークだと思っている。しかし10年以上この現場にいて感じるのは、TOGAFを「導入するもの」として扱った瞬間に失敗が始まるということだ。

始めるのは簡単だ。しかし根付かせるのには時間がかかる。この記事では、TOGAFは「資格を取り、翻訳力を磨き、育てる」という順番で向き合うものだという結論に至った理由を、順を追って説明していく。

TOGAFのフルセット実装が失敗する理由と部分適用という現実解

TOGAFの概念・考え方は本当に使える。しかしフルセットをそのまま実装しようとすると、ほぼ確実に破綻する。

なぜ破綻するのか。TOGAFは膨大なフレームワークだ。ドキュメント量だけでも圧倒される。真面目に全部やろうとすれば、運用の重さだけで組織が止まる。リソースが限られているからこそ、部分適用・育てる発想こそが現実解になる。

TOGAFのガイドライン自体が、組織の状況に応じた適応的活用を推奨している。フルセット実装を目指すことはTOGAFの本来の意図ではなく、部分適用こそが正しい使い方なのだ。

現場で使えるTOGAFの概念：ドメイン分けとサイクル思考

ビジョンから始めてドメインに落とす構造

まずアーキテクチャビジョンを描き、そこからビジネス・アプリケーション・データ・テクノロジーの各ドメインに分けて設計していく。この縦の構造と横のドメイン分けは、現場の議論を整理するのに非常に有効だ。「システムの話をしているのか、業務の話をしているのか」が混乱しがちな現場では、このドメイン分けを意識するだけで会話の質が変わる。

ServiceNowのCSDM（Common Service Data Model）はその好例だ。CSDMはTOGAFのドメイン構造の思想を取り込んで設計されており、ServiceNowを正しく使うこと自体がTOGAFのドメイン分けを実践することに繋がっている面がある。意識せずともTOGAFの考え方に乗れるツール環境を作ることも、現場浸透の有効な手段だ。

アーキテクチャをサイクルとして繰り返す発想

TOGAFはアーキテクチャを一度作って終わりではなく、繰り返しのサイクルとして捉える。システムも組織も変わり続ける。アーキテクチャは育てていくものだ。だからこそ最初から全部やらなくていい。育てるプロセスの中で、必要なものを必要なタイミングで取り込んでいけばいい。

TOGAF推進の軸：藤枝純教氏の「育てる・連携する」という考え方

TOGAFの実践的な考え方を語る上で、私が最も共感しているのが藤枝純教氏の視点だ。

藤枝氏はグローバル情報社会研究所の代表取締役社長であり、The Open Group日本代表・会長を務める人物だ。TOGAF 9・ArchiMate 3・IT4ITのすべての認定資格を保有し、TOGAF・ArchiMate・IT4ITの日本語訳版監修を長年にわたって手がけてきた。日本におけるTOGAFの第一人者と言っていい。

藤枝氏が強調するのは、「TOGAFは設計フレームワークであり、育てていくものだ」という考え方だ。そしてEAとして育てていく際に重要なのは1人でやろうとしないこと。現場の人・若手ときちんと手を取り合い、連携しながら育てていく。対話を続けながら根付かせていく。これが藤枝氏の言葉から私が受け取ったメッセージだ。

この考え方を私はこう解釈している。TOGAFは完成形を目指すものではなく、組織とともに成長する生き物だ。EAが1人で設計図を描いて「はい、これに従ってください」と言っても現場は動かない。現場の人と一緒に考え、若手に経験を積ませながら、少しずつ組織の血肉にしていく。それがTOGAFを本当に機能させる唯一の道だと、自分の経験からもそう思っている。

TOGAFが現場に刺さらない理由とEAの翻訳力

TOGAFには明確な弱点がある。資格を持っていない人には話が噛み合わない。

トップマネジメントや現場リーダーにTOGAFの言葉でそのまま話しても、まず伝わらない。「アーキテクチャドメイン」「ADMフェーズ」――こういった言葉を使った瞬間に相手の顔が曇る経験をした人は多いはずだ。

だからEAがやるべきことは、TOGAFの概念を咀嚼した上で、その組織の言葉に変換して入れていくことだ。「アーキテクチャビジョン」は「目指すべきIT全体像」に、「ビジネスアーキテクチャ」は「業務とITの対応関係の整理」に置き換える。TOGAFの言葉を使わずに、TOGAFの考え方を現場に浸透させる。これがEAとしての翻訳力だ。

TOGAF翻訳力の身につけ方：3つのステップ

「翻訳力」と言うと特別なスキルのように聞こえるかもしれないが、やっていることはコンサルタントが普通にやっていることと変わらない。ただし順番がある。

ステップ1：TOGAF資格を取る

変換先の地図を持っていなければ、翻訳はできない。「現場課題を感じているから資格を取りたい」という動機で動く人が多いが、それで十分だ。現場で感じた違和感や課題意識を持ったまま資格学習に入ると、TOGAFの概念が一気に腹落ちする瞬間がある。

試験はLevel 1（概念理解）とLevel 2（実践適用）の2段階だ。Level 1はきちんと学習すれば手が届く。Level 2は実際のシナリオへの適用を問う実践的な試験で、自分が受験したときも相当な準備時間を要した。数十時間規模の学習は覚悟した方がいい。学習教材としては藤枝氏が監修したTOGAF公式Study Guide日本語版があり、Open Groupの公式サイトから入手できる。まずここから手をつけることを勧める。

ステップ2：現場プロセスを深く理解する

資格を取った上で次にやることは、現場のプロセスを深く理解することだ。業務フローを追い、担当者の言葉を聞き、「なぜそのプロセスになっているのか」を掘り下げる。

具体的な第一歩はシンプルだ。現場の業務プロセスを1つ選び、「これはTOGAFのどのドメインの話か」を考えてみる。ビジネスアーキテクチャの話なのか、アプリケーションアーキテクチャの話なのか。その仕分けをするだけで、議論の解像度が上がる。最初の一歩はそれだけでいい。

ステップ3：翻訳力と育てる力を循環させる

翻訳力があるから現場を育てられる。育てるから翻訳力がさらに深まる。この循環こそが、TOGAFをエンタープライズアーキテクチャとして組織に根付かせる正体だ。循環が回り始めるまでには数年単位の時間がかかる。焦らず続けることが前提だ。

ここで社内EAが外部コンサルと決定的に違うのは、現場に居続けられることだ。外部コンサルはプロジェクトが終われば去る。社内EAは現場の変化を継続的に見続け、関係者と対話し続けることができる。もちろん異動や組織変更のリスクはある。だからこそ特定の個人に依存せず、組織に根付かせることが重要になる。藤枝氏が言う「育てる・連携する」は、そのリスクへの答えでもある。