LASSIC Media らしくメディア
エンタープライズアーキテクチャ(EA)整備を外注で進める
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- EAとは、業務とシステムをビジネス・データ・アプリケーション・テクノロジーの4層で捉え、全体最適の視点から整理する設計手法です。
- 代表的な枠組みTOGAFはThe Open Groupが策定し、ADMという反復型のプロセスでアーキテクチャを整備していく考え方を示しています。
- 経済産業省は2018年のDXレポートで、部門ごとに個別最適化されたレガシーシステムがデータ活用の壁になっている点を指摘しました。
目次
エンタープライズアーキテクチャ(EA)とは何か——4層で全社を捉える手法
エンタープライズアーキテクチャ(EA)とは、組織全体の業務と情報システムを、ビジネス・データ・アプリケーション・テクノロジーという4つの体系で整理し、全体最適の観点から見直すための設計・管理手法を指します。日本では経済産業省が2003年にEA策定ガイドラインを取りまとめ、2004年度から各府省で「業務・システム最適化計画」の策定が始まりました*3。独立行政法人向けにも同様の計画策定が求められており、IPA(独立行政法人情報処理推進機構)のサイトには、平成17年6月29日の各府省情報化統括責任者(CIO)連絡会議決定にもとづく最適化計画が公開されています*3。
4つの体系は独立した資料ではなく、上位の意思決定が下位の設計を規定する関係にあります。経営戦略や業務プロセスを定義するビジネスアーキテクチャがまず土台となり、そこで扱うデータの構造をデータアーキテクチャが定め、それを処理するシステム群をアプリケーションアーキテクチャが描き、最後に稼働基盤をテクノロジーアーキテクチャが支えるという流れです。個々のシステム設計とEAが異なるのは、この上下関係を全社横断で一枚の絵として持つ点にあります。
なぜ今EA整備が求められるのか——サイロ化・レガシー化と「2025年の崖」
EAという考え方自体は2000年代前半から存在していますが、あらためて注目される背景にはレガシーシステムの問題があります。経済産業省が2018年9月7日に公表したDXレポートでは、多くの企業でレガシーシステムが事業部門ごとに個別最適化されており、部門横断的なデータ活用が難しい状態になっていると指摘されました*5。同レポートは、この課題を克服できなければ2025年以降、現在の約3倍にあたる年間12兆円規模の経済損失が生じる可能性があるとも試算しています*5。
個別最適の積み重ねは、システムの重複投資や連携の複雑化を招きます。担当者の異動や退職によって設計の経緯が分からなくなり、システムがブラックボックス化していく点も同レポートで触れられている課題です*5。EAは、こうした個別最適の積み重ねを俯瞰し、全社としてどこに重複があり、どこを刷新すべきかを判断するための共通言語として位置づけられます。
政府部門でも、データそのものの標準化という形でアーキテクチャ整備は続いています。デジタル庁は政府相互運用性フレームワーク(GIF)を公開し、行政機関がデータモデルを共通化することでシステム間のデータ連携と相互運用性を高める取り組みを進めています*4。これはEAの4層のうちデータアーキテクチャに相当する領域を、政府横断で標準化しようとする実践例といえます。
代表的な枠組みTOGAF——ADMによる反復整備という考え方
民間企業でEAを整備する際によく参照される枠組みがTOGAFです。TOGAFはThe Open Group(グローバルなコンソーシアム)が策定するエンタープライズアーキテクチャのための方法論およびフレームワークで、1995年に米国防総省のTAFIMを基に開発が始まりました*1*2。対象領域はビジネス・データ・アプリケーション・テクノロジーの4段階でモデル化されており、EAの一般的な4層構成とも対応しています*2。
TOGAFの中核にあるのがADM(Architecture Development Method)です。The Open Group Japanのサイトでは、TOGAF標準を構成する要素としてADMが挙げられ、ADMの適用方法やガイドラインが用意されていると紹介されています*1。ADMは一度作って終わりではなく、現状分析から将来像の設計、移行計画、実装後の見直しまでを繰り返す反復型のプロセスとして設計されている点が特徴です。
ここで押さえておきたいのは、TOGAFは特定のツールや製品を指すものではなく、アーキテクチャを整備する際の考え方や成果物の型を提供する枠組みだという点です。自社の規模や業種に合わせて、必要な部分だけを取り入れる使い方も一般的に行われています。本稿でも特定の資格取得や製品導入を前提とせず、考え方の骨格として紹介するにとどめます。
4つのアーキテクチャがそれぞれ何を扱うかを整理すると、次のようになります。
| アーキテクチャ | 主に扱う対象 | 検討する主な問い |
|---|---|---|
| ビジネスアーキテクチャ(BA) | 経営戦略・組織・業務プロセス*2 | どの事業をどう組織で回すか |
| データアーキテクチャ(DA) | 論理・物理データ資産の構造*2 | どのデータを誰がどこで持つか |
| アプリケーションアーキテクチャ(AA) | 個々のアプリと業務プロセスの関係*2 | どのシステムがどの業務を担うか |
| テクノロジーアーキテクチャ(TA) | インフラ基盤・技術標準*2 | どの基盤・標準で稼働させるか |
As-IsからTo-Beへ——現状の可視化が全体最適の出発点になる
EA整備の実務で最初に着手するのは、多くの場合As-Is(現状)の可視化です。どの部門がどのシステムを使い、どのデータをどこで保持し、どのインフラの上で稼働しているのかを、4つの体系に沿って棚卸しします。この段階で、同じ機能を持つシステムが複数の部門で重複して運用されている実態や、担当者しか把握していない連携の存在が明らかになることが少なくありません。
As-Isが整理できたら、次にTo-Be(将来像)を描きます。経営戦略や事業計画から逆算して、どのようなビジネスアーキテクチャが必要かを定め、そこから必要なデータ・アプリケーション・技術基盤の姿を導く順序です。TOGAFのADMも、現状分析から将来のアーキテクチャを設計し、移行計画へつなげる流れをとっています*1。
As-IsとTo-Beの間にあるギャップこそが、実際の投資判断やシステム刷新計画の材料になります。可視化を怠ったまま個別のシステム更改を進めると、更改後にまた別の重複や不整合が生まれかねません。EAはこのギャップを継続的に見える形にしておくための土台という位置づけです。
重複排除とレガシー刷新の判断軸としてのEA
EAが実務で役立つ場面の一つが、システムの重複排除です。全社のアプリケーション一覧をアーキテクチャの観点で並べると、似た機能を持つ複数のシステムが別々の予算で維持されているケースが見えてきます。統合すべきか、機能を残しつつ基盤だけ統一すべきかは、ビジネスアーキテクチャ側の要件と照らし合わせて判断することになります。
レガシーシステムの刷新においても、EAは優先順位づけの軸になります。テクノロジーアーキテクチャの観点でサポート切れが近い基盤を洗い出し、その上で稼働しているアプリケーションがどの業務プロセスに関わるかをビジネスアーキテクチャ側から確認する、という双方向の突き合わせです。この突き合わせがないまま個別部門の要望だけで刷新順を決めると、全社としての投資対効果が見えにくくなります。
逆にいえば、EAは一度整えれば終わりというものではありません。事業の変化や技術の入れ替わりに合わせて、As-Isの棚卸しとTo-Beの見直しを繰り返す運用が前提になります。ドキュメントの更新体制をどう維持するかも、整備を始める段階からあわせて検討しておきたい点です。
小さく始めるEA整備——優先領域の選び方と進め方
全社のEAをいきなり網羅的に整備しようとすると、対象範囲が広すぎて途中で頓挫しやすくなります。実務では、影響の大きい特定の事業領域やシステム群からスコープを絞り、そこで4つのアーキテクチャを整理する進め方が現実的です。対象を絞ることで、棚卸しにかかる期間や関係部門の負荷も見積もりやすくなります。
進め方の目安は次の通りです。まず対象領域を決め、関係部門へのヒアリングを通じてAs-Isの情報を集めていきます。次に集めた情報をビジネス・データ・アプリケーション・テクノロジーの4層に整理し、重複や不整合を洗い出す流れです。そのうえで経営方針と照らしたTo-Beを描き、優先度をつけた移行計画に落とし込みます。TOGAFのADMが示す反復サイクルも、この一連の流れを継続的に回すための考え方です*1。
小さく始めた領域で成果が見えてくると、整理の型や様式を他の領域へ横展開しやすくなります。最初の対象領域の選定を誤ると効果が実感しにくくなるため、経営インパクトが大きく、かつ関係者を巻き込みやすい領域から着手する判断が求められます。
内製と外注の分かれ目——EA整備を外部に依頼する際の視点
EA整備を内製で進めるか外部に依頼するかは、社内にどれだけ横断的な調整力と可視化のノウハウがあるかによって変わってきます。対象領域が一部門に閉じている場合は、その部門の担当者が主導して整理できることもあります。一方、複数事業部やグループ会社をまたぐ規模になると、利害調整や情報収集だけでかなりの工数がかかる点に注意が必要です。
外部に依頼する場合は、依頼範囲の明確化が選定の分かれ目になります。As-Isのヒアリングと可視化だけを依頼するのか、To-Beの設計や移行計画の策定まで含めるのかによって、必要なスキルセットも変わってきます。ヒアリング対象部門との調整をどこまで委託先が担うかも、契約前にすり合わせておきたい点です。
また、EA整備は一度きりの調査で終わらせず、その後の運用・更新体制まで見据えて依頼先を選ぶことが実務的です。元請（プライムベンダー）として全社システムの保守・運用に関わっている企業であれば、As-Isの実態把握とその後の刷新プロジェクトへの橋渡しを一貫して担いやすくなります。
まとめ：EA整備で押さえる3つの視点
本稿ではエンタープライズアーキテクチャ(EA)の考え方を、公的情報にもとづいて整理しました。要点は3つです。第一に、EAは業務とシステムをビジネス・データ・アプリケーション・テクノロジーの4層で捉え、全体最適の視点から見直す手法です*3。第二に、TOGAFに代表される枠組みは、As-Is分析からTo-Be設計、移行計画までを反復的に回すADMという考え方を提供しています*1*2。第三に、経済産業省が指摘した個別最適化されたレガシーシステムの課題を踏まえると*5、EAは重複排除やレガシー刷新の優先順位を判断するための共通言語として機能します。
よくある質問
エンタープライズアーキテクチャ(EA)とDX推進の関係を教えてください。
経済産業省のDXレポートは、部門ごとに個別最適化されたレガシーシステムが、全社的なデータ活用の妨げになっていると指摘しています*5。EAは業務とシステムを4つの体系で俯瞰する手法であり、この個別最適の状態を可視化し、DX推進に向けた刷新の優先順位を検討する材料になります。
TOGAFを導入しないとEAは整備できませんか。
TOGAFはEA整備でよく参照される枠組みの一つですが*1*2、必須の資格や製品ではありません。自社の規模や課題に合わせて、ビジネス・データ・アプリケーション・テクノロジーという4層の考え方だけを取り入れ、自社の様式で整理を進める企業もあります。
全社的なEA整備は、どこから手をつければよいですか。
最初から全社を網羅しようとすると範囲が広がりすぎるため、経営インパクトの大きい特定の事業領域やシステム群からAs-Isの棚卸しを始める進め方が現実的です。対象を絞ったうえで4つの体系に整理し、そこで得た型を他領域へ広げていく流れが一般的です。
EA整備の外注を検討する際、何を確認すればよいですか。
As-Isのヒアリング・可視化のみを依頼するのか、To-Beの設計や移行計画の策定まで含めるのかを、まず自社側で整理します。そのうえで、複数部門にまたがる調整をどこまで委託先が担えるか、整備後の運用・更新体制まで支援範囲に含まれるかをすり合わせておくと、依頼後のギャップを抑えやすくなります。
EA整備にはどのくらいの期間がかかりますか。
対象範囲や関係部門の数によって幅があり、一律の目安を示すことは難しいというのが実情です。特定の事業領域に絞ったAs-Isの棚卸しとTo-Beの整理であれば比較的短期間で着手できますが、複数事業部やグループ会社を含む全社規模になると、ヒアリングと合意形成に相応の期間を要します。まずは対象範囲を確定させたうえで、外部の支援先とスケジュールをすり合わせることをおすすめします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：The Open Group Japan「TOGAF®」（https://www.opengroup.or.jp/togaf.html）
- *2 出典：The Open Group「TOGAF」（https://www.opengroup.org/togaf）
- *3 出典：IPA「業務・システム最適化計画」（https://www.ipa.go.jp/about/disclosure/teikyo/jouhou/saitekika.html）
- *4 出典：デジタル庁「政府相互運用性フレームワーク（GIF）」（https://www.digital.go.jp/policies/data_strategy_government_interoperability_framework）
- *5 出典：経済産業省「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（2018年9月7日、デジタルトランスフォーメーションに向けた研究会）※公式サイトがアクセス制限のため、URLの直接掲載は控えます。
