アプリケーションのリアーキテクチャ で開発生産性が上がった話

Transcript

1. © DMM.com アプリケーションのリアーキテクチャ で開発生産性が上がった話 合同会社DMM.com プラットフォーム開発本部 佐々木 総
2. © DMM.com 自己紹介 2 • 名前: 佐々木 総(ささき そう) • 所属: 合同会社DMM.com プラットフォーム開発本部 • 経歴: ◦ 2016年新卒入社 ◦ 不正防止システムの運用開発(4年) ◦ ログインシステムの自動テスト構築(1年) ◦ DMMヘルプセンターの運用開発(3年~) • 趣味 : アニメ、ゲーム • 好きな言葉 : 　プログラムは思った通りに動かない、書いた通りに動く
3. © DMM.com 今日話すこと 3 ・開発運用中のプロダクトについて ・システム改善への歩み ・改善に向けてやってきたこととその効果
4. © DMM.com DMM.comについて 4 ※2025年3月時点
5. © DMM.com DMMヘルプセンターについて ・多種多様なサービスで柔軟にお客様のお困りごとを解決するためのシステム ・エンドユーザー向けUIから管理システムまで全て内製となっている 5
6. © DMM.com 6 システム改善への歩み • 第一弾 ◦ バックエンドシステムをPHPからGoへのリプレース ◦ 一年半ほど前にリプレース完了！！！！ • 第二弾 ◦ MVC→レイヤードアーキテクチャにリアーキテクチャ
7. © DMM.com 7 システム改善への歩み • 第一弾←軽めに触れます ◦ バックエンドシステムをPHPからGoへのリプレース ◦ 一年半ほど前にリプレース完了！！！！ • 第二弾←こちら中心に話します ◦ MVC→レイヤードアーキテクチャにリアーキテクチャ
8. © DMM.com 8 リプレース時の悩み • 開発プロセスが整備されておらず開発のリードタイムがとにかく遅かった • ひどい時はPRが20個くらいたまり、PR作成からマージまで200h以上かかってい た... Findy Team+のチームサマリ
9. © DMM.com 9 リプレース時の悩みの解決 • FindyTeam+を活用して開発プロセスを見直すことで改善しました • PRが溜まることなく目標としていた72h以内にはマージできるように！！ 引用元 : https://blog.findy-team.io/posts/interview_dmm_01/
10. © DMM.com リードタイムもよくなったし 順調に運用できている☺ リプレース大成功！！！！
11. © DMM.com とはならなかったorz
12. © DMM.com 12 リプレース後に抱えた課題 • PRの中身を見るとバグ修正対応が多いと気づき始める... • バグ修正PRも集計対象だったため、リードタイムはよく見えていた
13. © DMM.com なぜバグが多かった？
14. © DMM.com ソースコードのあちこちにビジネスロジックが混在
15. © DMM.com 15 ソースコードのあちこちにビジネスロジックが混在 • フレームワーク(Gin)依存でのリクエストパラメータの細かい制御🤔 リンクエストパラメータのbind時に文字数チェック
16. © DMM.com 16 ソースコードのあちこちにビジネスロジックが混在 • MVCにおけるController層での細かな分岐処理😵 リクエストパラメータ によって呼び出すサービス を変えている レスポンスを返す直前で分岐 処理...
17. © DMM.com 17 ソースコードのあちこちにビジネスロジックが混在 • データアクセス層でのまさかまさかのSQL文を利用した分岐処理😔
18. © DMM.com 18 ソースコードのあちこちにビジネスロジックが混在 • どこかを修正すれば他のどこかでバグが発生 • 検証作業やバグ修正対応で時間が取られて新規開発がで きない状態に...orz Controller (ビジネスロジック) Model (ビジネスロジック) DAO (ビジネスロジック) ビジネスロジック修正 Controller (ビジネスロジック) Model (ビジネスロジック) DAO (ビジネスロジック) バグ発生 バグ発生
19. © DMM.com せっかくリプレースしたのに どうしてこうなった...
20. © DMM.com 20 設計不足 • 設計スキルの欠如 ◦ そもそもソースコードの何が悪いのか気づけていなかった • 最初に正しい設計をせずにコーディング作業を進めていた ◦ 仕様変更の度にコードがどんどん複雑化していった • バグを埋め込みやすい変更容易性が低い（品質が悪い）コード に なっていた
21. © DMM.com 改善に向けて
22. © DMM.com 22 設計のプロフェッショナルに相談 • ミノ駆動さん (@MinoDriven)に相談 • 「良いコード／悪いコードで学ぶ設計入門 」の著者
 • アプリケーションアーキテクチャに精通
23. © DMM.com 23 設計のプロフェッショナルに相談 • 設計の学び直し ◦ ミノ駆動さんのレクチャーを受けながら設計を再学習 ◦ システム改善後も、設計の良し悪しを判断できる力を習得したい • ソースコードのリアーキテクチャ ◦ MVCからドメインモデリングを活用したレイヤードアーキテクチャへ移行 ▪ MVCだとデータ更新時の制約がコントローラーやモデルに分散しやすい ◦ 変更容易性が高いコードを目指すならば時間をかけてでもリアーキテクチャした方 がいいと判断 以下の活動を通して品質の高いシステム再構築することになった
24. © DMM.com 24 設計の学び直し • ミノ駆動さんの著書や社内向け設計ガイ ドラインを元にバグが発生しにくくなる設 計を学んだ ◦ 設計の基礎的なことを重点的に学 んだ ▪ カプセル化 ▪ 関心の分離 ▪ 単一責任の原則 ▪ etc ◦ その上でDDDなど応用的なことも学 んだ
25. © DMM.com 25 リアーキテクチャ • その後以下の流れでリアーキテクチャを進めた ◦ ユースケースの洗い出し ◦ ドメインモデリング ▪ イベントストーミングによるモデルの可視化 ◦ ドメインモデルを元に実装
26. © DMM.com 26 リアーキテクチャ • その後以下の流れでリアーキテクチャを進めた ◦ ユースケースの洗い出し ◦ ドメインモデリング ▪ イベントストーミングによるモデルの可視化 ◦ ドメインモデルを元に実装 ここから実例をまじえた少しだけ細かい話をしていきます🙇
27. © DMM.com ユースケース洗い出し • 誰が何をやりたいかを洗い出す • 要件漏れがないようにできる限りステークホルダーを集めて実施 ex.管理者目線でのヘルプのカテゴリーについて考えてみる 27
28. © DMM.com ユースケース洗い出し • カテゴリーだけでも作成、並べ替え、編集 ...などなど多くのユースケースがある • ただし、データが壊れるのは基本的には更新系なので参照系のユースケースは考えない 28
29. © DMM.com ドメインモデリングを実施 カテゴリー作成のモデリングについて考えてみる • カテゴリーだけでも作成、並べ替え、編集 ...などなど多くのユースケースがある • ただし、データが壊れるのは基本的には更新系なので参照系のユースケースは考えない 29
30. © DMM.com 30 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 ex.カテゴリーの作成
31. © DMM.com 31 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 ex.カテゴリーの作成
32. © DMM.com 32 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 • モデルに対応する箱を準備 ◦ この部分が実際にコード化される ex.カテゴリーの作成
33. © DMM.com 33 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 • モデルに対応する箱を準備 ◦ この部分が実際にコードかされる • データを壊さないための制約(ビジネスロ ジック)を検討 ◦ どうやったらデータを壊せるか、 ユーザーが困るかを考える ex.カテゴリーの作成
34. © DMM.com 34 モデルや制約をコードに落とし込む
35. © DMM.com 35 モデルや制約をコードに落とし込む Category作成用モデル
36. © DMM.com 36 モデルや制約をコードに落とし込む Category作成用モデルはTitleという値を持つ
37. © DMM.com 37 モデルや制約をコードに落とし込む Titleの生成用関数を用意 生成や更新するときは制約に注意！！
38. © DMM.com 38 モデルや制約をコードに落とし込む 生成したTitleなどを利用してCategory作成用モデルの生成関数を準備
39. © DMM.com 39 モデルや制約をコードに落とし込む このように制約を守って安全に生成されたモデルが DBに保存される（永続化）
40. © DMM.com 40 コード改善後 • ビジネスロジック(制約)がドメインモデルに集約された Controller (ビジネスロジック) Model (ビジネスロジック) DAO (ビジネスロジック) ドメインモデル (ビジネスロジック) バラバラだったビジネスロジックを ドメインモデルに集約
41. © DMM.com 41 コード改善後 • ビジネスロジック(制約)がドメインモデルに集約された • もし仕様変更があった場合でも修正範囲はモデル内にとどまる • 最初に制約を意識してドメインモデリングをしたので可能な限りバグを減 らせる interface (リクエスト制御) infrastructure (データ永続化) ドメインモデル (ビジネスロジック) 修正 interface (リクエスト制御) infrastructure (DB永続化) ドメインモデル (ビジネスロジック) 影響なし 影響なし
42. © DMM.com なんとかバグを埋めにくく変更容易性が高いコード を実装(設計)できるようになった!
43. © DMM.com 43 リアーキテクチャ後は... 様々な成績が改善傾向 改善前(半年間) 改善後(半年間) Findy Team+の詳細比較
44. © DMM.com 44 リアーキテクチャ後は... 特にレビュー時間(レビューから承認までの時間)が改善
45. © DMM.com 45 リアーキテクチャ後は... レビュー時間の改善に伴いリードタイムも改善 改善前 改善後 Findy Team+のリードタイムサマリ
46. © DMM.com リアーキテクチャで 開発生産性が上がってた
47. © DMM.com 47 レビュー時間が改善した要因 • シンプルにコードの可読性が上がった • ビジネスロジックがモデルに集約されて理解しやすくなった • コード実装前にモデリングを行うことでレビュワーを含むチーム全 体での仕様の理解が早くなった
48. © DMM.com 48 まとめ • バグを減らすためにリアーキテクチャを実施し、コードの品質が向上した • その結果、開発生産性が向上し、特にレビュー時間の短縮が顕著だった • レビュー時間はコード品質の一つの定量的な指標になり得ると改めて実感 • 反省点としてそのようなリアーキテクチャの効果を、事前に定量的に予測・検討し ながら進めるべきだったかもしれない... • 今後はFindy Team+などを活用し、コードだけでなくチーム全体の改善目標を定 量的に設定していきたい