20年にわたり進化を続けてきたSansanにおける技術的負債：「コードの積層」と開発フレームワークのサポート終了

Sansanは「出会いからイノベーションを生みだす」をミッションに掲げ、国内最大級の営業AXサービス「Sansan」をはじめとする各種プロダクトを展開しています。従業員数は2,000名を超え、営業AXサービス「Sansan」の契約社数は1.1万超、システムとしては数億枚の名刺データや1日1億件のバックエンド処理を担う巨大なトラフィック基盤です。

主力である「Sansan」は、会社の創業期である2007年から提供してきたプロダクトです。過去のコードを一から捨てて作り直すことはせず進化を続けてきたため、過去のあらゆる意思決定がコードとして蓄積されています。GitHub上は2011年から、プロダクト自体は創業2007年から約20年にわたって開発・運用を続けています。

これまでも技術的負債の返済には取り組んできましたが、事業戦略に直結する新規機能開発が優先され、移行プロジェクトが途中で停滞することもありました。ビジネスの競争力を落とさないための投資判断としては正当である一方、いかにしてこの状況を打開するかが問われていました。

本日の発表では、Sansanにおけるフレームワーク移行の事例を通じて「技術的負債」への向き合い方についてお話します。

フレームワーク「.NET Framework」のサポート終了と移行

SansanはPC版/スマホアプリ、名刺スキャナ、APIといった一般的なwebの構成で提供しています。名刺データは数億枚ものデータを保有するバックエンドで、バックエンドは1日1億件もの処理をするためトラフィックがかなり大規模となります。

開発言語であるC#の基盤「.NET Framework」が最終バージョンをもって開発終了をアナウンスされたため、最新の「.NET（.NET 10等）」への移行が必須となりました。また、Windows自体のサポート猶予だけでなく、依存しているサードパーティー製ライブラリのサポート終了時期を洗い出すと、猶予が想定より短いケースも浮き彫りになりました。

また、10年〜20年の歴史の中で、「画面バインド」「DDD（ドメイン駆動設計）の導入」「ドメイン単位の再設計」など、歴代の設計方針が廃止されないまま残存。モジュール同士が複雑に参照し合い、1箇所の変更が広範囲に波及するコスト増大を招いていました。

なぜ優先度が上がらないのか？「事業の視点」で課題を定義する

エンジニアリソースは常に有限であり、いくら採用を進めてもドメイン知識を獲得して自走するまでには一定の時間がかかるものです。その中で「技術的に古くなった」「コードが複雑である」というエンジニア目線の言葉だけで訴えても、意思決定者との間で課題の優先度を比較することは難しいです。

これは「技術が分かってる・分かっていない」と言う話ではなく、仮にエンジニア組織が決定権を持っていたとしても、長期わたる改善で組織が一貫した判断を保ち続けるのは極めて困難です。人の入れ替わりはもちろんの事、市場や社会の状況も常に変化するため、ある時の意思決定が持続する状況は極めて稀です。

課題解決の本質は「優先度が高い・低い」を議論する前段階の「比較ができる状態を作れているか」にあるのではないでしょうか。

「だれにとっての課題か？」においては、事業の視点であるべきです。

「サポート終了のリスク」は単に「フレームワークが古い」ではなく、脆弱性放置による「情報漏洩や事業停止のリスク」として捉えます。また、「コードの複雑化」においては、「コードが綺麗でない」ではなく、「1年前と比較した機能開発スピードの低下」や「日々の運用工数（時間・費用）」として定量化します。

当たり前といえば当たり前の視点ですが、これをしっかりと出来ているか？は改めて問いかけて言語化、そしてステークホルダーと合意形成する事をちゃんとやる、これが重要かと思います。

非機能要件や技術的負債も、ビジネスの価値・リスクという軸で言語化・定量化することで、機能開発と技術改善が初めて同じテーブルで比較可能になります。組織の制約（予算やアサイン可能なエンジニア）を加味した上で期限を設定し、ステークホルダーと強固な合意形成を図ることがスタートラインとなります。

ここまでは「課題の特定」についてお話してきました。ここからは「プロジェクトとして遂行する」上で何が重要なのか？Sansanでの取り組みにおいて意識した点についてお話します。

「プロジェクト」として遂行する

プロジェクトにおいて重要なのは「有期性」つまり、いつまでに・何を完了する？と言った点を定義することです。つまり「完了」が定義されていることが条件となります。

ここからは、プロジェクト完了に向けてSansanで意識しているTipsをご紹介します。

①：シンプルにする

冒頭で「ビジネスロジックが積層している」とお話しましたが、ビジネスロジックには以下のような世代が複数存在します。

• 第1世代：Webアプリの各画面にビジネスロジックを1:1で実装
• 第2世代：DDDに寄せて共通化
• 第3世代：機能ドメイン単位に再設計
• 第4世代：登場人物を減らしてもっとシンプルに

複数世代の旧設計思想（DDDなど）を新環境へ無理に対応・移植させるのではなく、ロジックを最新世代のシンプルなアーキテクチャに直接移植する方針を選択しました。「スライド1枚で説明がつくレベル」まで登場人物（クラスやレイヤー）を削ぎ落とし、設計時や合意形成にかかる意思決定コストを徹底的に削減しています。

参考記事： モノリシックな大規模アプリを運用する技術-サービスを“分割しない”メリットをSansanの実例に学ぶ

②：移行対象を削減する

プログラマーがリファクタリングで解消できるのは「偶発的な複雑性」です。ビジネスロジックの分岐など「本質的な複雑性」はコードに残ります。
そこで、「顧客や事業の視点から見て、この機能・仕様は現在も本当に必要なのか？」を問い直し、利用頻度や保守コストを定量評価した上で、不要な機能を廃止・仕様削減して本質的なコード量自体を減らしています。

③：別の課題を混ぜない

プロジェクト進行中に「ついでにここも直したい」という欲求が生まれるのは自然ですが、課題が異なる場合は厳格に別プロジェクトとして切り離します。要件を膨らませないためにも、エンジニアやPMがプロジェクトのオーナーシップと拒否権（権限）を持つことが重要です。

④：作業を分割する

画面の実装移行と、裏側のコアビジネスロジックの移行をサブプロジェクトとして分割するなど、変更の影響範囲を小さくコントロールします。ただし、細分化しすぎると非効率になるため全体最適な視点が必須となります。

参考記事： 設計を積み重ねてシステムを刷新する

⑤：段階的にリリースする

技術的負債のプロジェクトでよく聞く話ではありますが、大規模な突貫リリースはバグが起きたり品質低下、リリースが長引くリスクがあります。

「デプロイの単位って、単一でやるべきなのか？本当にそれはやる必要があるのか？」

こう言った観点を検討する必要があります。

Sansanでは、インフラ側と連携しAPIのエンドポイント単位で切り出して別アプリケーションとして実装・デプロイする仕組みを構築しました。一見遠回りに見えますが、リスクを分散しながら段階的にリリースを重ねています。

まとめ

本日お話したフレームワークの移行は、進行中で現在も取り組んでいます。
これらのアプローチにより、最も複雑度の高かった第2世代アーキテクチャの廃止が完了し、一部のバッチ処理やAPIではすでに.NET 10での運用が開始されています。

また、フレームワーク移行以外にも「データベーススケールアウト」や「パフォーマンス改善」のような大規模改善が並行して進められています。

本日お話したのは「事業の視点で課題を定義する」「プロジェクトとして遂行する」と言った一見普通のことでした。ですが、こうした普通を普通にやる事が一番効果的な一方で、一番難しいのではないでしょうか。改めて一度向き合ってみるのも良いのではないか？という事で今回発表させていただきました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。