新卒がEightのエンジニアになって半年間で学んだこと

2025年の4月に入社した荒木です。入社して半年が経ったタイミングで、Eightでの開発を通じて感じた学びや成長を振り返ってみたいと思います。

はじめに

Eightに配属されてからの半年間、日々の開発を通じて大規模プロダクトを支える仕組みと独自のチーム文化に触れ、学び続けてきました。壁にぶつかるたびに、技術理解やコミュニケーションの不足を痛感しつつも、今は「ユーザーに価値を届ける」視点で開発に向き合えるようになっています。本記事では、入社の理由、取り組み、学び、今後の挑戦を振り返ります。

自己紹介

現在はEightのバックエンドエンジニアとして、主にRuby on Railsを用いた開発に携わっています。学生時代は、データサイエンティスト・機械学習エンジニアといったデータサイエンス領域を中心に活動していました。データを通じて課題を発見し、そこから新たな示唆を得て意思決定を変えていく力に魅力を感じ、「データを軸に事業価値を生み出せる環境」で働きたいと考えていました。

Eightを選んだ理由

まず、Sansanに入社を決めた理由は、「人と人のつながり」というユニークなデータを高品質に整備し、それを基盤に複数の事業を展開している点に強く惹かれたからです。その中でもEightを選んだのは、「データ × プロダクト」両面から挑戦できる環境があったからでした。社内にある複数のプロダクトの中で規模感も合わせるとビジネスサイドと開発サイドが最も密に連携してると思いました。そのため、データを起点とした仮説検証やプロダクト改善に関われる機会が多く、さらにプロダクト開発の両立も実現できることから、自分が目指すキャリアの方向と合致していました。また、早い段階から大規模なプロダクト開発に携わることで、現場での経験を通じて「プロダクト視点でのデータ活用」を実践的に学ぶことができ、自分が描くキャリアを具現化できると感じました。

入社後に取り組んだこと

配属後の半年間は、プロダクト開発を通して設計・運用・ユーザー体験の全体像を学ぶことを意識しました。その中でも印象に残っているのが、これから紹介する2つの取り組みです。

名刺交換後にデジタル名刺メールを送信できる機能の開発

Eightでは、名刺交換後にそのまま相手にメールを送れる機能があり、その開発を担当しました。この機能には、撮影方法に応じて同期的に送信するパターンと非同期的に送信するパターンがあり、自分は後者を担当しました。

非同期の場合の名刺交換からメール送信までの大まかな流れはこんな感じです。今回は後半2つのキュー追加からメール送信までが開発対象です。

この一連の処理では、「パフォーマンスとユーザー体験の両立」が大きなテーマでした。特に次のような課題がありました。

データ化が完了しないとメールが送れない
スレッド数を増やすと処理は速くなるが、コストやバウンス率が悪化する
一括処理すると深夜にメールが送られることがあり、ビジネスメールとして不適切で体験が悪化する
送信失敗時の再試行設計がなく、信頼性を担保しづらい

これらを解決するために、ECS Scheduled Taskを利用して送信時間を柔軟に制御できる仕組みを導入しました。スレッド数については普段のメール数と1つ当たりの送信時間に対して、ビジネスメールとして適切な送信時刻に送られるように調整して、処理性能・コスト・バウンス率のバランスを最適化しました。さらに、再試行処理を導入し、失敗時にも確実にメールを届けられる仕組みを実現しました。

最終的には、社内共有会で開発内容を発表し、ビジネスサイドからのフィードバックを受けながらリリースまで辿り着くことができ、ユーザーが名刺交換後に安心してメールを送信できる体験を提供できました。この開発を通して、パフォーマンスを追求しながらもユーザー体験を損なわない設計の難しさと面白さを実感しました。

Stripeの運用改善

EightにはtoBプロダクトとしてEight Teamという中小企業向けの名刺管理サービスがあります。このサービスでは、決済処理にStripeを利用しています。

当時、StripeとEightの契約管理ロジックに月ずれが発生するという課題がありました。原因は、Stripeが決済処理のみを担い、支払いが確認されたタイミングでEight側の契約が開始される設計にありました。支払い状況によって、次のようなずれが生じていました。

正常パターン：毎月支払い → Stripe契約期間 = Eight契約期間
異常パターン：支払い滞納・数ヶ月分まとめ払い → Stripe契約期間 ≠ Eight契約期間

このずれが蓄積すると、契約更新処理が失敗し、運用チームが手動でデータを修正する必要があり、日々の運用負荷が高い状態になっていました。この問題に対して、まず既存の決済ロジックを丁寧に読み解き、StripeとEight側のそれぞれで契約更新がどう行われているかを整理した結果、次のことがわかりました。

解約意思がなくても、滞納などがあると自動更新されない仕様になっていた
その結果、支払い滞納や数ヶ月分の一括支払いによって、Stripe側とEight側で契約期間がずれ、更新処理が失敗していた

本来はユーザーとの契約上、解約意思がない場合は自動更新をするのが正しい挙動であるため、その仕様に合わせてEight側の処理を修正しました。修正に当たっては、CSチームとも連携し、ユーザー対応の観点で問題がないかを確認し、無事にリリースできました。

結果として、月ずれの例外は解消し、運用チームの対応は不要となり、年間で見ると数時間分の対応工数を削減できました。一見すると小さな改善に見えますが、こうした地道な改善の積み重ねがプロダクトの信頼性と開発スピードを支える基盤になるのです。この経験を通じて、機能を「作る」だけでなく、「運用で支える」こともエンジニアの重要な役割だと改めて実感しました。

学んだこと

大規模プロダクト開発の難しさと面白さ

開発を進める中で最も実感したのは、大規模プロダクトでは通常より考慮すべきことがたくさんあるということでした。400万人以上のユーザーが利用するEightでは、ひとつの変更が別の機能やバッチ処理に影響を及ぼす可能性があります。当初は目の前のコードに集中しがちでしたが、多くのレビューを通じて「この変更が他の処理に与える影響を考慮しているか？」と問われることが増え、設計意図やデータフロー全体を意識して実装する習慣がつきました。こうした全体を俯瞰して設計する経験は、大規模プロダクトならではの学びだと思います。

ユーザーの体験を想像した開発

開発を通して、Sansanのカタチのひとつ「体験を想像する」をとても実感しています。上記で挙げた例だと、デジタル名刺メール送信機能では、ユーザーが名刺交換後どのように感じるかを想像しながら設計を進め、処理速度や安定性のバランスを細かく調整しました。このように、機能を実装するだけでなく、使う人の体験から逆算して設計する視点がプロダクト開発の根幹です。結局は使ってもらえる機能を作らないと意味がなく、本当の意味で「ユーザーが必要な機能は何か」と仕様を詰める段階から深く考えて開発していくことが良いプロダクトを継続的に作り続けるために欠かせない要素であると学びました。

プロダクトを支える運用改善

機能を開発して終わりではなく、その後の運用をいかに最適化するかが、プロダクト価値を長く維持する鍵だと言えます。不具合をその場で「対応」するだけでなく、再発しない仕組みを設計することこそエンジニアリングの本質だと捉えています。また、機能が増えるほど日々の運用コストも自然と積み上がっていきます。だからこそ、どれだけ低いコストで安定して運用できるかを意識することが重要です。運用コストの増大は、開発スピードや改善活動にも影響を及ぼすため、個人開発とは異なり、チームや組織全体の生産性に直結する要素だと実感しました。

今後の挑戦

Eightには、年次や職種に関わらず意見を出し合い、挑戦できる文化があります。そのため、新卒であっても手を挙げて積極的に行動すれば、さまざまなことにチャレンジできる環境です。実際にその文化に支えられながら、日々の開発を通して多くの経験を積み、成長を実感しています。

今後は、データを起点にプロダクトを進化させるエンジニアを目指していきます。ログやイベント設計を意識した「分析しやすいプロダクト設計」を推進し、データから仮説を立てて機能改善へとつなげていきたいと考えています。また、これまで蓄積されてきたデータをより有効に活用できるよう、自分の強みを生かしながらリードし、プロダクトのさらなる発展に貢献していきます。