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

■ イベント
技術的負債に向き合うConference 2026
https://technical-debt-con.findy-tools.io/2026

■登壇概要
タイトル：事業課題から技術的負債に向き合う
登壇者：技術本部 Sansan Engineering Unit グループマネジャー 加畑 博也

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

Transcript

1. 事業課題から技術的負債に向き合う Sansan株式会社 技術本部 Sansan Engineering Unit 加畑 博也
2. 加畑 博也 技術本部 Sansan Engineering Unit グループマネジャー ⼤学院卒業後、⼤⼿電機メーカーに研究開発職として新卒⼊社。2014 年、Sansan株式会社にWebエンジニアとして⼊社。営業AXサービス 「Sansan」の開発を担当し、現在は複数のプロジェクトマネジメン ト、グループマネジメントを兼任。
3. 技術的負債への対策 - 対策1: 事業の視点で課題を定義する - 対応する問題：優先度が上がらない∕予算が確保できない∕ステークホルダー を説得できない... - 対策2: プロジェクトとして遂⾏する - 対応する問題：開始しても進捗が悪い∕他タスクが差し込まれて進まない∕⼯ 数が膨らんで完了の⾒込みが⽴たない... 基本的なことを普通にやるのがもっとも効果的である。
4. 会社概要
5. 出会いから イノベーションを⽣み出す
6. 会社概要 社名 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キャリア株式会社
7. Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 法⼈向け 個⼈向け 名刺データベースが、収益を最⼤化する 契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 営業AXサービス 契約AXサービス 経理AXサービス 名刺アプリ 営業 契約 請求 名刺 管理 データクオリティマネジメント 各サービスの活⽤で変わる働き⽅ 必要な情報を 情報の管理がしやすく 情報を分析‧活⽤しやすく すぐに⾒つけられる すぐに共有できる データに基づいた判断ができる
8. Sansan事業 2026年5月期 通期実績 「Sansan 」：主要指標の状況 中小規模の獲得が進展し、契約件数は前年同期比 14.0%増と堅調に成長、契約当たり月次ストック売上高は同 1.0%減少 解約率は 0.55%となり、 1%未満の低水準を維持 (1)「Sansan」の既存契約のMRRに占める、解約に伴い減少したMRRの割合 7
9. Sansan事業 成長戦略 「Sansan」：提供価値の拡大 ビジネスデータの活用領域拡大を通じ、既存顧客における利用拡大と新規顧客獲得を推進 8
10. Sansanにおける技術的負債 - GitHub上は2011年から、プロダクト⾃体は2007年の創業から存在している。 - 過去の意思決定の歴史がコードという形で積層している。 - 本発表では、フレームワークの移⾏の事例を通じて、技術的負債への向き合い を紹介する。
11. 事例：フレームワークの移⾏
12. 前提：Sansanのシステム概観 - PC版/スマホアプリ、名刺スキャナ、APIなどを提供している。 - 数億枚の名刺データを保有し、バックエンドは約1億件/⽇の処理をしている。 Sansanユーザ Webブラウザ スマホアプリ Sansanプロダクト（サーバー） Webアプリ スマホ用アプリAPI RDB 外部システム用 コールバックAPI ファイルストレージ バッチ スキャナ 外部サービスなど スキャナ用API ユーザ公開用API 外部サービスなど キャッシュ メッセージキュー 内部システム用 コールバックAPI データ化/名寄せ など社内の別部署
13. 背景：開発フレームワークのサポート終了 - 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/
14. 背景：コードの複雑化 - 初期から現在に⾄るまでのコードが積層している。 - モジュール間が密結合しており、⼀か所の変更が様々な 箇所に波及する。 - ビジネスレイヤの設計⽅針が複数ある。 - 過去の世代が廃⽌されないまま次の世代が導⼊され、 共存している。
15. 背景：これまでの経緯 - 技術的負債と捉えて認識‧対策してきている。 - 7年前の議事録 → - 「開発⼯数の〇%は技術的負債の返済に あてる」といった⽅針を⽴てていた時期もある。 - ⼀⽅、事業戦略に関わる機能開発が優先され、 移⾏が停滞することもある。 - ⼀時期は最重要の機能開発にほぼすべてのメンバーが稼働していた。 - 投資判断としては正しい。移⾏している間に競争⼒を失い事業が失速したら 意味がない。
16. 対策1：事業の視点で課題を定義する
17. 前提：組織構成 - Sansanの開発組織はシンプルな階層構造である。 - 機能開発‧技術改善問わずプロジェクトの企画段階からエンジニアが⼊る。 Sansan Engineering Unit プロダクト 組織 部長 Mobile Enhancementグループ Reliabilityグループ グループマネジャー Sansan PdM グループマネジャー インフラ チーム チーム チーム Sansan デザイナー
18. なぜ優先度が上がらないのか - 開発組織のリソースは有限である。 - エンジニアの採⽤活動をがんばっても、急には増えない。 - ドメイン知識が深く、⾃⾛できるまでに時間がかかる。 - 事業が成⻑していく中で、機能開発‧改善のモチベーションは際限がない。 - 「フレームワークのサポートが終了する」「コードが複雑化している」と⾔わ れても、それを（機能開発より優先して）解決すべきか判断できない。 - 仮にエンジニア組織が決定権を持っていたとしても、⻑期にわたる改善で組織が ⼀貫した判断を保ち続けることは困難である。 - 優先順位が低いのではなく、⽐較ができていない。
19. だれにとっての課題か - 顧客の視点、すなわち事業の視点であるべきである。 - 「サポートが終了する」 - 事業の視点：「外部からの攻撃で顧客情報の漏洩‧事業停⽌のリスクがあ る。」 - 「コードが複雑化している」 - 事業の視点：「運⽤コスト‧新規機能開発コストが上がる。」 - 当たり前のことだが、改めて⾔語化しそれをもとに合意形成をする。 - さらに、そのリスク‧コストが具体的かつ実績値であるほど確度が⾼い。 - 攻撃を受ける確率、脆弱性が⾒つかる確率、想定される被害、... - 直近の新機能開発の⾒積もりと実績、⽇々の運⽤⼯数、...
20. 課題を具体化する - .NET Framework本体のサポート期限は 少なくともまだ数年の猶予がある。 - しかし、サードパーティーのライブラリは、 その⽅針を受けて.NET Frameworkの サポートを切っていく。 - 課題が曖昧な状況で想定していたよりも 期限が明らかになった。 https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework
21. 機能開発も事業課題を特定する - 当然ながら、機能開発でも事業の視点から課題を特定する。 - 課題が明確になっていない、あるいは複数の課題を混在すると、要件が複雑に なり、結果として課題の解決が難しくなる。 - 事業課題としてみたときに、 機能開発か技術改善かといった 区別は意味がなくなる。 https://buildersbox.corp-sansan.com/entry/2026/09/10/150000
22. スコープを設定し計画をたてる - 課題を解決するために必要な作業を網羅的に整理する。 - 各作業に必要なコストを⾒積もる。実績があればそれをもとに、未知のものは 不確実性を織り込む。
23. 合意形成をする - リスク‧コストその他の制約をもとに、課題を解決すべき期限を設定する。 - 制約の例：割り当てられる予算、アサイン可能なメンバー、... - その上で、ステークホルダーと合意形成をする。 - 開発組織の責任者やプロダクトマネージャー。 - Sansanの.NET移⾏に関しては、やるべきということ⾃体は合意が取れていた が、中⻑期的な投資の規模感を⽰し、機能開発その他との投資配分を合意し た。 - 前述のとおりリスクを正確に認識できていなかったため、その情報をもって優 先順位が相対的に上がり、注⼒して着⼿することが可能となった。
24. 対策2：プロジェクトとして遂⾏する
25. プロジェクトとは - PMBOKによると、プロジェクトの定義は「独⾃のプロダクト、サービス、所産 を創造するために実施する、有期性のある業務」である。 - 有期性、つまり完了が定義されていることが条件となる。 - 伝統的にはQuality/Cost/Deliveryの最適化が責務である。 - 以降ではプロジェクト完了に向けてSansanで意識し 実践していることを紹介する。
26. シンプルにする(1/2) - ビジネスロジックの設計⽅針は、4世代が混在している。 - 第1世代：Webアプリの各画⾯にビジネスロジックを1:1で実装 - 第2世代：DDDに寄せて共通化 - 第3世代：機能ドメイン単位に再設計 - 第4世代：登場⼈物を減らしてもっとシンプルに - 旧世代を.NET 10に対応させるより、ロジックを最新世代の アーキテクチャに移植するほうがコストも安い。 - 具体的なコストを⾒積もって意思決定をする。
27. シンプルにする(2/2) - 意思決定のコストを織り込み、登場⼈物を最⼩限にしている。 - 実装や画⾯の仕様、ユースケースの表層に引っ張られず、概念からモデリングす る。 https://en-ambi.com/itcontents/entry/2020/08/06/103000/
28. 移⾏対象を削減する(1/2) - プログラマ視点の⼀般的なアプローチとして、リファクタリングがある。 - リファクタリングにより排除できるのは「偶有的な複雑性」である。⼀⽅、プロ グラマの⽣産性の限界は「本質的な複雑性」にある。 - No Silver Bullet —Essence and Accident in Software Engineering [Brooks, 1986] - 本質的な複雑性は、解決すべき問題によってもたらされるものであり、これを取 り除くことはできない。 - プロダクトを取り巻く環境は時間とともに変化する。機能を開発したときの「解 決すべき問題」は、現在もそうか？ - リファクタリングではなく削除によって複雑性を削減する。
29. 移⾏対象を削減する(2/2) - 削除した場合のメリット、デメリットを事業‧顧客観点から定量で⽰す。 - 「利⽤頻度が⾼くない」→「⽉あたり10〜20回」 - 「コストが⾼い」→「1回のテストで2時間、過去1年間で2*20=40時間」 - 顧客影響に応じて数ヵ⽉のリードタイムを経て廃⽌する。
30. 別の課題を混ぜない - 課題が適切に定義されていれば、（制約の中で）それを解決する最⼩の要件‧ 設計を⽬指すべきである。 - ⼤⼩問わず、必須ではない変更は原則しない。「ついでに仕様を改善したい」 「リファクタリングしたい」という要求は⾃然に⽣まれる。 - 課題が別であれば別のプロジェクトとしたほうが、最終的に全体最適になる ケースが多い。 - 前提としてプロジェクトマネージャーが「ついでになおしたい」を拒否できる権 限を持っている必要がある。
31. 作業を分割する - ひとつのプロジェクトに複数の要件を盛り込み、設計が⻑引いたり、不具合が あるなど、進⾏を妨げていた。 - 画⾯の移⾏とビジネスロジックの移⾏を別にする。 - サブプロジェクトとして切り出す。 - 過去には細かく切りすぎて⾮効率な 時期もあった。あくまで全体をみて 効率化をする必要がある。 https://speakerdeck.com/sansantech/20250226
32. 段階的にリリースする - 技術的負債のプロジェクトで頻出する問題が、⼤規模な移⾏によりプロダクト の品質が低下することである。 - 単⼀のデプロイ単位と思い込んでいるものを分割する戦略を検討する。 - あるAPIを.NET Frameworkから.NET 10へ移⾏する際、アプリケーション単位 で.NET 10に移⾏‧リリースすると、プロジェクトのサイズが⼤きくなりリスク ‧コストが⾼まる懸念があった。 - そこで、エンドポイント単位で段階的に移⾏する⽅針とした。特定のエンドポ イントのみを.NET 10版の独⽴したアプリケーションとして実装‧デプロイし、 ロードバランサーでリクエストのURLをみて振り分ける環境を構築した。
33. まとめ
34. フレームワーク移⾏の現状 - 現在も注⼒して取り組んでいる。 - 旧世代のアーキテクチャーのうち、最も複雑性の⾼い箇所は廃⽌できた。 - ⼀部のバッチアプリケーション、APIは.NET 10で稼働しはじめた。 - 計画や設計はイテレーティブに⾒直している。 - ウォーターフォール的な プロセスをやりたいわけ ではない。
35. そのほかの事例：データベーススケールアウト - Sansanのデータベースは、主にAWS EC2上のPostgreSQLである。 - データ量の増加に対してスケールアップで対応してきたが、今後は継続的なス ケールアウトの実施がサービスの安定稼働に必要となっている。 - リザーブドインスタンスの期限を制約として計画、進⾏している。
36. そのほかの事例：パフォーマンス改善 - ユーザーの体験が損なわれると、利⽤が定着せず解約のリスクになる。 - 過去にはSLOを定めていたが、優先順位が上がらず運⽤に乗らなかった。 - ⼤規模なBtoB SaaS特有の技術的な難しさと向き合っている。 - インデックスを張るだけでは⾜りない。数億件の名刺データを扱うSansanのSQLパフォーマンス改善 - マルチテナントアプリケーションのクエリチューニング実例 - 1年前と⽐べて、Sansan全体のレスポンスタイムは約40%改善した。
37. 技術的負債への対策（再掲） - 対策1: 事業の視点で課題を定義する - 対応する問題：優先度が上がらない∕予算が確保できない∕ステークホルダー を説得できない... - 対策2: プロジェクトとして遂⾏する - 対応する問題：開始しても進捗が悪い∕他タスクが差し込まれて進まない∕⼯ 数が膨らんで完了の⾒込みが⽴たない... 基本的なことを普通にやるのがもっとも効果的である。
38. Sansan 技術本部 採⽤情報 https://media.sansan-engineering.com/