今日から技術研修の本番が始まった。今日から約1ヶ月の期間で、社内で使用されるツールを開発することがノルマとして与えられている。

生成AIの使用は禁止というルールで、俺としては、こういった機会に、エンジニアとしての地力をつける絶好のチャンスだと捉えているのだが、他のメンバーはそうでもないらしい。Cursorを使っていたら自動的にAI補完されてしまう？それなら設定でOFFにしろよ。誘惑に負ける？それならVSCodeをインストールしろよ。VSCodeの右側にAIチャット欄があるから使っちゃう？そんなこと知るかよ。

こんな感じで、全く会話が噛み合っていないし、そんな発言をメンターの先輩の前でしているのはいかがなものか。これから技術研修ですがんばりましょうのタイミングでGWに連休を取りたいとかそういう話するなよ、先輩がいない時にそういう話はしようよ。

はっきり言って、相当にガードレールが無いと建設的な議論ができないメンバーとのチーム開発だ。全く足並みが揃っていないし、揃えようというつもりもないのかもしれない。かなりしんどい。それでも、やってくしかないし、苦労はするけど、最終的に納得いくクオリティのものを完成させて、いい経験と思い出にしたい。現状、お互いに気に食わない部分もあると思うけd、これから同期として数年やってくわけだから。

〜

今日は昨年度の締め会を行なった。俺はオンラインでのアルバイト期間が長かったから、実際に会うのははじめましての人が結構いた。実際に会うと印象が全然違ったりして面白い。言い換えれば、人間は見たことがないものを、それだけ強固に想像によって作り出せるということでもある。

〜

サービスな複雑で不安定な箇所をスポットで改善してくれている凄腕のエンジニアがいる。彼がリアルタイムで問題が発生すると、あっという間にその原因を特定する姿をSlack上で何度も見て、色々と聞きたいことがあった。

曰く、エラーの原因を見つけるためのコツは、１つは経験、もう１つはパターンマッチングらしい（パターンを増やすのも経験だが）。経験を積むことによって、複雑なエラーでも、大体ここが怪しそうみたいなパターンが掴めてきて、それに当てはめて原因を特定できることが多いらしい。もしくは、完全にパターンマッチしていなくても、同じ・似たエラーなら、原因も類似すること多い。多分、パターンマッチにおける重要な点は、パターンを認識することだと思う。普段、漫然とコーディングして、エラーをググりながらダラダラと解決すると、このエラーが何かのパターンだということは認識できない。一方、筋が良い人は、そのエラーを何かしらのパターンに落とし込むことで、解釈しようとする。そうすれば、そこでハマってから解決した経験を含めて、一つのパターンとして蓄積される。大体、エラーメッセージの検索結果が出てくるなら、それはもう一つのパターンである。とにかく、パターンを意識すること、このエラーはどのパターンに当てはまるのか、みたいなことを意識しながら開発していきたい。同時に、パターンの箱を増やす努力もしていきたい、そのためには、普段からパターンを意識しながら、一方で、体系的かつ網羅的にパターンの箱を作っていく作業をする必要がある。具体的には、

〜

仕事について、仕事をする意義について考えたり、俺のやっている仕事が世の中のためになっているのか、という抽象的で答えのない問いを繰り返すタイプの人間だったが、そんな俺の認知的不協和を解決する方法を見つけた。それは、仕事を全体最適ではなく、局所最適として捉えるべきだということだ。たとえば、１つの商品が世の中全体を良くすることは難しいけれど、その商品を買った人たちがHappyになって、その商品がそれなりに売れれば、商品の作り手もHappyになる。仕事っていうのは結局その程度で考えればよいのだとおもう。