開発効率・生産性向上だけじゃない、ファインディの2週間インターン
- 私はファインディ株式会社で2週間エンジニアとして実務の開発インターンをしました。
参加した理由と、始まる前の不安
そもそも、なぜファインディのインターンに参加したのか？
- イベントやカンファレンスでの発信、そしてもともと別インターン先でメンターの方に紹介されて読んでいた技術ブログから、ファインディには「開発生産性や効率にこだわる、エンジニアのための会社」という印象がありました。
タスク分解のやり方 — 1タスク=1プルリクエスト - Findy Library
プルリクエストの書き方 — テンプレート・粒度・スタック - Findy Library
- そういった環境で、実際にどうやって開発を速くしているのか。記事を読むだけでは分からない部分を、百聞は一見に如かずで、自分の目で確かめてみたいと思っていました。
- そんなときに、X でファインディが DevRel のインターンを募集しているのを見つけました。
- DevRel という仕事には、Supabase のタイラーさんの発信を見て興味を持っていたので、すぐに応募しました。
- ただ、自分は台湾に住んでいて、イベントの多い DevRel の仕事に関わるのは難しい、という話になりました。
- そこで開発の実務のインターンを紹介してもらい、今回の2週間につながりました。
- そんなときに、X でファインディが DevRel のインターンを募集しているのを見つけました。
- せっかく行くなら、すでにユーザーがいるプロダクトで、タスク分解と PR の粒度を体で覚えたい。それが自分の今回の目標でした。
技術力不足ではないかと不安だった
- 自分は普段は台湾から、日本の企業のインターンにリモートで参加しています。
- オフラインで2週間働くのは、今回が初めてでした。
- 一番不安だったのは、自分の技術力のなさが出てしまうことです。普段は AI を使って、どう並列で速く、効率よくアウトプットを出すかを大事にしてきました。
- 対面で一緒に働いたら、AI がないと何もできない自分が見えてしまうんじゃないか、と思っていました。
- 技術スタックも不安でした。
- 普段書いているのは TypeScript、Python、C++。Rails は触ったことがなく、GraphQL も初めてでした。
配属先と働く環境
「Findy」の開発チームへ
- 自分は、エンジニア向けキャリアアップおよび転職支援サービス「Findy」の開発チームに参加しました！
- Findyは、企業からエンジニアに「いいね」を送り、エンジニアが「いいかも」を返すとマッチングが成立し、スカウトやメッセージのやり取りに進めるサービスです。
IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
- 主に技術スタックとしては Ruby on Rails と React と GraphQL が使用されています。
オフィスでの働き方
- 個人的にインターンを始める前に服装などは正直気になっていたので、書いておきます。
- 服装はオフィスカジュアルで、派手すぎなければ、基本何でも大丈夫でした。
- 時間は、10時ごろに出社して、19時ごろに退社する流れでした。
- オフィスはわりとワイワイした雰囲気で、皆さんとても優しかったです。
- 一方で、リモートで働いている方も多くいらっしゃいました。
2週間で、2つの施策を本番まで出せた
結果から書くと、担当した2つの施策は、どちらも本番リリースまで出せました。
- 2日目：タスク分解
- 5日目：1つ目の施策を本番リリース
- 6日目：学生向けの LT 会で、人生初の登壇
- 9日目：レビューで設計が変わる
- 10日目（最終日）：2つ目の施策を本番リリース
2週間で出した PR は35本、Issue は47件です。
Rails が初めてという不安は、思っていたほど問題になりませんでした。社内に整っていた AI の開発手順や、レビューでの助言にも支えられました。むしろ詰まったのは言語ではなく、要件に書かれていないことを自分で探しに行くことでした。
施策①：いいねした時間を常に表示する
- 1つ目は、企業の採用担当者が使うメッセージ画面に、「いつ・誰がいいねを送ったか」を常に表示する施策です。
- 採用担当者にとって大事な情報なのに、時間がたつと画面から見えなくなっていました
- 要望としては「画面の上の方に常に出したい」でしたが、調べてみると、表示位置の問題ではなく、データの返し方から見直す必要がありました。
- すぐに実装には入らず、まず分からないことを13個書き出しました。
- 過去のいいねもすべて表示するのか。
- Figma にない画面はどう見せるのか。
- 担当者が退会していたら、どう表示するのか。
- そんな粒度の疑問を洗い出しました。
- キックオフで全部聞いたところ、そもそも何のために作るのかという背景まで分かり、実装を始める前に疑問が解消されました。
- そこで新たに出た疑問は、キックオフ後に、実際に使っている方へ直接聞きに行きました。
- そのタイミングで、メンターの方から聞き方も教わりました。
- 「自分の仮説はこうなっているが、合っているか」で聞くと、相手は答えやすい。「どうすればいいですか」だと、考えるところから相手に渡してしまう。
- 仮説を持っていけば、違うところだけ直してもらえるので速い。
- それからは、自分の仮説と「ここまでは分かっている」「ここからが分からない」を分けて質問するようにしました。
- その後4日目にステージングに出して確認をお願いすると、その日の夜には QA の方から確認の観点が返ってきて、5日目に本番リリースできました。
- PR を出してから直すより、Issue の段階で聞くほうが速い。
- Issue を書く前に聞ければ、もっと速い。これが1つ目の施策で覚えたことです。
施策②：求人に「おすすめポイント」欄を追加する
- 2つ目は、ファインディ社内の人が候補者に紹介する求人に、「おすすめポイント」を書ける欄を追加する施策です。
- データベースのカラム追加から、社内の管理画面、候補者向けの画面まで、バックエンドとフロントエンドを通して実装しました。
ここで、バックエンドの設計で完全に止まりました。
- おすすめポイントを、どの単位で持たせるのか。履歴は残すべきか。コードを読んでも答えは出てこないし、AI に聞いても一般論しか返ってきません。
- どちらの案にもそれなりの理屈が立ってしまって、決められませんでした。
- それまでの自分は、設計の答えはコードを読むか、AI に聞けば出てくるものだと思っていました。
- 行き詰まって施策の議事録を読み返していたときに、「これ、一覧画面にも要るんじゃないか」と思いつきました。
- そこで、実際にこの画面を毎日使っている社内の担当者の方のところに、直接聞きに行きました。
- そうしたら、作るものが変わりました。
- 一覧画面でも、状況がひと目で分かるようにすることになりました。
- 自分の席でコードと AI だけを見ていたら、絶対に出てこなかった答えでした。メンターの方からも、仮説を立てて一次情報を取りに行く動きが良かった、と言ってもらえました。
- 最終的に、テーブルは作らず、カラムを1つ足す形にしました。
- テーブルは一度作ると、後から消すのが大変です。
- 作るならそれなりの理由が要りますが、実際の使われ方を直接聞いて、今回はそこまで必要ないと判断しました。
- もう一つ、反省もあります。
- 最終日の前日、レビューで作りそのものを変えることになりました。
- 似た機能をどう作っているか、既存の実装を先に読んでいれば避けられた作り直しでした。
- 人に聞きに行く前に、コードを読めば分かることは先に確かめる。
- それでも直して、翌朝にはリリースできました。
- 一次情報は、コードの中にはない。
- 言葉としては知っていましたが、自分の設計が変わるところまで体験したのは初めてでした。
- ファインディは職種の距離が近く、インターン生でも、PdM やデザイナー、実際に画面を使う人に直接聞きに行けます。
- 詰まったら、直接すぐに聞きに行っていい環境でした。
AIを使った開発で、支えられたことと学んだこと
AI が働きやすい環境が、スキルとして整っていた
- ファインディでは、Claude Code のスキル（作業の手順を AI に渡すための指示書）が、プラグインとして社内に配られています。
- 要件を渡すと、タスク分解、Issue 作成、実装、セルフレビュー、PR 作成まで、一連の流れをスキルに沿って進められます。
- Rails も GraphQL も初めてだった自分が初週から PR を出せたのは、この環境があったからです。
- 1日に12本 PR を出せた日もありました。
Git worktreeの運用をスキルに委ねる ―複雑さを隠蔽するClaude Codeスキル設計の実践― - Findy Tech Blog
- ただこれらのスキルは、作った人の「こう使われるだろう」という仮説でできていて、実際に使う人が気づいたことで良くなっていきます。
- インターン生の自分も、使っていて気づいたことを Issue にして、改善の PR を出させてもらいました。自分で課題を見つけて、課題を解決するというコントリビュートまでさせていただけました。
AI が書いたものも、自分のアウトプットだった
- ただ、速く出せるぶん、実装した後に気づくこともありました。1つの PR に、意図が2つ入っていたのです。
- レビューでも「自動生成の雛形と実装は、別の PR にしてほしい」と言われました。
- 本当は、Issue の段階で変更の意図を整理できるのが理想です。
- ただ、実際にやってみて気づくこともあります。
- そこで、PR を作るタイミングでコードを読み直すようにしました。
- 雛形と実装を分け、レビュアーが読みやすい単位にする。PR の説明文も、自分の言葉で短く書くようにしました。
- ただ、実際にやってみて気づくこともあります。
メンターからのフィードバック
- 最終日、メンターの方からこんなフィードバックをもらいました。
- AI を使って速くアウトプットを出せているのは良いけど、それは AI のアウトプットではなく、自分のアウトプットとして見られる。
- 質が低ければ、そのまま自分の評価が下がることもあるから注意が必要。
- だから、生成されたコードを自分で読んで、確認して、直す工程をしっかり踏むこと。
- もう一つ言われたのが、コンテキスト管理の大切さです。
- 一次情報を集めるだけでなく、それを言語化して AI に渡すこと。
- 来る前に不安だった「AI で速いだけの自分」への答えは、ここにありました。
- AI を使うことは、むしろ前提の環境です。
- 問われていたのは、書けるかどうかではなく、出したものに責任を持てるか。
- そして、集めた一次情報を言葉にして、AI にも人にも渡せるか、でした。
インターン生から、話しかけに行っていい
ファインディにはランチの文化があって、上下関係なく、いろんなエンジニアの方とご飯に行けます。
ランチだけでなく、インターン生という肩書きも活かして、色んなエンジニアの方に直接お話を聞きに行ける機会があるのはとても良かったです。
タスクをAIに並列で任せている間に、自分の席を立って先輩エンジニアの皆さんに積極的にキャリアや開発効率、最近面白いと思っている技術など聞きにいきました。
あるエンジニアの方から「話しかけてもらえるのは、意外と嬉しい」と聞いて、後半は自分からできるだけ色んなエンジニアの方にお願いして、話を聞かせていただこうと積極的に行動するよう意識しました。
- 1つ目は、技術ではなくユーザーとプロダクトを起点に考えること。
- ある先輩エンジニアは、新しい領域に手を広げたのも、特定の技術をやりたかったからではなく、プロダクトを作るために必要だったから、と話していました。
- 2つ目は、新卒だからこそ出せる価値があること。
- 知識が少ないから黙るのではなく、新卒だからこそ感じる疑問や違和感を出すことが、すぐにできる価値提供になる、という話でした。
- キャリアの話もたくさん聞きました。
- キャリアの軸は最初から決まっている必要はない、と聞いて、少し気が楽になりました。
- 自分は「作ったもので誰かが喜んでくれること」にモチベーションを感じるタイプです。
- 今は、グローバルな規模で、多くの人に価値を届けるプロダクトに関わりたい
- そのために、技術で解決できる問題の範囲を学びながら増やしていきたいと思っています。
- まだまだここの部分に関しては解像度を上げて自分が本当にやりたいことを見つめ直してより考えていくつもりです。
- キャリアの軸は最初から決まっている必要はない、と聞いて、少し気が楽になりました。
初めてのオフラインで不安でしたが、話しかけに行けば、皆さんとても優しく、ちゃんと真摯に応えていただける環境で、とても楽しく2週間インターンさせていただきました！
これからも大事にしたい、2つの学び
越境する
- 話を聞かせてもらったエンジニアの方から、これからは「越境」が大事になると教わりました。
- エンジニアを「技術を使って課題を解決する人」と捉え、実装だけでなく、必要に応じてデザインやプロジェクトの進め方にも関わっていく、という話でした。
- 自分から社内の担当者や PdM、デザイナーに聞きに行ったのも、小さな越境だったのだと思います。
- これからも、自分の担当範囲だけに閉じず、課題を解決するために必要なことに関わっていきたいです。
仮説を持ち続ける
- メンターの方から教わった「仮説を持ち続けること」は、今の自分に一番必要な姿勢だと思っています。
- AI を使えば、答えらしきものはすぐに出てきます。でも、AI だけに考えさせてしまうと、自分の判断基準が育たない。
- だからまず、課題の背景や一次情報を調べて、自分なりの仮説を持つ。
- 仮説が40点でも、AI や検証、レビューを通して90点に近づけていく。
- その差分から、自分の判断基準を更新していきたいです。
こんな人におすすめ
- ランチも含めて、いろんなエンジニアと話して、価値観やキャリアを知りたい人
- AI を使った開発を、レビューとリリースまで含めた実務で経験したい人
- 「何を作るか」「なんのために作るのか」から関わりたい人
- プロダクト思考強めの方に特におすすめです！
おわりに
- 百聞は一見に如かず。技術ブログを読むだけでは分からなかったことを、2週間で見に行けました。
- このことに関しても一次情報を自分から見にいくことでわかる発見が大きかったです。
- 来る前は、開発の速さこそがファインディの一番の特徴なのかなとなんとなく思っていました。
- 中に入って見えたのは、その速さを支える AI が働きやすい環境づくりと、「何を、何のために作るのか」を問い続けるプロダクト思考でした。
- インターンに応募するか迷っているなら、一度見に行ってみてください。
- 自分がそうだったように、この記事が少しでも安心材料になればうれしいです。
- メンターのお二人をはじめ、開発チーム、PdM、デザイナー、QA、実際に画面を使っている社内のみなさん、そしてインタビューさせていただいたエンジニアの皆さん、2週間本当にありがとうございました！
参考
この記事は note に 2026-10-01 に公開したものを移したものです。