3つの⽴場で考える 技術的負債への組織的アプローチ VPoE / VPoP ⻄場 正浩 Sansan技術本部 1

⁃ 実際にできているものもあれば、まだまだ試⾏錯誤中のものも多い。 ⁃ Sansanには複数の開発組織があり、それぞれ課題が違う。 ⁃ 「事業部の結びつきが強い組織」や「事業部を横断的に⽀援する組織」などがある。 ⁃ 各開発組織のフェーズや規模は異なる。 ⁃ 今⽇話すことは⼀般に成り⽴つ話ではなくコンテキスト次第である。 ⁃ 断⽚的な議論の例：これは良いコードか？ > 「状況による」としか⾔えない。 > バグがあっても稼いでいるコードはある意味では良い。 > テストがなくても障害がないコードはある意味では良い。 今⽇話すことの前提 2

コンテキストのためにSansanの概要を紹介する 3

⁃ VPoE／VPoP／CPO補佐、 プロダクト開発に主に責任がある。 ⁃ 開発者体験はユーザー体験と同等に重要である。 ⁃ 開発者体験が個⼈の⽣産性向上に⼤きく寄与する。 ⁃ 私が多くのことを考えても開発者体験の向上は難しい。 ⁃ そのためにボトムアップの組織を作りたい。 ⁃ トップダウンでボトムアップにする。 ⁃ ”Disagree and Commit”でやっていきましょう。 ⁃ 常に仮説を持ちながら新しい情報を探索し ⾃分の考えをアップデートしていきたい。 ※ VPoE／VPoPについては別途話したい。 ⾃⼰紹介：⻄場 正浩 4

⁃ 東証プライム市場上場 ⁃ 社員数は1,421 名（2023年8⽉31⽇時点） ⁃ 「この機能を1⽇でも早くリリースしないと潰れる」という プレッシャーは少ない（少ないだけである）。 ⁃ 新規のプロダクトをいくつも⽴ち上げており、そのいくつ かはすでに廃⽌している。 ⁃ 経営判断が速いのでプレッシャーがある。 ⁃ 今⽇は、特にSansan(プロダクト)に対する技術的負債の話 である。 ⁃ このプロダクトは創業当初から開発し続けており、ビジネ スも拡⼤し続けている。 会社紹介：Sansan株式会社 5

⁃ 2007年の創業時から開発し続けている。 ⁃ 順調に成⻑し、8,000社以上の企業で使われている。 ⁃ 解約率は0.49%と⾮常に低い。 ※23年5⽉期第２四半期 ⁃ SaaSのプロダクトにとってカスタマーサクセスが最も重 要なことの1つである。 ⁃ 名刺管理からスタートし、今では「営業を強くするデータ ベース」として様々なデータの蓄積し、それらの有効活⽤ を提案している。 ⁃ 実際に社内で徹底的に活⽤されており、Bill Oneの急激な 成⻑の１つの要因になっている。 ⁃ Bill OneはT2D3を⼤きく上回るスピードで成⻑している。 ※T2D3：SaaSのスタートアップの成⻑速度を測る指標 プロダクト紹介：Sansan(営業を強くするデータベース) 6

⁃ Sansan(プロダクト)の開発を担う組織。 ⁃ エンジニアが50名、PdMが10名、デザイナーが10名ほどいる。 ⁃ 間接的に関わっているエンジニアを含めると100名近くになる。 ⁃ Webアプリケーションはモノリスで開発されている。 ⁃ 社内外のサービスに依存している部分も多い。それらは別システムになっている。 ⁃ 名刺やメール等のデータ化 ⁃ 企業データや名寄せ ⁃ Sansan Labs ⁃ モノリスのメリットを活かしつつ俊敏さ(アジリティ)を上げる。 ⁃ ステップを刻んでユーザーにリリースできない／それをしない⽅がいい開発も存在する。 ⁃ Product Enhancement Group・・・プロジェクト単位で中⻑期的に開発する。 ⁃ Product Reliability Group・・・チーム単位でアジャイル的に開発する。 ⁃ プロジェクトの規模感やメンバー状況次第でメンバーが⾏き来する。 ※ プロダクトマネジメントと連携しかなり⼯夫している。どこかで話したい。 開発組織紹介：Sansan Engineering Unit 7

3つの⽴場で考える 技術的負債への組織的アプローチ 8

⁃ 今⽇話す内容は具体的なエンジニアリングではなく、経営やマネジメントの観 点でもある。 ⁃ エンジニアによるシステムの改善活動に感謝しているし、それらは⾼い評価に 値すると考えている。 ⁃ その上でエンジニアリングではない観点で、いわゆる技術的負債の話をする。 ⁃ また⼀般論ではなく私たちが今抱えている課題にどう取り組んでいるか？とい う個別ケースの話である。 ⁃ エンジニアリング的なアプローチは他の登壇者の発表や書籍などが参考にする と良い。 技術的負債に対する組織的な取り組みについて話す 9

⁃ 私たちがしていることは、 プロダクトを通して顧客課題を解決することである。 ⁃ システム開発はその1つの要素であり全てではない。 ⁃ Sansanはプロダクトが中⼼にある。 ⁃ プロダクトアウトを⾏っているということではない。 ⁃ 顧客の課題を解決するために様々な⽴場や役割の⼈たちが プロダクトに関わっている組織である。 ⁃ 社内の誰もがプロダクトに関わっている。 ⁃ 議論の場もオープンである。 > プロダクトビジョンに関するワークショップ > プロダクトの顧客価値に関する議論の場 ⁃ 技術的負債をどの領域で捉えるかでアプローチが異なる。 ⁃ 狙っている市場／顧客の課題解決 ／プロダクト開発／システム開発 ⁃ 技術的負債はすべての領域に包含されている。 私たちはプロダクトを通して顧客課題を解決する 10 狙っている市場 技術的負債 顧客の課題解決 プロダクト開発 システム開発

⁃ 本質的に対⽴構造ではない。 ⁃ 技術的負債によってネガティブなことが引き起こされる。 ⁃ 開発速度が低下する／障害が増える／保守運⽤⼯数が増える／機能の拡張性が悪化する ⁃ これにより開発組織への影響がある。 ⁃ チームの⼠気が下がる／⼈が辞める／採⽤しづらくなる。 ⁃ 連鎖的にプロダクトにも影響がでる。 ⁃ 進化が遅くなる／競合に負ける／UXが悪化する／UXを妥協する／PdMの⼠気が下がる ⁃ 顧客やビジネスへもネガティブに影響する。 ⁃ 利⽤中にストレスを感じる／解約が増える／求められている機能が作れずに受注できない／ 営業部やカスタマーサクセス部の⼈たちの⼠気が下がる。 ⁃ 結果、売上が下がる。 ⁃ つまり、技術的負債はシステムの課題だけでなく、プロダクト、ビジネス・経営の課題である。 システムの課題は、プロダクトの課題であり、ビジネス課題である 11

⁃ 各領域で意思決定者がいる。 ⁃ 経営／事業責任者 ⁃ プロダクト責任者 ⁃ システム開発責任者 ⁃ 技術的負債をシステムの課題とせず、プロダクトや経営の課題という共通認識を持つ。 ⁃ 私は執⾏役員として経営陣であり、Sansan事業部のVPoPであり、VPoEでもある。 ⁃ すべてを私が決められるわけではないが、各領域に影響⼒と権限がある。 ⁃ これにより技術的負債関連における意思決定者のコミュニケーションの難しさやエンジニア の評価の難しさが軽減される。 ⁃ 結果「ステークホルダーを説得する」といった⾏為が極限まで少ない。 ⁃ それでも共通認識を作るために⾔語化や議論が必要である。 技術的負債の解決のために様々な⼈たちが協⼒する必要がある 12

⁃ まずは、中⼼にあるプロダクトに対して全員が共通認識を持てるようにする。 ⁃ プロダクトビジョンを明確にする。プロダクトロードマップを作成する。 ⁃ 新しい何か壮⼤なものを考える必要はなく、すでにみんなが思っている／考えているものを ⾔語化していくことが⼤切である。 ⁃ プロダクトビジョン ⁃ 超⻑期的であり、⼈間中⼼に考える。ユーザー価値にフォーカスしたものとする。 ⁃ 更新頻度は低い。場合によっては経営判断が必要である。 ⁃ プロダクトロードマップ ⁃ １〜３年後に実現したいユーザ価値を具体化する。それを可能にするUI/UXも設計する。 ⁃ 更新頻度は⾼く、ユーザーにヒアリングしながら本当に作るべきかの判断を都度⾏いながら改善し ていく。 ⁃ 技術的負債になりうる各機能を、プロダクトの⽅向性と利⽤状況で分類する。 ⁃ 分類することで議論の前提を揃えることができる。 共通のゴールを⽬指すから課題も共通化される 13

⁃ 技術的負債を各カテゴリーに分類し、それらの対応⽅法を検討する。 ⁃ これらの分類に対し関係者全体で共通認識を持つ必要がある。 ⁃ 共通認識を持たない場合「断⽚的な議論」に陥り、対⽴構造になりやすい。 ⁃ 経営陣／プロダクト責任者／システム責任者の関わりは濃淡がある。 プロダクトが⽬指すべきゴールと現状から課題を分類する 14 主にプロダクト責任者 - 優先度が低い場合は削除する。 - 優先度が⾼い場合は投資しUX⾃体を ⼤幅にアップデートする。 主にシステム責任者 - 基本的に機能ごと削除する。 主に経営陣 - ⼀番対応が難しい。 - 「後発のスタートアップだったら、 このUXをデザインするか？」を考える。 主にプロダクト責任者 - プロダクトの⽅向性を再検討する。 - 「ユーザーがなぜこれを使うのか？」を 徹底的に調査する。 利 ⽤ 数 が 少 な い 利 ⽤ 数 が 多 い プロダクトの⽅向性と⼀致する プロダクトの⽅向性と⼀致しない 3 1 2 4

⁃ 意思決定としてはもっとも簡単である。 ⁃ 削除をする。 ⁃ そのために廃⽌プロセスを作る。 ⁃ 「廃⽌することでプロダクト開発が加速する」ことを営業等に伝えておくことが⼤ 事である。 ⁃ 「どうやったら消せるか？」をエンジニアやプロダクトマネジャー以外も考える状 況を作る。 ⁃ 「エンジニア→PdM→VPoP→営業部部⻑→事業責任者」という流れで廃⽌の承認を進 める。 ⁃ 「プロダクトの⽅向性と不⼀致であり、利⽤数が少ない」という前提が成り⽴っている 場合、論点は殆ど出ない。 ①プロダクトの⽅向性と不⼀致であり、利⽤数が少ない 15

⁃ まずはどのようなユーザーがどのように何のために使っているかを調査する。 ⁃ 機能ではなく課題に注⽬する。その課題⾃体がプロダクトとして解決すべきものなのかを再 検討する。 ⁃ これらの検討を通じて顧客や市場への理解が深まるので、プロダクトのビジョンやロードマ ップのアップデートも検討する。 ⁃ プロダクトとして解決すべき課題であれば解決策を再設計する。 ⁃ 既存の機能はプロダクトの⽅向性と⼀致していない。 ⁃ 既存の機能をベースとせずにゼロベースで解決策を再設計する必要がある。 ⁃ ターゲットのユーザーを限定することで「実は成り⽴つ」ということもある。 ⁃ プロダクトとして解決すべき課題でなければ機能削除を検討する。ユーザーがいても消すこ との判断が必要である。 ⁃ 経営陣の判断が必要になることもある。 ②プロダクトの⽅向性と不⼀致であるが、利⽤数が多い 16

⁃ プロダクトとして優先度を判断する。 ⁃ 優先度が低い場合は、⼀旦消すことを検討する。 ⁃ 優先度が⾼い場合は、ユーザーにとって価値のあるレベルにするために⽅針を検討する。 ⁃ 既存の機能の延⻑で磨き込むか ⁃ ゼロベースでUXをデザインするか ⁃ 他と同様に顧客の課題に注⽬し徹底的に調査する。 ⁃ ⼤幅なアップデートが必要である。 ⁃ 少なとも現状の機能では利⽤されていない。 ⁃ それだけの投資をできない場合、消す決断をする。 ⁃ プロダクト責任者だけでなく、場合によっては経営判断になる。 ③プロダクトの⽅向性と⼀致するが、利⽤数が少ない 17

⁃ これが⼀番むずかしい。基本的には消せない。 ⁃ ユーザー価値のアップデートがない中で⼤きな技術的な改善の投資は難しい。 ⁃ ビジネス観点ではなく、プロジェクトとして難易度が⾼い。 ⁃ そこで「⾃分がこの領域で起業するならどのような設計にするか」ということを考える。 ⁃ 後発企業が既存のプロダクトより良いUI/UXを実現したプロダクトを出すことはよくある。 ⁃ システムの制約などを考えずにゼロベースで顧客課題の解決に取り組む。 ⁃ 同時にデータモデルの変更なども考える。市場は常に変化しており、プロダクトも変化して いる。さらに当初のマーケット以外にも領域を伸ばしている。 ⁃ 開発当初になかった技術や設計⼿法を取り⼊れるチャンスにもなる。 ⁃ ゼロベースで既存の体験を⼤きく上回る設計を考え、経営陣も⼊れて投資するか判断する。 ※ もちろん⽇々の技術的な改善活動も⼤切である。 ④プロダクトの⽅向性と⼀致し、利⽤数が多い 18

⁃ 全員が「顧客課題を解決する」ことにフォーカスする。 ⁃ その前提のもと技術的負債によって引き起こる様々な阻害要因を各々の⽴場で理解 する。 ⁃ プロダクトの⽅向性に対して全員が共通認識を持つ。 ⁃ それにより技術的負債を分類することができ議論のベースができる。 ⁃ 個別のケースに対して各々の⽴場で対応⽅法を検討し最も良い⽴場で対応する。 ⁃ これらの質を⾼めるために顧客理解を深め続ける必要がある。 ビジョンを明確にし、顧客理解を深め、様々な⽴場で取り組む 19

組織的に取り組むためのマインドセット 20

⁃ 市場を牽引しプロダクトが強い会社において失敗は避けられない。 ⁃ 失敗する可能性があるような⼤きなチャレンジをしているからこそ市場を牽引できる。 ⁃ SansanのValuesの1つでもある「Lead the Customer」を実践し、まだないものを作る。 ⁃ みんなが当然だと思って受け⼊れてしまっている課題を⾼いレベルで解決し続ける。 ⁃ それをプロダクト開発だけでなく、マーケティング等も含めたすべての領域で⾏う。 ⁃ だからこそ失敗は避けられない。 不要になるものを作ってしまうことは避けられれない 21

⁃ ハイレベルなエンジニアやプロダクトマネジャーを採⽤することや育成することも技術的負債に取り組 む上で効果的である。 ⁃ 根本的な課題を解決する。開発リードタイムと技術的負債の取り組みがトレードオフにならない⼈もい る。 ⁃ 「それは本当に問題なのか？もし⾃分にもっと技術⼒／スキルがあれば問題にならないのではない か？」ということを⾃問⾃答している。 ⁃ 問題は⼤きいかもしれないが、多くの場合実⼒次第でどうにでもなる。 ⁃ ex. 打席に⽴ったのが、⼤⾕翔平なのか？ ⁃ もちろん技術⼒はすぐには上がらないので、短期的には他の⽅法で解決策を考えないといけない。 ⁃ ハイレベルなプロダクトマネジャーがいたらエンジニアリングが楽しくなるし、ハイレベルなエンジニ アがいたらプロダクトマネジメントが楽しくなる。 ⁃ だからこそ育成・評価・採⽤に⼒を⼊れないといけない。 （これらは同時にアプローチしたほうが効果が⼤きい。※ 別の機会に話したい。） 抱えている課題を難しいと感じないほどスキルを上げていく 22

⁃ 前述の通り、失敗は避けられない。 ⁃ 失敗の後処理のコストを最⼩化し続けることで、組織として失敗を恐れ る要因がなくなる。 ⁃ 経営・プロダクト・システムの観点で技術的負債に取り組むことで、⼤ きなチャレンジをし続ける⾵⼟が⽣まれる。 ⁃ だからこそ当たり前のように技術的負債に全員で取り組む。 ⁃ Sansanの「変化を恐れず、挑戦していく」⽂化は、様々な観点で様々な ⽴場の⼈たちが連携して築いていく。 ⼤きなことに挑戦し続ける⾵⼟を私たちが作る 23

コラム 24

⁃ 社員数が急速に増えている。2023年8⽉時点で1,400名。私が⼊社した2年前と⽐べて数百⼈ 増えている。 ⁃ ビジネスも急速に伸びている。30％成⻑を実現する。 ⁃ Sansan株式会社 統合報告書2023 ⁃ 組織もビジネスも拡⼤していく中で、それに対応するために組織体制の改⾰も起きている。 ⁃ 何もしないと⼀体感が失われていく。 ⁃ 私たちはValuesの「強みを活かし、結集する」を実践していきたい。 ⁃ 今⽇話したように様々な⽴場や役割の⼈が「顧客の課題を解決する」ことにフォーカスし、 ビジネス／プロダクト／システムの課題を解決し続けたい。 ⁃ そこで「社内ネットワーキング」に会社として投資している。 ⁃ あるリサーチで「拡⼤していく組織の官僚組織化を防ぐ唯⼀の⽅法はキーマン同⼠のつなが りの強さ」という調査結果があった。 ⁃ そのため社内ネットワーキングを強化するための施策を多く⾏っている。 なぜ急激に⼤きくなる組織にも関わらず⼀体感があるのか？ 25

⁃ 現場のマネジャーが必要だと判断して担当する現場⽤に作るケースはあ るが、私は社内評価のための評価軸を作っていない。 ⁃ Sansanで活躍している⼈の特徴は無限にある。 ⁃ 評価がある⼀定以上になると「成果＝会社にとってプラスのインパク ト」であり、その成果の具体の定義は各個⼈が提案したらいい。 ⁃ 多様性があるからこそ、イノベーションが加速する。 ⁃ このスライドの最後にもメンバー紹介を載せているので⾒てほしい。 多様性のある組織を作りたいからVPoEとして評価軸を作らない 26

⁃ 今回の「技術的負債」の話にも関連するが、継続して挑戦し続けることは難し い。 ⁃ 挑戦し続けることを阻害する要因は多くある。 ⁃ 挑戦すべきことを⾒つけられない。 ⁃ 挑戦する体⼒／気⼒が失われていく。 ⁃ 過去の挑戦の後処理で余裕がなくなる。 ⁃ 過去の成功が⾜枷になる。 ⁃ … ⁃ これらの多くの阻害要因をシステム思考で分析し、継続的に好循環が回るよう に組織を作っていく必要がある。 ⁃ 組織が⼤きくプロダクトが増えていく中で仕組みを作ることは難しいが、仕組 みを作ること⾃体にも挑戦し続けていく。 「挑戦する」と「挑戦し続ける」は⼤きく異なる 27

⁃ 多くの場合は事象であって課題ではない。課題になるためには諸々設計が必要である。 ⁃ 例えば、私は体重が80kgオーバーである、は事象である。 ⁃ そこに「かっこよくなりたい」という願望があって、さらに細い⼈のほうがかっこいい、と いう価値感があって、初めて80kgオーバーが課題になる。 ⁃ ⼀⽅で「昨年買ったスーツが⼊らない」というのであれば「痩せる」という⽅向以外に「新 しいスーツを買う」ということもできる。 ⁃ ただ「お⾦がないから買えない」のであれば、本質的な課題は「お⾦がない」ことかもしれ ない。 ⁃ それを「痩せる」という迂回策を講じている可能性がある。 ⁃ 課題が明確ではない中で、⼿段（ダイエット⽅法）を議論しても意味はない。 ⁃ 課題を明確にするためには、そもそもの⽬標を明確にする必要がある。 ⁃ ⽬標があって初めて事象は課題になる、課題が明確になって初めて⼿段の議論が意味を持つ。 ⼿段ではなく課題について議論する 28

⁃ 巨⼈の肩に乗ることは、過去の知識や経験から学び、それを利⽤してさらなる⾼みに達 することの⽐喩である。 ⁃ ソフトウエアの開発では、みんなは当然のようにこれらを⾏っていると思う。 ⁃ それを組織マネジメント等においてもやっていきたい。 ⁃ 私はVPoE／VPoPを担っており、組織マネジメント／プロダクトマネジメントの観点の 書籍を社内外で紹介している。 ⁃ 概念に対して前提知識や共通認識を持つことで、議論の質を⾼まることができる。 ⁃ さらに私が独⾃の⽅法ではなく書籍等をベースに⾏うことで、書籍を読んでいる同僚の 「戦術理解度」が上がる。 ⁃ つまり、書籍をベースにすると、個⼈の仕事の質が上がり、議論の質が上がり、組織全 体の質も上がる。 ※ Sansanでは、書籍購⼊補助／Minerva／EVeM／Udemy Business(準備中)など巨⼈の肩に乗るための ⽀援に⼒を⼊れている。 みんなで「巨⼈の肩に乗る」 29

メンバー 30

笹川 裕⼈ 技術本部 Sansan Engineering Unit 副部⻑ ⁃ コンピュータ・サイエンスで博⼠を取得。 ⁃ 新卒でリクルートに⼊社。⼤規模データ基盤の開発、データ 分析（ABテスト設計など）、データ基盤のクラウド化に従 事。 ⁃ エムスリーにSWEとして転職。⾃らも⼿を動かしながら、 AI/ML、SRE、QA、グローバルチームなどのマネジメント を担当。 ⁃ 2023年4⽉より現職 31

⼤⻄ 真央 Order One 事業責任者 ⁃ SEとしてキャリアをスタートし、前職ではスクラムマスタ ーを含むアジャイルな開発を推進。 ⁃ 2016/1にSansanに⼊社し、Sansanプロダクトの開発及び関 ⻄開発拠点の⽴ち上げを担当。 ⁃ 新規事業を⽴ち上げるエンジニアリング組織を⽴ち上げ後、 プロダクトマネージャー及び開発責任者としてBill Oneの⽴ ち上げ及びグロースを担当。 ⁃ 現在は、第三の事業の柱を作るべく、Order Oneの事業責任 者にチャレンジ中。 32

⼤島 武徳 技術本部 研究開発部 副部⻑ ⁃ ゲーム機本体の組み込みソフトウェア開発者としてキャリア スタート。動画ライブラリやストリーミングシステム、パフ ォーマンス・チューニング、アプリ開発などを⾏う ⁃ ⾃動⾞メーカーに転職。クラウドでの開発にswitchし、⾃動 運転向けのAI学習環境開発やdata pipeline開発を⾏う ⁃ このときにWaterfallからAgileへのswitchも経験する ⁃ その後、情報サービス系企業にてデータ基盤開発やデータガ バナンスの整理などを⾏う ⁃ 2023年4⽉より現職。データ利活⽤推進及び新規データプロ ダクト開発の⽀援を⾏っている 33

三浦 俊介 技術本部 コーポレートシステム部 部⻑ ⁃ ⾳楽⼤学、芸術⾳楽の作曲学科卒 ⁃ 広告業界で⼤⼿企業のWEBプロモーション案件のWEBプロ デューサー／ディレクターを担当 ⁃ 楽天（株）にて電⼦書籍/本ジャンルの新規サービス開発や サービスグロースのPjM、UIUXデザイナーを担当 ⁃ （株）JCBにてデジタルマーケティングの企画制作を担当 ⁃ コインチェック（株）にてUX部⻑／社⻑室⻑／システム企 画などを担当 ⁃ 2022年1⽉より現職 34

柴野 亮 Bill One事業部 VPoP / 公認会計⼠ ⁃ 公認会計⼠試験に合格後、監査法⼈に⼊社 ⁃ 2014年にSansan株式会社へ⼊社し、財務・経理担当として 経理実務に携わる ⁃ 請求書業務の⾮効率さに⼤きな課題を感じ、インボイス管理 サービス「Bill One」の事業開発に着⼿ ⁃ 現在はプロダクトマネジャーとして、新しい請求書業務の在 り⽅を普及させるために尽⼒する 35

川瀬 圭亮 Sansan事業部 プロダクトマネジャー ⁃ 在学中は政治学を専攻しながら、 フリーランスのWEBデザイナーとしても活動 ⁃ 卒業後、国内外のスタートアップやメガベンチャー、ビッグ テックでプロダクト開発に携わる ⁃ アジアの⼩中学⽣向け教育サービスから、国内⼤企業向け契 約管理サービスまで、様々なプロダクトマネジメントを担当 ⁃ 昨年、働きながら、オンラインでUSのMBAを取得 ⁃ 第⼀⼦、第⼆⼦ともに育休を取得 ⁃ 今年8⽉にSansan株式会社に⼊社 36

尾花 政篤 Contract One Unit プロダクトマネジャー ⁃ コンサルティングファームのマネジャーを経て、保険業界特 化型のVertical SaaSを創業。その後、2023年にSansan株式 会社に⼊社。 ⁃ 契約データベース「Contract One」のプロダクトマネジャー とグループ⼦会社の⾔語理解研究所を兼務。また社内の⽣成 AI/LLMを含めた⾃然⾔語処理技術の活⽤を推進。 37

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 38

39