システム監査、マネジメント、コントロール、リーダーシップ

前の記事で、「監査」の話がありました。システム監査は、「コンピュータシステムに関連するリスクに対するコントロールを評価すること」くらいに理解するとよいでしょう。「システム」という言葉はマネジメントシステムのようなコンピュータシステムとは異なる概念を指すこともある要注意の言葉です。また、「コントロール」という言葉も日本語に訳すると「管理」なのですが、この「管理」という言葉は「コントロール」と「マネジメント」というニュアンスが異なる言葉を含む概念なので、この点も要注意だと思っています。
例えば、「変更管理」という用語ですが、これは訳すると、Change Controlであって、決してChange Managementではありません。コントロールという言葉も学術的には様々な定義がありますが、私は自動車の運転をイメージしています。自動車は、基本的には公道を道路交通法というルールに従って、目的地まで人が運転します。道をそれないように、ハンドルを制御します。他の自動車の邪魔にならないようにある程度スピードを出すためアクセスを踏みます。また、事故にならないようにブレーキを踏んで、スピードを調整します。一方で、「マネジメント」は一般に「成果を出すために実施するあらゆる活動」が含まれるので、コントロールとは区別できる重複する部分のない概念です。スピードをマネジメントするとは通常言いません。しかし、自動車レースでタイヤマネジメントという場合、これをコントロールとは言いません。この時は1週なるべく速く走ろうとすると、タイヤを消耗するので、タイヤの消耗をいたわりながらも、レース全体を考えて、それぞれの周回のタイムをコントロールするイメージです。監査の対象は「マネジメント」ではなく、「コントロール」です。インシデント管理、変更管理、構成管理、問題管理などなどという意味です。私は、「標準業務手順書を含むルール作成し、ルールに従って業務をすること」くらいに理解しています。
。例えば、あるプロジェクトにA君ではなく、B君をアサインするという行為は、プロジェクトの特性、A・Bそれぞれの経験・スキルだけでなく、むしろ経験が不足しているAの成長をリスクととってマネージャが意思決定するような場合があるのですが、この意思決定はマネジメントの領分なのですが、この意思決定を第三者が評価などできません。
コンピュータシステムを開発する場合は、「情報システム管理規定」のような文書に従って、それに従ってセキュリティを確保する。そして、「コンピュータシステムの開発手順書」があれば、それに従って、要件定義、設計、実装、テストを実施しているかを評価します。「コンピュータシステムの運用・保守管理規定」のような文書があれば、それに従ってインシデント管理や変更管理等が実施されているか評価します。コントロールが適切に機能しているか評価します。業界の規制を遵守するための社内のルール等が社内になければ、コントロールのレベルが低いと評価し、改善を提案します。

プロジェクトマネージャとプロジェクトリーダーも役割が全く異なります。この話はまた今度します。
また、規定や手順書を作ることも難しい業務なのですが、例えば製薬業界の場合はGAMPのようなGood Practiceがあるので、これに沿って手順書を作成します。ERESのような規制要求もあるので、これも理解して手順書を作成します。運用・保守であれば、ITILもありますね。手順書作成という業務も奥深い面白い業務なので、これもまた機会があれば話したいと思います。ISO、QMS、日本の規制、欧米の規制まで考慮して、書いているということを理解してほしい。単なる内規や備忘録ではありません。