新卒エンジニアの転職

先週末 2016-08-26 がグリー株式会社での最終出社日でした。
あとで自分で見返したり、あわよくば誰かの参考にしてもらったりするために、思うところを書き起こしておきます。

私服の従業員のイラスト(男性) | かわいいフリー素材集 いらすとや

経歴

アルバイトのときから、ちょうど4年間ほどお世話になりました。その間、研修を除くと5つのチームを異動しました。

0. 入社まで

  • 志望動機は2点。この2つは今から見てもよい判断基準だったと思う。
    1. 創業者がエンジニアだったこと
    2. プラットフォーム事業を世界展開していたこと。ちなみに GREE Grobal Platform (GGP) と呼ばれていた。
  • 就活のイベントで @naoya さんと話す。
    • 当時勉強していた応用情報技術者試験を「やってもしょうがないよ」(意訳)と言われ衝撃を受ける。
    • 「外資系企業はHQと日本支社じゃ全然違うことが多いから気をつけて」(意訳)とアドバイスをもらった –のにもかかわらず、次の転職先は外資系の日本支社です
  • 世間は就活も本格的に始まっていない中、2月には内定をもらい「終活なう」ツイートを達成する — 当時は生前整理のことを指すとは知る由もなかった
  • 内定者期間のあいだにコンプガチャ問題がインターネットを騒がせる。このこともあり、現在に至るまで2013年が新卒採用の最盛期。
  • プログラミング歴は短め。業界には小学生のころから始めましたっていうひとも珍しくないなか、僕は大学生になって始めた遅めのスタート組です — 一般論としては早いにこしたことはないんでしょうが、はてブのホッテントリなんかを見ていると30歳ではじめているひとなんかも見かけるので僕の経歴も参考になるかと思います

1. 2012年5月〜 プラットフォーム部 (アルバイト; 8-9, 1-3月は勤務なし)

  • 最初期はコミット権がなかったためpatchを作って渡していた思い出。
  • Gitの操作に不慣れでわけがわからなくなったためGitHubでフォークしたレポジトリを消そうとして誤って本家レポジトリを消失させる。詳しくは下記。

2. 2013年4月〜 Bootcamp

  • 全体研修: 割愛。
  • エンジニア研修: 某動画サイトのクローンサービスを作成するなど。

3. 2013年6月〜 プラットフォーム部

  • 社外でも著名な方など、優秀なシニアのかたに設計やコードのレビューをしていただいて得難い経験ができた。まともにテストコードを書き始めた。思い出深いタスクが多い。
    • 2段階認証の導入: (僕の貢献は小さいが) チームとして全社MVPを獲得。
    • リスト攻撃の対応・対策: セキュリティに興味を抱くきっかけとなった。
    • GREEサービスへのIdPによるログインを導入: Facebook, Google+, Yahoo! Japanをサポート。オープンな仕様に則りつつ、1人で設計から実装までやったので勉強になった。

4. 2014年11月〜 Garage Studio

  • C++11 on Cocos2dx でタワーディフェンスゲームを制作する研修。
    • ゲームプログラミングの奥深さの一端に触れられた。
    • 経路探索はライブラリ使用が不可だったのでA*アルゴリズムを自前実装した。
    • 当時まだ不安定だったCocosStudioに頼ったことは反省している。

5. QAグループ (以降、カレンダーが閲覧できなくなったので異動時期不明)

  • 割りと自由にしていたが、ビジネス面での貢献度が低かったので反省している。
    • e2eテストを書いたり
    • Test導入の手伝いをしたり
    • テストライブラリを作成したり

6. Japan Game事業本部

  • Docomoのdゲームに内製ゲームを移植するプロジェクトにアサインされた。
    • コードベースはあったものの、モダンなPHPに移行したり、AWS使ったりなど、パイロットプロジェクトとしての側面もありliterally換骨奪胎だったので重めのタスクばかりだったがオンスケでリリース。
    • 運用に乗り出してからも、新機能を実装して本家へ逆輸入したり、自動化で運用の負担を減らしたり、わずかながら消費面でも貢献できたのが良かった。
    • ウェットな文化に馴染まなかったこともあり、タスクだけこなしていると「技術力はあるが、やる気のない人」として評価され気味だった。ただ、他の複数の事業から誘いをいただくなど、仕事ぶりを見てはもらっていたと思う。
    • 正直にいうとウェブゲーム開発に情熱を見いだせず苦しかった。主力事業が好きな分野であることは大切。

7. 投資インキュベーション事業本部

  • ARINE [アリネ] リリース。今から改善してサービスを伸ばしていくフェーズで抜けることになってしまい心苦しいところ。
    • 新卒研修ぶりにRailsを使用して馴染むわぁという感じ。プロダクトへのオーナーシップが強かったこともあり、コードを書く楽しさはグリーにいた4年間で1番大きかった。
    • 定例ミーティングなどを通して田中さんの考え方に多く触れられたのはとてもよい経験だった。

失敗談

FailConっぽい題材として僕の失敗談を掲載しておきます。

1. 非開発者のためのGitHubレポジトリを消すのがどれほどありえないことか解説

スクリーンショット中心に説明してみますと、まずですね…

Danger Zone - github.com

こんな危なそうなページの、危なそうなボタンを押して、

Are you ABSOLUTELY sure? - github.com

「君、ほんっとーに消したいんだよね?」とか聞かれるのもものともせず、フォームにレポジトリ名を入力して、さらに「私はこの操作がもたらす結果を理解しているのでリポジトリを削除してください」と半ば脅しをきかせているボタンを押して、はじめてレポジトリを消せるんですよ。「やり直せないよ、これ」って言われてるのに。

これをやっちゃう人っているんですね? はい、僕です。

「アルバイトのエンジニアがレポジトリを消したらしいぞ」と聞いた諸先輩方は、きっとstupid userのミームを思い浮かべたことでしょう。

Stupid user meme

むろん、こういう権限を絞る機能は GitHub Enterprize (GHE) にもあるのですが、まさかこんな底なしの阿呆がおろうことかと当時は設定されていませんでした。
※このエントリをご覧の方で心当たりのある方がいらっしゃいましたら、今すぐ権限制御することをおすすめいたします。

なぜこんなことをやったかというと、僕の場合、当時はremoteが2つ以上あるレポジトリを経験したことがなかったのでrebaseでコンフリクトなどが起きてどうしようもなくなって自分でforkしたレポジトリを消すことに麻痺するようになっていたのだと記憶しています。

幸い、プロダクションなどへの影響はなく、消し去られたソースコードも分散型バージョン管理システムの恩恵をこうむり事なきをえましたが、ありえない失態として今でもいじられます。

素晴らしいアーキテクチャをありがとう、リーナス。

やってよかったこと・これからも続けたいこと

1. 技術書を読む

  • 読書は、水泳の「息継ぎ」のようなものです。継続的に息継ぎしないと長距離を泳ぐことはできません。
    • 情報技術の基礎を修めたひとですら日々勉強しているなか、いわんや独学者をや。※特に良かった本は後述しています。
    • 技術書に限らず、読書は良質なインプットです。まさに “Garbage In, Garbage Out” といえますが、よい仕事をするのに良質なインプットは欠かせません。
    • 読書のインプット効率は大変によく、大抵の本は著者と10回飲みに行っても足りない内容が書かれていますし、あわよくば著者とともに1つのプロジェクトを完遂したとしても得難い内容が書かれています。

2. プライベートで業務と違うことをしてみる

  • 新しい技術を試す、ライブラリ開発、iOS/Androidアプリ開発、ウェブサービス開発、各種コンテストなど。
    • 仲間内・あるいは自分用の organization を作成してみるのもよいでしょう。僕は最近ボッチ organization announce をつくりました。
    • 新しい言語に馴染むためにProject Eulerを解く人がいますが、それに類する方法としてライブラリを作成してみるのも1つの手です。細かく切りだされたコード片だと見通しも効きやすく、要件を実現するために必然的に他の良質なプロジェクトのコードを読むことになるので勝手に手元にベストプラクティスがたまっていきます。
    • 業務で利用しているOSSへコミットする心理的障壁も下がります。
    • 誰しも新しい技術を試したいものです。業務でみさかいなく導入するひとは迷惑ですが、勝手によそでやる分には誰からも文句を言われません。そのうち加減も分かってくるものではないでしょうか。
  • アウトプットで成果を出すのがビジネスパーソンの役割です。ソフトウェア開発者の場合、こんなに魅力的な練習場がころがっているのですから、利用しない手はありません。

3. 大学院に通う

  • 僕は品川にあるJAISTの社会人コースに通い始めました。週末は授業でなくなりしんどいですが、仕事をするわけではないのでリフレッシュにはなります。
  • 学業は良質なインプット。仕事とのバランスをとっていれば相互によいフィードバックとなります。
    • 実務経験は研究にも活きると実感しています。というのもACM CCS 2015の論文で git のメタデータを訓練データとして用いたアプローチがあったのですが、ずっと学術畑にいるとにピンと来なかったりするのではないでしょうか。僕が git について語るのは皮肉ですが。

読んでよかった技術書10選

良書といっても限りがないので、特定のプログラミング言語やミドルウェアに依存しないWeb系の本をあげておきます。

  1. 徳丸本
    • セキュリティとは、プロとアマで最も違いがでる分野ではないか。いわゆる「非機能要件」なので明示されないことも多いが、安心してユーザーに使ってもらうためには欠かせない。社内の「後輩新卒エンジニアにおすすめする本は?」という企画でも推薦した。
    • セキュリティ関連の本では『Hacking:美しき策謀』も大変な良書。”Hacker’s delight”を体験できるので興奮しながら読めるが、メモリモデルやネットワークプログラミングなどコンピュータサイエンスの入門書としても活用できる1冊となっている。
  2. コードコンプリート
    • 新卒時に社内の勉強会で読んだ本。複数人開発をするための導入用にかかれており、まさに新人にうってつけの内容だった。
    • 輪読しているときは「そんなことわかってるよー!」と思う箇所も多かった覚えはあるが、それほど網羅的に書かれているということだ。
  3. リーダブルコード
    • 多くの先輩エンジニアが「あー、これ新人には読んでおいてほしいわ」とつぶやいているのを見かけ、焦って読んだ覚えがある。膨大なコードを読んで分かってくる勘所を程よく1冊にまとめたことが評価されている理由だろう。
    • ソフトウェア開発業では「名付け」が大切な仕事の1つだが、本書は filter と書くよりも extract と書いたほうが意味が誤解されにくいなど具体例まで載っているので新人でも理解できた。名付けはより良いソフトウェアを書くためだけならず、マーケティング面でも重要である。— cf. 名前重要 by Matz
  4. Webを支える技術
    • Webとは何か。どんな技術要素がwebをwebたらしめているのか。
    • Web = REST = ULCODC$SS (Uniform Layered Code on Demand Client Cache Stateless Server) とブレイクダウンしていく。
    • 筋のいいURLは実装依存でなくリソースをあらわす名詞になっている、など。
  5. ふつりな
    • OSの提供するAPIやストリームの概念、パイプとフィルタのパターンなど。
    • 著者の美意識がほとばしる淡泊だが硬派で渋い文章。憧れる。
  6. SQLアンチパターン
    • 特定のRDBMSに依存しないアンチパターン集で、組織内の共通言語づくりができる。データベース設計が糞だと他が芋づる式に崩壊していくのでアプリケーションの根幹をなす。
    • 正規化などは知っている前提なので類書を当たるとよい。
    • O’Reilly JapanからDRMフリー版が購入可。
  7. テストから見えてくるグーグルのソフトウェア開発
    • 原題は “How Google tests Software” だけど、邦題のほうが本書の趣旨に沿っている。
    • 自動化などを「どこまでやるべきか」迷っている人は必見。むろんケースごとの規模でペイするかは変わってくるが、「ここまでやっている」事例を知っておけば自分のなかで判断軸をもてる。
  8. パタヘネ本
    • 授業の教科書として使用した。
    • 読み終えると「MIPSはいいぞ」ってなる。rebuild.fmなどでもよく言及される。
  9. ジョエル本
    • 著名なオピニオンリーダーの本。
    • 何が書いてあったかは忘れたが、かなりよかったという記憶の残滓だけはあるので入れてみた。
  10. 実践 機械学習システム
    • 動物本から唯一のランクイン。個人的には意外と動物本に「これぞ」というものは多くない。特に入門書は当たりが少ない印象。
    • Machine learningは流行しているが、本書は書名に偽りなく「実践」できる内容が詰まっている。研究ですぐに役だったが、それだけにここにあげた他の本に比べると廃れやすいかも。
    • DRMフリーはO’Reilly Japanからどうぞ。

総括

グリーのような優秀で真面目な人が多い職場で一緒に働けてとても感謝しています。おかげさまでまだまだ三流ではありますが、プロフェッショナルな開発者の第一歩をふみだせました。

タイトルの転職についてですが、志望動機にも記した通り、広く世界に通用するプロダクトに携わっていくという軸は変えずに新しい環境で挑戦します。

付記

「エンジニア」について

  • 本エントリはソフトウェア開発者を広く「エンジニア」と呼称する慣習に則りました。実際名刺のタイトルも「エンジニア / Engineer」でした。ただ、タイトルについては業務の実態はともかく、ビジネス上必要であればソフトウェアのみならずハードウェアもハックせよとの意図が込められているかもしれないです。

ウィッシュリスト

Author: @i05

A Tokyo based software developer, a grad student belongs to a security lab at JAIST, and a husband of my mrs.