Sansan Engineering Unit 加畑 博也 削除からはじめよ #Fukuoka_33tech vol.3 ~技術負債解消編~ 

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

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

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

技術負債と私 - 過去にも様々な取り組みを紹介している。 - レガシーシステムのおそうじ - Sansan Tech Blog [kabata, 2018] - レガシーシステムとつきあう - Sansan Tech Blog [kabata, 2019] - レガシーシステムをこえて - Sansan Tech Blog [kabata, 2020] - 設計を積み重ねてシステムを刷新する - Speakerdeck [kabata, 2025] - 成⻑するプロダクトの複雑性 - Speakerdeck [kabata, 2026] 

技術負債へのアプローチ - プログラマ視点の⼀般的なアプローチとして、リファクタリングがある。 - リファクタリングにより排除できるのは「偶有的な複雑性」である。 ⼀⽅、プログラマの⽣産性の限界は「本質的な複雑性」にある。 - No Silver Bullet —Essence and Accident in Software Engineering [Brooks, 1986] - 本質的な複雑性は、解決すべき問題によってもたらされるものであり、 これを取り除くことはできない。 

技術負債へのアプローチ - プロダクトを取り巻く環境は時間とともに変化する。 機能を開発したときの「解決すべき問題」は、現在もそうか？ - 解決すべき問題を正しく認識すること⾃体が難しい。 正しい認識のもとで機能が作られているか？ - リファクタリングではなく削除によって複雑性を削減する。 - Sansanでの事例を3つ紹介する。 

事例1: ユーザー招待機能の削除 - ユーザーが同僚をSansanに招待する機能があった。 - 機能開発のプロジェクトでユーザーを追加する処理に触れるとき、 その導線のひとつであるユーザー招待機能もテストする必要がある。 - 招待機能は、歴史的経緯から複数のアプリケーションを跨いでおり、 テストのコストが⾼い。 - そのわりに利⽤頻度は⾼くなく、コストに対して顧客に提供している 価値が低い状態だった。 

事例1: ユーザー招待機能の削除 - 削除した場合のメリット、デメリットを事業・顧客観点から定量で⽰す。 - 「利⽤頻度が⾼くない」→「⽉あたり10〜20回」 - 「コストが⾼い」→「1回のテストで2時間、過去1年間で2*20=40時間」 

事例2: メッセージ機能の⼀部仕様の削除 - 同僚とSansan内でメッセージをやりとりする機能がある。 - メッセージの⽂⾯の中で、他ユーザーをメンションすることができる。 

事例2: メッセージ機能の⼀部仕様の削除 - 機能を消すことが⽬的ではない。仕様の整理でシンプルにできる。 - リリース当初に必要だった仕様が、現在も同じように必要とは限らない。 - 事業・顧客の価値を損なわないよう、営業・サポート部⾨と連携する。 

事例3: 利⽤状況を計測するログ追加 - 案件の進捗や状況を確認するための機能がある。 - かなり古くに作られたもので、アプリケーションのログが⼗分でなく、 利⽤状況が計測できない。 

事例3: 利⽤状況を計測するログ追加 - 客観的な情報が不⾜している場合は、計測する。 - トラックしたいユーザーの⾏動と、どのような情報が必要かを定義し、 設計する。 

まとめ - 本質的な複雑性はリファクタリングで改善できない。 - 解くべき問題を再定義し、機能・仕様を削除することで、 本質的な複雑性を改善することができる。 - 削除が⽬的ではない。事業・顧客の価値を主眼に置き、 客観的な指標をもって対話する。 - 「技術負債」という⾔葉を使わない。 

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

No content