DEVELOPER’s BLOG

技術ブログ

文系学部生 応用情報技術者試験 合格振り返り

2019.12.25 吉原 和毅
コラム
文系学部生  応用情報技術者試験  合格振り返り

はじめに

2019年秋の応用情報技術者試験に無事合格することができたので、勉強法などを何番煎じかわかりませんが書いていこうと思います。 私は現在文系学部の2年生で、趣味でプログラムとかを5年ほどやっているのでパソコン系の知識はそこそこありますが、数学や理論といったことははめっきり。 今春に基本情報技術者試験を通ったのでその流れで受けました。

試験の概要

IPA(独立行政法人 情報処理推進機構)によって実施されており、士業の独占などはありませんが、国家資格のひとつです。

対象者像
高度IT人材となるために必要な応用的知識・技能をもち、高度IT人材としての方向性を確立した者

IPAより

試験形態として、午前・午後試験があり、両方で60点以上で合格です。 午前試験が全て4択問題に対して、午後試験は記述式です。とはいえ、問題のほとんどが選択肢問題だったりします。
こちらから試験の過去問が公表されています。

問題の傾向や勉強法

午前試験

テクノロジ系 50問

マネジメント系 10問

ストラテジ系 20問

の3つ全80問から構成されています 。

基本情報と難易度はさして変わらないと言われますが、覚えないといけない量が少し増えます。特にテクノロジ系は計算問題が基本情報に比べ遥かに難しいと感じました。

ただ、午前試験の対策を万全にしていたら午後試験もその知識で解ける問題がほとんどだと思いました。

勉強法

ひたすら過去問を繰り返す。

私は ここを愛用していました。

会員登録はすると間違えた問題でソートしたりできるようになります。必須です。これだけでいいです。

参考書を基本情報試験のときに1冊購入しましたが、結局1回流し読みしてあとは辞書変わりに見る程度の使い方しかしていなかったので、応用情報用の参考書は買いませんでした。参考書通りにじっくり時間をかけるのはコスパ悪いと思います。 基本情報のときにはこちらを使っていました。

textbook

紙の本を買っても、電子版のpdfを無料で使えたので重宝しました。

わからなかったところは、ググって出てきた中で一番易しそうなのを見ました。文が多いと嫌になるので。
自分はここでさっと見てわからなかったら深く調べていました。 だいたいここで完結できます。

ある程度の知識があれば、通勤、通学時間だけで事足ります。

私は、通学に片道1時間程かかるので、その時間にせこせこやっていました。

電車の中では計算問題を出さないモードがあるので選択肢だけで完結している問題に終始するといいと思います。

本番はいくらでもメモが取れるのでそういった問題は別個で机に向かって解くと時短になります。

当日

試験時間が全部で150分もありますが、40分経つと退出可能になります。午後のことも考えて十分見直しが終わったら長めの昼を取るといいと思います。
私は30分で1週解ききって追加で30分ほどかけて見直しをして退出して隣の駅まで悠長に食事をしに行きました。

午後試験

試験の1ヶ月ほど前に気合を入れて過去問をコピーして3週間かばんにいれ読むことはなくお守りに。1週間前に焦って解き始めました。 分野として、

  1. 情報セキュリティ※必須
  2. 経営戦略
  3. プログラミング
  4. システムアーキテクチャ
  5. ネットワーク
  6. データベース
  7. 組込みシステム開発
  8. 情報システム開発
  9. プロジェクトマネジメント
  10. サービスマネジメント
  11. 11システム監査

の全11問の中から1以外から4問選択できます。

前までは経営戦略かプログラミングのどちらか1つが必須だったみたいですが、その縛りはなくなったようです。

勉強の時点で全てをやる必要はなく、ある程度自分が本番で解きそうな問題に絞ってやるようにしました。

選び方ですが、2, 6, 9, 10, 11が文系の人が取りやすいとよく言われています。 とはいえ、結局自分の得意なものがなにかをわかるのが一番重要です。

自分の知識がなにかを知る

私の場合事前に2, 3, 4, 5, 7にしぼりました。

  1. (必須), 前にctfに友人に誘われて参加したことがあり、そのときに学んだ知識と、午前の勉強でほぼ何にでも対応できそうだったので特段の勉強はしませんでした。ctfは分野が広いのでもしやっていれば非常に有効だと思います。私が受かったのはほぼこれのおかげだと思います。


  2. 簿記2級レベルならできるのでその範囲内に収まるなら選択するようにしました。その範囲から外れてたら過去問でも捨ててました。結局見極めが大事です。


  3. ある程度のプログラム経験があれば前準備なしでもできます。細かい仕様などは問題文に書いてくれているのでそこさえ気をつければあとは慣れです。


  4. システムアーキテクチャなぞ当然構築経験はありませんが、9, 10, 11に比べ文が少なくその代わりにちょっとした計算が絡むから楽だと思って選んでいました。本番は初っ端から掛け算間違えて途中まで解いて別に鞍替えしました。


  5. ctfと午前の知識でどうにでもと思い選択。本番では選択肢わからないのがあって途中まで解いて他で点が取れそうなのがあればそっちにいって無理そうだったら戻ってくることにしました。


  6. dbは1回覚えれば簡単!文系でもできる!と喧伝されてますが、sqlを触ったことがないのでパスしました。


  7. 3と4を足したような感じで読めばなんとでもなりそうだったので選択。毎年同じパターンの問題が1つは出るので過去問を多めに対策しました。


  8. 勉強のときには目もくれていなかった分野です。本番では惰性で5が自信ないからと見たら案外行けそうだったので選択。4との違いがいまいちわかりません。


  9. ここは基本情報のときに一番嫌いな分野だったので目もくれずスルー。計画性のあるかたは是非。


  10. ぶっちぎりの文字数。読みたくないです。


  11. 午前の監査系がこまごましてて嫌いだったので見ることもなく。

実際に本番で選択したのは、2, 3, 7, 8でした。事前にある程度範囲を絞るのも大事ですが、不足の事態に対応できるようにするべきだなぁと後悔しながら解きました。

極端な話3問完答すれば、残り2問は0点でも受かるので自分の得意な分野を探すことが本当に大事です。 これを書きながら再度感じました。

勉強法

上述の通り勉強自体は午前の用意の段階で終わっているので、あとはどの分野を選ぶかを決めるだけで十分だと思います。


過去問用の参考書も売っていますが、答えも公開されているのでそれをみてわからなかったら自分で調べてそれでもわからなかったら捨てる。という戦法で問題ないと思います。

ある程度絞ったら私は、傾向を掴むために過去問数回分やりました。数回分とはいえ、本番が1回2時間半で、本番より多い範囲やっているので結構な時間がとられます。


できなかった問題について用語など知っていればできた問題を落としたのか、それとも読めばわかる問題を落としたかの分類をして、知識が足りなければひたすら午前の問題を、論理問題を落としてしまったら集中力が切れているので寝てリフレッシュしましょう。


公式HP過去問
過去問道場

気をつけるべきこと

応募の締切が早い
2ヶ月前に締めきられてしまいます。私はこれで1回分逃しました。

試験当日への身構え
お金を払ったのに4割の受験者が会場に来ないようです。ハンター試験と揶揄されています。前もって予定の都合をつけたり当日面倒にならないようにメンタルケアをしておきましょう。

長期戦である
時間通りに受けていたら休憩時間が1時間しかありません。回収時間なども考えるともっと短くなってしまいます。早めに出て気晴らしに美味しいものでも食べましょう。食べすぎると午後眠くなります(戒め)。

思ったらまとめるほど勉強してなかったし運がよかったのかもしれません。

総勉強時間は、電車で毎日見ていたので往復2時間を20日ほど、午後の過去問を4回分解いたので約10時間。あわせて50時間。

机に向かっていた時間は10時間ほどなのでこうしてみるとそれでも結構やっていたなと思うくらいの時間感でした。

Twitter・Facebookで定期的に情報発信しています!

関連記事

MacBook Proにログインできない?復旧キーの探し方とロックの解除手順

はじめに 復旧キーとは? 「復旧キーがない場合」を試す まとめ はじめに 先日、私用のMacBook Proにログインできなくなる問題が発生しました。 経緯としては、2台あるMacBook Pro AとMacBook Pro Bを取り違えてしまい、MacBook Pro AにMacBook Pro Bのパスワードを入力し続け、パスワード入力の試行可能回数を超過してMacBook Pro Aにロックがかかりました。 Macのログインパスワー

記事詳細
MacBook Proにログインできない?復旧キーの探し方とロックの解除手順
コラム
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理

はじめに SSM統合コンソールによる一元管理 OSなど構成情報の可視化 Patch Managerによるパッチ運用の標準化 証明書有効期限の集中監視と自動通知 導入効果と業務改善イメージ 導入時の設計上の留意点 継続的改善を支える「運用の仕組み化」 1.はじめに クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を

記事詳細
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理
AWS SRE コラム
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス

はじめに 可用性設計の基礎:リージョンとAZの仕組みを理解する 止まらない設計を妨げる単一点障害:単一AZ構成の限界 マルチAZ構成:同一リージョン内での止まらない仕組み マルチリージョン構成:事業継続(BCP)のための冗長化 まとめ:設計段階で「どこまで止めないか」を決めよう 1. はじめに AWSは、数クリックで仮想サーバー(EC2)を立ち上げられるなど、手軽にサービスを構築できるクラウドです。システム企画や開発の初期段階では

記事詳細
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス
AWS コラム
[AWS ECS + Rails] スティッキーセッションとCSRFトークンエラー対策

はじめに スティッキーセッション(Sticky Session)とは Railsのセッション管理とCSRFトークン スティッキーセッションを無効化し、redisにセッションを保持させる場合 負荷分散とスティッキーセッションの設定 × セッションの保存場所 1. はじめに AWS ECS上でRails on Railsで開発したWebアプリケーション(以下Railsアプリ)を運用する際、ユーザーごとのセッション管理は重要なポイントです。 負荷分散を行いた

記事詳細
[AWS ECS + Rails] スティッキーセッションとCSRFトークンエラー対策
AWS コラム

お問い合わせはこちらから