先輩エンジニアの技術トレンドを掴む力をちょっと言語化してみた

はじめに

NCDC株式会社に入社して4ヶ月が経った。
その中で、先輩エンジニアの技術トレンドを掴む力がすごかったので、自分なりに分析してみました。

なぜそう思ったか

以下は先日のSlackでのやり取りである。

NCDC標準として、Pythonのパッケージ管理ツールに何を選定するかという話題になった。
最近のPJではrye使ってるからryeでいいのでは？と言っているのが自分（考えが浅い）。
今後のトレンドを先読みしてuvも入れようと言っているのが先輩エンジニアである。

何気ない会話かもしれないけれど、自分はuvなんて初めて聞いたし、ryeの開発者のブログを見るなんていう発想は自分には全くないもので驚きだった。

そこで技術選定時の思考の流れを知りたいなと思い、1on1の際に聞いてみた。

技術選定時の思考

一般的な技術選定時の思考ってこんな感じだと思う。（少なくとも自分はこんな感じ）

1. 技術選定をする場面が来る
2. ネットで検索をする（AIも使ったり）
3. いくつか記事を読む
4. メリット、デメリットを踏まえて技術選定する

先輩エンジニアも大きくは変わらないけど、異なる点が2つあった。

異なる点その1：ステップ0が存在する

1. 技術選定をする場面が来る

の前に、日頃から情報収集をしている。
先輩エンジニアの情報収集元は以下であった。
Zenn、Qiita、Twitter、Googleアプリ。

Zenn、Qiita、Twitterはよく聞くが、Googleアプリでの情報収集は初耳だった。
自分の検索履歴をもとにおススメのNewsや記事が出てくるから、そこから情報を得ることが多いそう。
以下の記事を書いたきっかけもGoogleアプリのNews記事だったそう。
https://zenn.dev/ncdc/articles/df170f524d9c0c

そんなこんなで今年の2月頃からuvの存在は知っていて、実際に使ってみたりしてたそうです。
つまり、ステップ2,3,4の思考は技術選定をする場面が来た際にはほぼ終わっている。。。

技術選定はヨーイドンのかけっこではない、フライングし放題なのだ。

全ての技術選定においてそうとは限らないが、ステップ0の積み重ねがスピード感を生む要因だと感じた。

異なる点その2：情報の大元を見に行く癖がある

情報の大元って、実は公式ドキュメント以外にもある。
先輩エンジニアを観察していると、OSS開発者のブログやGithubのIssueも見に行っている。

まだリリースされていない技術は公式ドキュメントも整備されていないことが多いが、IssueやPull Requestを見ることで、最新の開発動向をいち早くキャッチしていることがわかった。

とはいえ、全部が全部大元を見に行くわけではないそうで、
日本語の記事を読んで、納得しなかったら情報の大元を見に行くという思考プロセスになってるようです。
記事を読んで「論理が繋がってないな」「この数字の根拠はなんだろう？」という疑問が出れば、
納得する所まで情報を得にいくようである。

感想

先輩エンジニアの思考プロセスの中で、すぐ真似できる点は取り入れ、時間がかかる点はコツコツ身につけていきたいと思います。

例えば、「記事の論理がおかしい」と気づくことができるのは、一朝一夕に身につくものではありません。
自分の場合、「Qiitaの記事がわかりにくいから別の記事に移ろう」という風に水平移動しがちですが、深く掘り下げることを意識したいです。
自分の知識レベルに合った記事を探す癖があるために水平移動をしているのかもしれません。
「論理がおかしい」と感じられるようになるには、IT基礎力が必要だと思うので、地道に成長していこうと思います。