1度目の受験
1度目の受験は平成17年度の秋試験でした。きっかけは「ソフトウェア開発技術者試験(応用情報技術者)」の合格です。ソフトウェア開発技術者に合格すると、2年間はアプリケーションエンジニアの午前試験が免除されるため、これはチャンスだと思い受験しました。(この画像は午前免除の人の席に置いてある座席表です。)
受験会場に着くと、周りは午前免除の人ばかり・・・(座席表に明記されているのですぐ分かる。)軽く不安な気持ちの中臨んだ試験でしたが、落ちました。
結果は、午後Ⅰが650点、論文の評価は「C」。論文については2400文字程度書けばいいところを3200文字書き、それなりの手応えはあったものの、中身は「少ない経験から無理矢理書いた感」が否めないものでした。結果として、次回は「論文をどう攻略するか」というところにポイントを置けば、必ず合格できると信じ勉強に励みました。
使用したテキスト
アプリケーションエンジニア合格論文集〈2006/2007年版〉 芦屋 広太 (著) リックテレコム
アプリケーションエンジニア合格論文集 芦屋 広太 (著) リックテレコム
ぱっと見、同じ本に見えますがその通り、実は同じ本です。アプリケーションエンジニアの受験を決めてから、ブックオフに走りテキストを集めた際に後者を500円で購入しました。1度目の受験では、このテキストを使って合格するための論文のポイントを学びました。2度目の受験の際に、前者(新しい方)を見つけると内容がバージョンアップしており、濃くなっていたため迷わず購入しました。
新しくなって一番よくなった点は、各論文の前に新たについた「論述の対象とするシステムの対象」の記入例。現場経験の少なかった私にとって、論文で書くプロジェクトの内容・工数・開発費・期間などが例で掲載されていることにより、だいたいのパターンを把握し、本番でも迷わず記述することができました。
この本のほかに論文対策として、アプリケーションエンジニアのテキストや講座などもありますが、この本はぜひ購入することをお勧めします。大きさも単行本サイズのため、電車内でも楽々読むことができます。
論文が苦手だと思っている方は、まず合格レベルにある論文をたくさん読むことから始めてください。(内容については後述します!)
情報処理教科書 アプリケーションエンジニア 2005年度 松田 幹子(著)、松原 敬二(著)、生田 昇(著) 翔泳社
他の情報処理試験でも使用する「教科書シリーズ」。まさに定番ですが、やはり定番と言われるものは見やすいです。表紙には「午後対策」とアピールされていますが、午後Ⅱ(論文)に関しては、このテキストだけでは正直役不足です。午後Ⅰはソフトウェア開発技術者の合格レベルに達していれば、このテキストだけで十分です。どちらかというと合格には必須である「当たり前のこと」しか書いていないため、何回も読んで内容を頭に叩き込んでおきましょう。
午後Ⅰ対策
午後Ⅰの対策は、先述したテキストの読破だけで十分です。特別な業務経験などは必要ないと思います。(ソフトウェア開発技術者に合格していれば、の話ですが・・・)それよりも、当日どのように問題にあたるかがポイントです。
他の情報処理試験でも同様ですが、午後Ⅰは時間との勝負です。それに加えて、アプリケーションエンジニア合格には「国語力」が必要です。その理由としては、解答のほとんどが文中に含まれているからです。つまり、文中からいかに答えとなるポイントを導きだせるかがポイントなのです。
よって、午後Ⅰの問題を読む時には、国語の問題を解く時のように、大事そうな部分に線などを引いて、後で参照しやすくしておくと解きやすくなります。
また、過去の問題を分析すると、ある程度のパターンが見えてきます。100%法則がある訳ではありませんが、ある程度絞って効率よく勉強することもありだと思います。私が勉強する際には、「問題を解くこと」よりも先に「問題を分析すること」をするようにしています。
午後Ⅱ(論文)対策
すばらしい経験や、説得力のある話し方をできる人でも、「論文」というと苦手な人は少なくないようです。この人たちに足りないものをわたしなりに分析すると、「点を取るための文が書けていない」ということにつきます。ですから、先述した合格論文集をきっちり読むことで、自分の経験をどのように原稿用紙上に展開させればよいかそのうち分かってくるはずです。そこまでしなければ「合格論文」は書けません。
また、論文を書き始める前に、自分がどのような人物(立場)で書くのか、しっかりと認識しておく必要があります。経済産業省(2007年現在)から、「情報処理技術者試験とITスキル標準」という資料が公開されており、アプリケーションエンジニアの人物像について、以下のような記述があります。
●アプリケーションエンジニアの想定する受験者のレベル
この試験は、3年の経験のあるものを想定して試験を行なっている。3年の経験があれば通常は2件以上のプロジェクトに従事し、その中にはクロスプラットフォーム・複雑な業務要件等が現れることも避けられないため「想定している受験者」であれば、概ね既にレベル3の「達成度」で定義される経験を持っている。●合格者のレベル
実務に際し、アプリケーションエンジニアの本業はプロジェクト管理ではなく、業務設計なのであるが、実際には優秀なリーダ格のエンジニアがチーム内を指導する。現実にはAE試験の合格者であれば、リーダ格となるのが通常であって、その際、数名から10数名程度までのメンバを従えて指導するとともに、自らも業務設計を行うことが一般的である。このような人がAE試験合格者のイメージである。
これに対し、100人の人を管理する人は、業務システムとしてのフレームワークは自ら設計するとしても、個別の業務設計に関しては、もはや自ら設計を行うことはなくプロジェクトマネージャとしての仕事に専念するのが普通であって、AE試験では、ここまでの人は想定していない。このため、AE試験で問うプロジェクトマネジメントスキルは、あくまで初歩的なものにとどめている。
このように考えると、AE試験の合格者は、数人から10数人程度の人をリードするレベルであり、スキル標準で言えばレベル4が概ね合格レベルのスキルと対応する。このことは、AE試験において合格率が数%であること、AE試験合格者を単独で調達することには供給元のソフトハウス等が容易に応じず、チームを纏める立場としてでないと調達が難しいこと、受験者は自らの役割を「サブリーダ」として論述している例が多いこと、等とも符合する。
説明のために図にしておきました。
この図を見て、自分の想定されている立場は理解できましたか?つまり、プロジェクトのベクトルを決める役割でもなければ、実装の細かいレベルを考える役割でもないのです。そこを勘違いした論文ではいくら内容がリアルかつ充実していても、「的外れ」以外の何者でもありません。 評価としては「C」がいいところでしょう。
また、書く内容に関してはなるべく「一般的」なものにしましょう。「こんな画期的なシステムを開発した」「こんなWebサービスを立ち上げた」「誰も知らないニッチなパッケージを導入した」「フレームワークを工夫して他社ではやっていないことを実現した」など、一般的に言われる「業務アプリ」から外れると、採点者は内容を想像しにくくなります。その結果起きるのが「内容補完の不足」です。
人は文章を読むとき、自分の経験から次の文章を想像したり結果を予測する機能が働きます。その機能と文章の内容がそこそこ合っていると、「読みやすい文」として評価されます。しかし、知らないことが多い文はどうしても読みにくく感じてしまう傾向があります。
そこで、文を書く対象のシステムはなるべく一般的な案件を選択し、その中で「どのような工夫をして問題を解決したか」ということに注力して、文章を展開するようにしましょう。
それと、とっておきの秘策かつ合格の必須条件を1つ。
周りのアプリケーションエンジニア合格者が口を揃えて言うのは、「問題文をふんだんに引用すること」。例えば問題文で、以下のように書かれていたとしましょう。
問題の例
アプリケーションエンジニアは◇◇することが重要である。
そのためには、以下のことを実施する必要がある。
・○○の実施 ・××の準備 ・△△の回避
こんな記述があったらラッキーだと思ってください。記述する論文には以下のように盛り込みましょう。
記述例
・・・この問題を解決するためには、◇◇することが重要であると考えた。
なぜならば、##するためには、??することが!!だったからである。
そのため私は対策として、以下のような方策を定め実施することにした。・○○の実施
<本文(根拠も添えて)>
・××の準備
<本文(根拠も添えて)>
・△△
<本文(根拠も添えて)>
つまりほとんど問題文のコピーです。採点者はわざとらしいと思うでしょうが、問題文の文言を引用することで、確実に点を得られるのはまぎれもない事実です。使わない手はありません。感覚的には、問題文の明らかに不要な部分(前置き等)以外は、全て引用するレベルです。しかし、引用が重複しないよう、一度引用した問題文には取り消し線を引くなどの工夫が必要です。
問題文に「あなたはこう書くべきです」というヒントを入れてくれているのです。
受験を終えて
合格発表の時、自分の受験番号を見つけたときは、本当に興奮を覚えました。同時に、多くの人が何度も受験するアプリケーションエンジニアに、2回目で合格できたことで、自分の分析が合っていたことを確信しました。
論文は自己採点ができず、どうしても「自己満足」に陥りがちです。一部分でも構いませんので、周りの人に読んでもらうようにしましょう。相手はIT系の知識がある人でもない人でも構いません。