Sansan Engineering Unit 加畑 博也 成⻑するプロダクトの複雑性 Sansan Tech Talk @関⻄ 〜⼤阪からプロダクトを牽引する！技術とカルチャーのリアル〜 

名刺管理から、収益を最⼤化する © Sansan, Inc. 

Sansanの成⻑ https://ir.corp-sansan.com/ja/ir/library/presentation.html 

Sansanの成⻑ https://ir.corp-sansan.com/ja/ir/library/presentation.html 

成⻑と複雑性 - 成⻑するプログラムは放っておくと 複雑になっていく [Lehman, 1980]。 - 複雑性に対処した事例を 3つの観点で紹介する。 https://users.ece.utexas.edu/~perry/education/SE-Intro/lehman.pdf 観測する 予防する 整理する 

事例1: 観測する - 特定の時間帯・データベースのパフォーマンスが著しく劣化していた。 - データベースサーバーのCPU/メモリや、PostgreSQLの共有バッファの 空き容量など、各種メトリクスに異常がない。 - PostgreSQLでの明⽰的なロックも発⽣していない。 - 実⾏されているクエリは無数にあり因果関係がわからない。 - 例えば、メッセージング処理の流量は1億/⽇。 

事例1: 観測する - PostgreSQL内部には軽量ロック(LWLock)の仕組みがある。 - Improve PostgreSQL performance: Diagnose and mitigate lock manager contention - 拡張モジュールを導⼊して計測した。 - 共有バッファの割り当てを⾏うための ロックで待ちが発⽣していた。 - ロックを取得しているクエリを特定し 改善した。 - 仮説を⽴て、観測して実証する。 https://levtech.jp/media/article/interview/detail_798/ 

事例2: 予防する - 「会議の⾳声から商談記録を⾃動で作りたい」という要求がある。 - 機能を作ることはできるが、今後もメンテナンスが必要になる。 - 提供したい価値を分析しスコープマネジメントを徹底する。 - PC/スマホアプリ？ - iOS/Android？ - 運⽤⾃動化？ - 企画・要件定義から アプリケーションエンジニアが 参加する。 https://speakerdeck.com/sansantech/20251121-1?slide=12 

事例2: 予防する - 必要最⼩限の機能として早期にリリースした。 - MVP(Minimum Viable Product) - ユーザーからのフィードバックや利⽤状況を 計測し、より価値を⾼めていくフェーズに ⼊っている。 - ⽣み出す価値に⾒合わない複雑化を防ぐ。 https://sin.sansan.com/update/2025-11/ 

事例3: 整理する - アプリケーションコードにおいて、DDDをベースとしたアーキテクチャ 設計があった。 - 抽象化された登場⼈物の解釈が⼈や時期によって異なり、開発時の合意 形成にコストがかかっていた。 https://speakerdeck.com/sansanbuildersbox/a-brief-history-of-sansans-architecture-135274eb-8665-4255-97c7-2166e28edaac 

事例3: 整理する - モデルとしての登場⼈物を最⼩限にし、⽤途を明確にした。 - 中⻑期的な開発のコストを織り込み、適切な抽象化で整理しなおす。 

まとめ - Sansanは国内最⼤規模のBtoB SaaSであり、成⻑を続けている。 - 成⻑に伴うプロダクトの複雑化は避けられない。 - その複雑性に対して、観測・予防・整理を継続的に⾏い制御している。 - 複雑性を制御し続けることは、ソフトウェアエンジニアリングの本質的な 課題である。 - Sansanの開発では、その課題に実プロダクトで向き合うことができる。 

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

No content