はじめに

※この記事は社内の新人エンジニア・最近卒業して就職したインターンに向けて書いています。

ユアマイスター株式会社というスタートアップでエンジニアをやっています。
メインはWEBアプリケーションのバックエンドです。

大学時代はとくに留学もインターンもせず、休学を挟みながら6年通ってノリと勢いでSIerに就職しました。
TOEICもやってないし、資格もとってないし、入学時の偏差値は余裕で50を割っていました。

そんな自分が未経験の中で飛び込んでみてやってよかったな、ということをまとめてみました。
スタートアップ特化の視点のネタはこちら

あらゆる手を使って仕事を早くやる

便利なツールはたくさんあります。
そして、それらを使いこなすこと、作ってしまうことが大事です。

• 各エディタやIDEの拡張機能やクリップボードの拡張を使う。
• ちょっと面倒なことはスクリプトを書く。
• 先輩が勉強するときに使っていたメモをもらう。

仕事を想定の1.2倍早くやれば、きっと新しいことにチャレンジするチャンスをもらえますし、空いた時間で勉強できます。
仕事が遅い人にチャレンジのチャンスはありません。
雑になってはいけませんが、スピードは一つの共通の尺度として語ることができます。

定番ですが、お世話になっています。

クリップボード拡張 クリップボード拡張Macアプリ「Clipy」を公開しました
APIのテストツール Advanced REST client
スクリーンショット Skitch

インプットはとにかく量を増やす

体系的な知識も重要ですが、私はまず面を広げることを意識しました。
とにかくQiitaのトレンドを読む、そして知らない単語をググる、などです。
別に使えなくても最初はいいと思います。
知識の引き出しをとりあえずたくさん作ることが大切です。

エンジニアは覚えることが膨大にあります。
文系未経験だとそもそも知識量が足りなさすぎるので、薄くてもいいので「なんか聞いたことがある」「何となく意味がわかる」というレベルの知識を増やしましょう。

究極のIT系最新技術情報収集用Slackチーム公開 - モヒカンSlack -
Qiita トレンド
はてなブックマーク - 人気エントリー - テクノロジー

英語から逃げない

新卒一年目時代にJSF2.0という技術を使った開発案件をやりました。
その当時のバージョンにはそもそも不具合があり、どうしてもやりたいことが実現できない...
(確かc:forEachの中でajaxを実行すると上手く動かないとかそんなの)

どんなにググっても日本語の情報が出てこず、ひたすら英語のドキュメントやStackOverFlowを読みました。
結果として「それそもそもの不具合だから手動で実装しろ」と言い争っているどこかのフォーラムの記事を見つけたのを覚えています。

わからない単語はググればいいし、サンプルコードがあれば実行してみるとなんとなくわかります。
とにかく逃げないことが大事です。

CUIから逃げない

エンジニアは多分CUIから逃げられません。
まずは拒否反応をなくし、慣れましょう。

Linuxとシェルスクリプトから逃げない

サーバサイドをやるならこれも多分逃げられません。
最初はディレクトリとパーミッションの仕組みを理解できるまでひたすら触りましょう。
ログ解析などはよくある作業なので、整形や抽出はささっとbashで書けるようになるといいと思います。

いきなりLPICやスクリプトの本を読み始めると挫折しやすいので、「現場のエンジニアさんが使っている便利なスクリプト」を解説してもらうのがおすすめです。

不具合特定はタイムアタックを意識する

エンジニアの仕事は大体不具合の特定です。
新規実装でも常に不具合と戦いながら進めます。
自分の中で不具合を検索するための辞書を作り、探索のアルゴリズムを磨きましょう。

車輪の再発明をやってみる

JavaだとJSON<->POJOのパーサーとかを作って遊んでいました。
あとはソートアルゴリズムの再実装なども鉄板ですね。

「ソート」を極める！ 〜 なぜソートを学ぶのか 〜

目の前の仕事から学ぶ

眼の前にある仕事がつまらない、同期は面白そうなことをやっている、という気持ちが芽生える時があります。

つまらないのはそれに知的好奇心をくすぐられないからです。
できる、分かっている、というのは思い込みです。
眼の前の仕事の中にも知らないこと・工夫できることはたくさんあるはずです。

単純作業こそ効率化や自動化が入り込む余地があるはず。
その工夫を楽しみながら学ぶ姿勢を持ちましょう。

SQLをひたすら書く

ORMを前提としたWEB開発が主流になったため、そこまで複雑なSQLを頻繁に書くことはなくなってきました。
しかしながら、ORMでは速度面で問題があったりする場合や、とにかく巨大なデータを扱うバッチなどではまだまだSQLのチューニング技術は必要とされています。
ビックデータなどの分散処理基盤であるPrestoやHiveも、SQLを使用して処理を行いますし、データ分析としてBIツールを導入した場合は多くの場面で使うことになります。

SQLは過去の遺物ではありません。
プログラミング言語やフレームワークの流行が移り変わっても、なかなかなくなることはないでしょう。
RDBMSの違い(Oracle <-> MySQLなど)についても勉強しておくと非常に役に立ちます。

津島博士のパフォーマンス講座

データ構造の設計に情熱を持つ

私は2年目でひたすら「WEB APIを作り続ける」という仕事をしました。
毎日XMLとJSONの設計を続ける日々...
画面もない、アプリの開発もできない、という状況でしたが、だんだん面白さが分かってきました。

システム開発において、データ構造は非常に重要です。
データ設計がシステムの速度や柔軟性、拡張性や堅牢性の大きなファクターとなります。
より遠い未来を見通し、強くしなやかなデータ設計を行うには様々な開発の経験が必要とされます。
ER図をひたすら書かされているとしたら、それは非常に貴重な経験です。

4ステップで作成する、DB論理設計の手順とチェックポイントまとめ

オブジェクト指向を常に意識する

今でも気を抜くとダメなコードを書いてしまいます。
「オブジェクト指向を教える」ということは「自転車の乗り方を教える」と同じだと思っています。
スッと乗れる人もいれば、補助輪(サンプルコードや本)を使いながら転び続ける人も居ます。
乗れるようになってもたまに転ぶかもしれません。

ただし、いつまでも「自転車に乗ることを拒否」したり「補助輪を外さない」でいると乗れるようになりません。
いつも念頭に置いて、ある時きれいなコードが書けるようになるものだと思います。

オブジェクト指向とは結局何なのか あるいはプログラミングをする上で気をつけるべきたった一つのこと
オブジェクト指向の法則集

できないことにチャレンジする

エンジニアとして働いて1年位経つと徐々にできることが増えてきます。
その頃には仕事を任されて、更に1年経つと社内ではその分野の第一人者になれるかもしれません。

その状況はとても気分がいいですが、非常に危険です。

ぜひ3年経つまでは「やったことがないことがたくさんある」分野で仕事をしましょう。
できないこととぶつかることで自分の知識や能力は伸びていきます。
そして異なる知識や技術、言語を経験することでその共通点を抽象化して意識し、未知への耐性がつきます。

一つできるようになったら次のこと、言語もインフラもいろいろなものにチャレンジすると良いと思います。

事業と開発をつなげて考える練習をする

特にSIerですが、自分の開発は「どこかの誰かが事業上必要だから発注した」案件であることが多いです。

ですが、作っているシステムは必ず誰かが使います。
その誰かが関わる過程でお金が発生し、それが巡り巡って給与として支払われます。

その仕組みを理解している、というのは職業エンジニアとしては最低限の責任だと思います。
また、ユーザとマネタイズの仕組み、自分の立ち位置を理解することは自分の仕事のモチベーションに大きく寄与します。

異なる職能を持つ人と交流を持つ

エンジニアはエンジニア同士で閉じた世界を作りがちです。
ですが、エンジニア以外にも沢山の人が仕事には関わっています。

意外と犬猿の仲になりがちですが、営業さんとは仲良くしましょう。
営業さんはユーザの直接の声を聞ける存在です。
全てを聞き入れる必要はありませんが、その発言の中に開発のヒントが詰まっていることが沢山あります。

また、会社によって呼び名が違いますがマーケターやアナリストなど数字を扱う職種と話してみるのは面白いです。
データ分析や、エンジニア以上に集計SQLのプロが居たりします。

自分のモチベーションの源泉を知る

毎日黒い画面に向かってキーボードを叩き続ける、その仕事は楽しいですか？
いつも楽しい人は少ないと思います。

では、楽しいときはいつでしょうか？

どんな仕事にやりがいを感じますか？

それを早期に明確にできれば、成長スピードは飛躍的に伸びると思います。

私は事業をグロースさせることが何より楽しいです。
1行の美しいコードを書けた時に感動します。
チームで大きな何かをやり遂げたときは嬉しいです。

何か心の拠り所があると、精神的にやられることが少なくなります。

良いエンジニア、というのがなにかは未だにはっきりしませんが、成長のヒントに慣れれば幸いです。