はじめに
本エントリは、情報処理技術者試験の「システム監査」の論文答案の書き方をまとめたものです。
H22春のAU試験に合格したときに僕が実践した午後2の論文答案の書き方をまとめてみました。
※その他の情報処理関連のエントリは[情報処理]タグからどうぞ
サマリー
基本的な論文作成のお作法は他の論文系試験と同じで、「答案構成を作って、構成通りの答案を作る！」というやり方です。
答案構成というのはシナリオとか下書きとかいうイメージで、法律系の試験勉強で習った答案作成法を応用したものです。（プログラムを書くための基本設計みたいなものです）
論文作成作業項目をもう少しブレイクダウンすると、
- 設問から採点基準を漏らさず抽出する。
- 採点基準に沿って、問題文から論点を構成する。
- 論点をつなげて答案構成を作成する。
- 答案構成通りに論文答案を作成する。
となります。論点と言うのは配点ポイントのことで、要は「問いに対する答え」です。
この論点を積み上げて答案を作成します。詳細は後述します。
準備
まず準備として過去問題集を買います。
この本の解説にある「論文設計テンプレート」というのは「答案構成」とほぼ同じなので、上記の解き方を実践して答え合わせするのにぴったりです。
過去問解説だけでなく、勉強法、試験対策全般を網羅した良書です。
システム監査技術者試験の特徴
システム監査試験は他の論文試験とだいぶ毛色が違うのですが、特にこの区分の特徴として考えられるのが、以下の２つの考え方です。
- (1) コントロール
- (2) システム監査基準とシステム管理基準
上記の２つとも、論文問題を解く上であらかじめ身につけておくべき考え方になりますが、これについて詳しく説明します。
(1) コントロール
(1)のコントロールというのは、要は「正しく行われていることを検証するための仕組み」です。問題集の言葉を引用すると以下のような言い方になります
会社の目的に沿って企業内の活動が行われていること、組織のルールに従って企業内の活動が行われていること、社会の規制に従って企業内の活動が行われるようにすることがコントロールである。そして、監査とはこのコントロールが有効に機能しているかをチェックすることだと言える。（１０年版情報処理教科書４１ページ）
これシステム監査独特の概念で、この考え方に沿って考えるというのが、よく言う「監査人の立場に立って考える」ということかと思います。
システム屋さんにとって理解しやすい例を挙げるとすると、例えばテストやる時って、テストそれ自体とは別に、テストの網羅性とかエビデンスとかバグの数とかレビューとか、テストそのものの結果以外のテストのメタデータを作ったり使ったりします。
あれが「テストが正しく行われていることを検証する仕組み」になります。
このメタデータをどう定義するのかっていうのが「コントロール」で、そのコントロールをチェックするお仕事が「監査」って感じです。
(2) システム監査基準とシステム管理基準
(2)のシステム監査基準とシステム管理基準というのは、そのコントロールと監査のマニュアルですね。
このマニュアルの考え方を腹に落としておかないと、論文に何書いていいかポカーンとなってしまうので、最終的にはこの基準を「使える」状態にしておく必要があります。
お勉強の仕方
ただ、この２つの考え方は、いきなり理解しようとしてもチンプンカンプンなので、午後１の問題を通じて考え方のポイントを身につけていくのが王道です。
これから勉強始めようって人は、何を置いてもまず最新の過去問（午前、午後）を全部解いてみることです。最初は問題解けないですが、問題解いてゴールを確認しないと、どっちに向かって進めばいいかも判らないので。
例題
実際の本試験の午後2では、3問の中から1問選んで解答するのですが、選択すべき問題は「書けるネタをたくさん持ってそうなもの」を選びます。
ネタさえ持っていれば実際に経験してなくてもいいですが、大抵「具体的に」と言われるので、経験したシステムの方が具体的なネタを書きやすいというのは言わずもがなです。
今回は、私が前回本試験で解いたH22 - AU - 午後2 - 問1を例に説明してみたいと思います。
以下、問題文全文。
問1 情報システム又は組込みシステムに対するシステムテストの監査について
ITの進展に伴い、情報システムの役割はますます大きくなり、影響範囲も広がっている。例えば、生産システム、受発注システムなどの基幹系情報システムに不具合があると、自組織だけでなく、取引先などの業務にも影響が及ぶおそれがある。
また、産業機器、家電製品などは、機器や製品を制御するための組込みシステムが搭載されており、高機能化している。このような状況で、例えば、自動車やエレベータなどの機器の組込みシステムに不具合が発生すると、社会生活に影響が及ぶだけでなく、人命を脅かすような深刻な事態を招くおそれがある。
したがって、情報システム又は組込みシステムの稼働前に、システムが要件どおりに機能するか十分に検証し、品質や性能を確保しなければならない。特に、稼働時、利用時の様々な状況を想定し、不具合を事前に見つけ出すテスト工程（以下、システムテストという）は、システムの安全性を確保する上で重要な位置付けとなる
システム監査人は、このような点を踏まえて、情報システム又は組込みシステムについてシステムテストが適切に行われ、品質や性能が確保されていることを確かめなければならない。また、既に稼働している情報システム又は組込みシステムについても、十分な品質や性能が確保されていることを確かめるために、開発段階で実施したシステムテストの内容をさかのぼって確認する場合もある。
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
- 設問ア あなたが関係した情報システム又は組込みシステムの概要と、そのシステムの不具合が業務・社会に及ぼす影響について、800字以内で述べよ。
- 設問イ 設問アで述べた情報システム又は組込みシステムに対するシステムテストの内容について、700字以上1,400字以内で具体的に述べよ。
- 設問ウ 設問イで述べたシステムテストの適切性を確かめるために必要な監査手続について、700字以上1,400字以内で具体的に述べよ。
問題は、大きく、タイトル、問題文、設問の３つから構成されています。
タイトルは「情報システム又は組込みシステムに対するシステムテストの監査について」という部分で、問題文はその下から設問の手前までの文章、設問は設問ア〜ウに書いてある文章のことです。
説明の便宜上こう分けます。
１．設問から採点基準を漏らさず抽出する。
設問から採点基準を漏らさず抽出します。
これは設問に線を引いて、どこでどんなネタを使うかを考えます。
そして、解答の目次の大枠も決めますが、そんなにスッキリとは行かないので"およそ"で。
設問の流れから解答の目次を再構成すると、採点者にも採点しやすい構成になるので、なるべく設問のままで。
設問ア
- (1) あなたが関係した情報システム又は組込みシステムの概要が書かれている
- (2) そのシステムの不具合が業務・社会に及ぼす影響について書かれている
- (3) 上記の内容が800字以内で書かれている
設問イ
- (1) 設問アで述べた情報システム又は組込みシステムのシステムテストの内容が書かれている
- (2) 上記の内容が具体的に書かれている
- (3) 上記の内容が700字以上1,400字以内で書かれている
設問ウ
- (1) 設問イで述べたシステムテストの適切性を確かめるために必要な監査手続が書かれている
- (2) 上記の内容が具体的に書かれている
- (3) 上記の内容が700字以上1,400字以内で書かれている
これが採点基準の大枠です。（もちろんほんとの採点基準なんて知らないので、私の予想です。）
２．採点基準に沿って、問題文から論点を構成する。
前項で抽出した採点基準に則した論点を問題文から構成します。
論点というのは、採点基準を充たす問題提起、理由と結論、起承転結などで構成される配点ポイントのことです。
端的に言うと「問いに対する答え」です。必要な論点を書き忘れる＝論点落ちすると配点されないと考えられますが、だからといって書きすぎて時間がなくなったり、記述が設問の要求するレベルに達してない場合（たとえば具体的じゃない、とか）も配点されないので、注意が必要です。
設問ア
(1) 情報システムの概要
情報システム（又は組込みシステム）の概要を書きます。
まず会社におけるシステムの役割、用途を書きます。
私の場合、ERPパッケージを使った基幹系の人事システムで、社内の給与システムであること、社内の他システムとも連携していること、外部ＳＩを使って開発・運用・保守を行っていること、社内のシステム監査の対象になったことなどを書きました。
最後に「私は社内のシステムテストの監査の担当者として監査業務に参画した」と書きました。
この「情報システムとどう関係したか」というのは具体的な業務内容が思い浮かぶものに設定します。
また情報システムの概要については、事前にある程度使い回しの効くテンプレートを用意しておきましょう。
(2) システムの不具合が業務・社会に及ぼす影響
情報システムの導入の目的について書きます。
私の場合、このシステムは会社の給与計算に使うので、システムに不具合があったら、人事部だけの問題ではなく会社の存続に関わるみたいなことを大げさに（ｗ 書きました。
設問イ
(1) システムテストの概要
問題文には「システムテストの内容」としか書かれていないため、まずシステムテストの概要という節を設けました。
そして、問題文から、システムテストの内容を次の３つにブレイクダウンしたということを書いて、それぞれのテストの目的をざっと（ほぼ問題文コピペ）で書きました。
- 「システムが要件通りに機能するか十分に検証」
- →総合テスト。
- 「稼働時、利用時の様々な状況を想定」
- →ユーザ受入れテスト。
- 「既に稼働している情報システム又は組込みシステムについても、十分な品質や性能が確保されていることを確かめる」
- →既存システム部分のテスト。
設問ウに繋げないといけないので、これらのシステムテストの適切性を確かめるための監査手続を思い浮かべながら、テストの内容を定義する必要があります。逆に言えば監査手続が思い浮かばないテストについて書いてはいけません。
ところで、システム管理基準によるとシステムテストとユーザー受入れテストって別なんですが、これについては後述します。
(2) 総合テスト
総合テストの具体的な内容を書きます。
問題文で求められているのは「システムが要件どおりに機能するか十分に検証し、品質や性能を確保しなければならない」ということです。
これをベースに、具体的なネタを論点として展開します。
- 「システムが要件通りに機能するか十分に検証し」
- →要件定義書を基準にテスト仕様書を作成して、要件通りに機能するか検証する。
- 「品質（を確保）」
- →品質要件として、総合テスト時のバグが要件定義書に定義された数値以下であること。
- 「性能（を確保）」
- →性能要件として、バッチが要件定義書に定義された時間内に終わること。
(3) ユーザ受入れテスト
ユーザ受入れテストの具体的な内容を書きます。
問題文で求められているのは「稼働時、利用時の様々な状況を想定し、不具合を事前に見つけ出す」ということです。
これをベースに、具体的なネタを論点として展開します。
- 「稼働時、利用時の様々な状況を想定」
- →業務マニュアルをベースに受入れテスト仕様書を作成して、様々な状況を想定し、不具合を事前に見つけ出す。例えば、給与計算業務が業務マニュアルで想定している業務時間・期間内に遂行できること。
(4) 既存システム部分のテスト
既存システム部分のテストの具体的な内容を書きます。
問題文で求められているのは「既に稼働している情報システム又は組込みシステムについても、十分な品質や性能が確保されていることを確かめるために、開発段階で実施したシステムテストの内容をさかのぼって確認する」ということです。
これをベースに、具体的なネタを論点として展開します。
- 「既に稼働している情報システム」
- →外部連携している会計システム。
- 「十分な品質や性能が確保されていることを確かめる」
- →外部設計書ベースにテスト仕様書を作成して、十分な品質や性能が確保されていることを確かめる。
- 「開発段階で実施したシステムテストの内容をさかのぼって確認する」
- →会計システムについてはこちらではよく判らないので、外部ＳＩの力を借りて検証する。
設問ウ
設問イで上げた３つのテストの適切性を確かめるために必要な監査手続について記述します。
監査手続の詳細化、具体化について問題集から引用すると、
どのようなコントロールが存在するかを明確にした後、そのコントロールの妥当性をチェックするために、どのような監査手続が必要になるかを検討し、詳細化、具体化して、監査手続書に記述しておく。（１０年版情報処理教科書１１０ページ「監査手続きの詳細化、具体化」より）
となります。従って、この考え方をベースに以下の２つを論点として記述します。
なお、こんな細かい論点を暗記するとか無理なので、さきほど書いた「コントロールの意義」と「システム監査基準・管理基準」を腹に落としておいて「どうやったらシステムテストの適切性を確かめられるか」という視点で考えられれば、大きく外すことはないはずです。
(1) コントロールの存在
システムテストの適切性を確かめるためのコントロールについて記述します。
上記のテストは、要件定義書や設計書と言ったドキュメントベースにテスト仕様書を作っていますので、その元となるドキュメントとテスト仕様書を比較してレビューしてもらうことで、システムテストの適切性を確かめられます。
また、ただレビューするだけでなく、レビュー記録を取り、それを監査時に参照することでシステムテストの適切性を確かめられますし、レビュー記録だけを参照しては本当にそのレビューが行われたかどうか確認できないので、実際にレビューに参加した人にインタビューを実施して「ウラ」を取ることで、より確実にシステムテストの適切性を確かめられます。
なんてことを書きます。
(2) コントロールの妥当性のチェック
コントロールの妥当性のチェックについて記述します。
（１）であげたコントロールの妥当性、すなわちどうやったらそのコントロールが正しいかチェックできるかについて考えますが、私の場合、テスト仕様書の妥当性のチェックについてだけ記述しました。
余力があったら他の妥当性チェックについて記述してもいいですが、時間がなかったのと、（１）の例で言うと、テスト仕様書レビューはテスト仕様書の妥当性チェックになりますし、レビュー記録はレビューの妥当性チェックになるということもあるので、思い切って省略しました。
テスト仕様書の妥当性ということで、必要なテストが漏れてないか？（完全網羅性）、ヘンテコなテストじゃないか？（内容の妥当性）、というところをチェックできれば、テスト仕様書は妥当と言えるのではないかと考え（もちろん他にもありますが^^;）、この２つを論点として展開しました。
- 完全網羅性
- →テスト仕様書レビューで、要件定義書を用いて、テスト項目の完全網羅性を確認する
- 内容の妥当性
- →テスト仕様書レビューで、業務マニュアルを用いて、テスト内容の妥当性を検討する
完全網羅性については総合テストを、内容の妥当性についてはユーザ受入れテストを想定して書きました。
最後に「システムテストの適切性を確かめるために、以上の監査手続を実施した」と書けばＯＫでしょう^^;
と、ここまでに次の答案構成でやる内容をほとんど書いちゃってますが、実際に論点抽出でやるのは、問題文に線を引いたり、対策とかを頭で考えてメモする程度です。
本試験で私が実際にやった論点抽出という線引き・メモ作業はこんな感じでした。見にくいですが。（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
設問ア〜ウまでざっと見て、問題文から論点の抽出漏れがないか確認します。なければ答案構成の作成です
３．論点をつなげて答案構成を作成する。
論点抽出時のメモ書きを「答案構成」という形で問題用紙の[メモ用紙]というページにきっちり書き起こすというのが、この「答案構成の作成」というプロセスです。
大事なのは、全体を見て分量を調整したり、流れを阻害する要素がないかを考えて論点を取捨選択することです。
要は論点抽出のまとめですが、こんな感じに箇条書きに起こします。これがそのまま論文答案の答案構成になります。
ア．(1) 情報システムの概要
(2) システムの不具合が業務・社会に及ぼす影響
- このシステムは会社の給与計算に使う
- システムに不具合があったら、人事部だけの問題ではなく会社の存続に関わる
イ．(1) システムテストの概要
- 総合テスト
- ユーザ受入れテスト
- 既存システム部分のテスト
(2) 総合テスト
- 要件定義書を基準にテスト仕様書を作成して、要件通りに機能するか検証する
- 品質要件として、総合テスト時のバグが要件定義書に定義された数値以下であること。
- 性能要件として、バッチが要件定義書に定義された時間内に終わること。
(3) ユーザ受入れテスト
- 業務マニュアルをベースに受入れテスト仕様書を作成して、様々な状況を想定し、不具合を事前に見つけ出す。例えば、給与計算業務が業務マニュアルで想定している業務時間・期間ないに遂行できること。
(4) 既存システム部分のテスト
- 外部連携している会計システム。
- 外部設計書ベースにテスト仕様書を作成して、十分な品質や性能が確保されていることを確かめる。
- 会計システムについてはこちらではよく判らないので、外部ＳＩの力を借りて検証する。
ウ．(1) コントロールの存在
- テスト仕様書
- テスト仕様書レビュー
- レビュー記録を参照すること
- レビュー参加者へのインタビューの実施
ここまで細かく書くとたぶん時間がなくなるので、実際は自分で判るキーワードを箇条書きする程度で十分かと思います。
本試験で実際に私が作った答案構成はこんな感じでした。見にくい上に字も汚いですが。（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
４. 答案構成通りに論文答案を作成する。
答案構成が完成したら８割完成です。
時間的には逆で、ここまでで40分、残りの80分で答案構成の通りに答案を書ききります。
この時間配分については、本試験開始直後に、答案構成の隅に時間配分を書いてました。
| 14:30-14:40 | 問題読む |
| 14:40-15:10 | 答案構成 |
| 15:10-15:30 | ア |
| 15:30-15:55 | イ |
| 15:55-16:20 | ウ |
| 16:20-16:30 | 予備 |
これを書いておくのは途中で「時間がない！」ということになった場合に論点切りをしてでもウにたどり着けるようにするためです。
書いてる途中でタイムアップするとか、最低字数を満たせないというのが最悪のパターンなので、それを回避するために時計をチェックしながら、ひたすら書き続けます。
なお、答案作成中にあれ？この論点落としてね？というのに気づいても、極力止まらずに書ききります。別のネタを思いついたり、なんか微妙に書き間違っていても、書いてる途中に答案構成を変更するのは危険です。
そのレベルの変更をするなら、答案構成時にきちんとやっておくことです。
ここまで来たら、何も考えずに機械のように書ききることが大事です。
書き終わったら
最後まで書ききったら、受験番号とか選択した問題に○を付けてるか確認して、時間のある限り誤字脱字とかをチェックします。
ここまで来たらもう汚い字を書き直すぐらいで、答案構成を変更するようなことは無理なので諦めます。
この答案構成例について
なお、この答案構成例は優秀答案でもなんでもなく、私が前回の本試験時に作った答案構成を再現したものです。
おかしいところや甘いところ、記憶違いなところもありますが、「本試験の時間だとこれぐらいのことしか書けないのか」、「っていうかこの程度の解答でA評価なのか。。。！？」という感じで参考程度に見ていただければと思います。
問題集の答案例とか答案集の優秀答案って「こんな量、2時間で書けねーよ！」ってのも多いので。。。
普段の午後2の練習
普段、午後2の問題を練習で解くときは、答案構成のみ作って論点漏れしてないか確認する程度で十分かと思います。
ただし、最低一回は答案を最後まで作成して書く練習をしないと、時間配分ができません。
2時間で3,000文字近く書く感覚を掴んでおく必要があります。
できれば勉強の一番最初にやっといて、あとは問題の量をこなすようにすると、2時間で書ける量しか答案構成しないように訓練できるので効率的です。
午前と午後1は？
なお、午前と午後1については、問題集を買ってたくさん解けば十分だと思います。
午前は、高度午前を網羅した情報処理教科書 高度試験午前I・IIがオヌヌメ。
あと、本試験で午前や午後1がメタメタだった時も、午後2を無料模試と考えて受けましょう。これ一回やると、2時間の短さが本番さながら（っていうか本番w）で経験できるのでオヌヌメです。
採点基準について
採点基準については予想するしかないですが、それを考えるヒントになるのが試験後に公表される採点講評です。例えば、H22春の上記問題についてIPAの採点講評.PDFから分析すると、
高度化・多様化する情報技術に対応できるシステム監査人を育成するという観点に基づいて，情報技術について広く深い理解を求めるテーマを出題した。そのため，各テーマについての実務経験を有していない受験者にとっては，難しい問題になったと思われる。
情報システムの問題であれば、監査の実務経験がなくても大丈夫…なはず。
すべての問において，論述内容が一般的で具体的な記述まで至っていないものが多かった。（太字は筆者の加筆。以下同じ）
この「具体的」というのは、監査試験に限らず、どの区分でも同じですね。「例えば○○」の○○という部分を書くようにすると、自然と具体的になります。
問1（情報システム又は組込みシステムに対するシステムテストの監査について）は，システム開発段階の基本的なテーマであることから，選択率が最も高かった。情報システムを対象にした論述が多かったが，組込みシステムを対象にした論述も見受けられた。設問イ，ウは，単体テスト，結合テストなどを含めたテスト工程全体や，テストの実施手順についてなど，システムテストの位置づけや具体的な内容を理解できていない論述が目立った。
私の場合、ユーザ受入れテストはシステムテストに含まれるというストーリーで書きました。
システム管理基準ではこの２つのテストは別個のものなので、システム管理基準ベースで厳密に採点をするとペケになるはずなんですが、結果はＡ評価でした。
これは、おそらくテストの呼び方は色々あってもいいけど定義付けをしっかりしろということではないでしょうか。
上記の答案構成ではまずシステムテストの位置づけを明確にしたため、採点基準はクリアしたのかなというのが私なりの分析結果です。
また，設問ウでは監査の実施手順や，監査ポイントだけで，監査証拠について触れていない論述が散見された。
これは問題文には直接書かれてませんが、監査手続を具体的に書くと必然的に監査証拠についても書かざるを得ません。
なのでこの場合は「具体的に」という指示を守って論述するしかないですね。
どこまで書いたら具体的なのか、というのはもう具体的すぎるぐらい書くように普段から練習すること。
あとは問題集の答案例とか読んで「ここまで書くと具体的なのか」という感覚を身につけておくようにしましょー。
