ソフトウェア開発技術者は基本情報技術者の次に位置します。
多くのシステムエンジニアが取得を目指す資格です。

基本情報技術者より難しい問題が出ます。
午前試験の出題範囲は基本情報技術者から
「情報化と経営」を除いた部分です。すべて難易度があがります。
それと、午後試験が午後Ⅰと午後Ⅱになります。

一般論で言えばソフトウェア開発技術者は、
アプリケーションエンジニアやテクニカルエンジニア（DBやNW)の
指示を受けて小さな開発に責任を持つ人です。

その上位であるアプリケーションエンジニア試験は、
サブシステムをまるっと担当することができるような難易度に設定されています。
それを反映して論文試験でも、

• 「システム開発の経験で達成困難な仕様はなんでしたか？」
• 「あなたはどんな工夫でそれを乗り越えましたか？」
• 「その結果はうまくいきましたか？」

というような部分が問われます。

一方、ソフトウェア開発技術者試験には論文試験がありませんし、
短答の論述問題でも高い設計力を問うような問題は出題されません。
その代わりに出題範囲が広く、問題の量もたくさん出ます。
分野が広くてもネットワークやデータベースなどの基礎的な部分に
大きな弱点を抱えたままでは合格は難しいでしょう。

アプリケーションエンジニアとソフトウェア開発技術者の線引きはなんでしょうか。
アプリケーションエンジニアはお客様の思いを設計に落とします。
それをソフトウェア開発技術者が更に細かい設計を行ったうえで実装を担当する、
というような関係になります。
これがソフトウェア開発技術者の想定する技術者像です。

基本情報技術者はそのアプリケーションエンジニアや
ソフトウェア開発技術者の指導監督の下で開発に参画します。
ソフトウェア開発技術者を経て（経ない場合もありますが）
TEネットワーク・TEデータベース・アプリケーションエンジニア・
プロジェクトマネージャ・システムアナリストなどへ飛躍していきます。

最近、ソフトウェア開発技術者試験は春・秋の両方で受けられるようになりました。
それまでは春しか受けられない試験でした。
試験範囲が広く、ボリューム感のある試験ですので
一度落ちたときのダメージはかなり大きなものがあります。
私の友人の何人かはソフ開で参ってしまい、
なかなか取得できないままになってしまっています。

それとは反対に、ソフトウェア開発技術者に合格すると
なんと2年間はアプリケーションエンジニア、プロジェクトマネージャ、
システムアナリストの午前試験が免除になります。

また、これらの3試験に合格した翌年（1年後の1回だけ）も
同じくAE,PM,ANの午前試験が免除になります。

この春試験でソフトウェア開発技術者に合格すると、
そのまま午前免除を活かしてアプリケーションエンジニアに合格し、
翌年そのまま午前免除を活かしてプロジェクトマネージャに合格し、
翌年そのまま午前免除を活かしてシステムアナリストに合格することも可能です。

そうすると

• 大学最終学年（春）　→　就職先内定
• 大学最終学年（秋）　→　基本情報取得
• 就職1年目（春）　→　ソフトウェア開発技術者
• 就職1年目（秋）　→　アプリケーションエンジニア
• 就職2年目（春）　→　テクニカルエンジニア（セキュリティ）
• 就職2年目（秋）　→　プロジェクトマネージャ
• 就職3年目（春）　→　システム監査技術者
• 就職3年目（秋）　→　システムアナリスト
• 就職4年目（春）　→　テクニカルエンジニア（データベース）
• 就職4年目（秋）　→　テクニカルエンジニア（ネットワーク）
• その他いろいろ

という資格取得計画を実行することができます。
各資格間には取得順序や年齢制限が一切ありませんので
いきなり最高位のシステムアナリストとシステム監査から攻めることも可能です。
合格発表後の統計情報には、現在の仕事：学生、で
それら最高位クラスを取得しておられる方もおられます……。

私は残念ながら初回のアプリケーションエンジニア試験は不合格でした。
入社1年目の9月末までは新人研修でしたので、
業務経験がほとんど無い状態の受験でした。
日経コンピュータなどから構築事例を仕入れるなどの努力はしましたが
無念にも論文でB 判定でした。

しかし私はここでやる気を失いませんでした。むしろ、
今年でB判定が出たなら来年はいけるはず。と思ってまた勉強し直しました。

次の年にはAE試験に合格し、翌年のプロジェクトマネージャには
同年度の合格者の中で最年少の合格者となりました。
その翌年のシステムアナリスト試験でも、
同年度の合格者の中で最年少の合格者となりました。

アプリケーションエンジニア試験の意義を理解した上で業務を覚えていく事は
自分にとって大変なプラスになったと思っています。
経験が伴わない段階から「品質は上流工程で作りこむ」ということの大切さに
意識を払うことができたのは、大きなメリットだったと思います。

それでも
　「実務を伴わないで資格ばっかり取って何になるの？」
　「そもそもそんな奴が受かっちゃう資格なんて意味あるの？」
などと言われてしまうと、経験値の少ない私には返す言葉も無いのです。
（まだルーラも覚えてないので逃げ出すこともできません）

それでもいつか「やっぱり資格がある人はすごいね。安心だね。」
と言ってもらえるよう、明日もがんばります。

この春にシステム監査技術者試験を受験します。

私の担当している業務からすると、
まったく関連がないということはありません。
それどころか、システム開発に携わるものでシステム監査が
関係ない、ということはそうそうないと思われます。あくまで受ける側として、ですが。

システム監査というと、監査人がやってきて箸の上げ下げまで文句を言う、
というイメージを抱かれる方もおられると思います。
しかしよくよく勉強してみると、すこし違うことがわかってくるんですよ。

システム監査というのは、ひと言で言うとルールの遵守状況の確認です。
何も、机の上が汚いとか、ネクタイが緩んでいるとか、
そういう注意をするものではありません。
ましてや、フロアレイアウトが悪いから動線が長いじゃないか、とか、
おまえたちは日本語をもっと勉強すべきだとか、
そういうレベルの指摘というのは原則ありません。

ではどのような指摘が「システム監査」なのでしょうか。

日本の警察は規則で動きます。人相が悪いからといって無罪の人を突然逮捕しないように、
システム監査にも守るべき規則というのがあります。
監査人の胸先三寸で「お前その目つきは何だ。監査結果悪くしてやる。」とはなりません。

企業にはルールがあります。最近ですと日本版SOX法（J-SOX法）関連の
話題が盛り上がっていますね。あの法律は、会計のルールを厳しく定めたものです。
経理処理と異なり、システム自体にはさほど厳しいルールがありません。
建築物でも大きなものは耐震強度などが公式なルールで定められています。
一方、システムはこのように構築すべし、という共通ルールはないのです。
（ISOやらRFCなどは一旦忘れてください）

ので、代わりとなるルールを各社が責任を持ってしっかり作成します。
情報セキュリティガイドラインであったり、ユーザ登録手続き規定集であったりします。

システム監査人が調査するのは

そのようなルールが徹底されているかどうか

のひと言に尽きます。

まずシステム監査では、企業がシステム監査で何を目的とするかを
決定します。その目的を監査目的といいます。
普通ならば企業が抱えるリスクの大きさを考慮した目標がいくつかできます。

では、その目的を達成するためにはどうしたらよいのか。
それを実現するために計画書を作成します。
費用対効果を考えて効率的に監査が進むように計画します。

その段階で、会社が定めたルールを把握します。
ここが大変重要です。そのルールの遵守状況を確認することが監査だからです。

社長「個人情報漏洩なんていうのがあるとまずいからさ、しっかり監査してね」

監査人「いや、セキュリティポリシーすら無いんじゃ『何が悪い行為か』が定義できません。」

なんていう運びは監査ではありません。そんな場合は、
その辺りに明るいエンジニアやコンサルタントを早期に導入すべきでしょう。
（システム監査人がセキュリティ標準などの策定に参画する意味も大きいと思います。
また、上の例でも現実世界では経験豊富で優秀なシステム監査人が過去の経験から
有効な監査手続を洗い出して実力を発揮してくれることもあると思われます）

少し横道にそれましたが、その会社で、システムに関するルールが徹底されているか、
という辺りを監査するのがシステム監査です。

公正な判断のために、システム監査人は色々な利害関係から独立していなくてはいけません。
自分の元上司のところの監査をしたら、無言の圧力で「問題なし」と報告してしまった、
ではまずいのです。自分の会社のサーバをたくさん買ってくれるユーザ企業の監査を
自社でやった場合、甘くならないでしょうか。「このサーバ良くないですね」と言えるでしょうか。
そのような場合は別の監査人を立てるべき、ということになっています。

続きです。社内規約が記載されたドキュメントから、監査したいポイントを探しても
机上の空論になってしまいがちです。そういう場合、現場に入って準備をします。
予備監査と言います。そこで急所を洗い出すなどして、監査手続を完成させます。

監査手続には、チェック項目がずらーっと記載されます。
それに基づいて状況を確認します。もし良くない部分を見つけたら、
その場で証拠を取ります。被監査部署が監査人の目の前でログを削除することはないにしろ、
後日証拠を取得するために監査人が出向いたら跡形も無く・・・となるとまずいです。
oracleデータベースなどには「監査証跡ログ」というものがありますが
（デフォルトOFFだったような気が・・・）
それらは簡単には削除できない仕組みになっています。
ので、監査人はそういうような機能を活用し、

「ちゃんと社員それぞれが自分のアカウント使ってるね」
「SYS権限の利用状況を調べたけど、不要な場合には一切使われていないね」

などを確認します。まずいところがあったら証拠を押さえます。

証拠を持たない監査結果は監査報告書と言えません。
「なんか色々とまずいみたいです。」
じゃまずいわけです。上の例に絡めると

「普通のテーブルを参照するだけなのにSYSでログインした割合が20%」
「社員の6割が1つの特権アカウントを使いまわしている」

という指摘とともに、LOGという証拠を突きつけてこその監査となります。
社長が正式に監査人に監査を依頼したのであれば、
監査人の言うことは社長の言うことですので

「業務秘密につきLOGは出せない」

とは言わせません。（お客様の個人情報保護まで絡むとケースバイケースですが
個人を特定する部分をスクランブルしても証拠性を確保できるLOGもあると思います。
そもそも監査報告書は極めて丁寧な扱いを受けるはずです。その会社の弱点が山盛りですから。）

このようにまとめた監査報告書は経営者向けと、現場向けに作成されます。
現場には「あんたらこのへんまずいんちゃうか」という感じになりますし、
経営者向けにはそれらを包括したレベルの報告書が行きます。

アウトソーシング依頼主が、システム監査人を雇ってアウトソーシング依頼先を
監査するように命じるケースもあります。その場合も双方に報告書が行くのが普通でしょう。

監査報告書には「このへん、ちゃんと改善してよね」という意見が出されます。
「来週までにやれ」的な勢いもあれば、「費用対効果を考えてじっくり結論を出してね」
というテンションのものまでがあります。監査証拠から導き出せることを書きます。
「社員が挨拶もまともにできないし、この調子じゃ近いうちつぶれますな」
などという個人的な恨み言は記載されません。

監査の目的がリスク管理であるならば、特にハイリスクであり、至急対策を要するような
大穴が発見されてしまった場合などは必ず「フォローアップ監査」が行われます。
別に大穴じゃなくてもやったほうがいいのですが、そう毎月毎週監査ばっかりやっていられませんので
重要度に応じてフォローアップを1ヵ月後にやったり、来年の監査で重点項目にすればいいやで済ませたり、
と言うような具合に監査は終わります。終わりが続きでもあるのです。
美しいPlan-Do-Seeになります。

実際には、システム構築前に試算したパフォーマンスが予想値どおり発揮されているか、
というような監査などのバリエーションもあり、とても1エントリで語りきれるものではありません。

私は「やる側の」システム監査なんてこれっぽっちも経験が無いです。
以上は教科書から理解できた事を綴ってみました。長くなってすみません。
今週末の試験はこれで戦います。

間違いは発見次第修正していくつもりですが、上記理由により
このエントリにも間違いがいくつもある事かと思います。その点はお含み置きください。