インド人エンジニア大量採用とAI活用で挑む、Rimoの開発組織スケール戦略
こんにちは。 Rimo合同会社 CTO の山田祥允です。
Rimo Advent Calendar 2025 2日目の記事として、 Rimoの開発組織についてお話しします。
Rimoの開発組織はこうやってスケールしている
Rimo はここ数年、売上も人員もほぼ毎年 2 倍ペースで成長してきました。
今後もこのスピードを落とすつもりはありません。
一方で、単純に「人数を増やす」だけでは開発組織はスケールしません。
Rimo が選んだやり方は、
日本：ミドル〜シニアの即戦力エンジニア
インド：新卒・学生のジュニアエンジニアを大量採用＆育成
そして AI（Claude Code）をフル活用する開発プロセス
という、ちょっと変わった組み合わせでした。
この記事では、
「インド人エンジニアがどんどん増える中で、Rimo の開発組織がどんな課題にぶつかり、どう解決してきたか」
についてお伝えしします。
日本 × インドのハイブリッド開発チーム
現在の開発組織は、ざっくりいうとこんな構成です。
インド人エンジニア
新卒社員 3 名
内定者アルバイトとしてほぼフル稼働している学生が約 15 名
→ 合計 18 名ほどのインド人エンジニア
日本人エンジニア
正社員5名
業務委託数名(パートタイムの副業含む)
ほぼ全員がエンジニア経験5年以上のミドル〜シニアクラス
つまり、人数比で見るとインド側が圧倒的多数です。
インド側はポテンシャルは高いものの、ほとんどが「経験年数の浅いジュニア」。
一方、日本側は 即戦力としてコアな開発を進めつつ、インド側の育成・レビューも担う という役割です。
「インターン → 内定 → 内定者バイト」で育てる
インド人エンジニアの採用は、インターンを入り口にしたプロセスとして設計しています。
インドの大学生向けにインターン募集
応募は毎年 100〜数百人規模
その中から 5〜10 名ほどを選抜し、オンラインインターンを実施
活躍したメンバーに 内定オファー
内定後は 「内定者アルバイト」としてほぼフルタイムで参画
インドの大学では、長期インターンが単位認定されるケースも多く
→ 学生にとっても 「単位も取れて、給与ももらえて、経験も積める」 という win-win
このモデルのおかげで、学生の段階から実戦レベルの仕事を任せつつ、卒業する頃にはかなり戦力になっている、という状態を作れます。
なぜインドなのか？ 採用戦略としての狙い
インドでの採用を強化している背景は、ざっくりいうと次の 3 つです。
優秀な新卒エンジニアを採りやすい
日本は人口減少や新卒市場の競争が激しく、優秀層の奪い合いになっている
一方インドには、コンピュータサイエンスを学ぶ優秀な学生が非常に多い
多言語・国際環境に強い
インドのエンジニアは、英語＋母語を含む複数言語に慣れている人が多く
「自分が分からない言語がチーム内で飛び交う状況」にも強い
日本に来て働きたい人と志望してくれる人も多く、国際チームを作りやすい
Rimo のグローバル展開との相性
将来的にプロダクトを 多言語対応・グローバル展開 することを見据えると、
英語＋母語を含む複数言語をベースに動けるメンバーが多いことは大きな強み
こうした理由から、Rimo では「日本でシニアを採り、インドでジュニアを大量に育てる」という戦略を取っています。
インド側が一気に増えて見えてきた「3つの課題」
もちろん、良いことばかりではありません。
インド側の人数が一気に増えた結果、開発現場では次の 3 つの課題がはっきり見えてきました。
PR が大量に出てきて、レビューが完全にボトルネックになる
成果物（コード）の質にばらつきがあり、全体としてまだレベルが低い
育成コストが重い
日本人エンジニア自身にも進めるべきプロジェクトがある中で
ジュニアのメンバーにも丁寧にフィードバックを返す必要がある
ここからは、それぞれの課題に対して Rimo が実際にやったことを紹介していきます。
課題1：レビューのボトルネックを、AIとプロセスで崩す
① Claude Code による自動レビュー
レビューのボトルネックに対しては、まず Claude Code による自動レビュー を導入しました。
PR が作成・更新されるたびに Github Actions で Claude Code による自動レビューが走り、
コードスタイルや基本的な設計、
プロジェクトごとのコーディング規約違反
などを自動でチェックします。
ここでは、「単に Claude Code のレビューコマンドをそのまま使う」のではなく、Rimo 用に作り込んでいます。
レビュー観点をすべて Markdown ドキュメントに列挙
例えば：
React コンポーネント設計のルール
Go のエラーハンドリング方針
テストコードの書き方
命名規則 …など
それぞれの観点ごとに別々の「サブエージェント」として Claude に読ませ、
観点ごとにチェックさせる ことで、コンテキスト圧迫を避けています
観点が増えれば、このドキュメントを更新するだけで AI のレビューも賢くなる、という仕組みです。
実際に入れてみてどうだったか
良かった点：
インド側のメンバーが AI の指摘を一通り反映してから 人間にレビュー依頼を出すようになった
→ PR の「最低限直すべきところ」は AI の段階でかなり潰れる
また、思わぬ副産物として
日本人シニアエンジニアが「自分でサッと見てそのままマージ」していたようなコードにも
Claude が事前に目を通してくれるようになり、思わぬバグ検知にも貢献
一方で、課題もありました。
全ての push で自動レビューを走らせると、
同じようなコメントが何度も出てきて
PR がコメントだらけになり、読みにくくなる問題
そこで、運用を次のように調整しました。
最初の PR 作成時に 1 回レビュー
以降は、
専用のラベルを付けたときだけ 再レビューを走らせる
この辺りは、まだまだ改善の余地があり、日々改善を進めています。
② 「動作確認は実装者の責任」という文化づくり
AI に任せきりにしないために、PR テンプレートとプロセス側の工夫もしています。
PR テンプレートには、必ず次の項目を書かせています。
この PR で対応している 要件・背景
どのような アプローチ・設計方針 をとったのか
実施した テスト内容
手動の動作確認のケース
書いたテストコードの概要
テスト結果
これにより、
レビュワーは
「要件を満たしているか」「バグがないか」を一から自分で確かめる必要がなくなり
代わりに 設計・保守性・命名などの技術的観点に集中できる
実装者側には
「動作確認を自分の責任でやる」
「テストケースを自分の頭で設計する」
という意識が根付きつつあります
実際、テンプレートを通じて「明らかに動作確認していない PR」も見抜きやすくなり、
その場で「ちゃんと動作確認してから出してね」とフィードバックできるようになりました。
課題2：Claude Code + CLAUDE.md で最低限の品質ラインを揃える
インド側のメンバーは、ポテンシャルは高い一方で、経験年数が浅く、コード品質にばらつきが出やすい という課題がありました。
そこで、
インド人メンバーには Claude Code を標準ツールとして配布
Rimo 独自の CLAUDE.md を読み込ませた状態で使ってもらう
という形を徹底しています。
これにより、
「とりあえず AI なしで書いたコードをそのまま出す」のではなく、
一度 AI と一緒にブラッシュアップしてから PR にする
というフローが、インドメンバーの中に当たり前になりつつあります。
結果として、
まだまだ完璧とは言えないものの、
“AI レベル” の最低品質ライン を全員がクリアしやすくなり、
人間のレビューは「その先」の改善に集中できるようになってきました。
課題3：評価ラダーで「どう成長すればいいか」を可視化する
3つ目の課題は、育成コストの重さでした。
インド側のメンバーは、AI を使えばある程度自走できますが、
「そもそもAIに何を聞けばいいのか」が分からない という壁があります。
そこで Rimo では、次のようなアプローチを取りました。
エンジニア向けの 評価ラダー を用意
レベル 1, レベル 2,… と段階を定義
各レベルごとに
技術観点で「できていてほしいこと」
成果物の観点で「こういうアウトプットが出せている状態」
を具体的に言語化
「あなたは今はレベル 1。レベル 2 に上がるには、このあたりを伸ばす必要がある」
と、自分の現在地と次のステップを明示
これにより、
メンバーは
「どこを伸ばせばいいか」
「どのテーマについて AI に相談すればいいか」
を自分で考えやすくなり、
自己成長を設計しやすい状態 を作ろうとしています。
正直、これはまだ始めたばかりの取り組みで、
ここからどこまで機能するかは観察フェーズではあります。
ただ一つ言えるのは、現在のレベルと足りていない部分を明確に示したことで、
「このままだと AI に仕事を取られるかもしれない」という
ちょうど良い危機感 を持ってくれたメンバーも多く、それがきっかけで、
案件の進め方やスキルアップへの意識が変わってきた という感触があります。
Rimo の開発組織で得られる経験
ここまで、うまく進めているような施策を紹介してきましたが、
実際にはうまくいくことばかりではなく、日々トライアンドエラーの繰り返しです。
ただ、その分 得られる経験の振れ幅も大きい と感じています。
1. 職種の壁を超えた、幅広い開発経験
Rimo はまだ小さめの開発組織です。
その分、より幅広い経験を積むことができます。
フロントもバックエンドもインフラも触る
ビジネスサイドと一緒に「そもそも何を作るべきか」を考える
お客様の声を聞きながらプロダクトの方向性に口を出す
といった、「職種の枠を超えたフルスタックな経験」 を積みやすい環境です。
2. 国際チームをリードするマネジメント経験
インド人エンジニアが多数いるので、
英語でのコミュニケーション
文化の違いを踏まえた仕事の進め方
ジュニアメンバーを束ねて案件を進める
といった、国際的なマネジメント・リードの経験 を自然と求められます。
これは「日本人だけのチーム」ではなかなか得られない経験だと思います。
3. AI と一緒に開発するのが当たり前の環境
Rimo 自体が AI プロダクトを提供している会社なので、
自分たちの開発プロセスにも 徹底的に AI を使う
Claude Code Actions によるレビュープロセス
CLAUDE.md などの“AIに読ませるガイドライン”を育てていく
「AI に任せるところ」と「人間が判断するところ」を設計していく
といった、“AI とともに開発する”経験 を日常的に積むことができます。
こんなエンジニアに来てほしい
最後に、Rimo の開発組織として「ぜひ一緒に働きたい」と思っているのは、こんなタイプのエンジニアです。
プロジェクトを前に進めるのが好きな人
「人が足りないけど、やりたいことは山ほどある」という状態なので、
自分でどんどんボールを拾って、案件を進めていける人
新しい技術にどんどんチャレンジできる人
AI 時代の開発は、技術の変化がとにかく速いです
変化を怖がるというより、「面白そうだから触ってみるか」と思える人
インド人エンジニアと一緒に戦いたい人
チームを引っ張るリーダー的な立場に興味がある人も、
まずは個人としてバリバリ開発して貢献したい人も、どちらも歓迎です
AI に頼りつつも、AI に負けないアウトプットを出したい人
「AIをフル活用して、生産性を最大化したい」
あるいは「AIなんかに負けないくらい自分で書ける」
どちらのスタンスでも構いません。
ただし、どちらにせよ アウトプットを出すことに本気でコミットできる人 に来てほしいと思っています。
Rimo は、毎年 2 倍のスケールを目指しながら、
AI と国際チームを武器に、開発組織そのものも実験・改善を続けています。
ここまで読んで「このカオス、ちょっと面白そうだな」と感じていただけたなら、
ぜひ一度、カジュアル面談で話しましょう。
Day3の記事はこちら▼
インド新卒エンジニア3人の来日オンボーディングに1週間フルコミットしてみた話