前回は、IT運用の内部統制という観点から、改善が必要として選定したIT運用の業務プロセスと、その改善活動をマネジメントするシステム（ひとつのモデル）を紹介しました。そのモデルは、ISMS（情報セキュリティマネジメントシステム）の認証取得と継続的改善を目標としたフレームワークでした。そして、改善が必要な業務プロセス（以降、重点対応プロセスと言う）の再構築は、そのフレームワークの「リスク対応計画」というフェーズで、計画し実施することにしました。

そこで今回は、上述の「重点対応プロセス」を再構築する作業のフレームワーク（ひとつのモデル）を紹介します。（下図は概念図です）

目次

(1)あるべきプロセスの設計

(2)現状とのギャップ分析

(3)実装プロセスの設計と(5)実装

(4)ドキュメントの作成

(1)あるべきプロセスの設計

　まず、推進事務局が、上図の「（１）あるべきプロセスの設計」を行います。この「あるべきプロセス」は、原則として、「現状の成熟度レベル＋１α程度」のレベルを満たす業務プロセスを描き（設計し）ます。現状の成熟度レベルは、すでに作成した「成熟度レベル診断表」の「（６）評価点（現状の成熟度レベル）」です。

※　現状より上位１＋αの成熟度レベルがJ-SOXの要求レベルをクリアーできない場合は、やむを得ないのでJ-SOXの要求レベルをあるべき姿とします。このようなケースは多分、IT運用組織の再編成を含む大がかりな対策が別途に必要になるのかなと思います。

推進事務局はＩＴ運用の現業組織に、この設計した「あるべきプロセス」を提示します。提示するドキュメントは、対象とする業務プロセスの「機能情報関連図（DFD：データフローダイヤグラム）」と「業務フロー図」です。
「機能情報関連図（DFD）」は、すでに作成している「成熟度レベル診断表」の「（１）点検項目（要求するコントロール）」と「（４）点検項目の評価（改善点、潜在するリスク等）」の内容を切り口として、IT運用のガイドラインであるITIL（IT　Infrastructure　Library）などのベストプラクティスなプロセスを参考にして作成します。そして、推進事務局と管理責任者のレビューを経て、完成させます。「業務フロー図」は、この「機能情報関連図（DFD）」から書き起こします。その際に必要な統制事項（コントロール）を明示します。そして、統制事項（コントロール）に関わる基準・ルールの要約を、この「業務フロー図」の下段の注釈に記入するようにします。完成した「機能情報関連図（DFD）」と「業務フロー図」は、あるべき姿（業務プロセス）として経営者の承認を得ます。そして、現業組織に次の一連の作業（上図参照）、「（２）ギャップ分析および（３）実装プロセスの設計、（４）ドキュメントの作成、（５）実装　」、を依頼します。依頼は管理責任者が行います。

したがって、推進事務局が設計し、IT運用の現業組織に提示する「あるべきプロセス」は、トップダウンアプローチにより設計したプロセスです。IT運用の現業組織は、提示された「あるべきプロセス」をひな型にして、現状からボトムアップした業務プロセス（実装する業務プロセス）を設計するようにします。「あるべきプロセス」と「実装する業務プロセス」は大抵、一致しません。（一致するということは「あるべき業務プロセス」の設計に問題があるかも知れません）。不一致の所がギャップです。
ここでは、「あるべきプロセス」と「現状の業務プロセス」の間に存在するギャップを解消するための努力を要求します。（解消が難しいギャップについては、推進事務局とIT運用の現業組織が合議し、代替策を検討します。おそらく、その多くは、実現可能性に関連した議論になるかと思います）。
推進事務局は、IT運用の現業組織による「実装プロセスの設計」作業の過程を定期的にモニタリングするようにします。そして、IT運用の現業組織が現状のプロセスを最大限にレベルアップし、かつ現業組織として”実現可能な”実装プロセスを設計できるように、後方から支援します。

———————————————

《作成するドキュメント》

機能情報関連図（DFD）
業務フロー図
———————————————

(2)現状とのギャップ分析

上図の（２）ギャップ分析は、提示された「あるべきプロセス」と「現状の業務プロセス」とのギャップを明確にするものです。そして、そのギャップを解消するために必要な改善策と、それを可能にするアクションプランを検討し、立案します。「現状の業務プロセス」と「あるべきプロセス」が著しく乖離しており、そのままの適用が困難な統制事項（コントロール）については、実現可能な代替策を検討します。
教科書的に言うと、統制事項（コントロール）は「予防的なもの」／「発見的なもの」／「IT化されたもの」などがあると言われています。予防的なものは、職務の分掌とか、二重チェックとか、審査／承認とか、業務の記録などがあげられます。発見的なものは、結果を示すAとBの比較／照合とか、不正の検知／警告とか、作業記録／システムログとか、作業履歴などがあげられます。IT化されたものとは、システム化（プログラミング）された自動的なコントロールを言います。代替策はこれらの統制事項（コントロール）を組み合わせて、想定されるリスクに対応させます。また、統制事項（コントロール）のモデルとして前述（第１回目で紹介）のCOBITに掲げられている「コントロール目標」を参考にするのも良いでしょう。ただし、COBITの「コントロール目標」は、目的レベルで記述されています。・・ので、具体的な実施レベルの統制事項（コントロール）にブレークダウンして利用することになります。
また、推進事務局から提示された統制事項（コントロール）よりも、IT運用の現業組織に適合する統制事項（コントロール）があれば、おそらく後者の方が有効かと思います。推進事務局の提示に固執することなく柔軟に、より良い適切な選択をしましょう。要は、より実現可能性の高い有効な統制事項（コントロール）を選択することが重要だからです。
そして、並行して実施しているISMS（情報セキュリティマネジメントシステム）の導入作業（リスク分析の結果（「リスク分析表」の「想定されるリスクと予防策」）を確認／検証しながら、「現状の業務プロセス」に対する改善策をまとめていきます。
———————————————
《作成するドキュメント》

ギヤップ分析表
———————————————
※グループ会社ＩＴ運用
（１ｂ）標準プロセスの設計、（２ｂ）現状とのギャップ分析

　上図の下段に描いた「（１ｂ）標準プロセスの設計」と「（２ｂ）現状とのギャップ分析」は、小規模なIT運用組織を持つ、グループ会社用に設計するものです。グループ会社共通の標準プロセスとして提供します。
この「（１ｂ）標準プロセスの設計」は、上述の「（１）あるべきプロセスの設計」で作成した「機能情報関連図（DFD）」を使用して設計します。端的に言えば、グループ会社用（小規模な組織用）に必要、且つ、最小限の機能に絞り込んだプロセスを設計することになります。たとえば、職務分掌等の予防的コントロールなどは、小規模な組織ゆえの工夫、現実的な対処が必要になります。とってつけたような、滑稽な職務分掌などは、実効面からしても意味がありません。どちらかというと、発見的なコントロールに重きを置いたプロセスにならざるを得ません。業務プロセスを軽装化するために、システムログなどを取得し管理することも有効です。ツールの導入も考慮すべきです。（小規模なＩＴ運用組織にとっては、必須の要件と言っても良いと思います）。
次の「（２ｂ）現状とのギャップ分析」の作業内容は、上述の「（２）現状とのギャップ分析」の作業と同じです。標準プロセスと現状の業務プロセスのギャップを分析し、そのギャップを解消するために必要な改善策を立案します。

余談ですが・・・、２０数年前（～１０年位）、多くの企業内IT部門がITの専門会社として分社しました。その中で、IT運用を担う子会社も多かったように思います。設立の形態と目的はそれぞれ異なるようですが、一様に今、悩みを抱えている組織が多いように言われています。その悩みを一括りにすると、本社との関係において、期待される役割の変化によるものと思われます。それは、経営環境の変化に伴って形骸化してしまった役割の再設定が求められています。そこで、一案です。親会社（本社の統括部門）を系列とするIT子会社のポジションを活かして、当該の活動（ＩＴ運用のプロセス改善）を役割として担うことは如何でしょうか？　この役割の目指すパフォーマンスは「企業グループとしてのIT環境の統合と共有化／IT運用サービスの一元化」と言うことになりますか・・・。

余談の余談ですが・・・、J-SOX適用の　1年目（3月決算の企業）の開示が当年6月から始まりました。2年目以降の課題として、本社統括部門の果たす役割がクローズアップされるように思います。本社単体ではなく、企業グループとして内部統制を捉え、対応することが必要です。開示の状況をみると特に、海外を拠点とするグループ会社への対応が弱いような気がします。（これは、業務処理統制を含む全社的な内部統制の課題として提起されるものですが・・・、それを下支えするIT運用としても無関係とは言えません。前述、余談のＩＴ運用子会社の期待される役割もここにあります。）
———————————————
《作成するドキュメント》

業務フロー図
業務記述書／帳票定義書
RCM（リスクコントロールマトリックス）

———————————————

(3)実装プロセスの設計と(5)実装

あるべきプロセスと現状の業務プロセスとのギャップ分析（グループ会社のIT運用組織の場合は、標準プロセスと現状の業務プロセスとのギャップ分析）から、実現可能な上位レベルの実装する業務プロセスを設計します。

J-SOX を意識するあまりに、統制レベルを強め過ぎると、IT利活用の自由度を過度に阻害する事態を招くことがあります。IT運用の本来の役割からすると、本末転倒の事態を招きかねません。実装するプロセスの設計にあたっては、「統制」と「利活用」のバランスを保つこと。これは、実現可能性と併せて重要な要件です。バランスのレベルはIT運用組織とＩＴを利活用する組織との関係性と相関します。ＩT運用の場合は、ITを利活用する人に加えて、アプリケーションシステムを設計し、開発するIT部門の人達も利活用する組織(顧客)として識別します。これらの顧客との日常の関係（マネジメント）の善し悪し（レベル）が活きてくる局面です。それは、システム利活用部門におけるオーナー部門の定義、役割の設定とか、ＩＴ部門における開発と運用の職務分離とか、種々の権限設定とか、顧客との合意を元にしたルール作りなどの局面を指します。組織によっては根気の要る説得が必要な場合も想定されます。ここは、IT運用の現業部門にとって日常のマネジメントが活かされる場面でもあり、時を得た、頑張りどころでもあります。この局面には、推進事務局および管理責任者のサポート（後ろ盾）も必要です。なぜならば、実装プロセスをIT化（自動化）することも、業務の効率性の観点から、考慮すべきだからです。実装の迅速性、継続性を考えると、適当なパッケージソフトの導入もまた、有効な方策かと思います。上述の顧客への説得に根気を要する組織などは、IT化（自動化）を次年度の方策とするのも良いと思います。実装の結果を確認し、評価した後にIT化（自動化）する。その場合は、業務面で多少の不効率を覚悟することも必要です。推進事務局および管理責任者は、顧客の不効率に起因するストレスの高低を勘案して、適切な選択をすべきでしょう。いずれにしろ、実装プロセスのIT化（自動化）は、効率的に内部統制とＩＴ活用のバランスを保つための必須の要件として、考慮すべきかと思います。

(4)ドキュメントの作成

当該の（１）あるべきプロセスの設計から始まる活動の成果物として次のドキュメントを作成します。

業務フロー図
業務記述書
RCM（リスクコントロールマトリックス）
　いわゆる、内部統制文書の3点セットです。金融庁の「内部統制報告書に関するQ&A」／追加Q&A（2008.6.24）によると、これらの文書はJ-SOXとして必ずしも要求するものではないと言っています。ですが、私は一連の作業の成果物として作成すべきものと思っています。なぜならば、それは当該活動の継続性を維持するために有効な文書として評価するからです。特に、RCM（リスクコントロールマトリックス）は活用すべきかと思います。業務フロー図および業務説明書はRCM（リスクコントロールマトリックス）の附属文書でも良いと思います。文書のフォーマットにこだわる必要はありません。
また、内部監査人、外部監査人に提供する文書としても有効です。監査は定期的に行うことになります。監査人および監査を受けるＩＴ運用の現業組織にとって、その工数は一定の負担となります。監査の効率化は、必要な課題として考慮すべきです。
文書を作成すると更新が必要です。とかく、このような文書はメンテナンスされずに放置されてしまう恐れがあります。RCM（リスクコントロールマトリックス）を継続する当該活動の成果物とすること、監査人に提示する必須の書類とすること、によって、メンテナンスが義務化されます。依って、RCM（リスクコントロールマトリックス）が更新されているということは、当該の活動が継続して実施されていること、ＩＴ運用のマネジメントレベル（内部統制の管理レベル）が更新されていること、を証明します。

———————————————

　次回は「第４回　重点対応プロセス」の改善、再設計~実装計画を策定する。」《その２：作成するドキュメント》と題して、当回で紹介したフレームワークで作成する一部のドキュメントについて、その書式と記載内容の概要（モデル）を紹介します。
———————————————