IT経営戦略バイブル

ネットショップを開業したい！　ネットショップを運営しているが売り上げが～　
って皆様に！

業界のプロが講師となる「EC塾」が開講されます。

ネットショップを月額たった５００円で簡単に開業できるサービスで今や定番となりつつある「おちゃのこネット」代表の伊藤富雄氏（アメリカのネット事情に精通し、常に最新の情報を取り入れ実験を繰り返す。私の師匠です）や株式会社ドアズの戸田克己氏（早くからブログに着目し、ブログを超カスタマイズしたサイトの制作で時代の先端を走る風雲児？）など超多忙な講師陣が時間を割いて皆様に講義を行います。（これだけの面々が一堂に会する事は史上初では？）

気になる講義の内容ですが・・・

インターネットの基礎知識から実践のノウハウまで
「よだれの出る商品写真の撮り方」
「また買っちゃったな顧客囲い込み術」
「リピート率をアップさせる梱包とは」
などは必見！

受講科目

受講は神戸で行われ限定たったの６名！

しかし、

神戸に通えない。時間がないという方のために

オンラインでの受講も可！（こちらも限定１５名様）

ぜひ参加したい！　っていう皆様に朗報！

自分の顧客にこの「EC塾」を紹介したいと伊藤氏に相談しました。
そして、私の紹介ならって事でなんと教材費３７８００円を無料にしてもらいました。（受講料は別途必要です。）受講申し込みページのクーポンコード欄に“marc”と入力ください。
それだけで３７８００円が無料！

もう、残りわずかと聞いています。
「EC塾」で儲かるネットショップ作りを！

「EC塾」ホームページ

Comments(0)

　EAの起源は1987年に当時IBM社員だったジョン・ザックマン氏が提唱したフレーム
　ワークです。ザックマンは企業の情報化戦略策定や個別システムにおける概念モデル
　として６×６のマトリクスのダイアグラムを提唱しました。システムの要件定義に
　必要な要件を整理したダイアグラムと言い換えても良いと思います。
　このマトリクス縦軸には製造過程の関与者の観点を捉えています。計画者視点として
　の「スコープ（目的・範囲）」、オーナー視点としての「エンタープライズ（ビジネ
　スモデル）」、設計者視点としての「システムモデル」、構築者視点としての「テク
　ノロジーモデル（物理技術モデル）」、構築請負者視点としての「コンポーネント
　（構成要素）」、利用者視点としての「ファンクショニング（製品、企業機能）」の
　6つの視点を縦軸に置きました。
　横軸には縦軸の製造過程の関与者の視点で必要とする5W１Hの視点である「What(デー
　タ)」、「How(機能)」、「Where(ネットワーク)」、「Who（人）」、「When
　（Time）」、「Why（モチベーショ）」の6つの要因を置いた。この６×６の要因を
　明確にすることで企業システムモデルの概念を定義しました。
　マトリクスの各要因を製造過程の関与者の視点で5W1HのWhat、How、Where、Who、
　When、Whyの順に要因を整理すると下記のようになります。参考として列記しま
　しょう。
　（１）計画者視点としての「スコープ（目的・範囲）」の要因
　　　　実体(目的物)、プロセス、ロケーション、組織、マスタースケジュール、
　　　　ビジョン
　（２）オーナー視点としての「エンタープライズ（ビジネスモデル）」の要因
　　　　概念データモデル、ビジネスプロセスモデル、ネットワークモデル、ワーク
　　　　フローモデル、イベントモデル、戦略モデル
　（３）設計者視点としての「システムモデル」の要因
　　　　論理データモデル、情報プロセスモデル（DFD）、ネットワークモデル、
　　　　ヒューマンインターフェース、イベントダイアグラム、ビジネスルールモデル
　（４）構築者視点としての「テクノロジーモデル（物理技術モデル）」の要因
　　　　物理データモデル、機能構造図、サーバー・ネットワーク構成、ユーザー
　　　　インタフェース/セキュリティ設計、コントロール制御、ビジネスルール設計
　（５）構築請負者視点としての「コンポーネント（構成要素）」の要因
　　　　実装設計、プログラム設計・構築、ネットワークコンポネント、スクリーン
　　　　設計・セキュリティ実装、タイミング定義、ルール記述
　（６）利用者視点としての「ファンクショニング（製品、企業機能）」の要因
　　　　データベース、実行プログラム、ネットワーク、人、イベント、強制ルール

　米国連邦政府はこのザックマンモデルを引用し、連邦政府EAフレームワークVer1.1
（Federal　Enterprise　Architecture　Frame）を、2001年には連邦政府EA実践ガイド
　を策定し、連邦政府のの業務・システム最適化/改革を推進しています。
　このザックマンモデルが日本のEAモデルでは如何に変換されたのでしょうか？
　次回にしましょう。
　第１１４回はここで終了します。
　今回は「EA出現の背景－その１」として、ザックマンモデルを中心に紹介しました。
　次回は「EA出現の背景－その2」でザックマンモデルのEAへの応用を取り上げます。

Comments(0)

　前回、情報システム構築の体系化をしたザックスマンモデルを紹介しましたが、この
　モデルがEAにいかに反映されたのかが今日のテーマです。

　ザックスマンモデルの縦軸は製造過程の関与者（ステイクホルダー）の立場で「計画
　者」、「オーナー」、「設計者」、「構築者」、「構築請負者」、「利用者」の視点
　からの要因を取り上げました。この視点を経営の設計仕様に対する要望の観点で見
　ますと、「計画者」や「オーナー」の視点は経営活動・業務遂行の観点で必要な要因
　であり、「設計者」、「構築者」、「構築請負者」の視点は情報システム部のシステ
　ム構築の観点で必要な要因であることが分かります。「利用者」はユーザーの観点と
　なっています。

　横軸の5W１Hは「What」として情報システムの対象となるデータやオブジェクトの観点
　とその他の観点で分類できます。Whatの観点は各ステイクホルダーの目的対象で
　あり、必要情報から必要DBへの展開の要因事項になっています。データを中心とした
　体系化エリアを表しています。

　その他の5W１HはこのWhatの目標を達成するための手段となっていいます。
　すなわち、What達成するために「如何にして」、「何処で」、「誰が」、「何時」、
　「何のために」を定義しているわけです。

　これらの手段の経営活動・業務遂行の観点での必要な要因情報化の対象となる業務
　プロセスを定義することになっています。すなわち、業務プロセスの体系化エリアに
　なっています。

　システム構築の観点での設計者と構築者の視点の要因を捉えると、情報を中心とした
　ビジネスプロセスや情報化機能定義が中心になることがお分かりでしょう。これは
　アプリケーション体系化のエリアの必要性を示唆しています。システム構築の観点で
　もう一つの構築請負者の視点ではプログラム作成やIT インフラ構築のための技術的
　要因のエリアの体系化が必要となります。

　このように、ザックマンモデルは情報システム構築にはデータエリアの体系化、業務
　プロセスの体系化、アプリケーションの体系化、技術エリアの体系化の4点が必要で
　あると言うことを表現していたわけです。

　EAではこの４つのモデルをそれぞれBA（Ｂｕｓｉｎｅｓｓ　Ａｒｃｈｉｔｅｃｔｕｒ
　ｅ）、DA（Ｄａｔａ　Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＡＡ（Ａｐｐｌｉｃａｔｉｏｎ
　Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＴＡ（Ｔｅｃｈｎｉｃａｌ　Ａｒｃｈｉｔｅｃｔｕｒ
　ｅ）として整理しました。ＢＡとは業務プロセスの体系化、ＤＡとはデータエリアの
　体系化、ＡＡとはアプリケーションの体系化、ＴＡとは技術的要因エリアの体系化を
　指しています。

　情報システム化はＥＡに基づいて実施することで、標準化でき合理的・効率的な構築
　が可能と言うわけです。

　米国のFEAF（Federal　Enterprise　Architecture　Frame）は1993年の国家事業評価
　法に基づいた調査で、IT投資プロジェクトの半数以上が失敗であることが判明し、
　連邦政府の情報システム調達制度に関する改革としてスタートしました。
　
　さて、何故日本版EAは何故スタートしたのか？次回のテーマとします。
　第１１５回はここで終了します。

Comments(0)

IT化の急速な進展の中で、米国連邦政府のFEAF(Federal　Enterprise　Architecture
　Frame)による行政情報化改革はIT投資プロジェクト調査で半数以上の失敗に対する
対策として始まりました。
日本の行政府のシステムも同様な問題を抱えており、その問題の根源は政府調達の
仕組みにあると指摘されました。注１
（注１）政府調達のためのIT専門家について　～ITアソシエイト協議会中間報告　～
（２００２年１２月）　http://www.meti.go.jp/feedback/data/i21227jj.html
　この報告書の中で、大きく３つの課題を取り上げています。
　第１の課題：ITベンダーへの依存構造
　RFPの質が悪く、求められているシステムの内容が明確にならない。その結果、資金力
のある大手ITベンダーに独壇場になり、各社がコアになるシステムをバラバラに構築
し、運用も完全に依存せざるを得ない。
ちなみに、当時の報告による政府調達市場の各社のシェアはNTTグループ(34%)、富士
通グループ（10%）、日立グループ（9%）、NECグループ（６％）、その他6大手グルー
プ（20%）、10グループ以外(21%)である。2兆円と言われた政府関連IT化市場を大手
４社で60%、10社で80%を独占していたことになる。

第2の課題：電子政府システム実現に向けた課題
　 IT化による業務改革は統合化荷あるにもかかわらず、各府省ごとに個別の企画開発
が行われ、それぞれのシステムは、RFPに基づいて各ITベンダーの独自の手法により
ITの企画・開発を行われているため統合化が困難になっている。

第3の課題：属人的な能力に頼った組織からの脱皮
　 ITの導入によって将来を見据えた効果的な行政サービスの実現が企画されるべき
であるが、属人的な能力に頼り、現行の業務に「便利な道具」として導入されて
いるに過ぎない。
以上のように行政府のIT化に対する課題を見極め、その対策として
◆「段階を追って業務・システムを統合し、より合理的かつ効果的なシステムが実現
されるよう統合化・合理化・標準化戦略を持つ必要がある。」と定め、米国連邦政
府が導入したEAの採用を決めています。
◆「組織全体としてのナレッジマネジメントや人材育成と連携したシステムを目指し
た企画行い、行政組織自体がITを活用した学習する組織とする。」このことによっ
て属人的能力にだけ依存しない行政システムの構築を行っていく。この対策のもと
に、ガイドラインやリファレンスが作られることになりました。
◆「業務プロセスを明示化し、的確に進めていくための人材の採用」の下にCIO補佐官
が民間から採用・任命され、指導・育成を図ることになりました。

おおまかですが、EAを用いた電子政府プロジェクト発足の背景をまとめてみました。
第１１６回はここで終了します。
今回は「EA出現の背景－その３」として、日本版EAを策定するに至る課題を紹介しま
した。
次回からは本論である電子政府プロジェクトに入ります。まず最初に「電子政府プロ
ジェクトの目的と役割」をとりあげます。

Comments(0)

ここから、申し上げるEAとは日本版EAである電子政府EAモデルを取り上げて行きます。
電子政府構築のためのEA策定ガイドラインから引用しますと、EAとは「組織全体の業務
とシステムを統一的手法でモデル化し、部局ごとではなく『全体最適』の観点から業務
システムを同時に顧客志向に改善していくための組織の設計・管理手法」（経済産業
省）と定義しています。言い換えると、EAは企業と業務システムの全体構造に対して、
整合性をもって設計・管理するためのシステムの見取り図というべきものです。
EA導入の目的は、以下のように定義されています。
　(1)IT投資の合理化・効率化する
　　電子政府予算をより効果的、効率的に活用することであり、そのためには、現状
業務の明確化とそれによる改善が必要になる。
重複投資や無駄な行政プロセス最小化するために、18府省の中でEA開発対象となる
業務を21個の共通業務システムと各府省独自の51個の個別業務システムに整理し、
合理化・効率化を図ることになる。
　(2)高度な行政サービスの実現する
　　顧客志向へ転換することで高度な行政サービスの実現することである。国民向けの
インターネットによるワンストップサービスや国民からのフィードバック意見を
受けるパブリックオピニオンによるモニタリング制度が組み込まれる。
　(3)統合化・合理化プロセスの提示する
　　業務システムが向かうプロセスについての改革指針を提示できることである。業務
システムについて、「現状から理想像に向けた軸」に沿ってその移行プロセスを
決め、政策と情報技術の乖離を防ぐ。
　(4)長期的な設計思想を取り入れる
　　アウトソーシングなど民間活力を活用した行政サービスの実現と情報システムは
長期的にＷｅｂベース技術に統合されていく観点で、セキュリティ確保が容易と
なる業務・システム構成を確保する。
以上のEAの目的は「政策」を「経営」に置き換えれば、民間企業でも同様に活用できる
ものです。作成されたモデルを民間へリファレンスとして提供し、民間での適用する
ことにも大きな目的があります。
EAが業務システムを設計・管理するシステムの見取り図とすれば、その役割が定義
される必要があります。
その役割は、以下の４つが定義されています。
　(1)「業務とシステム間の関係と現状の明確化」できること
　　組織の業務・システム全体を「共通言語」による「統一的な手法」で記述し、組織
の所有者の立場から業務・システムの全体を把握できるようにする。
　(2)「現状から理想に至る活動の明確化と改善サイクルの確立」ができること
　　業務・システムに関する組織全体での改善活動の道筋をつける。「アプローチの
定義」→「現状モデルの作成」→「理想モデルの作成」→「次期モデルの策定」→
「EAの利用」→「EAの保守」→「モニタリングとコントロール」→「管理体制とコン
トロールの確立」からなるEAプロセスの改善サイクルを確立することにある。
　(3)「情報資産と業務との関係の明確化」が出来ること
　　データ体系の明確化を行うために機能中心の業務分析でなく、データ中心の業務
分析を行いシステム全体のデータ整合性を確立する。
　(4)「長期的な設計思想と技術の世代管理に関する指針」が出来ること
　　理想（ToBe）モデルを描いていく時点で、業務・システム自体の設計思想を明確に
していくことを求めている。今回のガイドラインでは、行政事務サービスがWebベー
スのシステムへ移行するという前提のもとに進められている。ポータルサイトで
見受けられるように、消費者は一度入力をすれば、サービスを受け入れられる利便
性のある業務設計になる必要がある。EAの設計にはこのようなOne　Writing　
Systemの構造が組み込まれることになる。
これらの役割を作り上げるために、ザックマンモデルが活用され、EAの機能体系が作成
されました。

第１１７回はここで終了します。
今回は「電子政府プロジェクトの目的と役割」を紹介しました。
次回は「EAのフレームワーク－全体機能」をとりあげます。

Comments(0)

115回でザックマンモデルは情報システム構築には業務プロセスの体系化、データ
エリアの体系化、アプリケーションの体系化、技術エリアの体系化の4点が必要である
と言うことを表現していると述べました。
EAのフレームワークはこのザックマンモデルをそのままEA体系を引用しています。
業務プロセスの体系であるBA（Business　Architecture）は「政策・業務体系」、
データエリア体系であるDA(Data　Architecture)は「データ体系」、アプリケーション
の体系であるAA(Application　Architecture)は「適用処理体系」、技術エリアの体系
TA(Technology　Architecture)は「技術体系」と表現されています。
情報システム設計するときにはBA→DA→AA→TAと展開して設計書を作るというわけ
です。
それぞれの機能は
（１）政策・業務体系(=BA)での設計書は「業務目標の設定」と「業務機能構成の
定義」を行います。業務改善目標と業務プロセス分析ですから、要件定義書に該当
します。
（２）データ体系(=DA)では業務機能を遂行するための「データ」、これらの「データ
間の関係の定義」の設計書を作ります。基本設計で行う「マスターデータとトラン
ザクションデータの関係定義」になります。
（３）適用処理体系(=AA)での設計書は政策・業務体系でシステム化対象の業務シス
テムを捉え「データ処理と業務の関係を定義」する。システム化の要件定義で作成
するシステム機能とシステム機能構成図に該当する。
（４）技術体系(=TA)での設計書は業務システム要件を満たす「ITインフラの構成」を
定義する。
システム化のRFPに対して提案する「IT機器やネットワーク構成、ソフトウエア構成
定義」に該当します。
　EAのフレームはこの４つの体系を現状（As　ｉｓ）モデルで定義し、業務目標に
沿って将来(To　ｂｅ)モデルを作り上げることにあります。
私たちが通常実施している企業情報システムの構築する場合には最も体系ですが、
このことの重要さはこの作業で設計書を作成していくプロセスと仕様手法を標準化
したことにあります。電子政府プロジェクトで18府省が同じ設計プロセスで同じ手法
を使用して作成し、ＲＦＰが業者に向けて提出されることになれば、効率的に、
迅速なシステム構築、運用が可能となってきます。
政府調達のシステムの規模は日本の全ＩＴ投資の約20%といわれています。これらの
システムが標準的なプロセス、手法で作成されるとすれば日本発のソフトウエア
エンジニアリングが出来上がるかもしれません。平成１７年12月のJEITAの報告データ
注ですが、民間でもトヨタやエーザイ等、13社がＥＡをシステム設計に採用しま
した。
(注) http://it.jeita.or.jp/infosys/committee/SOL/CEATEC2005CONFERENCE_EAguide1006.pdf

第１１８回はここで終了します。
今回は「ＥＡのフレームワーク－全体機能」を紹介しました。
次回は「EAのフレームワーク－成果物と手法」でBAの成果物をとりあげます。

Comments(0)

EAの全体機能はBA(Business　Architecture：政策・業務体系)、DA(Data　
Architectureのデータ体系)、AA(Application　Architecture:適用処理体系)、TA
(Technical　Architecture:技術体系)の４つの機能体系からなることは概ねご理解
いただけたと思います。
今回はこの体系を策定するに必要な作業項目とその成果物についての概要を解説した
いと思います。現在は先行した共通業務システムプロジェクトの成果物があります。
ここではその1つである
人事給与業務の成果物を参考にしながら進めて行きましょう。
BAは業務処理を標準化するための機能体系ですので、業務機能目標のもとに「業務機能
構成の定義」が必要になります。業務機能構成の定義では業務機能をDMM(Diamond　
Mandara　Matrix)を用いて細部機能へ階層化した機能構成図を作成します。たとえば、
販売機能の下位の機能は受注/在庫/発注/入庫/出庫等になります。
機能構成図の
URL→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-2-3.pdf
機能構成図が作成されると、DFD（Data　Flow　Diagram）を用いて業務機能間情報の
関連を記述した「情報機能関連図」を作成します。この成果物で業務遂行を行う上で
必要となる情報の連携を見極めることが出来ます。
情報機能関連図の
URL→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-2-1.pdf
情報機能関連図ができると業務機能に担当する部門と情報システムとの関係を加え、
業務情報の部門間の流れをあらわす「業務流れ図」を（Work　Flow　Architecture)
手法を用いて作成します。部門という物理要素を加え、部門間での業務が連携を記述
することで現実の運用に近い業務フローが確認できます。
業務流れ図の
URL→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-3-1.pdf
この確認ができると、業務機能に必要な情報が確定できたことになりますのでUML
(Unified　Model　Language：第61-65回参照)を用いてデータベース体系と
なる情報モデルとして「情報体系整理図」を策定することになります。
情報体系整理図の
URL　→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-4-1.pdf
この情報モデルは業務遂行のための情報を提供が可能なことを表わしていますので、
ここまでの成果物がBAにおける設計仕様書となります。
残りの機能体系であるDA、AA、TAの解説は次回に譲りましょう。
第１１９回はここで終了します。

今回は「ＥＡのフレームワーク－成果物と手法（BAの成果物）」を紹介しました。
次回は「ＥＡのフレームワーク－成果物と手法（DA,AA,TAの成果物）」をとりあげ
ます。

Comments(0)

前回、EAの４つの機能体系のBA（政策・業務体系）を取り上げましたので、今回は
残りの３つの機能体系であるDA（データ体系）、AA(適用処理体系)、TA（技術体系）
を取り上げます。
DAはBAで定義したDFDの成果物である情報機能関連図と情報体系整理図からデータ
ベースの関連を定義していきます。データベースの定義はデータベースの関係の
多重度定義とデータ項目の抽象化が作業項目となります。データベース関係の多重度
定義はERD（Entity　Relationship　Diagram）を用いて「実体関係図」として定義
します。
実体関係図のURL
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-5.pdf
この定義書のデータ項目は抽象化を行った「データ定義表」として作成します。
データ定義表のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-6-6.pdf
何の変哲も無いファール項目定義表のように見えますが、この項目は18府省で共通に
使用できるデータ項目となっています。今まで18府省で個別に人事・給与業務を
やっていたシステムを統合化するわけですから、このデータ項目の抽象化は必須の
作業となります。このデータ項目の抽象化の手法にはDAM（Data　Abstraction　
Matrix）があり、業務名と業務プロセスの抽象化手法にはEEM（Entiｔｙ　Event　
Matrix）が提供されています。これらの手法の紹介は後日に譲ります。
話を元に戻して、AAの機能体系の成果物を見てみましょう。
AAは業務遂行に必要な業務システム構成を「情報システム関連図」と「情報システム
機能構成図」を作成します。この定義図は私どもの全社統合システムの置き換える
と、「情報システム機能構成図」は販売システム、生産システム、会計システムなど
のシステム機能構成を表し、これらのシステムのインターフェース関係を記述した
ものが「情報システム関連図」となります。
情報システム機能構成図のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-8.pdf
情報システム関連図のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-7.pdf
TAは業務システム要件を満たすITインフラの構成を定義します。「ネットワーク
構成図」、「ソフトウエア構成図」そして「ハードウエア構成図」を定義します。
これらの定義図はよく作成されている方も多いと思いますので、URLから記述例を参照
すれば容易に理解できます。
ネットワーク構成図のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-9-1.pdf
ソフトウエア構成図のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-9-2.pdf
ハードウエア構成図のURL　
→　http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-9-3.pdf
以上、のべてきましたのが、EAの4つの機能体系での作業と成果物です。
この成果物を現行業務の現行体系として作成し、現行体系に改善を加えたあるべき
システムとして将来体系を作成することになります。この将来体系がRFPとして
調達要件資料となるわけです。
皆さん方が作成される要件定義書に該当するレベルの記述書に該当すると思います。
これらの成果物を作成するには、ガイドや記述サンプルがあればより統一された仕様
が出来上がることはお気づきでしょう。これをEAでは参照モデルといいます。

第１２０回はここで終了します。
今回は「ＥＡのフレームワーク－成果物と手法（DA,AA,TAの成果物）」を紹介し
ました。
次回は「ＥＡのフレームワーク－参照モデル」をとりあげます。

Comments(0)

　EAの４つの機能体系の成果物を作成するのに、作成の参照となるサンプルやガイド
　があれば一定水準の成果物を作成することが容易になると思われるでしょう。
　EAではこれを参照モデルとして４つの機能体系に対応して提示しています。
　BA体系の参照モデルにはBRM（Business　Reference　Model：政策・業務参照モデル）
　とPRM（Performance　Reference　Model：業績測定参照モデル）があります。
　BRMは業務を抽象的な業務分類に整理し、その雛形を提供する参照モデルで標準的な
　業務の機能モデルやプロセスモデル、情報モデルのガイドと記述例を提供して
　います。
　BRMのURLは→　　　
　http://www.meti.go.jp/policy/it_policy/ea/gainen/structure/ba/index.html

　PRMは政府内の複数ある業務を共通の業績指標で測定するための指標の参照モデルで
　ＫＧＩ（重要目標達成指標）とＫＰＩ（重要業績指標）といった業務目標を設定する
　ときに有効なモデルで米国のFEAの資料を参照モデルとして紹介しています。
　PRMのURLは→　
　http://www.meti.go.jp/policy/it_policy/ea/gainen/model/prm/index.html

　DA体系の参照モデルにはDRM(Data　Reference　Model：データ参照モデル)があり
　ます。このモデルは組織を超えて、流通もしくは共有される情報やデータの名称、
　属性などを標準的且つ統一的にする参照モデルです。
　DRMのURLは→　
　http://www.meti.go.jp/policy/it_policy/ea/gainen/model/drm/index.html

　AA体系の参照モデルにはSRM（Service　component　Reference　Model：サービス
　コンポーネント参照モデル）があります。このモデルはアプリケーションを構築する
　上で、システムを部品（コンポネント）で構築可能とする標準部品の分類・体系化
　された参照モデルです。考え方はSOA（Service　Oriented　Approach）に従った
　概念を紹介しています。
　SRMのURLは→　
　http://www.meti.go.jp/policy/it_policy/ea/gainen/model/srm/index.html

　最後に、TA体系の参照モデルにはTRM（Technical　Reference　Model:技術参照
　モデル）があります。このモデルは・組織の各システムで共通に利用する技術を
　体系化した参照モデルで主要技術を実用性、相互運用性、将来性の観点から評価
　する考え方と整理例を紹介しています。
　TRMのURLは→　
　http://www.meti.go.jp/policy/it_policy/ea/gainen/model/trm/index.html

　EAの4つの機能体系に対応する参照モデルは以上の通りです。これらの参照モデル
　に加えて、実例を参照できるようになっています。現在21個の共通業務野中で最優先
　に取り上げられた「人事・給与業務」、「共通システム」、「共済業務」、「物品
　調達業務」が府省共通業務・システムの最適化の項に実例として提供されています。
　4業務の実際の設計書のURL→　http://www.e-gov.go.jp/doc/scheme.html

　EAのフレームワークを述べてきました。概要機能はご理解いただけたと思います
　ので、次回から業務を設計する手順である「最適化計画策定プロセス」と取り上げ
　ます。
　第１２１回はここで終了します。
　今回は「ＥＡのフレームワーク－参照モデル」を紹介しました。
　次回は「最適化計画策定プロセス－全体プロセス」をとりあげます。

Comments(0)

前回まででＥＡの概要は掴まれたと思います。今回からはＥＡのフレームワークに
沿って業務システムを作成していく手順とその手法を見ていこうと思います。従来、
私たちが民間企業で実践してきたことと対比しながら見ていくと良くわかると思い
ます。
ユーザー企業の立場で業務システムを導入しようとする場合、ＲＦＰ（Ｒｅｑｕｅ
ｓｔ　Ｆｏｒ　Ｐｒｏｐｏｒｓａｌ）を出し、ＩＴベンダーを選定しその協力の
下に「要件定義」、「基本設計」、「詳細設計」、「製造・テスト」、「システム
移行」の開発フェーズを通して「システム運用」と進みました。
一方、ＩＴＣプロセスでは経営戦略に沿った情報システム作りのプロセスですので、
「経営戦略策定」、「ＩＴ戦略策定」、「ＩＴ資源調達」、「ＩＴ導入」、「ＩＴ
サービス活用」の5つのフェーズを推奨しています。ＩＴＣプロセスはＲＦＰを出す
「ＩＴ資源調達」の前に経営戦略とＩＴ戦略策定があります。
ＥＡの対象とするフェーズはＩＴＣプロセスのＩＴ戦略策定のフェーズに該当し
ます。 このフェーズを「最適化計画策定フェーズ」と言います。政府の業務システム
構築には経営戦略策定のフェーズは組み込まれません。経営戦略に相当する部分は
国会で法律として決定されてきますので、その法律に沿って円滑に業務遂行するため
の情報システムの構築となるからです。法律化された業務ですので、お役人の業務
規定書は六法全書がそれに相当しますから、六法全書片手に仕事をしているとよく
言われています。
この業務をＩＴ化するために、最適化計画策定フェーズにおける作業手順と仕様書、
活用手法等を規定し、共通なガイドラインとして「業務・システム最適化計画策定
指針（ガイドライン）」（現在は第4版）が作成され発表されました。
ＵＲＬ→　http://www.e-gov.go.jp/doc/20050202doc.pdf

最適化計画策定フェーズの作業のステップは「現状分析」→「見直し方針の作成」
→「将来体系の作成」→「移行計画の作成」の４ステップです。このフェーズの
終了後、「ＲＦＰ」が作成され、ＩＴベンダーとの「契約」、「開発」、「運用
/保守」、「モニタリング」というステップを踏むことになります。
最適化計画策定フェーズの４つの作業ステップを概観してみましょう。
「現状分析」では現行の業務プロセスと機能、情報等をＢＡ、ＤＡ、ＡＡ、ＴＡの
ＥＡフレームに沿って整理します。「見直し方針の作成」では業務としての目標を
達せするための改善/改革要件をＳＷＯＴ分析等を活用して見直し方針として策定
します。
「将来体系の作成」ではこの見直し方針に沿ってあるべき業務プロセス、機能、情報
等をＢＡ、ＤＡ、ＡＡ、ＴＡの将来体系ＥＡとして作成します。「移行計画の作成」
は将来体系があるべき姿としての目標業務システムですので、そこに至るまでの移行
のステップを策定し、現行業務の以降方針を策定します。
以上の4つのステップを通して、ＲＦＰ要件を定義済ます。
このステップが最適化計画といわれるフェーズです。政府調達の前段のＲＦＰを作成
するまでのフェーズを政府自身で作成するようになったと言うことは大変な変革
です。また、この手順を標準手順、手法として民間企業が活用できるためのリファ
レンスとしても役立てようとしているわけです。

EAの最適化計画策定フェーズを述べてきました。次回からこのフェーズの具体的な
設計手法や内容に入って行きましょう。
第１２２回はここで終了します。
今回は「最適化計画策定プロセス－全体プロセス」を紹介しました。
　次回は「現状分析－分析手順」をとりあげます。

Comments(0)

　EAの現状分析での成果物は先の119回、120回で述べたようにBA（政策・業務
　体系）、DA（データ体系）、AA（適用処理体系）、TA(技術体系)の現状分析資料です
　が、ここではこのフェーズの中核であるBA、DAに焦点を当てて話を進めます。
　従来、私たちが要件定義といっていたフェーズに該当すると考えてよいでしょう。
　これから数回、現状分析のステップを比較して読んでいただければと思います。
　現状分析の作業と成果物の全体フローを捉えてみましょう。７つの作業ステップから
　構成されます。
　★ステップ１：ファンクション分析
　　手法として、DMM（Diamond　Mandara　Matrix）を用い業務の機能構成を細分化し
　　ます。成果物は機能構成図と呼ばれます。
　★ステップ２：業務プロセスモデル作成
　　手法として、DFD（Data　Flow　Diagram）を用い現行ありのままに業務機能の情報
　　関連図を作成します。成果物は情報機能関連図と呼ばれます。
　★ステップ３：プロセスの論理化・抽象化
　　手法はDFDですが、業務のプロセスを有効な業務の塊として業務プロセスの抽象化
　　を図ります。
　　成果物は論理化された情報機能関連図です。
　★ステップ４：業務流れ図作成
　　手法として、WFA（Work　Flow　Architecture）を用いて、情報機能関連図を処理
　　担当部門、IT化業務機能が判別できるように、業務機能と部門とを関連付けた業務
　　流れ図です。
　★ステップ５：情報分析
　　手法として、DAM（Data　Abstraction　Matrix）を用いDFDで定義された情報項目の
　　抽象化を図ります。目的は各業務プロセスで使用されている帳票のデータ項目を
　　論理化して捉えることにあります。成果物として情報抽象化シートが出来上がり
　　ます。
　★ステップ６：EEM1（Entity　Event　Matrix　1：情報分析図）作成
　　手法として、EEMを用い情報抽象化シートのデータ項目と論理化された情報機能関連
　　図を用いて業務プロセスで作成される帳票へのデータ項目（Entity）の反映と業務
　　機能発生タイミング（Event）の関係で捉えます。
　　論理化された業務プロセスが論理化されたデータ項目を用いても現行業務をカバー
　　できていることを確認することにあります。成果物として情報分析図が出来上が
　　ります。
　★ステップ７：情報モデルの作成
　　手法としてUMLを用い情報抽象化シートのデータ項目をスタンディング情報（マス
　　ターファイルのように固定レコード）とイベント情報（トランザクションファイル
　　のような都度発生レコード）の関係を情報モデル図として情報体系整理図を作成
　　します。現行業務のデータベースの体系を整理したものと捉えてよいでしょう。
　以上が現状分析の作業です。　現状分析での７つのステップの各作業の詳細は次回
　から御伝えします。

　第１２３回はここで終了します。
　今回は「最適化計画策定プロセス－現状分析全体フロー」を取り上げました。
　次回は「現状分析－ファンクション分析」をとりあげます。

Comments(0)

ここからの解説は単なる説明というより、事例として話をまとめていこうと思い
ます。
DMM（Diamond　Mandara　Matrix）は3×3のマトリクスを用いて業務機能を分解して
機能構成図を作成する手法です。9つの升目の中央に対象業務を置き、左上の升目
から細分化されたサブ機能を時計回りに最大8つの升目に分解します。このレベルの
機能構成図を階層0といい、階層0のサブ機能を対象業務としてDMMを用いて業務分解
することで、より詳細な業務機能へと展開できます。
例えば、業務・システム最適化計画策定指針－ガイドライン（経産省）では文書管理
の例を上げています。階層0の文書管理の機能構成図は中央の升目に「文書管理」を
置き、サブ機能を左上の升目から時計回りに「文書受付」、「文書作成」、「決裁・
供覧」、「施行・発送」、「移管」、「廃棄」、「保存期間延長」、「管理簿作成」
となっています。この例でも分かりますが、サブ機能はイベントの処理順序に文書
受付から廃棄まで書き、保守業務、モニタリング業務と記述するのが一般的です。
機能構成図の階層１にはこれらの8つのサブ業務を対象にして、階層０と同様に
最大8つのサブサブ業務へ分解します。ガイドラインでは、「決裁・供覧」を階層１
の対象業務として取り上げ、この業務のサブ機能を「鑑作成」、「起案」、「決
裁」、「決裁文書件名簿登録」、「文書保存」の5機能に分解しています。同様に
して、階層2を作成しますと対象業務に対する最大8×8×8＝512個の業務機能が定義
できることになります。
このDMM手法は全く経験の無い業務機能を整理する場合に非常に有効な手段となり
ます。この手法が最初に公的な資料として紹介されたのはITCプロセスガイドでした。
その手法がEAで正式に採用されています。両方ともに設計者が松尾明先生（青山監査
法人）であることに起因すると思います。私が担当しました共通業務の設計でもこの
手法を最初に使用し、機能構成図を作成しました。
共通業務は18府省の業務を統一するわけですが、18府省に全てインタビューする時間
は取れません。参加したプロジェクトでも機能構成図の全府省会合は1回（半日）の
チャンスしかありませんでした。そのため、先行していて、より大きな業務機能を
持つ府省の業務資料を下にプロトタイプの機能構成図を階層0と階層１で作成し、
会合で各府省毎のグループのワークショップ形式で追加、修正を加えてもらい、
最小公倍数の機能構成図（原案）を作成しました。
その後、この原案を各府省に配布し、機能として含まれていることの検証を依頼し、
改定して行きました。
18府省の共通業務といっても、従来、府省間のやり取りは皆無だったわけですから、
同じ処理機能でも手段や処理手順の違いがありますし、各府省の特性が出てきます。
プロトタイプアプローチを取っていくことで全府省会合から2週間で現行の機能構成図
を完成しています。
このファンクション分析の意図は業務機能の体系的な整理をすることと設計担当者が
業務の全容を概要理解することにあります。この機能図を作成することで、対話
できる能力が付き、作業が開始できるようになります。
正直言いまして、プロトタイプを作成しないとまとまり取れなくなったでしょうし、
プロトタイプも作成できない業者についてきてくれなかっただろうと思います。
この後、DFD手法により業務機能を情報の流れとして把握して業務の連携を具体的に
することができることになります。
現行の業務プロセスモデルを作成していくことになります。

第１２４回はここで終了します。
今回は「現状分析プロセス－ファンクション分析」を取り上げました。
次回は「現状分析プロセス－業務プロセスモデル作成」をとりあげます。

Comments(0)