【具体例】ユーザー導入教育 - ドキュメントの保管について
【文言】
弊社の情報システムでは、ドキュメントの保存、保管に下記の媒体を想定しております。それぞれ個別の注意点がございますので、ご注意ください。
PCのデスクトップ
マイドキュメント
ファイル・サーバー
グループ・ポータル
外部媒体
<< PCのデスクトップ >>
PCのデスクトップは、仕掛りのドキュメント等、一時的な保管目的の際にご使用ください。個々人のPCのデスクトップは、バックアップが全く取られていないため、PCの故障等の際に、そのデータの復元は不可能となってしまいます。
<< マイドキュメント >>
マイドキュメントは、その使用アカウント（ユーザーID）の人がログインした際に、その人しか見れないフォルダです。そのため、個人的なドキュメント（人事的なものや、健康診断、家族構成、税金関係の書類等）につきましては、当マイドキュメント・フォルダをご使用ください。
当フォルダは、個々人のPCと常に同期がとられ、毎日バックアップしております。そのため、故障等の事態でも、復元が可能です。また、当マイドキュメント・フォルダにあまりにも大量のドキュメントを保管していると、その同期に著しく時間がかかります。当フォルダのクリーニングにつきましては、個々人の責任で適宜行ってください。
<< ファイル・サーバー >>
ファイル・サーバーは、権限管理に応じ、見ることができる人を限定したフォルダです。そのため、チームや部門等、他のメンバーとファイルを共有したい場合、当ファイル・サーバー内のフォルダをご使用ください。
当フォルダは、毎日バックアップしております。そのため、故障等の事態でも、復元が可能です。しかしながら、ご操作による上書き保管等の場合、その復元が難しい場合があります。そのため、編集・更新の際には、細心の注意を払うよう、お願いいたします。また、その運用方法は、各チーム・部門にお任せいたしますが、不要なコピー等は、できる限りお控えください。ドキュメントのコピーとは、監査上、情報の複製であり、その漏洩リスクが高まる行為、と考えられております。
<< グループ・ポータル >>
グループ・ポータルは、権限管理に応じ、見ることができる人を限定したフォルダです。そのため、チームや部門等、他のメンバーとファイルを共有したい場合、当グループ・ポータル内のフォルダをご使用ください。
先に掲げた、ファイル・サーバーとの違いですが、大きく下記の点が違います。
・インターネット環境からの接続性
当ポータルはインターネットからでもアクセスできます。その際には、弊社の情報システムにアクセスする際に使用しているアカウント（IDおよびパスワード）の入力を求められます。
・ドキュメントのバージョン管理
ドキュメントのバージョンを自動的に管理し、世代毎のドキュメントを保管できます。これを応用すると、誤操作による上書き等行った際にも、その前のドキュメントを復元することが可能です。
当フォルダは、毎日バックアップしております。そのため、故障等の事態でも、復元が可能です。また、その運用方法は、サイト管理者にお任せいたします。
<< 外部媒体 >>
弊社の情報システムでは、そのポリシー上、外部媒体へのデータのコピーを禁止しております。しかしながら、さまざまな業務内容により、その必要性があることも事実です。そのため、下記の例外事項についてのみ、そのコピーを認めております。
・メールボックスのクリーニングのための、過去のメッセージのアーカイブ
CDやDVDにデータをコピーし、それを社内で保管する場合。必要に応じ、その媒体内の情報を参照したり、復元したりする際に許可しております。
・社外の場所での業務の必要上の一時的なデータの社外持ち出し
業務上の必要に応じ、外部媒体にデータやドキュメントをコピーし、社外で使用することも可能です。しかしながら、その使用はあくまで一時的であり、その使用後速やかに媒体より消去してください。特に、社外のPC等にデータをコーピーしなければならない場合は、細心の注意を払ってください。コピーしたデータやドキュメントをそのまま放置した場合、監査上、情報の漏えいと看做され、重い処罰が下ります。
また、外部に持ち出す媒体ですが、必ず、会社が承認したものを使用してください。
個人所有のUSBメモリ等にコピーした場合は、その時点で、情報の個人的な複製と看做され、社外に出た瞬間に、データの個人使用による社外への無断持ち出し、と看做されます。
--------------------
上記に長々と書いていますが、要するに、指定された媒体に必ず保管し、また、できる限り組織として情報を共有してください、ということになります。
確かに、情報はできる限り自分だけのものにしたい、という誘惑はあるでしょう。
しかし、その誘惑に負けず、チームプレイを重視し、社会の変化に柔軟に対応していくことが、結果として、もっと魅力的なことなのです、というようなことを、毎回必ず伝えるようにしています。
もちろん、その文言を資料に書くわけにもいきませんので、口頭での説明になりますけど・・・
次回は、電話機について、具体例を書いてみます。
【具体例】ユーザー導入教育 - インターネットの使用について
【文言】
弊社の情報システムでは、現在のところ、インターネット閲覧の際に、特段制限は設けておりません。しかしながら、その内部仕様として、個々人のアクセス状況はすべて記録されており、誰が、いつ、どのPCから、どのサイトに、どのくらいの時間、滞在していたのか、すべて把握されております。
アダルトサイト、誹謗中傷、ギャンブル、差別、セクハラ、個人的な利益のため、等のサイトは絶対に見ないでください。また、誤って、そのようなサイトに入ってしまった（飛んでしまった）際には、速やかに、ウィンドウを閉じてください。
--------------------
今回はインターネットの使用に関して、書いておきます。
実際には、電子メールの使用に関する部分と同様で、非常にシンプルな内容の指導となっています。
禁止事項の制御のため、プロキシサーバを設置し、その部分を適宜制御することも当然可能です（ということは、現在は導入されていない、ということですけれど・・・恥）。
しかし、現在は、インターネットサイトもどんどん複雑化されており、必要な情報へのリンクもいろいろな手段（検索エンジンや、メールマガジン、Twitter等）で提供されるようになっています。
さらに、けんぢの会社は外資系であるため、プロキシサーバに設定すべきフィルタは、日本向け＋海外向けの設定を必要とします。
現在はその部分を踏まえ、機種選定等行っている段階です。
たぶん、アプライアンス製品を導入するでしょう。その方が、運用面で勘弁ですし。
もちろん、電子メールと同様で、原則論としては、インターネットも業務上の目的のみに使用しなければなりません。
しかし、実際には・・・
インターネットで登録して、その確認がメールで配信されて、またインターネットで変更して・・・のようなことは存在しますしね。
ある程度は仕方ないのでしょう。モチベーションやチームの潤滑材になる程度の使用は致し方ありませんね。
次回は、ドキュメントやファイルの保管についての具体例について書いてみます。
【具体例】ユーザー導入教育 - 電子メールの使用について
【文言】
弊社の情報システムでは、Microsoft Outlook2007を使用しております。画面構成等につきましては、業務を行いやすいよう、カスタマイズして構いません。
<< 容量について >>
現在は800MB（メガバイト）としております。これは、一般の会社と比較してかなり多い（通常は250MBくらいで運用しているケースがほとんどです）ですが、電子メールをあまり溜めますと、PCのパフォーマンスに多大な影響を与えます。
<< 補足事項 >>
メールボックスのクリーニングにつきましては、個々人の責任で適宜行ってください。Outlookに標準で使用できる、アーカイブ機能を使用すると、自動的に行われるため、大変有効です。
--------------------
今回は電子メールの使用に関して、書いてきます。
実際には、シンプルな内容の指導となっています。
基本的に、組織が個人に提供しているメールシステムは、組織の所有物であり、メールアドレスに設定されているドメイン名も、組織の所有物です。
そのため、このメールアドレスの個人的な使用は認めておらず、その部分の詳細な事項は、セキュリティポリシーに記載し、運用しています。
しかし、実際には、ある程度の個人的な使用は行われている（これは一般社員だけでなく、経営幹部もそうでしょう・・・ゴルフの予約とか・・・）ことは否定できません。
組織として、電子メールシステムを飛び交うメールメッセージを検閲することも可能でしょう。
しかし、それは内部統制的には正しいことかもしれませんが、それに費やすエネルギーは非常に内向きであり、組織で働く従業員間の信頼関係を著しく阻害するものでしょう。
そのような訳で、けんぢの会社ではそのようなことは行なっておりませんし、現時点まで、幸運なことに、検閲の必要性を再考させられるような事故は発生しておりません。
また、メールボックスのサイズですが、実際のところ、無制限に設定している組織もあります。しかし、上限値を設けることにより、その内容を常に直近に保ち、個々人の所有から、組織としての所有へと、情報の共有化を進めています。そのような意味で、あえてその旨を明記しています。
要するに、電子メールシステムや、その上を飛び交うメッセージも含めてすべて組織の資産であり、場合により、検閲することもあります、ということを明確に伝えておくことにより、その運用の正常性が保たれるようにすることが一番日本人に合うのではないでしょうか？
甘い、と言われてしまえばそれまでですけど・・・
次回は、インターネットの使用についての具体例について書いてみます。
【具体例】ユーザー導入教育 - ネットワークログインについて
【文言】
弊社内の情報システムでは、その使用時に、専用ネットワークにログインする必要があります。また、その際に使用するIDおよびパスワードは、それぞれ個別のものを与えております。
特に、パスワードは、情報システム部門でも知り得ない、個々人のみに割り当てられた情報です。
<< 注意事項 >>
そのIDおよびパスワードの管理には、細心の注意をお願いいたします。特に、PCに付箋等でパスワードらしきものを貼り付けていることが見受けられますが、それにつきましては、監査や内部統制（SOX法等）対応の注意事項として厳しく指摘されます。ご注意ください。
<< パスワードの変更頻度 >>
弊社内の認証システムでは、現在、自動でのパスワードの失効期間設定等は行なっておらず、皆様の良識によって、その変更が行われるような仕組みとしております。
適宜、推測されにくいパスワードに変更するよう、努めてください。
推奨される、一般的なパスワードの変更頻度は、45日～60日毎です。
パスワードの変更方法は、"Ctrl" + "Alt" + "Delete"キーを押し、「パスワードの変更」ボタンから行ってください。
--------------------
上記にあるように、けんぢの会社では、パスワードポリシーをシステム上制御していません。
もちろん、原則論では制御したほうが良いのですが、持ち株会社であり、かつ傘下の複数の会社に段階的に情報システムサービスを展開している関係で、一気呵成にパスワードポリシーを適用することができない状態です。
これまで使用しているシステムへの影響や、ユーザーのこれまでのITリテラシに開きがあり、それを適用することの負の影響が未だに色濃く見られるからです。
そのような意味で、まず、当該導入教育を広く行い、全体的なリテラシの底のレベルを合わせ、その後、底上げを図っています。
道はまだまだ続いています・・・辛抱辛抱・・・
次回は電子メールの使用についての具体例について書いてみます。
【具体例】ユーザー導入教育 - 配布物について
【文言】
原則として、会社は、以下の物品を貸与いたします。情報システム部門では、個人個人に会社から貸与している物品について、すべて管理（物品のシリアルナンバーや貸与者、および想定貸与期間等）しています。
そのため、もし紛失や破損等の場合は、その旨を速やかにお申し出ください。それを怠りますと、後日他の方に迷惑がかかるだけでなく、その修復に想定よりも高い金額がかかってしまいます。
また、異動や退職時には、その必要に応じ、速やかに貸与機器類をご返却いただきます。その際には、当該機器類に保管されている情報は無条件に消去いたします。
<< 貸与物 >>
当人の使用するPC（セットアップがすべて完了しているもの）、および電源ケーブル、マウス
携帯電話機（許可された者のみ）
--------------------
上記は、会社が貸与した物品は、その金額の大小に関わらず、すべて管理されており、その所有件が会社にあること、また、従業員はそれを借りて業務を行っている、と言うことを明確にするため、わざわざ説明しています。
上記の管理には、社内でのシリアルナンバーを記載したステッカー（テプラで作成）をすべての物品に貼りつけ、その台帳管理を行っています。
もちろん、その物品数はそれなりに膨大なため、紙ベースの台帳管理ではなく、システム化しております。
現在使用しているシステムは、『レンタルアシスト』で、バーコードでピッとスキャンしたりできるようにしています。
若干のカスタマイズは施していますが、基本的な貸出管理はノンカスタマイズ（既存フィールドの流用や応用と、業務サイクルの変更）で対応できます。
バーコードリーダー端末が若干高価なため、小規模ではその効果は出ませんが、それなりの物品数がある場合、非常に効率的で、その管理が実践できます。
サプライヤの社長や開発者の方々は非常に良心的で親身になって考えてくれます（こちらの無茶がある場合、その指摘等、柔らかく行ってくれ、最低限のカスタマイズで済むように考えてくれます）。
興味があれば、コンタクトしてみてください。
さて、次回は、ネットワークログインについて書いてみます。
ユーザー導入教育
けんぢの会社では、情報システムユーザーに対して、その導入研修を入社時等、その必要に応じて、必ず行っています。
基本的には、PCの業務上の操作に関することなので、受講者の方々の中には、『何を今さら・・・』という方もいらっしゃるかと思っています。
しかしながら、実際に導入教育を行っていくと、受講者の方々はその制約事項の多さにゲンナリしていくことが、手に取るようにわかります。
もちろん、IT技術は日々進化しているので、できる限る制約事項を取り除き、ユーザーに対し、最新技術を提供したい、という気持ちはあります。
しかし、常に最新を導入していく、と言うことは、常に老朽化していくサービスを産んでいく、ということになり、結果として、情報システムの安定性の欠如や、サポート側の管理体制に多大な影響を及ぼします。
そのような理由を背景に、できる限り、その運用を標準化するため、導入教育で、その制約条件を説明し、理解を得ている、ということを行っています。
この導入教育ですが、けんぢが、現在の会社に入社した際には全くありませんでした。
組織自体が未熟であった、ということもありますが、それ以上に、サービスマネジメントが欠如していた（裏返せば、ある意味常に最新技術に触ることができた）ため、性善説に基づいた無法地帯であったことが主な理由です。
対象ユーザーが少人数の場合には、それでもよかった（それでも前任者はパンクしていましたが）のかもしれませんが、情報システム部門を運営していく立場として、今後の人員およびサービスの拡大や柔軟性の確保、さらには、内部スタッフの効率化を想定し、外堀から埋めていく作戦を実行したわけです。
当初は、ヤイノヤイノ言われましたが、現在ではすでにその教育は安定稼働し、人事部門も、そのセッションを予め準備してくれています。ありがたいことです。
さて、当該導入教育では、その目的を、『情報システム環境、および、情報システム・ポリシーを正しくご理解いただき、今後の情報システムを使用した業務を、安全かつ正しく行っていただくためのセッション』と設定し、以下のことについて説明しています。
配布物
ネットワークログイン
電子メールの使用
インターネットの使用
ドキュメントの保存
電話機
印刷物を出力するときの注意
サービスの申請
「そんなところまでわざわざ説明しなくとも・・・」と思われる方もいらっしゃるでしょう。
性善説を否定するわけではないですが、『書かれていなかったから・・・』や『説明されていなかったから・・・』という言い訳で行われてしまった事故は結構多い（顕在していないものを想定すると、相当な量になると思われます）ものです。
皆が知っている一貫したルールを敷くことによって、相互抑制や、不用意な事故を防ぎ、結果として、高品質のサービスの継続的な提供が可能になってきます。
次回から数回に分け、上記の事項に関する詳細な説明を書いてみます。
復元テスト
今回は、システムやデータの復元について、その内部統制の観点からのポイントを説明します。
前回、説明しました、バックアップに関してのガイドラインに加えて、重要アプリケーションに関するすべてのデータを復元でき、復元した時点でデータに完全性があることを事業が確認することも不可欠です。
原則として、完全性は明らかに必要です。しかしながら、現実問題としては、トランザクションデータを複数のテーブルに格納しているデータベース内のデータの完全性を確保することは特に困難です。
完全性を確保するには、すべてのトランザクションが完全な形で、単一時点のスナップショットである必要があるからです。
個々のファイル、特に稼動中のデータのバックアップでは、必ずしもこれを保証できるとは限りません。
データに財務トランザクションが格納されている場合、全データの完全性を確認する唯一の方法は、復元したデータをアプリケーションのテスト環境（または品質保証環境）に接続して十分なテストを行うというものです。
テスト用システムと稼動中のシステムでそれぞれ数種類のレポートを出力・比較し、バックアップを行った時点の本番システムとデータが一致することを確かめることが重要です。
これは容易な作業ではなく、全データの格納とアプリケーションの実行が可能なテスト環境およびその機器類が必要です。
また、その復元だけでなく、環境設定やその維持、さらには業務レポートの出力とその意味等、専門的な知識のある人員が時間を割く必要もあります。
上記を行うことは決して簡単ではありません
しかしながら、その経験は、内部統制だけでなく、非常事態時のシステムの復旧等、必ず役に立ちます（たとえ非常事態が起きなくとも、それに対し、備えておくことは、組織のリスクの大幅な軽減につながります）ので、ぜひ挑戦してみてください
下記にその実践の際のポイントを記しておきます。
復元テスト
【統制内容】
各基幹・重要アプリケーションのすべてのデータ・ファイルが復元可能で、データの整合性が維持されていることを定期的に確認しましょう。
整合性検査を実施できるように、該当する基幹・重要アプリケーションの本番コピーを移植したテスト環境を準備し、テストを実施しましょう。
また、復元の対象となる重要なデータ・ファイルを明記し、復元テストの頻度を定めた計画書を準備しておくことも大変有効です。
【検査頻度と成果物】
年1回は、システムの完全復元テストを行い、その結果を保管しておきましょう。復元ログを保管しておくと有効です。
完全復元テストは、複数のファイルがトランザクション型アプリケーションの一部である場合に、特段の注意が必要です。
このようなアプリケーションでは、アプリケーションの完全性を証明するために、深いレベルのテストを実施する必要があります。
ファイルサーバ内の一部のファイルの復元に関するテストも忘れてはなりません。
たとえ単一ファイルでも、業務上重要なデータを同梱しているファイルはたくさんあります。
すべてのファイル・システム上で適切な復元が行われたことを確認するために、部分的な復元に対しても、その結果を検証用に保管しておくことが必要です。
特定の期間内に部分的な復元を必要とするファイル・システムでは、その実施スケジュールが必要となります。
通常操作中に復元されなかったファイル・システムでは別途特別に復元を行い、その実施スケジュールを遵守しなければなりません。
復元の際にエラーが発見され、その都度手動にて対応する、ということはよくあることです。
しかしながら、その根本原因をそのまま放置しておけば、次回のテストや非常時に必ず同様の手動操作が必要となります。
そのため、何らかのエラーが確認された場合は、自動的な（または属人的でない）システムの完全復元が難しいわけですから、必ず、その解決に向けたアクションを必要とし、また、そのことは記録され、適切なスピードで解決されている必要があります。
次回は少し目先を変え、けんぢの会社内で、実際に起こっている困ったことを紹介しておきます。
バックアップ
システムやデータのバックアップが必要だ、と言うことは、特にここで明言しなくとも理解している、という読者の方が多いでしょう。
しかしながら、ここでバックアップの意味を、もう一度考えていただけましたら幸いです。
バックアップは、あくまで、その復元を前提としているものです。つまり、正確に復元できないバックアップに意味はありません。
システムおよびデータを正確に復元できない場合、データの消失やはデータの不整合により、システムを業務上使用できなくなるため、ユーザー（顧客など）に対するサービスや財務管理に支障が出る場合がある等のリスクを常に抱えてしまうことになります。
有事が無ければ大丈夫、という考えもあるでしょうが、いざという時に備え、常に適切にバックアップを取得しておく必要があります。
完全な裏方作業ですが、情報システム部門は、元来縁の下の力持ち、という側面がありますので、リスク軽減を主眼に置いて対応してみてください。
正確に復元できるバックアップを取得するためには、若干堅苦しいですが、次の点を考慮に入れておかなければなりません。
・すべての重要なデータをメディアにバックアップし、安全な方法で取り扱い、輸送、保管すること。
・日常的なバックアッププロセスが機能していることを確認すること。
上記を確保するために確認すべき点は2つあります。
第1に、原則として、毎日バックアップログをレビューし、エラーや警告についてはその重大度に応じて対応することです。
第2に、メディアの循環、交換、輸送、保管の各プロセスが適切であり、その原則が遵守されているかどうかです。遵守を検証できるよう、これらのプロセスは文書化された管理策を伴わなければなりません。
また、システムやアプリケーションを復元（再構築）できるよう、すべての重要アプリケーションおよびシステムの全システム・ソフトウェアのコピーを安全な場所に保管し、最新の状態に保つことも不可欠となります。
具体的には、下記のような統制を実践してみると良いでしょう。
十分な手順の整備
【統制内容】
バックアップの手順が明記され、バックアップ担当者がその手順を認識し、遵守されていなければなりません（その手順には、準備手順および内容を把握していない人にも内容が分かるように、媒体にはっきりとラベル付けする手順を含めることも重要です。バックアップ・スケジュールとともに、媒体のローテーションおよび使用期間に関する要件についても手順に含めておかなければなりません）。
【検査頻度と成果物】
年2回ほど、バックアップの手順およびバックアップ・スケジュール、および、バックアップを実行する担当者を明記したスケジュールの確認を行う。これを適切な管理者が承認することが重要です。
また、四半期ごとに、バックアップ・テープが、別の場所に保管されていること、および、復元時に参照しやすいようにラベル付けされていることの確認も行なってください。バックアップ担当者は、常にその業務を行っているので、いつの間にか、その基本原則が崩れていってしまいます。担当者の罪ではなく、遵守させる管理者の責務の欠如がそのような事態を生んでしまいます。
バックアップ・ログの検証
【統制内容】
バックアップの度に、そのバックアップ・ログを調査し、エラーメッセージがないかどうか確認しましょう。
【検査頻度と成果物】
バックアップの度に、その取得の完全性を検証済みのバックアップのログをバックアップ媒体とともに保管しておきましょう。何らかのエラーが確認された場合は、システムの完全復元には使用できないわけですから、必ず、その解決に向けたアクションを必要とし、また、そのことは記録され、適切なスピードで解決されている必要があります。
バックアップ媒体の劣化によってエラーが引き起こされることもあります。適宜劣化状態を検査し、予防措置（クリーニングや新しい媒体への交換等）を確実に行なっておきましょう。
次回は、システムやデータの復元について、内部統制上の観点から必要とされることを書いていこうと思います。
インタフェースの完全性
組織または事業部門内での業務は、決して1つのプロセスだけで完結するわけではなく、必ずいくつかのプロセスが連鎖、連携しています。必ず開始点と終了点があり、前プロセスから何らかの結果を受け取り、自プロセスでその結果を加工し、次プロセスに結果を引渡していきます。
情報システムの内部統制では、事業の必要性に適した保護体制を確立、提供し、各プロセスやアプリケーション間のインタフェースを把握してコントロールできるよう、重要プロセスおよびアプリケーションを抽出し、リスト化しておくほうが良いでしょう。
ここで言う、リスト化の対象となる重要プロセスとは、下記のものがその適用範囲となります。
各組織内で、その事業遂行上、基幹となるアプリケーション、またはERPモジュールと、総勘定元帳との間のすべてのプロセスおよびインタフェース。
通常、インタフェースは2種類あります。
1つは異なるアプリケーション間のインタフェースで、インタフェース・ツールを使用してデータのマッピングと変換を行う場合です。
このようなインタフェースでは、障害を引き起こす恐れのあるポイントが複数あるため、インタフェース・アプリケーションおよびツールごとに整合性検査が必要です。
これらのインタフェースの代表的な例は、ERP（統合アプリケーション）と、給与、銀行支払い、人事（スタンドアロン）の各システム、時間記録用アプリケーション、さらに組織において重要となる顧客情報/課金アプリケーションとのインタフェースです。
もう1つのインタフェースは、ERP上位階層のモジュール間のインタフェースです。
これらは非常に密接なインタフェースで接続されていますが、それでもなお問題が発生することがあるため、レポート等を出力・調査して、インタフェース間に機能的または技術的な矛盾がないかどうか確認しなければなりません。
プロセスおよびアプリケーション間で結果としてのデータが送信される場合、エラーまたは不足点が存在するにも関わらず、それが検出されなかったり、何者かによって偽データに置き換えられたり、加工されたりする可能性があります。
情報システム部門が注意尽力を払うのは、自動インタフェースでシステムエラーが生成されないようにしたり、データフローに対して不正な変更を行えないようにすることです。
アプリケーション間でやりとりされる数字に対して責任を負うのは、そのアプリケーションやデータの「所有者」です。
もちろん、通常、インタフェースの設計の責任は、情報システム部門が負うため、設計のコントロールが必要で、またそれは上記の「所有者」と足並みを揃えて行う必要があります。
エラーが顕在化しない、と言う問題が存在する可能性が最も高いのは、独立したアプリケーション間でのデータのやりとりです。もちろん、ERP（統合アプリケーション）のモジュール間でやりとりされるデータの確認プロセスを備えることも重要です。多くの場合は、確認レポートを適宜作成してレビューすることでこの問題を回避、予防しています。
このようなレポートの数値を確認することは情報システム部門の業務ではありませんが、ソフトウェアの実装時や、アプリケーション所有者からの依頼を受けた場合、または定期的に確認レポートを作成することは情報システム部門の業務となります。
許可なくデータを変更できないことを確認するために、各プロセスのインタフェースの完全性をレビューし、必要な場合は、プロセスを変更することも重要です。
実際に、内部統制の確保の実践として行うべきことは下記になります。
インタフェースのマッピング
【統制内容】
すべてのインタフェースをマッピングし、すべてのインタフェースが正しく接続されていることを確認すること（マッピングには、各インタフェースの稼働頻度とその所有者が示されなければならない）。
【検査頻度と成果物】
年1回、マッピングリストおよびこれまでの運用結果のレビューを行うと良いでしょう。
インタフェースの動作検証
【統制内容】
インタフェースの所有者は、ビジネス・システムおよびインタフェース・アプリケーション（必要な場合）の該当するレポートを調査し、インタフェースがエラーなく稼働していることを確認すること（この統制は、情報システム統制ではなく、該当するビジネス領域に含まれている場合がある）。
【検査頻度と成果物】
適宜、各インタフェース実行後にレポートを出力し、それを検査すると良いでしょう。
堅苦しい様に書かれていますが、実際には、合計数や金額の目視によるチェック等、日々定常的に行なっているものですから、それを保管しておくことが良いとされています。
インタフェース・エラーの検証
【統制内容】
情報システム部門および適切な業務管理者により、すべてのインタフェース・エラーの検証を行い、どの修正も正式に承認され、適宜解決されていることを確認すること。エラーは、その内容と発生理由を明記して責任の所在を明らかにし、解決策およびその対応を予定に組み込む必要があります。
【検査頻度と成果物】
月1回（努力目標ですが）、レビューを行い、インシデント管理表、およびインタフェース所有者によって修正対応が正式に承認された証拠書類を残しておくと良いでしょう。
次回は、内部統制上の、バックアップとリストアについて書いてみます。
IT資産管理
けんぢは業務運営の上で常に感じていますが、IT資産管理は結構厄介です
ここで言う、「管理」ですが、きちんと実情を把握し、適宜監視し、さらに必要なアクションを起こす、ということを意味しています。
IT資産、と呼ばれているものには、下記のものが含まれます。
ハードウェア
備品
ソフトウェア
また、実際には、下記のものも、ITを構成する要素として存在しますので、きちんと管理しなければなりません。
プロジェクターやデジタルカメラなどの、ITと親和性が高い機器
ハードウェアのキッティングや、ソフトウェアのインストールに係る労務
IT資産（機器）のメンテナンスや、アップグレード等に係る労務
上記のように、列記してしまえば、管理する項目は比較的シンプルですし、それをExcelとかで管理することも十分可能なように感じてしまいます。
しかしながら、実際は、ソフトウェアの無許可のインストールや、メンテナンス、備品の追加購入等で知らないうちに資産は増えています。
また、その機器がどのPCに接続されているの？ということになると、人力で的確に把握することは非常に難しくなります
もちろん、予防的な措置を講じることは可能でしょう。ただ、トラブル対応やそのメンテナンスに係る労務をあらかじめ予期することは難しいでしょう。
そのような訳で、IT資産管理に係る実務は、どうしても後追いになってしまい、放置され、いつの間にか管理不能な状態に陥っていきます。
情報システムの内部統制の実践では、IT資産のTCOを的確に把握する必要がありますから、それを放置しておくと、あとで慌てることになります。
けんぢの場合、前回にも書きましたが、その対策として、ManageEngine ServiceDesk Plusを使用しています。
このツールでは、ドメイン（ネットワークでも可）内に接続されているPCを自動検知し、その内部構成を検索してくれます。
これで、インストールされているソフトウェアや、接続されている備品等も検知してくれます。
また、その資産の購入費用や、キッティングやプレインストールに要した労務（費用換算して）も「コスト」として管理できます。
さらには、定常業務としての運用記録（メンテナンスや追加ソフトウェア等）も、インシデントとリンクしています。
もちろん、上記は「把握」するためのアクションですので、それだけで良いわけではありません。
上記で得た事実をレポートとして分析することにより、一時的・突発的なインシデントなのか、潜在的に問題を抱えている問題なのかが判断でき、先行して予防措置を行うことが可能になります。
また、PCの老化や劣化もその購入時期や、リソースの残存状況を的確に把握することにより、次年度予算の組み立ても、より説明責任をもつ形になります。
下記のリンクでデモサイトの体験操作や、製品概要に関する情報が読めます。
無償版も備えておりますので、ぜひ遊んでみてください。
当該製品の購入を奨めているわけではなく、ツールを使用したIT資産管理を体感および概要理解することができるでしょう。
次回は、内部統制に係る、システムインターフェースについて書いてみます。