エンジニア転職活動ハックをシェアしよう！カレンダー1日目の記事になります。 筆者について ソフトウェア・エンジニアとして、これまでに3回の転職を経験しました。 在職期間は一番長くて10年、一番短いところで11ヵ月ほどです。 転職に成功したかどうかでいうと、ひとつの指標でしかありませんが、給与水準は転職の度に上げることができています。 これまでの経験を振り返り、「次に転職するとしたら」という立ち位置で、中堅～ベテランの転職戦略について、企業を選ぶ側面、企業に選ばれる側面の両方から考えてみたいと思います。 職探しの入口 まずは、何を使って求人情報を探すかという方法論です。 だいたい以下のような手段があるかと思います。 知人からの紹介 スカウト・エージェントからの紹介 転職サイト・SNSで探す SNSやメディアでの発信 企業に直接応募する 知人からの紹介 だれでも利用できる手段ではありませんが、

テスト自動化失敗談を共有しよう！ by T-DASH カレンダー、2日目の記事になります。 はじめに E2Eテストを書きましょう！とチームで決意し、実際に書いてみたものの、気づけばいつのまにか通らなくなっており、誰も直さないうちにそのまま忘れ去られる……というのは、E2Eテスト自動化のあるあるだと思います。 この記事では、メンテナブルなE2Eテスト実装について、一般的に言われることと、自身の失敗経験とを照らし合わせてみたいと思います。 E2Eテストについて ここでE2Eテスト（End to Endテスト）と呼んでいるものは、なんらかのUI操作自動化ライブラリ（UI Automation, Puppeteer, Cypressなど）を使い、コードとしてユーザー操作シナリオをエミュレートするテストのことを言っています。 特に、ノーコードのシナリオ自動生成ツール利用を検討する場合は別のソリューシ

「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence カレンダー、3日目の記事になります。 はじめに プロダクトや開発環境に限らず、どんな会社にも多かれ少なかれレガシーなメソッドがレガシーなまま残っているものです。 だれも見ていない予定表に記入するルール、冗長な二重の申請手続き、印刷した紙ベースでのコードレビューetc. 何をレガシーとするかは主観による部分も大きいですが、誰もが「これ意味あるの？」「もっといい方法ないの？」と思いつつ、なんとなく続けられている規則もあるでしょう。 そういったレガシーをどうやってカイゼンしていくか、という話になります。 どんなレガシーがあるか イメージをもっていただきやすいように、実際に過去に遭遇し、自分または周囲の人がカイゼンを試みたレガシーな社内メソッドを挙げてみます。 社