はじめに
こんにちは、xincere採用担当です！
xincereでは現在、既存のRailsサービスをNext.js／Honoへ移行するプロジェクトが進行中です。「移行プロジェクト」と聞くと、地味な作業の繰り返しをイメージする方もいるかもしれません。でも実際は、単純に書き写すだけでは終わらない、リファクタリングや設計判断がいくつも詰まった仕事なんです。
「実際どんなふうにタスクが進んでいくの？」「レビューって厳しいの？」——そんな候補者のみなさんの疑問に答えるべく、今回はこのプロジェクトに携わるエンジニアに、タスクが完成するまでのリアルな流れを聞いてみました。
🔍 プロジェクトの全体像 ── 「移す」だけじゃない移行
―― まず、今関わっているプロジェクトについて教えてください。
すでに公開されているRailsのサービスを、Next.jsとHonoに移行するプロジェクトです。全部を一気に切り替えるわけではなく、1サービスごとに期間を区切って、順番に移行を進めています。私はメインでバックエンド側の開発を担当しています。
――「移行」というと、既存のコードをそのまま移すだけのイメージもありますが。
基本的には移行元のリポジトリの内容を移していく作業がベースにはなります。ただ、移す過程で気づいた無駄な処理をリファクタしたり、不要になったサービスを削除しながら設計し直したりすることも多いですね。単純な「コピー作業」ではなく、都度「今の構成に合わせるならどう書くべきか」を考えながら進めています。
―― 日々のタスクは、どういう形で降りてくるんですか？
パターンは大きく2つあります。1つは、要件を整理する担当者がいて、そこからissueが切られてアサインされるケース。もう1つは、すでに移行済みの部分について、クライアント側からバグ報告をいただいて、それを調査・修正するケースです。
🛠 1つのタスクが完了するまで
―― 実際に1つのタスクに着手してから、完了するまでの流れを教えてください。
今のプロジェクトでは、エンドポイントごとにissueが作られる運用になっています。流れとしては、
という順番で進みます。テストを先に設計してから実装に入るので、ゴールが明確な状態で手を動かせるのがポイントですね。
―― 進める中で、悩んだり詰まったりするポイントは？
一番悩むのは、Rails側にはすでに実装されているロジックを、TypeScriptでどう表現し直すかという部分です。たとえば、Rails側では対象データを丸ごと作り直す「全体更新」のロジックだったものを、TypeScript側では必要な部分だけを書き換える「差分更新」の設計に変える必要があった場面がありました。
単純に文法を置き換えるだけでは済まなくて、「なぜ差分更新にするのか」「既存の挙動を壊さずにどう置き換えるか」まで考える必要があって、自分にとっては挑戦的なタスクでした。
―― 複数のサービスをまたぐ構成だと、コードをどこに配置するかという判断も出てきそうですが。
そうですね。今は1サービスごとにフォルダを分けつつ、共通で使うロジックは共通のレイヤーに置く、という構成にしています。「このロジックはこのサービス固有なのか、それとも共通化すべきなのか」を都度判断しながら実装を進めていくイメージです。
💬 レビューの空気感
―― PRレビューは実際どんな雰囲気なんですか？厳しいイメージを持つ候補者の方も多いと思うのですが。
まずAIにレビューさせて、その内容を踏まえて最終的には人間がちゃんと目を通した上で、コメントとして伝える、という流れになっています。なので「AI任せで誰も見ていない」ということはなくて、AIの指摘を土台にしながら、人が判断して言葉を選んでくれている感じですね。内容も「こう書いた方がいい」「既存の規約に合わせてほしい」といった、改善提案・すり合わせに近いフィードバックが中心です。
正直に言うと、似たような指摘を何度か繰り返し受けたこともあって。そのときに「あ、これは自分のセルフレビューが甘かったんだな」って気づかされたんです。指摘されて終わりじゃなくて、「次に出す前にここを見ておこう」という自分なりのチェックポイントが少しずつ増えていく感覚があります。一方的にチェックされる場というより、学びに変えていく場、という感じですね。
――最後に、この働き方を通じて候補者の方に伝えたいことはありますか？
入社直後は、正直「これってどこまで自分で確認していいんだろう」って悩んだ時期もありました。聞きすぎたら迷惑かな、でも聞かないと前に進まないし……みたいな。実際には、まずAIと壁打ちしながら自分なりに仮説を立てて、それを踏まえて確認する、というやり方に落ち着いていきました。
それに、移行プロジェクトって「正解が決まりきってない」場面が多いんですよね。すでに動いてるコードがある分、ゼロから作るより簡単そうに見えて、実は「なぜこう書かれてるのか」「今の構成ならどう変えるべきか」を自分で考える場面がすごく多くて。最初は戸惑うかもしれないけど、それって裏を返せば、指示されたことをこなすだけじゃない、考える余地がちゃんとある仕事だと思います。
🤝 こんな方と一緒に働きたい
- 既存のコードを読み解きながら、今の設計に落とし込んで考えるのが好きな方
- 指摘を「詰められる」ではなく「学びに変える」機会として捉えられる方
- わからないことを一人で抱え込まず、AIやチームを頼りながら前に進める方
おわりに
移行プロジェクトは、地味に見えて実は「設計判断の連続」です。既存の資産を活かしながら、今の技術・思想にどう落とし込むか——その面白さと難しさを、少しでも感じていただけたら嬉しいです。
xincereに興味を持っていただいた方へ
少しでも興味を持っていただけたら、まずはカジュアル面談からお気軽にどうぞ。実際の開発現場やAI活用の様子について、もっと詳しくお話しします。
株式会社シンシアの募集・採用・募集条件 - Wantedly
関連記事
/assets/images/24204841/original/850ac969-d7b1-4031-93b7-5a0648b6e097?1783643492&w=1440)
入社前にAIのキャッチアップは必要？現場エンジニアに聞いてみた | 株式会社シンシア
/assets/images/23863667/original/9b2308b9-b95b-4b0a-83dd-31a2aba166bd?1780032586&w=1440)
エンジニアに向いている人って、どんな人だろう？ | 株式会社シンシア
#xincere #エンジニア採用 #Rails #NextJS #Hono #バックエンドエンジニア #レガシーマイグレーション #中途採用 #エンジニア組織 #開発の裏側
/assets/images/7395491/original/07f965bc-cf78-49ee-bcec-fbf7e34cb56b?1629769675)
/assets/images/7395491/original/07f965bc-cf78-49ee-bcec-fbf7e34cb56b?1629769675)
/assets/images/7395491/original/07f965bc-cf78-49ee-bcec-fbf7e34cb56b?1629769675)
