いよいよ「業務・システム最適化計画」の最終ステップである移行計画です。
業務・システム最適化計画はこのフェーズまでがまとめられて、調達のステップであるRFP（Request For Proposal）へと進みます。
ここでの移行計画は通常いうシステムの本番移行とは若干意味合いが異なります。
IT新改革戦略でも電子政府システム構築完了を2010年としているわけですから、2006年から調達を開始しているシステムは今後5年間を3フェーズに分割して導入していくことになります。
将来体系はあるべき姿を描いていますので、3フェーズを経て現行体系から将来体系へ移行していくことになります。
例として、ある国家試験の願書受付業務の将来体系が「インターネットによる願書ダウンロードとインターネットによる願書申請」であったとしましょう。
この形態ですと業務工数もスピードも格段に向上すると思われますので、この方向を将来体系の業務とします。そうしますと、いろんな問題が発生してきます。
国家試験は誰でも受験資格がありますので、“インターネットが出来ない人やその接続環境の無い方は受験できません。”とは言えないわけです。
また、インターネットだけでは不安なので窓口に来て相談される方も有りますし、身障者や僻地の方もいます。“何時、窓口受付業務を停止し、インターネットとTELだけの状態に持っていくか”など課題が出てきます。
そうしますと、5年後のあるべき姿としては、“窓口受付や郵送受付は残し、インターネットによる願書申請を50％以上にする”というようなあるべき姿が出てきます。
この業務の姿に向けて移行計画を作成していくことになります。移行計画としては、第1ステップは「業務プロセスの標準化」、第2ステップは「電子申請業務システムの導入・運用」、第3ステップで「モニタリングや業務効率化のための情報の共有・分析」の移行方針を策定しますと、この目標に沿った実施計画が組まれ、各移行フェーズのBA、DA、AA、TAの体系を作成し、最適化計画を完成させていくことになります。
第１３６回はここで終了します。
この回で最適化計画のステップは全てカバーしましたのでEAのテーマは終了しようと思います。
“EAが少しは身近なものになりましたか？”
皆様方の実務へ何らかの形で反映でき、お役に立てば幸甚の限りです。
次回以降のテーマは、私の書いた雑誌記事「最先端の経営リスクを追う！」 （アスキービジネス）
から、日本版SOX法として注目を集めている内部統制の中でITに焦点を当てた「IT内部統制」を取り上げようと思います。
題材は「サーベンズ・オクスリー法（企業改革法）遵守のためのIT統制目標」（ITGavernance Institute 2004年翻訳版）を使用します。
今後、法制化されることもあり、IT化指導をするITコーディネータ企業にとって必須のテーマです。
業務・システム最適化計画はこのフェーズまでがまとめられて、調達のステップであるRFP（Request For Proposal）へと進みます。
ここでの移行計画は通常いうシステムの本番移行とは若干意味合いが異なります。
IT新改革戦略でも電子政府システム構築完了を2010年としているわけですから、2006年から調達を開始しているシステムは今後5年間を3フェーズに分割して導入していくことになります。
将来体系はあるべき姿を描いていますので、3フェーズを経て現行体系から将来体系へ移行していくことになります。
例として、ある国家試験の願書受付業務の将来体系が「インターネットによる願書ダウンロードとインターネットによる願書申請」であったとしましょう。
この形態ですと業務工数もスピードも格段に向上すると思われますので、この方向を将来体系の業務とします。そうしますと、いろんな問題が発生してきます。
国家試験は誰でも受験資格がありますので、“インターネットが出来ない人やその接続環境の無い方は受験できません。”とは言えないわけです。
また、インターネットだけでは不安なので窓口に来て相談される方も有りますし、身障者や僻地の方もいます。“何時、窓口受付業務を停止し、インターネットとTELだけの状態に持っていくか”など課題が出てきます。
そうしますと、5年後のあるべき姿としては、“窓口受付や郵送受付は残し、インターネットによる願書申請を50％以上にする”というようなあるべき姿が出てきます。
この業務の姿に向けて移行計画を作成していくことになります。移行計画としては、第1ステップは「業務プロセスの標準化」、第2ステップは「電子申請業務システムの導入・運用」、第3ステップで「モニタリングや業務効率化のための情報の共有・分析」の移行方針を策定しますと、この目標に沿った実施計画が組まれ、各移行フェーズのBA、DA、AA、TAの体系を作成し、最適化計画を完成させていくことになります。
第１３６回はここで終了します。
この回で最適化計画のステップは全てカバーしましたのでEAのテーマは終了しようと思います。
“EAが少しは身近なものになりましたか？”
皆様方の実務へ何らかの形で反映でき、お役に立てば幸甚の限りです。
次回以降のテーマは、私の書いた雑誌記事「最先端の経営リスクを追う！」 （アスキービジネス）
から、日本版SOX法として注目を集めている内部統制の中でITに焦点を当てた「IT内部統制」を取り上げようと思います。
題材は「サーベンズ・オクスリー法（企業改革法）遵守のためのIT統制目標」（ITGavernance Institute 2004年翻訳版）を使用します。
今後、法制化されることもあり、IT化指導をするITコーディネータ企業にとって必須のテーマです。
127回、128回でEEM（Entity Event Matrix：情報分析図）とDAM（Data
Abstraction Matrix：情報抽象化表）を取り上げました。
それぞれ現行体系で、共通業務として複数の府省の独自の処理をまとめるために
抽象化して最小公倍数的な機能を持たせて記述するために採用した抽象化の技法で
した。それぞれDAMが各府省の独自のデータ項目を共通のデータ項目とするために
抽象化、EEMはトランザクション出力情報に必要なマスターファイルのデータの関係
付けを行い、業務と情報の妥当性を確認するものでした。
現行体系では現状を把握するために使用しましたが、将来体系の情報分析図として
EEM１をもとにEEM2へ拡張して作成します。今回はこの抽象化概念を取り上げようと
思います。
EEM２の作成の位置づけは将来体系のDMM（Diamond Mandara Matrix：機能構成図）
→DFD(Data Flow Diagram：情報機能関連図)を作成後、DAM （Data Abstraction
Matrix：情報抽象化表）をより抽象度を高めで作成し、EEM2（Entity Event Matrix
２）の作成となります。その後、WFA（Work Flow Architecture:業務流れ図）→
情報モデルとしての情報体系整理図の作成順序になります。
EEM2を話す前に将来体系のDAMを取り上げましょう。EEM１で共通業務として複数の
府省を整理するためにデータフィールド名称を統一する話をしました。
例えば、承認者を○○承認者や××承認者、あるいは○○課長と言うように各府省で
同じ機能でも全く違った名称で使用されていたフィールド名称を“承認者”という
ようなフィールド名称に統一することです。この考え方をEEMのトランザクション
プロセスと組み合わせるとモット大胆な抽象化が可能となります。
例えば、「申請受付処理」、「申請承認・却下処理」、「申請許諾回答処理」が
あったとしましょう。各処理で承認者がいるはずです。そうしますと、フィールド
名称は申請受付承認者、申請承認・却下承認者、申請許諾回答承認者という風に
3種類のフィールド名称が必要になります。しかし、ここに処理コードを入れると
１つの名称でよいことになります。“承認者”というフィールド名称にして、処理
タイプコードとして、各処理コードをそれぞれ“０１”、“０２”、“０３”を
設けることによって、０１の処理をしているプログラムは同じ承認者のデータ
フィールドを扱っていても“申請受付承認者”を扱っていることを意味することが
可能になります。同様に、承認者という名称フィールドに加え、全く別の担当者や
監督者、管理者、社員等人にまつわる名称がたくさん出てきます。
ただ、ある処理では“承認者”と“監督者” を使用するが、別の処理では“社員”
と“管理者”しか使用しないという状況があります。
このような場合の抽象化は人タイプコードを設けてフィールド名称を“担当者”、
“監督者”等にまとめ、人タイプコードを“H1”、“H2”と言う風にコード付けし
ます。そうすると処理タイプコードと人タイプコードのマトリックステーブルを作成
しておけば、ファイルのフィールド項目は格段に抽象化された項目で処理が可能と
なります。
このことはプログラム作成において単純なI/Oで処理ロジックを作成できるとともに、
ユーザーはマトリクスのメンテナンスのみでシステム維持・管理の容易なシステム
運用を可能とすることになります。
EEM2の構造はこの抽象化されたデータフィールド項目を立軸にとり、横軸にトラン
ザクション処理を配置することでトランザクション処理にデータ項目の関係を関連
付けた設計書が出来上がります。
実際の将来体系ではEEM1までの作成で完了になり、EEM2の拡張は行われていません
でした。
概念としては、非常にすばらしいのですが、設計者が追いついていけないところに
原因があったようです。
第１３５回はここで終了します。
今回は「将来体系設計プロセス−業務プロセス設計の抽象化」を取り上げました。
次回は「移行計画の作成」をとりあげます。
Abstraction Matrix：情報抽象化表）を取り上げました。
それぞれ現行体系で、共通業務として複数の府省の独自の処理をまとめるために
抽象化して最小公倍数的な機能を持たせて記述するために採用した抽象化の技法で
した。それぞれDAMが各府省の独自のデータ項目を共通のデータ項目とするために
抽象化、EEMはトランザクション出力情報に必要なマスターファイルのデータの関係
付けを行い、業務と情報の妥当性を確認するものでした。
現行体系では現状を把握するために使用しましたが、将来体系の情報分析図として
EEM１をもとにEEM2へ拡張して作成します。今回はこの抽象化概念を取り上げようと
思います。
EEM２の作成の位置づけは将来体系のDMM（Diamond Mandara Matrix：機能構成図）
→DFD(Data Flow Diagram：情報機能関連図)を作成後、DAM （Data Abstraction
Matrix：情報抽象化表）をより抽象度を高めで作成し、EEM2（Entity Event Matrix
２）の作成となります。その後、WFA（Work Flow Architecture:業務流れ図）→
情報モデルとしての情報体系整理図の作成順序になります。
EEM2を話す前に将来体系のDAMを取り上げましょう。EEM１で共通業務として複数の
府省を整理するためにデータフィールド名称を統一する話をしました。
例えば、承認者を○○承認者や××承認者、あるいは○○課長と言うように各府省で
同じ機能でも全く違った名称で使用されていたフィールド名称を“承認者”という
ようなフィールド名称に統一することです。この考え方をEEMのトランザクション
プロセスと組み合わせるとモット大胆な抽象化が可能となります。
例えば、「申請受付処理」、「申請承認・却下処理」、「申請許諾回答処理」が
あったとしましょう。各処理で承認者がいるはずです。そうしますと、フィールド
名称は申請受付承認者、申請承認・却下承認者、申請許諾回答承認者という風に
3種類のフィールド名称が必要になります。しかし、ここに処理コードを入れると
１つの名称でよいことになります。“承認者”というフィールド名称にして、処理
タイプコードとして、各処理コードをそれぞれ“０１”、“０２”、“０３”を
設けることによって、０１の処理をしているプログラムは同じ承認者のデータ
フィールドを扱っていても“申請受付承認者”を扱っていることを意味することが
可能になります。同様に、承認者という名称フィールドに加え、全く別の担当者や
監督者、管理者、社員等人にまつわる名称がたくさん出てきます。
ただ、ある処理では“承認者”と“監督者” を使用するが、別の処理では“社員”
と“管理者”しか使用しないという状況があります。
このような場合の抽象化は人タイプコードを設けてフィールド名称を“担当者”、
“監督者”等にまとめ、人タイプコードを“H1”、“H2”と言う風にコード付けし
ます。そうすると処理タイプコードと人タイプコードのマトリックステーブルを作成
しておけば、ファイルのフィールド項目は格段に抽象化された項目で処理が可能と
なります。
このことはプログラム作成において単純なI/Oで処理ロジックを作成できるとともに、
ユーザーはマトリクスのメンテナンスのみでシステム維持・管理の容易なシステム
運用を可能とすることになります。
EEM2の構造はこの抽象化されたデータフィールド項目を立軸にとり、横軸にトラン
ザクション処理を配置することでトランザクション処理にデータ項目の関係を関連
付けた設計書が出来上がります。
実際の将来体系ではEEM1までの作成で完了になり、EEM2の拡張は行われていません
でした。
概念としては、非常にすばらしいのですが、設計者が追いついていけないところに
原因があったようです。
第１３５回はここで終了します。
今回は「将来体系設計プロセス−業務プロセス設計の抽象化」を取り上げました。
次回は「移行計画の作成」をとりあげます。
前回までで「見直し方針」を作成しました。見直し方針ではあるべき業務・システム
のための方針と目標を決めましたので、その方針に沿って「将来政策・業務体系
（BA）」、「将来データ体系（DA）」、「将来適用業務体系（AA）」、「将来技術体系
（TA）」をまとめることになります。
作業内容は現行体系のプロセスでまとめた体系図を見直し方針に沿って置き換える
ことになりますので使用する手法や体系図作成作業は同じになります。
ここでは現行体系プロセスと異なる将来体系作業における留意点とEEM2（Event
Entity Matrix ２）について述べておきます。
留意点としては、
（１）見直し方針を生かした全体イメージを作成します。
皆さん方もお客向けに提案書を作成するときに、提案するシステムの全体イメージ図
を描かれると思います。そうすることで、提案システムの改革イメージを統合化
できます。同様なイメージ図を将来体系にも作成することで４つの将来体系の作成が
統一できます。18府省を束ねる共通業務を例に取りますと、盛り込む内容は「国民の
窓口になるポータルサイトの主要機能とポータルサイト以外の機能」、「抽象化
（または共通化）されたIT化対象プロセス」、「主要なデータベース」、「各府省と
のシステムインターフェース」となります。
（２）住基ネット（住民基本台帳ネットワークシステム）をシステムに組み込みます。
国民とのインターフェースがインターネットになってきますので、申請者や依頼者が
日本国民であることをチェックするためには住基ネットを活用し、検証や証明用と
することは必須となります。
現在も本人の日本国民を確認するために登記簿謄本や抄本、住民票等の添付が必要
な場合が多くあります。この添付資料が電子化を阻害してしまいます。
（３）承認・決裁プロセスに電子認証の取り込みを行う。
府省業務が民間業務と異なるのはいくつもの段階で承認、そして最終的な決済と
いうように押印プロセスがあることでしょう。
国家試験業務を見ても、○○小委員会が発足し原案が作成され、原局承認、審議会
で検討承認、官房決裁というように各専門家の集まり、依頼元の原局担当者、責任
者、外部公表時の官房承認というように、役割ごとに内部・外部からの検証が加え
られて法律や制度をつくり運用しています。この承認がｅ−Ｊａｐａｎ前は紙に
承認印または決裁印を押すことが必要でした。○○委員や審議会と言った外部機関
に対しては電子化が無理な状態が発生しますが、府省内の承認・決裁プロセスの
電子認証化を進めていくことになります。
（４）モニタリングのビジネスプロセス構造を確保します。
業務プロセス改善のために、業務が以前目標に対する情報の収集と検証のプロセス
を組み入れます。さらに、国民からサービス提供に対するパブリックオピニオン
（公開質問受付）の機能を付け加えておくことが必須要件となります。
第１３４回はここで終了します。
今回は「将来体系設計プロセス−将来体系作業の留意点」を取り上げました。
次回は「将来体系設計プロセス−業務プロセス設計の抽象化」をとりあげます。
のための方針と目標を決めましたので、その方針に沿って「将来政策・業務体系
（BA）」、「将来データ体系（DA）」、「将来適用業務体系（AA）」、「将来技術体系
（TA）」をまとめることになります。
作業内容は現行体系のプロセスでまとめた体系図を見直し方針に沿って置き換える
ことになりますので使用する手法や体系図作成作業は同じになります。
ここでは現行体系プロセスと異なる将来体系作業における留意点とEEM2（Event
Entity Matrix ２）について述べておきます。
留意点としては、
（１）見直し方針を生かした全体イメージを作成します。
皆さん方もお客向けに提案書を作成するときに、提案するシステムの全体イメージ図
を描かれると思います。そうすることで、提案システムの改革イメージを統合化
できます。同様なイメージ図を将来体系にも作成することで４つの将来体系の作成が
統一できます。18府省を束ねる共通業務を例に取りますと、盛り込む内容は「国民の
窓口になるポータルサイトの主要機能とポータルサイト以外の機能」、「抽象化
（または共通化）されたIT化対象プロセス」、「主要なデータベース」、「各府省と
のシステムインターフェース」となります。
（２）住基ネット（住民基本台帳ネットワークシステム）をシステムに組み込みます。
国民とのインターフェースがインターネットになってきますので、申請者や依頼者が
日本国民であることをチェックするためには住基ネットを活用し、検証や証明用と
することは必須となります。
現在も本人の日本国民を確認するために登記簿謄本や抄本、住民票等の添付が必要
な場合が多くあります。この添付資料が電子化を阻害してしまいます。
（３）承認・決裁プロセスに電子認証の取り込みを行う。
府省業務が民間業務と異なるのはいくつもの段階で承認、そして最終的な決済と
いうように押印プロセスがあることでしょう。
国家試験業務を見ても、○○小委員会が発足し原案が作成され、原局承認、審議会
で検討承認、官房決裁というように各専門家の集まり、依頼元の原局担当者、責任
者、外部公表時の官房承認というように、役割ごとに内部・外部からの検証が加え
られて法律や制度をつくり運用しています。この承認がｅ−Ｊａｐａｎ前は紙に
承認印または決裁印を押すことが必要でした。○○委員や審議会と言った外部機関
に対しては電子化が無理な状態が発生しますが、府省内の承認・決裁プロセスの
電子認証化を進めていくことになります。
（４）モニタリングのビジネスプロセス構造を確保します。
業務プロセス改善のために、業務が以前目標に対する情報の収集と検証のプロセス
を組み入れます。さらに、国民からサービス提供に対するパブリックオピニオン
（公開質問受付）の機能を付け加えておくことが必須要件となります。
第１３４回はここで終了します。
今回は「将来体系設計プロセス−将来体系作業の留意点」を取り上げました。
次回は「将来体系設計プロセス−業務プロセス設計の抽象化」をとりあげます。
「内部業務見直し方針」を受けて、この3フェーズプランニングを行います。私たち
の一般的な言葉で言い換えますと、業務改善方針（すなわち主要課題）を受けて
その方針に沿った改善策を今後3期または3段階のスケジュールに展開するということ
です。
SWOT分析によって創出したCSFは内部業務見直し方針を作成する際にCSFを参照します
ので、主要課題ごとに整理されています。この主要課）ごとにその課題達成のための
CSFロードマップを作成します。
参照URL：http://www.meti.go.jp/policy/it_policy/ea/data/report/r2/r2.pdf
の62ページ
このロードマップの作り方はバランススコアカードで作成する戦略マップの作成方法
と同じです。場戦略マップと同様にCSFを「目的―手段」の因果関係で繋いでいき
ます。例えば、「データ項目の抽象化手法を選択」という手段はその手法を用いて
目的の「○○業務情報の項目抽象化」が可能になり、またその手段はその目的として
の「○○業務のデータベース一元化」を導くことが出来ます。戦略マップと同様に、
その手段を採用することである目的が達成されます。 さらに、その目的が手段と
なってその上位の目的が達成されるという連携で主要課題達成のロードマップを作成
していくわけです。
当然、CSFを連携していく中で、連携できない漏れのCSFがあることも気づきます
ので、追加していきます。
このようにして作成した主要課題解決のロードマップは実施順序を決め、スケジュー
ル化しなければなりません。このロードマップ全体を3フェーズに分割して3フェーズ
プランを作成します。3フェーズプランの考え方は事業計画やシステム導入等で実施
作業を3段階にわけ各フェーズで投資対効果が見極められるようにすることと
各フェーズの中間目標を測定することで経営リスク等のリスクを減少させる意味が
あります。
ただ、EAの場合ですと、最適業務・システムの構築になるわけですから対象が業務
プロセスです。業務プロセスは「計画」、「分析・設計」、「構築・導入」、
「検証」、「改善・対処」のステップを踏むことになりますので、１ｓｔフェーズは
「計画」、「分析・設計」、2ndフェーズは「構築・導入」、3ｒｄフェーズは
「検証」、「改善・対処」の順に最適化実施のロードマップが作られることになり
ます。
この3フェーズで将来体系への改善方針としての主要解決課題、目標と実施事項が決定
されることになりますので、将来体系の設計へ移ることになります。
第１３３回はここで終了します。
今回は「見直し方針プロセス−３フェーズプランニング」を取り上げました。
次回は「将来体系設計プロセス−将来体系作業の留意点」をとりあげます。
の一般的な言葉で言い換えますと、業務改善方針（すなわち主要課題）を受けて
その方針に沿った改善策を今後3期または3段階のスケジュールに展開するということ
です。
SWOT分析によって創出したCSFは内部業務見直し方針を作成する際にCSFを参照します
ので、主要課題ごとに整理されています。この主要課）ごとにその課題達成のための
CSFロードマップを作成します。
参照URL：http://www.meti.go.jp/policy/it_policy/ea/data/report/r2/r2.pdf
の62ページ
このロードマップの作り方はバランススコアカードで作成する戦略マップの作成方法
と同じです。場戦略マップと同様にCSFを「目的―手段」の因果関係で繋いでいき
ます。例えば、「データ項目の抽象化手法を選択」という手段はその手法を用いて
目的の「○○業務情報の項目抽象化」が可能になり、またその手段はその目的として
の「○○業務のデータベース一元化」を導くことが出来ます。戦略マップと同様に、
その手段を採用することである目的が達成されます。 さらに、その目的が手段と
なってその上位の目的が達成されるという連携で主要課題達成のロードマップを作成
していくわけです。
当然、CSFを連携していく中で、連携できない漏れのCSFがあることも気づきます
ので、追加していきます。
このようにして作成した主要課題解決のロードマップは実施順序を決め、スケジュー
ル化しなければなりません。このロードマップ全体を3フェーズに分割して3フェーズ
プランを作成します。3フェーズプランの考え方は事業計画やシステム導入等で実施
作業を3段階にわけ各フェーズで投資対効果が見極められるようにすることと
各フェーズの中間目標を測定することで経営リスク等のリスクを減少させる意味が
あります。
ただ、EAの場合ですと、最適業務・システムの構築になるわけですから対象が業務
プロセスです。業務プロセスは「計画」、「分析・設計」、「構築・導入」、
「検証」、「改善・対処」のステップを踏むことになりますので、１ｓｔフェーズは
「計画」、「分析・設計」、2ndフェーズは「構築・導入」、3ｒｄフェーズは
「検証」、「改善・対処」の順に最適化実施のロードマップが作られることになり
ます。
この3フェーズで将来体系への改善方針としての主要解決課題、目標と実施事項が決定
されることになりますので、将来体系の設計へ移ることになります。
第１３３回はここで終了します。
今回は「見直し方針プロセス−３フェーズプランニング」を取り上げました。
次回は「将来体系設計プロセス−将来体系作業の留意点」をとりあげます。
