初めに
有期型プロジェクトの怨念
打ち上げが終わればすべてチャラ
メンバーが頻繁に入れ替わる
育成のための予算はつかない
チームの成長戦略には2通りある
ひとつは、個々の課題を解決することでチームの成長を目指す方法
もう一つは、目標を決めて現状との差異を埋める施策を実施することでチームの成長を目指す方法
専門的には、前者を帰納法的、後者を演繹法的というらしい
課題解決的な成長戦略
早く実現できるが問題が再発しやすい
対処療法的・場当たり的
ゴールが見えない
チームの特徴に合致しやすい
計画が立てづらい
成長度合いが見えない
目標達成的な成長戦略
時間がかかるが長持ちする
根本的解決
ゴールが見える
チームのルール変更を伴う
計画的に施策を打ちやすい
成長度合いが見える
システム監査業務は
俗人化より標準化を目指す
感と度胸より数値化、見える化を目指す
行き当たりばったりより予測できる計画できる組織を目指す
正しい原則や理論は後にし、個人的に好きな業務なので、なぜ好きかを先にお話ししますので、興味が湧きましたら、本題のほうもお読みください。
早速ですが、監査業務で私が一番好きなところは、「個別最適化」から「全体最適化」を目指して、枝葉の細かな問題ではなく根本的な問題に目を向け、問題点の明確化と改善策を提案するところです。
これは、コンサルティングの原則でコンサルタント自身が成果を上げることはせず、クライアント自身が成果を上げるようにすることが最大の任務となるのと同じで、監査者は自身で成果を上げることはしません。
あくまで、依頼者自身が成果を上げて、業務を改善してゆくことが原則です。
また、監査で対象を評価するには基準となる物差しが必要です。
世の中には先人の苦労から導き出されたベストプラクティスが数多くあります。
その中から、汎用的にまとめたものが標準や基準と呼ばれるものです。
そして、「全体最適化」を目指す第一歩は標準化です。
標準は言語と同じで、ステークホルダー同士が問題なく情報を疎通するために最低限必要なことです。
現場第1主義の方には基準や標準を嫌う方がいますが、長い間同じメンバーで同じような作業を続けて行く業務であれば、それも成り立ちますが、プロジェクト運営のようにステークホルダーやメンバーが頻繁に変わるような業務では、なかなか大変です。
基本的な部分は基準や標準で固めて、応用レベルで特化した技術や手法で業務を遂行するのが理想です。
たとえば、コーディング規約や変数の命名規約などが決まっていれば、作業者が変わってもバグなどを防止できます。
そういう意味では、汎用性が高いJavaなどの開発言語では、担当者のさじ加減で好きなように書けるので、逆に理解が難しくなり開発効率は低下します。
オブジェクト指向も汎用性を制限するPrivate属性などにより、制限を掛けることでバグの入り込む隙間を小さくして開発効率を向上する役割を担っています。
Javaもオブジェクト指向のはずなのですが、アノテーションのような拡張機能が追加されて、機能が豊富過ぎて使えないシステムと同じ道をたどっているような気がします。
その点、VBAはシンプルな言語として親しまれたBasicをベースにしていることや変数や関数に2バイト文字が使用できるので、日本語で理解しやすいプログラムが書け、補助コメントだらけになるプログラミングから比べて、見やすくなり、バグの発生を防止できます。
そんなことで、標準化により業務体系や技術体系を整理でき、シンプルで分かりやすい環境を実現する監査業務は複雑化したプロジェクト運営には欠かせない存在と考えます。
原則
システム監査基準より
[１] システム監査の意義と目的
システム監査とは、専門性と客観性を備えたシステム監査人が、一定の基準に基づいて情報システムを総合的に点検・評価・検証をして、監査報告の利用者に情報システムのガバナンス、マネジメント、コントロールの適切性等に対する保証を与える、又は改善のための助言を行う監査の一類型である。
[２] システム監査基準の意義と適用上の留意事項
「システム監査基準」（以下「本監査基準」という。）とは、情報システムのガバナンス、マネジメント又はコントロールを点検・評価・検証する業務（以下「システム監査業務」という。）の品質を確保し、有効かつ効率的な監査を実現するためのシステム監査人の行為規範である。
[３] システム監査上の判断尺度
本監査基準に基づくシステム監査においては、情報システムのガバナンス、マネジメント又はコントロールを点検・評価・検証する際の判断の尺度（以下「システム監査上の判断尺度」という。）として、原則として**「システム管理基準」**又は当該基準を組織体の特性や状況等に応じて編集した基準・規程等を利用することが望ましい。
なお、システム監査は各種目的あるいは各種形態をもって実施されることから、他のガイドラインや組織体独自の諸規程・マニュアル等を、システム監査上の判断尺度として用いることもできる。特に、情報セキュリティの監査に際しては、「システム管理基準」とともに、「情報セキュリティ管理基準」を参照することが望ましい。
システム管理基準一部抜粋
Ⅲ．開発フェーズ
1.開発ルールの管理
(1) 情報システム部門長は、事前にシステム開発部署とシステム運用部署の責任を分離す
ること。
＜主旨＞
システム開発業務において不正を防止するために、開発と運用の責任を分離する必要が
ある。
＜着眼点＞
① システム開発部署の職務及び責任が明確に定められていること。
② システム開発部署の職務及び責任には、システム運用、システム利用を含めないこと。
(2) PM は、プロジェクト標準を策定し、文書化し、プロジェクト運営委員会の承認を得る
こと。
＜主旨＞
プロジェクトの品質を確保するためには、プロジェクトの担当者が遵守すべきガイドラ
インとしてプロジェクト標準を定める必要がある。プロジェクト標準には以下の内容が含
まれる。
① 成果物に関する標準
② 作業に関する標準
③ プロジェクト支援ツール
＜着眼点＞
① PM は、プロジェクト標準の策定に必要な資源を確保すること。
② PM は、開発の規模、開発手法、システムの特性、スキルレベルに適合したプロジェ
クト標準を策定すること。
③ プロジェクト担当者が遵守すべき項目を明確に記載すること。
④ プロジェクト支援ツールの選択にあたっては、適用可能性や効果を評価すること。
⑤ プログラムのコーディング標準を定めること。
⑥ 品質、コスト、進捗に関する測定指標を定義すること。
⑦ 他のシステムとの整合性を確保すること。
⑧ 外部委託を行う場合は、「Ⅶ．外部サービス管理」に準ずること。
⑨ プロジェクト標準に関わる情報セキュリティ管理策については、情報セキュリティ
管理基準参照表を利用して、情報セキュリティ管理基準の該当箇所を参照すること。
CMMIについて
CMMIとは組織成熟度
成熟度レベルは、最初にプロジェクトレベルでプロジェクト管理の基礎を達成することからはじまり
定性的データ、定量的データの両方を使用して意思決定を行い
最終的には組織全体にわたる継続的な改善へと進む段階的な改善経路を提供する。
※解説
・プロジェクトの活動（生産性や品質）が計測できているか
レビュー実施状況やバグ発生状況などプロジェクトの活動状況が数値化されて計測できているということは、過去の実績と今の状況から未来を予測できるということです。
逆に、計測されていないということは、未来が予測不能で、場当たり的な対応しかできなくなります。
・ＰＤＣＡを回して改善を継続できているか
プロジェクトの活動状況を計測し記録できるようになると、その状況に応じた過去の対応の記録からＰＤＣＡを回すことで対応内容も洗練し改善されて行きます。
逆に、正しくＰＤＣＡが回せないと、安定化はしますが、それ以上の改善や成長が望めません。
・プロジェクト内だけか組織として標準化されているか
各プロジェクトの経験やノウハウを組織として共有する為には標準化が必要です。
逆に標準化されていないと、各プロジェクトのエゴが組織全体としての利益を阻害する可能性もあります。 ⇒ 個別最適化は必ずしも全体最適化ではない