概要

書いたきかっけ、前置き

自社の社員や仕事関係者や知り合いなどで若手 IT エンジニア（だいたいエンジニア経験 3 年前後くらい）と話す際に、今後のキャリアや生き方などについて話すことがよくあり、割とためになるらしいので、文章に起こしてまとめた。

あくまで自分の経験や自分の周りの人の話などを基とした個人的見解。

目次

大まかに以下 3 つのカテゴリに分けて記載していく

• ① スキル・キャリアアップ関連 ← 本ページ
• ② 会社・働き方関連
• ③ 社会・生き方関連

スキル・キャリアアップに関する話

独学には限界がある

自己学習でいろいろ学ぶこと自体はとてもいいことで大事。 ただ、学んだことが足りているか、認識齟齬がないか、学習の方向性はあっているかなどは学んでいる時点で検証するのが難しい。 更に、難解なものについてはそもそも学ぶこと自体に多大なリソースがかかる。

何かを学ぶのであれば、学校や塾のように、理解している人に説明してもらうのが圧倒的に効率が良く正確。 その為、ある程度知識、経験があるエンジニアから教わったり、レビューやフィードバックを受けることは、よりよい成長する上では非常に重要。

日々仕事でレビューなどで成果物チェックを受けることもあると思うが、それには大きく分けて 2 種類のものがある。

1. 成果物が求められた要件を満たすか
   • これはどんなレビューアでも必ず実施しているもの。むしろ実施しないと PJ が破綻する。
2. 成果物がその時点で考えられる最適解か
   • 設計方針、コードの書き方などで、悪いところはなぜ悪いかを具体的に提示し、どういう方法が良いか明確な理由付けを指摘してもらうことで、レビューを受けるたびに確実にスキルアップができる。

技術志向な会社や PJ では 2 つともレビューアが実施してくれるが、そうではない場合、独学で学んでいるのとほぼ同じなので、あまりそういう環境で長くいるのはお勧めできない。

楽だと思ったら業務や環境を変える

日々業務をしていて、何も調べることなくすんなり進められたり、あまり頭を使わずにこなせるようになったりし、業務自体がほぼルーチン化してしまうことがある。 業務の内容や難易度にもよるが、ストレスなく仕事ができてある種の充実感が得られている状態だと思うが、それは裏を返せば今以上の成長がほとんどできていない、という状態でもある。

その為、そういう状態になったら、まず日々の業務で新しくできることにチャレンジすることが大事。

例

新人エンジニアでいうと、上流が書いた設計書通りに実装したり、他の実装を横展開したり、といったことを最初にやると思うが、それができるようになったら、

詳細設計をしたり、新規の実装をしたりなどをして、ジュニアレベルのエンジニアの業務ができるように、それらができるようになったら、

技術選定をしたり、基本設計をしたり、といったことをしてみて更に上のランクのエンジニアの業務ができるように、それができるようになったら・・・以降繰り返し・・・

といったように、段階を踏んで徐々にできる範囲を広げていくイメージ。

会社に属していればたいていの場合は、社員の成長を考慮し、その人ができるレベル＋ α の業務を振ってくれたり、役職アップや部署移動などで業務内容が変わったりして、そういったマンネリ化は回避できるはずだとは思う。

ただ、もしそれらが行われずずっと同じようなレベルの仕事をやり続けらされるのであれば、自ら志願して業務内容を調整してもらったり部署移動をお願いしたりする。 もしそれが叶わないなら転職してでも環境を変えたほうがいい。

プログラムを書くことだけがプログラマーの仕事ではない

プログラムを書いてただ動くものを作るのがプログラマーの仕事ではない。プログラムが義務教育で必修化された現代では小学生ですらプログラムが書ける時代。

社会人として、プロのエンジニアとして、責任持った成果物を提供することがプログラマーの仕事であり、例えば、

• 書いたコードがバグや業務要件的な不具合がなく確実に正しく動くか
• 抜け漏れなく正しくテストコードの作成及びテストを行っているか
• 性能及び負荷を考慮しているか
• セキュリティリスクが無いか
• 可読性がいいか
• 変更がしやすいか ...etc

などなど、報酬をもらいプログラムを書くということは、顧客へ提供するものは常に最高の品質で無ければならない。

完璧なものを作ろうとするとそれなりの知識経験が必要な為、経験が浅いうちはなかなか難しいが、それらの意識が常にあるかが重要。 私がレビューア経験してきた中で、その辺を意識しているかしていないかはコードを見れば一目瞭然で、雲泥の差が出る。

TIP

自分の作成した成果物に責任を持てない、他力本願や他の人に迷惑をかけることを何とも思わないようなプログラマーは、厳しい言い方だがいないほうがプロジェクトの効率が上がるのが現実。

• レビューアの人が見てくれておかしなところがあったら指摘してくれるだろう
• 不具合やおかしな書き方のコードがあっても他の誰かが直してくれるだろう
• システム障害が起きても上流の人や運用の人が対応してくれるだろう
• テストをちゃんとしなくても誰かが発見してくれるだろう

などなど、残念なことに何年もエンジニアやってる人でもそういう人は多々見かける。 そういう人になって苦労しないよう若いうちからしっかり意識し習慣づけするのが大事。

インフラ系のエンジニアも同様で、昨今クラウドの普及やハードウェアスペックの向上により、OS、ネットワーク、セキュリティ、ディスク、冗長化、バックアップ、ログ、監視...etc などインフラの根幹となる知識が無くてもそれなりのインフラが作れるようになってきた。

それにより、もっといい構成にできるのに、他の PJ やネットや本の構成を丸っと移したような設計になったり、非機能要件がそもそも満たせてなかったりと、「とりあえず動いてるからヨシ！」的なものを何の躊躇いもなく出してくる人が増えてきた。

プログラマーの欄に書いたこと同じで、

• 要件を確実に責任もって満たす
• 現時点のベストプラクティスを出す

といった意識を常に持っておくことは、どんなエンジニアでも成長する上では必ず必要。

学んだことはアウトプットする

インプットだけでは学習対象のことの半分も身についてなく、しかもすぐに忘れてしまう。 例えば、

• 勉強会やセミナーに行った
• 本を 1 冊読み切った
• web の教材やチュートリアルを最後までやり切った

など一区切りついた時に達成感が得られ、そこで技術が習得できたと錯覚しやすい。 確かに、インプット前よりは確実にレベルはアップしているが、冒頭書いた通り、それはまだ完全な状態でなく、そこから学んだことをアウトプットして完全に身に着けることが大事。

アウトプットするということは、必然的に責任が生じ、アウトプットする過程で、深堀りや関連知識の取り込みなどをせざるを得なくなる為、そこでより深く広く、そして記憶の定着が行われる。 エンジニアはよく実務経験が重要、とされるのはこのためでもある。

TIP

アウトプットの方法はブログ、イベント登壇、個人開発、人に教える、など様々あるが、やはり日々の業務を通じてアプトプット、すなわち自分の学びたいことが業務に関連しているというのがもっともベスト。

ただそういった状況は、毎回配属ガチャ SSR 引き続けらる強運がいるか、自分で仕事を選べるレベルの技術力や役職などが無い限りなかなか難しい。

そういったときは、会社や PJ の風土にもよるが、スキル向上の意識がありそこまで日々の業務が常に逼迫していないのであれば、社内勉強会の開催や定例 MTG 開始前に LT をする、みたいなことをお勧めする。

• 全く知らない人にアウトプットするよりハードルは下がる
• フィードバックも受けやすい
• アウトプットされる側も新たな発見がある
• メンバー間でコミュニケーションも取れる

などでいいことばかりなので是非提案してみるのがいいと思う。

自身のスキルが今どれくらいのレベルなのかを知る

エンジニアのスキルを定量的に計るのは、測定対象が膨大かつ人の考えにも左右されるため基本的に難しいが、一つの指標として計ることはできる。

roadmap (opens new window) サイトで自身の該当するまたは求められるエンジニア種別を見て、それぞれの技術ができるかを見れば何が足りなくて何が必要かが見えてくる。

当然、各技術に対して知見が 0 か 1 かという話ではなく、修練度もあるので、参考までに私が会社などで使っている指標を記載しておく。

レベル	対象技術への知見
0:未経験者	まだ使ったことが無い
1:初学者	ネットや本の内容を参考に、基本的な概要は理解できて、最低限作成及び動作させることができる
2:経験者	基本知識をベースとして、1 から自分の設計を考案し作成できる
3:理解者	応用的なやりかたや、既存の仕組みで解決できないようなことを代替策などで対応できる
4:熟練者	対象技術の主要なユースケースをほとんど把握していて、対応できる
5:上級者	技術仕様を把握していて、仕組みの改善や派生機能の追加などができる

目安として、実務でやっていけるのは最低でもレベル 2、できればレベル 3 は必要。

常に自身のスキルレベルがどの程度かわかり、今後何が必要かを知っておくことで、キャリアの選択や進む方向の道が大きくそれることはなくなる為、一度自己評価としてやってみてほしい。

また、自己評価した内容を有識者にも伝えて、自己評価の内容が正当性あるのかも確認することで、より精度は高まる為、可能であればそれを実施することを推奨する。

DANGER

逆に絶対やってはいけない自己評価の方法もある。

それは、自分の身近にいる人と相対評価でスキルレベルを図ること。 周りのレベルが高いところだと挫折してモチベーションが下がりがちになるし、周りのレベルの低いところだと勘違いして天狗になり成長性が下がる。

良い子は真似しないように。。。

所感

まあぶっちゃけ若いうちに成長できる環境にいられるかどうかは運の要素強い。