設計を積み重ねてシステムを刷新する

■ イベント
リプレイスメント・デイ - システム刷新の最前線 -
https://enechange-meetup.connpass.com/event/343395/

■ 発表者
技術本部 Sansan Engineering Unit Product Enhancementグループ
加畑 博也

■ Sansan 開発エンジニア 採用情報
https://media.sansan-engineering.com/sansan-engineer

Transcript

1. 設計を積み重ねてシステムを刷新する Sansan株式会社 Sansan Engineering Unit 加畑博也 リプレイスメント・デイ - システム刷新の最前線 -
2. 背景
3. 3 © Sansan, Inc. 名刺管理から、収益を最⼤化する 営業DXサービス「Sansan」 Sansanは、名刺や企業情報、営業履歴を ⼀元管理して全社で共有できるようにすることで、 売上拡⼤とコスト削減を同時に実現する 営業DXサービスです。
4. 4 © Sansan, Inc. 営業DXサービス「Sansan」 4 10,000社 ※利⽤企業数は、 営業DXサービス「Sansan」を ご利⽤いただいている契約数 利⽤企業 シェア ※営業⽀援DXにおける 名刺管理サービスの最新動向2025 （2025年1⽉ シード・プランニング調査） 84.1%
5. 5 © Sansan, Inc. Sansanユーザ Webブラウザ スマホアプリ スキャナ 外部サービスなど Sansanプロダクト（サーバー） Webアプリ スマホ用アプリAPI スキャナ⽤API ユーザ公開⽤API RDB ファイルストレージ キャッシュ メッセージキュー 外部システム⽤ コールバックAPI 内部システム⽤ コールバックAPI バッチ 外部サービスなど データ化/名寄せ など社内の別部署 システム構成 - ユーザーに提供するアプリケーションやAPI、および社内向けのAPI等も 含めて、WebサービスとしてのSansanを提供している。
6. 6 © Sansan, Inc. Sansan Engineering Unit（約30名） 開発組織 Enhancementグループ （約15名） Reliabilityグループ （約15名） プロダクト 組織 Sansan PdM チーム グループマネジャー Mobileグループ Sansan デザイナー インフラグループ グループマネジャー チーム チーム - 基本的にマネジャーを含めて全メンバーがコードを書く。 - ドメインを限定せずプロジェクトをアサイン・リードする。
7. 7 © Sansan, Inc. プロダクトの歴史 - GitHubに残っている最初のコミットは2011年である。 - システムはGitHub以前、2007年の創業から存在している。
8. 課題
9. 9 © Sansan, Inc. - Sansanの開発⾔語はC#、フレームワークは.NET Frameworkである。 - .NET Frameworkは現⾏バージョンで開発終了が発表されている。 - 新たなフレームワークである.NETへの移⾏が必要である。 課題：開発フレームワークのサポート終了 https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-9/
10. 10 © Sansan, Inc. 課題：技術的負債の蓄積 - 初期から現在に⾄るまでのコードが積層している。 - モジュール間が密結合している。 - 複数世代のアーキテクチャが共存している。 - 保守性や開発効率が低下している。 http://www.laputan.org/mud/ https://www.infoq.com/news/2015/01/lava-layer-antipattern
11. 11 © Sansan, Inc. - システム刷新は⻑期的な取り組みとして、 漸進的に進めている。 - 「重要であるが、緊急ではない」タスクである。 - ⼀般論としての対策は「計画すること」である。 - ⼀⽅、「重要かつ緊急」な機能開発もある。 - 機能開発が流動的なため、システム刷新の計画が⽴たない。 - 本質的に、事業の対象となる市場・社会⾃体の 不確実性が⾼いためである。 - システム刷新を停滞させずに進捗するには、どうすればいいか？ 課題：システム刷新の停滞 https://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method Eisenhower Matrix
12. 対策
13. 13 © Sansan, Inc. - “私が検討する難問の⼀つ⼀つを、 できるだけ多くの、しかも問題をよりよく 解くために必要なだけの⼩部分に 分割することである。” by デカルト - システム刷新を実⾏可能な単位に分割し、 機能開発の合間に組み込む。 対策：困難は分割せよ
14. 14 © Sansan, Inc. - ライブラリ - ⾮業務機能 - データプロバイダ - データベースコネクション管理 - メッセージング処理（⾮同期・分散ライブラリ） - … - 業務機能 - ビジネスロジック - エントリーポイントアプリケーション - Webアプリ - Web API（公開API＆社内API） - バッチ 対策：全体を体系的に分割
15. 15 © Sansan, Inc. - 体系的な分割の単位では⼤きすぎる。 - 機能開発のプロジェクトより優先してアサインできない。 - プロジェクトマネジメントにおける不確実性が⾼い。 - 概算⼯数を⾒積り、適切な粒度に分割する。 - 例えば、1000時間×1プロジェクトを100時間×10プロジェクトに。 - 実⾏単位の依存関係を明確にし、並列化を意識する。 - 例えば、複数のアプリケーションから参照するライブラリを移⾏する場 合、ライブラリ⾃体の移⾏および各アプリケーションの移⾏を分割する。 対策：実⾏可能な単位へ分割
16. 16 © Sansan, Inc. - 互換性のあるインターフェイスを使って段階的に進める。 - ライブラリを.NET Standardに移⾏し、そのあとに エントリポイントアプリケーションを.NETに移⾏する。 対策：実⾏可能な単位へ分割 - フェーズ
17. 17 © Sansan, Inc. - .NET移⾏のため、WebフレームワークをMVCへ変更する。 - アーキテクチャ移⾏のため、ロジックを新世代へ再実装する。 - しかし、これらが同時である必要はない。 対策：実⾏可能な単位へ分割 - コンポーネント
18. 18 © Sansan, Inc. - .NET Frameworkに依存する実装を廃⽌する。 - しかし、すべて同時に廃⽌する必要はない。 - 「ライブラリAを移⾏」を、 「ライブラリAのクラス1を移⾏」 「ライブラリAのクラス2を移⾏」に分割する。 対策：実⾏可能な単位へ分割 - 機能
19. 19 © Sansan, Inc. - メリット - システム刷新の進⾏を保証しつつ、⽇常の機能開発と両⽴できる。 - プロジェクトの規模が⼩さくなり、品質が向上する。 - デメリット - システムとしての⼀貫性が損なわれる。 - 新たな技術的負債をリアルタイムに⽣み出すだけになるかもしれない。 対策：分割のメリット・デメリット
20. 20 © Sansan, Inc. - 設計書を作成し、アーキテクトがオープンな場でレビューをする。 - 限定されたユースケースではなく、アプリケーション全体で整合させる /妥当な品質に押し上げる。 対策：設計への投資 https://martinfowler.com/bliki/DesignStaminaHypothesis.html 設計＝スタミナ仮説
21. 実例
22. 22 © Sansan, Inc. - アーキテクトがバックログにイシューを起票する。 - 密結合の温床になっている汎⽤処理ライブラリから、 移⾏プロジェクトを切り出す。 実例：起案
23. 23 © Sansan, Inc. - 起票したイシューについて、優先度をつける。 - 様々な要因を勘案してメンバーへのアサインを決定する。 - 他プロジェクトのアサイン状況 - プロジェクトの優先度 - プロジェクトの難易度 - メンバーの熟達度 - メンバーのタスク状況 - … - 適切に分割しておくことで、アサインがしやすくなる。 実例：リファインメント＆アサイン
24. 24 © Sansan, Inc. - イシューで定義されたスコープで、設計をする。 - ⽂字列の正規化処理をするメソッド群は⾮業務機能と判断し、社内パッ ケージに移⾏する。 - コードレベルの依存関係を切り離し、結合を疎にする。 実例：設計
25. 25 © Sansan, Inc. - プロジェクト内のメンバーおよびアーキテクトによるレビューをする。 実例：設計レビュー
26. 26 © Sansan, Inc. - 設計にのっとって実装＆コードレビューをする。 - 実装において設計に論点が⽣じた場合は、再設計をする。 - 要件やスコープに⽴ち戻ることもある。 実例：実装
27. 27 © Sansan, Inc. - うまくいった点 - 密結合の温床だった汎⽤処理ライブラリを⼩分けにしてアサインするこ とで、着⼿しやすくなり、リリースまでのサイクルが短縮された。 - ユースケースや利⽤者を意識したインターフェースを再設計できた。 - 改善点 - プロジェクト初期の時点でメソッドの仕様を再整理すべきだった。 - ライブラリの挙動を維持する前提で設計してしまっていた。 - 設計の論点がふくらみ、結果として⼯数が上振れした。 実例：結果
28. TIPS
29. 29 © Sansan, Inc. TIPS：アーキテクチャをシンプルにする - 登場⼈物・依存関係を最⼩限にする。 - 前世代のアーキテクチャは登場⼈物が多く、解釈と判断の余地が⼤いに あった。
30. 30 © Sansan, Inc. - 機能廃⽌のプロセスを整備する。 - 利⽤状況や顧客価値、プロダクトの⽅向性を勘案して意思決定する。 TIPS：作り直す前に廃⽌を考える https://levtech.jp/media/article/interview/detail_370/
31. 31 © Sansan, Inc. - 基本は仕様を維持し、ついでの機能改善は避ける。 - しかし、そのために⾒合わないコストをかける必要はない。 - Webフレームワークを変更するなら、新しい仕組みに則る。 - プロダクトマネージャーやデザイナーと協⼒関係になる。 TIPS：無理に仕様を維持しない
32. 結論
33. 33 © Sansan, Inc. - ソフトウェアシステムは継続的に適応・変化を続けなければならない。 - Lehmanのソフトウェア進化法則: https://ieeexplore.ieee.org/document/1456074 - 成⻑を続けるシステムの刷新は、本質的に進捗しづらい。 - 適切な粒度への分割と、設計への投資によって対処している。 - 結果、機能開発が多くある中で、破綻せず継続できている。 結論：まとめ
34. 34 © Sansan, Inc. - 困難を分割する - 分割統治的なアプローチは、システム刷新にかぎらず、⼀般的な課題解 決の戦略である。 - 例：「スライドをつくる」という困難を分割して、「構成をつくる」「背 景の章をつくる」「まとめの章をつくる」… - 設計に投資する - ⻑期的に価値を提供するシステムにおいて、⼀貫性・整合性の⽋如によ る負債、初期の投資による効果は軽視されがちである。 結論：学び
35. 35 © Sansan, Inc. 採⽤案内 Sansan Engineering Unitのカルチャーや具体的な業 務内容など気になることを応募前に⾯談にてお話す ることができます。お気軽にお申し込みください。 カジュアル⾯談 採⽤情報 申し込みはこちら 募集中のポジションやメンバーの執筆記事、オフィ ス、社内制度などを紹介しています。 詳細はこちら