IT組織変革とTOGAF活用で業務改善を進めた実例紹介

＃アーキテクチャ開発手法（ADM）＃＃＃ ビジネスの空論から技術現場へ

役員会議室の空気は、なんというか…普通じゃなかった。圧迫感がまるで布団みたいに降りてきて、コーヒーの湿った匂い、妙に主張する高価な香水、そして沈黙が生む引力、それが渦巻いていた。新任チーフアーキテクトとして――いや、自分で言うのも変だけど、この「オムニマート」っていう大手小売チェーンで、初のまともなIT戦略を提示する役目を背負わされてた。でもさ、肝心なのはこの会社自体、一枚岩なんかじゃなくて…。ああ、ときどき考えすぎかな？えっと、とにかく、小さな買収を繰り返して寄せ集められた結果、“フランケンシュタイン”みたいになってて、それぞれの子会社ごとにレガシーシステムとか勝手なプロジェクト、「影IT部門」まで抱えて、自分だけの縄張り守ってる中世の領主みたいだったんだよね。組織図も、企業っぽい形っていうよりは混沌とした内乱マップとでも呼びたくなる感じだった。

CEOは株価への耐性と反比例しながら「デジタルトランスフォーメーション」の停滞を鋭く突いてきた。「1990年代フリーマーケット並みのITインフラしかないし、競合他社はシリコンバレー系スタートアップ並みに敏捷だ」とバッサリ。まあ実際、その評価にも根拠はあるわけで。冗長化されたシステムや機会損失によるコスト膨張――そんな現象が社内では当たり前になっていた。

正直言うと、自分で用意した資料にも不安しかなく、その混沌ぶりを目の当たりにして呆然としていた。与えられたミッション自体は明快だった。“断片化したIT環境を統合しつつビジネス目標へちゃんと整合させて、とにかく早く成果出せ”ってこと。でもね、その道筋が全然クリアじゃなくて…。飛行中、それも煙吹いてる飛行機でエンジン設計しろと言われたようなものだった。技術面だけじゃなく文化的・政治的事情も絡んできて、“再現可能な”仕組みナシには攻略できそうにない難物だと感じ始めた。本当に頭痛い。

最初の日々…あれはある意味、巨大組織特有の歪みへの社会科見学でもあったよ。既存システム全体像を掴もうと思えば思うほど、大地震で揺れる海岸線を手探りで測量するような無力感ばかりだった。例えばCRMシステム一つ取っても3種類あって、お互い連携ゼロとかザラだったしね。それだけじゃない、サプライチェーン管理ソフトウェアもカスタムコードと昔導入した外部製品がごちゃ混ぜになって、公認業務プロセスごとに5個以上非公式ワークアラウンド使われてる例も見つけちゃったんだよね…。ここまで来るともはや何が本筋かわからないけど、と、とりあえず話戻そう。

IT部門内では担当者同士より協調性より“自分テリトリー死守！”という雰囲気ばかり強まっていた。一方経営側から見るとIT部門＝コストセンター扱いされ、多額予算食いつぶす割には成果が見えない、と陰口叩かれている様子もうっすら伝わった。不公平だと思いつつも…。

前任者はいわゆるトップダウン施策型でこの問題打開を試みたものの、大半は綺麗事満載設計図として名残だけ残して消え去った。その資料群はいまや誰にも参照されず共有ドライブのお荷物になっている始末。当時、“同じ轍踏むものか”と思いつつ焦燥感ばっか募らせていたっけ。本質的課題…結局、“技術” と “ビジネス” の間に横たわる断絶こそ最大障壁なのだろう――そんな実感しか残らなかった。

気づけば、私たちは「ITに全社が振り回される」パターンにまんまと陥っていた。何というか…企業自体がすでに深刻な問題を抱えてたんだよね。新しい技術を導入すればいい、みたいな単純な話じゃないのは、うーん、もう明白だった。アーキテクチャとか管理手法とか、その根っこから考え直さないと無理っぽい。しかもテクノロジー部門とビジネス部門が互いにちゃんと分かり合って―ああいや、一瞬コーヒーのこと考えちゃったけど―ともかく共通言語や枠組みが必要だ、と痛感していた。

でも実際、その道はまあ容易ではなかったわけで。会議なんて数知れず出席したものの、大半は成果ゼロに終わった感じだし…。関係部署同士で優先順位ばかり争ってたしね。マーケティング部門長は分析プラットフォームだ！と騒ぎ、CFO（最高財務責任者）はIT予算30%削減しか頭になくて。一方で物流部門長は倉庫スキャナーだけ直せばいいと思ってるみたいで、おおらかと言うべきなのかな…。そのあたり、ふと思い出して笑いそうになるんだけど、現実には全体方針も決まらずカオスだった。それぞれ要望バラバラなのに全部叶えろ的空気になっちゃってて――チームとして挟まれて動いても誰にも満足されないわけ。不思議なくらいプレッシャーだけ増してくるし。CEOから進捗確認の電話が毎日来る頃には、本当にもう神経ピリピリしてきた。その時期、自分でも驚くぐらい睡眠時間1日4時間くらいしか取れてなくて…今思えばよく倒れなかったなと思う。

転機、と言えるほど派手ではなかった。ただ切羽詰まった末の流れ…いや、この表現ちょっと大げさかな。でもある夜、ふとTOGAF（The Open Group Architecture Framework）のことを数年前耳にした記憶が蘇った。当時？官僚的で面倒臭そう…そういうイメージで敬遠してしまって、それ以上調べようとも思わなかった。でも今なら、このフレームワークの構造化された仕組みこそ混乱状況下でも頼れる軸になる可能性があるような気がする。「Architecture Development Method（ADM）」って中核プロセスも反復型だし、大規模エンタープライズ・アーキテクチャ構築運用向け設計という説明も腑に落ちる部分あったり。華々しさは全然ないけど理論的には評価されている方法論なんだ。

それまでとは別物の切迫感を引きずりつつ、自分でも驚くぐらいTOGAF関連文書読み漁り始めた。その中ですごく印象的だったのが、「抽象目標」から「具体実装」へ段階的につながる体系化された手順。このADMのおかげで、自社ITアーキテクチャとビジネスゴールとの整合性確保への希望というか糸口らしいものが見えてきた気はした。ただ念押しすると魔法みたいには行かなくて、一貫した論理プロセスとして地味に進めるものなんだけど。

ちなみにこのフレームワーク自体1990年代登場なんだよね。それから改良重ね今まで発展してきた歴史もちょっと興味深かったりする。最新バージョン＝TOGAF Standard, 10th Edition（2022年リリース）は以前よりユーザーフレンドリーになるよう工夫盛り込まれていて…。そして市場調査データによれば**Forbes Global Top 50企業の80%以上**が導入済みという数字まであるとか聞いて、「大企業でも採用例あり！」みたいなお決まり説明にも意外と使える材料だったんだよね。

それがね、私みたいな「新入り」にはどうしても足りない信頼性を与えてくれたんだよ。ま、そう思う。ああ、ちょっと話が逸れるけど、新参者ってさ、何かと疑われるでしょ？でも、この取組みは単なる個人プロジェクトじゃなくて、「ちゃんと実績ある業界標準を使ってます」って胸張って言えるような位置付けにできたのは大きかったと思う。しかもこのフレームワークの強みは、その反復的というか…まあ繰り返し型の性質なんだよね。一気に全貌を完成させる必要なんて実際なくて、とりあえず一歩ずつ進めながら学び直したり微調整できたりする、その感じ。 うーん、途中でちょっと別件考えてしまったけど…カスタマイズ性も高いから、自社独特の問題とか文化にも割と柔軟に合わせられるわけ。

最初のステップ、それが**予備フェーズ（Preliminary Phase）**だったんだけど——いやまあ図表描くだけなら簡単だけど、それだけじゃないんだよ。本当は成功するための土台作りそのもの。この段階ではアーキテクチャチーム立ち上げたり、原則決めたり、自社能力について現実的な自己評価もしなきゃいけなくて。正直面倒だと思う瞬間も多々ある。でもIT部門や事業部門から適切な人選ぶことが重要で、それぞれ変革推進の主因も明確化されたっぽい。その時CEOから「効率向上」「分散ユニット統合」「市場シェア損失抑制」という方針が示されていて…。こんなの本当に全部必要なのかな、とか疑問挟みつつガバナンス・フレームワークまで策定して、誰が意思決定するかとか方法まで決めちゃった。このフェーズ自体が「どう動くか」のルール設定期間と言えるかな。会議やワークショップとか地味に手間ばっか掛かったし書類作成も山積みだった。でも結局、大規模変革への足場固めだったわけで。それに組織範囲もここで定義されるし、この最初の活動範囲となる事業領域もしっかり確認された。おまけに財務制約・政治的制約まで整理対象になったから驚いたよ…。えっと、そんな下準備抜きでは後続アーキテクチャ活動なんて机上論止まりになっちゃう可能性、高かったと思う。

それから次へ移った工程が**フェーズA：アーキテクチャ・ビジョン（Architecture Vision）**になる。この段階では未来像――なんというか理想図？――を書き出すことになるんだけど、本プロジェクト範囲や主要ステークホルダー（成果＝キャリアや報酬につながる人々）の合意形成を目指す展開になった。不思議と技術側よりビジネス側優先だった気配すらある。「ビジネス起点」、そんな感じ？関係部署との課題認識や期待事項・戦略目標などについてワークショップ等交え理解深めた記憶あり。しかしふと途中「これ全部意味ある？」と思いつつ…CEOによる強力メッセージ内容もしっかり具体化して、「OmniMart」という統合企業イメージとして落とし込む必要にも迫られた。「マーケティング部門が顧客情報一元管理したら何起こる？」みたいな仮説ベースでも色々検討された。本当に完璧な答えは出ない。でも、それくらい曖昧さ含む過程こそ現場感じゃないかな、と今さら思い返す。

もし在庫がサプライヤーから店頭までシームレスに追跡できたら、ロジスティクスってどれだけ変わるんだろうなあ。まあ…現実ではなかなか全部がうまくいかないのは分かってるけどさ。このフェーズで私たちがやろうとしていたことは、結局「何を問題と見なすのか」について全員で同じ絵を描いておこう、という話だった気がする。成果物はStatement of Architecture Work（アーキテクチャ作業計画書）で、これはプロジェクト範囲や目標、それに制約条件まで細かく書き出した文書なんだ。えっと…ここで急に思い出したけど、昔この手の計画書ばっかり作ってて夜中ずっとパソコンの前にいた時期もあったっけ、と妙にセンチになる。でも戻るよ、本筋へ。このドキュメント自体がビジネス側との契約みたいな役割になってて、「これくらいできれば成功ですよ」というラインを明確化してたわけだ。そしてArchitecture Visionはターゲットとなるアーキテクチャのざっくりした像――そう、「北極星」と呼ばれているような指針になった。それは決して技術図面ではなくて、むしろビジネス的ストーリー性を持つゴールイメージだった。

この一連の過程で得た教訓には正直重みがある。混乱が起こる理由って技術だけじゃなくて、人間側の事情――例えばインセンティブがお互い食い違ったりとか、伝達ミスとか共通認識不足とか…そういうところから生まれることも多かった。「いや、自分だけこんなことで悩んでる？」とふと思いつつも、多分みんな似たり寄ったりだったと思う。ADM（Architecture Development Method）は直接その課題を魔法みたいに消せる道具ではないものの、それらと向き合える枠組みとして機能していた。そのお陰なのかな、不可能にも感じられた巨大な問題群も、一歩ごと管理できるステップへ崩して捉え直せた感覚になったんだよね。しかしながら、この時点でもまだ旅路は始まったばかり。本当に最初の地図を手渡された―そんな心境。

## 現実への設計図策定という着実な工程

Architecture Visionフェーズ終わり際には、「ひとまず合意形成できた」という安心感もちょっとあった。でも正直言えば、それって登山口に立った程度なんじゃない？　本格的なしんどさはここからスタートする感じだったし…。次なるADMフェーズ――つまりB・C・D段階こそ、高度ビジョンと現存組織内リアルとの衝突地点と言える。いやほんと、このギャップには毎回ため息しか出ない。でも逃げても仕方ないのでね。この段階では戦略レベル止まりだったアイディア群を粘り強く具体化・詳細化し、「Business」「Information Systems」「Technology」の各領域ごとのアーキテクチャ体系として整備する必要あり。その分析やモデル化作業が延々続いて、「ギャップ特定」と称されてもまあ簡単じゃない。

OmniMartの場合なら、この時点ですべて重要業務プロセス洗い出し→複雑怪奇データフロー一件ずつ可視化→古びた自社ハードウェア資産全リストアップ……という無茶振り三連発状態。ただ理想論や抽象イメージだけ語っている場合じゃなく、本当「今住人暮らしてます！」という家屋大改修現場そのものへ移行したような圧迫感もあった。途中、ご飯何食べようとか考え始めたりしちゃうくらい集中力消耗するんだけど、仕事だから続行せざるを得ず…。

このタイミングでは、とくに高リスク意識必須。「まあ、大丈夫だろ」など油断すると即死コースなのよね。判断ミスや調査抜け漏れなどある場合、美しく描くだけなら易しいものの実装困難＆本質課題解決につながらぬ「机上プラン」で終焉―なんて展開も珍しくなくなる。この場面ほど成功失敗左右されやすい局面は他になかなか無かった気がする。

Phase B（Business Architecture） では、その「技術導入」をどうして選ぶべきなの？　背景理由そのものまで深掘り検討対象となっていた。うーん、人によって正解違いそうだけど…。

より良いITシステムを設計するには、まず、そのシステムが支えるべきビジネスの実態を知らないと話にならない。うーん、当たり前って思うかもしれないけど、これが案外難しい。私もチームの面々も、それぞれ色んな事業部門に“放り込まれる”みたいな感じで過ごした。数週間はマーチャンダイジングチームとかサプライチェーンの人たちやマーケ担当者と一緒に、まあ正直ちょっと居心地悪かったけど——あ、いや、慣れてくると妙な一体感もあるんだよね。

手法としてはビジネスシナリオ分析なんて仰々しいもの使ったりして、「現場では何が本当に課題なのか」を構造的に洗い出そうとした。でもさ、「ワークフロー上で最大のボトルネックは何？」とか「情報アクセスを一つだけ変えられるなら？」とか質問すると、大抵返ってくる答えは全然予想外だったりする。実際、“昔からこうだから”で見過ごされてきた無駄がゴロゴロ出てくるわけで…ああ、自分も似たようなことやっちゃってる気がして落ち込む。そんなこんなで詳細な現状モデルを作成しながら、人・プロセス・情報がどう絡み合っているか明示していった。

このモデルたちは単なる理論上の産物じゃなくて、本当に組織そのものを映す鏡みたいだった。意外にも、多くのステークホルダーにとって「自分たち部署が企業全体とどう繋がっているか」を初めて視覚化できた瞬間になったんだよね。……脱線したかな？でも、このプロセスのお陰で今ここに存在する大きなギャップ――例えば、新商品導入プロセスひとつ取っても4部門またぐ17もの手作業工程（これ、買収前から残った古びたワークフロー）があり、それゆえ最適化なんて程遠かった――が露わになった。その非効率だけでも市場投入遅延による多額損失につながる、とCFOもうんざり顔だったっけ。

こういう現状や候補となるターゲットビジネスアーキテクチャを書類化しておくことで、課題点をピンポイントで把握できるようになる。しかも、この段階で仕上げた成果物はエンジニア向け技術資料というよりむしろCFOでも理解可能な言葉選び重視のビジネス分析資料として成立した。「ま、いいか。」

さて、ビジネスニーズ明確になったところで**Phase C, Information Systems Architectures**へ進行。このフェーズ自体さらに**Data と Application Architecture**という2つに分割されていて、「何を」設計すればターゲットビジネスアーキテクチャ（さっき定義したやつ）を下支えできるか考える段階になる。「ふう…」現実問題として既存アプリケーション群には混乱状態が蔓延していたので、それへの対処策でもあったわけ。

当時は機能重複しまくり＆サイロ化された大量アプリ群から、一貫性ある統合生態系へ移行しないと詰む気配だった。最初に“現状アプリケーションランドスケープ”、つまり通称「スパゲッティ図」と呼ばれるベースライン可視化から着手。それ描いてみれば分かるけど…数百個ものアプリ同士が重複機能＋脆弱ポイントツーポイント連携によってぐちゃぐちゃに結び付いている有様だった。「ため息しか出ない。」

目標として掲げたターゲットアプリケーションアーキテクチャはもっと単純＆柔軟性高く設定。そして当然ながらビジネスドメインとの整合性もしっかり意識。「購入優先」「クラウドネイティブソリューション推奨」など原則も打ち立てつつ、その中から廃止・置換・統合対象まで定義した。一度横道それても戻れることに少し安堵しつつ——こんな泥臭い整理こそ後々効いてくるんだと思うよ、多分ね。

データアーキテクチャのコンポーネントも、なんだかんだ言って本当に大事だった。いや、大事じゃない場面があったかといえば…思い出せないな。エンタープライズ全体を流れる情報の経路をつぶさに見て、「customer」とか「product」、あと「supplier」みたいな主要データエンティティの“これが権威”っていうソースを探し当てるわけで。でも、その過程でふと思う。「そもそも何年も前から同じ単語なのに、各システムで意味違うとかどういうこと？」って。ま、いいか。現実にはそういう食い違いがあるからレポートは混乱するし、数字もずれっぱなしになる、と。
なのでターゲットとなるデータアーキテクチャを設計して、“ここだけ信じればいい”、つまりデータ駆動型組織のど真ん中に据えるべき基盤要素、それを作ろうとしたというわけ。それと並行して現状とのギャップ分析――またやったよね。また？　と思いつつ、“何を変えたらいいか”明確なリスト作りにも励む羽目になった。この段階では選択肢が苦しいほど多くて、例えばどのレガシーシステムを消すか、新機能への投資先はどこなのか…迷子になりそうだった。本音としては未来志向で行きたいけど、今目の前にある問題とも格闘し続けなきゃならなくて、その間でバランス取るしかない感じ。

そして最終的な設計段階――Phase D, the Technology Architecture（技術アーキテクチャ）へ進むことになった。これは、「結局どうやる？」という問いそのものだね。アプリケーションやデータを下支えするインフラ全部について考える部分だから気分的には重かった気がする。具体的にはサーバーとかネットワーク、それからDBMSやOSについて検討したっけ…。OmniMart社の場合、この技術インフラ自体もうバラバラで、一貫性ゼロと言いたくなるぐらい断片化されていたんだよね。不意に「あれ？ クラウド戦略なんてあったっけ？」と思ったくらいだし…。複数ベンダー製ハードウェア入り交じり状態、まとまり感なし。そのため拡張性・信頼性・セキュリティ全部担保できる基盤プラットフォーム定義せざる得なくなる。当然ながらネットワークトポロジから仮想化戦略まで幅広く議論された。“そんな細部まで？”と我ながら驚いた記憶あり。
目指すべき技術像として採用されたのはハイブリッドクラウドモデルだった。それぞれ異なるワークロードごと適切な場所へ配置できる柔軟性重視型。一方、このまま放置すれば互換性なしプラットフォーム増殖地獄…それ避けたくて技術標準もしっかり策定されたんだ。またこのフェーズでも現状（ベースライン）と理想（ターゲット）の差分分析＝ギャップ分析が念押しみたいに行われたお陰で、インフラ近代化への道筋＝具体的ロードマップにつながった。その内容には調達・導入予定ハードウェア/ソフトウェア/サービス等々盛り込まれている。
加えて、この段階成果物として詳細仕様書みたいな“エンジニア大好き文書”もしっかり生み出されている。ただそれら全部Phase B由来ビジネス要件からトレーサビリティ確保済。“単なる新しいIT買いました”ではなく、本当に事業変革そのものへの橋渡し役だった、と振り返って思う。

B・C・D各フェーズ全体通して取り組むプロセスというのは徹底的——正直ちょっと疲弊するほど——細かな分解＆再設計作業だった。不具合一つひとつ丁寧につぶして、新規統合ブループリントへ練り上げ直す体系立ても必要不可欠だったように思う。“あぁまだ終わってない…”とうめき声出そうになりながら進めた時期もあった。でもこうした積み重ねによって漠然とした理想像から具体案——しかも実行可能性有——へ昇華できたと言えるんじゃないかな。もちろん今後歩む道筋は長大無限ループにも映る瞬間ある。しかしゴール地点だけは既に抽象絵画ではなく、多層構造詳細設計図として着実に現実味帯び始めている、不思議だけど。

## ブループリントから具体策へ：実現可能性という観点

完全無欠にも見える建築図面一式持っていて安心？いやまあ、それ自体嬉しい反面、本当に“動く職場”へ落とし込む工程とは次元違い…痛感せざる得ない。「紙上完璧→運用泥沼」なんてありがち話とは言え…。

野心的な変革って、たいていその複雑さにやられて途中で挫折するんだよね。ああ、なんでみんな最初は大きく出ちゃうんだろう？でもTOGAF ADMは、そういう現実をちゃんと見てる。次の段階――計画と実行にフォーカスしているわけ。でも…ちょっと話それるけど、理想ばっかり追っても仕方ないし、現場は動いているからね。さて、本筋戻すと、**フェーズE（機会およびソリューション）**と**フェーズF（移行計画）**では、「何を」「どのように」だけじゃなくて、それを「いつ」やるのかまで具体的に考えることになる。これがまた難しい。ま、ときどき頭痛くなるくらい。

ここからはアーキテクトというより戦略家とか現実主義者にならざるを得ないタイミングなんだよね。OmniMartの場合もそうだった。一気呵成の全社改革なんて無理だし、そもそも事業活動自体止められないからITシステム再構築は並行して進めざるを得なかった。「全部一度に」は幻想でしかなくて…。だからこそ将来像だけ夢見ても意味がない、一歩ずつ現実的な道筋に切り替えて、中間地点ごとに価値提供できるよう設計し直した。この感じ、「未来への橋」を板材一枚一枚地道にはめ込むイメージかな。うーん、伝わるかな？

フェーズE（機会およびソリューション）は設計から戦略へ舵を切るところだと思う。中心作業は前段階で洗い出したギャップ――つまり課題とか不足――それら全部まとめて論理的なワークパッケージへ落とし込むこと。一発で解決なんて到底無理なので優先順位付けが不可欠だった。コストやリスク、それから依存関係…色々な観点で異なる実装オプションもちゃんと評価した。本当、この辺り妙に神経使った覚えある。それで、一番重要なのが**アーキテクチャロードマップ**という成果物。ただのプロジェクト計画じゃなくて、変更内容の時系列整理、中間地点となる「トランジションアーキテクチャ」（遷移状態として安定した構成）とかも含まれる戦略文書として仕上げたんだ。でもまあ、その過程で何度も「あれ？本当にこれでいいのか？」って立ち止まったけど。

例えばさ、「新CRM導入」を巨大プロジェクト1本でやっちゃう手もあるけど、OmniMartではまず「顧客データ統合によるマスターデータ整備（単一情報源確立）」っていう中継ぎ段階踏んで、その後各事業部ごとのCRMモジュール展開へ細分化していた。この進め方にも利点はいくつかあったと思う。早期に目に見える成果が出せて関係者への説明もしやすいし、その分予算確保にもプラスだったんじゃないかなぁ。また状況変化や想定外が起こった時にも軌道修正する余地（柔軟性）が残されていた。「変革」という長丁場には適度なオフランプ――途中下車できるポイント――が絶対必要なんだよね。しかしながら、それぞれの施策について影響度分析を慎重に行い、高いビジネス価値・管理可能なリスク水準と思われるものから優先着手する基準づくりにも力入れてた。…いや、本当に面倒だった。

そしてこうして練り上げた戦略ロードマップ（Phase E）のあとにはPhase F（移行計画）が待っている。この段階ではさらに具体的・詳細レベルまで落とし込みつつ、本格的な実行方法について検討され始めるわけ。でも、そこまで来てもまだ不安になる瞬間ってあるんだよね…。

ここでは、実装と移行計画の最終段階に至った……いや、正直ちょっと手が止まりそうになったけど、ともかく作業は進めざるを得なかった。このドキュメントってさ、ロードマップで洗い出されたプロジェクトについて「誰が・何を・いつ・どう進めるか」を余すことなく書き込んだ包括的なものなんだ。ああ、途中でコーヒー切らしてたっけ。でも戻ろう。具体的には、プロジェクトチャーターをさらに細分化し、各作業パッケージごとに明確な成果物を定義したり、時間軸やリソース配分まできっちり決めていた。頭痛かったな。

このフェーズで特に大事だったのが**アーキテクチャ契約（Architecture Contract）**。実はこれ、本当に欠かせない存在だった。アーキテクチャチームと実装チームとの間で正式合意する文書でね、プロジェクト全体として守るべき基準とかガイドライン、それからアーキテクチャ上の要件なんかも全部盛り込まれているんだよね。うーん、それ書いてるとき途中で急に昼ご飯どうしようとか考え始めたりして。でもまた戻ってくる。それだけ、この契約が丹念に設計されたアーキテクチャへ忠実なソリューション構築を保証する主軸となったわけだ。それだけじゃなくて、「スコープクリープ」まで防いでたし、バラバラなプロジェクトもそれぞれ価値を発揮しつつ大きな戦略目標にも貢献できていた。

さらに言えば、それぞれ異なるプロジェクトごとの実装ガバナンスについても検討した。単なるインフラアップグレードと複雑な顧客向けアプリ展開じゃ管理水準違うから、そのあたりもしっかり対応策考えざるを得ない状況だったんだよね。しかも各プロジェクト間の依存関係まで明示して、一方が終わらないと次に進めないケースなんかも整理したりして……ちょっと脱線するけど、その頃猫がパソコンの上乗って邪魔されたこと思い出した。でも話戻すよ。当時はコストや利益もしっかり算出されていて、そのデータ自体が投資判断用の最終ビジネスケースになってたんだ。その時点でもう仮説段階は完全に終了して、この計画は資金調達済み＆現実味あるものとして成立していたというわけ。不思議だけど、この秩序立った計画こそ昔OmniMart社内で見られた混乱から組織守ってくれる強い盾だったと思う。

こういう体系化された現場適用例を見ると、多くの組織でも似たような変革への挑戦が見受けられる。一例として**デイリーファームグループ（Dairy Farm Group）** があるんだけど……香港拠点の大規模小売持株会社なのさ。ただ、多数ある独立事業体統合という難題抱えててね。その際TOGAF ADM 活用によって統一技術アーキテクチャ策定へ舵切った結果、ごく短期間──本当に4ヶ月間──で企業再編成後グループ共通基盤構築につながった報告も存在するんだよ。「そんな短期間？」と思わず声出そうになったけど、それくらいADMによる構造的手法には推進速度向上への可能性感じさせられる。

あと英国国防省（UK Ministry of Defence）。ここ、多数独立部門集まる超分散型組織だけど、その中でもTOGAF導入によって全体共通枠組み確立への道筋付いてるという指摘あり。本当に多様部署横断型管理とか運営一貫性保つ効果あったらしい——まあ、自分その現場見てないから「たぶん」としか言えないけどさ。そして、小売業界から防衛領域までこのフレームワーク応用可能性指摘され続けている。ただTOGAF自体は固定された教条じゃなく状況適応的手法として設計されている点にも一応触れておくべきかな。

そしてオーストラリアWestpac銀行ではIBMとのアウトソーシング関係維持目的でもこの方法論使われた経験例あり。また英国警察情報システム機構（UK Police IT Organization）も警察情報システム国家戦略整備へTOGAF活用記録残している。他にも米国Litton PRC や英国社会保障省（Department of Social Security）など様々な事例下でも段階的計画執行や構造原則適応例として位置付けられているみたいなんだよね。…話それちゃうけど、その資料まとめながら夜食買い忘れ気づいて凍えた夜思い出した。でも重要なのはこういう先行観察結果こそOmniMart内部説明時、自分案じゃなく有力企業群採択経験ある方法論という根拠になることだった。他社知見や過去蓄積踏まえて、本枠組みにより困難環境下でも一定水準以上期待されうる成果支援役割担える内容になっていた、と改めて感じたりした。

設計図、まあ、なんかもう手元にあってさ。しかも戦略まで、とっくに練り上げちゃってるんだよね。うーん…ここまで来ると、いざ舞台が整ったぞという感じ。でも、急にコーヒー飲みたくなったりするのは自分だけ？いや、本題戻るけど、本当に「実装」へ向けてすべてが揃った気分だった。

## ビルドの統治と将来管理

アーキテクチャ開発手法（ADM）サイクルの最後の場面になるとね、計画を現実世界で動かしていかなきゃならない。その後もアーキテクチャはずっと生き続けるから、それに合わせて何度も対応しなきゃいけないわけで。**フェーズG：実装ガバナンス**とか**フェーズH：アーキテクチャ変更管理**では、「この計画、本当にちゃんと動いてる？」みたいな部分や、「社会とかビジネスが変わっても、この構造、大丈夫？」という視点を大切にしていた。不安定になりそうな時ほど監督役にならなきゃダメなんだろうな…まあ話逸れるけど最近監督映画ばっか見てしまう…。えっと、元に戻すと、この段階では企画・設計中心だったムードが、一気に運営や適応へ移行していくんだ。

OmniMartで言えば、新しいシステム作っているプロジェクトチームが本当に設計図通り進めているのか、それを見張るチェック体制もしっかり築いたし。うーん、でも時々「誰が本当に責任持つの？」みたいな疑念湧いてこない？でもまあ、ともあれ、新しいビジネス要件や技術トレンドによって最初決めたことから外れてしまわないよう、そのためのプロセスづくりにも着手した。このADMサイクル最後の周回こそ、「一度作ったら終わり」じゃなく、「続いて変化し続ける取組」に変えるための肝心要（かなめ）の部分だったと思う。ここでガバナンスとか変更管理機能を持たせれば、時間経過とともにゆっくりカオスへ逆戻り…みたいなのへの抑止力になる。「ま、それでも仕組み無かったら全部形骸化して誰にも思い出されない企業イニシアティブになるよ」と冷静につぶやく同僚が頭によぎった。

フェーズG――実装ガバナンスは品質維持・管理策として導入された。目的は明快でさ、「期待された価値を届けつつ枠内できちんと進行する」「リスクだけ膨らませない」こと。現場でもビジネス部門＋IT部門から主役級を集めて「アーキテクチャ・ガバナンス委員会」を結成、第Fフェーズで書いた「アーキテクチャ契約書」を土台としてプロジェクト進捗や成果物レビューを区切れごとやった。「このプロジェクト、本当に合意済み内容＆ターゲット・アーキテクチャ目指した正しい方法で価値生まれてます？」そこばっか問われ続けて少し息苦しかった記憶ある。でもね…。

この体制自体は細かな口出し（マイクロマネジメント）が狙いじゃなくて、大枠監督とか助言役として機能した感じ。本音言えば、「予定外れても怒られるだけなら誰も挑戦しなくなるよ」と思ってた。でも違った。その理由探求こそ重視されていて、「最初から設計思想ズレてた？」「いやビジネス要件自体おかしくなった？」「現場側問題？」多方向的検討→柔軟判断へ流れ込む。不足項目や想定外案件あれば、“get-well”レコメンデーション＝具体的改善策提示となって返される。このフェーズ全体がトランスフォーメーションへの免疫系として前兆段階認識→早期対応へ誘導していた印象強い。そして、自分達掲げた理想像そのまま現場結果につながせるには欠かせぬ規律となっていた。

ちなみに、本格稼働＝最終納品完了後ですべて終わるわけじゃないという…なんだろう、不思議な感覚だけ残された気さえする。

ここからフェーズH——つまりアーキテクチャ変更管理、始まる。ああ、どうしてこういうのはいつも唐突なんだろうね。ともかく、アーキテクチャって不思議でさ、出来上がった瞬間から、もう古びていくらしい。まあ、人も建物もそうだけど…。ビジネス環境は絶えず揺らぐし、新しい技術が突然現れて騒がしくなるし、「えっ？」って顔をするほど競合企業がとんでもない動きを見せることもある。その全部に翻弄されている場合じゃない。フェーズHでは、それら変化を制御する正式なプロセスを提供するんだけど…ちょっと待って、自分のお茶こぼした…（気を取り直して）。二つ目的がある。この段階で最初にやることは、実装した変更によって本当にビジネスケース通りの利益が出たのか確かめること。それだけじゃなくて、本当にその価値が現れたかどうかポスト実装レビューで必死に評価し直す。そして、その一連のループ…つまりアーキテクチャビジョンからスタートした流れをきちんと閉じるというわけ。

うーん、それよりも大事なのは、新しい**アーキテクチャ変更要求**に応える仕組みをちゃんと用意する部分かな、と個人的には思う。各事業部門から突然「新しい機能欲しい」と言われたり、最新技術せいで今まで使っていた仕組み自体が時代遅れ扱いされたり——そういったリクエスト全部、このプロセス経由で提出される流れになる。そこから先は、その変更提案が現在のアーキテクチャへ与える影響についてじっくり評価しつつ、リスクや新たなチャンスも秤に掛けて判断していく形になる。「まあ、面倒くさいよな」って思うけど、不意打ちな対応とか、その場しのぎばかりだった昔みたいにならないためにも、このプロセス重要なのかな、と結局思い直す。この手順踏むことで過去ありがちだった無秩序で混乱した変更嵐——要するにカオス状態ね——それ防げるわけだ。

あと、大規模な変更要求の場合はADM（Architecture Development Method）の新サイクル開始にもなる可能性高くて、その時にはまず特定部分向けの新たなアーキテクチャビジョン考案から入ったほうがいい。本当めんどくさい。でもこの終わらないループ機構によって、アーキテクチャ自体が常に進化中の資産として残り続けていき、それと同時並行的にビジネス全体も前進してゆく道筋作れる…多分。そしてまぁ、この仕組みあれば企業側として俊敏性とか柔軟性ギリギリ保てる感じになるらしい。

将来について想像するとさ…これからADM運用の意味合いや存在感もっと膨張してくだろうなという漠然とした予感あるよね。ジェネレーティブAIとか量子コンピューティング？インダストリアル・メタバース？そんな響きですら現実味帯び始めちゃった今、多数の組織では急激変革への耐性問われ続けそう。でも成熟したエンタープライズ・アーキテクチャプラクティス無い会社だとさ、その波来ただけでも転覆気味になっちゃって部分的・短命的意思決定しかできなくなりやすい。それ積み重なることで将来的IT負債とかシステム細分化につながりそうだよね。本気出せば良かったと思いつつ目先技術だけぽっと導入しちゃった挙げ句、自社戦略や既存システム整合まで頭回せなくなるパターン――まあありがち…。

逆方向としてADM等体系立ったプロセス根付いている企業なら、新規技術についても一歩引いて「本当にコアビジネス能力へ何寄与できる？」「有効活用には各層——ビジネス／データ／アプリケーション／テクノロジ領域それぞれ何調整必要？」など問い掛け可能になる。「そんなん難しすぎ」…でもフレームワーク通じ答え探せる余白残されている感じだろうか。また段階的価値創出＆リスク管理両睨み採用ロードマップ描写なども論理立て推進できたり…。ADMは容赦なく移ろう環境下ですら構造的対応力支えて、不測外圧にも冷静計画立案へ誘導する役割果たしているようだ。そのおかげで企業裁量幅拡大できたり自己決定域増すと言われても納得かな。

なんだか結局戻っちゃうんだけどさ……ADM等フレームワーク本質目的とは「固着プラン作成」じゃなく、「統制付き進化力」を組織能力として鍛錬・増強する点そのものと言えると思う。一度サボった自分への戒めでもある。

もしさらなるITアーキテクチャ戦略知識深掘りたいなら、一度覗いてみても損なし：https://itbookhub.com