Rubyエンジニアの参画初月にやること｜現場で信頼される進め方

Rubyエンジニアの参画初月は、開発環境からデプロイまでの流れを自分で回せるようになり、小さなプルリクエストを複数マージし、そのチームのRailsの流儀をつかむところまでを目標にします。最初の1か月で求められるのは、大きな機能を出すことより、この人に既存のコードを任せて大丈夫だとチームが判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、Ruby on Railsの現場ならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境を整え、コードの地図を作る

最初に読むもの

Railsの現場では、読む順番を決めておくと全体像をつかみやすくなります。

1. README・開発環境の手順：環境構築の手順どおりに進め、つまずいた点はメモして後でREADMEに反映する候補にする
2. Gemfile：使っているgemから、認証、非同期ジョブ、管理画面、テストの道具など、チームの選択を読み取る
3. db/schema.rb：主要なテーブルと関連を把握する。サービスの中心となるモデルがどれかをつかむ
4. config/routes.rb：画面とAPIの入口を一覧で見て、サービスの機能の範囲を知る
5. app/models の主要なモデル：バリデーション、関連、コールバック、Concernの使い方から、責務の置き方の流儀を読む
6. 直近にマージされたプルリクエスト：粒度、説明の書き方、レビューの指摘の傾向をつかむ
7. CIとデプロイの手順：テストが自動で動く仕組みと、本番へ出すまでの決まりを知る

読みながら、「ここは流儀が独特だ」「ここは負債になっていそうだ」と感じた点を書き留めておきます。この段階では口に出さず、仮説としてためておきます。

小さな変更を一つ、マージまで運ぶ

1週目のうちに、文言の修正や小さな不具合の修正など、影響の小さい変更を一つ選び、プルリクエストからデプロイまでを通します。目的は成果ではなく、流れの中で自分が詰まる場所を知ることです。レビューの依頼の仕方、CIの待ち時間、デプロイの承認の流れなど、書かれていない決まりがここで見えてきます。

連絡の取り方を決める

リモートの現場では、連絡が取れる時間帯、朝会の形、質問を書く場所を、参画の初日にリーダーと確かめます。「30分詰まったら、試したことと一緒にチャットに書く」のように、自分の相談の区切りも決めておきます。リモートでの進め方はRubyのリモート案件の記事で整理しています。

2週目：中くらいの変更で流儀に合わせる

任された機能を小さく分けて出す

2週目には、モデルの変更やマイグレーションを含む、中くらいの機能を任されることが増えます。一度に出さず、マイグレーション、モデル、画面やAPIのように、意味のある単位で分けてプルリクエストを出します。先に設計のメモや空のプルリクエストで方向を合わせてから実装に入ると、大きな手戻りを避けられます。

レビューの指摘を流儀の学びに変える

レビューで受けた指摘は、そのチームの流儀そのものです。「サービスオブジェクトはここに置く」「このテストはリクエストスペックで書く」といった指摘は、メモにまとめて次の変更から先回りします。指摘の意図が分からないときは、一言で確かめてから直すと、やりとりが短くなります。

テストの粒度を合わせる

モデルのテストを厚く書くチーム、リクエストのテストを中心にするチーム、画面のテストまで自動で動かすチームなど、粒度はさまざまです。既存のテストを読んで、同じ粒度で書くことを優先します。テストの少ないコードに触る場合は、触る範囲のテストから足していく方針をリーダーと合わせます。

3〜4週目：任された範囲をやり切り、次を合わせる

担当する機能を本番まで運ぶ

3〜4週目には、任された機能を本番まで出し、リリース後の様子（ログ、エラーの通知、監視の数字）を自分で確かめます。リリース後に小さな不具合が見つかったときは、すぐに直すプルリクエストを出し、原因と対策を短く共有します。この一連の動きが、「本番まで責任を持つ人」としての信頼につながります。

気づいた点を提案の形で出す

1週目からためてきた「流儀が独特」「負債になっていそう」という仮説を、流儀に従って成果を出した後で、提案の形で出します。「このN+1を直すと一覧が速くなる」「このマイグレーションは本番で時間がかかりそう」といった具体的で小さな提案から始めると、受け入れられやすくなります。決めるのはリーダーに委ね、自分は選択肢と根拠を示す立場に徹します。

2か月目以降の範囲を合わせる

月末に、リーダーと短い時間をもらい、自分が担う機能や領域、レビューの役割、障害対応への関わり方を言葉で確かめます。契約で決めた業務の範囲と、実際に頼まれている仕事がずれていないかも、このときに見ておきます。

案件の型によって初月の重心は変わる

同じRubyの案件でも、型によって初月に力を入れる場所が違います。

運用中サービスの機能追加

もっとも多い型です。既存のコードの読解と、流儀に合わせた小さな変更の積み重ねが中心になります。上で書いた週ごとの進め方が、そのまま当てはまります。

バージョンアップ・負債の整理

更新の案件では、初月は実装より調査が中心です。対象の版の変更点、使っているgemの対応状況、テストの網羅の程度を調べ、作業の見積もりと段階的な進め方の案を出します。月末には、どの順で何を上げるか、本番でどう確かめるかの計画に合意を取ることを目指します。

フロントとの分離・API化

画面をReactなどに移してRailsをAPIにする案件では、フロント側のエンジニアとの取り決めが初月の中心です。APIの設計の決まり、認証の扱い、エラーの返し方を早い段階で合わせ、小さなエンドポイントを一つ通して流れを確かめます。

新規サービスの立ち上げ

まだコードが少ない段階で入る場合は、既存の流儀をつかむより、要件があいまいな中で速く作って出すことが求められます。設計の判断を一人で抱えず、リーダーと短い間隔で方向を合わせながら進めます。初月から機能を出す速さを見られるため、環境の整備とデプロイの流れを最初の数日で固めておきます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、Rubyのフリーランスがつまずきやすい場面はRubyエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 環境構築からデプロイまでを、一人で通せるようになったか
• 自分でマージまで運んだ変更が、複数あるか
• レビューで受けた指摘の傾向を、次の変更で先回りできているか
• 2か月目以降に担う範囲を、リーダーと言葉で確かめたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。初月に書き留めた環境構築のつまずきや流儀のメモは、READMEへの反映を提案したり、将来の引き継ぎの材料にしたりできます。契約が終わるときの引き継ぎの考え方は契約終了時の引き継ぎの記事で整理しています。

よくある質問

ドキュメントがほとんどなく、前任者もいません。何から始めればよいですか？

db/schema.rb、config/routes.rb、直近のプルリクエストの順に読み、サービスの中心となるモデルと、よく変更される場所をつかむのが近道です。そのうえで、リーダーに「今一番困っていること」を聞き、そこに関わる小さな変更から始めます。ドキュメントがない状態そのものも、初月の振り返りで共有しておくとよいでしょう。

参画初月から大きな機能を一人で任されたら、どうすればよいですか？

設計のメモを先に書いてリーダーと方向を合わせ、実装はマイグレーション、モデル、画面やAPIのように小さく分けて出します。進み具合と詰まっている点は、聞かれる前に短く共有します。大きな機能でも、本番に出た小さな変更が積み上がっていれば、チームは安心して任せられます。

テストがほとんどないサービスでした。初月に何をすればよいですか？

触る範囲のテストから足していく方針を、リーダーと最初に合わせます。既存のコード全体にテストを足そうとすると初月の成果が見えにくくなるため、自分が変更する箇所のテストを書き、変更が小さく安全であることを示すことを優先します。求められるテストの考え方はRubyの案件で求められるスキルの記事で整理しています。