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

Slide 1

Slide 1 text

設計を積み重ねてシステムを刷新する Sansan株式会社 Sansan Engineering Unit 加畑博也リプレイスメント・デイ - システム刷新の最前線 -

Slide 2

Slide 2 text

背景

Slide 3

Slide 3 text

3 © Sansan, Inc. 名刺管理から、収益を最⼤化する営業DXサービス「Sansan」 Sansanは、名刺や企業情報、営業履歴を⼀元管理して全社で共有できるようにすることで、売上拡⼤とコスト削減を同時に実現する営業DXサービスです。

Slide 4

Slide 4 text

4 © Sansan, Inc. 営業DXサービス「Sansan」 4 10,000社 ※利⽤企業数は、営業DXサービス「Sansan」をご利⽤いただいている契約数利⽤企業シェア ※営業⽀援DXにおける名刺管理サービスの最新動向2025 （2025年1⽉シード・プランニング調査） 84.1%

Slide 5

Slide 5 text

5 © Sansan, Inc. Sansanユーザ Webブラウザスマホアプリスキャナ外部サービスなど Sansanプロダクト（サーバー） Webアプリスマホ用アプリAPI スキャナ⽤API ユーザ公開⽤API RDB ファイルストレージキャッシュメッセージキュー外部システム⽤コールバックAPI 内部システム⽤コールバックAPI バッチ外部サービスなどデータ化/名寄せなど社内の別部署システム構成 - ユーザーに提供するアプリケーションやAPI、および社内向けのAPI等も含めて、WebサービスとしてのSansanを提供している。

Slide 6

Slide 6 text

6 © Sansan, Inc. Sansan Engineering Unit（約30名）開発組織 Enhancementグループ（約15名） Reliabilityグループ（約15名）プロダクト組織 Sansan PdM チームグループマネジャー Mobileグループ Sansan デザイナーインフラグループグループマネジャーチームチーム - 基本的にマネジャーを含めて全メンバーがコードを書く。 - ドメインを限定せずプロジェクトをアサイン・リードする。

Slide 7

Slide 7 text

7 © Sansan, Inc. プロダクトの歴史 - GitHubに残っている最初のコミットは2011年である。 - システムはGitHub以前、2007年の創業から存在している。

Slide 8

Slide 8 text

課題

Slide 9

Slide 9 text

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/

Slide 10

Slide 10 text

10 © Sansan, Inc. 課題：技術的負債の蓄積 - 初期から現在に⾄るまでのコードが積層している。 - モジュール間が密結合している。 - 複数世代のアーキテクチャが共存している。 - 保守性や開発効率が低下している。 http://www.laputan.org/mud/ https://www.infoq.com/news/2015/01/lava-layer-antipattern

Slide 11

Slide 11 text

11 © Sansan, Inc. - システム刷新は⻑期的な取り組みとして、漸進的に進めている。 - 「重要であるが、緊急ではない」タスクである。 - ⼀般論としての対策は「計画すること」である。 - ⼀⽅、「重要かつ緊急」な機能開発もある。 - 機能開発が流動的なため、システム刷新の計画が⽴たない。 - 本質的に、事業の対象となる市場・社会⾃体の不確実性が⾼いためである。 - システム刷新を停滞させずに進捗するには、どうすればいいか？課題：システム刷新の停滞 https://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method Eisenhower Matrix

Slide 12

Slide 12 text

対策

Slide 13

Slide 13 text

13 © Sansan, Inc. - “私が検討する難問の⼀つ⼀つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの⼩部分に分割することである。” by デカルト - システム刷新を実⾏可能な単位に分割し、機能開発の合間に組み込む。対策：困難は分割せよ

Slide 14

Slide 14 text

14 © Sansan, Inc. - ライブラリ - ⾮業務機能 - データプロバイダ - データベースコネクション管理 - メッセージング処理（⾮同期・分散ライブラリ） - … - 業務機能 - ビジネスロジック - エントリーポイントアプリケーション - Webアプリ - Web API（公開API＆社内API） - バッチ対策：全体を体系的に分割

Slide 15

Slide 15 text

15 © Sansan, Inc. - 体系的な分割の単位では⼤きすぎる。 - 機能開発のプロジェクトより優先してアサインできない。 - プロジェクトマネジメントにおける不確実性が⾼い。 - 概算⼯数を⾒積り、適切な粒度に分割する。 - 例えば、1000時間×1プロジェクトを100時間×10プロジェクトに。 - 実⾏単位の依存関係を明確にし、並列化を意識する。 - 例えば、複数のアプリケーションから参照するライブラリを移⾏する場合、ライブラリ⾃体の移⾏および各アプリケーションの移⾏を分割する。対策：実⾏可能な単位へ分割

Slide 16

Slide 16 text

16 © Sansan, Inc. - 互換性のあるインターフェイスを使って段階的に進める。 - ライブラリを.NET Standardに移⾏し、そのあとにエントリポイントアプリケーションを.NETに移⾏する。対策：実⾏可能な単位へ分割 - フェーズ

Slide 17

Slide 17 text

17 © Sansan, Inc. - .NET移⾏のため、WebフレームワークをMVCへ変更する。 - アーキテクチャ移⾏のため、ロジックを新世代へ再実装する。 - しかし、これらが同時である必要はない。対策：実⾏可能な単位へ分割 - コンポーネント

Slide 18

Slide 18 text

18 © Sansan, Inc. - .NET Frameworkに依存する実装を廃⽌する。 - しかし、すべて同時に廃⽌する必要はない。 - 「ライブラリAを移⾏」を、「ライブラリAのクラス1を移⾏」「ライブラリAのクラス2を移⾏」に分割する。対策：実⾏可能な単位へ分割 - 機能

Slide 19

Slide 19 text

19 © Sansan, Inc. - メリット - システム刷新の進⾏を保証しつつ、⽇常の機能開発と両⽴できる。 - プロジェクトの規模が⼩さくなり、品質が向上する。 - デメリット - システムとしての⼀貫性が損なわれる。 - 新たな技術的負債をリアルタイムに⽣み出すだけになるかもしれない。対策：分割のメリット・デメリット

Slide 20

Slide 20 text

20 © Sansan, Inc. - 設計書を作成し、アーキテクトがオープンな場でレビューをする。 - 限定されたユースケースではなく、アプリケーション全体で整合させる /妥当な品質に押し上げる。対策：設計への投資 https://martinfowler.com/bliki/DesignStaminaHypothesis.html 設計＝スタミナ仮説

Slide 21

Slide 21 text

実例

Slide 22

Slide 22 text

22 © Sansan, Inc. - アーキテクトがバックログにイシューを起票する。 - 密結合の温床になっている汎⽤処理ライブラリから、移⾏プロジェクトを切り出す。実例：起案

Slide 23

Slide 23 text

23 © Sansan, Inc. - 起票したイシューについて、優先度をつける。 - 様々な要因を勘案してメンバーへのアサインを決定する。 - 他プロジェクトのアサイン状況 - プロジェクトの優先度 - プロジェクトの難易度 - メンバーの熟達度 - メンバーのタスク状況 - … - 適切に分割しておくことで、アサインがしやすくなる。実例：リファインメント＆アサイン

Slide 24

Slide 24 text

24 © Sansan, Inc. - イシューで定義されたスコープで、設計をする。 - ⽂字列の正規化処理をするメソッド群は⾮業務機能と判断し、社内パッケージに移⾏する。 - コードレベルの依存関係を切り離し、結合を疎にする。実例：設計

Slide 25

Slide 25 text

25 © Sansan, Inc. - プロジェクト内のメンバーおよびアーキテクトによるレビューをする。実例：設計レビュー

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © Sansan, Inc. - うまくいった点 - 密結合の温床だった汎⽤処理ライブラリを⼩分けにしてアサインすることで、着⼿しやすくなり、リリースまでのサイクルが短縮された。 - ユースケースや利⽤者を意識したインターフェースを再設計できた。 - 改善点 - プロジェクト初期の時点でメソッドの仕様を再整理すべきだった。 - ライブラリの挙動を維持する前提で設計してしまっていた。 - 設計の論点がふくらみ、結果として⼯数が上振れした。実例：結果

Slide 28

Slide 28 text

TIPS

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 © Sansan, Inc. - 機能廃⽌のプロセスを整備する。 - 利⽤状況や顧客価値、プロダクトの⽅向性を勘案して意思決定する。 TIPS：作り直す前に廃⽌を考える https://levtech.jp/media/article/interview/detail_370/

Slide 31

Slide 31 text

31 © Sansan, Inc. - 基本は仕様を維持し、ついでの機能改善は避ける。 - しかし、そのために⾒合わないコストをかける必要はない。 - Webフレームワークを変更するなら、新しい仕組みに則る。 - プロダクトマネージャーやデザイナーと協⼒関係になる。 TIPS：無理に仕様を維持しない

Slide 32

Slide 32 text

結論

Slide 33

Slide 33 text

33 © Sansan, Inc. - ソフトウェアシステムは継続的に適応・変化を続けなければならない。 - Lehmanのソフトウェア進化法則: https://ieeexplore.ieee.org/document/1456074 - 成⻑を続けるシステムの刷新は、本質的に進捗しづらい。 - 適切な粒度への分割と、設計への投資によって対処している。 - 結果、機能開発が多くある中で、破綻せず継続できている。結論：まとめ

Slide 34

Slide 34 text

34 © Sansan, Inc. - 困難を分割する - 分割統治的なアプローチは、システム刷新にかぎらず、⼀般的な課題解決の戦略である。 - 例：「スライドをつくる」という困難を分割して、「構成をつくる」「背景の章をつくる」「まとめの章をつくる」… - 設計に投資する - ⻑期的に価値を提供するシステムにおいて、⼀貫性・整合性の⽋如による負債、初期の投資による効果は軽視されがちである。結論：学び

Slide 35

Slide 35 text

35 © Sansan, Inc. 採⽤案内 Sansan Engineering Unitのカルチャーや具体的な業務内容など気になることを応募前に⾯談にてお話することができます。お気軽にお申し込みください。カジュアル⾯談採⽤情報申し込みはこちら募集中のポジションやメンバーの執筆記事、オフィス、社内制度などを紹介しています。詳細はこちら

Slide 36

Slide 36 text

No content