はじめに
ホットペッパーグルメで開発を担当している亀山です。
時間が経つのは早いですね。
昔はあれこれ悩んでるうちに1年が過ぎてしまった記憶があります。
そんな、悩んでいた若かりし頃の自分（プログラマー1～3年目くらい）にアドバイスする感じでポエムを書きました。
どこかの誰かの参考になれば幸いです。
まずは現状使ってるもので進んでみる
インターネット上にはプログラミングに関連する様々な言語やフレームワークやライブラリがあり、日々議論や新しいものが生まれています。
PHPだと、日本だとまだまだCakePHPのシェアがあるけどLaravelの方が…いや他にもSymfonyやFuelPHPやYiiも…。
Javaだと、StrutsでXML地獄、Seasar2はサポート終わったけどDropwizardは日本で流行ってない、JavaEEやPlay FrameworkもいいけどSpringの方がコミュニティ活発そう。
JavaScriptだと、prototype.js,jQuery,Backbone.js,AngularJS,Vue.js,Riot.js,React系（react.jsやRedux）,Angular2…他にも〇〇があるよとかたくさん。
そもそも、数年前までaltJSが大量にあったけど基本はBabelでES6すればいいのような雰囲気になってたりします。
横文字が大量に出てきた際に経験が浅いと、「この言語は流行ってないからもう辞めようか？」とか、
「もっとイケてるフレームワークを使った方がいいのではないか？」という気持ちになるのですが、
まずは、今使ってる言語やライブラリやフレームワークをもう少し使い倒してみるのもよいでしょう。
理由としては、使い倒すことで足りないと感じる部分が実感として分かってきたりするので次に繋がることがあります。
他言語や異なるフレームワークと比較するにしても現状への理解が薄いと比較も難しいです。
※世の中にあるシステム全てがモダンかつ最適解であるなら誰も苦労することなんてないんや…。
（新規プロダクトの場合は、最初からモダンなものを使ってる場合もあるのでこの限りではないと思います）
ただ、レガシー過ぎるものに耐えられないのであれば改善提案を行って現場を変えたり
それも難しくてストレスを溜め込んでしまうくらいならプロジェクトの移動等を考えるのも良いでしょう。
あまり強い言葉を使わない
現状動いてるコードに対してクソコードとかウンコードとか駄設計とか言ってdisりすぎない。
特に個人に対して攻撃的に発言するのダメ絶対。
残念な設計やコードが産まれてしまう背景を上げればきりがないと思います。
_スキル不足…開発期間と人数…ハードウェアやネットワーク環境の制限…直前での仕様変更…許されるコード改修は極小のみ…_etc
調子に乗って過度なdisり発言をしてしまった為にチーム全体の雰囲気が悪くなり、結果として全体の生産性が下がってしまうという事態もありえます。
また、技術的負債解決の為にリファクタリングやプロダクトをリプレイスする際に、なぜ残念なことになったのか、当時の知見が必要になる場合もあるかもしれません。
その際に、過去にコードを書いた人を敵にまわすような発言は必要ないです。
「エンジニアとして〇〇じゃないと駄目」みたいなのもやり過ぎは良くないです。
進化・成長を止めない為に
まずは先人から学ぶために技術書を読むのが良いです。
どの参考書を読むかは、メンターや先輩にオススメの技術書を聞いたりすると自分のレベルにあった本を見つけられる可能性が高いです。
近しい人であれば仕事の合間などに、本の内容で分からないところを聞いたり出来るので一人で黙々と読むより理解が進みやすいです。
技術書を読む以外だと、やはり新しい技術やバズワードをネット等で調べたりする必要はあります。
※業務で必要になりそうなタイミングでしっかり調べればいいと思います。
（最初から最先端を追うことを目標にしてしまうと、ストレスの元となってしまうのであまりオススメはしません）
例えばバックエンドをメインに仕事をしているのであれば、サーバレスアーキテクチャは知っておいた方がよいでしょう。
時代と共に効率の良い設計だったりベストプラクティスは変わっています。
新しい情報をどこで入手するかは人それぞれだと思いますが、Twitterで著名なエンジニアをフォローしたり、PodcastのRebuildを聴いてみたり、ユーザーグループや企業が主催する勉強会やカンファレンスに参加するのもよいと思います。
※英語が得意ならGithubで人気のリポジトリを眺めたりとか
バズワードに踊らされすぎない
プログラミングには直接関係ないですが、新しいバズワードが出るたびに思い出すFacebookのポストがあるのでそれの紹介。（ビッグデータについて）
https://www.facebook.com/dan.ariely/posts/904383595868
日々新しいキーワードが出現しています。Twelve Factor、マイクロサービス 、DevOps、Infrastructure as Code、サーバーレス、ブロックチェーン…。
他社がやってるからうちも導入したい！という考えを全否定するつもりはないですが、結論ありきですすめるのは危険です。
開発・運用する組織、プロダクトの目指す方向によって最適解は異なります。
日本のIT業界だとどうしても、ITゼネコン状態で開発＆運用をパートナー会社に委託してる事もあると思いますが、
その状態で「サーバーレスやブロックチェーンを使いつつ、マイクロサービスでDevOpsな体制で開発を推進してください！」と言われても難しい部分もあると思います。
とはいえ、話題になるにはそれなりの理由がある事が多いので、概要や特徴を把握しておいて損は無いです。
定期的に振り返る
チーム開発ではKPTを使ってPDCAを回すことがよくありますが、それを自分自身でもやってみるとよいです。
個人的には自分のやってきたことや今後やってみたいことを定期的にGoogleDocsに書いたりするのが役に立ちました。
プロジェクトを移動だったり転職する際に非常に役立ったので、やってきた仕事だけでも記録を残しておくだけでも良いです。
KPTのポイントとしては、Try（やりたい事）を真面目にやり過ぎると、やりたい事が全然出来てない…鬱だ。みたいになる場合があるので、明確にやりたい事がないのであれば、ざっくりした方向性程度でもよいかもしれません。
（会社や組織の方向性もあるので、必ずしもやりたい事がやれるわけではないですし）
業務上で分からないかったところや詰まったところをまとめておき、
コラボレーションツール上に記載したりするとチームメンバーの役に立ったりするのでよいです。
コードでも文章でも良いのでアウトプットする習慣を身につけることは後々役に立つことが多いです。
技術書を薦めるなら
中小企業あるあるだと思うのですが、他社へ出向して様々な案件を転々としていた為、
自社のメンターや気軽に聞ける先輩が居なかったので、今思えば様々なことを遠回りしていた感が強いです。
膨大な数の技術書籍があると思いますが、当時の自分に薦めるならこの辺。
技術に特化するというよりは、考え方や基本的な事を抑えるような内容で読みやすかったです。
リーダブルコード
SQLアンチパターン
Team Geek
新装版 達人プログラマー
色々と偉そうに書いてるけどまだまだ成長中です！
今年も一人でIT系の勉強会行ってきた Advent Calendar 2016やったりしてます。
最後に一言、「あれこれ調べてわからないのであれば、テンパる前に周りに聞いたり相談してください！」