はじめに
新人プログラマ応援イベントのための記事です。そろそろ経歴が10年くらいになり、新人のときに知っておければいいなと思うことがでてきたので、整理してみました。
具体的な技術というより、仕事で必要なスキルをどうやって手に入れていくかという、メタ寄りな内容です。
5年くらい前にも同じテーマで書いた記事があります。よければこちらもどうぞ。
楽しいと思える瞬間を見つけよう
仕事に限らず、なにかを続けていくためには、「なんか面白い！」「うまくいった！」「なんか良いな」というような、プリミティブに楽しい・良いと思える瞬間が大事です。そう思えるポイントは人それぞれです。
- 思いどおりに動くプログラムが書けた
- きれいなコードが書けた
- 面倒な作業を自動化できて楽になった
- プロジェクトがうまくいった
- 新しいプログラミング言語を使いこなせるようになった
- チームメンバーのスキルがあがってきた
- 良い感じの作業フローが作れた
- やばい障害があったけど、短時間で復旧できた
などと、色々です。普段の仕事で、こういった瞬間があると、しんどいときでも踏ん張れるようになれます。
なるべく、自分だけで完結することで楽しめることがあると、周りの状況に振り回されず、自分の気持ちを維持しやすくなります。
逆に楽しいと思える瞬間が（本当に）全然ないなら、別の仕事を考えた方がいいかもしれません。
欲しい情報にたどり着きやすい探し方をみつけよう
技術の進歩も早く、いろんなものがでてくる時代なので、「事前に仕事に必要な知識を十分に学んでいる」ということはなかなか作れないです。大なり小なり、「必要になった時に、必要な情報を収集する」ことが求められます。
新しい情報をとりにいく（古い情報にひっかからない）
後方互換性を意識していたJavaも含め、各種のプログラミング言語はリリースサイクルが短くなっている傾向にあります。「以前なら有効な選択肢だったけど、今となっては悪手」ということは、よくあります。過去の記事の方が、ググったときに上位になりやすいこともあり、「今では使わない古い手法」を若い人がやってしまうことを、しばしば見かけました。
これを回避するためには、「バージョン・時期によって、ベストプラクティスや標準的なやり方が変わる」ことを知ることです。
- 使っているバージョンがリリースされたときと、同じ時期にかかれた記事を検索する
- 使っているツールのリリースノートがでたとき、やり方がかわったものがないかを意識する
といったことを、調べるときに意識するといいです。
google検索では、期間指定の機能があります。なるべく新しい情報が欲しいときは、1年以内に絞ったりすると、不要な情報を弾けやすくなります。
欲しい情報・最近のトレンドをキャッチするための情報源・習慣を作る
- QiitaやZennなどの、知識・知見を共有するサイトを定期的にチェックする
- 著名なエンジニアのtwitterなどをフォローする
- 勉強会などのコミュニティに参加する
- できる人がだいたい読んでいる技術本を読む
など、自分の興味がある分野の情報を、入りやすくしておくといいです。
（twitterフォローしてみたら、技術の話ほとんどない、みたいな話もききますが）
情報収集のやり方はこの記事が参考になるでしょう。
その中で、自分が今抱えている問題を解決する技術がないか、最近のトレンドでは、何に問題意識があって、どのようにそれを解決しようとしているか、をみておくと、技術のパラダイムシフトがあっても追随しやすくなります。
「できることの手札を増やす」ためと、「より上手くやる」ための２つのために学ぶ
日々、新しいツール、サービスがでて、使っているツールもアップデートされていきます。
いくらでも学習対象がある状況です。トレンドに出たものを闇雲に追っていたら、おそらくいくら時間があっても足りなくなるでしょう。学習するものを選ぶための判断基準を自分なりにもつといいです。
- 今の仕事では、他の人にお願いしているが、自分でできた方が効率が良さそうなこと
- （例）アプリ開発メインの人が、環境構築のための最低限のインフラ寄りの知識
- （例）アクセスログの簡単な解析
- これまでの仕事である程度上手くいっているが、もっと良くしたいと感じていること
- （例）ORMの機能でDBに登録しているが、処理時間をもっと短くしたい
- （例）動いているはいるが、コードが読みづらい
- （例）最近の、安全な強度のSSH鍵ペアの作り方
手札を増やす
システム開発の作業はどれもある種の専門性が求められ、「コードしか書かない人」「インフラ構築だけの人」「テストだけの人」というような、分業化が進んでいるケースもあるでしょう。一方で、コードだけ・インフラだけといった、部分の改善だけでは、難しいケースもよくあります。分業化すると、どうしてもコミュニケーションコストが発生します。
できることが増えると、ひとりでやることでコミュニケーションコストを減らせたり、両方の知見を生かしたよりよい選択肢が見えるようにもなってきます。なんでも屋になる必要もないですが、周辺分野の知識があると、問題解決のためにとれる選択肢が増えて、結果が出しやすくなります。メインにやっている分野の周辺から知識を増やすと無理になくやっていけます。
こちらの記事が少し近い話題をとりあげています。
より上手くやる・知識のアップデート
時間や予算などの制約があるので、現実的にはとれる手段は限られているものの、システム開発やコーディングには明確な正確があるわけではないです。その意味では、より良いものはいくらでもありうると言えます。「もっと良い形はないか」と、さらなる理想をなんとなくでもいいので、思い描く癖があるといいです。
今まで上手く行っているやり方も、状況が変われば、悪手にもなりえます。（逆パターンもまれにあります。）
わかりやすいのは、セキュリティ関連です。新しいアルゴリズムによって、過去のやり方が非推奨になるのはよくあります。
公開鍵暗号がわかりやすいのですが、私がエンジニアになりはじめた頃は、鍵長は1024bit以上が推奨だったような気がします。今では、2048bit以上推奨、できれば4096bitという雰囲気です。Ed25519にかわりつつあるようです。
こういったことは、コーディングレベルでも普通にあります。
多くの言語が、関数型プログラミングのパラダイムをとりいれつつあるので、今までのやり方のいくつか（大半）は、いわゆる高階関数を使った形で書き直せます。
最後に
動くものが作れるようになったら、保守・運用しやすいものを目指す
とりあえずは、動くものが作れるようになればいいです。（そこまでの学習コストを業界としてどう負っていくかは、難しいところですが）
システムは想定する動きをしていれば、価値が提供できるものです。
「動くけど汚いコード」 > 「綺麗だけど動かないコード」
この不等式はいつも言えることです。けど、この事実に（いつまでも）甘えてはいけないです。
システムはリリースしてからが本番です。
- あとから機能追加・変更がしやすいコード
- 運用作業がすくないシステム構成
になってるかは、リリース後にボディブローのごとく効いてきます。
この観点が弱いと、あとになるほど、放置するほど辛くなります。
単純・明快なシステムになるよう、そのときの最善を尽くしましょう。
仕事なので、どこかで割り切りましょう
仕事なので、締切があります。使える人数や予算にも限りがあるのが普通です。
納期までに動くものを提供するのが、最低限求められることです。なので、理想・最善を求めつつも、どこかで妥協・割り切りが必要です。なにを妥協するかも含めて、最善手を考えましょう。
やれる範囲でやっていきましょう
このご時世、エンジニアに限らず、どの仕事でもなんらかの学習が必要でしょう。
逆説的に言うと、ちゃんとやってると、割と簡単に、周囲より一歩抜きん出ることができます。
プライベートの時間全部使ってもいいですし、ゆるゆる・ダラダラやるのも、人それぞれです。
良いエンジニアライフを。