ホーム  >  メルマガバックナンバー  >  Ⅳ.Enterprise Archtecture  >  第135回「将来体系設計プロセス-業務プロセスの抽象化」

オープンコース案内

  • 第135回「将来体系設計プロセス-業務プロセスの抽象化」

    ~ITコンサルタント養成講座~

    皆さん、こんにちは! 当メルマガを担当しています井上正和です。112回からは、このメルマガでEA(Enterprise Architecture)を取り上げています。
    e-Japan戦略も2006年3月31日をもって終了し、今後の5年の施策として「IT新革新戦略」が実施されています。そこには、電子政府は導入の段階に入り、自治体、独立法人等へのEA展開が明記されました。
    EAは日本が最初に公的に発表したソフトエンジニアリングと思っています。昨年から、電子政府の業務・システム最適化計画のプロジェクトに参加している中で、EAが難しいという意見をよく聞きました。小職も実際の成果物を作る中でかなり苦労しました。出版物も多く見受けますが、“帯に短し、襷に長し”の感があります。自分なりにもう少し、わかり易く解説できないものかとの疑問がありました。昨年、私のコースの受講生の方からEAのメルマガをやってくれませんかと要望があり、トライしてみようと思いました。
    今日はEAメルマガの第24回です。

    メルマガの127回、128回でEEM(Entity Event Matrix:情報分析図)とDAM(Data Abstraction Matrix:情報抽象化表)を取り上げました。
    それぞれ現行体系で、共通業務として複数の府省の独自の処理をまとめるために抽象化して最小公倍数的な機能を持たせて記述するために採用した抽象化の技法でした。それぞれDAMが各府省の独自のデータ項目を共通のデータ項目とするために抽象化、EEMはトランザクション出力情報に必要なマスターファイルのデータの関係付けを行い、業務と情報の妥当性を確認するものでした。
    現行体系では現状を把握するために使用しましたが、将来体系の情報分析図としてEEM1をもとにEEM2へ拡張して作成します。今回はこの抽象化概念を取り上げようと思います。
    EEM2の作成の位置づけは将来体系のDMM(Diamond Mandara Matrix:機能構成図)→DFD(Data Flow Diagram:情報機能関連図)を作成後、DAM (Data Abstraction Matrix:情報抽象化表)をより抽象度を高めで作成し、EEM2(Entity Event Matrix 2)の作成となります。その後、WFA(Work Flow Architecture:業務流れ図)→情報モデルとしての情報体系整理図の作成順序になります。
    EEM2を話す前に将来体系のDAMを取り上げましょう。EEM1で共通業務として複数の府省を整理するためにデータフィールド名称を統一する話をしました。例えば、承認者を○○承認者や××承認者、あるいは○○課長と言うように各府省で同じ機能でも全く違った名称で使用されていたフィールド名称を“承認者”というようなフィールド名称に統一することです。この考え方をEEMのトランザクションプロセスと組み合わせるとモット大胆な抽象化が可能となります。
    例えば、「申請受付処理」、「申請承認・却下処理」、「申請許諾回答処理」があったとしましょう。各
    処理で承認者がいるはずです。そうしますと、フィールド名称は申請受付承認者、申請承認・却下承認者、申請許諾回答承認者という風に3種類のフィールド名称が必要になります。しかし、ここに処理コードを入れると1つの名称でよいことになります。“承認者”というフィールド名称にして、処理タイプコードとして、各処理コードをそれぞれ“01”、“02”、“03”を設けることによって、01の処理をしているプログラムは同じ承認者のデータフィールドを扱っていても“申請受付承認者”を扱っていることを意味することが可能になります。同様に、承認者という名称フィールドに加え、全く別の担当者や監督者、管理者、社員等人にまつわる名称がたくさん出てきます。ただ、ある処理では“承認者”と“監督者” を使用するが、別の処理では“社員”と“管理者”しか使用しないという状況があります。
    このような場合の抽象化は人タイプコードを設けてフィールド名称を“担当者”、“監督者”等にまとめ、人タイプコードを“H1”、“H2”と言う風にコード付けします。そうすると処理タイプコードと人タイプコードのマトリックステーブルを作成しておけば、ファイルのフィールド項目は格段に抽象化された項目で処理が可能となります。このことはプログラム作成において単純なI/Oで処理ロジックを作成できるとともに、ユーザーはマトリクスのメンテナンスのみでシステム維持・管理の容易なシステム運用を可能とすることになります。
    EEM2の構造はこの抽象化されたデータフィールド項目を立軸にとり、横軸にトランザクション処理を配置することでトランザクション処理にデータ項目の関係を関連付けた設計書が出来上がります。
    実際の将来体系ではEEM1までの作成で完了になり、EEM2の拡張は行われていませんでした。
    概念としては、非常にすばらしいのですが、設計者が追いついていけないところに原因があったようです。
    第135回はここで終了します。
    今回は「将来体系設計プロセス-業務プロセス設計の抽象化」を取り上げました。
    次回は「移行計画の作成」をとりあげます。

    ISMリサーチ代表 井上正和
    question@mail.ism-research.com


    (雑感)先週、6月15日にe-Japan発足時のIT戦略本部の中で設立された情報セキュリティ政策会議から「セキュア・ジャパン2006」が発表になっていまして調べてみました。この政策は、今年2月2日の「第1次情報セキュリティ基本計画」の基に2006年から3年間で情報セキュリティガバナンスの意識付けを政府機関、重要インフラ、全企業、国民に対して植え付け、その実施体制を確立する計画です。情報セキュリティガバナンスというのは経産省がBCP(事業継続計画)で掲げたテーマでした。このガバナンスを確立するのはISMS体制を確立することといっています。ISMSの認証の最新版であるJISQ27001とJISQ27002が今年の5月20日に発表されています。この資格認定を受けるとISO27001,27002も同時認定となるようです。全てがIT新改革戦略(経産省)でいうITで社会を改革すると言う方向で統
    一されてきているように思います。


    (注1)「ズバリ!経営戦略立案ソフト」を開発し、発売開始しています。
    経営戦略目標から部門の行動計画まで、経営者が容易に、体系的に作成できる
    パッケージです。
    こちらです。 http://e-site-frontier.kir.jp/index-11.html
    (注2) ITコーディネータガイドラインV1.0対応の「ITコーディネータ試験想定問題
    集」と「ITコーディネータ試験対策コース」を開発しました。
    問題集はこちらを参照 http://www.ism-research.com/book-3.htm
    研修コースはこちらを参照 http://www.gtc.co.jp/semn/isc/itc.html
    (注3) 「経営戦略」、「情報戦略」の基礎知識を整理したメルマガ本で、この応用編
    メルマガの基礎知識の集大成をしました。
    ISMリサーチが絵入り解説で提供していますので、まとめには最適です。
    こちらです。 http://www.ism-research.com/book-1.htm
    (注4)「経営戦略」、「情報戦略」のオンサイト研修を実施しています。適正な
    価格で、カスタマイズした実践的コースを提供します。
    こちらです。 http://www.ism-research.com/course-1.htm
    (注5)「経営戦略」、「情報戦略」の基礎知識を今までのメルマガのマグマグの
    バックナンバー(無料)から入手することができます。
    こちらです。 http://backno.mag2.com/reader/Back?id=0000118350
    (注6)小職が実施している主な研修機関の研修コースは以下の通りです。
    ●株式会社 アスキー
    http://ascii-business.com/abiz/itseminar/
    ●グローバルナレッジ(株)
    http://www.globalknowledge.co.jp/reference/Reference.asp?KBN=1&DCODE=29&SCODE=170
    ●(株)富士ゼロックス総合教育研究所
    http://www.pm-fxli.com/multi.html
    ●(株)グローバルテクノ
    http://www.gtc.co.jp/semn/isc/itc.html

ページトップへ

サイドメニュー

オープンコース案内