エンタープライズアーキテクチャ（EA）｜As-isとTo-beの差を移行計画で埋める【ITパスポート】

EA（エンタープライズアーキテクチャ）は、組織全体の業務と情報システムを見える化し、全体として最適な形へ組み替えていくための手法です。

部門ごとの最適から、組織全体の最適へ
As-is と To-be ── 差を明らかにして移行計画を立てる
業務とシステムを4つの層で見る
見える化して組み替える ── 総合窓口の例
まとめ
この節で解ける公開問題

部門ごとの最適から、組織全体の最適へ

会社の情報システムは、たいてい部門ごとに必要になったときに作られます。営業部は顧客管理のシステムを、経理部は請求のシステムを、物流部は出荷のシステムを、それぞれ自分の仕事に合わせて入れていきます。1つずつ見れば、どれもその部門にとっては使いやすいシステムです。

ところが会社全体で見ると、同じ顧客のデータを3つのシステムがそれぞれ持っていて、住所が変わると3か所で直さなければならない、といったことが起こります。似た機能を何度も作れば費用が増え、システムどうしの仕様が合わないと、部門をまたいだ仕事でデータを受け渡しにくくなります。部門ごとには最適でも、全体としては最適ではない状態です（部分最適）。

部分最適と全体最適の比較。左＝部門ごとに作った状態：営業部・経理部・物流部がそれぞれ自分のサーバに顧客データを持っていて、同じデータと機能が重複し、つながりにくい。右＝全体を見て組み立てた状態：営業部・経理部・物流部の3つが、1つの共通の顧客データにつながっていて、重複がなく、部門をまたいでつながる。

部門ごとに作ると同じデータが3か所にでき、全体を見て組み立てると1か所で済みます。

EA は、この状態を組織全体から見直すための手法です。業務と情報システムが今どうなっているかを図や表に書き起こし、関係者のだれが見ても分かる形にしたうえで、どこをどう組み替えればよいかを考えます。 EA が目指すのは、1つのシステムの改善ではなく、業務と情報システムの全体最適です。

総務省は、地方公共団体向けに「自治体EA」という進め方をまとめています。そこでは、EA の取組みが情報システム部門だけのものになったり、作業を主に外部のコンサルタントや IT ベンダーが行ったりすることがあった反省から、業務を担当する職員が自ら現状を書き起こすことを重視しています。自分の知っていることを自分で書き起こすと内容が整理され、それまで気づかなかった業務の構造や課題に気づくこともある、という理由です。

As-is と To-be ── 差を明らかにして移行計画を立てる

As-is モデル（現在の姿）　… いまの業務と情報システムがどうなっているかを表したもの。課題を抱えた出発点

To-be モデル（あるべき姿）　… 目的を達成したときの、目標とする業務と情報システムの理想像

手順は次のとおりです。まず現状を把握して As-is を描き、目標とする理想像として To-be を描きます。次に、2つを比べて差（ギャップ）を明らかにします。そして、その差を埋めるための改善の活動を、どの順番で、いつ行うかを移行計画として決めます。

As-isからTo-beへの道筋。左＝As-is（現在の姿）、中央＝次期の姿（途中の段階）、右＝To-be（あるべき姿）を矢印で順につなぐ。上に、As-isからTo-beまでをまたぐ括弧「差を明らかにする」。下に、全体にわたる帯「移行計画 ── 差を埋める順番と時期を決める」。

現在の姿とあるべき姿の差を明らかにし、途中の段階を挟みながら差を埋める順番を移行計画にします。

制約がなければ To-be へいっぺんに移れますが、実際には法制度、組織、予算などの制約があるのがふつうです。そこで、一部の組み替えを終えた途中の段階（総務省の手引きでは「次期の姿」）を挟んで、段階的に近づけていきます。このとき To-be を先に描いておかないと、目の前の改善を1つずつ積み重ねるうちに、理想とは別の方向へ進んでしまうおそれがあります。To-be を明確にしてから、As-is との差を順番に埋めていくのが EA の進め方です。

ある会社が EA の考え方で、受注から出荷までの業務とシステムを見直しています。いまの業務の流れとシステムの構成を書き起こし、目標とする姿も描き終えました。次に行うこととして、最も適切なものはどれですか。

業務とシステムを4つの層で見る

EA では、業務と情報システムを4つの層に分けて捉えるのが代表的なやり方です（総務省の手引きもこの4階層です）。層ごとに図表に書き起こすと、複数のシステムをまとめて組み替える検討がしやすくなります。

業務の層から決め、データ・アプリケーション・技術の層はそれを踏まえて決めます。

EAの4つの層

ビジネス　… どんな業務を、どんな流れと機能で行っているか

データ　… 業務で扱う情報は何か、それがどんな構造になっているか

アプリケーション　… 業務を支えるために、どのシステムがどんな機能を持つか

技術　… システムを動かすハードウェア・ソフトウェア・ネットワーク

総務省の手引きでは、データ・アプリケーション・技術の層の検討は、ビジネスの層の検討を踏まえて行うとしています。先に業務をどう組み替えるかを決め、それに合わせてデータの持ち方やシステムの機能、使う技術を決める、という順番です。

層に分けると、複数のシステムに共通する部分も見つけやすくなります。たとえばデータの層では顧客や職員の情報、アプリケーションの層では利用者の認証やバックアップの機能、技術の層ではネットワーク基盤やセキュリティの基準を、個々のシステムから取り出して組織で1つにまとめられます。層ごとに共通部分を1つにまとめることで、重複と不整合を減らしていきます。

見える化して組み替える ── 総合窓口の例

総務省の手引きにある例を、簡単にして見てみます。ある市では、住民票の写し、印鑑登録証明書、所得証明書の交付が別々の業務として行われていて、住民はそれぞれの申請書に同じ氏名・生年月日・住所を何度も書く必要がありました。

市役所の証明書の受付を組み替える例。左＝現在の姿：住民が、住民票の写し・印鑑登録証明書・所得証明書の3つの窓口を回り、それぞれに申請書を出すので、同じ氏名・住所を3回書く。右＝あるべき姿：住民が総合窓口で1枚の申請書を渡す。申請書は1枚、受付も1か所。

業務ごとに分かれていた受付と申請書を、1つにまとめた姿が「あるべき姿」です。

業務を書き起こして並べてみると、3つの業務のどれにも「申請を受け付ける」「本人を確認する」「証明書を渡す」という同じ機能があり、申請書に書く申請者の情報も同じだと分かります。そこで、受付と交付の機能、申請者の情報をそれぞれ1つにまとめた総合窓口を To-be として描きます。窓口を1つにするだけでなく、申請者の情報を1つにまとめることまで決めておかないと、窓口が1つになっても住民は同じことを3回書くことになります。

EA は大きく次の順番で進めます（総務省の自治体EA の作業手順）。

1.　組み替えで達成したい目的と目標、組み替える項目とその実施時期の見通しを決める

2.　対象の業務の現在の姿（As-is）を書き起こす

3.　あるべき姿（To-be）を描く

4.　次の段階の姿と、そこでシステム化する部分を決めて、調達につなげる

現在の姿を書き起こすときには、業務の流れや機能、情報のやり取りを表す図を使います。業務流れ図（WFA）・機能構成図（DMM）・機能情報関連図（DFD）などの描き方は「ビジネスプロセス」の回（3-3）で扱っています。また、EA で描いたあるべき姿は、会社の情報システム戦略（2-3）や情報システム化基本計画を立てるときの土台になります。

似た名前と区別する

BI（Business Intelligence）は、蓄積したデータを分析して経営の意思決定に役立てることです。現状と理想の差を埋める計画を立てる手法ではありません。
MOT（Management of Technology、技術経営）は、研究開発の成果を事業の価値に結びつけるマネジメントです（イノベーション戦略の回）。
SOA（Service Oriented Architecture、サービス指向アーキテクチャ）は、情報システムを「業務やシステムの基本的な機能を提供するサービスの組み合わせ」として作る手法や技術です。システムの作り方の話で、組織全体を最適化する手法そのものではありません。

ある会社では、営業部と経理部がそれぞれのシステムに取引先の住所を登録していて、片方だけが更新されることがよくあります。EA の4つの層で見たとき、取引先の情報を1か所にまとめて両方の部門が使うようにするのは、主にどの層の見直しですか。