【システム監査】
















  経済産業省














    システム監査基準 http://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kansa.pdf



















    システム管理基準 http://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kanri.pdf



















 














  日科技連  http://www.juse.or.jp/






















    SQuBOK 第一版 ベータ  http://www.juse.or.jp/software/pdf/squbok-beta.pdf






















 










 










【セキュリティ】
















  経済産業省














    情報セキュリティに関する政策 緊急情報 http://www.meti.go.jp/policy/netsecurity/











 








    情報セキュリティ監査基準 http://www.meti.go.jp/policy/netsecurity/downloadfiles/IS_Audit_Annex04.pdf



















    情報セキュリティ管理基準 http://www.meti.go.jp/policy/netsecurity/downloadfiles/IS_Audit_Annex01.pdf











 






  独立行政法人 情報処理推進機構(IPA) http://www.ipa.go.jp


/






    情報セキュリティ http://www.ipa.go.jp/security/index.html




    緊急対策情報・注意喚起 一覧 http://www.ipa.go.jp/security/announce/alert.html






 


今年は特に「品質」に関して実践を行っていきたい。いろいろな分野にまたがるとは思うが、テーマを「システム監査」としておく。

私自身がIT産業に従事した当初からの関心事のひとつが「品質」の問題である。どこまで行えば品質を保証したことになるのか。顧客にとっては「原因は何であれ正常に動くこと」が求められる。そうなると「作ったソフトウェア、計算機自体、OS、コンパイラなど、すべて品質保証されていなければ、顧客にとって品質保証をしたとは言えないのでは」と当時は考えていた。

そう考えたり、その考えを強めた背景にはいくつかの知識や経験がある。

 ・コンピュータが計算ミスをしないのであれば、デュアル(Dual)というシステム構成(二台の計算機に同じ処理をさせ結果を照合させることで信頼性を高める方法)は考えられなかったろう、という推測
 ・無線機器など、機械側によって誤動作を起こしたことがある経験
 ・電波により他の機器のケーブルや他の周波数帯の電波に影響がでるという知識と経験
 ・昔のOSは処理がコケた場合にそれをリカバーするためのプロセスも走らせていたという知識
  ※何の本だか忘れたが、記憶にある文体からすると、祝一平氏 の「試験に出るX1」日本ソフトバンク(1987当時)に書いてあったように思う。
 ・初期の頃のPentiumチップの計算ミス問題
 ・リソースの残量によって動作ミスが起こる場合があるという経験

などである。

上記はソフトウェア自体ではないが、システムを運用しサービスを提供する立場としてならば考慮が必要なことでもあるものの、横道に逸れた感がある。


このブログでは、品質に関する一般論を「システム監査」のカテゴリに、VBAで注意を払うべきことを「考慮点(運用・保守)」のテーマで書いていく所存です。
各プロセスには

・インプット
・ツールと技法
・アウトプット

の3つがある。そのプロセスが

・どういう情報を受け取り
・どういう事をして
・どういう情報を出すか

によって「どういうドキュメントがどこで発生してどこで変更されるか」を、他のプロセスとの関連として追いかけることができる。

各プロセスの関連を理解するのには役立つだろう。