１．受ける試験区分の論文になっているか確認する
これができていないと、どんな名文を書いてもだめである。例えば、システム管理の論文なのに開発者の視点で書いてしまう、システム監査の論文なのに監査基準に反する内容を書いてしまう、などというのは論外だ。そんなこと当たり前と思っていても、自分の書いた準備論文をもう一度よく読むと、意外な穴があるかもしれない。自分の立場を再認識すること。
２．論述する項目を体系的に整理しておく
特にむずかしいことを言っているのではなく、論点を箇条書きにでもしてみよう、という意味である。用意する項目数が多いに越したことはないが、個々のトピックについて十分な説明ができれば、数はさほど気にする必要はない。箇条書きにすると全体が見えるので、試験当日に見るメモとしても有効に使えるだろう。
３．テンプレートの記述内容を確認する
試験のときは、問題を解く前に、論述の対象となるシステムやプロジェクトの概要について15項目ほどの質問に答えることになっている。テンプレートと呼ばれるもので、市販の過去問題集などに見本が掲載されているはずだ。これは、きちんと書かなければいけない。すばやく記入できるように準備しておき、論文との矛盾がないようにチェックすること。
４．再度、過去の問題に目を通しておく
論文試験というのは、どうしても書くほうばかり気になってしまうが、じつは読むほうも大切である。題意を正確に読み取らないと、望ましい解答が書けないからである。試験直前には、過去の午後２問題をいくつか選んで読み、実戦イメージをつかんでおくこと。
５．自分の解答ペース＝時間配分を確認する
対策本などには、標準的な時間配分について記載されていたりする。それはそれで参考にはなるが、結局は自分で決めるべきだろう。ちなみに私の場合、以下のような配分を事前に決め、本番でもこのペースをほぼ守っている。
読解及び設計 14:10〜14:25（15分）
設問アの記述 14:25〜14:50（25分）
設問イの記述 14:50〜15:50（60分）※監査のみ14:50〜15:35（45分）
設問ウの記述 15:50〜16:10（20分）※監査のみ15:35〜16:10（35分）
本当は論文設計にもっと時間をかけるべきかもしれないが、実際に書くための時間がたくさん欲しいので、さっさと書き始める場合が多い。また、最後の見直しは今までやったことがない。やりたくても時間がなくてできないのだが、仮にまずい所があったとしても手書きの修正は難しいので、見直しは行わないことにしている。
次回へつづく。
