Vol.10 立ち上げからリリースまで、「シュッと話す」文化で走り抜けたSDI開発チームの話

この記事は、Sansan Data Intelligence 開発Unit ブログリレーのVol.10です。

こんにちは、技術本部 Data Intelligence Engineering Unitのエンジニアの遠藤です。

これまでのブログリレーでは、技術選定やアーキテクチャなど、システムの設計や技術的な側面を中心にお伝えしてきました。今回は少し視点を変えて、技術ではなく「チーム」にフォーカスし、Sansan Data Intelligence（以下、SDI）の開発チームがどのように立ち上がり、約6カ月でリリースまで走り抜けたのかをお話しします。

チームの発足 — 2025年6月末

2025年6月末、SDIの開発チームが発足しました。メンバーは9名。うち2名はインターン生です。

チームに課せられたミッションは明確でした。「最速でリリースすること」です。

SDIは既存プロダクトであるSansan Data Hubと領域が近いプロダクトです（両者の関係についてはVol.02の記事で詳しく紹介しています）。しかし、Sansan Data Hubを経験しているメンバーは半数に満たず、ドメイン知識が十分とは言えない状態でのスタートでした。

ただ、これは悪いことばかりではありませんでした。「なぜこうなっているのか」という素朴な問いが、これまで当たり前だと思っていた設計や進め方を見直すきっかけになったからです。例えば、既存プロダクトで「運用でカバーしていた」部分について、「そもそもその運用が発生しない設計にできないか」という問いが上がり、仕組みそのものを見直す判断につながったことがありました。新しいチームだからこそ、ゼロから考え直せる強さがありました。

方向性を定める — 2025年7月

最初の1ヶ月は、技術スタックの決定や、既存のSansan Data Hubグループとの連携方針に時間を費やしました。どこまで共通化するか、どこを独自に作るか。議論は尽きませんでしたが、最終的に「Sansan Data Hubリニューアルプロジェクトの基盤を活用する」という意思決定をしたことで、方向性が定まりました。

この意思決定は、Vol.01やVol.02で紹介されている通り、バックエンドの技術スタックや共通ライブラリ、CI/CDフローをそのまま活用できることを意味します。おかげで、開発初日からビジネスロジックの実装に集中できる環境が整いました。

一方で、この時期に見えてきた課題もありました。SDIの開発では、既存のSansan Data HubグループやSOCv2（Sansan Organization Code v2）グループなど、複数のグループと連携する場面が多くありましたが、グループ間の動き出しが遅くなりがちだったのです。この課題は、後に説明する合宿を経てチームに「シュッと話して解決する」文化が根付くことで、少しずつ解消されていきました。

設計を深める — 2025年8〜9月

方向性が定まった後は、SDIの中身を作り込んでいく段階に入りました。ここでは大きく3つの取り組みが設計や実装の質を高めてくれました。

デザイナーとエンジニアの協業

SDIはデータの価値を届けるプロダクトです。ユーザーがその価値を受け取れるよう、画面設計には力を入れました。デザイナーが中心となりつつ、エンジニアも積極的に意見を出し合いながら進めていきました。

エンジニア側からも体験を想像し、提案することを心がけていました。「こういう操作をしたくなるのでは」「ここはエラーが起きやすそう」といった会話が、設計の質を高めてくれたと思います。

イベントストーミングによるドメインの探索

FigJamを使って、発生しうるイベントやシステムの振る舞いを洗い出すワークショップも行いました。イベントストーミングを参考にしつつ、ドメインエキスパートを交えた本来の形式ではなく、エンジニア間で実施しました。

AIを使い倒す

SDIの開発はフルスタックで取り組む必要がありました。フロントエンドの経験者は少なかったものの、やったことのない領域に踏み込むことを楽しめるチームでした。そこで助けになったのがAIです。

フロントエンドでは、Figma MCPを使ってデザイントークンの情報を取得したり、文言のチェックを行ったりしました。Next.jsの実装では、先にある程度知見のあるメンバーが書いたコードをベースに、AIが既存の書き方に沿ったコードを生成してくれました。

バックエンドでは、FigJamに書いた設計をもとに、ドメインの境界やデータ構造の設計についてAIと壁打ちしました。「この責務はどのドメインが持つべきか」「このロジックはどこに置くのが自然か」といった設計の議論や、「何を優先して何を諦めるか」というトレードオフの議論を、AIを相手に繰り返しながら設計を固めていきました。

AIを駆使することで、技術的な偏りを補いながら開発を進めることができました。実際に、フロントエンド未経験のメンバーがページを作れるようになったり、QAさんやデザイナーさんからのフィードバック修正を自分で対応できるようになりました。

合宿で一気に加速する — 2025年10月

10月、チームで3日間の合宿を行いました。

SDIはまず「取り込みデータ」と「企業データベース」という2つの主要機能を軸に開発を進めました。この合宿で、取り込みデータをCSVからインポートする機能を一気に作りきりました。設計の詰めから実装、結合テストまでを3日間で完了し、最終日には50万件の大量インポートも成功しました。

普段はリモートで作業することも多い中、同じ場所に集まって集中的に開発を進めたことで、チームの一体感が生まれたように思います。

チームの変化 — シュッと話して解決する

合宿あたりから、何かあったときに「シュッと話して解決する」という姿勢が自然と身についていきました。

レビューが溜まっていたら声をかけ、設計で迷ったらすぐに相談する。そうした小さな「シュッと話す」が積み重なることで、スピード感と話しやすさがチーム内に定着していきました。

この姿勢で、他グループとの連携にも取り組むようになりました。SDIチームではバーチャルオフィスツールのGatherを使っているのですが、チームの部屋を隣同士に配置するなど、気軽に話しかけられる環境を意識しました。その結果、先に触れたグループ間の連携の遅さも、だんだんと解消されていきました。

もともとチームは、変化に対してポジティブで、ガツガツやっていく姿勢が強いチームでした。9人がフラットに、それぞれがリードを取れる体制で、誰かが細かく指示を出すのではなく各自が動いていました。インターン生も含めて、全員がオーナーシップを持って開発に取り組んでおり、例えば、インターン生がQAさんやデザイナーさんとの会話をリードして進める場面も多く見られるようになりました。