文化が数字を動かす。人柄採用から始まる、Recustomerの高い生産性と伝播する組織の作り方
文化が数字を動かす。人柄採用から始まる、Recustomerの高い生産性と伝播する組織の作り方
目次
目次を読み込み中...
「デプロイ頻度5倍、リードタイム1/6」。この数字だけを見れば、何か特別な技術施策を打ったのではないかと思う方も多いかもしれません。しかしRecustomer株式会社がこの改善を実現した背景には、ツールや手法の刷新だけでは説明できない、採用と組織文化への地道な投資がありました。
返品・交換後体験を支えるSaaSを展開する同社の開発組織は、プロダクトチーム13名という少数精鋭の体制です。Findy Team+ Awardを2年連続で受賞するほどの生産性を実現した同社が最初に着手したのは、「人柄を最重視する採用方針」の確立でした。技術力や実績よりも人柄を優先する。一見、生産性向上とは直結しないように見えるこの選択が、デモ駆動開発やDevOps文化の浸透、Bizを含む全社へのClaude Code展開を経て、最終的に劇的な数値改善へとつながっていきました。
本記事では、CTO眞鍋さんとEM・スクラムマスターを兼務する佐藤さんに、採用思想の背景から具体的な生産性改善施策、Findy Team+の活用方法まで、その全体像をお伺いしました。
プロフィール
眞鍋 秀悟さん CTO
京都大学理学部に首席で合格し、京都大学大学院を経てエンジニアの道へ。新卒で入社したフィックスターズにてExecutive Engineerとしてエンジニア開発をリードし上場を経験。その後Mujinにてアーキテクトを務める。Preferred NetworksではEngineering Managerを経て、HacobuではCTO室室長および研究開発部部長に着任。2024年5月、Recustomer株式会社にてCTOに就任し現在に至る。Startup CTO of the Year 2025 にてオーディエンス賞受賞。
佐藤 樹さん エンジニアリングマネージャー / スクラムマスター
高専で電気電子を専攻し、新卒でSIerに入社。2022年、Recustomer株式会社にフルスタックエンジニアとして入社。フロントエンド・バックエンドの開発を担当し、2024年にEMに就任。新規機能開発チームのマネジメントを担当しながら、自身もコードを書くプレイングマネージャーとして活動しています。
「人柄」採用が生む「呼応する組織」──AI時代に強いチームの土台は、技術力より先に作られていた
眞鍋： エンジニア組織の採用方針として「人柄」を重視するようになったのには、いくつか背景がありますが、やはりWeb系の会社という点は1つあるんです。
フロントエンド・バックエンド・インフラといったところで、その人1人が全ての領域を把握しているのはかなり稀です。CTOレベルの人であっても、これを全て深くまで完全に理解している人は恐らくいないほどに広く深い。なので、「集合知」で互いの弱みを補いながら製品を作ることがWeb開発では特に問われていて、そもそもコミュニケーションを取らないとスムーズに進まないからこそ、人柄が重要になってくるのです。
ビジネスを考えたときに、知識を知っていることが優位なのではなく、その知識を広めてみんなで推進したいというメンバーが大事だと思っています。
例えば「GraphQLを知らない人とは働きたくない」というエンジニアがいるとします。その人にとってはGraphQLはとても凄いもので当然なものということです。そして、自分たちが作っているプロダクトも、それもまた画期的な世界を変えるような凄いものになります。
しかしながら、どうでしょう。自分たちが作っている、その「凄いもの」は当然のように世界の誰もが使っているものでしょうか。それをオンボーディングや認知獲得、などいろいろなことをしてようやく、その「凄いもの」は使われるものに変わるのです。
ただ、特定の技術を「凄い」からあたり前というのは違っていて、こういうことを大事だと思い、浸透をさせようとする人が、プロダクトのことを考えられる、Recustomerが求めているエンジニアなのだと思っています。
眞鍋： 採用の面接では「チーム活動での失敗・成功談」と「上司や部下からの客観的な評価をあなたはどう思っているか」を必ず聞くようにしています。ポジティブな話しか出てこない人は、恐らく自己認識ができていないですね。
技術試験などは設けておらず、20分ほどで口頭試問をしていて、技術に関する質問に必ず答えてくれるよりは、正直に回答してくれるメンバーを重要視しています。知ったかぶりをするメンバーがチームに入ると、失敗を組織内で共有できなくなってしまう恐れがあります。
実際、お見送りになる理由はチームワーク、コミュニケーション、人間力の部分が多いですが、今までカンファレンスへの登壇率の高さや積極的な発信をしてきた影響もあり、面接で技術力が足りないからお見送りということはあまりないです。
同じカルチャーが浸透できている証拠となったアドベントカレンダー
眞鍋：1人がやるとみんなが勝手にやってくれるのが、本当にすごいところだと思います。例えばアドベントカレンダーは、8人で24記事はCTOとして「さすがに無理だからやめておきなよ」とずっと思っていました。しかし「やります」となり、本当にやり切ってしまう。その上、Zennのトレンドにもなる記事が多く生まれました。
勉強会も出席率はほぼ100%であり、夜遅くから急にAI勉強会が始まる時もあるのですが、POも含めてみんな集まるんですよね。
1on1で出てくる話も、「あのメンバーとうまくいかない」「チームを入れ替えたい」といったプロダクト開発において本質的でない課題は一切ありません。「こうしたいがどうしたらいいか」という前向きな話ができる点が、やはり人柄を一番大事にしているところの良さが出てきていると思っています。
オンボーディングでも「チーム単位で動いてほしい」ということは強く意識して伝えています。
チームを組んで進める中で間違いをきちんと認めることも大事にし、チーム内で失敗を経験することで、今後の取り組みがアップデートされていく。そのチームの8割ぐらいのメンバーが「これが大事だったんだ」と理解した状態で新しい人が入ってきたとき、過去の経験を通じてしっかりと伝えてくれるんです。
失敗を通してチームというスキルがアップデートできていくような仕組みが、自然とできていると感じています。
ガッツだけでは進まなかった──推進力のある船に、航海士が必要だった
眞鍋： 僕が入る前の状態は、少し心配する程ガッツのあるメンバーが多かったのですが、数ヶ月単位で見たときには、そこまで進んでいない状態でした。
推進力のある船にエンジンは積まれているのに、航海士がいない。ガッツと推進力はあるが、ビジネスとしての方向性がぶれていて、結果としてビジネス価値が低い状態になってしまっていました。
自分がジョインを決めた理由の一つは、組織マネジメントでもあります。効率よくビジネス価値を高めるためには何が必要かを強化しなければならないと考えていました。
実際、CTO候補の方が2〜3人来ていたらしいのですが、いずれも技術的なアプローチだけになってしまい、うまくいかなかったという経緯があったのです。
「今この1ヶ月、自分たちは何のために動いているのか」「この施策を実施することで、ビジネスとしてどれだけの価値が出るのか」そういった問いをメンバーに発信し続けることから始めました。
エンジニアが作ることだけに集中するのではなく、ビジネスを動かしている主役だという意識に変わっていくことが必要でした。
結果的に、入社して1年半前と比べると現在のチームレベルはとても上がっていると思います。
デプロイ頻度5倍・リードタイム1/6を実現した「やめたこと」と「変えたこと」──完璧主義を手放し、デモ駆動×DevOps×AI活用へ
動くものを見せることを最優先に──デモ駆動開発の導入
佐藤： デモ駆動開発を導入したのは、失敗から出た施策です。元々私たちは完璧主義で、全部作り切ってから初めてデプロイし、初めて人に見せるという状況でした。その結果、実際に見ると「ちょっと思ったのと違う」というフィードバックや手戻りが発生したり、同じチームなのに他のメンバーが何をやっているかわからない、という不健全な状態になっていたのです。
現在は1週間1スプリントというかなり早いサイクルで回し、スプリントの最後にスプリントレビューとしてデモ会を行っています。
まず動くものを見せることを優先した上で、タスクの優先度を決める。「まだ完成していないけど、こういうイメージで動きます」と事前に共有した上で、実際に動くものを見せる運用にしています。
導入当初は抵抗や課題もあり、「1週間で見せられるものがないです」といった声がありました。ただ、「PRベースで見せてもいいよ」とすると、意外と話が上がってくるんですよね。
「見せられるものがない」というのは、完成品を見せないといけない固定観念から来ていたと思います。
振り返ると、アジャイルと言いながらウォーターフォールに近い開発をしていたことに気づき、小さくどんどん試していく、あるべき文化に近づいていきました。
この取り組みを通じ、エンジニアがやる意義や背景理解が強まりました。言われたことをなんとかやり遂げようという考えから、「なぜやるのか」「お客さまはなぜこの機能を要望しているのか」という本質的な部分に目を向けられるようになりました。社内受託的に動くのではなく、一緒に価値を作るメンバーという理解ができるようになったと感じています。
佐藤： 逆にやめたことで一番大きかったのは、プロダクトオーナーが全てのデプロイに責任を持つ運用です。DevOpsという文化を取り入れ、開発だけでなく保守・運用まで一貫してエンジニアが責任を持つ形に変えました。
これにより、エンジニアが開発・検証・リリース・保守運用までを自律的に完結できるようになり、必要なときだけPOに力を借りることで、デプロイ頻度の改善に大きくつながったと思います。
全員が同じエコシステムに乗る──Claude Code全社浸透
佐藤： AI活用は会社で推奨しており、全員Claude Codeを使いながら開発をしています。メインのスプリントのタスクに加え、各々が感じている技術負債の解消も同時並行で進めているので、チーム内の浸透度は非常に高いです。直近でPR数も約5倍ほどになっています。
眞鍋： 他社のCTOと話していると「AIを使えないメンバーをどうするか」という話がよく出るのですが、その悩みがないんですよね。前提としてチームで動けているので、誰か1人がAIを使えない状況がない。1人がいい仕組みを作るとみんながやるようになるので、個人間の乖離がないんです。
ペアプロではないのですが「こんな開発してるよ」という“会話”が常にあって、ナレッジシェアが非常に活発です。ビジネス価値に注力しながら、裏側でもやるべきことをやりきっている状態ができています。
Biz側もClaude Codeを活用し始めている点も、特徴的なところです。
開発側でClaude Codeの事前設定を全て用意しているので、Biz側のメンバーが自然に使えるようになっています。ビジネス側がソースコードを全て閲覧できる状態にし、AIがそれを学習することで技術的な質問にも答えられる状態のため、エンジニアへの問い合わせが少なくなっています。
例えばデータ分析の場面でも、Biz側からエンジニアに問い合わせが来ていたものが、AIに質問するとSQLが自動的に生成され、HTMLで描画されるところまで全て自動化されています。こうした仕組みを社内で標準化しているので、エンジニアもBiz側に追いつかれてしまうという、良い意味での緊張感も生まれています。
数値目標を追いすぎた失敗──「傾向を見るもの」という考え方へ
佐藤：改善活動を進める中で、うまくいかなかった試みもあります。具体的な数値目標を持つことです。数値目標を設定すると、その数字をどうしたら達成できるかという方向に思考が向いてしまい、本質的ではない動きが見えるようになってしまいました。数値はあくまで組織の傾向を可視化するものであり、数字を達成したからといって顧客に対して新しい価値を作り出せているかどうかとは別の話なので、目標を持つことをやめました。
もう1つの失敗は、AIで過去の技術負債を解消するPRを大量生成する施策を推進したときのことです。結果、1デプロイの中にたくさんの内容が混在してしまい、テストが薄くなり量に埋もれてしまう問題が発生しました。
PRを作るのは簡単になりましたが、それを届けるところまでの意識づくりについて、あらためてチーム全体で認識を合わせる必要がありました。
Findy Team+の活用方法──数値を「管理」から「改善の楽しさ」と「称賛」へ変える運用術
佐藤： Findy Team+を導入して良かったのは、数値化しづらかったエンジニアのアクティビティが見えるようになり、自分たちの状況や傾向が把握できるようになったことです。
特に、特定のメンバーに対してレビューが偏ってしまい、レビュー負荷や開発負荷が大きくなっていたことが、画面上で見える点が良かったです。「負荷が偏っている」という感覚はチーム内にもありましたが、実際にUIで見えることで「これは確かに問題だよね」という共通認識をチーム全体で持つことができ、どう改善するかの議論に発展させられました。チーム体制やPRのレビュアーの見直しにつながり、全体の開発生産性の向上につながっています。
AI活用度をラベルで自動計測する
佐藤： AI活用度の可視化については、Claude CodeでPRを作成するコマンドの中に自動でラベルを付与する仕組みを組み込んでいます。後からラベルを付けようとすると漏れが発生してしまうので、自動化することで確実に計測できるようにしました。
可視化したことで想定外だったのは、AI活用によるリードタイムやサイクルタイムに好影響があったことです。
一方、AI活用によってアウトプットやアウトカムに爆発的な影響が出るだけでなく、むしろ新しいボトルネックが見えてきました。PRが増えたものの、人間のレビュー負荷が全体的に増加したこと。デプロイ対象のコミット数が多くなって検証の時間が増えたこと。そういった新しい課題の発見につながったのは、意外な気づきでした。
佐藤： Findy Team+のデータは週1回の振り返りで全員が確認するようにしています。エンジニアがなんとなく感じていた定性的なモヤモヤが、数値で見えることで裏付けられる側面があるからです。
例えばAI活用によってPR数が増えていく一方で、変更行数も一緒に増えていたことがありました。「PRを小さくしよう」「レビュアーにやさしいPRを作ろう」と話し合っていたはずが、いつの間にかその文化が薄れていたことが数値から見えてきたのです。メンバーから「自分もそう感じていた」という声が出たことで、改善の議論が自然に始まりました。
眞鍋：挑戦を推奨し、頑張っている人がいたらみんなの前で褒めるということも意識しています。一緒に協力して仕事をする文化がより高まり、スコアという形で表現されたことで、「自分もこういう行動を頑張ろう」と自然と真似をするようになり、集団としての結果につながってきています。
佐藤：実際、数値が良くないメンバーに対して、数字を押しつけるコミュニケーションはしていません。PRが出ていない場合は、まず背景や原因をヒアリングするようにしています。無理にアウトプットを上げようとするのではなく、AI活用の方法を一緒に見直したり、タスクの整理を手伝うなど、その人の状況に寄り添って一緒に考えるようにしています。
数値目標を持つことをやめた背景と同様、数値はあくまで共通認識を持つための共通言語であって、責める道具ではない。コードレビューで言えば、ただ最速でマージをするだけの人は単に「approve力が高いだけの人」。ただapproveをするだけであればAIのほうが得意なんです。どういうコードにしていきたいか、どういうチームにしていきたいかという文化の話こそが大事だと、メンバーには強く伝えています。
2年連続受賞の決め手は、施策ではなく文化だった
佐藤： Findy Team+ Awardを2年連続で受賞できたことは、決め手の施策ではなく、文化が一番大きかったと思います。
週1回デプロイできるかどうかの状態から、ここまで来られたのは、日常的な会話や行動、1行のコードを書くといったところに至るまでの小さな積み重ねです。
「Recustomerとしてどんな組織を目指すのか」という方向性がチームの中で一致していたからこそ、高い生産性につながる文化ができたと思います。
対外的に評価されたことで組織の自信にもつながり、「自分たちの取り組みは間違っていなかった」という確信が、次の発信や改善へのモチベーションにもなりました。
「強いエンジニア」の定義が変わった時代に──Recustomerで働くということ
眞鍋：昔は、強いエンジニア＝すごいコードが書ける人だったと思うのですが、ここから変わってきたなと感じています。
不確実な状況でも本質的な課題を見抜き、周囲を巻き込みながら継続的に価値を出せる人。一人よがりではなく、皆で協力して開発できる人。
そして様々なことへの挑戦意欲が高い人が、これからの時代に強いエンジニアだと思っています。
AIを活用した開発や価値提供に興味を持つエンジニアにとって、Recustomerはかなり挑戦しやすい環境です。ビジネスチームもClaude Codeを触って自動化している会社なので、互いに教え合える。エンジニアの活動がビジネスチーム全体に変化をもたらすことにもつながる会社です。
Claude Code Max 20xプランを誰でも使えますし、仕事能率を高めるためのキーバインドやショートカットの会話も日常的に飛び交っていて、作業能率の平均が高い。エンジニア同士の会話がとても多く、登壇や発信も当たり前に行っているので、新規ジョインメンバーにとっても自然とそういう文化が身につく環境になっていると思います。
Recustomer株式会社のエンジニア求人一覧
▶︎https://findy-code.io/companies/1720/jobs
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
「デプロイ頻度5倍、リードタイム1/6」。この数字だけを見れば、何か特別な技術施策を打ったのではないかと思う方も多いかもしれません。しかしRecustomer株式会社がこの改善を実現した背景には、ツールや手法の刷新だけでは説明できない、採用と組織文化への地道な投資がありました。
返品・交換後体験を支えるSaaSを展開する同社の開発組織は、プロダクトチーム13名という少数精鋭の体制です。Findy Team+ Awardを2年連続で受賞するほどの生産性を実現した同社が最初に着手したのは、「人柄を最重視する採用方針」の確立でした。技術力や実績よりも人柄を優先する。一見、生産性向上とは直結しないように見えるこの選択が、デモ駆動開発やDevOps文化の浸透、Bizを含む全社へのClaude Code展開を経て、最終的に劇的な数値改善へとつながっていきました。
本記事では、CTO眞鍋さんとEM・スクラムマスターを兼務する佐藤さんに、採用思想の背景から具体的な生産性改善施策、Findy Team+の活用方法まで、その全体像をお伺いしました。
プロフィール
眞鍋 秀悟さん CTO
京都大学理学部に首席で合格し、京都大学大学院を経てエンジニアの道へ。新卒で入社したフィックスターズにてExecutive Engineerとしてエンジニア開発をリードし上場を経験。その後Mujinにてアーキテクトを務める。Preferred NetworksではEngineering Managerを経て、HacobuではCTO室室長および研究開発部部長に着任。2024年5月、Recustomer株式会社にてCTOに就任し現在に至る。Startup CTO of the Year 2025 にてオーディエンス賞受賞。
佐藤 樹さん エンジニアリングマネージャー / スクラムマスター
高専で電気電子を専攻し、新卒でSIerに入社。2022年、Recustomer株式会社にフルスタックエンジニアとして入社。フロントエンド・バックエンドの開発を担当し、2024年にEMに就任。新規機能開発チームのマネジメントを担当しながら、自身もコードを書くプレイングマネージャーとして活動しています。
「人柄」採用が生む「呼応する組織」──AI時代に強いチームの土台は、技術力より先に作られていた
眞鍋： エンジニア組織の採用方針として「人柄」を重視するようになったのには、いくつか背景がありますが、やはりWeb系の会社という点は1つあるんです。
フロントエンド・バックエンド・インフラといったところで、その人1人が全ての領域を把握しているのはかなり稀です。CTOレベルの人であっても、これを全て深くまで完全に理解している人は恐らくいないほどに広く深い。なので、「集合知」で互いの弱みを補いながら製品を作ることがWeb開発では特に問われていて、そもそもコミュニケーションを取らないとスムーズに進まないからこそ、人柄が重要になってくるのです。
ビジネスを考えたときに、知識を知っていることが優位なのではなく、その知識を広めてみんなで推進したいというメンバーが大事だと思っています。
例えば「GraphQLを知らない人とは働きたくない」というエンジニアがいるとします。その人にとってはGraphQLはとても凄いもので当然なものということです。そして、自分たちが作っているプロダクトも、それもまた画期的な世界を変えるような凄いものになります。
しかしながら、どうでしょう。自分たちが作っている、その「凄いもの」は当然のように世界の誰もが使っているものでしょうか。それをオンボーディングや認知獲得、などいろいろなことをしてようやく、その「凄いもの」は使われるものに変わるのです。
ただ、特定の技術を「凄い」からあたり前というのは違っていて、こういうことを大事だと思い、浸透をさせようとする人が、プロダクトのことを考えられる、Recustomerが求めているエンジニアなのだと思っています。
眞鍋： 採用の面接では「チーム活動での失敗・成功談」と「上司や部下からの客観的な評価をあなたはどう思っているか」を必ず聞くようにしています。ポジティブな話しか出てこない人は、恐らく自己認識ができていないですね。
技術試験などは設けておらず、20分ほどで口頭試問をしていて、技術に関する質問に必ず答えてくれるよりは、正直に回答してくれるメンバーを重要視しています。知ったかぶりをするメンバーがチームに入ると、失敗を組織内で共有できなくなってしまう恐れがあります。
実際、お見送りになる理由はチームワーク、コミュニケーション、人間力の部分が多いですが、今までカンファレンスへの登壇率の高さや積極的な発信をしてきた影響もあり、面接で技術力が足りないからお見送りということはあまりないです。
同じカルチャーが浸透できている証拠となったアドベントカレンダー
眞鍋：1人がやるとみんなが勝手にやってくれるのが、本当にすごいところだと思います。例えばアドベントカレンダーは、8人で24記事はCTOとして「さすがに無理だからやめておきなよ」とずっと思っていました。しかし「やります」となり、本当にやり切ってしまう。その上、Zennのトレンドにもなる記事が多く生まれました。
勉強会も出席率はほぼ100%であり、夜遅くから急にAI勉強会が始まる時もあるのですが、POも含めてみんな集まるんですよね。
1on1で出てくる話も、「あのメンバーとうまくいかない」「チームを入れ替えたい」といったプロダクト開発において本質的でない課題は一切ありません。「こうしたいがどうしたらいいか」という前向きな話ができる点が、やはり人柄を一番大事にしているところの良さが出てきていると思っています。
オンボーディングでも「チーム単位で動いてほしい」ということは強く意識して伝えています。
チームを組んで進める中で間違いをきちんと認めることも大事にし、チーム内で失敗を経験することで、今後の取り組みがアップデートされていく。そのチームの8割ぐらいのメンバーが「これが大事だったんだ」と理解した状態で新しい人が入ってきたとき、過去の経験を通じてしっかりと伝えてくれるんです。
失敗を通してチームというスキルがアップデートできていくような仕組みが、自然とできていると感じています。
ガッツだけでは進まなかった──推進力のある船に、航海士が必要だった
眞鍋： 僕が入る前の状態は、少し心配する程ガッツのあるメンバーが多かったのですが、数ヶ月単位で見たときには、そこまで進んでいない状態でした。
推進力のある船にエンジンは積まれているのに、航海士がいない。ガッツと推進力はあるが、ビジネスとしての方向性がぶれていて、結果としてビジネス価値が低い状態になってしまっていました。
自分がジョインを決めた理由の一つは、組織マネジメントでもあります。効率よくビジネス価値を高めるためには何が必要かを強化しなければならないと考えていました。
実際、CTO候補の方が2〜3人来ていたらしいのですが、いずれも技術的なアプローチだけになってしまい、うまくいかなかったという経緯があったのです。
「今この1ヶ月、自分たちは何のために動いているのか」「この施策を実施することで、ビジネスとしてどれだけの価値が出るのか」そういった問いをメンバーに発信し続けることから始めました。
エンジニアが作ることだけに集中するのではなく、ビジネスを動かしている主役だという意識に変わっていくことが必要でした。
結果的に、入社して1年半前と比べると現在のチームレベルはとても上がっていると思います。
デプロイ頻度5倍・リードタイム1/6を実現した「やめたこと」と「変えたこと」──完璧主義を手放し、デモ駆動×DevOps×AI活用へ
動くものを見せることを最優先に──デモ駆動開発の導入
佐藤： デモ駆動開発を導入したのは、失敗から出た施策です。元々私たちは完璧主義で、全部作り切ってから初めてデプロイし、初めて人に見せるという状況でした。その結果、実際に見ると「ちょっと思ったのと違う」というフィードバックや手戻りが発生したり、同じチームなのに他のメンバーが何をやっているかわからない、という不健全な状態になっていたのです。
現在は1週間1スプリントというかなり早いサイクルで回し、スプリントの最後にスプリントレビューとしてデモ会を行っています。
まず動くものを見せることを優先した上で、タスクの優先度を決める。「まだ完成していないけど、こういうイメージで動きます」と事前に共有した上で、実際に動くものを見せる運用にしています。
導入当初は抵抗や課題もあり、「1週間で見せられるものがないです」といった声がありました。ただ、「PRベースで見せてもいいよ」とすると、意外と話が上がってくるんですよね。
「見せられるものがない」というのは、完成品を見せないといけない固定観念から来ていたと思います。
振り返ると、アジャイルと言いながらウォーターフォールに近い開発をしていたことに気づき、小さくどんどん試していく、あるべき文化に近づいていきました。
この取り組みを通じ、エンジニアがやる意義や背景理解が強まりました。言われたことをなんとかやり遂げようという考えから、「なぜやるのか」「お客さまはなぜこの機能を要望しているのか」という本質的な部分に目を向けられるようになりました。社内受託的に動くのではなく、一緒に価値を作るメンバーという理解ができるようになったと感じています。
佐藤： 逆にやめたことで一番大きかったのは、プロダクトオーナーが全てのデプロイに責任を持つ運用です。DevOpsという文化を取り入れ、開発だけでなく保守・運用まで一貫してエンジニアが責任を持つ形に変えました。
これにより、エンジニアが開発・検証・リリース・保守運用までを自律的に完結できるようになり、必要なときだけPOに力を借りることで、デプロイ頻度の改善に大きくつながったと思います。
全員が同じエコシステムに乗る──Claude Code全社浸透
佐藤： AI活用は会社で推奨しており、全員Claude Codeを使いながら開発をしています。メインのスプリントのタスクに加え、各々が感じている技術負債の解消も同時並行で進めているので、チーム内の浸透度は非常に高いです。直近でPR数も約5倍ほどになっています。
眞鍋： 他社のCTOと話していると「AIを使えないメンバーをどうするか」という話がよく出るのですが、その悩みがないんですよね。前提としてチームで動けているので、誰か1人がAIを使えない状況がない。1人がいい仕組みを作るとみんながやるようになるので、個人間の乖離がないんです。
ペアプロではないのですが「こんな開発してるよ」という“会話”が常にあって、ナレッジシェアが非常に活発です。ビジネス価値に注力しながら、裏側でもやるべきことをやりきっている状態ができています。
Biz側もClaude Codeを活用し始めている点も、特徴的なところです。
開発側でClaude Codeの事前設定を全て用意しているので、Biz側のメンバーが自然に使えるようになっています。ビジネス側がソースコードを全て閲覧できる状態にし、AIがそれを学習することで技術的な質問にも答えられる状態のため、エンジニアへの問い合わせが少なくなっています。
例えばデータ分析の場面でも、Biz側からエンジニアに問い合わせが来ていたものが、AIに質問するとSQLが自動的に生成され、HTMLで描画されるところまで全て自動化されています。こうした仕組みを社内で標準化しているので、エンジニアもBiz側に追いつかれてしまうという、良い意味での緊張感も生まれています。
数値目標を追いすぎた失敗──「傾向を見るもの」という考え方へ
佐藤：改善活動を進める中で、うまくいかなかった試みもあります。具体的な数値目標を持つことです。数値目標を設定すると、その数字をどうしたら達成できるかという方向に思考が向いてしまい、本質的ではない動きが見えるようになってしまいました。数値はあくまで組織の傾向を可視化するものであり、数字を達成したからといって顧客に対して新しい価値を作り出せているかどうかとは別の話なので、目標を持つことをやめました。
もう1つの失敗は、AIで過去の技術負債を解消するPRを大量生成する施策を推進したときのことです。結果、1デプロイの中にたくさんの内容が混在してしまい、テストが薄くなり量に埋もれてしまう問題が発生しました。
PRを作るのは簡単になりましたが、それを届けるところまでの意識づくりについて、あらためてチーム全体で認識を合わせる必要がありました。
Findy Team+の活用方法──数値を「管理」から「改善の楽しさ」と「称賛」へ変える運用術
佐藤： Findy Team+を導入して良かったのは、数値化しづらかったエンジニアのアクティビティが見えるようになり、自分たちの状況や傾向が把握できるようになったことです。
特に、特定のメンバーに対してレビューが偏ってしまい、レビュー負荷や開発負荷が大きくなっていたことが、画面上で見える点が良かったです。「負荷が偏っている」という感覚はチーム内にもありましたが、実際にUIで見えることで「これは確かに問題だよね」という共通認識をチーム全体で持つことができ、どう改善するかの議論に発展させられました。チーム体制やPRのレビュアーの見直しにつながり、全体の開発生産性の向上につながっています。
AI活用度をラベルで自動計測する
佐藤： AI活用度の可視化については、Claude CodeでPRを作成するコマンドの中に自動でラベルを付与する仕組みを組み込んでいます。後からラベルを付けようとすると漏れが発生してしまうので、自動化することで確実に計測できるようにしました。
可視化したことで想定外だったのは、AI活用によるリードタイムやサイクルタイムに好影響があったことです。
一方、AI活用によってアウトプットやアウトカムに爆発的な影響が出るだけでなく、むしろ新しいボトルネックが見えてきました。PRが増えたものの、人間のレビュー負荷が全体的に増加したこと。デプロイ対象のコミット数が多くなって検証の時間が増えたこと。そういった新しい課題の発見につながったのは、意外な気づきでした。
佐藤： Findy Team+のデータは週1回の振り返りで全員が確認するようにしています。エンジニアがなんとなく感じていた定性的なモヤモヤが、数値で見えることで裏付けられる側面があるからです。
例えばAI活用によってPR数が増えていく一方で、変更行数も一緒に増えていたことがありました。「PRを小さくしよう」「レビュアーにやさしいPRを作ろう」と話し合っていたはずが、いつの間にかその文化が薄れていたことが数値から見えてきたのです。メンバーから「自分もそう感じていた」という声が出たことで、改善の議論が自然に始まりました。
眞鍋：挑戦を推奨し、頑張っている人がいたらみんなの前で褒めるということも意識しています。一緒に協力して仕事をする文化がより高まり、スコアという形で表現されたことで、「自分もこういう行動を頑張ろう」と自然と真似をするようになり、集団としての結果につながってきています。
佐藤：実際、数値が良くないメンバーに対して、数字を押しつけるコミュニケーションはしていません。PRが出ていない場合は、まず背景や原因をヒアリングするようにしています。無理にアウトプットを上げようとするのではなく、AI活用の方法を一緒に見直したり、タスクの整理を手伝うなど、その人の状況に寄り添って一緒に考えるようにしています。
数値目標を持つことをやめた背景と同様、数値はあくまで共通認識を持つための共通言語であって、責める道具ではない。コードレビューで言えば、ただ最速でマージをするだけの人は単に「approve力が高いだけの人」。ただapproveをするだけであればAIのほうが得意なんです。どういうコードにしていきたいか、どういうチームにしていきたいかという文化の話こそが大事だと、メンバーには強く伝えています。
2年連続受賞の決め手は、施策ではなく文化だった
佐藤： Findy Team+ Awardを2年連続で受賞できたことは、決め手の施策ではなく、文化が一番大きかったと思います。
週1回デプロイできるかどうかの状態から、ここまで来られたのは、日常的な会話や行動、1行のコードを書くといったところに至るまでの小さな積み重ねです。
「Recustomerとしてどんな組織を目指すのか」という方向性がチームの中で一致していたからこそ、高い生産性につながる文化ができたと思います。
対外的に評価されたことで組織の自信にもつながり、「自分たちの取り組みは間違っていなかった」という確信が、次の発信や改善へのモチベーションにもなりました。
「強いエンジニア」の定義が変わった時代に──Recustomerで働くということ
眞鍋：昔は、強いエンジニア＝すごいコードが書ける人だったと思うのですが、ここから変わってきたなと感じています。
不確実な状況でも本質的な課題を見抜き、周囲を巻き込みながら継続的に価値を出せる人。一人よがりではなく、皆で協力して開発できる人。
そして様々なことへの挑戦意欲が高い人が、これからの時代に強いエンジニアだと思っています。
AIを活用した開発や価値提供に興味を持つエンジニアにとって、Recustomerはかなり挑戦しやすい環境です。ビジネスチームもClaude Codeを触って自動化している会社なので、互いに教え合える。エンジニアの活動がビジネスチーム全体に変化をもたらすことにもつながる会社です。
Claude Code Max 20xプランを誰でも使えますし、仕事能率を高めるためのキーバインドやショートカットの会話も日常的に飛び交っていて、作業能率の平均が高い。エンジニア同士の会話がとても多く、登壇や発信も当たり前に行っているので、新規ジョインメンバーにとっても自然とそういう文化が身につく環境になっていると思います。
Recustomer株式会社のエンジニア求人一覧
▶︎https://findy-code.io/companies/1720/jobs
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
文化が数字を動かす。人柄採用から始まる、Recustomerの高い生産性と伝播する組織の作り方
「デプロイ頻度5倍、リードタイム1/6」。この数字だけを見れば、何か特別な技術施策を打ったのではないかと思う方も多いかもしれません。しかしRecustomer株式会社がこの改善を実現した背景には、ツールや手法の刷新だけでは説明できない、採用と組織文化への地道な投資がありました。
返品・交換後体験を支えるSaaSを展開する同社の開発組織は、プロダクトチーム13名という少数精鋭の体制です。Findy Team+ Awardを2年連続で受賞するほどの生産性を実現した同社が最初に着手したのは、「人柄を最重視する採用方針」の確立でした。技術力や実績よりも人柄を優先する。一見、生産性向上とは直結しないように見えるこの選択が、デモ駆動開発やDevOps文化の浸透、Bizを含む全社へのClaude Code展開を経て、最終的に劇的な数値改善へとつながっていきました。
本記事では、CTO眞鍋さんとEM・スクラムマスターを兼務する佐藤さんに、採用思想の背景から具体的な生産性改善施策、Findy Team+の活用方法まで、その全体像をお伺いしました。
プロフィール
眞鍋 秀悟さん CTO
京都大学理学部に首席で合格し、京都大学大学院を経てエンジニアの道へ。新卒で入社したフィックスターズにてExecutive Engineerとしてエンジニア開発をリードし上場を経験。その後Mujinにてアーキテクトを務める。Preferred NetworksではEngineering Managerを経て、HacobuではCTO室室長および研究開発部部長に着任。2024年5月、Recustomer株式会社にてCTOに就任し現在に至る。Startup CTO of the Year 2025 にてオーディエンス賞受賞。
佐藤 樹さん エンジニアリングマネージャー / スクラムマスター
高専で電気電子を専攻し、新卒でSIerに入社。2022年、Recustomer株式会社にフルスタックエンジニアとして入社。フロントエンド・バックエンドの開発を担当し、2024年にEMに就任。新規機能開発チームのマネジメントを担当しながら、自身もコードを書くプレイングマネージャーとして活動しています。
「人柄」採用が生む「呼応する組織」──AI時代に強いチームの土台は、技術力より先に作られていた
眞鍋： エンジニア組織の採用方針として「人柄」を重視するようになったのには、いくつか背景がありますが、やはりWeb系の会社という点は1つあるんです。
フロントエンド・バックエンド・インフラといったところで、その人1人が全ての領域を把握しているのはかなり稀です。CTOレベルの人であっても、これを全て深くまで完全に理解している人は恐らくいないほどに広く深い。なので、「集合知」で互いの弱みを補いながら製品を作ることがWeb開発では特に問われていて、そもそもコミュニケーションを取らないとスムーズに進まないからこそ、人柄が重要になってくるのです。
ビジネスを考えたときに、知識を知っていることが優位なのではなく、その知識を広めてみんなで推進したいというメンバーが大事だと思っています。
例えば「GraphQLを知らない人とは働きたくない」というエンジニアがいるとします。その人にとってはGraphQLはとても凄いもので当然なものということです。そして、自分たちが作っているプロダクトも、それもまた画期的な世界を変えるような凄いものになります。
しかしながら、どうでしょう。自分たちが作っている、その「凄いもの」は当然のように世界の誰もが使っているものでしょうか。それをオンボーディングや認知獲得、などいろいろなことをしてようやく、その「凄いもの」は使われるものに変わるのです。
ただ、特定の技術を「凄い」からあたり前というのは違っていて、こういうことを大事だと思い、浸透をさせようとする人が、プロダクトのことを考えられる、Recustomerが求めているエンジニアなのだと思っています。
眞鍋： 採用の面接では「チーム活動での失敗・成功談」と「上司や部下からの客観的な評価をあなたはどう思っているか」を必ず聞くようにしています。ポジティブな話しか出てこない人は、恐らく自己認識ができていないですね。
技術試験などは設けておらず、20分ほどで口頭試問をしていて、技術に関する質問に必ず答えてくれるよりは、正直に回答してくれるメンバーを重要視しています。知ったかぶりをするメンバーがチームに入ると、失敗を組織内で共有できなくなってしまう恐れがあります。
実際、お見送りになる理由はチームワーク、コミュニケーション、人間力の部分が多いですが、今までカンファレンスへの登壇率の高さや積極的な発信をしてきた影響もあり、面接で技術力が足りないからお見送りということはあまりないです。
同じカルチャーが浸透できている証拠となったアドベントカレンダー
眞鍋：1人がやるとみんなが勝手にやってくれるのが、本当にすごいところだと思います。例えばアドベントカレンダーは、8人で24記事はCTOとして「さすがに無理だからやめておきなよ」とずっと思っていました。しかし「やります」となり、本当にやり切ってしまう。その上、Zennのトレンドにもなる記事が多く生まれました。
勉強会も出席率はほぼ100%であり、夜遅くから急にAI勉強会が始まる時もあるのですが、POも含めてみんな集まるんですよね。
1on1で出てくる話も、「あのメンバーとうまくいかない」「チームを入れ替えたい」といったプロダクト開発において本質的でない課題は一切ありません。「こうしたいがどうしたらいいか」という前向きな話ができる点が、やはり人柄を一番大事にしているところの良さが出てきていると思っています。
オンボーディングでも「チーム単位で動いてほしい」ということは強く意識して伝えています。
チームを組んで進める中で間違いをきちんと認めることも大事にし、チーム内で失敗を経験することで、今後の取り組みがアップデートされていく。そのチームの8割ぐらいのメンバーが「これが大事だったんだ」と理解した状態で新しい人が入ってきたとき、過去の経験を通じてしっかりと伝えてくれるんです。
失敗を通してチームというスキルがアップデートできていくような仕組みが、自然とできていると感じています。
ガッツだけでは進まなかった──推進力のある船に、航海士が必要だった
眞鍋： 僕が入る前の状態は、少し心配する程ガッツのあるメンバーが多かったのですが、数ヶ月単位で見たときには、そこまで進んでいない状態でした。
推進力のある船にエンジンは積まれているのに、航海士がいない。ガッツと推進力はあるが、ビジネスとしての方向性がぶれていて、結果としてビジネス価値が低い状態になってしまっていました。
自分がジョインを決めた理由の一つは、組織マネジメントでもあります。効率よくビジネス価値を高めるためには何が必要かを強化しなければならないと考えていました。
実際、CTO候補の方が2〜3人来ていたらしいのですが、いずれも技術的なアプローチだけになってしまい、うまくいかなかったという経緯があったのです。
「今この1ヶ月、自分たちは何のために動いているのか」「この施策を実施することで、ビジネスとしてどれだけの価値が出るのか」そういった問いをメンバーに発信し続けることから始めました。
エンジニアが作ることだけに集中するのではなく、ビジネスを動かしている主役だという意識に変わっていくことが必要でした。
結果的に、入社して1年半前と比べると現在のチームレベルはとても上がっていると思います。
デプロイ頻度5倍・リードタイム1/6を実現した「やめたこと」と「変えたこと」──完璧主義を手放し、デモ駆動×DevOps×AI活用へ
動くものを見せることを最優先に──デモ駆動開発の導入
佐藤： デモ駆動開発を導入したのは、失敗から出た施策です。元々私たちは完璧主義で、全部作り切ってから初めてデプロイし、初めて人に見せるという状況でした。その結果、実際に見ると「ちょっと思ったのと違う」というフィードバックや手戻りが発生したり、同じチームなのに他のメンバーが何をやっているかわからない、という不健全な状態になっていたのです。
現在は1週間1スプリントというかなり早いサイクルで回し、スプリントの最後にスプリントレビューとしてデモ会を行っています。
まず動くものを見せることを優先した上で、タスクの優先度を決める。「まだ完成していないけど、こういうイメージで動きます」と事前に共有した上で、実際に動くものを見せる運用にしています。
導入当初は抵抗や課題もあり、「1週間で見せられるものがないです」といった声がありました。ただ、「PRベースで見せてもいいよ」とすると、意外と話が上がってくるんですよね。
「見せられるものがない」というのは、完成品を見せないといけない固定観念から来ていたと思います。
振り返ると、アジャイルと言いながらウォーターフォールに近い開発をしていたことに気づき、小さくどんどん試していく、あるべき文化に近づいていきました。
この取り組みを通じ、エンジニアがやる意義や背景理解が強まりました。言われたことをなんとかやり遂げようという考えから、「なぜやるのか」「お客さまはなぜこの機能を要望しているのか」という本質的な部分に目を向けられるようになりました。社内受託的に動くのではなく、一緒に価値を作るメンバーという理解ができるようになったと感じています。
佐藤： 逆にやめたことで一番大きかったのは、プロダクトオーナーが全てのデプロイに責任を持つ運用です。DevOpsという文化を取り入れ、開発だけでなく保守・運用まで一貫してエンジニアが責任を持つ形に変えました。
これにより、エンジニアが開発・検証・リリース・保守運用までを自律的に完結できるようになり、必要なときだけPOに力を借りることで、デプロイ頻度の改善に大きくつながったと思います。
全員が同じエコシステムに乗る──Claude Code全社浸透
佐藤： AI活用は会社で推奨しており、全員Claude Codeを使いながら開発をしています。メインのスプリントのタスクに加え、各々が感じている技術負債の解消も同時並行で進めているので、チーム内の浸透度は非常に高いです。直近でPR数も約5倍ほどになっています。
眞鍋： 他社のCTOと話していると「AIを使えないメンバーをどうするか」という話がよく出るのですが、その悩みがないんですよね。前提としてチームで動けているので、誰か1人がAIを使えない状況がない。1人がいい仕組みを作るとみんながやるようになるので、個人間の乖離がないんです。
ペアプロではないのですが「こんな開発してるよ」という“会話”が常にあって、ナレッジシェアが非常に活発です。ビジネス価値に注力しながら、裏側でもやるべきことをやりきっている状態ができています。
Biz側もClaude Codeを活用し始めている点も、特徴的なところです。
開発側でClaude Codeの事前設定を全て用意しているので、Biz側のメンバーが自然に使えるようになっています。ビジネス側がソースコードを全て閲覧できる状態にし、AIがそれを学習することで技術的な質問にも答えられる状態のため、エンジニアへの問い合わせが少なくなっています。
例えばデータ分析の場面でも、Biz側からエンジニアに問い合わせが来ていたものが、AIに質問するとSQLが自動的に生成され、HTMLで描画されるところまで全て自動化されています。こうした仕組みを社内で標準化しているので、エンジニアもBiz側に追いつかれてしまうという、良い意味での緊張感も生まれています。
数値目標を追いすぎた失敗──「傾向を見るもの」という考え方へ
佐藤：改善活動を進める中で、うまくいかなかった試みもあります。具体的な数値目標を持つことです。数値目標を設定すると、その数字をどうしたら達成できるかという方向に思考が向いてしまい、本質的ではない動きが見えるようになってしまいました。数値はあくまで組織の傾向を可視化するものであり、数字を達成したからといって顧客に対して新しい価値を作り出せているかどうかとは別の話なので、目標を持つことをやめました。
もう1つの失敗は、AIで過去の技術負債を解消するPRを大量生成する施策を推進したときのことです。結果、1デプロイの中にたくさんの内容が混在してしまい、テストが薄くなり量に埋もれてしまう問題が発生しました。
PRを作るのは簡単になりましたが、それを届けるところまでの意識づくりについて、あらためてチーム全体で認識を合わせる必要がありました。
Findy Team+の活用方法──数値を「管理」から「改善の楽しさ」と「称賛」へ変える運用術
佐藤： Findy Team+を導入して良かったのは、数値化しづらかったエンジニアのアクティビティが見えるようになり、自分たちの状況や傾向が把握できるようになったことです。
特に、特定のメンバーに対してレビューが偏ってしまい、レビュー負荷や開発負荷が大きくなっていたことが、画面上で見える点が良かったです。「負荷が偏っている」という感覚はチーム内にもありましたが、実際にUIで見えることで「これは確かに問題だよね」という共通認識をチーム全体で持つことができ、どう改善するかの議論に発展させられました。チーム体制やPRのレビュアーの見直しにつながり、全体の開発生産性の向上につながっています。
AI活用度をラベルで自動計測する
佐藤： AI活用度の可視化については、Claude CodeでPRを作成するコマンドの中に自動でラベルを付与する仕組みを組み込んでいます。後からラベルを付けようとすると漏れが発生してしまうので、自動化することで確実に計測できるようにしました。
可視化したことで想定外だったのは、AI活用によるリードタイムやサイクルタイムに好影響があったことです。
一方、AI活用によってアウトプットやアウトカムに爆発的な影響が出るだけでなく、むしろ新しいボトルネックが見えてきました。PRが増えたものの、人間のレビュー負荷が全体的に増加したこと。デプロイ対象のコミット数が多くなって検証の時間が増えたこと。そういった新しい課題の発見につながったのは、意外な気づきでした。
佐藤： Findy Team+のデータは週1回の振り返りで全員が確認するようにしています。エンジニアがなんとなく感じていた定性的なモヤモヤが、数値で見えることで裏付けられる側面があるからです。
例えばAI活用によってPR数が増えていく一方で、変更行数も一緒に増えていたことがありました。「PRを小さくしよう」「レビュアーにやさしいPRを作ろう」と話し合っていたはずが、いつの間にかその文化が薄れていたことが数値から見えてきたのです。メンバーから「自分もそう感じていた」という声が出たことで、改善の議論が自然に始まりました。
眞鍋：挑戦を推奨し、頑張っている人がいたらみんなの前で褒めるということも意識しています。一緒に協力して仕事をする文化がより高まり、スコアという形で表現されたことで、「自分もこういう行動を頑張ろう」と自然と真似をするようになり、集団としての結果につながってきています。
佐藤：実際、数値が良くないメンバーに対して、数字を押しつけるコミュニケーションはしていません。PRが出ていない場合は、まず背景や原因をヒアリングするようにしています。無理にアウトプットを上げようとするのではなく、AI活用の方法を一緒に見直したり、タスクの整理を手伝うなど、その人の状況に寄り添って一緒に考えるようにしています。
数値目標を持つことをやめた背景と同様、数値はあくまで共通認識を持つための共通言語であって、責める道具ではない。コードレビューで言えば、ただ最速でマージをするだけの人は単に「approve力が高いだけの人」。ただapproveをするだけであればAIのほうが得意なんです。どういうコードにしていきたいか、どういうチームにしていきたいかという文化の話こそが大事だと、メンバーには強く伝えています。
2年連続受賞の決め手は、施策ではなく文化だった
佐藤： Findy Team+ Awardを2年連続で受賞できたことは、決め手の施策ではなく、文化が一番大きかったと思います。
週1回デプロイできるかどうかの状態から、ここまで来られたのは、日常的な会話や行動、1行のコードを書くといったところに至るまでの小さな積み重ねです。
「Recustomerとしてどんな組織を目指すのか」という方向性がチームの中で一致していたからこそ、高い生産性につながる文化ができたと思います。
対外的に評価されたことで組織の自信にもつながり、「自分たちの取り組みは間違っていなかった」という確信が、次の発信や改善へのモチベーションにもなりました。
「強いエンジニア」の定義が変わった時代に──Recustomerで働くということ
眞鍋：昔は、強いエンジニア＝すごいコードが書ける人だったと思うのですが、ここから変わってきたなと感じています。
不確実な状況でも本質的な課題を見抜き、周囲を巻き込みながら継続的に価値を出せる人。一人よがりではなく、皆で協力して開発できる人。
そして様々なことへの挑戦意欲が高い人が、これからの時代に強いエンジニアだと思っています。
AIを活用した開発や価値提供に興味を持つエンジニアにとって、Recustomerはかなり挑戦しやすい環境です。ビジネスチームもClaude Codeを触って自動化している会社なので、互いに教え合える。エンジニアの活動がビジネスチーム全体に変化をもたらすことにもつながる会社です。
Claude Code Max 20xプランを誰でも使えますし、仕事能率を高めるためのキーバインドやショートカットの会話も日常的に飛び交っていて、作業能率の平均が高い。エンジニア同士の会話がとても多く、登壇や発信も当たり前に行っているので、新規ジョインメンバーにとっても自然とそういう文化が身につく環境になっていると思います。
Recustomer株式会社のエンジニア求人一覧
▶︎https://findy-code.io/companies/1720/jobs
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
