アーキテクチャを手の内化するアーキテクチャガバナンス

新たな時代のアーキテクチャガバナンス：変化に柔軟に対応するためのアプローチ

はじめに

デジタル化が進む現代において、企業のITデジタル基盤やアーキテクチャは、従来の枠組みを超えて大きな変革を迫られている。この変革を成功させるためには、従来のITガバナンスの枠組みだけではなく、新しいアプローチが必要とされている。そこで注目されるのが、「変化に追随しながらガバナンスを効かせる」という新たなガバナンスの考え方である。

従来のITガバナンスは、ルールや規定に基づいて堅牢な統制を行うことが重視されてきた。しかし、デジタル時代の進展に伴い、ビジネス環境の変化が激しい今日、従来のガバナンスの枠組みでは、ビジネスの変化やテクノロジーの進化に追従することが難しくなってきている。ビジネスのニーズやテクノロジーの進化に追随するためには、迅速性や柔軟性が不可欠となるため、従来のITガバナンスとは異なる視点や、変化に対応するための手法が必要となってきている。これは、単なるルールや規定でガチガチに固めるのではなく、変化を捉えながら適切なガバナンスを実践していくことを意味している。

本稿では、従来のガバナンスが抱える課題を理解することから始め、新しいアプローチの必要性を明らかにし、新たな時代のアーキテクチャガバナンスについて探究する。さまざまな事例やベストプラクティスを通じて、柔軟性と安定性を両立させる新しいガバナンスの手法について考察する。

従来のガバナンスにおける課題

従来のITシステムでは、部門やプロジェクトごとに独自のシステムが導入され、それぞれのシステム間で大きなギャップが生じていることが多く見受けられる。例えば、異なるシステム間でデータ連携ができない、運用が個別最適となっている、セキュリティレベルが個別最適でシャドーITの台頭や情報漏洩リスクが高い、ソフトウェアやハードウェアの個別調達や個別運用となっていてコスト高を招いているなど、様々な課題を内包している。また、クラウド時代においては、グローバル展開する企業にとって、海外子会社のIT統制が課題となるが、従来は各拠点で独自のITインフラを持つことが一般的であったものの、クラウドの普及により、本社と同じクラウドを利用することが容易になってきている。このような状況下で、システムの構造や製品や設計ルールを統一するというITガバナンスの強化が進んできている。

しかし、これが、ビジネス環境の変化に対する迅速性や即応性の阻害になっていることもまた事実となっている。

従来のITガバナンスがビジネスの変化に対応できない原因はいくつか考えられる。

• 過剰な規制と制約：従来のITガバナンスは、厳格な規制や制約を課すことが一般的であった。これにより、ビジネス部門やプロジェクトが柔軟に新しいテクノロジーやシステムを採用することが困難となり、ビジネスの変化に対応するための柔軟性が制限され、イノベーションや変革が阻害される要因となっている。
• 分業化された組織構造：従来の組織構造では、IT部門がビジネス部門とは独立した存在として機能している。このため、ビジネスのニーズや変化に対応するためのコラボレーションが不足し、ビジネス部門とIT部門の間での意思疎通が困難となる要因となっている。
• プロセスの煩雑化：従来のITガバナンスでは、意思決定や変更のプロセスが煩雑化しており、変更を実装するためには多くの承認や手続きが必要となっている。このため、ビジネスのニーズが迅速に変化しても、ITシステムの変更には時間がかかり、適切なタイミングで対応できない要因となっている。
• 技術の遅れ：従来のITガバナンスでは、ルールや標準が定義されているという理由で、古い技術やアーキテクチャに固執してしまい、新しいテクノロジーやアーキテクチャへの適応が遅れてしまう。このため、結果的にビジネス環境が急速に変化する中で、最新テクノロジーの取り込みができず、ビジネスのニーズに適切に対応できなくなる要因となっている。

ITガバナンスとITマネジメントプロセスについて

本来、ITガバナンスは、組織がITを適切に活用する能力のことを示し、経済産業省の定義なども踏まえると、ITガバナンスは情報システムのあるべき姿を示す戦略の策定と実現に必要となる組織能力のことを示し、具体的には、どのようなビジネス要求があり、経営を取り巻く環境変化のスピードがどれくらいで、テクノロジーとしてはどのような要素が必要となり、それらをどのように実現していくか、そのためにどのような組織体制が必要であるかを検討するものとなる。また、ITマネジメントという言葉もあるが、これは、情報システムの企画、開発、保守、運用といったライフサイクルを管理するためのマネジメントプロセスのことを示しており、IT マネジメントとそのプロセスに対して、経営陣が評価し、指示し、モニタすることがITガバナンスにおける経営陣の行動として定義される。

ここで重要なポイントを1つあげておく。ほとんどの日本企業においては、 ITガバナンスという言葉で示されるのは、ITガバナンスとして経営陣がモニタ・評価する対象となるITマネジメントにおける管理業務のことであることが多い。この際、 ITガバナンスやITマネジメントプロセスの検討をSIerやコンサルタントに丸投げしてしまい、様々なプロセス実施のためのガイドラインや標準が定義され、組織のIT部門はITマネジメントのプロセスを標準どおりに実施できているかどうかが評価のKPIとなってしまい、硬直的にITシステムのマネジメントを行うことがITガバナンスの歪曲化された目的となってしまっていることが多く見受けられる。

本来的にはITガバナンスの目的に鑑みて、経営陣は、経営戦略の方針に基づいて情報システム戦略の方針・目標設定及び情報システム化基本計画を策定し、適時見直しを行っていくことが必要であり、ビジネスの将来を描き、柔軟に対応するための枠組みとするべきである。この点で重要な役割を果たすのが、エンタープライズアーキテクチャである。ビジネスの方針を踏まえてITやデジタルの方向性をどのようにするかを定義するものがアーキテクチャであるため、ITガバナンスを議論する際にはアーキテクチャの議論は切っても切り離せないものとなる。また、ITガバナンスを支えるITサービスマネジメントプロセスにおいても、エンタープライズアーキテクチャの管理がそのうちの一要素として含まれており、アーキテクチャとガバナンスはセットで議論されるべきものとなっている。

なお、ITガバナンスの検討支援をSIerやコンサルタントに丸投げしてしまい、ベンダの担当者がアーキテクチャに関する知見がないままITガバナンスについて検討を進められてしまうと、アーキテクチャの検討がすっぽり抜けてしまうので注意が必要である。

ビジネスの未来を築くためのアプローチ

それでは、ビジネス変化に資するアーキテクチャと、 「変化に追随しながらガバナンスを効かせる」という新たなガバナンス検討を進めるためのアプローチについて見ていこう。

従来のアーキテクチャ検討は、主にITシステムそのものの整備と効率化を目指しており、このアプローチでは、テクノロジーの統合と標準化が中心であり、業務要件の徹底的な分析と一方通行のアプローチが取られることとなる。また、IT専門チームが中心となり、標準化された規定文書に基づく厳密なガバナンスが行うものとなることがほとんどである。

一方、デジタル・クラウド時代のアーキテクチャ検討は、企業の市場価値創出と変化への迅速な対応が求められおり、このアプローチでは、トランスフォーメーションとイノベーションが重視され、問題解決アプローチとアジャイルな手法が採用されるものとなる。規定文書に基づく厳密なガバナンスではなく、最小限のガバナンスと最大限のサポートが重視されており、さらに、企業全体を俯瞰した視点でアーキテクチャを構築し、明確で創造的なコラボレーションが重視されている。

従来のアプローチでは、ITシステムの整備と効率化を主眼に置き、コスト削減を志向してしていたが、デジタル・クラウド時代のアプローチでは、市場価値創出と変化への迅速な対応が求められるため、効果最大化を目指すものとなっている。このように、従来のアプローチとデジタル・クラウド時代のアプローチとでは、目的、手法、視点や志向などに大きな違いがある（図1参照）。

アーキテクチャとアーキテクチャガバナンスの関係

アーキテクチャとアーキテクチャガバナンスの関係は、都市計画と都市整備局の関係に例えることができる（図2参照）。都市計画は将来の街づくりのビジョンを描き、商業区画や住宅地などの機能配置を考えるものである。一方、都市整備局はその計画に基づいて街づくりを実現し、統制を図るものである。ここで、重要となることは、ルールや規制に囚われることなく、柔軟性と即応性を保つということである。例えば、少子化により都市計画が思うように進まない場合、移住支援制度を導入するなどの柔軟な対応が求められる。

デジタル・クラウド時代におけるアーキテクチャガバナンスも同様で、これは新しいルールや規約に縛られるものではなく、むしろ、ビジネスの将来を見据え、アーキテクチャのビジョンに基づき、ポリシーや、プロセス、ケイパビリティを持って柔軟な統制を行うものとするべきである。

一方で、従来のITガバナンスの議論では、アーキテクチャの本質を見落としがちであった。多くの場合、個別のツールや管理プロセスに焦点を当て、全体像を見据えないまま取り組むことが多くあった。しかし、アーキテクチャは単なるツールやプロセスではなく、それはビジネスの将来を描くための枠組みであり、重要な戦略的アセットであるべきものである。

先に述べたとおり、ITガバナンスの考え方そのものに問題があるのではなく、ITガバナンスの議論のときに、その前提となるアーキテクチャ議論をすることを認識できていない、または認識できていてもアーキテクチャがわかる人材が社内にいないことが問題となることが多い。社内にアーキテクト人材がいれば、検討を依頼したSerやコンサルタントがアーキテクチャ検討を漏らしてしまっていても、指摘をして正しい方向へ検討を進めることができる。

アーキテクチャ“の”ガバナンスプロセス

アーキテクチャ構想の継続的な見直し

ここから、従来のITガバナンスに加えて、デジタル・クラウド時代に求められるアーキテクチャガバナンス実践の考え方について見ていこう。

1つ目は、アーキテクチャ自体を見直すプロセスである。一度定めたアーキテクチャについて後生大事に抱えて蔵の中に大事にしまっておいては、変化の激しい経営環境下において、常に最新テクノロジーが出現し、テクノロジーのベストプラクティスも変化する中で、定義したアーキテクチャが陳腐化し、結果的にビジネス変革の足枷となってしまう。このため、デジタル・クラウド時代のアーキテクチャガバナンスについては、アーキテクチャ自体をきちんと継続的に見直すことをプロセス化することから始める必要がある。

図3に、アーキテクチャ自体を見直す際の検討プロセスを図解した。ここでは、アーキテクチャについて定義した文書を「アーキテクチャ構想」と呼ぶものとする。アーキテクチャ構想自体は、概ね年単位で見直すものとし、見直す際は、前年度版のアーキテクチャ構想をインプットとし、ビジネス要求や最新テクノロジーの情報をもとにして見直していくものとする。

• 戦略の確認：目指すべき中長期におけるビジネス目標を踏まえた上で、ビジネスとITの最新の方向性や、戦略の最新の状態を確認するとともに、中期経営計画等で定められた経営戦略や、IT戦略を確認する
• 新規ビジネス要求の確認：ビジネス部門から上がってくるIT部門に対する要望（小さいものであれば、特定システムの改修要望のようなものになるが、翌年の新規システム化企画や、影響が大きいものであれば基幹系の刷新計画等が含まれる）の中から、現状のアーキテクチャ定義に影響する可能性のある新たなビジネス要求の有無を確認する
• 実現性分析：新たなビジネス要求が現状のアーキテクチャの範囲内で実現できるかを確認し（現状のアーキテクチャ定義に影響する可能性のある新たなビジネス要求は、大概は“大玉”のビジネス要求となりえる）、一方で、クラウドサービスプロバイダーから新たなサービスがリリースされているかや、新しいテクノロジーのトレンドがどうなっているかについても確認し、どのようなテクノロジーを用いることでビジネス要求が実現できるかについて検討する
• アーキテクチャの更新：新たなビジネス要求と、各アーキテクチャの要素の整合性を考慮して、アーキテクチャ定義を前年度の内容から更新する。“都市計画”としてのアーキテクチャが全くガラリと変更となることは少ないと考えられるが、新たなビジネス要求を踏まて、新たなコンポーネントが必要となることや、もともと導入要否検討自体を先送りしていた対象が必要となる事もありえる。追加コンポーネントがあればそれをアーキテクチャ図に反映し、ほかの機能要素との関係性を明確化する
• ロードマップ更新：アーキテクチャ定義の更新の際に、アーキテクチャの実現ロードマップについて、前年度にどこまで実現が進んでいるかについて反映したうえで、新たなテクノロジーコンポーネントの導入を計画として織り込む。その場合、既存テクノロジー要素との関係性を踏まえて実行順序の見直しをおこない、アーキテクチャ実現ロードマップについても更新する。

この継続的な見直しを行っていくのは誰か。全社アーキテクチャの目指す姿自体が変わらなかったとしても、新しいビジネス要求のうちアーキテクチャに影響する施策や、新しいテクノロジーサービスについてきちんと把握し、アーキテクチャ構想に反映して各部門へ展開することが必要となるため、それが行えるケイパビリティを持ったメンバーをきちんと集めて、“アーキテクトチーム”とすることが必要となる。

アーキテクチャ“による”ガバナンスプロセス

企画フェーズにおけるアーキテクチャレビュープロセスのシフトレフト

2つ目は、個々のシステムアーキテクチャが全体アーキテクチャに沿ったものとなるように統制を掛けていくためのプロセスについてである。

日本企業においては、アーキテクチャの設計レビューとして、要件定義フェーズ、基本設計フェーズ、詳細設計フェーズといったフェーズごとに、設計内容の妥当性や品質をチェックするプロセスが整備されていることがある。設計確認会、SDR（システムデザインレビュー）、フェーズゲートなど、会社によって呼び名は様々だが、設計やスコープやコストなども加味して次のフェーズまで進めてよいかを検討するものとなっているはずだ。これに加えて、システム導入のライフサイクルの中で、テクノロジーの検討状況をアーキテクト目線でレビューするための仕掛けとして、「ARB：Architecture Review Board」というプロセスを企画フェーズより実施するものとして導入することが、デジタル・クラウド活用の時代においては必要となる。これは、通常の設計レビューを行うフェーズよりさらに上流フェーズで行うため、レビュープロセスのシフトレフトとなる（図4参照）。

一番重要となるのが、企画フェーズにおいてアーキテクチャレビューを実施するということである。

通常は、企画フェーズ後に調達を行うなどして、システム要件定義フェーズでSIerやITコンサルを調達して概要設計を行い、基本設計フェーズへ進めていく。その際に全体アーキテクチャが存在していないと、 SIerやITコンサルの得意なアーキテクチャ設計がその領域に特化して定義され、サイロ型のシステムの乱立を招いてしまう。そうならないように、企画フェーズ時点でアーキテクチャの検討をすることが重要となるのだ。

しかし、ビジネス部門から見ると、SIerやITコンサルの調達をしないままアーキテクチャ設計など出来ないということで、反発を招きかねない。理想的には、社内担当者が全社アーキテクチャに沿った個別システムアーキテクチャ検討ができることが望ましいが、実際には、企画フェーズでRFI（Request for Information）などを行ってSIerやITコンサルにて粗くても個別システムのアーキテクチャ検討をしてもらうことが望ましいだろう。

その際に、RFIに全社アーキテクチャの内容をきちんと添付して伝えておくことが何よりも重要となる。企画フェーズでアーキテクチャの方向性を揃えておくことで、後工程での大きな手戻りがなく、よりスピーディに、検討が進められるほか、例えば認証基盤やデータ連携基盤、共通基盤の整備有無などが把握できればそれを前提としてSIerやITコンサルが提案をすることが出来、似たような機能の乱立を防ぎコスト最適化につなげることが期待できる。

本取り組みにより、さらに2つの効果が期待できる。

• １つ目は、システム企画時にもれなく最新テクノロジーの活用検討がなされるようになることだ。日本企業でよく見られる「フェーズゲート」と呼ばれる品質管理プロセスでは、「プロジェクトを失敗させないこと」に主眼がおかれ、過去のバースト案件の教訓として、あくまでリスクヘッジが目的のレビューとなりがちであるため、そこに新しいテクノロジーが積極的に活用されているか、ビジネス上の価値に貢献できているか、についての検討の優先度が低くなりがちだ。ともすれば、新しいテクノロジーの活用はリスクとして排除される可能性すらある。企業としての品質管理を徹底することは極めて重要なことではあるが、行き過ぎたブレーキによってビジネスの足かせになることは避けるべきであり、ARBの導入によって全体アーキテクチャへのアラインと同時に、デジタルやクラウド活用のアクセルが踏み込まれることが期待できる。
• ２つ目は、ARBの導入によって企業内にテクノロジー活用のノウハウが蓄積されることである。単に情報として実践知が蓄積できることに加えて、対応するアーキテクトチームの育成も期待できる。ARBを対応するメンバーは、各担当領域の専門性を高められるだけでなく、アーキテクトとしての幅広い視点やビジネス・IT両面の経験を積むことができ、組織としてのアーキテクト力の向上にもつなげることが期待できる。

アーキテクトCoE体制の組成

スクラム体制としてのアーキテクト体制

3つ目は、社内におけるアーキテクト体制の組成である。

システム導入の上流工程において、適切なテクノロジーの選定とシステムアーキテクチャを構想するアーキテクトには、非常に広範な領域の知識と経験が求められる。ビジネスニーズに即したアプリケーション（昨今ではその多くはSaaSとして提供される）の最新知識に加え、クラウド活用やデータマネジメント、サイバーセキュリティーからオペレーションに至るまで、複数領域の視点をもって全体をデザインしなければならない。このようなケイパビリティを自前で確保するのは当然容易ではなく、結果としてアーキテクト体制が空白の状態が続き、企業としてのテクノロジー活用が進まない状況に陥っている。

そこで、アーキテクトの役割を特定の組織や人材に依存するのではなく、IT部門を中心とした組織から各専門家を集めて仮想的なチームとして、アーキテクトCoEを構築することが肝要である（図5参照）。そうすることで、求められる専門性を集合知で対応することができることに加えて、特定の組織や担当者の経験、ケイパビリティに左右されることのない体制を構築することができる。

アーキテクチャレビューにおけるレビューポイントは、ビジネスニーズや利用するテクノロジーによって様々であるため、一概にチェックリスト化は出来ず、有識者のケイパビリティに依存してしまうことになるが、レビュー観点としては大きく2点挙げられる。

1点目は、“都市計画”として定義した全社アーキテクチャの機能配置に反しない設計案となっているかどうかである。例えば、住宅街の区画に工場を建てようとしてしまっていないか、すでにある幹線道路と同じ用途の道路を新たに敷設しようとしていないか、といった観点である。何の目的でどの技術を使おうとしているのか、目的に反しないで共通機能の利用を検討しているかというチェックが必要となる。また、それに加えて、こういうことをしたいならこの共通基盤のこの機能を利用すると実現できるといったことをアーキテクトCoEから個々のプロジェクトへアドバイスできることが望ましく、各技術領域の利用有無が判明していなくても、可能な限り技術領域の有識者を全員揃えることが重要となる。

2点目は、実現性（フィジビリティ）の確認である。ITシステム導入における体制、スケジュール、スコープ、期間、インタフェース先との調整状況など、企画自体が絵に描いた餅とならないか、現実的なプランとなっているかという目線で確認することが重要である。

また、体制の組成にあたってのポイントは、その体制の中にビジネス部門も巻き込むことである。従来のように、ビジネス部門が要件を提示し、IT部門が実装方式を検討するといった一方通行の関係性では、どうしても互いの距離が縮まらず、より良いアイデアや最適な実現手段を見出しにくい。ビジネスニーズを把握しているビジネス部門と、デジタルに精通したIT部門の協業体制を構築し、システム化検討の初期段階から一緒になって検討を進めることで、テクノロジーの可能性を最大限に引き出すことができるようになることが期待できる。

アーキテクチャオペレーティングモデルの実践

デジタル・クラウド化を手の内化するためのプロセスとケイパビリティの獲得

4つ目は、アーキテクチャオペレーティングモデルの実践である。

テクノロジーの活用を進めていくためには、戦略立案の考え方、予算の立て方、統制の仕方など、あらゆる観点でオペレーティングモデルの再構築が必要であり、デロイト トーマツ グループ（デロイト）では、デジタルやクラウド活用を手の内化するために必要となるプロセスやケイパビリティについてパースペクティブ（観点）を定義したフレームワークをアーキテクチャオペレーティングモデルと呼んでいる（図6参照）。

例えば「ビジネス」パースペクティブでは、従来のオンプレミスを前提とした予算管理の考え方（５年償却を前提とした予算編成および四半期ごとの実績把握）から、as a Service利用における予算管理の考え方（従量課金を前提としたタイムリーな実績把握）への見直しを検討する。「セキュリティ」パースペクティブでは、ITやシステムに関する社内セキュリティ規定について、先進的なテクノロジーやサービス利用の阻害要因になるものがないかを再点検する。これらは、単なるルール変更だけではなく、新しいイニシアティブの開始やカルチャー・マインドの抜本的な見直しを伴うことも多い。

それぞれのパースペクティブにて、従来のビジネス＆IT組織の状態と、デジタル・クラウド活用を進めるために必要なことを対比することで、それぞれのパースペクティブで検討するべきことを確認しておく（図7参照）。

• ビジネスパースペクティブ：従来は、年間計画通りに実行すること自体が目的化してしまい、決まったことのみを遂行している組織から、環境変化やビジネス価値を意識して、自律的にアジャストしてビジネス成果創出へつなげるためにクラウドを活用できる組織への変革が求められる。
• ピープルパースペクティブ：従来は、IT部門がビジネス部門の現場要件の“御用聞き”であり、かつ現業の運用保守のみで手一杯である組織から、クラウドを活用できるためのスキル向上、新たな取組にヒトを振向ける組織調整など、変化に先回りして問題解決ができる組織への変革が求められる。
• ガバナンスパースペクティブ：従来は、設計や開発にかかる標準や規定にて統制している組織から、クラウドネイティブな仕組みを用いてKPIや構成管理を行うなど、最小限の統制と最大限の価値創出につなげられる組織への変革が求められる。
• サービスストラテジーパースペクティブ：従来は、社内ITサービス利用者の利便性を向上させる戦略的取組はなく、利用者側で煩雑な手続きを必要とする組織から、セルフサービス型で利用者自らが迅速に業務を遂行できるよう、サービス標準化と現場への権限移譲を実施できる組織への変革が求められる。
• テクノロジーパースペクティブでは、従来は、手組のアプリケーション開発や、インフラ環境の個別の都度対応など、オーダーメード対応している組織から、アプリは“ありもの”機能の組合わせで開発し、インフラの設計・構築・運用も自動化することで俊敏性を確保できる組織への変革が求められる。
• セキュリティパースペクティブでは、従来は、境界型セキュリティがメインで、膨大なアラートへの対応負荷が高く、真に対応が必要な案件に対応できない組織から、ゼロトラスト前提のセキュリティ機能整備とセキュリティ運用自動化により自由度と統制の両立を実現できる組織への変革が求められる。
• オペレーションパースペクティブでは、従来は、部門ごとに独自のIT資産を保有し、個別の役割・責任定義をしていて膨大な時間・負荷がかかる組織から、ハイパースケーラの豊富な機能や責任共有モデルを前提として、迅速で柔軟なサポートを可能な組織への変革が求められる。
• データパースペクティブでは、従来は、一部の利用者が特定のデータを収集・分析しているが、固定的な分析に制限され、変更にはベンダの支援が必要となる組織から、組織全体のデータから誰もがインサイトを導出できるよう、データ活用基盤と統制体制を自社で整備・運営している組織への変革が求められる。

まとめ

アーキテクチャを手の内化するアーキテクトの獲得

日本の多くの企業では、ビジネス部門が最新テクノロジーを取り入れようとしても、固定的な社内規定が障壁となるほか、また、新しいチャレンジの人柱となることを避け、変化に消極的な反対勢力が足かせとなって導入が進められないケースがよく発生している。IT部門もニーズに応じて順次見直しを進めているものの、必要性が生じたものからその場しのぎの対応に追われている状況ではないだろうか。

本稿では、企業がビジネス変革を加速するためにデジタル・クラウドを活用した全体アーキテクチャを定義し、個々の施策においてアーキテクチャに沿った検討ができ、プラスアルファとして新たなテクノロジー活用を提案できる社内コンサルとしてのアーキテクト体制が必要となることを述べてきた。

このアーキテクト体制は、特定の組織だけで実現すべきものではない。ビジネス部門が実現したい業務に必要なテクノロジーの選定をすべてIT部門が決めるような中央集権的体制では、スピード感が損なわれてしまう一方で、ビジネス部門に自由度を持たせすぎると野良IT（シャドーIT）の量産につながり、企業としてのコントロールが効かなくなる。目指すべき姿は、ビジネス部門とIT部門の協業体制を構築し、併せて最低限のセキュリティやガバナンスをガードレールとして担保できる環境を整備することで、自由と統制の両立を実現することである。

ここで少しITサービスマネジメントについて言及しておく。ITサービスマネジメントのフレームワークとしてはITIL®が有名であるが、当初のITIL®は「インシデント管理」「問題管理」「変更管理」「リリース管理」「構成管理」といったサービスサポートプロセスと、サービスレベル管理などを含むサービスデリバリが主眼だったが、プロセスが一次元的であることが課題であった。その対応として、継続的サービス改善の観点を入れたのがITIL®v3/2011となっている。さらに、デジタルトランスフォーメーションの潮流の中で、顧客への新たな価値創出やエコシステムの観点を取り込んだものがITIL®4となり、そこから複数のサービスプロバイダの管理や、ITだけでなく事業含むサービス全般という観点を取り込んだものがSIAM^TMと呼ばれるフレームワークとなっている。

本稿で述べているアーキテクチャとアーキテクチャガバナンスも、デジタルトランスフォーメーションの潮流の中で、継続的に見直すプロセスが重要であることを述べてきた。また、ITとしてのコスト削減という観点だけでなく、事業の価値創造を見据えること、複数のアズアサービスの組み合わせで成り立つアーキテクチャに対して、複数の有識者で対応していくことを述べてきたが、ITIL®からSIAM^TMへの歴史と流れと同じ観点が取り込まれていることと比較すると、理解の一助になるだろう。

ビジネス変化に対応するために真の意味でデジタルやクラウドテクノロジーを活用できるようにするためには、将来の足かせにならないように先回りして備えていくことが極めて重要となる。裏を返せば、先に述べたオペレーティングモデルをしっかりと整備することで、企業としてデジタルネイティブなケイパビリティを獲得することができ、アーキテクト力を強化することにつながるであろう。

その実現に向けた取り組みとして、アーキテクトCoEの構築やアーキテクチャオペレーティングモデルによるIT部門の変革は有効な手段となり得る。本稿の内容も参考にしつつ、ぜひこの機会に、ビジネス変化に対応できるアーキテクチャと、そのアーキテクチャを手の内化するアーキテクト体制の獲得に向けた取組みを進めてほしい。