情報処理技術者試験の論文対策

毎年4月と10月の2回行われる情報処理技術者試験、IT分野の国家試験ということで業界では有名ですが、秋の試験まで残り2カ月を切ってそろそろ準備を始めようかなと思っておられる方も多いのではないでしょうか。特に論文試験のある区分を受けてみたいけれどどんな準備をしたら良いか分からないという方に向けて、参考になるか分かりませんが私なりの準備方法をお伝えしたいと思います。

参考書の選び方

論文試験の為に模試や講習を受けて対策する人は一定数いるでしょうが、そんなお金も時間も無いよという場合には対策本を買うことになると思います。どの参考書を買うか決めているという場合を除いて、駅ビルや百貨店に入っているような大型の書店に出かけましょう。選択肢が多ければ自分に合った参考書を見つけやすくなるからです。

参考書にはいくつか種類がありますが、個人的な分類はこんな感じです。
過去問…直近3年くらいの問題を掲載して解説しているものです。
教科書…試験範囲をテーマごとの単元に分けて詳しく解説しています。
問題集…過去問ではなく出題傾向に沿ったオリジナルの問題を掲載しています。
対策本…教科書タイプと過去問タイプの中間です。

時間とお金がたっぷりあってじっくり取り組みたいという場合には教科書タイプと過去問タイプを揃えるのが良いと思います。そもそも情報処理技術者試験をあまり受けておらず試験慣れしていない場合にはまずは過去問タイプで学習することをお奨めします。受験する区分の知識に乏しい場合には教科書タイプを使えば基本的な用語や知識を一通り習得できるでしょう。時間もあんまり無いのでてっとり早くやりたいという時には対策本がお奨めです。

それでもどれを買って良いか迷うとは思いますが、特に論文対策ということで言えば、私は経験上、著者の人数が少ない方を選んでいます。人には考え方のパターン(つまり癖)があり、同じ人が全ての解説を執筆していれば、その著者の思考パターンを身に着けることができます。すると、水戸黄門みたいに、どんな問題が出題されてもその思考パターンで論文を展開することができ、応用が利きます。ところが著者が多いと思考パターンにばらつきがあり、ある問題はある思考パターン、また別の問題は別の思考パターンで解説されているといったことが起こりやすく、試験対策どころか迷いが生じる可能性があります。

他に選ぶ基準としては、しっかりと出題傾向を分析できているものが良いです。あと、部分的に過去問を引用している場合は、昔の問題ばかりではなく最近の問題を積極的に取り上げている方が良いですね。参考書は毎年出版されますが、ちゃんと傾向に追いついて改訂しているかどうかが試されます。

論文の準備方法

参考書の中には、準備論文を書きましょうと奨めているものが結構あるのですが、私はいわゆる本番さながらの準備論文を作りません。何故なら労力の割に実りが少ないと考えるからです。準備論文を作ったからと言ってそのテーマが出題されるとは限りませんし、かといって忙しくてまとまった時間が取れない中で準備論文をいくつも書けないですよね。それよりも論文のネタになりそうなものをきちんと整理しておく方がよっぽど効果的です。ただ、章立て(アウトライン)を作る練習くらいは過去問で一通りやっておいてもよいでしょう。

私が論文対策としてやるのは実績(経歴)の棚卸です。試験区分にはそれぞれ人材像が設定されていますので、過去に関わった案件を該当する人材像の切り口で整理していきます。また出題のテーマも複数ありますので、どんなテーマだったらどの案件が使えるかという基準が変わってきます。ピックアップした案件をさらに掘り下げて、どんな案件なのかという概要を設問の(ア)に書けるレベルで説明できるようにします。実は設問(ア)だけはテーマに左右されにくいので論文として準備しても良いと思います。

未経験の区分でも合格することはできますが、だからといって全く関わったことのない架空の案件をこしらえるのはリアリティに欠けますしお奨めしません。実際に関わった案件の中で、受験区分に該当する役割を担った人がどのような動きをしていたかを想起すれば、自分の経験ではなくてもリアリティのある論文が書けます。この棚卸がしっかり準備できているかいないかで論文がスラスラと書けるかが決まってきます。ここはどんな参考書を使ったとしても関係ない部分ですし、短時間で出来るので忙しい人にもお奨めです。


プログラミングが得意な人、そうでない人

久しぶりにプログラミングの話を書いてみようと思います。プログラミングの割と初歩的な話なのですが、プログラムを作っていく工程には「デバッグ」というものがあります。

要はプログラミング作業のミスによって生じるエラーをバグ(=虫)に見立て、プログラムを修正することによってエラーを解消することをデバッグと表現するのですが、スキルがあるレベルに達するまではこれが非常にきつい。何故かというと修正しても修正してもなかなか自分が思ったとおりに動いてくれず、時間ばかりが過ぎていくということが起こり得るからです。それに加え、プログラムをコンパイルした時や実行した時のエラー表示が、まるで自分を否定されたような気持ちにさせるという側面もあるでしょう。(こんなのは慣れればどうということはありませんが)

そのデバッグ作業なのですが、そのエラーを早く直せる人となかなか直せない人がいます。もちろんその差は知識や経験の差ではあるのですが、具体的にどういうところに現れるのでしょうか。

私がデバッグ作業の進まない人の仕事を見ていて気付いたことがあります。その中の一つが「エラーメッセージを読まない」ということです。つまりコンパイラやインタプリタやミドルウェアが出すエラーメッセージから「エラーを解消するために手掛かりに成り得る情報」を取ろうとしないということです。

その人は「実行したらエラーになった」「直して実行してもまたエラーになった」という程度の情報しか取りませんでした。でも私が見ていたところ、2回目に実行した時にはエラーメッセージが変わっていたのです。そこで「今、エラーメッセージが変わったことに気付きましたか?」と質問したところ「え、そうでした?」というような返事が返ってきました。

もちろん某ミドルウェアのように、非常にわかりにくい不親切なメッセージしか表示されないということもあるでしょう。でも、たとえ分かりにくくても「ある個所を直したらエラーメッセージが変わった」というのはエラーには違いありませんがデバッグを行う上では重要な手がかりです。その上でメッセージの内容を読めば、比較的容易にエラー解消に近づいていくでしょう。

このように、プログラミングのスキルというのは一朝一夕に向上するものではなく、こういった緻密な心配りの積み重ねで伸びていくのかなと思っています。