前回は、「重点対応プロセス」を再設計（改善）し、実装する作業のフレームワーク（ひとつのモデル）を紹介しました。今回は、当該のフレームワークで作成する主なドキュメントを紹介します。これらは必ずしも、J-SOXということで要求されているドキュメントではありません。《　業務フロー図　》《　業務記述書　》《　RCM（リスクコントロールマトリックス）　》、内部統制文書の3点セットと言われている文書も含めて、IT運用の業務プロセスを再設計（改善）するという目的から作成されたドキュメントのモデルです。

目次

１．　機能情報関連図（DFD:　Data　Flow　Diagram）

２．　業務フロー図

３．　ギャップ分析表

４．　帳票定義書／業務記述書

５．　RCM（リスクコントロールマトリックス）表

１．　機能情報関連図（DFD:　Data　Flow　Diagram）

　機能情報関連図は、業務と情報の流れを明確にするために作成します。それは、業務の目的・役割を実現するために必要な機能を抽出し、整理するものです。抽出はトップダウンアプローチで行います。整理は階層構造でまとめます。つぎに、筆者の機能の抽出と整理の仕方（自分では一般的と思っていますが・・）を紹介します。

（１）機能の抽出

左図は、機能階層図と呼ばれるものです。構成する機能を階層化して描きます。階層の下位に置く機能は上位に置く機能の目的を意味しています。筆者は、ボトムアップでなぞるように「×××（下位の機能）は×××（上位の機能）のために・・・」と、その階層構造を確認したりします。

　自分が、十分に把握している業務の場合は、右図の機能構成図を用いて機能を抽出します。所謂、真ん中に大日如来を置いて、いろいろな役割を担う仏さまを配置する、あの「曼荼羅」のイメージ（右図）です。複数の機能を「役割」とか「目的」という秩序を核にして組み合せて、曼陀羅模様に表現するものです。「対象とする業務の機能を抽出する」という事から言えば、上図の機能階層図（目的樹木図とも言う）との違いは、表現方法の違いだけで、求める内容は同じです（正方形の升目の中に機能を記述します）
　複数のメンバーや、多くの人が関与する共同作業の場合は、記述する機能の階層レベルを事前に定義して置くことが必要です。記述する機能の階層レベルが設計者（作成者）によって異なると、読者（実務担当者）の理解を妨げる恐れがあります。

 

次に筆者の採用する機能の階層レベルを例示します。これは、参考までに例示するもので、正解という訳ではありません（定義することが重要です）。

階層レベル１（活動領域）＝＝＝＝＝＝＝＞例：　IT、・・等々
階層レベル２（役割／機能）＝＝＝＝＝＝＞　　　IT運用、・・等々
階層レベル３（一連の業務）＝＝＝＝＝＝＞　　　アクセス管理・・等々
階層レベル４（業務）＝＝＝＝＝＝＝＝＝＞　　　利用者IDの付与、・・等々
階層レベル５（業務の要素）＝＝＝＝＝＝＞　　　申請書の作成、・・等々
階層レベル６（作業）＝＝＝＝＝＝＝＝＝＞　　　申請書の記入、・・等々
階層レベル７（作業の要素）＝＝＝＝＝＝＞　　（申請書を）取り出す、・・等々
階層レベル８（動作）＝＝＝＝＝＝＝＝＝＞　　（申請書に）手をのばす、・・等々

　当該の改善活動で作成する機能情報関連図は上記の「階層レベル＝３」の単位で、レベル４とレベル５を対象にして記述しています。階層レベルの１は、企業における活動の領域、たとえば「研究開発」とか「生産」、「営業」、「財務」等々のレベルを意識しています。（今や、ITをこのレベルに位置づけることに異論はないと思いますが如何でしょうか。）階層レベルの２はITにおける「企画」とか「開発」「運用」等々のレベルを意識しています。階層レベルの３が当該活動の対象とする業務プロセスです。作業と動作に関わる階層レベルの６、７、８は対象外としています。

（２）機能の整理

上述の「機能階層図」や「機能構成図」等により抽出した機能から、上図の「機能情報関連図（DFD:　Data　Flow　Diagram）」を作成します。抽出した機能を楕円で配置します。大きな楕円は小さな楕円の上位の階層レベルの機能です。平行する二本線の中に、台帳とか、帳票とか、共有する書類・ファイル等の名前を記述します。特定の機能に関係する事物（他の業務・組織・システム等の情報発信元あるいは発信先）は矩形の中に記述します。これらの図形をつなぐ矢印は情報（データ）の流れを示します。機能と機能を情報で繋いで、その関連を整理し、対象とする業務の流れを設計します。

私は、基本的に右図の伝統的なシステム モデルを念頭に置いて設計します。入出力情報とその処理、変換ロジックとフィードバック（コントロール情報）の組み合わせが機能情報関連図（DFD:　Data　Flow　Diagram）なのだろうと思います。そして、そのフィードバック（コントロール情報）が内部統制に関係します。
　よく考えると、IT運用を担う技術者は日々、このモデルの整合性と闘っていると言っても過言ではありません。バランスを崩すと不効率（高コスト）なIT運用になります。不整合を起こすとトラブル（業務が継続できない状態）を引き起こしたりします。

 

２．　業務フロー図

　業務フロー図は、機能情報関連図を実際の業務手順に返還したものです。変換に際しては、業務の処理手順とその業務に関わる人、組織、情報システムなどを明確にします。その中で、業務手順に具体的な統制事項（コントロール）を付加して組み込んでいきます。必要な内部統制の基準・ルールなどは、その要約を下段の注釈に記述します。ルール集とか基準書、規程集などを検索できるようにしておくと便利です。業務フロー図の様式は、普段、書きなれているものを採用すれば良いと思います。当然ですが、標準化されている様式があれば、それを採用することがベストです。
　ひとつの考えとして、SOA基盤を活用するBPM（BPMN）により業務フローを作成することも考えられます。それは、業務プロセスの継続的な改善を容易にするなどの効果を期待することができます。ただし、当該のプロジェクトとして、新しくSOA基盤を構築するというテーマを課すと、活動の目的を分散させてしまう恐れがあります。SOAの基盤が確立されていない場合は、BPMの適用を留保した方がよいでしょう。”テストケースとして”という考え方もありますが、あまりにも荷が重すぎるように思います。
　これは余談ですが、上図の「伝統的なシステムモデル」の入力（情報）を「供給する者に対する要求」とし、出力（情報）を「提供する者に対するサービス」とし、処理を「生産（サービスを作り出す行い）」として、その連鎖を描いていくとSOA（Service　Oriented　　Architecture）に通じてきます。SOAを意識して取り組むことは、今後のシステム化（プロセスの自動化）を容易にします。（SOAおよびBPMは別途、重要な課題と認識して取り組むべきでしょう。）
　　下図は、今回の活動（ひとつのモデル）で作成した業務フロー図の様式です。これはひとつのサンプルで、特別に目新しいものではありません。（当該の活動組織が日常的に使用している様式をアレンジして採用したものです。）

機能情報関連図（DFD:　Data　Flow　Diagram）とは、上図のDivision／Function／業務フローの番号と機能の名称で連係しています。
　記述される機能の階層レベルは、
上図のＤivisionは階層レベル３（一連の業務）
上図のＦunctionは階層レベル４（業務）
上図の業務フロー図の業務処理（記述記号）は階層レベル５（業務の要素）です。

 

３．　ギャップ分析表

　ギャップ分析表は、「あるべきプロセス」と「現状の業務プロセス」とのギャップを明確にします。そして、そのギャップを解消するために策定した「改善策」を記述します。そして、その改善策を「実施責任者：改善策を実現する人」および、「実施完了予定日：改善策を実現する日」を確定して記入します。「改善策」には、個々の改善策を識別する「管理番号」を付与します。付与した「管理番号」は、リスクコントロールマトリックス表の「管理番号」と連環させます。ギャップ分析表に記述した「改善策」は、後続のステップである「実装プロセスの設計」で実行されます。「リスクコントロールマトリックス表」の「管理番号」は、その実行状況を監視するために記載して置くものです。

　次にギャップ分析表の記入項目を示します。

（１）業務フロー図と連環する記入項目

・　Division　　　
　　　・　識別番号／一連の業務名称
・　Function
　　　・　識別番号／業務名称
・　業務フロー図の業務処理（記述記号）
　　　・　識別番号／業務の要素名称

（２）当該文書の中心となる記入項目

「あるべきプロセス」とのギャップ
想定されるリスク
「現状の業務プロセス」に対する改善策
実施責任者
実施完了予定日
管理番号
起案責任者（管理監督者）／承認者（マネージャー）のサインと日付

 

４．　帳票定義書／業務記述書

　帳票定義書と業務記述書は、業務フロー図の内容を解説する附属文書です。説明書と言っても良いでしょう。当該の文書について、更新と保管を義務付ける文書にするかどうかは議論すべきです。なぜならば、業務フロー図の説明は備考欄に記述する補足説明で事が足ります。帳票定義書は実装後の帳票サンプルで事が足りる筈です。したがって、当該文書の必要性と利用価値は限定的と言えます。監査人等の第三者に当該の業務を理解して頂く必要がある場合は、作成した方が良いでしょう。（監査による被監査部門の負担を軽減することは、実務を担う部門にとって重要な課題です。）しかし、このような文書は、作成して以降、二度と手にすることもなく保管されたままの”忘れられた文書”になる要素を持っています。状況に応じて、必要な時に作成する文書と言う事で、良いのかもしれません。

　次に帳票定義書と業務記述書の記入項目を示します。

（１）帳票定義書

・　帳票の名前
・　識別番号／記入項目の分類
　　　　ヘッダー／セントラル／フッターなど帳票フォーマットから分類（ヘッダー／セントラル／フッター）したり、
　　　　記入項目の内容から分類したりします。
・　識別番号／記入項目
・　作業の種別と記入の必要レベル
　　　　たとえば、登録・変更・削除などアクションの別に記入の必要なレベルを設定します。
　　　　必要レベルは、○印：必須の記入項目、△印：適用する組織によって選択が可能な記入項目
　　　　というように定義します。
・　備考

（２）業務記述書
Division　　　
　　 ・　識別番号／一連の業務名称
作成日／作成者
Function
　　　・　識別番号／業務名称
業務フロー図の業務処理（記述記号）
　　　・　識別番号／業務の要素名称
Outline（業務要素の記述）
　　　業務および業務要素の説明を記述します。
備考
参考資料
　　　添付する、上記（１）帳票定義書の帳票の名前を明記します。

 

５．　RCM（リスクコントロールマトリックス）表

　　RCM（リスクコントロールマトリックス）表は、該当する業務の中で発生し得るリスクと、そのリスクをコントロール（統制）する方策を示します。RCM（リスクコントロールマトリックス）表の「リスク番号：Rxx」と「コントロール番号：Cxx」は、上記２の業務フロー図と連係します。業務フロー図の対応するプロセスに、その適用箇所を明記します。（Rはリスク、Cはコントロールの略でxxは番号です）。　また、「管理番号」は上記３のギャップ分析表の「管理番号」と連係しています。これは、ギャップ分析表の「現状の業務プロセスに対する改善策」の実施状況をモニタリングするために設定しています。
　　　当該の改善活動を継続的に機能させるために、その有効性を測定しマネジメントすることは重要です。組織の活動目的を明確にして、獲得する成果目標と獲得した成果を測定し、次年度の活動に結び付けていく（マネジメントサイクルを回す）活動にすべきです。これはIT運用を担う組織の重要な成果領域と成果指標になります。活動をレベルアップするために、次のような成果目標の引き出し（成果領域）を定義しておきます。これは、RCM（リスクコントロールマトリックス）表の「統制の目的」と「リスク」＆「コントロール」と対応させます。この引き出しから、「コントロール目標」と、達成する「成果指標」を設定し、組織マネジメントとしての目標管理システムに連動させます。

該当するコントロールはIT運用の

信頼性を高める
可用性を高める
保守性を高める
完全性を高める
安全性を高める

 

下図に、今回の活動（ひとつのモデル）で作成したRCM（リスクコントロールマトリックス）表の様式を示します。

 

次回は、「重点対応プロセスの参照モデル　《　その1：アクセス管理　》」と題して、当該の活動において選定した重点的に改善・再構築するプロセスの一つ、「アクセス管理」を参照モデルとして紹介します。