こんにちは。2026年4月にラクスに入社し、楽楽精算開発部に配属された木村です。
この記事では、入社してから実務に入るまでの約4ヶ月間に受けた研修の内容と、配属後の研修中に学んだことを書きます。ラクスのエンジニア職に興味がある方のご参考になれば幸いです。
研修の内容は年次によって変わる可能性があるため、ご注意ください。
なぜラクスを選んだか
ラクスを選んだ理由の1つは、若手にも挑戦の機会がある環境だと判断したからです。
就職活動では、若手にも挑戦の機会があるかを重視していました。やったことのない仕事に挑戦することで、できることを増やしていきたいと考えていました。選考の際、面接の逆質問を通して若手の挑戦機会について直接確認できたことが、入社を決める後押しとなりました。
入社後に社員の方とお話しする中で、実際に成果を出した若手が新しい役割やプロジェクトを任された事例を本人や周囲の方からお聞きしました。年次に関係なく成果を出していれば挑戦の機会を与えてもらえる環境なのだと改めて実感しました。
入社から実務に入るまでの流れ
入社から実務に入るまでのスケジュールは以下の通りです。
| 期間 | 内容 |
|---|---|
| 4/1 - 4/10 | 新入社員合同研修 |
| 4/13 - 6/30 | 技術研修 |
| 7/1 - 9/11 | 配属後研修 |
配属後研修の期間は目安です。配属時の経験や知識によって、研修期間は前後します。
以降でそれぞれの研修について説明していきます。
新入社員合同研修
ビジネスマナーなど社会人としての基礎に加え、就業規則や人事制度といった社内の制度、クラウドサービスのビジネスモデルや各プロダクトについて学びます。
今年は生成 AI 活用研修がありました。生成 AI の特徴と社内で利用できる AI の説明から始まり、 Gemini とNotebookLM（現Gemini Notebook）のハンズオンがありました。最後に Gemini の Canvas 機能を使ってアプリを作るハッカソンがありました。Gemini は学生のときから使っていましたが、Canvas 機能でアプリを作れることまでは知りませんでした。
技術研修
約2ヶ月半、エンジニア職の新卒全員で受ける研修です。Webアプリケーションの設計から運用保守までの一連の開発プロセスを実践できるようになることを目指した内容になっています。具体的な学習内容は以下の通りです。
| カテゴリ | 内容 |
|---|---|
| IT基礎 | ハードウェア基礎、ネットワーク基礎 |
| Java | プログラミング入門、Collection API、ラムダ式、Stream API、例外処理 |
| オブジェクト指向 | クラス、継承、委譲、カプセル化、インターフェース、ポリモーフィズム、SOLID 原則 |
| データベース | RDBMS、SQL、JDBC、Entity と DAO パターン |
| Webフレームワーク | Spring Boot、Thymeleaf、DI コンテナ、Spring JDBC |
| フロントエンド | HTML/CSS、JavaScript、jQuery、Ajax による非同期処理、React |
| テスト | ソフトウェアテスト入門、JUnit、TDD |
| バージョン管理 | Git |
| AI駆動開発 | プロンプト、Design Doc、ADR |
| セキュリティ | SQL インジェクション、XSS |
| 運用保守 | パフォーマンスチューニング、ロギング |
| インフラ | Linux、シェルスクリプト、Docker、Apache & Tomcat 連携、デプロイ |
AI 駆動開発は今年から追加された内容です。Claude Code のようなコーディングエージェントを使う研修ではなく、コンテキストエンジニアリングの講義でした。仕様と意図を Design Doc、ADR、Javadoc として書き出し、それらをプロンプトとともに Gemini へ渡してコードを生成させるという内容でした。実装しながら設計や仕様を固めていくスタイルに慣れていたので、先に仕様を文書化してから生成させる進め方には苦戦しました。AI を使いこなすためには、開発スタイルを変えていく必要があると感じました。
これらの学習と並行して、朝の時間に技術発表か小テストがありました。技術発表とは、担当者が特定のテーマについて勉強したことを発表する取り組みです。1周目は『リーダブルコード』、2周目は技術や用語の説明でした。
研修の最後にはチームで EC サイトを開発しました。商材はいくつか用意されていましたが、今年は全チームが独自の商材を扱う EC サイトを開発しました。私たちのチームは編み物のキットを商材に選びました。ただ、チームに編み物の経験者がいなかったため、機能のアイデアは出せるものの、それが実際に使われるものなのか判断できませんでした。そこで、編み物の経験がある同期や、編み物の専門店で働いている方にインタビューを行い、曲がりなりにも根拠を持って仕様を決めていくことができました。
これは実際のプロダクト開発でも同じではないかと思います。顧客への解像度が低いまま作った機能は価値として届きません。根拠がないまま議論を続けても結論は出ず、リリースも遅れます。ラクスが顧客志向を重要視する理由が少し分かりました。
配属後研修（楽楽精算）
楽楽精算の開発に必要な技術やドメイン知識を学ぶ研修です。主に以下のことを学びます。
- 楽楽精算の機能
- 楽楽精算で利用されている技術
- 楽楽精算のシステム構成
最後に楽楽精算に機能を追加する課題に取り組みます。学習メニューの詳細は2022年の記事でも紹介されているので、こちらをご覧ください。
変わった点としては、資格の取得が任意になったこと、サポートサイト課題の負担が減ったことがあります。楽楽精算のサポートサイトには「フムフム」という AI チャットボットが導入されています。以前はサポートサイトのほぼ全ページを読む必要があったようですが、チャットボットのおかげで知りたい情報をピンポイントで入手できるようになりました。
配属後研修で得た気付き
ここでは、楽楽精算に機能を追加する課題で学んだことを書きます。
同期のプルリクエストに LGTM（Looks Good To Me）を返した後、メンターの方から以下のようなコメントを頂きました。
“LGTMと判断したレビュー観点をリストアップして貰えますか？”
1行消して1行足すだけのプルリクエストだから、そんなに時間はかからないだろうと思い、レビューの観点を書き出すと、思いの外、手が止まりました。同期が書いた値の意味は理解していましたが、なぜその値にするのかまで説明できませんでした。その値がどこでどう使われているのかを調べ直すことになり、返信までに20分以上かかりました。
自分も同じ課題をやったはずなのに、なぜ理由を説明できなかったのか。自分なりに考えた結果、実装時に自ら判断する機会を作らなかったからだという結論に至りました。
自分で実装する場合、何を書くかを自分で選ぶ必要があります。選ぶ以上、なぜその値にしたのかという理由が自分の中に残ります。一方、AI に実装を任せると、すでに選ばれた状態のコードが出てきます。出力を読んで確認はしますが、なぜ他ではなくその値なのかを考えなくても先に進めてしまいます。今回の課題でも、なぜその値にするのかまで踏み込めていなかったため、理由を説明できませんでした。
AI を活用するのが当たり前となった現代において、すべてを自分で実装するのは現実的ではありません。AI に実装させる前提で、なぜその実装にしたのか自分で判断する機会を意図的に設ける必要があることを学びました。
おわりに
約4ヶ月の研修を通じて、技術面はもちろん、プロダクト開発における顧客志向の重要性や、AI を活用した実装において自ら判断を下す必要性など、実務に通じる気付きを得ることができました。
判断する機会の必要性について、現時点で明確な解決策を持っているわけではありません。これから実務が始まるので、日々の業務の中で試行錯誤しながら、実装の理由を見失わない進め方を見つけていきたいです。
この記事が、ラクスのエンジニア職に興味がある方のご参考になれば幸いです。
