システム監査 受験

情報処理試験を、またもやぎりぎりで申し込んだ。今回はシステム監査。

正直なところ、改善活動などを通じて考え方自体は身についていると思う。まともな学習はしていないので過去問題を解くと「知識で応える部分」はダメだが、経験で回答できるところは概ねよい。問題の選択を誤らなければ午後１は突破可能だろう。今後は知識も強化して確実に得点を重ねられるようにする必要があるだろうと思う。

問題は午後２である。システム監査の論文は開発者、マネージャー、アーキテクトのような立場では駄目で、ちゃんと監査の視点でないといけない。それも独りよがりなモノではいけない。
監査の論文は個人ごとに当たり外れかなりあるらしく、テーマが合えば書けるが、そうでなければかなり苦しいらしい。システムアーキテクトのように「適当なアレンジ」が効くようなものではないらしい。
ただ、監査系の資格、例えば公認会計士やISMS審査員の視覚保持者に言わせれば、結構楽勝らしい。要するにその観点を身につけさえすればそれほど難しくない、とも言えるのだろう。

年中仕事が忙しいので勉強もままならないが、IPAの過去問とその回答を使うと結構効率的な気がする。とりあえずはがんばってみる。

3W1H ピクト図解

たまたま、ビジネスモデルを見える化（関係ないが、個人的には「見える化」という表現は嫌い）するための技法の紹介があった。ピクト図解＆3W1Hというものだ。
従来あるものより、「儲ける」という点をしっかりと表現できるように思う。
http://3w1h.jp/3w1h


使い勝手を試してみるにあたり、今やろうとしていることをこれでチェックしてみるようかと思う。

復旧モデル

データベースといえばデータ命である。DBMSによって若干異なるが、データを保全する仕組みがあることが多い。

SQL Server ではその保全レベルに応じ、トランザクションログの扱いが異なる３種類の復旧モデルがある。この復旧モデルは、テーブル単位ではなくデータベース単位で設定する。

・単純復旧モデル
トランザクションログは確保されない、と考えて頂いてよいだろう。
用途としては読み取り専用のデータベース。更新が行われるデータベースではこれであればいいだろう。

・完全復旧モデル
トランザクションログファイルにトランザクションとデータの更新履歴を書き込む、真面目な方法である。
一般的に更新が行われるデータベースはこれを用いている。

・一括ログ復旧モデル
通常は完全復旧モデルとそう変わらない。異なるのは一括処理のときのトランザクションログの記録方法で、この復旧モデルの場合では簡単なログしか取得しない。
通常は完全復旧モデルとしているデータベースに、膨大なデータを一括で書き込むときに切り替えて使うのが一般的らしい。一括処理の時のパフォーマンスの向上とログの肥大化を防ぐためのモデルと言える。


これから読み取れることは、読み取り専用データベースは更新の入るデータベースとは分離した方がバックアップの効率という面ではよい、といえるだろう。