It's okay to be weird

レールの無い道を行くプログラマーのブログ

基本情報技術者試験を受けるべきか

私は情報系専門学校に通っていた時期に基本情報技術者試験を取得したのですが、ITの勉強を積んで、実際にITエンジニアとして働くようになった今、試験に対する見方が変わりました。試験を受けるかどうか、迷っている方の参考になればと思いこの記事を書くことにしました。

私の経験から書いていることなので、鵜呑みにはしない方がいいかと思います。あくまで一個人の意見として参考にして下さい。

結論

まず結論から書いてしまいます。理由については後述するのでそちらを参照ください。

まず、社会人で既にIT業務に既に携わっている方については、基本的に受ける必要は無い と思います。

そして、逆に私が思う受けた方がいいかもしれない方というのは、学生の中で、学歴だけがステータスとして通用しないような学校、 特に専門学校に所属する方 です。

受ける必要が無いケース、受けた方がいいケースについてこれから書いていきます。

受ける必要が無いケース

社会人でIT業務に関わっている方は既に就職をされているわけで、就活目的で資格を取る必要はもう無いのではないかと思います。

それでも基本情報技術者試験のメイン領域であるコンピュータサイエンスの勉強をしたいというのであれば、試験を受けるまでもなく、いい教材がたくさん存在します。例えば本で言うと、コンピュータサイエンス全般では入門 コンピュータ科学 ITを支える技術と理論の基礎知識といった本や、セキュリティでは体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践といった本です。月額1000円で学べるN予備校にはコンピュータサイエンスのコースも存在します。これはほんの一例で、ネットには素晴らしい教材があふれています。

なぜ試験を受けることを勧めないかというと、基本情報技術者試験の教材というのは、試験のための受かるためだけの教材といった感じで、原理や背景を説明せず、ただやみくもに頭に入れるというような本が多いです。試験の範囲が広範囲に渡っていることも原因でしょう。例外として、キタミ式イラストIT塾 基本情報技術者 平成30年度 (情報処理技術者試験)はイラスト豊富で大変解りやすく、試験受験者以外にもおすすめです。

社会人で受けた方がいいかもしれないケースとしては、会社で資格手当てを支給しているような場合や、会社の資格保持者数が案件を任される判断材料になるようなお仕事をされている場合です。そういった方は取得した方がいいかもしれません。

受けた方がいいケース

情報系の大学や、名前だけでステータスとなるような大学に通っている方は別ですが、それ以外の学校、特に専門学校は学歴としてなかなか通用しにくいところがあると思います。そこで資格をきっちり取ることで箔を付けることができます。就職対策として取得するわけです。

また、まともな情報系の大学ではしっかりとコンピュータサイエンスを教えてもらえると思いますが、専門学校では実技を優先してコンピュータサイエンスを疎かにしているところも多いのではないかと思います。その意味でコンピュータサイエンスを広く浅く学べる基本情報技術者試験はいい目標なのではないかと思います。コンピュータサイエンスの勉強というのは、すぐに実践で役に立たない部分も多く、モチベーションを保つのが大変だったりします。そこに試験という目標を用意することで勉強の動機を作るというわけです。

ただ、そうした学校に通っている方も、資格にこだわらず、自分で学んだことを使ってポートフォリオを作成した方が対象とする企業によっては就職に有利に働くかもしれません。志望する企業が業務系なのか、Web系なのかなどによっても変わってくるかもしれません。

あとは、試験を取れたからといって技術者と名乗っていいかというと全然そういうことはない資格だと思います。ただ、広く浅く学ぶことで、あとで実務で関わった時に「ああ、あれのことか」という下地にはなると思います。

まとめ

始めにいいましたが、あくまで一個人の意見です。「僕は取得したいんだ!」という気持ちがあれば是非そうした方がいいと思いますし、取っておいて損はない資格だと思います。ただ勉強するなら代替はいくらでもあるよということを言いたいです。

ご参考にしていただければと思います。

Siriのとても有効な活用方法を発見した: それはリマインダー

今年はブログを積極的に書いていこうと思います。よろしくお願いします。

今日、新発見したことがありまして、まぁタイトルの通りなんですが、Siriでリマインダーを作成するというものです。

元々忘れやすい体質なので、あとでやろうと思ってたことをすぐ忘れてしまうんですよね。日々のタスク管理にはTodoistを使ってはいるし、「忘れるようなことは大事でないこと」とも言いますが、あとで「あれやるんだったー」となることも多いです。映画を観ている時にぽっとやることが浮かんだりもするんで、そういう時は頭を空っぽにして集中するためにもさくっと入力したいものです。

そこで、いっそ自分で入力簡単で超シンプルなTodoアプリを作ってしまうかとも考えたんですが、思いついたのが「あれ、Siriで入力すれば即入力できるし、標準のリマインダーと組み合わせれば最強じゃね?」というものです。

やり方としては「○○をリマンド」と入力すればオッケーです。例えば「PHPのexplodeがどんな関数か調べるをリマインド」みたいな感じです。

実際に試したのですが超いい感じです。僕はApple Watchでやってますが、外部と通信してるSFのエージェントっぽくていい (かもしれない) です。欠点は音声入力なので外でやるのがちょっと恥ずかしかったり、声を出せない場面だと難しいことでしょうか。

スマートスピーカー全盛で音声入力時代の幕開けのご時世です。皆さんも試してみてはいかがでしょうか。

追記: 運用方法を改善できた

標準アプリからTodoアプリへ

ブログ記事を書いた後、monoさんから以下のリプライをいただきました。

ブログを書いた時点では標準アプリにしかタスクを作成させず、標準アプリにはバッジ機能がないため見返すのを忘れる恐れがあったのですが、真似をして自分のTodoistでも取り組むようにしてみました。OmniFocusと違いTodoistにはそのような機能はありませんでしたが、IFTTTにレシピがあったのでそれを使いました。

やってみるとなるほど快適です。アイディアをいただいたmonoさんに感謝です。

入力は最低限に

音声入力の精度は上がったとは言え、まだまだ正確に聞き取ってくれません。前回の記事では「PHPのexplodeがどんな関数か調べるをリマインド」という例を取りましたが、これではぐちゃぐちゃになる可能性大です。そこで「ピーの爆発を調べるをリマインド」と単純化します。すぐに見返すタスク用にTodoを作るので、思い出せればオッケーという方針です。 まとめ

しばらく使ってみての運用方法を紹介しました。ライフチェンジングとまではいかないですが、なるべく脳を空っぽにするという姿勢を保つのにいい技です。皆さんもいかがでしょうか。

『テスト駆動開発』を読んだ

去年末から読み始めていた『テスト駆動開発』を読み終えました。原書は古いとはいえとても新鮮な体験が出来ていい本でした。

テスト駆動開発

テスト駆動開発

情報

Kent BeckによるTest-Driven Development by Example (2003) を和田卓人氏が訳した新訳版。TDDを忠実に実践しようとしているわけではないですが、ユニットテストを書く仕事を任せられており、参考になりそうなので読み始めました。

第I部、第II部で実際にTDDを実践しながら少しずつコードを書いていく例を取り、第III部でベストプラクティスを学ぶ本となっています。また、新訳版では和田卓人氏によるテスト駆動開発の現在について書かれた付録Cが追加されています。

感想

和田卓人氏もおっしゃってますが、写経をしながら第I部、第II部を読み進めることで本領を発揮する本だと思います。コードとは最終的なアウトプットが評価されるものではありますが、それが生まれる過程を追体験できるからです。

第I部、第II部で実践したあとでベストプラクティスを学ぶという構成がいいと思いました。やっぱ手を動かさないとプログラミングは身につかないものです。

あとは元はJavaPythonで書かれた例コードをPHPで写経しながら書いたのですが、元々がJavaプログラマーだったせいかPHPだとどう書けばいいか解らない場面も多く、特にキャストや、引数・戻り値の型指定など、動的型付けの部分に慣れていないせいで戸惑ったもののPHPそのものの勉強になりました。

もはや固有名詞となった「付録C」にも書かれていますが、教条主義的になってしまった面もあるTDDの目的とはそもそも、より良く設計されたコードを生み出すため、小さく自信を持って進めるための手段でしかないということが大事だと思います。TDDそのものが目的となってはいけないのだということでしょう。これはどんなプログラミング手法にも言えるのではないかと思います。よりよい成果物を生み出せるよう、最適な手法を取捨選択できるようになりたいと思いました。

リンク

テスト駆動開発

テスト駆動開発

グッドバイ2017、ハロー2018

毎日特に何をするでもなく寝てばかりいたら、あっというまに年末年始休みが終わろうとしています。まぁたまには生産性も何もないこんな休みもいいかなと思っています。

2017年

とりあえず2017年の振り返りが出来ていないのでそこからします。

会社

1年少し勤めた初めての会社を2月末に辞め、間にもう1つの会社を渡り、最終的に今の会社に10月終わりに落ち着きました。まだアルバイトの身ですが、ようやく活躍できそうな「場」を与えられた感じがするので、あとはそこで力を発揮できるよう努力していきたいと思っています。

勉強

勉強的にはこの辺をやってました。

この中でも読了した数でいうとたった5冊なので、やっぱ足りてないですね。最低でも1ヶ月に1冊ぐらい読んでいきたいです。

ただ、就職前に数学やデータベース、アルゴリズムとデータ構造といった基礎的なところを勉強できたのは有意義だったと思います。

趣味

趣味でいうと、ライブによく行った年でした。数えてみたら合計13回も行っていたようです。引き続きライブはどんどん行きたいですね。ライブって、当日までは「その日まで頑張ろう」、終わった後は「次のライブまで頑張ろう」という気にさせてくれる本当にいいものです。

そして、新たな趣味としてコーヒーが加わりました。豆から挽いて毎朝飲む習慣ができました。朝が苦手な自分にはいい贅沢が出来ていい感じです。

2018年

勉強

まずは仕事で必要とされるスキルを最優先に身につけていきたいです。主にWeb開発全般とPHP周辺ですね。コードリーディング力が足りてないことを実感したのでそこも埋めていきたいです。あとはN予備校のプログラミングコースでWeb開発を体系的に学び直し、抜けを無くしていこうと思います。

趣味

ギターをやるかやらまいか、上達を考えてやろうとするとキツいので迷いましたが、ストイックに向上を目指すのは技術だけに絞ろうと思い、週末にコードをジャガジャガかき鳴らして気分良くなれればいいやぐらいな感じでとりあえずはやっていくことにしました。仕事が落ち着いたら弾き語り教室でも通ってガッツリやってみたいなーとは思ってます。

あとは体力の無さを実感しているのでランニングの習慣をつけたいです。寒さが和らいだらサイクリングもまた色んな場所に行きたいですね。

まとめ

勉強は毎日コツコツやりつつも、週末は思いっきり遊ぶ。そのメリハリをつけていく年にしたいなーと思っています。

乗り遅れただけ乗り遅れた人生なので、使える時間を全部使って息切れするまで勉強しまくって一発逆転を狙おうなんて思うこともたまによくありますが、自分はそんなにタフじゃないし、人生は他人との競争ではないと思うし、自分なりに成長を少しずつ重ね、毎日を楽しく生きて行けたらいいなーと思います。

数学好きの皆さん、Software Design 2017年12月号の特集が「ITエンジニアと数学」ですよ!

今日 (2017/11/18) 発売のSoftware Design 2017年12月号が数学特集です。

Software Design 2017年12月号|技術評論社

下のような記事を書いた僕としては、買うしかないわけで。即購入、一気に読み通しました。 tkykhk.hatenablog.com

感想

感想はScrapboxに書いてるので興味があれば読んで下さい:
Software Design 2017年12月号 数学特集 - トミー - Scrapbox

まとめると「手を動かすこと大事!」ですね。

オンラインコミュニティ欲しい

感想の中でも書いてますがオンラインの数学コミュニティ欲しいなーと。数学の独学って詰まるからけっこうきついんですよね。

主催者になったりするのはそういう経験ないんでアレですけど誰かやってくれるならお手伝いとかしたいところ。誰かやってくれないかなー (チラッ)。

必読

ともかく。数学に興味のあるITエンジニアの皆さん、必読 ですよー。

Software Design 2017年12月号|技術評論社

32歳にしてWebプログラマーとしてやり直すことにした

3ヶ月ぶりのブログ更新です。自分の状況に変化が起こったのでお知らせしたいと思い、記事を書きました。

これまで

僕は高校を中退して長い空白期間のあと、25歳で情報系の専門学校に入学し、2015年に29歳で卒業してから会社を2社渡り歩きました。1社目は開発者が2人だけのプロジェクトに配属されたあと、リーダーが辞めてしまい、1人で後始末を任されるという状況に耐えられなくて辞めました。そして、2社目は零細が故に開発の仕事をやらせてもらえなかったうえ、給料面で折り合いがつかず辞めました。

どちらも次の転職先を見つける前に辞めてしまったので、その間はコンビニのバイトをしながら食い繋いでいました。Twitterなどのプロフィールにプログラマーと書いていましたが、実際はコンビニ店員だったわけです (心はいつもプログラマーですが)。

そんなこんなで、次はどうするかと考えながらレジを打ったり検品したりしていたわけですが、ここはいきなり高いところを目指すよりは、しっかり地に足を着けて、エントリーレベルの求人を探した方がいいのではないかと思いました。それも正社員ではなく、アルバイトという条件で探すことにしました。そうすることで、立場は低いものの、先輩方に教えてもらいながら働けるのではないかと考えたのです。30を過ぎて未だにバイトというのも少し悲しくなりますが、高校を中退してから散々レールを外れて生きてきたのだから、今さら焦る必要はないと思いました。

もう1つの条件として、Webの会社にしようというのがありました。学校を卒業する以前はAndroidiOSの勉強をしたり、モバイルアプリ系の仕事がしたいと思っていたのですが、結局モバイルアプリだけで収益を上げられるのはほんの一握りの会社で、Webこそ堅実なのではないかと思ったのです。

そして、学生だった頃からネット上で交流があり、関東にライブで遠征した時には実際にお会いしたこともある、くもキャストというポッドキャストをホストされているがみさんたちがWebの世界に生きていることもあり、せっかくそういう縁があるのだから自分もWebをやろうじゃないかと思ったのです。

あとは最近、なむさん黒澤俊文さんといった、同じ30代にしてWebエンジニアの世界に踏み込んだ方に刺激を受けたのも大きいです。

そうして条件が決まったので求人を探してみると、まさに先輩に学びながら働けると書いてあるうえ、労働環境もよさそうな会社が見つかり、早速応募、先週無事に内定をいただきました。

現在

Webで行くと決めたので、今まで数学やアルゴリズムなどの基礎的な勉強をしていたのですが、仕事に直結するWeb開発周りの勉強を始めました。

今はfreeCodeCampというインタラクティブにWeb開発を学べるサイトで、"Front End Development Certificate"という修了書の取得を目的に勉強中です。これは指定されたJavaScriptアルゴリズム問題と、HTML/CSS/JavaScriptのプロジェクトをいくつか完成させることで取得できるものです。プロジェクトベースなのが実践力をつけるためにかなりいい感じです。ちなみにプロジェクト用に作ったものはCodePenに置いています。

これから

freeCodeCampでフロントエンドの勉強はしつつ、セキュリティは重要なので、まずは徳丸本を読もうと思っています。そのあとは、ES6も含めたプレーンJavaScriptを抑えつつ、React / Redux、Vue.jsなどにも触れ、freeCodeCampのバックエンドに移っていこうと思っています。会社で扱っているのが主にPHPなので、その勉強も必要ですね。

Webって本当に勉強しなきゃいけないことが多いけど、それだけにやりがいのある世界だと思います。焦らず1歩1歩、力を付けていきたいと思っています。

『Clean Code』を読んだ

達人に学ぶDB設計 徹底指南書に続き、言語やフレームワークに依存しない本として何か読みたいと思い、評判の良さを以前から聞いていた『Clean Code』を読みました。なかなか読み応えのある良い本でした。

日本ではリーダブルコードがよく新人にお勧めする本として挙がりますが、redditの開発系subredditなどを読んでいると、海外ではリーダブルコードの名前が挙がることは少なく、代わりにこのClean Codeの名前をよく目にするような気がします。内容としては読みやすい = 綺麗なコードの書き方ということで似ているのですが、Clean Codeは日本では訳書が絶版になってしまっていることが影響しているのか、あまり広く読まれていないようです。

(2018/01/24 追記)
訳書が2017/12/18より再出版されているようです。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

構成としては、1〜13章が本編、14〜16章がバッドコードをリファクタリングするケーススタディ、17章がコードの臭い・ヒューリスティック集となっています。

どういう本か

序文で、近代建築の巨匠であるミース・ファン・デル・ローエの「神は細部に宿る」という言葉を引用し、ソフトウェア開発では細部にこだわることが重要と言っています。また、この本は読んだだけで"feel good"にしてくれる本ではなく、Clean Codeを書くのは”hard work”であると述べています。例となるコードがたくさん含まれており、頭に入ってきやすいように作られています。

以下、特に印象に残ったことを章ごとに箇条書きで書いていきます。Scrapbox読書メモを残しているので、さらに読みたい方がいたらそちらを読んでいただければと思います。

Chapter 1: Clean Code

  • 最近は人工知能の躍進が著しいので、やがてプログラマーの職も奪われるのではないかと危惧している人もいるのではないかと思いますが、この本では、「人間でさえ顧客の曖昧な仕様をシステムに落とせないのだから、機械がコードを勝手に作ってくれるようになるなんていうのは幻想。もしそうなったとしたら、今度は仕様書がそれだけ形式的になるというだけ」と述べており、なるほどと思いました。
  • マネージャーにバッドコードを放っておかないよう伝えるのはプログラマーの務め。バッドコードを放っておくのは、医者が手術をする際に時間がかかるからといって手洗いをしないのと同じ。
  • 「この本は柔術の流派の1つを教えるようなもので、絶対的に”right”であるとは考えないで欲しい」と言っていますが、確かに著者の得意とするJavaアジャイルの文化が色濃く反映されているので、全てを鵜呑みにする必要はないと思いました。

Chapter 3: Functions

  • 関数の最初のルールは小さくあること、2番目のルールはさらに小さくあること。
  • 関数の長さは20行を超えるべきではない (異論が挟めそう)。
  • Kent Beckの視覚効果を画面に出すJava/Swingプログラムを見せてもらったら全ての関数が2〜4行に納まっていた。
  • 文章を推敲するように、まずは汚く書いて徐々に綺麗にしていく。その際にテストコードをまず書いておき、改良したあともテストが通るようにすると良い。

Chapter 4: Comments

  • コードの表現を補わなければいけなかったという意味でコメントは常に"failure"である。
  • コメントはメンテナンスされずにいると正確性を欠くようになっていまう。コードだけにしか真実は表されていない。

Chapter 5: Formatting

  • 新聞には見出しがあり、最初の段落であらすじが書かれ、次に詳細が書かれる。ソースファイルも同じように名前は簡潔かつ明瞭で、上部に高レベルな概念とアルゴリズム、下部に低レベルな関数と詳細が書かれているべき。
  • かけ算、割り算の演算子は1*2のようにひっつけて書き、足し算、引き算の演算子は3 + 4のように離して書くと優先度が分かりやすい。

Chapter 6: Objects and Data Structures

  • オブジェクトはデータを抽象化の背後に隠蔽し、公開された関数を通してデータを操作する。データ構造はデータを公開し、意味のある関数を持たない。
  • 手続き型コード (データ構造を使用するコード) は既存のデータ構造を変更することなく関数を追加することが容易。オブジェクト指向コードは既存の関数を変更することなく新しいクラスを追加することが容易。
  • 手続き型コードは全ての関数の変更が必要なため、新しいデータ構造を追加することが困難。オブジェクト指向コードは全てのクラスの変更が必要なため、新しい関数を追加することが困難。
  • 全てのものがオブジェクトというのは神話でしかない。時にはシンプルなデータ構造と手続きが必要なときもある。

Chapter 9: Unit Tests

  • 3つのことがテストを綺麗にする。それは可読性、可読性、可読性である。テストコードではプロダクションコードより可読性が重要とも言える。

Chapter 10: Classes

  • クラスのサイズを測定する際、行数ではなく責任 (responsibilities) によって測定する。
  • 70個のpublicメソッドを持つクラスを5個に減らしたからといって、責任が減るというわけではない。
  • SuperDashboardのように、Super、Processor、Managerといった名前のつくクラスや、"if"、"and"、"or"、"but"のような言葉で繋げなければ説明できないクラスは責任の多さを示唆している。

Chapter 15: JUnit Internals

感想

「そうなのか!」という驚きというよりは、「ふんふん、そうだよね」という感じが多かったです。ある程度、開発経験を積んだからかもしれません。

ただ、「どこまで当たり前のことを当たり前にやれるか」ということが開発をする上で大事なことのように思います。一度サボりだすと雪崩を打って、割れ窓理論で言われるように全てが崩壊してしまうものだと思います。そこのところを注意しつつ、最初から完璧に綺麗なコードを書こうとせず、初めはダーッと書いて、まとまったところですぐにリファクタリング、の繰り返しをしていくのがいいのではないかとこの本を読んで思いました。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技