理論値を目指せ、満点を目指すな。考えても分からない問題に時間を割くのではなく、プログラムのミス、計算ミス、判断ミス、文章の確認不足を恐れた追加確認、記述の正確化など優先せよ
ケアレスミスをへらす工夫を。一度解いた時にケアレスミス完全になしには出来ない。解いている最終に考え直していくか、二週目で頭をいい意味でリセットさせる。
単語問題は分からなければ早急に飛ばせ、そのことは忘れろ。問題には必ずチェックをつけて。2 周目にチェックを見て思い出そうとするはず
穴埋め問題かつ文中利用の問題は、いきなり見つけようとせず、何がほしいか？を考えろ。それっぽい単語が複数あって騙されるから必ず。
図にはヒントしかない。無駄な情報はないと思え
文章に下線引くのは悪くないが、下線を引いた箇所だけ問題を解く時に確認するわけではない
文章中を確認せず勘で選ぼうとした時点で正答率はぐっと下がる、この意識を忘れるな。
不注意な受験生を潰すための引っ掛け問題は十分にある、そのつもりで解く。引っ掛けに引っかからない意識。
記述
- まず一言で本質・結論を記述。そこから足していく。少しずつ良くする。
- 説明は主語抜けてないか、動詞があるか、必要な具体性にかけないか、抽象的に書くべき箇所は抽象的か、自問自答して最終到達地点と言えるか、考える。
- 下線部の説明は、どの時点での判断かを注意せよ。その下線以下もすべて考慮しないパターンがある。その下線部時点で、どう考えたか？という問題だと、その下線前の情報から判断しないと模範とならない。
- 自分で採点するつもりで記述をより正確に作りあげる。そのためには下書きする必要あり。
- 記述はひねった独創的な文章ではなく、素直なムダを省いた文章を意識せよ
- 表現に気をつけろ。出来ないのか、するのが難しいのか。一定間隔で 1 回か、一定間隔未満で 1 回か。
- 具体的であるべき場所は具体的に書いたままにせよ、時間・カウント値などの数値は組み込みで鍵になる
- 手も足も出ないときは、本質的に間違えているか、素直に考えるだけか、本当に分からないか。素直に、浅く考えることを第一優先にする。
- 任意の文字数制限は基本的にゆるい、ちょうどくらいになるのなら、間違えている。もっと簡潔な答えが絶対にある
- 〜の 1 つを答えよ、なら複数あることは確定。1 つを正確に答えよ
- 常識問題や自明に近い問題は、本文に答えがあるとは限らない・・・
- 使う単語が具体的過ぎないか注意する（PC ではなく機器とまとめるべきなど
- 字数を減らせるなら減らすべき、説明すべきことがすべて入るように。
- 解答パターン
  - 本文に根拠がある
    - 探すしかない。探す前に、どういう情報がほしいか？を考えてから探すと迷いは少なく。
    - 根拠を見つけるにしても、どの時点での根拠かは要意識
  - 本文に根拠がない
    - 一般常識を元に、文章題の流れを汲み取る
    - 知識問題も兼ねていることになる。本当に無理だったら諦めるのも大事
ミリオンとメガは違う
具体的な単語が問題文にあったら正確に答えに反映・利用しようとせよ、判断ミスをへらす努力を

情報セキュリティの掟

選択問題の 2 択まで絞ったのに判断ミスするパターンが多い。問われていることを読んで再度理解して選ぶべき。選択肢を睨んでいても進展がなかったり、合理的な判断ができなくなる気がする
結論を答える。途中経過ではなく。とにかく、自問自答して、最終到達地点だと自信を持って言える回答をする
記述の該当箇所が定かでなく、自分で考えたものを書いてよいか不安になったが、この問題に関しては自分で考えたものを書くべきだった。この判断が弱い。いわゆる常識問題だと本文に答えはない
国語的にも理解しづらい問題を無駄に悩んでしまった。直接関係する箇所が分かっているのだから、いったんそこを書いておいてあとで見直すべきかな
案外素直な答えしかない場合もあるし、実際にこれはそうだった。
与えられた条件、状況を正しく把握。他の問題はこうだったし、こうだろ〜という幻想は危険。マシンの配置なら簡単な図を。通信でも簡単な図を。読みながら書くべき。
うまく表現しづらい言葉は、文中にしれっとおいてあったりする。とりあえず冗長でも自分なりにメモして、これに近い、これをより短く表す単語を見つけようとすると良さそう
選択肢の穴埋め問題も、引掛けが必ずある。該当箇所の前後からより正確に選び出せ
選択肢を見て初めて、もしかしてこうでは？と思ったのならチャンスで、本文を確認して根拠を見つけに行く
選択問題（1 つ選ぶもすべて選ぶも）では絶対に違う！というものは印付けて、あやふやなら？をつける。後で比較する。

プログラミングの掟

与えられた図・具体例はヒント。
具体化して問題を考えたのは正しいが、プログラムでは当然、抽象化せよ
似たような変数に注意せよ、あれ？となる・ならないに関係なく、絶対に確認せよ。自分を信用するな。指差し確認して正確に把握せよ。
数式を書き出せ、狭い場所に書くな、ミスを見つけたら前のもすべてやり直すつもりでとき直せ
if,while の中身の書き方に注意
- if(BOOL が true と等しいとき)
- while(HOGE が X 未満)
使っていない変数がないか確認せよ、絶対に使う。無駄なプログラムは与えられないというのが最大のヒント
コードの穴埋め
- 半分くらいまで来てミスに気づいたり、あ、こうじゃない、と気づいたら、ロールバックせよ。
- 空欄系の問題でラストが分からないなら飛ばしていい。途中がわからないのは後の理解に響くが、最後なら正直 1 点だし、捨ててもいい
- 途中の設問でミスに気づいたら、それの前後の問題に悪影響出している可能性あるからとき直せ。消す必要はないから、余白に書く。
常識的に、超複雑な計算を複数回させることはない
具体的な処理手順が与えられていて、それを実際にやったときの数値を答える問題は、その問でミスった場合は他の設問に影響する場合がそこそこ多いので、時間をかけて良いから確実に理解して値を求めて問題文の読み違いなどを修正する
ケアレスミス予防のために、プログラムをいきなり埋めずに、数式を確実に書き出して、その後にプログラムにする
算出する、と問われているのだから算出する方法を模索せよ
例のケースを最後まで書き出せば解けたであろう問題が合った、文中で示されてた題材の例は最後まで手を動かそう。
割り算は「／」で書く
掛け算は「＊」のことが多い
記述は、基本的には最大字数より少なくて答えとなる、つまり、多かったらそれは答えではなく、的外れである可能性が高い
満点を取りに行くのではなく、理論値を取りに行くためにできることをするべき
今回の場合で行くと、その仕方ないミスの問題を考える時間を使って、別の穴埋め、計算にミスが無いか、他の大門の記述の精度を高めることが出来ないか、を優先する
配列の中身が具体的にどこか確認していないことによるミス
記述の表現は、文中から答えると推測できるものは、可能な限り文中の言葉、表現を使い、本質のみを言及、つまり無駄な言葉は省こう
記述はひねられた解答より、素直なムダを省いた解答を心がける
該当しそうな箇所は一見面倒でも地道に確認せよ
行ごと書け、なのに変更する一部分しか書いていなかった。任意の場所に代入する系は、どこからどこまで回答にするか、を常に意識する。
具体化して問題を考えたのは正しいが、プログラムでは当然、抽象化する。それに合わせて回答する必要があるのに。N=3 で考えていても、プログラムでは N という変数のまま解く。
やけに簡単だと思ったら、何かに引っかかってしょうもないミスをしている可能性がある

システムアーキテクチャの掟

時間やカウント値などは具体的に記述する、不要な修飾語は省く
時間の単位変換は、簡単なものから書き出して、それを利用して割り算せよ
システムアーキテクチャではシステム構成図にもヒントが眠っている、最初から構成図をガン見する必要はないが、問（特に記述問題）を解くときには要注意。図は必要だから載せているということを忘れるな
グラフ的に無理と分かるが、それだけで決定してはならなかった。実際に数値計算をして、本当にグラフのようにダメだ、という確信が得られないと博打になっている
記述の精度を上げるよう、本当に良いか？を自分で疑え
記述で文中の用語を使う場合は、可能な限りそのまま使い、当然無駄な部分、具体的すぎる部分があるならそれは抽象化・飛ばし、書く。無駄に創作・カスタマイズはしない
選択問題で安直に特定のワードを直接説明した選択肢を選ばない、いったん手を止めて、冷静に
記述、理由説明でズバッと簡潔に言うことを意識できていないし、本文を利用できていなかった。これは本文を利用することが自明でもあるんだから、判断ミスがないように注意
記述において、自分の書いたものを、書く前のメモを見て、これが絶対か？より深く、正しく言えているか？を疑い続ける
選択肢、印をつけたが見づらい感じで解答用紙に写すのミスった
主語の意識が記述で抜けてしまった、疲れもあるが言い訳に過ぎない

ネットワークの掟

問題文を確認する努力がとにかく足りておらず、勘になってしまっている。そりゃ間違える。問題を読み進めながら解くことで、問題文を完全に忘れることはないと推測できる。
IP アドレスからサブネットマスク考えるなら、該当する IP をすべて書き出すべき。そうしてネットワークアドレスを確定させる
LAN は強度なども考慮する
文中にヒントはあっても、前提知識がないと厳しいのもある。無理だと割り切って次へ進み、取れるところを取る意識
記述の主語抜け確認不足
通信については基本的にインターネットからの応答のほうがパケット大きい
トラフィックの上り下りも意識しよう
〜を見て、不具合は具体的に何と考えたか？を答えよ
- つまり、その下線時点の考え、それ以下の文章はない前提の答えに絶対にしないとダメ。問題文の読む力が甘かった。
記述がほぼない年もある、その代わり文章や図の確認にかなり時間がかかると事前に覚悟を決めておく
ネットワーク構成図がない場合は自分で書くとスッキリ記述も解けるかも。
記述、下書きしてないからミスに気づけなかった。だめだよ
選択問題で「〜少ない」というとき、単に少ない＝数個という意味ではなく、他の何かと比べて少ないという意味合いである点に注意、これでミスった。単に少ないだけなら、X とは言えないから。
4 つリストアップされていて、2 つが違うのなら、残りが答えになるのは自明。深く考えすぎなくてもいい

組み込みシステムの掟

通信障害がある＝何も通じていない。引っ掛け問題。
与えられた条件を自分の頭で置き換えるな・・・実際に起こったのは何回か？を考えろ
ステレオなら＊２、モノラルならそのまま！引っかかるな。
記述でなく、選択問題・数値問題だったら、まじで分からなくてもそれっぽいのを一応書いておけ。記述の場合は当てずっぽうは基本当たらない
四捨五入か切り上げか、そこまで丁寧に問題文を確認せよ
組み込みはカウント値で考えるのが非常に大切、なん分以上とかではなく、O 回のカウント値になったら、のように
フローチャートから不具合を見つけることは一般に大事！
必要に応じて記述は具体的な説明が求められる。組み込みだと特に、具体的なカウントとか、特定のイベントを指定することが多い。他の記述とは違うと認識した上で記述するように注意
単語の記入問題は、前後関係や本文の関係を利用すべき（はっきりしない場合は
無駄な表現がないように気をつける
- 〜してしまうため
- 〜するため
- でいい
具体的に数字を書き出して試して特徴を掴んで記述に落とし込もうとしていない
フローチャートと説明がある問題では、フローチャートに読んだ説明を適宜書き込んで理解を深めるべき
組込み開発では、正確に時間やカウントが正確でなければいけません。
0.5s 周期で未検出かどうかがわかって、3 分以上だとある時点から継続しなくても累計で 3 分なったら異常とか読めるんですよね。プログラム的にやるならやはりカウントですな
応用情報技術者試験ドットコムより
数字系の問題は、小さな数で試せ。絶対に分かるし、そこで引掛けポイントに気づくことが可能
5 分以内！＝ 5 分経過する前にが安全。安全な行記をするべき
組み込みは消費電力も大事、隠れた答えになっている
字句挿入問題、適切な語尾かとうか、きちんと判断。とくに複数箇所で字句のスペースが共有されている場合は、すべてに最適な記述を行う。例えば、説明文とフローチャートなど。説明文ならどんな言葉でも入りうるが、フローチャートは形式が決まっていて、他の語を見れば一目瞭然
組み込み開発はシビア、という意識。コーナーケースではないが、ギリギリをつくケースが存在し、それも考える必要がある。簡単すぎるな、という時に中位すべき

おわりに

少しでも参考になれば、、、と思います。