営業AXサービス「Sansan」の機能開発では、プロダクトマネジャーとアーキテクトが、企画の要件を整理する段階から連携しています。
「本当に必要な開発なのか」「どうすればユーザーに早く価値を届けられるのか」。
さまざまな機能を持ち、ユーザーの多いSansanだからこそ考える必要がある問いです。
今回のインタビューでは、プロダクトマネジャーの杉原とアーキテクトの佐藤に、機能をユーザーへ届けるまでの連携や、Sansan開発ならではの面白さについて聞きました。
杉原 健太 / Kenta Sugihara Sansan事業部 プロダクト室2017年にSansan株式会社に入社。入社後はWebアプリケーションエンジニアとして、営業AXサービス「Sansan」の開発に従事。その後、チームリーダー、エンジニアリングマネジャーを経て、2019年から2026年現在までプロダクトマネジャーとして同サービスに携わっている。
佐藤 輝年 / Akitoshi Sato Sansan Engineering Unit Product Enhancementグループ2019年に新卒でSansanに入社。営業AXサービス「Sansan」の開発エンジニアとして機能開発、技術改善に携わる。その後開発プロジェクトのリード・開発チームリーダーを経験。2024年からはアーキテクトを担当し、主に機能開発プロジェクトを中心に、複数のプロジェクトの責任者として、要件定義・計画・設計・ステークホルダーマネジメントなどを担っている。
課題や要件を決めるところから、一緒に考える
──まず、それぞれの役割について教えてください。
杉原：営業AXサービス「Sansan」のプロダクトマネジャー（PdM）を担当しています。PdMは主に、新機能や既存機能の改善について、企画からリリースまでのプロジェクト管理、リリース後の評価などを担っています。
Sansanには2017年にWebアプリケーションエンジニアとして入社しました。2019年からPdMを兼務するようになり、2021年からはPdM専任になりました。入社してからずっとSansanに関わっています。
佐藤：私は2019年に新卒で入社し、Sansanの開発エンジニアを経験しました。徐々に担当する範囲が広がり、今はアーキテクトを担当しています。
Sansan開発におけるアーキテクトは、技術面だけでなく、プロジェクトの上流から幅広く関わります。
組織によっては、要件定義や計画などはPdMやPjM（プロジェクトマネジャー）が担い、アーキテクトは技術的な意思決定を中心に行う場合もあると思います。
一方で、Sansan開発では、PdMが「こういう課題を解決したい」「こういうものを作りたい」と考えた段階からアーキテクトもプロジェクトに入り、一緒に要件やスコープを整理し、どう実現するかを考えます。
その後は、プロジェクトの計画・進捗・品質・コスト・スケジュールまで責任を持ちます。技術的な意思決定だけでなく、PjMに近い役割も含めて、プロジェクト全体を見るイメージです。
──企画からリリースまでのプロセスについて教えてください。
杉原：大きく分けると、企画のアイデアにはトップダウンで生まれるものと、ボトムアップで生まれるものがあります。
トップダウンは、事業的な観点やプロダクトとして目指している方向から「こういうものが必要なんじゃないか」という仮説が出てきます。
ボトムアップでは、ユーザーからのフィードバックやコミュニティー、日々の相談の中での気づきから「ここを改善した方がいいんじゃないか」という話が出てきます。
企画を始めるとき、最初に行うのが「課題の特定」です。
「誰の、どんな課題を解決するのか」を考えるため、まず一人のユーザーを具体的にイメージします。どんな業務をしていて、どこで困っているのか。その上で、同じ課題を持つユーザーがどれくらいいるのかを調査しながら、解決すべきコアの部分を特定します。
課題が見えたら、次に「解決するために、システムとして、ビジネスとして何ができなければいけないのか」という要件を決めます。
このあたりからアーキテクトと一緒に、「課題をもう少し明確にできるのか」「考慮することは他にないか」「本当に全部必要なのか」とやりとりしながら要件を詰めていきます。
課題と要件がある程度明確になったら、開発着手の優先度を決定する会議（リファインメント）に出します。通過したらエンジニアをアサインして開発が始まります。
リリース後は利用状況などのデータを見ながら、想定した課題を解決できているのかを評価します。利用が伸びていれば次の施策につなげますし、伸びていなければその原因を考えます。
パフォーマンスも見ていて、ユーザーが実際に使う中で遅くなっている部分があれば、それをきっかけに改善に着手することもあります。
──PdMとアーキテクトは、かなり早い段階から一緒に考えているんですね。
佐藤：そうですね。課題や要件の検討からアーキテクトが入るのには理由があります。
PdMは、事業的な観点やユーザーの声などをもとに「何を作るべきか」を考えています。ただ、その実現方法や必要な工数は、システムの中身を知るエンジニアでなければ把握しきれません。
そこでアーキテクトが、既存機能への影響や開発スコープを見ながら、優先度を考えて、その時々に必要な要件を判断します。
そうやって、優先度と開発工数のバランスを見ながら、必要なタイミングに合わせて、リリースに含める範囲を考えます。
実際、プロジェクトによっては、アーキテクトが精査したことにより、開発期間が1/2〜1/3まで圧縮でき、リリースが早まるということもあります。
「何を作るか」だけでなく、「今は何を作らないか」も一緒に決める
──実際に、PdMとアーキテクトが一緒に進めたプロジェクトの例はありますか。
佐藤：今年リリースしたZoom名刺連携機能（※1）は分かりやすいかもしれません。
※1 Zoom名刺連携機能：オンライン会議の開催時に外部参加者用のURLを発行し、参加者に氏名や会社名などを入力してもらうことで、その情報をSansanの名刺データとして登録できる機能
当初は、より便利な体験を実現するために、さまざまな要件を盛り込んでいました。
例えば、一般的なオンライン会議アプリにあるような、Googleカレンダーで予定を作成するだけで、自動的にフォームが作成され、予定に添付されるといった機能です。
ただ、最初からすべてを実現しようとすると、顧客体験は良くなる一方で、開発工数が増え、リリースまでの時間も長くなります。そこで、「顧客の課題を解決するために、本当に最初のリリースから必要なものは何か」を考え、要件を絞っていきました。
また、PdMから受け取った要件の中では検討しきれていなかった既存機能への影響についても、アーキテクト側で精査していきました。
Zoom名刺連携は名刺を作成する機能ですが、Sansanでは名刺を起点にさまざまな機能が利用できます。
例えば、登録した名刺に記載のメールアドレス宛にまとめてメールを送れる「メール一括配信機能」や名刺交換後の接点情報を名刺にひも付けて記録できる「コンタクト機能」などです。
これらの機能には、名刺の登録方法によって利用可否が変わるものがあります。例えば、名刺交換をした相手に翌朝メールを自動配信する「デジタル名刺メール機能」は実際の名刺交換が対象となるため、ユーザーがCSVファイルから登録する「名刺インポート機能」の名刺は対象外です。
そのため、新しい名刺の登録経路を追加するだけでも、既存機能の実装やテストに影響します。どこまで対応するかによって工数が大きく変わるため、既存機能への影響を見ながらスコープを決めました。
結果として、当初考えていたものをすべて実現すると半年以上かかる見込みでしたが、初回リリースに必要な範囲に絞ることで、大幅に期間を短縮できました。
──杉原さんはもともとエンジニアでしたが、その経験は今のPdMの仕事にどんな影響がありますか。
杉原：Sansanに入社しエンジニアとして働いて一番感じたのは、大規模なシステムでは「普通にものを作って動かすこと自体が難しい」ということでした。
「一つ変えるだけ」に見えても、他の仕様と整合性が取れなくなったり、パフォーマンスが悪化したりすることがあるからです。実際にたくさん経験してきたので、裏側の大変さはとてもよく分かります。
その上で、ユーザーに価値を届けるスピードも重要だと思っています。エンジニアから「削りたい機能がある」と言われたら、その場面において本当に必要なのかを判断し、絶対に必要なら削らず、「あればいいかも」くらいなら、削って早く届けることを選びます。
そういう感覚は、自分で作って、自分で経験したことがあるからこそ、今のPdMの仕事にもかなり生きていると思います。
──PdMとアーキテクトが一緒に判断するとき、共通して大事にしていることはありますか。
佐藤：「このプロジェクトで解決すべき課題は何か」、そしてその解決策を最速で顧客に提供するために「最低限必要な要件は何か」を考えることですね。
これは私個人だけでなく、Sansanの開発全体で大事にしている考え方です。プロジェクトを担当するアーキテクトは、開発内の上流レビューでも、課題や要件について「なぜ必要なのか」「要件は最適か」を他のアーキテクトと議論します。
課題と要件を深掘りし、本当に必要なものを見極めた上で開発に入るのようにしています。
杉原：私がSansan開発ですごくいいなと思っているのは、最後は「ユーザーを主語」にして会話できることです。
営業もカスタマーサクセスもマーケティングもエンジニアも、それぞれの立場から「こうしたい」という話は出てきます。その中で、最終的にユーザーにとって何が必要なのかを基準に、優先するものを考えていきます。
開発側から技術改善の必要性を説明するときも、「技術的負債があるから」だけでは終わらせないんです。例えば、ライブラリを適切に更新しなければ将来的にセキュリティーアップデートに対応できなくなる可能性があるのであれば、ユーザーのセキュリティーを守るために必要な対応であることをしっかりと説明します。
そこまで踏み込んでPdMとエンジニアで話せるのは良いところだと思っています。
──最近リリースした「AIサーチ」の開発では、Sansan開発だけで完結させず、他の開発組織とも連携したそうですね。どのように進めたのでしょうか。
杉原：Sansanというと名刺管理のイメージが強いかもしれませんが、今はオンライン会議との連携やAIサーチ（※2）のように、営業活動を支える機能の幅も広がっています。
※2 AIサーチ：Sansanに蓄積された名刺情報や商談履歴に加え、企業情報やWeb上の公開情報などをAIが横断的に参照し、商談相手の情報収集や提案準備をサポートする機能
jp.corp-sansan.com
佐藤：Sansanの機能は、既存機能との連携が必要なものが多く、影響する範囲も広いため、既存の仕組みをよく理解しているSansan Engineering Unit（Sansan EU）で、開発から運用まで担っています。
ただ、Sansan EUのエンジニアだけでは人数も限られますし、すべての開発を担うのは難しいので、他の開発組織との連携を考える必要がありました。
AIサーチは、他の開発組織と役割を分担しやすい機能でした。
AIへのインプットとして必要な名刺情報を連携できれば、既存機能との複雑な連携をあまり意識せずに、独立した機能として成立します。
Sansanには、CTO室が開発・運用している「Sansan Labs」という実験的な機能があり、すでに名刺情報を連携したAI機能の開発実績がありました。そこで、AIサーチのメイン機能はCTO室に担ってもらい、Sansan EUは必要なデータを提供する仕組みと、Sansanの画面からAIサーチにつなぐ導線の開発を担当しました。
このように役割を切り分けることで、より早くユーザーに届けられる形にしました。
杉原：Sansanがこれまで積み重ねてきた仕様を全部そのまま持ち込んで作ろうとすると、時間がかかります。その中で「どこをどの組織が開発するか」を佐藤さんが中心になって整理してくれたことで、早くリリースできたと思っています。
それに、今後もAIを使った機能を作っていくことを考えると、今回だけ早くリリースできれば良いわけではありません。既存の仕組みを毎回すべて理解しなくても、AI側から扱いやすい形でデータを使えるようにしていく。
今回の開発では、その後にもつながる形を考えながら作っています。
多くのユーザーに使われるSansanだからこそ、考え続ける
── 多くのユーザーに長く使われ続けているSansanだからこその、技術的な難しさや面白さはありますか。
杉原：難しさでいうと、今使ってくれているユーザーがたくさんいる中で、システムを変え続けなければいけないことが一番大きいと思います。
SansanはBtoBのサービスで、ユーザーの業務の中に組み込まれています。だから、機能を一つ変えるだけでも、既存の業務に与える影響が大きい。新しくゼロから作るのとは違って、とにかく作って試すというわけにはいきません。
今使っているユーザーへの影響を見ながら、今ある機能をきちんと動かし続けつつ、新しいものも早く届ける。その両方を同時に考える必要があります。
そうした難しさに向き合いながら、20年近く使われ続けているシステムを作っています。これだけ長く続いて、今も変わり続けているシステムだからこそ、どの判断がどんな負債を生み、成長の中でどんな問題が起きるのかを体感でき、それを防ぐための知見も得られます。
その知見を生かして多くのユーザーに価値を届けられる、そんなシステムに携われる機会はなかなかないと思っています。
それを生で感じながらプロダクトを作れるのは、面白いですね。
佐藤：既存機能への影響を考えながら新しいものを作る難しさはあります。それに加えて、Sansanならではなのが、パフォーマンス面の難しさです。
Sansanはユーザー数やデータ量も多いうえに、会社や人物など、特定の単位でさまざまな情報を集約して表示する機能がたくさんあります。
例えば、ある企業について、自社の各部署の誰がどの担当者と接点を持っているのかを、全社に蓄積された名刺やコンタクトの履歴を横断して集計し、表示するといったものです。
さらに、Sansanには「アクセス権限設定」があり、ユーザーや部署ごとに、名刺情報へのアクセス範囲を細かく設定できます。そのため、ユーザーによって閲覧できる情報の範囲が異なり、集計結果をそのまま使い回すようなキャッシュの仕組みも取りづらいです。
情報を集約して見せる機能が多く、そこにアクセス権限の制御が絡み、さらにデータ量も多い。この3つが重なる中で、必要なパフォーマンスを出していくことが難しいポイントです。
一方で、こうした難しさに挑戦できること自体が、面白さでもあると思っています。
──最後に、これからSansanで実現していきたいことを教えてください。
杉原：Sansanには「それ、早く言ってよ〜」というTVCMがあるんですが、私はあの世界観を実現することが、Sansanというプロダクトの根幹にあると思っています。
名刺をスキャンするだけで情報がたまって、それを使える。このシンプルさはSansanの魅力なので、もっと磨いていきたいです。
今はAIによって、これまで技術的な制約などで難しかったこともできるようになってきています。AIもうまく組み合わせながら、「それ、早く言ってよ〜」がなくなるようなプロダクトの世界観を、もっと実現していきたいですね。
そのためには、新しい機能を作ることも、裏側の仕組みを改善することも必要です。ユーザーに早く価値を届けるためにできることは、全部やっていきたいと思っています。
佐藤：引き続き「解決すべき課題を、できるだけ早く解決すること」を大切にして、ユーザーに価値を届けていきたいです。
「開発スピードを上げる」「スコープを調整する」「開発組織を分ける」など、手段はいろいろあります。
突き詰めれば、「そもそも開発をしなくても解決できるのではないか？」と、開発すること自体を疑うことも含めて、一番早く課題を解決できる届け方を今後も考えていきたいです。
Sansanでは一緒に働く仲間を募集しています！
Sansanでの働き方や仕事の魅力などについて、実際に働くメンバーがお話しします。興味を持っていただいた方は、ぜひカジュアル面談にお申し込みください！
