基本情報技術者試験を6回受験した経験から語る役立ち情報

未経験でIT業界へ入った時に基本情報技術者試験に合格するということは一種の憧れがありました。年に2回しか受験できないためとりあえず毎回申し込みをしようと決意し、結局6回目で合格しました。我ながら落ちすぎだろうと恥ずかしいですが、最後の試験では午後のアルゴリズムが満点でJavaも7~8割とれたことを記載させて下さい…(名誉挽回のため)

とりあえず結構な回数受験したのでそこで実際に思った役立ち情報のような物を紹介したいと思います。勉強の合間のブレイクタイムにでも流し読みしてもらえればと思います。

 

受験票の顔写真を忘れても試験開始30分までに用意すれば受験可能


受験票に顔写真が必要なのですが、実は忘れていても試験開始から30分以内に写真を用意して戻ってくることができれば受験ができます。というより遅刻しても30分以内に教室に入れば受験させてくれるので当然の対応といえば当然ですね(その旨の記載も受験票にあります)。

4回目の受験の時ですが受験票を確認するために試験官が席を周っていた時に隣の人の受験票に顔写真がありませんでした。顔写真の面を裏返してやり過ごそうとしていましたがあっけなく見破られ、試験管に写真を用意するように促されていました。

結局一度退席しましたが10分程で戻ってきて「写真用意できなかったんで辞退します」と言って帰っていきました。

6回受験しても顔写真がない人はこの1回しか見たことがないのであまりない例なのかもしれませんが、万が一忘れてしまっても落ち着いて準備しましょう(絶望的な状況には変わりありませんが…)。

 

試験開始時間は集合時間ではない


試験は9時30分開始と書いているので9時30分集合というわけではないです。

というのも9時15分くらいには試験管が説明を始めて、携帯電話の電源を切れとか色々指示され始めます。9時25分くらいには問題冊子を配られ試験開始時間まで待ってくださいといわれシーンとした教室で待つことになります。

こんな状況でがらがらっと入ってきたらみんな注目されて結構恥ずかしいですし、気持ちの面でも出遅れてしまいます。

9時くらいに余裕を持って会場入りするのがいいかと思います。

 

目薬は机の上に置いてもOK


5回目の試験の時でしたが、机の上に目薬を置いていたら試験管から「目薬をしまってください」と注意されたことがありました。そこで私は「受験票の机に置いていいものの中に目薬も可能って書いてますよ?」と言いました。というよりさっき別の試験管が説明の時に目薬OKといっていたのになぁと思っていましたが確認後問題ないと言われました(そして謝られました)

机の上に置いていいものの中で目薬だけ少し浮いているような気もしますがOKなのです。目薬をさすと疲れた目が刺激され集中力が戻るのでかなり重宝しました。

目薬というアイテムは上手く使うと効果があると思いました。

 

シラバスが更新されているか確認する


IPAのホームページの右側に『試験要綱・シラバス』という項目があります。

この中の資料に新たに出題される項目が増えていることがあります。例えば最近ではテザリングとかそういう新しい単語です。

更新された項目は出題される可能性が高いらしく一読しておく価値はあると思います。よくわからない場合は最新の『でるとこだけ系』の試験対策本を読むとまとまっていて勉強しやすいかと思います。

困ったら『ウ』


基本情報を取得していた情報系専門学校卒の同僚が言っていました。どうやら選択肢の『ウ』が正答率が高いとか…。

IT業界に入ってすぐの1回目の試験で計算問題が全然わからず、とりあえずウにしたら8割くらい合っていてそこそこの点数を取ってしまいました(でも不合格)。ここでそれなりの点数を取ってしまったのが「意外といけるじゃん」と勘違いしてしまい、他の試験勉強を並行して始めてしまい、結果として6回も受験するはめになってしまったですが、「困ったらウにしておけばいいか」と決めておくと少し受験の緊張が和らぐのではないでしょうか?

 

問題に対してどの分野の問題かわかるようになってくると合格が近い


これは完全に主観なのですが、問題を解いていて「あ、ここはマネジメント系の問題だ」とわかるようになってくると合格が近いと思います。

というのも基本情報の問題は「計算問題」「知っていなければ解けない問題」「よく読めば解ける問題」の3つに分けることができると思います。そこで「あ、これはマネジメント系の問題だ」とわかれば「よく読めば解ける問題」に分類されるので時間をかけていいかどうか判断ができます。これは「ハードウェアの問題」となれば大抵「知らなければ解けない問題」になるのでもしわからなければ後回しです。

また、合格のため勉強では過去問を何度も解いていると思いますが、何度も解いているうちにこういった分野がわかってくるようになりました。つまり分野がわかってくるくらいに勉強をしているというひとつの目安になるのではないでしょうか?

 

基本情報技術者認定試験は難しい!


『IT業界を目指す人が最初に目指す試験』とか『業界に入って3年以内に取らないと向いてないんじゃない?』とか取って当たり前というプレッシャーがある試験ですが、実際IT業界で持っていない人も結構います。なんせ合格率が2割ほどなので落ち続けたからといって「自分は駄目なんだ…」と思わず何度も挑戦してもらいたいです。

技術の移り変わりが激しい業界ですが、基本情報を勉強する過程で学んだ知識は意外なところで役立ったりします。OSI参照モデルとかその辺りの対策はインフラ系の仕事はもちろんweb屋でもhttpの仕組みなんかを理解するのに役立つと思います。

この記事が試験当日に少しでも役立てば幸いです。

 

スポンサーリンク

【新人君物語】第3話 名前をつけるって難しい!編

引き続き先輩さんにソースレビューをしてもらっている新人君。どうやら先輩さんにはまだ気になるところがあるようです。

先輩さん「新人君、ここの変数parameter1とparameter2っていうのは何?」

新人君「parameter1は画面から入力された名前でparameter2は住所です。」

先輩さん「どうしてこの変数名にしたの?」

新人君「画面の最初の項目だったのでparameter1、2つめの項目だからparameter2としました。何かまずいですか?」

先輩「なるほどね…。ちなみにこっちのstartって?ここは終わりの処理だと思うけど?」

新人君「あ!すみません、そこはコピペしてコピー先の名前のままでした。」

先輩さん「…」

 

解説


名前をつけるって難しいですよね。開発をする時はプロジェクト名からクラス名、メソッド名、変数名、返り値のなどなど名前をつけることはたくさんあります。案外ソースを書いているよりよりよい命名を考えて頭をひねる時間のほうが長かったりするのではないでしょうか?

新人君の命名方法ですがかなりまずいですね。名前であれば素直にname、もしくはinputNameとかわかりやすい名前にしたほうがベターでしょう。最初の項目だからparameter1としてしまうと、例えば名前と住所の間に郵便番号の項目が増えてしまったらどうすればいいでしょう?parameter1.5とするのでしょうか?

命名はたいてい英語のため、例えば「入力」って英語でなんだろう?とか「結果」ってなんだろう?と最初は英訳しながら名前をつけることもあるかもしれませんね。

規則に合わせるのが一番大切


プロジェクトやフレームワークにより命名規則が決まっていることも多々あります。インサート文をデータベースに実行するクラスであれば『insert○○クラス』やDTOであれば○○Dto.javaとするみたいな感じです。

たとえこの名前なら一発で何をしているかわかる最高の名前が思いついたとしても命名規則に沿っていなければそれは駄目な名前なのです。


 

新人君「名前をつけるって大切なんですね」

先輩さん「そう。開発は終わってもシステムは動き続ける限りそのコードはずっと残ることになる。いつか見返した時に何をやっているかわからなければあまりいい名前とはいえないよ。もしその辺を勉強したければ『リーダブルコード』という名著があるから読んでみるよいいよ。これは『プログラマーが読むべき本』みたいなランキングで大体上位にいるからオススメだよ」

新人君「わかりました!」

 

続く…

 

スポンサーリンク

【新人君物語】第2話 どうして同じ処理をまとめるの?編

先輩さんが新人君のソースレビューをしている時です。先輩さんがむむっとうめいて話し始めました。

先輩さん「おや?ここのコードだけど違うメソッドで同じ処理がされているよ?なんでかな?」

確かにここは全く同じ処理をしているロジックがある。それは自分でも把握していた。

新人君「確かにここは同じ処理をしていますが、AメソッドではA画面のパラメータを受け取っていて、BメソッドではB画面のパラメータを受け取っています。違う画面の処理なのでそれぞれ分けました。」

先輩さん「なるほどね。ただ全く同じ処理を複数書くということはよくないことなんだ。なんでかわかるかい?」

新人君は動いていればいいんじゃないの?という思を隠しながら、どうして駄目なのか考えてみました。

 

解説


確かに新人君の言うとおり動いているからいいじゃないかという思いもわからなくはありません。ただ、一度作ったプログラムはこの先改修をされる可能性が高いと言う事がポイントになります。そう考えるとなぜ同じ処理を複数個所で書くのがいけないのかわかると思います。

変更に弱いシステム


例えばほぼ同じ機能をもったA画面とB画面にそれぞれ「備考」という項目が増えたとします。その場合「備考」項目を受け取る処理が追加になります。プログラムを見てみると受け取る処理は全く同じなのに別々にプログラムが書かれていました。ということは改修は2箇所になります。

今回は2箇所だからまだいいですが、何箇所も同じ処理が散乱していると修正漏れがあるかもしれません。画面項目なら動かせば修正漏れがあったとわかるからいいですが、あまり気がつかないような処理であればバグの原因がわからずただの修正漏れに時間がかかってしまう可能性もあります。

つまり変更に弱いシステムになってしまうのです。

テスト地獄


また処理が増えるということはこの後実施するであろうテストにも影響が出ます。全く同じ処理(コピペしたソース)だったとしてもそれぞれテストの必要性があります。

例えば「世界のナベアツ」クラスと「日本のナベアツ」クラスがあったとします。どちらの機能も『画面に入力した数字に対し3の倍数であれば画面に表示する』という機能だったとします。

テストでは1~100の数字を1つずつ画面に入力して網羅することになりました。「世界のナベアツ」クラスは問題ありませんでした。ふぅ終わった終わったと思ったのもつかの間、今度は「日本のナベアツ」クラスに対し同じ作業をする必要があるのです。

上の例は極端ですが、同じ処理が複数あるということは同じテストをその個数分必要になる可能性があるということです。

共通化しよう


ということで同じ処理は共通化してしまいましょう。具体的には引数だけ渡して同じ処理を呼ぶとか、そもそも違うクラスで共通クラスを作るのもいいかもしれません。

もしかしたら上手く共通化できないということもあると思います。実際に同じ処理だからといって機能的に共通化できないこともあります。

ただ理由が「自分の技術では難しそう」ということであれば少し頑張って考えてみてほしいです。もしくは先輩に聞いてもいいかもしれません。長い目で見るとそれだけ時間をかける意味はあります(納期以内でね!)

 


新人君「先輩さんの言ったように上手く共通化することができました!」

先輩さん「お疲れ様。コードも短くなってすっきりしたし、よかったよかった」

新人君「先輩さんにレビューをしてもらいよかったです」

先輩さん「そうだね。これからもどんどんレビューしていくからね」

新人君「よろしくお願いします!」

先輩さん「よろしくね。(新人君のコードはレビューしないと危な過ぎるからね…)」

続く…

スポンサーリンク

【新人君物語】第1話 初めての開発編

『新人君』は某情報大学を卒業した新卒の男の子。研修が終わりプロジェクトにアサインされました。優しい『先輩さん』に教わりながら今日からプログラマーとしての人生のスタートです。


先輩さん「環境構築も終わったし、さっそく新人君には開発をやってもらうよ。まずはこの画面を作ってね」

先輩さんから説明を受け早速開発に入ります。任されたのはとあるECサイト(ショッピングサイト)の管理ページです。この画面にテキストボックスとラジオボタンを増やし、登録ボタンを押すと入力値をデータベースに登録するというものでした。

新人君はさっそく画面にテキストボックスとラジオボタンを増やしました。似たような機能がある画面のソースを教えて貰ったので真似をすればすぐに画面は完成しました。問題はその後です。登録ボタンを押したらどのような経路でデータベースに登録されるのかさっぱりわかりません。参考ページを見ても色々なクラスが呼ばれているのはなんとなくわかりますがじゃあどうすればいいのか。

新人君は途方にくれてしまいました…。

 

解説


新人が配属された時、web業界ではわりと任される開発内容ではないでしょうか?管理ページというのは直接お客さんが触れるサイトを「管理」するページなので例えばショッピングサイトのページにバグがある場合より管理ページにバグがあったほうが被害は少なくすみます(運用でカバーできたりもするので)。

今回新人君はデータベースの接続方法がわからず途方に暮れていますね。データベースに接続といっても言語やフレームワークによっても違いますし、そのプロジェクト独自のルールもあるのでまずは聞いてみるのが一番でしょう。

ただし「データベース」に何かするということはどのシステムも必ず「SQL」を使っているというのは変わりません。またヒントとして「MVC」モデルの考え方があると理解しやすいと思います。

SQL


私も新人の頃先輩に「データベースに何かしているということはこのソースのどこかにSQLが書かれている場所があるからそれを探すのだ」と言われなるほどなと思ったものです。

新人の頃は「げ、SQL書かないとだめなのか」と身構えてしまうかもしれませんが、こればかりは避けて通れません。フレームワークによっては直接SQLを書かなくてもフレームワーク独自の機能を使ってデータベースにアクセスしたりもできますが、SQLの基本は変わりません。基本はなるべく早く覚えた方がのちのち楽を出来ると思います。

近道としては使用しているフレームワークのデータベースアクセスの仕方を調べてみることです。場合によっては色々なクラスを経由した上でようやくSQLが現れるということも珍しくありません。なんでこんなあっちこっちクラスを呼ぶんだ?と思ってもそういう思想があると思って納得しましょう(余裕がある時にでも調べましょう)。その過程でゲッターセッターの存在やクエリビルダの存在、DBマッパーの存在を知ると思います。…頑張りましょう。

 

MVC


MVCとはモデル・ビュー・コントローラーの頭文字をとったものです。今回の開発を例にすごく乱暴にいうと

モデル=データベースに接続する流れ

ビュー=画面

コントローラー=ビューとモデルを繋ぐもの

という感じです。まずビューで入力されたものはコントローラーで受け取り、受け取った値をモデルへという流れになります。

MVCを元に作られたシステムであればこの辺の役割がしっかり分かれているので全体像が理解しやすいのではないでしょうか?ちなみにモデルはサービスと呼ばれることもあるのでなんちゃらサービスクラスというものがあったらモデルと思っておいてよいかと思います(フレームワークやシステムによっては違うこともありますが)。そんなこと言われたってDAOとかDTOとかあるって?まぁそういうこともありますよね!コントローラーとモデルが曖昧になってたりすることもあるのでその辺は空気を読みましょう!(白目)

 


先輩さんに教えて貰いながらなんとか実装できました。先輩さんがやれば1日で終わるものに5日もかかってしまいました。

先輩さん「まぁ最初はそんなものだよ。これから覚えていってね」

なんと優しい先輩なのでしょう。残念ながらこんな優しい先輩ばかりではなかったりするのが悲しいところです。ちなみに新人というものはプロジェクト内で工数に入っていなかったり0.5人としてカウントされいたりするのでこれくらいの遅れは織り込み済みだったりします。これで気を落とさず頑張りましょう!

続く…

スポンサーリンク

初めてのライトニングトークを終えて

先日こちらでライトニングトークについて書きましたが実際に発表をしてきました。

発表する前は心臓がばくばくいうほど緊張しましたが、実際に発表してみるとなんとかなるもので終わった後におもしろかったよーと言ってもらえたので、やってよかったなと思いました。

なんでこんなに緊張したかというと実は少し前に会社でサークルを立ち上げる際に100人くらいの前でサークルの勧誘トークをしたのですが、いざやってみると緊張してしまい事前に考えていた内容を上手く話すことが出来ずに失敗してしまいました(ただ伝えるだけになってしまった)。

そんな経験からまた失敗するのではないかと緊張しましたが今回は自分でも成功することができましたので当日心がけていたことを紹介したいと思います。

声を大きく出す


なんていうかこれが全てのような気がします。時間的に大した内容を話すことが出来ず、スライドも10枚で1枚に1~3行くらいしか文が書いていないのでいかに伝えるかが勝負だと思いました。

そこで大切なのが姿勢と声の大きさだと思います。特に人前の発表では「聞こえなかった」が一番悲しいので大きな声で自信満々に話しをするよう心がけました。

具体的には最初に言う挨拶を「これから僕の発表を始めます。よろしくお願いします」と決めていたのでこの「よろしくお願いします」を大きな声で言うようにしました。ここで大きな声を出しておくとそのトーンのまま話始めることができると思ったからです。さらにここできちんと挨拶をしておくことで相手に「これから発表する」ということがストレートに伝わり、聞く状態にすることができます。実際何人か発表したのですが、自分だけしっかりと始めに挨拶をしたので拍手がおきました。

実際にこの作戦は上手くいき、はきはきと発表をすることができました。今回「よろしくお願いします」を大きな声で出せた時点でほぼ成功したようなものではないでしょうか?

 

内容は簡潔にして練習あるのみ


スライドの中に文を羅列してそれを読むだけというのはライトニングトークっぽくないと思っていました。5分という短い時間で簡単に言いたいことを言うだけくらいのほうが聞いていてわかりやすいと思ったからです。

自分の順番はちょうど真ん中くらいの発表だったので特に簡潔にして聞いている人を飽きさせないようにする必要もありました。これでもかというくらい内容を簡潔にして、後はトークでなんとかしようと思っていました。この辺は元販売士の経験が活きたと思います。

ただぶっつけ本番はやはり怖すぎるので前日と前々日は自宅で練習しました。時間を計るのはもちろん、ここは抑揚をつけようとかここは特にはっきりととか考えながら構成を練りました。

結果練習をしたことにより自信が生まれ、それが発表時にも現れたと思います。まぁ販売士はハッタリで喋ることもあるのでこの辺も昔の経験が活きたように感じました。

終わりに


ライトニングトークの経験談を聞くとやってよかったと言う人が多いのでほんとうかな?と半信半疑でしたがやはりやってよかったと思います。これはもし失敗していても経験を積めたという意味では機会があればチャレンジするのもいいのではないでしょうか?

全然話をしたことのない他部署の人に「そんなにハキハキ喋る人だとは知らなかった」といわれたのでいい意味でプラス評価になったのではないでしょうか?(普段どれだけ根暗に見えたんだ…)

 

スポンサーリンク