自由に働くアウトドア志向エンジニア

【所属】ベンチャー(2018年7億調達) 【役職】PM/エンジニア 【経歴】メガベンチャーにて開発(新人賞獲得)/フリーランスにてフットサル予約システム開発 【スキル】TOEIC900/Ruby on Rails/Nuxt.js 【学歴】名古屋大学/ウプサラ大学 【趣味】バックパック(29カ国)/サッカー(歴21年) ※発言はすべて個人的なものであり、属する企業の意見を代表するものではありません。

4月に読んだ本のまとめ

f:id:knsg16:20190502095849p:plain
タイトル
4月はついに200冊読破。 863日かけてやっと達成。 感想の投稿率も100%。読んだ本は絶対アウトプットすると決めて読むと、 質の高いインプットができると思う!

Twitterに感想投稿するでも、ノートにまとめるでもいいけど、 アウトプット前提で読んでみてほしい。

4月の読書メーター
読んだ本の数:7
読んだページ数:2156
ナイス数:157

ドイツ人はなぜ、年290万円でも生活が「豊か」なのか (青春新書インテリジェンス)ドイツ人はなぜ、年290万円でも生活が「豊か」なのか (青春新書インテリジェンス)感想

スウェーデンに1年住んでいたので、ドイツの労働・環境・個人主義な考え方は非常に納得感があった。

このドイツのような社会を実現するには、各人が「仕事で自己実現をしたいのか」それとも、「仕事では、ただのお金を稼ぐ手段なのか」を明確に意識しながら、自分の行動を選択していく必要があるはず。

日本の場合は、「働いて自己実現する」という方向に舵を切っている人が多い印象だが、それだから不幸になる人が多いのではないだろうか。仕事は手段って割り切れると人の顔色伺わなくていいから定時で帰ったりできるのではないか。

読了日:04月30日 著者:熊谷 徹
アフターデジタル オフラインのない時代に生き残るアフターデジタル オフラインのない時代に生き残る感想

中国のデジタル化は進んでるけど、データをすべて共産党に取られて監視されているから怖いってエンジニア同士で話していて本書を読んでみようってなった。

勉強になったのは、「顧客はその時に一番便利な方法で選びたいだけ」という法則。企業を主語にするのではなく、「顧客」を主語にし、さらに、属性でセグメント分けするのではなく、「状況」でセグメントを切る。これは目から鱗だった。

ただ、注意しないといけないのは、本書にある通り、全てデータ化しないといけないが、日本の企業は変わりにくいということ。

読了日:04月30日 著者:藤井 保文,尾原 和啓
沈黙のWebライティング —Webマーケッター ボーンの激闘—〈SEOのためのライティング教本〉沈黙のWebライティング —Webマーケッター ボーンの激闘—〈SEOのためのライティング教本〉感想

この手の本は普段読まない。この手というのは、漫画っぽくてなんか大衆向けに優しくしたような本はわざと避けていた。しかし、ブログよりもYoutubeや漫画のほうがウケがいいみたいな話を聞いてなるほどなと思って手にとってみた。内容はすごい勉強になるし、よく読み手(ターゲット)のことを考えているなという印象。どんな読者(もはやターゲットは普段本を読む人ではないはず)に向けて、どんな情報をどのように届ければいいのかの説明もしっかりしていたし、本書自体が入念に設計されている。すごい勉強になった。

読了日:04月29日 著者:松尾 茂起
年収は「住むところ」で決まる  雇用とイノベーションの都市経済学年収は「住むところ」で決まる 雇用とイノベーションの都市経済学感想

「マーケット感覚」「教育」「環境」がキーワード。結論からいうと、高等教育を受け、社会が欲している専門性の高い能力を身に着けて、その能力を求めている都市に移動し、仕事をする。そういう場所は、能力が高い人がイノベーションを起こす環境だから、相乗効果で、その都市全体の反映につながる。面白いのは、教育レベルが高くないと、場所を変えないということ。自分の生まれ育った場所を離れることができるのは、高等教育を受けたことのある人のほうが多いとのこと。

読了日:04月29日 著者:エンリコ・モレッティ
1万円起業 文庫版1万円起業 文庫版感想

上場目指して起業だけではなく、1万円出資の規模感でも年500万利益をあげるだけのビジネスを作り上げることは可能だよと、教えてくれる本。 「『魚』を与えよ」はなるほどなって思う。よく後輩を指導するには、「魚」ではなく、「魚のとり方」を教えろと聞くが、ユーザーに対しては、「魚」を与えることが重要というのには、納得。一番むずかしいのは、ユーザーが欲しいものをピンポイントで作れるかということ。ここは、考えてもわからないことが多いので、スモールスタートで始めるしかなさそう。

読了日:04月24日 著者:クリス・ギレボー
どこでも誰とでも働ける――12の会社で学んだ“これから"の仕事と転職のルールどこでも誰とでも働ける――12の会社で学んだ“これから"の仕事と転職のルール感想

転職の仕方や仕事の進め方のハウトゥーは勉強になった。12社も転職経験のある人は少ないだろうし、しかもその転職した会社は普通では入れないような超ハイスペックな人たちの集団のような会社で、珍しい経験をされてきたなという印象。

特に面白いなと思ったのは、人間関係構築。情報を発信し、Giveし続けること。また、マイクロインタレスト、自己開示、コミットメントといった方法で、出会って間もない人たちに信頼してもらえるように工夫していた方法が勉強になった。

読了日:04月23日 著者:尾原 和啓
日日是好日―「お茶」が教えてくれた15のしあわせ (新潮文庫)日日是好日―「お茶」が教えてくれた15のしあわせ (新潮文庫)感想

自分は旅が好き。 何がいいのかというと、非日常感がいい。 旅に出ると、日常の生活から離れ新しい刺激が向こうから勝手にやってくる。 でも、この本を読んで気付かされたのは、自分は「今、ここにいないんだな」ということ。 常に心ここにあらずで、日常は退屈で我慢する必要があり、それに耐えることで非日常=旅がより豊かなものになると思いこんでいた。 茶道の世界は体育会出身の自分からはほど遠い世界だけど、全く自分とは違う世界のことを勉強すると、こういった気付きがあるから面白い。
読了日:04月01日 著者:森下 典子

読書メーター

GWに高い金出して旅行するのはおかしい気がしてる

f:id:knsg16:20190412061202j:plain

2019年のGWは大型連休で喜んでいた。

10連休というのは、日本で会社員をやってる人にとっては珍しい長期休暇だ。2019年のGWは10連休らしいということを風の噂で聞いて、喜んでいた。

学生時代には、バックパッカーとして約25カ国くらい旅をしてたけど、大学卒業して、日本で働き出してからは、長期で休みを取れる機会もなく、ダナン(ベトナム)のリゾートに去年の年明けに行ったくらいだった。

社会人になったら長期の休みは取れないことはわかっていたので、学生時代に遠いとこに行こうと決めていて、実際に行った。スウェーデンに1年間留学していたので、ヨーロッパは色んなとこ行けたし、バックパッカーとして南米横断を一人でしていた。そして、近場のアジアは社会人になってからのために、わざと残しておいた。

2019年GWはインド行こうとしたけど、航空券高すぎ

残しておいたのは、タイ、ミャンマーカンボジアとか日本人のバックパッカーなら必ず行きそうな国だけど、戦略的に残しておいた。ただ今回のGWは10連休だから、残しておいたアジアの中でも20代のうちに行っておきたいランキング1位のインドに行くことにした。

バックパッカーのくせに、インドに行ったことがないのは引け目を感じていたし、色んなバックパッカーからインドは壮絶だったという話を聞くので、どうしても行きたかった。

せっかくの10連休という長期休暇なので、インドに行こうとして、いつもの通り約4ヶ月前の2019年1月くらいに航空券を調べ始めた。なぜ4ヶ月前なのかというと、航空券を取るのは4ヶ月前〜3ヶ月前と決まっているからだ。

いつもの通り、SkyScannerで航空券だけ予約してから、そのあと適当にホステルを取ればいいと思っていたが、成田〜ニューデリー(インド)のチケットの往復が12万を超えていた。

「え、なんでそんな高いの??」

基本は格安の航空券しか取らないので、インドへの往復の相場は往復5〜6万と聞いていた。去年(2018年)のGWはマレー半島縦断して、その時は往復4万くらいだった。

高い金を出して旅行したくない

航空券はダイナミックプライシングだから、需要と供給のバランスを取っていて、みんなが欲しい時は、航空券の値段が高くなるし、みんながほしくない時は、航空券の値段が低くなるようにできている。

2倍の値段を払ってGWにインドに行きたくないという気持ちが強くなったので、今回は見送ることに。

本当はインド行って、タージマハル見て、ガンジス川で背泳ぎして、アシュラムでヨガの修行しようとしてたのに、お預け。

india-yoga.jp

時期をずらしてバルセロナなう

そんな自分はスペインなう。時期をずらして、4/5 ~ 4/13までバルセロナとまでマドリードに来てる。地元の成田空港から出発したけど、ほとんど日本人はいなかった。みんなGWで旅行することが決まってるからこの時期は旅行しないんだろうな。

無類のサッカー好きなので、カンプノウバルセロナアトレティコマドリードという、リーガ・エスパニョーラの首位攻防戦を生で見ることができて大歓喜。チケットは下から3番目に安いチケットを取ったけど、2人で約4万円。かなり高く思えるけど、倍のお金を払ってGWに旅行すると考えたら安い。

f:id:knsg16:20190412061302j:plain

Expediaで予約して安い

会社の同僚のお父さんが今年のGWにバルセロナに行くらしいが、航空券だけで30万近くかかっているらしい。今回自分のスペイン旅行では、往復航空券と4つ星ホテル7日間で13万円しかかかっていない。Expediaさまさまだ。

高いお金を出してビジネスクラスやファーストクラスに乗れるならいい体験を買うことができているので、高いお金を払う価値があると思うが、高い金を出してエコノミーにしか乗れないのは気に食わない。しかも、高い理由はGWはだからっていう。

弊社は、働き方が自由な会社

今働いているベンチャー企業は少々変わった勤怠制度がある。月で営業日×8h働けばよいという制度。この制度を利用して今回は長期の休みを頂いた。例えば今年の4月だったら20営業日あるので、20営業日×8hだから、月で160h働けばよく、22時を超えて残業したり、休日に働いたりしなければ、厳しい決まりはほとんどない。だから、今回は5営業日分休みを頂いたから、5営業日×8h=40h分を今月中に働くか、有給を組合せたりして月末に調整すればよい。なんて働きやすい会社なんだろうか。

おまけにスペインから、リモート働いてslackでやり取りもしていた。でも、いまのPM(Product Manager)の仕事はリモートに向いていなかったなと思う。この辺は別の記事でまとめてみる。

まとめ

GWだからって長期休みをとって、海外旅行をする。みんな当たり前だと思っていませんか?なんで、人が多い日にわざわざ旅行行かなければならないんだろう。なんで、航空券が高い日に航空券を取らなければいけないんだろう。こういう疑問を持つことが必要なのではないでしょうか?

よく考えて自分が納得できるのならば、問題ないのですが、盲目的にみんながこうしているから、こうするといったものを避けるべきかと。

3月に読んだ本のまとめ

今月は本を読もうと意識していたので、比較的多くの本を読むことができた。 振り返ってみると、なんか簡単そうなビジネス書とか小説が多い。 仕事で新しい挑戦をしていて、そこでかなり疲労困憊してたので、 そういう時は、簡単でわかりやすくてスラスラ読める本を読みたくなるんだろうな。

そのうち、読書メーターを使って読書をするメリットとか、 そろそろ200冊読了するので、200冊読んでみてのまとめを書かないと!

3月の読書メーター
読んだ本の数:10
読んだページ数:3416
ナイス数:208

人生は、運よりも実力よりも「勘違いさせる力」で決まっている人生は、運よりも実力よりも「勘違いさせる力」で決まっている感想
なんとなくそうだろうなーと思っていたことが整理させていたので、なるほどとなった。

大学受験やサッカーとかは、完全に実力社会で、受験というテストで点数を取らないといけないし、サッカーでも実力がある人が、レギュラーになっている。

しかし、社会人になって、何が評価されるのかも分からない。少なくとも日系企業ではスタートアップでもメガベンチャーでも大企業でも実力社会ではないなと思うようになってきていた。

なんかすごいっぽい人が評価されるし、本当に定量的な成果を出している実力のある人が評価されてる訳ではない。
読了日:03月25日 著者:ふろむだ
億男億男感想
「どんなに賢い人間でも、それ(お金)をコントロールすることはできない。そのことに気づいた一男は、目の前のすべてを労働で埋めることにした。」こういう考えの人は多いんじゃないかなと思った。お金のことに限らず、これからのことを考えるのは怖いから、とりあえず働く。働くことで、お金とかこれからのことに関する思考を停止することができるから、むしろ楽だと感じているのではないだろうか。本当にお金のことを気にするなら、お金のことを詳しく知ってなかよくなる必要がある。それは至極当然な意見だと思った。
読了日:03月19日 著者:川村 元気
知的幸福の技術―自由な人生のための40の物語 (幻冬舎文庫)知的幸福の技術―自由な人生のための40の物語 (幻冬舎文庫)感想
なるほどなーと思うことが沢山あったので、羅列する。厚生年金は所得のない人の配偶者(専業主婦)の分も賄っているので割に合わない。不動産について、もし本当に利益がでるなら、その提案している不動産会社が自分でやって利益を出しているだろうということ。国家にも企業にも依存せず、自分と家族の生活を守ることのできる生活基盤を持つことを「経済的独立」という。
読了日:03月19日 著者:橘 玲
FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣感想
筆者の通われていたウプサラ大学に自分も留学していて、国際平和学といった似たようなことを勉強していたので非常にしっくりきた。 自分たちの思い込みは捨てて、データから正確な情報を読取るべき。気をつけなければならないのは2つあって、1つはデータの見方。2つの軸で比較しながらだったり割合をみないと本当に見たい情報を獲得できないということ。もう1つは、メディアの報道。メディアの報道では、視聴者・読者を引きつけるような事象を伝えていて、必ずしもそれは事実ではないということ。
読了日:03月19日 著者:ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド
ロボット・イン・ザ・ガーデン (小学館文庫)ロボット・イン・ザ・ガーデン (小学館文庫)感想
サイエンス・フィクションであることを忘れさせるくらい、タングが人間の子どもっぽいなと感じた。この世界のAIは、人間の作業のいくつかを代行することができるアンドロイドが主流である。人間みたいな気持ちを理解して、学習することができて、嘘をつくことができるようなAIには、タングのように、自分の子どものような可愛さがある一方、ボリンジャーの失敗作のように人間を殺してしまうような存在にもなりうる。その対比がAIについて考えさせられた。タングが論理的すぎて、ベンの感覚的な説明を理解できないといった表現は秀逸。
読了日:03月10日 著者:デボラ インストール
(日本人)(日本人)感想
面白い。協調性や他人の面子を立てるといった、日本人が「日本人らしさ」と思っていたことは実は間違っていて、東南アジアでもみうけられる共通の特徴であり、日本人固有の特徴ではないということを証明している。「自分で責任を持って行動することにストレスを感じやすく、他人から嫌われることを恐れ、目立つことを嫌がる。」加えて、「世間のしがらみに溺れながらも、現世を楽しく生きることがすべてだだと考えてきた。」こうした特徴を日本人らしさと定義している。

論の進め方に説得力があって、頭いいんだろうなと思った。
読了日:03月09日 著者:橘 玲
マネーロンダリング (幻冬舎文庫)マネーロンダリング (幻冬舎文庫)感想
めちゃくちゃ面白かった。投資、金融、マネーロンダリング、香港、裏社会、サスペンスっていう要素がきれいに混ざりあって、そんな脱税方法があるんだとか勉強になりながらも、一体麗子は何者なんだっていうことが気になって、つい読みいってしまった。

できれば、自分も働きたくないのでこの筆者みたいに、投資だけでお金を回しながら生活したいな、とも思いながら読んでいた。
読了日:03月09日 著者:橘 玲
超 筋トレが最強のソリューションである 筋肉が人生を変える超・科学的な理由超 筋トレが最強のソリューションである 筋肉が人生を変える超・科学的な理由感想
正直前作の方が面白かった。でも、筋トレが最強である科学的な理由を証明しようっていうのは説得力があって良い。

科学的な根拠はなかったけど、筋トレをして筋肉が付き始めると不思議とメンタルが強くなる。筆者が言う通り、「何かあってもぶちのめせる感」かどうかは分からないが、筋肉が付くには、食事と筋トレを規則的に努力する必要がある。それは簡単な道のりではなく、その努力を継続したってことが自信につながるのかもしれない。
読了日:03月09日 著者:Testosterone,久保 孝史
独立記念日 (PHP文芸文庫)独立記念日 (PHP文芸文庫)感想
何か自分の生活に不満があると、自分だけが不幸な気持ちになる。まるで、じぶんだけ「シンデレラ」みたいな悲劇のヒロインみたいな気持ちになる。でも、みんな何かしらの悩みを抱えていて、自分だけが悩んでいるんじゃないと気づかせてくれる一冊。

この本を読むと周りの人に、自分ももっと頑張ろう。もっと優しく周りの人に接しようって思える。

残念なのは、1つの話が短く感じたので読み応えはなかった。
読了日:03月09日 著者:原田 マハ
エミール (まんがで読破 MD111)エミール (まんがで読破 MD111)感想
kindleで10円で買えるので、ぜひ読んでほしい。 教育学を専攻していたので、部分的には授業の課題で読んでいたが、最後まで読んだことがなかったので、漫画で全容を把握してから、岩波文庫でのエミールを読むのはいい流れかと。

教育は、自分が親から受けた教育を当たり前に思ってしまいやすい。しかし、教育にも古典があり、現代においてベストプラクティスという訳ではないが、エッセンスは抽出して現代に当てはめて使える考え方は多いと思う。
読了日:03月09日 著者:バラエティ・アートワークス

読書メーター

【後編】他の駆け出しエンジニアと差別化するために必要な5つのこと

f:id:knsg16:20190309171549p:plain

この記事は前回のこちらの続きとなっています。

knsg16.hatenablog.com

駆け出しエンジニアには、マストな知識ではないが、知っておいたり、頭の片隅においておいて実装すれば、他の駆け出しエンジニアと差別化できる5つのことを紹介している記事となっています。

前回は、

  • RubyRailsの便利メソッドを使いこなす
  • 保守性への意識

この2点について説明させて頂いたので、今回は残りの3つについて説明します。

  • 速度
  • データを安全にDBに入れる
  • 拡張性

速度への意識

業務レベルになると、速度を意識したコードを書く必要がでてきます。特にtoCの領域だと、「ボタンをクリックしたら、画面遷移するのに1秒くらいかかるから、もう見るのやめよう。」みたいな感じで、折角興味を持ってくれたユーザーの方を逃してしまったりします。

駆け出しエンジニアの頃は、その辺を意識していません。 というよりは、意識してコードを書くだけの余裕がないので、速度を意識すれば差別化できるはずです。

駆け出しエンジニアのレベルで意識できたら、かなりいいなと思うのは、以下の2つです。

  • N+1問題
  • SQLの発行回数

N+1問題はかなり有名なのでご存知の方もいらっしゃるかもしれません。詳細な解決方法はいかに譲ります。

Rails で includes して N+1 問題対策 - Qiita

簡単にまとめると、 indexのページで、レコードをJOINして、情報を表示させたい時に、多くのSQLを発行してしまい、速度が遅くなってしまうということです。

そして、BulletというGemも用意されていますので、N+1を検知して警告をしてくれます。以下の記事で説明されています。

N+1問題を発見しDBのクエリを改善するBullet | 酒と涙とRubyとRailsと

SQLの発行回数にも気をつけなければいけません。 Ruby on Railsで書いている方は、Active RecordというO/R マッパーを利用しているので、意識している方は少ないかもしれません。 しかし、Active Recordの裏側ではSQLを発行しているので、どのActive Recordのメソッドを書けば、 どのようなSQLのクエリが投げられるのかを把握する必要があります。

https://lets.postgresql.jp/documents/tutorial/dos-and-donts/3

こちらのブログから引用すると、

アプリケーションの内部で、特定の条件でレコード数をカウントし、FORループを回してレコード数分のSELECTクエリを実行するようなコードを見かけることがあります

とあります。 これを読んでギクッとした人もいるのではないでしょうか?

SQLの発行回数について、特に意識しないと、SQLをむやみに発行してしまう、速度が遅いアプリケーションになってしまいます。

データを安全にDBに入れる

なにか情報を登録したい時に、MySQLなどを使ってDBにデータを登録する必要があります。その時に、実際に入力してほしいデータが本当に登録されるようにコードを書いてあるか、複数モデルにまたがった時に、リレーションのズレがないように登録するようにできているのかということは非常に重要な観点になります。

この辺の知識とスキルは業務レベルでは必須であるものの、スクールレベルでは解説程度に留められてしまっている印象です。なぜなら、少し高度な内容になってくるので、駆け出しエンジニアの方には、少し難しいと感じる方が多いはずです。こういう難しい話で挫折するよりは、この辺の話は飛ばして、コードを書くことが楽しいと思ってもらった方がよいとの判断でしょう。 駆け出しエンジニアでは以下の2つを意識できれば十分でしょう

  • Transactionロック
  • validationをどこでどのようにかけるか

例えば、Transactionロックとは以下のようなものです。 authorのsaveとbookのupdateの両方が成功しないと、DBに登録できないといった書き方です。 どちらか一方が登録に失敗したら、両方が失敗をするといった感じです。

anthor = Author.new(author_create_params)
book = Book.find(params[:id])
begin
  ActiveRecord::Base.transaction do
    author.save!
    book.update(book_update_params)!
  end
  p '登録完了しました' # トランザクション処理を確定
rescue => e
  p '登録に失敗しました' # トランザクション処理を失敗させて、DBのデータの整合性を守る
end

validationに関しては、 データは、ほしい形で登録したいよという話です。 例えば、会員登録する画面では、メールアドレスの登録が必須だと思いますが、 @マークがないメールアドレスは存在しないので、 taro_yamada.google.jp というメールアドレスが入力されたら、「そのメールアドレスは無効です!」といったアラートを出したりします。

そのように、DBにほしい形で登録したいという設定をする箇所が大きく分けて3箇所あります。

  1. javascriptでクライアント側で防ぐ
  2. applicationレイヤーで防ぐ(modelにvalidationを実装する)
  3. DBのschemaの設定防ぐ

駆け出しエンジニアは、たぶん2のapplicationのレイヤーでmodelにvalidationを実装するという形しか知らないのではない、もしくは実装したことないのかもしれませんが、色んな方法があるということを知っておくと差別化につながると思います。

拡張性

拡張性については、DBの話とメソッドの話があります。 業務に入ると、コードレビューで、どうしてこのテーブル構成にしたのか、どうしてこんなメソッドにしたのかを説明が求められることがあります。

その時に、今の仕様を満たしているだけで、拡張性がないコードを書くと、レビューで通らないなんてこともあります。一度書いたコードは残り続けるので、たとえ、今の仕様を満たしていても、未来のことを考慮できていない書き方だと、新たな機能を追加する時や、業務が変更になった時に対応できなくなってしまいます。

駆け出しエンジニアの時代では、そこまで長期で使用することを考慮してコードを書く訳ではなく、勉強のためとか、ポートフォリオのためとか、発表のためとかいった目的でコードを書くと思います。

実際の業務との大きな違いは、コードを書いて動かすソフトウェアは、業務がなくなったり、仕様が変わったり、会社が潰れたりするまでは一生使い続けます。その点を考慮したコードを書くことができるか、DB設計ができるかが現場では重要になります。

ここをこういう構成にしたのは、将来この業務がこういう変更されることも考慮しています。この仕様がこのように変更する可能性も考慮しています。などといったことが説明できるようなコードを書くことができれば、他の駆け出しエンジニアと1歩も2歩も差がつくのではないかと思います。

まとめ

私自身が、駆け出しエンジニアをやや卒業気味になり、先輩のエンジニアからも面倒をほとんど見てもらうことなく、現場で楽しくコードをかけるようになってきて、その経験を多くの方に伝えようと思って今回の記事を書きました。

他の駆け出しエンジニアと差別化するために必要な5つのことは、自分が現場に入ってから、スクールや独学では理解することができなかったことを抽象化してまとめました。

これからエンジニアになりたい人、エンジニアになるために勉強してる人の役に立つことができればと思います。

【前編】他の駆け出しエンジニアと差別化するために必要な5つのこと

f:id:knsg16:20190224111921p:plain 今回の話は、駆け出しエンジニア時代に知っておきたかった5つのことについてです。

会社にRubyエンジニアとして入社して、はじめは非常に苦労しました。それは、独学ではなかなか身につかないような知識を高速でキャッチアップしなければならなかったからです。

これから話す内容の技術的な知識のほとんどは、会社に入社してから獲得しても遅くはありません。しかし、もし、入社前の駆け出しエンジニア時代に、これらの知識を身に着けておいて、採用面接時にアピールできたら、他の駆け出しエンジニアと大きく差別化できると思います。

独学と業務レベルのコードの違いは以下の5つのことが考慮されたコードになっているかどうかだと、自分は学びました。

  • RubyRailsの便利メソッドを使いこなす
  • 保守性への意識
  • 速度への意識
  • データを安全にDBに入れる
  • 拡張性への意識

RubyRailsの便利メソッドをつかいこなせているか

RubyRailsには多くの便利メソッドが用意されています。たぶん、多くの駆け出しエンジニアは、実装物を動かすのに必死で、どんな場合にどんなメソッドを使うことができるのかということまでに頭が回っていないと思います。自分自身も謎のエラーでハマって、ずっとググっていて、その問題を解決するのに必死だったので、「もっといいメソッドないかな」と思うことなど1度もありませんでした。

しかし、業務レベルでは動くのは、当たり前でもっと完結に書けるのではないかといったレベルの話になってきます。この辺は、場数をこなして業務経験を積みまくって、最適なメソッドを選択できるようになればいいと思います。

Railsの便利なメソッドたち - Qiita

[初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

こういう記事を見ると、そんな書き方があるのかと勉強になります。自分が業務に入り初めてこんなメソッドあるのかと勉強になったのは例えば、以下です。

駆け出しエンジニア時代には、全く使うことができなかったメソッド達です。

駆け出し時代に少しでも、便利メソッドの存在を頭に入れておけば、他の駆け出しエンジニアとの差別化できると思います。

Rubyエンジニアのバイブルとなっているチェリー本には、色んなメソッドが紹介されていて、その説明が非常にわかりやすいので一度手にとって読んでみることをオススメします。

保守性への意識

前述の通り、駆け出しエンジニア時代はとにかく実装物を動かすのに必死なので、あまり保守性について意識はされないかもしれません。しかし、実際の業務では、一度書いたソースコードは、リファクタリングや不具合修正などで、ソースコードを消さない限り、残り続けます。

そして、そのソースコードは自分だけではなく、自分以外の開発者が読むことになります。したがって、自分以外の人が読んでもソースコードが理解できるような状態にしなければなりません。

具体的には以下の2点をちゃんと考慮できているかという点です。

  • 変数、メソッド名の命名
  • 深すぎないネスト

変数、メソッド名の命名

1点目に関しては、変数やメソッドの命名が分かりやすいものになっているかという話です。変数名から、その変数に格納されている値が、連想できる名前になっていますか?たとえば、Bookクラスのレコードを全件取得して、ある変数に格納したい時に、

#変数名が単数
book = Book.all

このように書いていませんか?これだと、獲得してる値は複数なのに、変数名が単数系なので、変数名と格納されている値がうまく連想できません。

そうではなく、

#複数系にする
books = Book.all

#Arrayで取ってくるなら接尾辞に"list"をつける
book_list = Book.all.to_a

などとして上げるとわかりやすいでしょう。

深すぎないネスト

2点目についても、自分以外の開発者が自分の書いたソースを読んだ時にどう思うのかという点です。

ネストが深すぎるとは、

def hoge
  if(a == 1){
    if(b == 2){
      if(c == 3){
        if(d == 4){
          ...
        }
      }else(c == 5){
        ...
      }
    }
  }
end

こんな状態を指します。これだと、自分で書いてるにも関わらず、どこで、どんな分岐をしているのかどうか分からなくなってしまうことは容易にありえます。

ましては、他の開発者が読んだら、分からないですし、分かったとしても、理解するのに、相当の時間がかかると思います。

そうではなく、そもそもメソッドを切り分けたり、早期returnしてネストが深くならないように工夫しなければなりません。詳細は、他の記事に譲りますが、弊社だとネストは2段階までと決めて実装しています。

以下の記事は、ネストについて詳細に書かれているので非常に参考になります。

新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita

コードのネストを深くするな | anopara

「リーダブルコード」を読むと非常に勉強になるでしょう。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

最後に

今回は前編ということで、ここまでにします。

  • 速度への意識
  • データを安全にDBに入れる
  • 拡張性への意識

上記の3点については、後編にてお伝えします。

正直、駆け出しエンジニア時代は、動かすのに必死なのでここまで余裕がないかもしれません。

自分が駆け出しエンジニア時代には、全く知らなかった知識なので、あくまで他の駆け出しエンジニアと差別化したいという意欲の強い方は勉強されていてもいいかもしれません。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月 〜TechCampに通う編〜

f:id:knsg16:20190211095220j:plain
image

駆け出しエンジニアはTechCampに通う必要はない

今回はTechCampというプログラミングスクールに自分が実際に通って良かったこと、良くなかったことの共有することによって、プログラミングスクールに通おうかどうか迷われてる方の助けになればなと思いながら記事を書いています。

結論としては、

自分はTechCampに通う必要はなかった

会社のお金で研修として通わせて頂いたので、個人のスキルアップのために会社のお金を使ってくれたことに非常に感謝していますが、TechCampに通って半年たった今振り返ってみると、他の勉強方法で補うことができたのではないかと思います。

Rubyエンジニアになるまでの流れは以下の記事を参考にしてください。

knsg16.hatenablog.com

knsg16.hatenablog.com

TechCampに通う必要のない3つの理由

1.カリキュラムが自分で勉強できる内容だった

TechCampに通う必要がないなと思った一番の理由は、これって自分で勉強できる内容だと気づいたことです。

Tech::CampのWebサービス開発コースに参加して、その後にオリジナルアプリの開発をしたのですが、Webサービス開発コースの内容はほとんど、Rails TutorialやProgateの内容と同じでした。

なので、オンライン教材を使ってRuby on Railsの勉強をしてた自分にとっては非常に物足りない内容でした。

自分もまだ駆け出しエンジニアなのですが、エンジニアになってみて自分で勉強しなければならないことがかなりあると毎日実感してます。そういった学び続けなければいけないWeb系エンジニアになりたいのであれば、これくらいは自分で勉強できないとWebエンジニアとしてキャリアを続けていけないのではないでしょうか。

2.メンターが質問に答えることができない

Tech::Campには学生と思われるメンターが常時待機していて、わからないことがあったら質問をするというシステムでした。

Webサービス開発コースに参加して、その後にオリジナルアプリの開発をしたのですが、オリジナルアプリの開発というように、カリキュラムから外れたような質問になってくると、メンターの方が自分のした質問に答えてくれませんでした。

想像でしかないのですが、たぶんカリキュラムよりも少し高度な内容になると、質問に答えることができないのではないでしょうか。

もちろん、メンターさんの中にはあらゆる質問にすぐに回答してくれるような技術力・技術知識の高いメンターさんはいらっしゃったのですが、その割合は5%以下くらいでした。

どうせ質問しても回答してくれないなら、自分で調べた方が早かったので、教室には毎日通っていましたが、後半はほとんど全く質問をしませんでした。

3.詰まったところを解消するというメタなスキルを学んだ方が早い

駆け出しエンジニアが詰まるところは、経験上2つのパターンに分けられます。

  1. ググり方が下手
  2. ベストプラクティスを把握していないので、知ってる知識の組み合わせで開発をしてしまい、構造的におかしなソースになってしまう。

Ruby on Railsの日本語の情報はありがたいことにかなり豊富です。正しくググることができたら、ほぼ確実に詰まったところの解消方法が見つかります。

しかし、前述した2つの理由で正しくググれないので、ほしい情報にありつくことができないのです。

エンジニアとしてキャリアを積んでいくには、「魚をもらう」のではなく、「魚の釣り方」を学ぶ必要があります。それが、「詰まったところを調べて自分で解決するスキル」です。最初の方はなんで詰まってるのかも分からない状態だと思うので非常に苦しいですが、ここで逃げ出さずに自分で調べ抜くことで、エンジニアとして非常に大切なスキルが身につきます。

誰も教えてくれないググり方 - Qiita

TechCampに通うメリット

自分はTechCampに通うメリットは少ないなと感じたのですが、もちろんメリットがない訳ではありません。

1.教材は超初心者にとってはわかりやすい

TechCampの教材はTechCampに入会した方だけが見ることのできるオンラインカリキュラムです。

【徹底レビュー】TECH::CAMP(テックキャンプ)全コース受講した感想まとめ | ロボット・IT雑食日記

こちらの記事にあるように、TechCampのカリキュラムはオンラインのカリキュラムなので、受講生から質問が多かった箇所などを随時分かりやすくするために更新しています。

なので、超初心者にとっては、カリキュラムが非常にわかりやすいのでありがたいと思います。

2.自分だけで自習だとモチベーションが続かない人にとっては良い環境なのかな?

TechcCampの教室は、非常に集中できる空間でした。自分は渋谷校に通ったのですが、あまり混雑してることもなく、受講生は黙々とプログラミングの学習をしていたので、環境面では非常に良かったです。

自分は自宅でも集中して勉強できるタイプなので、特にメリットを感じなかったのですが、自分の家だと集中できないとか、一人だと勉強を続けることができない人にとっては、プログラミングの学習に集中できる良い環境なのかなと。

まとめ

個人的な意見としては、TechCampで勉強できることはすべてオンラインカリキュラムを使って自分で勉強できます。実際に通うタイプのプログラミングスクールは、金銭的コストが非常に高いので、そこまでオススメできません。

エンジニアとして活躍するためには、常に自分で勉強し続けることが求められます。そうしたトレーニングも兼ねて自分で勉強する力も身に着けたほうが、エンジニアとして成長できると、自分はTechCampに通って感じた次第です。

次は...

次の記事は、実際に業務に入って細かいバグ修正をした話を書こうかなと考えています。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月 〜転職活動編〜

転職準備期間から転職活動へ

転職の意志が固まったら、あとは思い切って転職活動をするだけです。実際に自分は、転職活動で2社の内定を獲得したのですが、前職の先輩から誘って頂いた会社に入社することに決めました。

転職活動の準備は事前に完了しているので、怖いことはありません。自信を持って挑戦しましょう。転職準備の方法は以下を参照。

knsg16.hatenablog.com

本記事で伝えたいことは以下の3点です。 - やりたいことをぶらさない - 「やりたい」ではなく「やってる」をアピール - 自分が与えることができることをアピール

転職の準備をしっかりして、転職活動中に以上のようなアピールができれば、きっと結果はついてくるはずです。

エージェントに登録

自分は、まずは転職エージェントの話を聞くことにしました。具体的には、 - ビズリーチ - Wantedly - リクルート

に登録をしました。 まずは、リクルートに登録をしたのですが、こちらが就業しているにも関わらず、繰り返し電話をしてくるので、うざかったので、リクルートをつかって転職活動をするのはやめました。

ビズリーチWantedlyには、自己紹介や自分の経歴などを書くことが求められるのですが、そこは丁寧にしっかりと書きました。具体的には、自分には何ができるのか、どんな思いがあって転職活動をしているのかが読み手に伝わるように書きました。

ここでちゃんと書くと、ビズリーチの場合は、エージェントから、Wantedlyの場合は会社から直接スカウトという形で連絡が来ます。

ビズリーチの場合は、エージェントなので、ここからどんな会社に転職したいのかといったヒアリングを受けます。こちらから、いまの転職市場の状況がどのような状況なのかを積極的に掴みにいきましょう。

カジュアルに話したいという1次面談

Wantedlyでスカウトが来たり、話を聞きたいといったアクションをすると、次は「カジュアルに」話したいという連絡が来ます。お茶でも飲みながら、気楽にお互いのことを知れたらいいですね、といった内容で連絡がくるのですが、惑わされないでください。これは紛れもない1次面接です。

会社は、転職したい人の相談に無料で相談に乗ってくれるほど余裕がないし、暇じゃありません。転職したい人にとっては、話を聞きに行くだけだからという甘い気持ちでいくと、もうその会社から次の連絡はきません。

カジュアルに話たいという連絡がきても、これは1次面接なんだという覚悟を持って、なぜ自分はこの会社で働きたいのかということをしっかり伝えましょう。

なぜ、ここまで言えるかって? 自分が失敗したからです。(笑) カジュアル面談だからといって、何も相手企業のことを調べないで行ったらコテンパンにやられたからです...

印象の良かったアピール

印象の良かったアピールは、自分はどういった貢献ができるかを伝えることができたことと、コードが書きたいだけじゃなくて、実際に書いて勉強しているということを伝えることができたことです。

前者に関しては、自分を雇うことで相手の会社はどういうメリットがあるのかということを認識してもうらう必要があるということです。自分の場合は、社内の業務を効率化できますということを伝えました。自分で問題点を見つけて、実際にコードを書いて、しょぼいツールでしたけど、みんなの工数を70%削減したという話は、成果として認めてもらうことができました。

たとえ社会人歴が短いとしても、なにか自分が会社のために工夫したことがあるはずなので、それを伝えましょう。逆に、自分を雇うメリットを伝えることができない状態ならば、まだ転職の準備が完了してないはずです。いまの環境でできることは何かしらあるはずです。しっかり準備しましょう。

何よりも手を動かすことが重要

自分がRubyエンジニアになりたいということを証明するために、いかに独学で勉強したのかということを示しました。Githubのソースを見せたり、実装物の画面を見せたり、企画書を見せたりもしました。

これがかなり良い評価に繋がったのではないかと実感してます。

エンジニアになりたい人は、やはり手を動かすことが重要です。実際に自分でプログラミングを書いて、何か動くものを作ってみる経験が必要です。

エンジニアになりたいのに、プログラミングを実際にやったことのない人は信用できません。

そして実際に第二新卒の採用に携わって実感したことですが、エンジニアになりたいと言ってるが、実際に手を動かさない人は、なんとなくエンジニアとしてのポテンシャルが低く見えてしまいます。自分でやってみるといいう能力が低い人は、エンジニアになってから直面するであろう問題の数々に乗り越えることができないのではないかと思います。

「やってみたい」と、「やってみた」のあいだにある、大きな差。 | Books&Apps

こちらのブログでなるほどなと思うことが書いてありました。

「やってみた」は、科学。「やってみたい」は、迷信。やってみれば、データが取れる。それを基に、もっとうまいやり方を考えられる。実験ができて、きちんと検証できれば科学だ。

やってみたいでは、先に進めないけど、やってみたらたとえ失敗したとしても先に進めることができる。

Twitterでも、こんなフィードが流れてきて、「その通り」って思いました。

魅力的なオファーという誘惑

ここでは、自分の軸をぶらさないことが大事と思った理由を話ます。ビズリーチで知り合うことができたエージェントからは、自分の進みたい方向(プログラミングを実際にして技術力を高めて、社会の問題を解決する)とは、少し違った方向の職種からのオファーが多かったです。

具体的には、コンサル系や品質保証系のお仕事でした。 勝手にオファーがきたので、特に無視すればいいだけだったのですが、それらがかなり魅力的なオファーだったのが問題でした。誰もが知ってるような会社から、年俸が上がるようなオファーを頂いて、一緒に働いてみないかと言われると、非常に心が揺らぎます。

ただでさえ、転職活動で疲弊しているのに、そんな甘い誘惑をされると、自分が本当に進みたい方向を見失ってしまいます。だから、自分の軸を言語化して、常に確認することが必要です。その軸に沿ってないようであったら、心苦しいですが、オファーを断る勇気が必要です。

失敗談

成功談ばかり話しても面白くないですから、失敗談も話します。Wantedlyで求人を探していたところ、ここで働きたいと思える会社を見つけることができたのですが、ここを乗り越えれば、残りは最終面接という3次面接で落ちてしまいました。

なぜかというと3次面接の内容は技術面談だったからです。実際に画面を作成して、DB構成を考えて、好きな言語で実装をして、自動テストを書くという内容でした。

Ruby on Railsは独学で勉強してきたので、なんとなく動くコードを書くことができるが、それは業務で使用できるレベルではありませんでした。なぜなら、どんな書き方があってて、どんな書き方が間違っているのかを自分では全く判断できなかったからです。

今になって振り返ると、誰かに自分の書いたソースコードを見てもらう必要があったなと思います。つまり、コードレビューをしてもらった方が良かったなと思います。ただ、独学で勉強している段階でソースコードをレビューしてもらう環境を探すのは至難の技です。タイムチケット | 個人の時間を30分単位で売り買い例えば、こういったサイトで、コードレビューをお願いしたりすればいいのですが、なにせお金がかかります。

一番いいのは、仲の良いエンジニアの知り合いに見てもらうかと。

しかし、駆け出しエンジニアには、技術試験のある会社のハードルは非常に高いですね...

まとめ

  • 軸をぶらさない
  • 「やりたい」ではなく「やってる」
  • 自分が与えることができる価値をアピール

これらを実践することで、自分は内定を獲得することができました。転職活動は、採用する立場になって分かったのですが、ただの運ゲーです。

自分がいくら努力しても、自分が影響を及ぼすことができない不確定要素が大きすぎて、ベストを尽くすことはできますが、どんな努力をしてもすべての企業から内定をもらうことができません。

ただ、自分ができるベストを尽くしましょう。 この記事がエンジニアになりたい人への参考になれば幸いです。