事業課題から技術的負債に向き合う

by SansanTech

Embed

Start on current slide

Slide 1

Slide 1 text

事業課題から技術的負債に向き合う Sansan株式会社技術本部 Sansan Engineering Unit 加畑博也

Slide 2

Slide 2 text

加畑博也技術本部 Sansan Engineering Unit グループマネジャー⼤学院卒業後、⼤⼿電機メーカーに研究開発職として新卒⼊社。2014 年、Sansan株式会社にWebエンジニアとして⼊社。営業AXサービス「Sansan」の開発を担当し、現在は複数のプロジェクトマネジメント、グループマネジメントを兼任。

Slide 3

Slide 3 text

技術的負債への対策 - 対策1: 事業の視点で課題を定義する - 対応する問題：優先度が上がらない∕予算が確保できない∕ステークホルダーを説得できない... - 対策2: プロジェクトとして遂⾏する - 対応する問題：開始しても進捗が悪い∕他タスクが差し込まれて進まない∕⼯数が膨らんで完了の⾒込みが⽴たない... 基本的なことを普通にやるのがもっとも効果的である。

Slide 4

Slide 4 text

会社概要

Slide 5

Slide 5 text

出会いからイノベーションを⽣み出す

Slide 6

Slide 6 text

会社概要社名 Sansan株式会社設⽴ 2007年6⽉11⽇従業員数 2,077名（2026年5月31日時点）上場証券取引所東京証券取引所プライム市場拠点本社：東京都渋⾕区桜丘町1-1 渋⾕サクラステージ28F 関⻄⽀店、福岡⽀店、中部⽀店サテライトオフィスグループ会社 Sansan神⼭ラボ、Sansan Innovation Lab、Sansan⻑岡ラボ Sansan Global Pte. Ltd. （シンガポール） Sansan Global Development Center, Inc. （フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ）ナインアウト株式会社株式会社⾔語理解研究所 Eightキャリア株式会社

Slide 7

Slide 7 text

Sansan株式会社の働き⽅を変えるAXサービス⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる「働き⽅を変えるAXサービス」を提供します。法⼈向け個⼈向け名刺データベースが、収益を最⼤化する契約データベースが、利益を守る「なくせる」をつくり、全社の働き⽅を変える営業AXサービス契約AXサービス経理AXサービス名刺アプリ営業契約請求名刺管理データクオリティマネジメント各サービスの活⽤で変わる働き⽅必要な情報を情報の管理がしやすく情報を分析‧活⽤しやすくすぐに⾒つけられるすぐに共有できるデータに基づいた判断ができる

Slide 8

Slide 8 text

Sansan事業 2026年5月期通期実績「Sansan 」：主要指標の状況中小規模の獲得が進展し、契約件数は前年同期比 14.0%増と堅調に成長、契約当たり月次ストック売上高は同 1.0%減少解約率は 0.55%となり、 1%未満の低水準を維持 (1)「Sansan」の既存契約のMRRに占める、解約に伴い減少したMRRの割合 7

Slide 9

Slide 9 text

Sansan事業成長戦略「Sansan」：提供価値の拡大ビジネスデータの活用領域拡大を通じ、既存顧客における利用拡大と新規顧客獲得を推進 8

Slide 10

Slide 10 text

Sansanにおける技術的負債 - GitHub上は2011年から、プロダクト⾃体は2007年の創業から存在している。 - 過去の意思決定の歴史がコードという形で積層している。 - 本発表では、フレームワークの移⾏の事例を通じて、技術的負債への向き合いを紹介する。

Slide 11

Slide 11 text

事例：フレームワークの移⾏

Slide 12

Slide 12 text

前提：Sansanのシステム概観 - PC版/スマホアプリ、名刺スキャナ、APIなどを提供している。 - 数億枚の名刺データを保有し、バックエンドは約1億件/⽇の処理をしている。 Sansanユーザ Webブラウザスマホアプリ Sansanプロダクト（サーバー） Webアプリスマホ用アプリAPI RDB 外部システム用コールバックAPI ファイルストレージバッチスキャナ外部サービスなどスキャナ用API ユーザ公開用API 外部サービスなどキャッシュメッセージキュー内部システム用コールバックAPI データ化/名寄せなど社内の別部署

Slide 13

Slide 13 text

背景：開発フレームワークのサポート終了 - Sansanの開発⾔語はC#、フレームワークは.NET Frameworkである。 - .NET Frameworkは現⾏バージョンで開発終了が発表されている。 - 新たなフレームワークである「.NET」への移⾏が必要である。 https://devblogs.microsoft.com/dotnet/announcing-dotnet-10/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/

Slide 14

Slide 14 text

背景：コードの複雑化 - 初期から現在に⾄るまでのコードが積層している。 - モジュール間が密結合しており、⼀か所の変更が様々な箇所に波及する。 - ビジネスレイヤの設計⽅針が複数ある。 - 過去の世代が廃⽌されないまま次の世代が導⼊され、共存している。

Slide 15

Slide 15 text

背景：これまでの経緯 - 技術的負債と捉えて認識‧対策してきている。 - 7年前の議事録 → - 「開発⼯数の〇%は技術的負債の返済にあてる」といった⽅針を⽴てていた時期もある。 - ⼀⽅、事業戦略に関わる機能開発が優先され、移⾏が停滞することもある。 - ⼀時期は最重要の機能開発にほぼすべてのメンバーが稼働していた。 - 投資判断としては正しい。移⾏している間に競争⼒を失い事業が失速したら意味がない。

Slide 16

Slide 16 text

対策1：事業の視点で課題を定義する

Slide 17

Slide 17 text

前提：組織構成 - Sansanの開発組織はシンプルな階層構造である。 - 機能開発‧技術改善問わずプロジェクトの企画段階からエンジニアが⼊る。 Sansan Engineering Unit プロダクト組織部長 Mobile Enhancementグループ Reliabilityグループグループマネジャー Sansan PdM グループマネジャーインフラチームチームチーム Sansan デザイナー

Slide 18

Slide 18 text

なぜ優先度が上がらないのか - 開発組織のリソースは有限である。 - エンジニアの採⽤活動をがんばっても、急には増えない。 - ドメイン知識が深く、⾃⾛できるまでに時間がかかる。 - 事業が成⻑していく中で、機能開発‧改善のモチベーションは際限がない。 - 「フレームワークのサポートが終了する」「コードが複雑化している」と⾔われても、それを（機能開発より優先して）解決すべきか判断できない。 - 仮にエンジニア組織が決定権を持っていたとしても、⻑期にわたる改善で組織が⼀貫した判断を保ち続けることは困難である。 - 優先順位が低いのではなく、⽐較ができていない。

Slide 19

Slide 19 text

だれにとっての課題か - 顧客の視点、すなわち事業の視点であるべきである。 - 「サポートが終了する」 - 事業の視点：「外部からの攻撃で顧客情報の漏洩‧事業停⽌のリスクがある。」 - 「コードが複雑化している」 - 事業の視点：「運⽤コスト‧新規機能開発コストが上がる。」 - 当たり前のことだが、改めて⾔語化しそれをもとに合意形成をする。 - さらに、そのリスク‧コストが具体的かつ実績値であるほど確度が⾼い。 - 攻撃を受ける確率、脆弱性が⾒つかる確率、想定される被害、... - 直近の新機能開発の⾒積もりと実績、⽇々の運⽤⼯数、...

Slide 20

Slide 20 text

課題を具体化する - .NET Framework本体のサポート期限は少なくともまだ数年の猶予がある。 - しかし、サードパーティーのライブラリは、その⽅針を受けて.NET Frameworkのサポートを切っていく。 - 課題が曖昧な状況で想定していたよりも期限が明らかになった。 https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework

Slide 21

Slide 21 text

機能開発も事業課題を特定する - 当然ながら、機能開発でも事業の視点から課題を特定する。 - 課題が明確になっていない、あるいは複数の課題を混在すると、要件が複雑になり、結果として課題の解決が難しくなる。 - 事業課題としてみたときに、機能開発か技術改善かといった区別は意味がなくなる。 https://buildersbox.corp-sansan.com/entry/2026/09/10/150000

Slide 22

Slide 22 text

スコープを設定し計画をたてる - 課題を解決するために必要な作業を網羅的に整理する。 - 各作業に必要なコストを⾒積もる。実績があればそれをもとに、未知のものは不確実性を織り込む。

Slide 23

Slide 23 text

合意形成をする - リスク‧コストその他の制約をもとに、課題を解決すべき期限を設定する。 - 制約の例：割り当てられる予算、アサイン可能なメンバー、... - その上で、ステークホルダーと合意形成をする。 - 開発組織の責任者やプロダクトマネージャー。 - Sansanの.NET移⾏に関しては、やるべきということ⾃体は合意が取れていたが、中⻑期的な投資の規模感を⽰し、機能開発その他との投資配分を合意した。 - 前述のとおりリスクを正確に認識できていなかったため、その情報をもって優先順位が相対的に上がり、注⼒して着⼿することが可能となった。

Slide 24

Slide 24 text

対策2：プロジェクトとして遂⾏する

Slide 25

Slide 25 text

プロジェクトとは - PMBOKによると、プロジェクトの定義は「独⾃のプロダクト、サービス、所産を創造するために実施する、有期性のある業務」である。 - 有期性、つまり完了が定義されていることが条件となる。 - 伝統的にはQuality/Cost/Deliveryの最適化が責務である。 - 以降ではプロジェクト完了に向けてSansanで意識し実践していることを紹介する。

Slide 26

Slide 26 text

シンプルにする(1/2) - ビジネスロジックの設計⽅針は、4世代が混在している。 - 第1世代：Webアプリの各画⾯にビジネスロジックを1:1で実装 - 第2世代：DDDに寄せて共通化 - 第3世代：機能ドメイン単位に再設計 - 第4世代：登場⼈物を減らしてもっとシンプルに - 旧世代を.NET 10に対応させるより、ロジックを最新世代のアーキテクチャに移植するほうがコストも安い。 - 具体的なコストを⾒積もって意思決定をする。

Slide 27

Slide 27 text

シンプルにする(2/2) - 意思決定のコストを織り込み、登場⼈物を最⼩限にしている。 - 実装や画⾯の仕様、ユースケースの表層に引っ張られず、概念からモデリングする。 https://en-ambi.com/itcontents/entry/2020/08/06/103000/

Slide 28

Slide 28 text

移⾏対象を削減する(1/2) - プログラマ視点の⼀般的なアプローチとして、リファクタリングがある。 - リファクタリングにより排除できるのは「偶有的な複雑性」である。⼀⽅、プログラマの⽣産性の限界は「本質的な複雑性」にある。 - No Silver Bullet —Essence and Accident in Software Engineering [Brooks, 1986] - 本質的な複雑性は、解決すべき問題によってもたらされるものであり、これを取り除くことはできない。 - プロダクトを取り巻く環境は時間とともに変化する。機能を開発したときの「解決すべき問題」は、現在もそうか？ - リファクタリングではなく削除によって複雑性を削減する。

Slide 29

Slide 29 text

移⾏対象を削減する(2/2) - 削除した場合のメリット、デメリットを事業‧顧客観点から定量で⽰す。 - 「利⽤頻度が⾼くない」→「⽉あたり10〜20回」 - 「コストが⾼い」→「1回のテストで2時間、過去1年間で2*20=40時間」 - 顧客影響に応じて数ヵ⽉のリードタイムを経て廃⽌する。

Slide 30

Slide 30 text

別の課題を混ぜない - 課題が適切に定義されていれば、（制約の中で）それを解決する最⼩の要件‧ 設計を⽬指すべきである。 - ⼤⼩問わず、必須ではない変更は原則しない。「ついでに仕様を改善したい」「リファクタリングしたい」という要求は⾃然に⽣まれる。 - 課題が別であれば別のプロジェクトとしたほうが、最終的に全体最適になるケースが多い。 - 前提としてプロジェクトマネージャーが「ついでになおしたい」を拒否できる権限を持っている必要がある。

Slide 31

Slide 31 text

作業を分割する - ひとつのプロジェクトに複数の要件を盛り込み、設計が⻑引いたり、不具合があるなど、進⾏を妨げていた。 - 画⾯の移⾏とビジネスロジックの移⾏を別にする。 - サブプロジェクトとして切り出す。 - 過去には細かく切りすぎて⾮効率な時期もあった。あくまで全体をみて効率化をする必要がある。 https://speakerdeck.com/sansantech/20250226

Slide 32

Slide 32 text

段階的にリリースする - 技術的負債のプロジェクトで頻出する問題が、⼤規模な移⾏によりプロダクトの品質が低下することである。 - 単⼀のデプロイ単位と思い込んでいるものを分割する戦略を検討する。 - あるAPIを.NET Frameworkから.NET 10へ移⾏する際、アプリケーション単位で.NET 10に移⾏‧リリースすると、プロジェクトのサイズが⼤きくなりリスク ‧コストが⾼まる懸念があった。 - そこで、エンドポイント単位で段階的に移⾏する⽅針とした。特定のエンドポイントのみを.NET 10版の独⽴したアプリケーションとして実装‧デプロイし、ロードバランサーでリクエストのURLをみて振り分ける環境を構築した。

Slide 33

Slide 33 text

まとめ

Slide 34

Slide 34 text

フレームワーク移⾏の現状 - 現在も注⼒して取り組んでいる。 - 旧世代のアーキテクチャーのうち、最も複雑性の⾼い箇所は廃⽌できた。 - ⼀部のバッチアプリケーション、APIは.NET 10で稼働しはじめた。 - 計画や設計はイテレーティブに⾒直している。 - ウォーターフォール的なプロセスをやりたいわけではない。

Slide 35

Slide 35 text

そのほかの事例：データベーススケールアウト - Sansanのデータベースは、主にAWS EC2上のPostgreSQLである。 - データ量の増加に対してスケールアップで対応してきたが、今後は継続的なスケールアウトの実施がサービスの安定稼働に必要となっている。 - リザーブドインスタンスの期限を制約として計画、進⾏している。

Slide 36

Slide 36 text

そのほかの事例：パフォーマンス改善 - ユーザーの体験が損なわれると、利⽤が定着せず解約のリスクになる。 - 過去にはSLOを定めていたが、優先順位が上がらず運⽤に乗らなかった。 - ⼤規模なBtoB SaaS特有の技術的な難しさと向き合っている。 - インデックスを張るだけでは⾜りない。数億件の名刺データを扱うSansanのSQLパフォーマンス改善 - マルチテナントアプリケーションのクエリチューニング実例 - 1年前と⽐べて、Sansan全体のレスポンスタイムは約40%改善した。

Slide 37

Slide 37 text

技術的負債への対策（再掲） - 対策1: 事業の視点で課題を定義する - 対応する問題：優先度が上がらない∕予算が確保できない∕ステークホルダーを説得できない... - 対策2: プロジェクトとして遂⾏する - 対応する問題：開始しても進捗が悪い∕他タスクが差し込まれて進まない∕⼯数が膨らんで完了の⾒込みが⽴たない... 基本的なことを普通にやるのがもっとも効果的である。

Slide 38

Slide 38 text

Sansan 技術本部採⽤情報 https://media.sansan-engineering.com/