ジュニアエンジニアからの相談
シニアソフトエンジニアのriddleです。 このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回は、お問い合わせをいただきましたので、回答していこうと思います。 初めまして、現在、SaaS系のメガベンチャーでエンジニアをしております、
隣の番号班と申します。 今回は、相談したいことがあり、お便りをお送りしました。 私は、今の会社に入って2年目になるのですが、
ジュニアエンジニアとして入社しており、 社内の優秀なエンジニアと比較すると、技術力が弱いと感じます。
社内の優秀なエンジニアを見ていると、 皆さん、言語仕様やライブラリに精通されている方が多いのに対して、
私は、言語仕様は基本的なことしか知らないですし、 ライブラリ等にもあまり明るくないのが現状です。
そこで、技術力を上げるために、 自己学習を進めようとしているのですが、
最適な方法がわからず悶々としています。
ぱっと思いつく方法としては、
1.自社プロダクトのソースコードを学んで、 社内の優秀なエンジニアから学ぶ。
2.個人開発を通してアウトプット駆動で知見を増やす。
3.技術書等の外部の情報をもとにインプットを増やす。
以上のような選択肢が挙げられると思いますが、 どれが良いのか判断がつかない状況です。
私のようなジュニアエンジニアの最適な勉強方法について、 リドルさんのお考えをお伺いしたいです。
参考までに私の経歴をお伝えすると、
新卒ではSIRに入社し、ウェブシステムの運用保守を半年、 開発を3ヶ月ほど経験しました。
他はコンサル1年目のようなExcel Powerpoint授業をしていました。
そして2年弱でその会社を辞めて、今の会社に転職し、 社会人歴で言うと現在で4年目です。
社内ではフロントからバックエンドまでのフルスタックで開発しています。
最近はAIで開発スピードが加速していることも伝わって、
エンジニアの役割も広がり、 エンジニアもやりつつPDMのような動きもしています。
「最適な勉強法」の捉え方
はい、お便りありがとうございます。隣のバンゴハンさん。
そうですね、2年目というところでAIも盛り上がってきている中、 どうやって自分の価値を高めていこうかとか、
周りにどうやって追いつこうかというところで 悩まれているんだなということが伝わってきました。
隣のバンゴハンさんに限らず、こういった悩みを持っている方は 非常に多いんじゃないかなと思いますし、
もし自分が同じ立場だったとしたら、 うまく動けたのかなというのは結構思います。
だいぶ僕はもうちょっとくすぶっていた側の立場ではあるので、
隣のバンゴハンさんが実際に転職をされて環境を変えて、
いかしがし開発をしているというところから考えると、
だいぶ過去の自分よりは前に進んでいるというイメージを受けましたね。
そんな中でどういうアドバイスをしていこうかなというところで、
まず最適な勉強方法について教えてほしいと言われたんですが、
最適な勉強方法というのは僕は知らないというのと、
最適な勉強方法は追い求めない方がいいです、前提として。
結局目の前の仕事をいち早く終わらせるためのスキルが欲しいという話なのか、
中長期にわたって状況の変革に対応できて、
社会の荒波にとかエンジニアの市場状況とかにも
そんなに左右されずに生き残っていくみたいなところが目標になってくると、
結局みんなと同じことをしていてもダメだし、
かといって誰かにとって有利な方法が自分にとっても有利かどうかというのは、
たまらない可能性もありますよね。
例えば、YouTubeを見てめちゃくちゃ覚えられる人が、
紙に書いて覚える方式は全然ダメみたいなこともあるでしょうし、
その逆もありますよね。
なので一見回り道にしか見えないようなことなんだけど、
やってみたら意外と役に立ったみたいなこととか、
いろんな方法が考えられますので、
まずは最適な方法を知るとか聞くとか探すとか、
そういうのはなるべく避けた方がいいかなと思います。
なのでがむしゃらにいろいろやってみるというのが、
基本スタンスでまずいた方が良いかなと個人的には思いますね。
では早速実際の回答に移っていきましょう。
「技術力」の定義と本質
技術力を上げるというのが今回質問のキーテーマかなと思いますので、
こちらについて深掘っていこうと思うんですけれども、
ここで言う技術力を上げる言葉が、
抽象度がすごい高いなと思って、
自分も昔よく言ってたんですけど、
技術力を上げたいから転職しようと、
技術力が高いコミュニティに入ったら自分も引き上げられるだろう、
みたいなところの文脈でいろいろ言ってたんですけど、
じゃあこの技術力って何だって話じゃないですか。
例えば周りの人はライブラリの使い方とか言語仕様をすごい知っていて、
自分は全然知らないというところにギャップを感じているという話があったんですけれども、
例えばですね、隣の番号班さんが、
それらをマスターしたとしましょう。
そうしたら明日から先輩たちと肩を並べて自信を持って
仕事ができるかどうかをちょっと考えてみてほしいですね。
どういう現場にいらっしゃるかわかんないんですけれども、
大半の現場においては、
ライブラリの使い方や言語仕様を覚えたっていうのは、
とてもじゃないけど多分肩を張れる状態じゃないと思うんですね。
それ以上に仕事を進める上での大事なことって多いので、
例えばですけど、どういう案件かわかりませんが、
適当に流通業界だとして、
流通に携わるシステムを作っているとしましょうと。
僕は別に流通全然知らないんですけど、
例えば在庫とか引当とかそういう概念があったとして、
そのドメインに対しての知識が全然ない状態で
機能を作ろうとしたときに、いくら言語仕様や
ライブラリの使い方に精通していたところで、ほぼコードを書けないと思いますし、
書いて何とか動いたってところまで行ったとしても、
例えばこの業界はこういうところが結構ボトルネックになるので、
拡張性高く作っておかないといけないよねとか、
流通業界におけるセキュリティ的な観点としては、
こういうところよく突っつかれるから、ちゃんと手厚く見ておこうとか、
そういうところ絶対ありますよね。
また単純にそのドメインのものをシステムに落とし込む際にも、
DDDみたいな考え方もありますが、
モデリングどうやってやっていくんだとか、
モデリングに合わせてデータベースの設計どうしていくんだとか、
またフロントエンドはどういう形でデータを取り扱って、
うまくUI、UXを担保した上で表示するんだとか、
実装するんだみたいなことって、
いろいろ無限に考えることってあるじゃないですか。
という業務の成功にはいろんな副次的な、
いろんなスキルの掛け算の結果が成り立っているものですよね。
多分これらをひっくりめて技術力って呼んでしまってもいいかなと思うんですけれども、
さすがに広すぎるんで、もうちょっと区分した方がいいと思いますが、
いわゆるライブラリとか言語仕様っていうのは、
あくまでその一端にしか過ぎないですし、
仮にそこ知らなくても、そこって詳しい人に聞けばいいし、
AIに聞けばいいしっていうぐらいの話になるんですよね。
ってなってくると、多分今悩んでいるのは、
ライブラリの使い方とか言語仕様に明るいっていうところではなくて、
もうちょっと仕事を進める上で、
自分がイニシアチブを取れる領域が周りの人に比べてだいぶ低くて、
その追いつき方が分からないっていうところにあるんじゃないかなと思っています。
これがまず的外れだったらごめんなさい。すみません。
得意分野の確立とスキルアップ
これよく言われるんですけど、結局は先輩と自分との
差分を見つけて、何が先輩ができて何が自分ができないのかっていうギャップを
徐々に埋めていくっていうのが一番の近道なんですね。
単純にその目の前の業務をこなすという意味では。
っていう時において、そのギャップを埋めるために何をすればいいかっていう話で言うと、
ちょっと話を戻しますが、周りの先輩とかを見て
技術力高いなと思った要因の一つはおそらく
言語仕様とかライブラリの使い方ではなくて
機能の作成とかバグとかに直面した時の引き出しの多さとか
思考の深さとかレスポンスの速さとか
そういうところからこの先輩は技術力あるな、自分はないなって
思ったんじゃないかなと思うんですね。これもまず外れだったらすみません。
こういう状況においてどうするのがいいんだろうかって話で言うと、
まずはその現場においての自分の得意分野を一つ
何でもいいから確立するっていうのがよくある方法です。
これは別に何でもよくて狭くてもいいんですよね。
例えばUIXの話に明るくなってもいいし、
バックエンドとかに詳しくなってもいいんですけど、ずっと後々の
キャリアにつながる方がいいかなと思っていて、例えば将来デザイナー系の方に
フロントエンドに進みたいのであれば
UI、UXの一部の例えばアクセシビリティに
明るくなるとか強くなるみたいなところでもいいでしょうし
あとはデザインシステムのうまい運用の仕方とかそういうところに明るくなっても
いいんでしょうけど、もうちょっとバックエンド寄りのところを
主軸にしていきたい場合はちょっと離れてしまうので
まずは注力する分野、例えばインフラとか、今インフラは
やっていらっしゃらないっていうことだと思いますが、インフラ、バックエンド、フロントエンド、モバイルとか
注力する分野を決めます。現場で使っている
技術の考え方とかを分解してみましょう。どういう言語で、どういう
フレームワークで、どんなライブラリを何の理由で使っていて、システム的な
アーキテクチャはどうで、ソフトウェアのアーキテクチャはどうで
サービスはどんなサービスがあって、どういう機能を有していて
そのサービスはどういう役割を持っているのか、この機能はどういう役割を持っているのか
関数とかメソッドとかモジュール単位の責任分解
点はどこなのかって、たぶん自分たちの作っているサービスのことを
深く見ていくと、いくらでも細かくカットできると思うんですけど
そういうのをまず分解してみて
分解した要素のうち、自分の理解度にレベルを
つけてみるといいと思うんですよ。0、知らない。1、知ってる。2、説明できる。
3、自分で設計構築できる。4、さらに高められる
既存の問題点を上げられる、みたいな感じでやっていったときに
その細かく分類した一つ一つが、例えばインフラの
既存のアーキテクチャについては語れます、作れます、だけど
このアーキテクチャにどういう問題があるのかは分からないとか
今現状インフラのアーキテクチャにこういう問題が起きているけど
それを解決するための方法は分からないってなったら、その方法を
調査したりとか担当して解決に導くとかを通じて
スキルを蓄えるとか知見を蓄えるっていう感じになるんですよね
みんなそんなに計画的にやってるかっていうとそうじゃなくて
結論、ずっと仕事してるといろんな障害とか機能追加とか依頼とか
バンバンバンバンって飛んでくるんで、それを一個一個愚直に解決していくと
これ前やったことある、こうだったよなとか、これ失敗してるの見たら
だからこうしよう、みたいな経験が積み重なっていって
結局その広がって技術の深さが出たように見えるみたいな感じなんですよね
からくりとしては。なのでまず自分の中で鍛えたいポイント
これは大きなジャンルで決めて、それに関する
社内のシステムのうちこういう要素あるよね、自分はこの辺に
弱そうだよねってなったら、それに近そうなタスクから
持って行ったり、そういうタスクを多く振ってもらうように
冗長に調整した上で、そのタスクを通じて自分の理解度不足なところを
一個ずつ補っていくっていうやり方が一番
再現性が高いと思います。なので最初にいろいろ
現場経験と個人開発の比較
これの方法どうですか、みたいなのを書いていただいて、例えば
自社プロダクトのソースコードを読んで、社内のエンジニアから学ぶとか
個人開発を通してアウトプット駆動で知見を増やすとか、技術書等
ハーフアリエンスとかの外部の知識をインプットするみたいなこと
どれも言っていいかなと思うんですけれども、一番
個人的に伸びたなと思うのはやっぱり現場で経験したことを
通じて学ぶことが何よりも力になるんですよね
それは毎日8時間ぐらい働いてりゃ、週で40時間ですから
40時間目の前のタスクに集中できたり
そこで自分なりのアプローチで答えを見つけて解決できるようになったら
そこが一番の成長の機会なので、まずそこを生かさない手はないと
ってなった時に、個人開発とか全然やってもいいですし、好きなもの
好きなように作れるっていうのは言っていいんですけど
開発するときって作りたいものを作るんで、勉強したいものを作るわけじゃないので
そんなに学びにならなかった経験は個人的にはありますし
あと、結局チームでやるとチームの中で合意を取って進めるとか
この設計がなぜ良いのかをチームメンバーに説明する機会も
必然的に訪れると思うので、そういうのが個人開発だとないので
新しい設計採用しました、終わりみたいになっちゃうので
あんまり学びが薄いというか、書いた時に
ちょっとこっちの方が書きやすいなとか、多少回収しやすいなとか
そういうのは身をもって分かると思うんですけど、それを周りに
メリットを説明した上で導入進める難易度と比べると
だいぶ低いかなと思います。なので、基本的には自分の
今やってる仕事に主軸を置きながら、そこから
ちょっと半歩ずらす形での個人開発とか、半歩ずらす形での
情報収集とかをして、それを内部の仕事に還元していって
さらに仕事の質を上げていくとか、仕事の幅を広げていくっていうところが
一番レベルアップとしては近道かつ学ぶことも
多いかなと思います。その上で周りとの関係性も
構築すると、自分にとっての美味しい仕事みたいなことに
多く巡り合うことになるので、成長して成果出して
美味しい仕事をもらって、またそれで成果を出してっていう
いいスパイラルを形成できるんですよ。エサ屋にいたなら分かると思うんですけど
つまんない仕事って多いじゃないですか。つまんなくて身乗りの
あんまりないというか、スキル的な意味ではあまり経験値が詰めない
ような仕事ってあるじゃないですか。そういうのにやっぱり自分の時間取られちゃうと
大変なので、それよりかはもうちょっと
これやったら今自分のレベル絶対に上がるぞみたいな案件をポンポンポンって
こなしていく方にフォーカスできると、もうすぐに先輩と肩
なべらべられると思います。同じその界隈とか
ジャンルじゃなかったとしても、自分の得意分野をバーンって伸ばしちゃえば
結局その何かしらに詳しい人っていう意味では肩なられたことになるので
意外と早くなれると思います。
まとめと今後の展望
ということで今回は隣の番号班さんから
4年目のエンジニアとして悩んでいる
技術力の伸ばし方というところを回答してみました。
技術力の伸ばし方というか、会社で学びを
最大化するための方法みたいな話に変わってしまったので申し訳ないんですけども
自分の中ではこうかなと思います。
このポッドキャストはハッシュタイトルで皆様からの感想やコメントを募集しております。
今回のように皆さんが日頃感じている悩みであったりだとか
実際にどういう風に働いているんだっていうところだったり
シニアエンジニアの生態みたいなところも質問があればお問い合わせいただければ
回答させていただきますのでよろしくお願いいたします。ありがとうございました。
