アプリケーションエンジニア試験に合格した勉強法は？
こちらは読んでいただけましたか？
＞＞最重要項目！○○○を入手せよ！
私は２冊の過去問で以下の様に勉強しました。
| 項番 | 過去問 | 内容 | 私が勉強したのは |
| １ | アプリケーションエンジニア 過去問題＆分析 ２001年版 | 午前、午後Ⅰ、午後Ⅱそれぞれの過去３年間の問題と解説 | 午前を重点。 午後Ⅰもそこそこに。 |
| ２ | 情報処理教科書 アプリケーションエンジニア 平成１５年度 | 午後Ⅰ、午後Ⅱそれぞれ出題傾向に応じた問題と解説 | 午後Ⅰを重点。午後Ⅱは最終１週間で。 |
午前問題勉強法
項番１の教材をひたすら解きました。
とはいえ、最初はぜんぜん分かりませんでした！
| ＜午前問題勉強法＞ １）分からなければさっさと飛ばし（考えもしないで）、後で解答をみて覚える。あやふやなものは分からないこととする。 ２）できなかった問題、分からなかった問題のみ次はやり、できなかったりわからなかったら、解答をみて覚える。 ３）２）を繰り返し、問題全てが正解できるようにする。 ４）３）までできたら、再度全ての問題を解いてみる。ここで解けない問題が本当にあなたにとって苦手、または記憶に定着しない部分なのでひたすら覚える。場合によっては、ここで初めて参考書などを見る。 ５）４）１度でも分からなかった問題、できなかった問題を再度解いてみる。 |
１）について、知識が問われているものは、知らないものは答えられないし、計算問題は、考え方が分からなければ計算式を書くに至らないのだから考えても無駄。時間の無駄を省くために、後で解答で覚える方式をとりました。
２）３）について、いったんできた問題は忘れる。また、この段階では、内容はともかく、答えられればいい。
例）設問３の正解がウだったとしたら、
「問題の解答の内容として、適している内容がウだから、答えはウ！」
ではなく、
「この問題の内容のときの答えは上から３つ目だったな～。だからウ！」
でいいということを言っています！
まずはこの３）までを目標に繰り返します。
４）ここで、その時点の力試しをします。手ごたえを感じてみてください。かなり解けるようになったのが実感できるのではないでしょうか？
５）３）のフォローをします。
「この問題の内容のときの答えは上から３つ目だったな～。だからウ！」
だった問題に対して、解答の内容が理解、納得できているかを確かめます。４）までで、解答の内容も頭に入ってきていると思いますが、ここでフォローしてください。
以降、時間が許せば１）から繰り返します！今まで解けなかった問題を簡単に解いてしまっているあなた自身に感激してください！
午後Ⅰ問題勉強法
項番１の教材と項番２の教材をやりました。項番１の教材を早くからもっていたので、ほとんど項番１の教材をやっていましたが、最終的な詰めで、項番２の教材を使いました。
項番２の教材は、午後の試験に特化した本なので、もう少し早めにやっていても良かったかなと思います！
勉強法ですが、基本は午前と全く同じです！
| ＜午後Ⅰ問題勉強法＞ １）分からなければさっさと飛ばし（考えもしないで）、後で解答をみて理解する。あやふやなものは分からないこととする。 ２）できなかった設問、分からなかった設問のみ次はやり、できなかったりわからなかったら、解答をみて理解する。 ３）２）を繰り返し、設問全てが正解できるようにする。 ４）１度でも分からなかった設問、できなかった設問を再度解いてみる。 |
基本的には午前問題と同じ考え方です。
ただ、覚えるものが若干違うこと、および、理解をすることと、問題のパターンを掴むことが重要になります！
＜覚えること＞
午後Ⅰの問題は、システム開発、設計の経験を問われているような問題が出ます。ですので、システム開発、設計時にお目にかかる(実務ではお目にかからない場合もあるけど・・・）のＤＦＤ、ＥＲ図、システムフロー図、正規化したデータ等々の情報処理試験問題に出る記述ルールを覚えてください！
厳密に覚えなくても良いですが、見慣れておいてください。
問題を解いていくうちに、いくつかのパターンしか出題されていないことに気がつくはずです。
また、出題のパターンもデータベース、業務分析、移行・・・という様にいくつかのパターンがあります。教材でも、そのような分類毎にまとめているのが結構ありますので、確認してみてください。
＜理解すること＞
どうしてその解答になるのか？という、出題者が一番受験者の実力を知りたい部分だと思います。これは教材の解答に書いてある説明をよく読んで理解してください。
＜問題のパターンを掴む＞
出題はいろいろですが、こんなのがよくあるパターンです！
| 問題文のパターン | 説明 |
| 図ｎ中のａ～ｆに適切なデータを答えよ。 | 必ずといっていいほど出ます。 |
| ～をしようとしたらうまくできないことがわかった。その理由１５字以内で答えよ。 | システムに変更を加えるとき実現するべき内容が理解できているか問われる！ |
| ○○を実施する場合に関連するプロセスを修正する必要がある。そのプロセスと追加するデータ項目を答えよ。 | |
| ○○を改善した場合、図○○はどのようになるか。図○○を完成させよ。 | ＤＦＤ、とかフロー図とかＥＲ図とかが狙われる！ |
必ず問題を読む前に設問を見て、解答を意識しながら問題を読むことが重要！
特に、語句の穴埋めなんかは、問題を読みながら、怪しい言葉をマークしていけば、すぐ埋まっちゃったりします。
解答はほとんど問題文中の語句で書けてしまう！ということです。
（→たまに書けないものがあるので注意！。大体、○○文字以内で述べよ、というところです。過去問で、もし問題文から解答できないことがあれば、それは一般的知識（あるいは一般的用語）での記述を問われている場合が多いので、丸暗記することをお勧めします！）
午後Ⅱ問題勉強法
論文です。問題文に合わせて、やったこともないこと捏造するのは難しいです！なので、まずあなたが今までやってきたことを整理しておきます。
教材は項番２のもののみです。
| ＜午後Ⅱ問題勉強法＞ １）まず、あなたが今までやってきた開発を一通り拾い上げておく。 ２）１）の中で、特に工夫したこととか印象に残ったことをそれぞれ記述しておく。 ３）あなたが携わったシステムの概要をざっと書いてみる。 ４）過去問をみてポイントを掴む |
１）ですが、試験の最初に”論述の対象とするシステムの概要”を必ず記入するところがあります。システム名称とか、いつからいつまで、どのような立場で、システムの規模、利用者の人数等々・・・。
準備なく、いざ試験本番で記入しようとしても、なかなか書けません。書けないとこの時点で滅入ってしまい後に続きません！
２）問題が、あなたの経験してきたこととうまくマッチした場合はとても有効です！マッチしない場合でも、それを思い出してみること、書いてみることが重要。試験中ではなかなか思い出せませんよ！
３）設問１で必ずあなたが携わったシステムの概要を記述することになります。問題によって、同じシステムでも書き方が変わってきますが、とにかく何回か覚えて書いてみてください。特に、試験１週間前には必ず１回は見ないで書いてみること！
・・・考えてみてください。普段鉛筆で２４００文字以上の文を書いていますか？通常で書くことができなければ、試験本番はもっと書けないです！あと前日ではなく、１週間前という意味は、腕に疲れを残さないこと！これだけの理由です。
４）月並みですが、ポイントを掴むのは過去問をやるしかないです。私が使用した教材
情報処理教科書 アプリケーションエンジニア 2007年度版情報処理教科書は、論文問題の記述のポイントが分かりやすく、有効でした。
＜点数が取れる論文の書き方＞
それではどうすれば点数が取れる論文が書けるのでしょうか？
論文の問題は、問題文、設問１、設問２、設問３という構成になっています。
問題文は、内容から大きく４つに分かれています！その箇所と内容の意味するものは下表の通りです。
| 問題文の箇所 | その内容の意味するところとポイント |
| タイトル | その問題のテーマ。 |
| １段落 | テーマの背景を、近年のシステムねたで説明している。 大体、「～する必要がある。」的な記述になっている。 実は、この部分の内容をあなたが携わったシステムに置き換えて設問１を書けばいい！ |
| ２段落 | １段落目のシステムの話の、より具体的な「～すべきである。」という点が箇条書きになっていることが多い。 その箇条書きの部分があなたのシステムに照らしてどうだったかを設問２に書けばよい！ |
| ３段落 | 文章で記述されていたり、箇条書きであったりするが、ここも２段落目と同様、「～しなければならない。」という記述になっていることが多い。 あなたのシステムに照らしてどうだったかを設問２に書けばよい！ |
「問題文に沿った解答を！」なんて試験問題に書かれていたりしますが、文字通り、問題文に沿って解答！をすればよいのです！
私は、試験直前１週間前にそのことに気づきました。もっと早く論文の過去問を見ておけばよかった！と思いました。
＜問題の選択と論文に書く内容＞
午後Ⅱの問題を開き、３問の問題をざっと見てみました。あなたはどの様に解くべき問題を１題選びますか？
まずタイトルは重要です！例えば「パイロット開発について」なんていうお題の時に、もしあなたがパイロット開発をしたことがないのなら、敢えてそれを選択する必要はないでしょう。
次に、さっと問題に目を通します。この時＜点数が取れる論文の書き方＞の表の内容を思い出してください。
あなたが携わったシステムの内、問題文の各段落に沿った内容を実施したものがありますか？
例えば「～しなければならない。」と、箇条書きになった問題部分に照らした時、その「しなければならない」ことをあなたが携わったシステムで検討しましたか？ということです。
具体的に検討したことがイメージできて、それが、実現(１段落目の「～しなければならない。」が実現）したかどうかが具体的に書けそうか？
もし書けそうなら、それが、選択すべき問題です。
ここで注意。午後Ⅱ問題勉強法で、あなたが今までやってきたことを整理したと思います。項番１）～３）に該当します。
ところが、実際の試験では、それに該当する問題がない可能性の方が高いです！
それはなぜかというと、整理した内容の方がシステムの規模が大きすぎるのです！
・・・私の場合もそうでした！
私も、システムを全く新しく作り替えたとか、もともと違う会社のシステムを、自分たちのシステムに置き換えられるようにしたとか、性能改善とか、そんなことを整理していました。
しかし、実際に論文に書いたのは、一つの案件に過ぎない、データのリアルタイム転送化でした。試験問題を見るまで全然考えていなかった内容です。
・・・じゃあ、最初の整理がまずいか？というと、そんなことはありません！最初の整理は、あなたがやってきたことの主要な幹と枝の部分になります。
試験問題を見て、２段落目、３段落目あたりの箇条書きで書いてある検討をした案件を探すとき・・・つまりもっと先の細分化された枝を捜す基準となります！主要な幹と枝を整理したからこそ、早くもっと先の枝にたどり着くことができるのです。
試験当日、その主要な幹、枝に問題が合致しなくても慌てることはありません。落ち着いてその先の枝を探してみてください！
照らし合わせた結果、問題が決定したのであれば、もう書く内容は確定したも同然ですね！照らした問題部分について、自システム側で検討した具体的内容がそのまま解答なのですから。
＜設問３について＞
最後に設問３の記述方についてです。
ここは大抵、あなたが設計したシステムの評価と、今後の改善点の２つの記述を求められます。
ここでの重要事項は、設問２までを否定する様な解答をしないこと。設計自身を否定することになってしまいます。改善したシステムを使用していくうちに、追加要望が挙がったなどで、それに対応する、といった程度の内容をうまくまとめて締めた方がいいと思います。
以上が勉強法でした。
ところで、いったいいつごろから勉強を始めたのか気になりませんか？