「開発がボトルネックになっている」——そう感じるエンジニア組織は少なくない。しかし、Sansan株式会社のContract One Engineering Unitは、今や正反対の悩みを抱えている。かつてバックログに積み上がっていたタスクは枯渇し、チームは「次にやることが見つからないか」と問いかけられるフェーズに到達した。
いったい何が変わったのか。スピードを組織の中心に据え、1人1エピック制の導入、生成AIの徹底活用、そしてFindy Team+による定量的なメトリクス管理。複数の施策を組み合わせた結果、リリースノートの件数は14倍に膨らんだ。しかし、部長の大島武則氏とテックリードの高橋直也氏が見据えているのは、その先だ。
生成AIの時代、エンジニア組織はどこを目指すべきか。Contract Oneの挑戦は、その一つの答えを示している。
「止めない」組織をつくる——スピードへの信念はどこから来たのか
—— まず、Contract Oneというプロダクトについて教えてください。
大島： Contract Oneは、契約書をデータベース化して活用するためのプロダクトです。企業が締結する契約書には、期日・金額・条件など重要な情報が大量に含まれているにもかかわらず、多くの企業でその情報が活用しきれていない。Contract Oneはその情報を整理・構造化することで、契約データを経営判断や業務効率化に活かせるようにします。Sansanが名刺データを起点にビジネスの可能性を広げてきたように、Contract Oneは契約データを起点に、企業の新しい価値を生み出すことを目指しています。
—— お二人がいま、この仕事に向き合っている原点を教えてください。
大島： 自動運転の開発に携わっていた頃、機械学習でアルゴリズムを磨くよりも、データの質こそが結果を左右すると気づいたんです。良いデータがあれば良い機能になる。Contract Oneで契約書をデータベース化して活用するというミッションは、自分にとって一直線につながっています。
高橋： インターン時代に「品質はチームでカバーできる。それよりスピードを意識しろ」と言われて、意識がガラッと変わりました。価値提供が遅ければ、品質がどれだけ高くてもプロダクトは成長しない。その考え方が今も自分の軸です。
—— Contract One Engineering Unitという組織として、何を一番大事にしていますか。
大島： 明文化はしていないんですが、スピードです。プロダクトの成長のために開発を止めてはならない——これはチーム全員が共通して持っている意識だと思います。加えて、要望を受けて作るのではなく、自分たちで課題を捉えて開発を進める「真のプロダクト開発組織」を目指したい。その二つが根っこにあります。
高橋： 誰かに言われる前に「この課題、自分たちで拾いにいこう」という動きが普通になっている。それがこのチームの良さだと感じています。
数値で組織を動かす——リリース量2倍を求められた組織が選んだ答えとは
—— Contract Oneはいまどんなフェーズにありますか。
大島： 2023年リリースで、PMFからまだ2年という若いプロダクトです。市場開拓を進めるなかで「リリースの生産量を2倍にしてほしい」という要求が組織にかかってきていました。それを実現しなければプロダクトが成長しない。そのプレッシャーは相当なものでした。
—— 正直、当時の開発現場はどんな状態でしたか。
高橋： バックログがどんどん積み上がっていくのに、消化しきれない状態が続いていました。1チームに1プロジェクトという体制だったので、どこかで詰まると全体が止まってしまう。「早くしなければ」という焦りはあるのに、何が原因で遅いのかが数値として見えていなかった。それが一番しんどかったですね。
大島： 内製でメトリクスを集計しようとしていたんですが、詳細な数値が取れなかった。リリースノートの件数は増えているのはわかる。でも、どの施策がどれだけ効いているのかが見えない。感覚で判断するしかない状態で、意思決定に自信が持てなかった。
—— そこでFindy Team+を導入することになった。何が決め手でしたか。
大島： 意思決定を数値の上に乗せたかった、というのが正直なところです。内製では取れなかった詳細なメトリクスが取れて、すぐに使い始められる。それだけで十分な理由でした。開発リソースをメトリクス整備に使わずに済むというのも、スピードを重視する組織としては大きかったです。
高橋： 私はレビューリードタイムをずっと追いたかったんですが、内製では限界があって。Team+を使うとPRレビューの流れが細かく見えるようになりました。どこで止まっているのか、誰がボトルネックになっているのかが特定できるようになったのは、想像以上のインパクトでした。
—— 導入後、組織に一番大きな変化をもたらしたのは何でしたか。
高橋： 「同じ数値を見る」という体験が生まれたことだと思います。以前は設計ドキュメントのレビューが特定のメンバーで止まっても、それが問題として認識されにくかった。Team+で可視化されると、ボトルネックが一目でわかる。「ここが詰まっている」と数値で示せるようになってから、意思決定のスピードが明らかに変わりました。
—— Findy Team+のカスタマイズ性についても高く評価されていると伺いました。
高橋： チームモニタリングの設定には正直感動しましたね。私のチームはインターン生と正社員が混在しているので、それぞれの指標を別々に追いたいという場面があるんです。Findy Team+だとそういった単位でのモニタリングが柔軟に設定できて、用途に応じた使い方ができる。内製化を以前試みたことがあるので、それがどれだけ大変かはよくわかっていて。だからこそ、このカスタマイズ性のありがたさが身に染みています。
大島： 内製だとどうしても作るのに時間がかかって、それ自体がボトルネックになってしまう。Findy Team+はすぐに使い始められて、かつ細かい設定もできる。開発リソースをメトリクス整備に使わなくて済む分、プロダクト開発に集中できるというのは、組織としてもありがたいです。
—— 地道な改善の積み重ねで、結果はどう変わりましたか。
高橋： 泥臭いことの積み重ねです。レビューリードタイムを毎週確認して、止まっているところを地道に潰していく。それだけです。ただ、その結果としてバックログに積まれていたタスクがほぼ無くなるレベルまで消化できるようになった。今は「次にやることが見つからないか」と言われるくらいのフェーズになっています。
大島： リリースノートの件数は14倍まで変化しています。以前は開発がボトルネックでしたが、今は数値以上のインパクトが出ていると感じています。ただ、これはゴールではなくて、ここからが本番だと思っています。
生成AI×自動化——「完全自動化」を見据えたskills・rules設計の最前線
—— 生成AIの活用は、どのように始まったんですか。
高橋： 最初は「LLM week」という取り組みをやっていました。一定期間、チーム全員でLLMの活用方法を集中的に試してトラッキングしていくというものです。ただ正直なところ、最初はうまく使いこなせなかった。「便利そうだけど、どこに使えばいいか分からない」という状態が続いて、個人の温度差もかなりありました。
大島： 何でもAIに任せればいいという雰囲気になって、逆に質が落ちる場面もあって。「AIを使うこと」が目的になってしまっていたんですよね。そこで一度立ち止まって、「何のために使うのか」を整理し直した。その過程でskillsとrulesという考え方に行き着いたんです。
—— skills・rulesとは、具体的にどんなものですか。
高橋： rulesはAIへの「約束事」です。コードスタイルや設計方針など、チームとして守ってほしいことを定義する。skillsは「PRレビューの依頼文を書く」「テストコードを生成する」といった、繰り返し使う作業をAIに任せるためのテンプレートのようなものです。この二つを整備することで、個人の使い方のばらつきをなくして、チーム全体の実装力を底上げできる。
—— skills・rulesの整備に取り組み始めたきっかけは何でしたか。
高橋： AIを個人が好き勝手に使うと、アウトプットの品質がバラバラになってしまうんです。「あの人のコードはAIっぽい」「レビューが増えた」という声も出てきた。チームとしての実装品質を担保しながらスピードを上げるには、AIの使い方自体を標準化する必要があると気づきました。
大島： そこで出てきた課題が、「標準化できているかどうかを、どうやって確認するか」という問題です。skillsやrulesを整備しても、それが実際にスピードや品質の向上につながっているのかが数値で見えない。感覚で「良くなった気がする」では、組織として判断できない。
—— そこでFindy Team+が、また必要になってくる。
高橋： skills・rulesを整備してレビューリードタイムが縮まっているか、デプロイ頻度が上がっているかをTeam+で確認できるようになった。AIの活用が本当に効いているのかを数値で検証できるようになったのは大きかったです。施策の効果が見えないと、次に何を改善すべきかの判断もできないので。
大島： AIで生産性を上げようとしている組織ほど、メトリクスが必要だと思っています。AIの効果は一見わかりにくい。「なんとなく速くなった気がする」では組織を動かせない。Team+があることで、AI活用への投資が正しい方向に向かっているかどうかを判断できるようになりました。
髙橋： 数値で現状を把握して、AIで改善を実行する。この二つが揃って初めて、スピードの向上が持続的なものになる。どちらか一方だけでは限界があるので、組み合わせることに意味があると考えています。
—— skills・rulesの整備は今も続いているんですか。
高橋： 続いています。一回作ったら終わりではなくて、プロダクトが進化するにつれてアップデートし続ける必要がある。古いskillsをそのまま使い続けると、むしろ邪魔になることもある。Team+でメトリクスを見ながら「ここが遅くなってきた」と気づいたら、対応するskillsやrulesを見直す。このサイクルを回し続けることが、テックリードとしての一番重要な仕事になっています。
—— その延長線上に「完全自動化」がある。
大島： 目標達成には、人間が介在している工程を自動化していくしかない。E2Eで自動化されたオペレーションを構築して、エンジニアが本質的な判断だけに集中できるようにしたい。今まさにその仕組みを設計しているところです。
高橋： 完全自動化というと大げさに聞こえるかもしれませんが、要は「人間の判断が必要なところ以外は自動で流れるようにする」ということです。AIと自動化で工程を減らしながら、Team+で効果を確認する。このサイクルが回り続ける限り、スピードは上がり続けると思っています。
次のフロンティアは「課題発見」——エンジニアが営業戦略を動かす日
—— 開発ボトルネックが解消された先に、何が見えてきましたか。
大島： 次のフェーズとして取り組みたいのが、課題発見への踏み込みです。バックログが枯渇したことで、ようやくその余白が生まれてきた。これはゴールではなくて、スタートラインだと思っています。
高橋： GWにプロダクト開発の書籍を読み直したんですが、「入り方」が全然違って見えました。以前は開発がボトルネックで、そこに集中せざるを得なかった。でも今は、その先のフェーズの話として読めるようになった。このフェーズまで来られたのは、チームとして本当に良かったです。
—— これまで課題発見はPdMが担っていた。エンジニアが踏み込むことで、何が変わるんですか。
大島： 「何を作るか」の議論から関われるようになる。それがプロダクトの質と速度を同時に上げると思っています。同じチームとしてPdMと一緒に課題発見を進めることで、開発とディスカバリーの往復が減る。そのインパクトは、機能開発のスピードアップとは比べ物にならないくらい大きいはずです。
高橋： エンジニアが課題発見に入ると、技術的な実現可能性をその場で判断しながら議論できます。「これは作れる、これは難しい」というフィードバックをリアルタイムで返せるので、ディスカバリーの精度と速度が上がる。PdMとエンジニアの往復が減るだけで、全体のリードタイムはかなり縮まるはずです。
—— 具体的にどんな目標を描いていますか。
大島： 課題発見からリリースまでを、1か月以内に完結させることを目指しています。それが実現できると、営業戦略にまで強く影響できるようになる。「この機能があれば、この案件が取れる」というサイクルを1か月単位で回せるようになれば、プロダクトとして市場に提供できる価値のスピードが根本から変わります。
高橋： エンジニアが営業戦略に影響を与えられる、という状態は、以前は現実的に考えられていなかった。でも今はそれが射程に入ってきている。組織として一段階上のフェーズに来ているという実感があります。
—— 最後に、Contract Oneという組織の魅力と、一緒に働きたいエンジニア像を教えてください。
大島： AIの時代にエンジニアがどう価値を発揮するか、その一つの方向性を体現しようとしている組織だと思っています。Contract OneはSansanの次の柱として期待されているプロダクトで、今まさに伸びているフェーズにある。組織の進化とプロダクトの成長を同時に体験できる環境はなかなかないはずです。一緒に働きたいのは、壁を作らずにアウトカムにこだわれる人。技術だけでなく、プロダクトやビジネスにも広く興味を持って、とにかく成果を出しにいける人と働きたいです。
高橋： 動きが速くて、やりたいことが柔軟にできる組織です。「これをやってみたい」という意欲があれば、トライアンドエラーをどんどんできる文化があります。今後はビジネス側との協業もさらに増えていくので、技術とプロダクト、両方に興味を持って幅広く関われる人だと、より力を発揮できると思います。
※経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」のサービス詳細は、以下よりご覧いただけます
