濃縮ソフトウェアエンジニア研修：職務プログラミングで重要な心構え+お勧め書籍
はじめに
この記事の目的は、新しく職務としてプログラミングをすることになった人に、一生忘れないでほしい考え方や姿勢を身につけてもらうことです。
ソフトウェア開発で気をつけるべきことは細かいこと言い出すとキリがないですが、これぐらいは開発者全員が心と体に叩き込んでおいて欲しいという内容を凝縮してあります。
職務プログラミングの趣味プログラミングとの違い
まず、職務でプログラミングをすることは、趣味（や学校の課題や研究室で論文のために作るものも含めて）でプログラミングすることは全然違うという話です。
趣味プログラミングの特徴
趣味プログラミングは、自分のためのものなので、やりたい放題
- 自分で作りたいものを決める
- 自分で作る
- 自分で使う（運用する）
- エラーで落ちたりフリーズしても、データや動作環境をいじってやりなおせばよい
- 自分で作り直す（直さないのも自分の勝手）
職務プログラミング
プロダクトやプログラムは、組織（会社やプロジェクトチーム）のために存在し、自分のものではない
- 他人(経営者、プロジェクトオーナー)の作りたいものを作る
- だから、対価として給料がもらえる
- 他人と（場合によってはチームや会社の垣根を越えて）強調して作る
- 大きな成果を期限内に作るためには多人数でやる必要がある。ビジネス的な価値や責任も大きくなる
- 他人がそのプロダクトを使う
- 簡単にフリーズしたりエラーで落ちたりしてはいけない
- 他人が運用する（してくれる）
- 自分には休日がもらえることになる。問題が起きた時に自分しか対応できないときついよ
- 他人にテストされ、ソースを読まれ、バグを発見され、修正される（してもらえる）
職務プログラミングにあたっての心構え
- 何を作るべきなのか（必要十分な機能）、自分の担当範囲を明確にしておく
- 限られた時間と人数で成果を上げる必要があるので、余計な機能を勝手に追加しないこと
- エラー処理をどれぐらい丁寧にやるべきかを明確にしておくこともわりと重要
- 開発の終盤で作り漏れに気づくと締め切りを守れなくなるので、漏れもないように気をつける
- いつまでに開発終了させるべきか、間に合わなさそうになったどうするべきかを把握しておく
- ビジネスにおいて時間や時期は最重要事項なので、進捗によってプロジェクトの変更（締め切りを伸ばす、機能を減らす、仕事の分配を修正する）の判断に迫られる
- 判断のタイミングが遅いと取り返しがつかなくなる。間に合わなさそうなものを一人でなんとか頑張ったけど挽回できなかったというのは最悪。できるだけ予兆の段階で報告すること
- 開発の成果物（プログラムやデータ、ドキュメント）をきちんと管理する
- 運用の手間を減らすようにUI設計を工夫する
- 何十年間も無駄な運用コストが発生することにもなりかねない
- テストしやすいよう設計、プログラミングする
- プログラムを他の人に読んでもらいやすいように書く
- プログラムを修正しやすいように予め構成しておく
どう設計すればいいか
テストやデバッグ、修正が簡単になるようにしましょう
- 重複を避ける
- 重複箇所にバグがあったり修正が発生した場合、テストやデバッグの手間が倍になる
- 機能のはっきりしたコンポーネント、クラス、関数に分解しておく
- 関係あるものをまとめる/関係ないものを分離する
- 意味的/機能的に（あるいは他の合理的な指針で）、階層構造/木構造になるように構成する
- 分割したもの同士が必要以上に影響し合わないようにする
- 余計な依存をなくしたり、一方通行にする
- 例：関係するモジュール(とかクラスとか関数)A0とB0がある場合
- AをA1に取り替えようとするとBも変更しなければならず、BをB1に取り替えようとするとAも変更しなければならない→よくない
- AをA1に取り替えようとするとBも変更しなければならないが、 BをB1に取り替えようとしてもAはそのままでよい→よい
- AもBもそれぞれ独立に代替物に取り替えれる→とてもよい
よい設計が出来るようなるための参考書籍
- アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者: ロバート・C・マーチン,瀬谷啓介
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/07/01
- メディア: 大型本
- 購入: 18人 クリック: 586回
- この商品を含むブログ (71件) を見る
- 新装版 リファクタリング―既存のコードを安全に改善する―
リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
- 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2000/05
- メディア: 単行本
- 購入: 94人 クリック: 3,091回
- この商品を含むブログ (312件) を見る
- とてもよい本。
どうすれば良いコードになるの？
〜名前編〜
変数名、関数名、クラス名、ファイル名などに気をつけましょう
- 名前で中身がわかるようにする（変な名前をつけてコメントで説明したりしないこと）
- 駄目な名前 x、u （ループ変数のようなちょっとしたローカル変数ならOK）
- 良い名前 user_id、uid （コード以外でも使われる略語はOKだが独自略語は避ける）
- 命名方針を統一する
- convert_to_eucとかconvertToUTF8とかconv2sjisとかを混ぜない
〜見栄え編〜
読んでもらいやすく、修正しやすいプログラムを書く
- 重複を避ける
- 読む量が増えるし、同じっぽく見えて微妙に違うのかなとか無駄な混乱が起きる
- 出来る限り短くする
- 分かりにくくならない範囲で、行数も１行の文字数も減らすこと
- 構造を見た目で表す
- きれいにインデントする
- 必要十分な空白を入れる
- 必要十分な括弧を入れる
よいコーディングのためのキーワード
- コーディングスタイル
- 防御的プログラミング
- 各言語の仕様を読むこと
- 言語の機能の意義を理解すること
コーディングのスキルアップのための参考書籍
- CODE COMPLETE 第2版
- 作者: スティーブマコネル,Steve McConnell,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2005/03/26
- メディア: 単行本
- 購入: 44人 クリック: 1,166回
- この商品を含むブログ (288件) を見る
- 上級プログラマーを目指している人には手元に置いておいて何度も読み返す価値のある本。ただし、量が多く文体も硬いし難しいので、いきなり読むと挫折するかも。ある程度の経験を積んだ後の方が内容が身につきやすいと思う
- リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (126件) を見る
- CODE COMPLETEを読めば結局は要らない気もする
- モチベーションの低い人にもとりあえずお勧めできるぐらい読む量が少なくて文体も軽いので、とっかかりとしては良い
- Code Craft ~エクセレントなコードを書くための実践的技法~
Code Craft ~エクセレントなコードを書くための実践的技法~
- 作者: Pete Goodliffe,後藤正徳,鵜飼文敏,平林俊一,トップスタジオ,まつもとゆきひろ
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2007/11/29
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 216回
- この商品を含むブログ (82件) を見る
- コーディング以外の話も出てくる部分がためになる
時間・タスク管理もしっかり
ソフトウェア開発は、試行錯誤の繰り返しで、人によって作業効率もぜんぜん違う。
作るべき内容が途中で変更されることもしばしばある。
計画当初の通りに進むことはまずない。
→ 個人でも、時間管理とタスク（の優先度）の管理が超重要になってくる。
時間管理力アップのための参考書籍
- 作者: Thomas A. Limoncelli,株式会社クイープ
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/10/19
- メディア: 単行本（ソフトカバー）
- 購入: 11人 クリック: 322回
- この商品を含むブログ (153件) を見る
おまけのアドバイス：英語も勉強しよう
余力があれば（というか余力のある今のうちに）英語の勉強をしましょう。ソフトウェアの技術や文化はほぼ全て英語に基づいています。英語力があると、適切な関数名・変数名を付けるといった細かい話から、最先端の技術を身につけたり、海外出張に行ったり、転職したりといったエンジニア人生に関わる大きな話まで、色々な点でとても有利になります
あとがき
先輩面したようなことを書いていますが、自分もまだまだ理想のエンジニアにはほど遠いので、これからも頑張り続ける所存です。
理系IT系就活で全然自信がなかったからこそ面接に成功したと思える当時の心構えと今の考え
特に、理系の人やエンジニア志望の人はスキルがあっても口下手で面接が苦手って自分で思ってる人も多いと思うので、そういう人に参考にしてもらえたらと思って書きました。
就活当時の話
人に自慢できる学生時代のエピソードもなかったし、全く内定をもらえる自信がなかった。
基本的に「どこも受からなさそうな気がするし、落ちたら落ちたでいいや」と思っていた。
「ひょっとしたらここは受かりそうだから自分をよく見せておこう」とか微粒子レベルにも考えてなかった。
面接1社目で流れを経験した後は、完全に吹っ切れて、気負うこともなく、全く緊張しなくなっていた。
「エンジニアをちゃんと評価してくれる会社とは？」が就活時の一番の関心事で、面接官がどうやって良いエンジニアを見抜くのか興味があったので、面接中は「さて、お手並み拝見〜♪」と考えていて、面接官の質問はじっくり聴いた上で、素直に気楽に答えていた。
ある面接では、面接官の方が緊張していたみたいで「なんでそんなに余裕で自信満々なんですか！？」と聞かれた。
上記のことをぶっちゃけてしまうわけには当然いかないので「普段通りの自分を見てもらった方がいいと思って、自然体で話すように気をつけています」と、焦りつつ取り繕う場面もあった。
面接は、面接官が就活生を評価する場でもあるけど、半分ぐらいは就活生が会社を良く知るための場でもあると思っていたので、社会見学のノリでこっちの知りたいことはズバズバと（しかし失礼はないように）質問した。
こういう受け答えは、面接官からは自社に対する興味とか積極性と感じてもらえたような気がする。
運とか色々な要素があったと思うけど、大体の会社は最終面接まで行けて、いくつかの会社はこちらから次の選考を辞退した。
最終的に「この辺に受かれば就活は成功かな」と就活開始時に考えていた会社から内定がもらえた。
まとめに、あえて方法論として名前をつけるなら「どうせ落ちる面接なら楽しんだ方が勝ちメソッド」？
ちなみに、Wordで作った履歴書を印刷して提出していた会社の面接は落ちた（他の会社は手書き）ことを、こちらの記事を読んで思い出しました。
履歴書はちゃんと手書きで書こうよ、就活生クンたち！
今の話
ここからは、IT系（というかWeb系）のエンジニア志望の人向けに特化した自分の意見なので、興味ある人だけ読んでいただければと思います。
今、IT系のエンジニアとして働き続けていて、後輩もいる状況で考えてみると、エンジニアってコミュ力がそんなに高い必要はないかなと思います。
上司も社長も友達感覚で会話してもらえるので、一流マネージメント職を目指すのでなければ、友達と普通に社会生活が送れるぐらいのコミュ力で十分です。
今でも面接を特別に頑張る必要はなかったと思っていて、就活で具体的に評価されたポイントは、ソフトウェア開発のための勉強を一通りはやってたことと、自分でWebサービスを作って研究室のサーバーで公開していたことかなと思います。
そのWebサービスは、商店街や街角の街灯の写真をアップロードして地域ごとに整理して楽しめるという超ニッチで自分しか見てなかったんじゃないかという、全然大したものではないです（今考えるとレベルも内容も謎過ぎて、恥ずかしい）。それでも、作品があるとないとでは雲泥の差です。
エンジニアのコミュ力がどれだけ高くても技術力がしょぼければ良い製品は完成しないので、自分が面接官をするときには、同じように評価したいと思います。
エンジニア志望のみなさんには表面的な面接対策をするのではなく、こちらの記事に書いた通りプログラミングの基礎を身につけることと作品制作をお勧めしたいです。
この本を読んで実践できてたら新卒の応募者としては完璧レベルで、面接がよほど酷くない限り、即採用したい。読んで理解できてるだけでも候補には残したい。
良いコードを書く技術 ?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)
- 作者: 縣俊貴
- 出版社/メーカー: 技術評論社
- 発売日: 2011/04/09
- メディア: 単行本（ソフトカバー）
- 購入: 46人 クリック: 2,459回
- この商品を含むブログ (68件) を見る
あと、面接などの服装で「カジュアルな服装でお越し下さい」と書かれているのに、わざわざスーツ着てくるのやめてねw。部下やチームメイトは、指示には素直に従ってくれる人でないと困るのよ〜
就活生の皆様の健闘と幸運を祈ります。
では。
おまけ
知り合いになった人が書いた記事がヒットしているクックパッドとヤフーの開発者ブログの人気に嫉妬しつつ就職先としてお勧めしておきます。転職しようかな
就活生がITエンジニアを目指す前に伝えておきたい業界の真実と現役エンジニアからのアドバイス
はじめに
日本のIT業界では、技術職求人に対して、ちゃんと専門教育を受けていない（独学で身につけたわけでもない）人の応募の割合がとても高く、絶大なる不幸を生み出しているのが現状です。
これから社会人になる就活生の皆さんには、できれば不幸な人生ではなく幸せな人生を歩める選択をしてほしいとの願いから、このエントリーを書きました。
注意：ITエンジニアとして就活をしてプログラマー的な仕事が主な業務になる人が多いと思うので、この記事に出てくるITエンジニアという言葉は、プログラマーのことだと思って読んでいただけると幸いです。広い括りの題名をつけてしまってすみませんが、インフラ/ネットワークエンジニアやメーカーのエンジニアの話は出てきませんので、ご容赦ください。
目次
- 背景
- プログラミング言語を覚えよう
- データベースの使い方を覚えよう
- オリジナル作品を作ろう（ここが一番大事）
- IT系の勉強会に参加しよう
- GitHubで自分のプログラムを公開しよう
- インターネット上に自分のソフトウェアを公開しよう
- 自分がプログラマーに向いているかどうか判断しよう
- アマとプロのプログラミングの違いを知っておこう（二番目に大事）
- 個人的にオススメな応募先
背景
プログラマーの適性（向き不向き）の差は、他の職種よりも非常に大きいです。
『ソフトウエア開発 55の真実と10のウソ』に書かれている調査によると、向いていない人は、向いてる人と28倍も生産性が違うという結果が得られたそうです。同じ仕事をこなすために何倍もの時間がかかったり、作った物のクオリティも何倍も低い（バグが多いなど）ということです。
仮に、向いていない人が職業としてのプログラマーになったら、どうなるでしょうか。
他の人と同じように仕事が与えられれば、向いていない人は、深夜残業を毎日して徹夜も普通という生活を強いられることになりかねません。その上、仕事のクオリティも低ければ、給料アップの望みもないでしょう。
最近は、ブラック企業が社会的に大きな問題になっています。ブラック企業のやり方はもちろん問題なのですが、あなた自身でブラックな状況を作ってしまうことも有りうると認識しておいて下さい。
まともに利益を上げてまともに社員に給料を払う気がある会社なら、適性によって生産性が何倍も違う職種の採用で「プログラミング未経験者歓迎」と本当に思っているわけがないことを理解しておきましょう。適性のない人を採用したら、納期を守るのも難しくなってしまいますし、残業代も沢山払わなければいけなくなってしまいます（払ってもらえればマシなんですが）。「未経験でもプログラミングができるよう教育します」といううたい文句の会社も沢山あります。教育されればプログラミング言語の一つぐらいは文法を覚えて書けるようになるかもしれませんが、第一線で活躍できるレベルは全然別物です。最低限はできるけど向いてない人を丁寧に面倒見てくれるほど余裕のある会社はあまりないでしょう。もし、未経験（とか、ほぼ未経験）でエンジニア採用されることが普通な会社に入社したら、相当の修羅場を覚悟した方がいいですよ。
あと、日本の大学の情報なんとか科でちゃんと勉強せずに生ぬるく卒業してITエンジニア人生を安泰に送ろうと思っている人も危ないです。
念のために言っておくと、パソコンの使い方やインターネットに詳しいとか、エクセルがちゃんと使えるとかはプログラミングの適性とあんまり関係ないです（必要なスキルではあります）ので、そこを勘違いをしていると後で苦労します。
そうならないために、ソフトウェアエンジニアを目指すと決める前に最低でもこれぐらいやっておいた方が良いことをあげておきますので、実践した上で応募を検討してみてください。
プログラミング言語を覚えよう
何かを作って適性を見ようというのがこのページの趣旨なので、プログラマーの向き不向きが分かる前にくじけてしまわないように、初心者が手っ取り早く自分の作りたいものを作れるようになる言語としてPHPで話を進めたいと思います（プログラマーになる決意の固い人は、RubyとかPython、ScalaあるいはiPhoneアプリ作りたいならSwiftとかをじっくり勉強した方がいいかもしれません。こっちができた方がイケてる会社の面接では受けがいいと思われます）。
作る内容によりますが、PHPが多分一番簡単にWebサービスを作れます。
ちゃんと勉強すれば他の言語にも応用が利く知識が身につくと思います。
PHPの勉強は、書籍やWeb上のチュートリアルを参考にしてください。
[asin:B00JA179KY:detail]
（ここに挙げる参考書・サイトは一例なので、なるべく自分にあった参考書を探してください。以下同様）
データベースの使い方を覚えよう
現実的なプログラムでデータベースを使わないものはまずないので、データベースも基本知識として必須です。
データベースも色々ありますが、無料で使えて、PHPと合わせて開発しやすいMySQL（マイエスキューエルと読みます）をお勧めしておきます。
MySQL公式サイト MySQL
Web上にたくさん解説記事がありますし、上記のPHPの書籍でMySQLの使い方も解説されているので、一通り勉強するにはちょうど良いと思います。
[asin:B00JA179KY:detail]
オリジナル作品を作ろう
さて、ここが一番大事なところです。
教科書や書籍、参考サイトに書いてある通り作るだけなら誰でもできてしまうことなので、向いてるかどうかは判断できません。本当にそれができるというには怪しいところです。
自分の作りたいものを考えて、オリジナル作品を作りましょう！
斬新である必要はありませんし、独自性も高くなくて構いません。
教科書や書籍に書いてあった通りに作ったというのでなければOKです。
色を変えただけとかはダメですよ^^;
見た感じツイッターっぽいものを中身は自分で考えて作るといった程度のことです。
少しで良いので、そのサービスが魅力的であるために自分なりの工夫を入れましょう。
実際に自分で作ってみると、分からないことが沢山あったり、エラーがいっぱい出てどうすればいいか分からなくなってしまうと思います。
そこで諦めずに、本や検索で調べたり、詳しい人に聞いたりしてください。
後述の勉強会に参加して、教えてもらうのもよいと思います。
そういうことがソフトウェア開発現場での仕事です。
（作ろうとした機能が意外と難しい場合は部分的に削ってもいいので）
とにかく完成させましょう！
IT系の勉強会に参加しよう
この業界はオープンな勉強会がよく開催されていて、いろいろな会社からモチベーションの高い現役のエンジニアが参加しています。
無料のものが多いですし、懇親会があったりして、公式の会社説明会では聞くことができない（それよりももっと重要な）現場の生の情報を聞けるので、参加しない手はないです。企業が主催の勉強会は、主催側の話を鵜呑みにするのではなく、参加者の先輩エンジニアからも話を聞くように注意しましょう。
IT系勉強会を検索できるconnpassやATEND、dots.などのサービスで勉強会を検索してみてください。
何を選ぶにしろ、三、四回ぐらいは行った方がいいと思うので、ここでは具体的にオススメは挙げません。
なんでも良いので、なるはやで入門的な名前が付いているものに行ってみて、知り合った人にオススメを聞いてみてください。
GitHubで自分のプログラムを公開しよう
最近は、採用面接でエンジニアが面接官になり、実際に自分の書いたコードについて話をすることも多いです。
その場でコードを書く面接も増えています。
GitHubは、共同開発できるようにプログラムを管理・共有するためのサービスです。
ここにプログラムをアップロードしておくと他の人に見てもらえるようになります。
確かにプログラムをかけるということの証拠になりますし、GitHubのアカウントを持っていることが応募の条件という会社すらあります。
逆に他の人のプログラムを見て参考にすることもできますので活用しましょう。
GitHubなどを利用して自分の書いたコードをきちんと管理することはプロとして必須スキルなので、コード管理はなるべく早めに身につけましょう。
使い方は、
などを参考にしてください。
エンジニアがコードを見る面接の場合は、プログラムのクオリティも審査されると思いますが、こちらの本を参考にして作り方にもある程度の工夫がしてあれば、申し分ないです。
良いコードを書く技術 －読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)
- 作者:縣 俊貴
- 発売日: 2011/04/09
- メディア: 単行本（ソフトカバー）
インターネット上に自分のソフトウェアを公開しよう
インターネット上に自分の作品を公開しておけば、採用担当の人事の方に見てもらうこともできます。
これはとてもよいアピールになるので、エントリーとか初期段階で落とされなくなると思います。
自分でサーバーを持っていなくても、無料でインターネット上に作品が公開できるherokuというサービス（ヘロクと読みます）があります。
Cloud Application Platform | Heroku
使い方は、
などを参考にしてください。
自分がソフトウェアエンジニアに向いているかどうか判断しよう
まずは、オリジナル作品の作成や公開の作業が楽しい・やりがいがあると思えたかどうかが、最低限のプログラマーの向き不向きの判断基準となります。
自分の作りたいものを作ったはずなので、この作業があまり楽しいと思えなかったのなら、プログラマーには向いていません。仕事だと、自分が作りたいものを作らせてもらえるとは限りませんし、くだらなくてつまらなくて苦痛な作業もあるので、モチベーションは続かないでしょう。
この基準をクリアしたとして、ちょっとだけ向いてるのか、すごく向いてるのかを短期間で判断するのは難しいですが、プログラマー職に応募する意味があるレベルだと思います。やる気と時間の余裕がある人は、プログラミングのコンテストに出てみたりするといいと思います。
アマとプロのプログラミングの違いを知っておこう
採用ページとか説明会ではよく分からないと思いますが、実際のプログラマーの仕事の内容を、ちゃんと知ってから応募したほうがいいです。
職業としてのプログラマーになるということは、単に動くプログラムが書ければ良いということではありません。
初めてオリジナルのソフトウェアを作った人は、おそらくエラー処理はほとんどしていないと思いますが、仕事ならあらゆるエラーに対応できるように面倒臭いコードも沢山書かなければいけません。
ユーザーから遅いと言われたら、速く動くアルゴリズムを考えたり、実装方法を工夫して速くなるように作り直さなければいけません。
機能追加や修正がしやすいようにプログラムを構成する工夫も必要です。
仕事は共同作業ですから、他の人にも読みやすいように書かなければいけません。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者:Dustin Boswell,Trevor Foucher
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
動作テストもちゃんとしなければいけませんし、バグがあれば、何千、何万行もあるプログラムの中からバグを探したりもします。
色々と難しそうなことを書きましたが、プログラマーの仕事は、言語を使って複雑なパズルを解くような仕事なので、パズルの解き方を考えるのが好きで文字を読むのが好きな人と相性が良いと思います。
現実的には、Webサービスやアプリを安定稼働させるためにサーバーやネットワークの知識も勉強する必要があります。
変化の早い業界なので、時代や目的に合わせてプログラミング言語や関連技術を常に新しく勉強する学習意欲や向上心も必要です。プログラミング言語は10個ぐらいは覚えることになると思います。
- 作者:Junio C Hamano,大塚 弘記,川口 耕介,kana,大竹 智也(tomoya),尾藤 正人
- 発売日: 2013/04/10
- メディア: 大型本
そういったことを踏まえた上で、「もっと勉強して上達したい」「この仕事にチャレンジしたい」と思える人は、きっとプログラマーに向いています。
是非、ソフトウェアエンジニアになってください！
個人的にオススメな応募先
クックパッドさん、一番オススメしたいのにリンクの埋め込みが表示されません ＞＜ 助けて*1
http://hr.yahoo.co.jp/fresh/
などなど、他にも私の知らない範囲でもあると思います。
自分がWeb業界の人間なので、挙げるのがWeb系ばかりになってしまいました。ごめんなさい。BtoBやSIerにも良い会社あると思います。でも、Web業界も楽しいです。
IT系の勉強会に参加して、転職経験者の経緯とか聞いてみると良いですよ！
オススメできない応募先はここにはちょっと書けない（笑）ので、自己判断してください。
面接について
あとがき
今までの日本のIT業界は歴史的な事情で、向いていない人もたくさんプログラマーになっているので、向いている人にとってはむしろチャンスの大きい職種とも言えます。現に、トップレベルのプログラマーは年収1000万円以上もらっていたり、ベンチャー企業を立ち上げて資産が何十億円という人もいます。向いてそうなのに他の業界や職種を目指しているお知り合いがいらっしゃいましたら、是非ともプログラマー職の応募を勧めてみてください
おすすめ記事
*1:クックパッドさんにご対応いただきました。ありがとうございます。こうやってネット上のエンジニアの話題にも敏感で、採用活動にも真剣さが感じられ、エンジニアに対するリスペクトのあるふっふはっほさん、やっぱり素敵です
Swift NSTimerの使い方のポイント
scheduledTimerWithTimeInterval(ti: NSTimeInterval, target: AnyObject, selector: Selector, userInfo: AnyObject?, repeats: Bool)
ポイント
- target
- 指定するオブジェクトは、NSObjectを継承しているか、@objcのついたクラスである必要がある
- selector
- Selector("onUpdate:")でもよいし、"onUpdate:"でもよい
- コロンは省略不可（引数が一つあることを表す）
- メソッド名はなんでも良い
- 引数はtimer: NSTimerでなければならない
- 戻り値は自由
- Selector("onUpdate:")でもよいし、"onUpdate:"でもよい
サンプルコード1
class AnswerTimer: NSObject {
init() {
super.init()
NSTimer.scheduledTimerWithTimeInterval(1.0, target: self, selector: Selector("onUpdate:"), userInfo: nil, repeats: true)
}
func onUpdate(timer: NSTimer) {
}
}
スポンサーリンク
サンプルコード2
@objc
class AnswerTimer {
init() {
NSTimer.scheduledTimerWithTimeInterval(1.0, target: self, selector: Selector("onUpdate:"), userInfo: nil, repeats: true)
}
func onUpdate(timer: NSTimer) {
}
}
エラーメッセージ
上記のポイントが満たされていないと下記のようなエラーが出る
2014-11-23 10:13:12.623 MyApp[7959:894999] *** NSForwarding: warning: object 0x78e5d4f0 of class 'MyApp.AnswerTimer' does not implement methodSignatureForSelector: -- trouble ahead Unrecognized selector -[MyApp.AnswerTimer onUpdate:]
スポンサーリンク
おすすめツール
クイズアプリQuizUpで気分転換も兼ねた英語学習はいかが？
最近、iPhoneのクイズアプリQuizUpにハマっています。
QuizUpとは？
ジャンルを選んで、Play Now!ボタンを押します。
システムが対戦相手を探してくれて、対戦が始まります。
１対１の対戦で１0問の４択問題を解いてポイントを競います。
ポイントは回答時間が短いほど高くなるようです。
対戦が終わると、ポイントが集計されて、レベルアップしたり、「日本でトップ10内です！」などの賞がもらえたりします。
結果画面から対戦相手に再挑戦ができたりもします。
画面のメッセージや問題、選択肢などすべて英語なので、楽しみながら英語力Upできてとても良いです。
こんなQuizUpの魅力をご紹介します。
純粋に楽しい！
参加者が本当にグローバルで、アフリカやヨーロッパのあまり聞かない国の人もいます。
ロシア人の若い女性と対戦が組まれたりすると、ちょっと興奮しますね(笑)。
国別にランキングがつきますが、今の所は日本人の参加者が少ないので、少し頑張ると日本人トップランクが取れて、ちょっとだけ自分がすごい人になれた気分になります。
速く読む練習になる！
回答の制限時間が1問につき10秒で、残り時間が少なくなるとチキチキ音がなりだします。
選択肢も全部読むとなると結構な速さで読むことになりますので、速読力が相当鍛えられます。
カタカナ英語のスペルが覚えられる！
地名とか人名、商品名などが答えになっていることが多いので、それらのスペルを知ることができて、「へー、こういうスペルだったのかー！」と新鮮な気分を味わえます。
オススメのジャンルを紹介
英語が分からなくても画像だけ見て答えられるジャンルなんかもありますが、英語の勉強の意味でいくと以下の分野がオススメです
- 自分の専門分野
- 映画・ドラマ
- クイズにチャレンジするつもりで自分の好きな映画を英語音声・英語字幕で見直してみるとリスニングの勉強にもなって楽しいです
- 個人的には、Disney、Back to the Futuer、24あたりを見直している途中ですね
- ハリーポッターの原書
にも挑戦しようかと考えています
- アニメ
- 日本の作品がたくさん出てきます！アニメ文化が世界で受け入れられている実感がわきます！
- Animeというジャンルもありますし、作品別でもOne Piece、Dragon Ball、Narutoとかがあります！
オススメできないジャンル
- 英語のスペルを答える系のジャンル
- ネイティブの人の回答スピードに絶対勝てないので無駄に悔しいです
まとめ
以上、QuizUpの魅力を紹介してみました。
皆様も是非チャレンジしてみてください〜
日本人が知らない ネイティブがよく使う英会話フレーズ４００ 中経の文庫
- 作者: ジェームス・Ｍ・バーダマン
- 出版社/メーカー: KADOKAWA / 中経出版
- 発売日: 2014/01/14
- メディア: Kindle版
- この商品を含むブログを見る
素人iOSアプリ開発でプロの開発者に個人レクチャーをしてもらってとても良かったのでレポート
経緯
最近、個人的にiOSアプリを開発し始めました。Swiftの勉強はしたので、簡単なUIを作るぐらいはできたのですが、本格的なアプリを作るためには、UIKitの使い方や、Xcodeの使い方、iOS各種機能の使い方なども習熟しなければいけません。学生並みに時間がたっぷりあれば自分で勉強したでしょうし、外注したり、開発者の仲間を募って協力してもらえば、それなりに捗るとは思います。ただ、自分はサラリーマンで勉強時間はそんなに取る余裕はありませんし、外注や共同開発者は割とデメリットが大きいと思いました。
- 外注するデメリット
- 契約などが面倒臭い
- 納品後にしかクオリティが分からないのに、料金は先に決めなければいけない
- ノウハウがたまらないので納品後のメンテナンスができない（メンテ料金は払いたくない）
- 共同開発者を増やすデメリット
- 収益化した時のお金の分配が煩わしい
- 増やしたメンバーに途中で抜けられると、開発や運用が継続できなくなる
そこで、開発自体は自分で行いながら、腕の立つプロの開発者に分からない部分を教えてもらうことで、いい感じに開発を進められないだろうかと考えていました。
そんな時に、とある縁があって、iOSの勉強会などをよく主催なさっている平松さんに、アプリ開発の個人レクチャーをお願いできる機会に恵まれました。
レクチャーをお願いして良かったこと
現場の第一線で活躍なさっている方から得たもの（以下の通り）は自分が予想していたよりも大きく、とても有意義な一日になりました。
- ピンポイントで必要なことを必要なレベルで教えてもらえました
- 当たり前ですが、一般的な講習との一番大きな違いだと思います
- Xcodeの使いこなしを直に見たり聞いたりして、普段自分では気づかなかったXcodeの操作方法やTipsをたくさん知ることができました
- 言葉だけでは説明しづらいTipsも結構あります
- 自分でやり方を調べたり試行錯誤したとすると、数日間はハマってしまっていたであろうことを、「これはよくハマりがちなんですが〜」と予め教えてもらえました
- 新しい開発手法のノウハウを教えてもらって今後の開発が捗りそうです
- 特にautolayoutの効率的な組み方を教えてもらえたのが良かったです
- 書籍やWebではまだドキュメントが充実していないライブラリやiOSの機能も教えてもらえた
- とくにプッシュ通知などのバックエンドが絡む部分をParseを使って実装すると色々と捗ることを教えてもらって、バックエンドの実装がほぼなくなりそうなことが分かりました
「今後も分からないことがあったら教えますんで、また連絡下さい」と仰っていたので、皆さんも平松さんにレクチャーをお願いしてみてはいかがでしょうか。
平松さんのTwitter http://twitter.com/#!/himara2
レクチャーしてもらう側としてのポイントだと思ったこと
- アプリの要件、画面構成など、何を作りたいかは細かいところまでハッキリさせておくこと
- どう作るかは、素人考えであれこれ考えても無駄が多く、丸投げする感じで教えてもらうこと
- 実装するにあたって、自分が技術的に分かっている所、分からない所をハッキリさせておくこと
- 紙とペンも持参すること
- 教えてもらったやり方などをちゃんとメモしておくこと
- 教えてもらった成果物だけあっても、作成過程を再現できなかったり、そのように作られている理由が思い出せなければ、結局外注と同じになってしまいます
- 実機での検証ができる環境を前日までに整えておくこと
- 今回、実機でしか動かすことができないPush通知も教えてもらおうと思っていたのですが、なぜかApple Depeloper Centerにログインできない状況に陥り、実機検証ができなくて断念しました
当日の模様
- 11:00に平松さんオススメのシェアオフィス【東京・渋谷】ありんこオフィスで合流
- 午前中は、席が半分以上空いていました
（ありんこオフィス内の様子） - 横に二人がけのデスクがちょうどあったので確保
- 午前中は、席が半分以上空いていました
- 作りたいものを説明して、若干作ってあったUIを見てもらった
- UINavigationControllerの使い方の細かいことを教えて貰った
- 13:00ちょい前〜昼ご飯休憩
- 14:00〜レクチャー再開
- CustomView、autolayout、Parseを教えて貰った
- 17:30〜疲れてきたのでおやつ休憩
- コワーキングスペース内のオフィスグリコは食べたいものが見つからなかったので、隣のヒカリエ内のローソンで買い出し
- 18:00〜レクチャー再開
- 色々細かいことを教えてもらった
- 18:30に、今の段階で教わりたい要素が出尽くしたので解散
- 利用料金1000円でありんこオフィスもなかなか良かった
あとがき
Objective-Cの定番の書籍を書いていた人がSwiftの書籍も出したので、この機会にちゃんと勉強し直そう
- 作者: 荻原剛志
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2014/12/11
- メディア: 大型本
- この商品を含むブログ (1件) を見る
iOSアプリ開発初心者が最初に覚えるべきXcodeキーボードショートカットのトップ10
Xcodeでよく使う機能は画面上のボタンになっていますが、よく使うということは結局、キーボードショートカットを覚えた方がいいです。
シミュレーターの起動/停止
- ⌘+Rで起動
- ⌘+.(ピリオド)で停止
※シミュレーター側で終了するなら⌘+Q
プロジェクトナビゲーターの表示/非表示
- ⌘+1で表示
- ⌘+0で非表示
編集位置の遷移
- control+⌘+←（左矢印）で前に編集していたファイル・位置に戻る
- control+⌘+→（右矢印）で次に編集していたファイル・位置に進む
スタンダード/アシスタントエディターの表示
- option+⌘+enterでアシスタントエディターを表示
- ⌘+enterでスタンダードエディターを表示（アシスタントエディターを閉じる）
ユーティリティの表示/非表示の切り替え
- option+⌘+0(ゼロ)で切り替え
デバッグエリアの表示/非表示切り替え
- shift+⌘+Yで切り替え
