Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリケーションのリアーキテクチャ で開発生産性が上がった話
Search
sasaki
March 26, 2025
Technology
0
110
アプリケーションのリアーキテクチャ で開発生産性が上がった話
sasaki
March 26, 2025
Tweet
Share
More Decks by sasaki
See All by sasaki
チーム開発における責任と感謝の話
ssk1991
0
120
Other Decks in Technology
See All in Technology
AIは変更差分からユニットテスト_結合テスト_システムテストでテストすべきことが出せるのか?
mineo_matsuya
5
2.7k
「Roblox」の開発環境とその効率化 ~DAU9700万人超の巨大プラットフォームの開発 事始め~
keitatanji
0
150
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
7.3k
開発と脆弱性と脆弱性診断についての話
su3158
0
140
Observability for LLM Application lifecycle
ivry_presentationmaterials
1
170
[CVPR2025論文読み会] Linguistics-aware Masked Image Modelingfor Self-supervised Scene Text Recognition
s_aiueo32
0
140
自治体職員がガバクラの AWS 閉域ネットワークを理解するのにやって良かった個人検証環境
takeda_h
2
340
20250818_KGX・One Hokkaidoコラボイベント
tohgeyukihiro
0
120
会社にデータエンジニアがいることでできるようになること
10xinc
8
1.2k
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
180
信頼できる開発プラットフォームをどう作るか?-Governance as Codeと継続的監視/フィードバックが導くPlatform Engineeringの進め方
yuriemori
1
240
Cloud WANの基礎から応用~少しだけDeep Dive~
masakiokuda
4
130
Featured
See All Featured
Faster Mobile Websites
deanohume
309
31k
The Invisible Side of Design
smashingmag
301
51k
Gamification - CAS2011
davidbonilla
81
5.4k
Become a Pro
speakerdeck
PRO
29
5.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
KATA
mclloyd
32
14k
Raft: Consensus for Rubyists
vanstee
140
7.1k
How STYLIGHT went responsive
nonsquared
100
5.7k
Transcript
© DMM.com アプリケーションのリアーキテクチャ で開発生産性が上がった話 合同会社DMM.com プラットフォーム開発本部 佐々木 総
© DMM.com 自己紹介 2 • 名前: 佐々木 総(ささき そう) •
所属: 合同会社DMM.com プラットフォーム開発本部 • 経歴: ◦ 2016年新卒入社 ◦ 不正防止システムの運用開発(4年) ◦ ログインシステムの自動テスト構築(1年) ◦ DMMヘルプセンターの運用開発(3年~) • 趣味 : アニメ、ゲーム • 好きな言葉 : プログラムは思った通りに動かない、書いた通りに動く
© DMM.com 今日話すこと 3 ・開発運用中のプロダクトについて ・システム改善への歩み ・改善に向けてやってきたこととその効果
© DMM.com DMM.comについて 4 ※2025年3月時点
© DMM.com DMMヘルプセンターについて ・多種多様なサービスで柔軟にお客様のお困りごとを解決するためのシステム ・エンドユーザー向けUIから管理システムまで全て内製となっている 5
© DMM.com 6 システム改善への歩み • 第一弾 ◦ バックエンドシステムをPHPからGoへのリプレース ◦ 一年半ほど前にリプレース完了!!!!
• 第二弾 ◦ MVC→レイヤードアーキテクチャにリアーキテクチャ
© DMM.com 7 システム改善への歩み • 第一弾←軽めに触れます ◦ バックエンドシステムをPHPからGoへのリプレース ◦ 一年半ほど前にリプレース完了!!!!
• 第二弾←こちら中心に話します ◦ MVC→レイヤードアーキテクチャにリアーキテクチャ
© DMM.com 8 リプレース時の悩み • 開発プロセスが整備されておらず開発のリードタイムがとにかく遅かった • ひどい時はPRが20個くらいたまり、PR作成からマージまで200h以上かかってい た... Findy
Team+のチームサマリ
© DMM.com 9 リプレース時の悩みの解決 • FindyTeam+を活用して開発プロセスを見直すことで改善しました • PRが溜まることなく目標としていた72h以内にはマージできるように!! 引用元 :
https://blog.findy-team.io/posts/interview_dmm_01/
© DMM.com リードタイムもよくなったし 順調に運用できている☺ リプレース大成功!!!!
© DMM.com とはならなかったorz
© DMM.com 12 リプレース後に抱えた課題 • PRの中身を見るとバグ修正対応が多いと気づき始める... • バグ修正PRも集計対象だったため、リードタイムはよく見えていた
© DMM.com なぜバグが多かった?
© DMM.com ソースコードのあちこちにビジネスロジックが混在
© DMM.com 15 ソースコードのあちこちにビジネスロジックが混在 • フレームワーク(Gin)依存でのリクエストパラメータの細かい制御🤔 リンクエストパラメータのbind時に文字数チェック
© DMM.com 16 ソースコードのあちこちにビジネスロジックが混在 • MVCにおけるController層での細かな分岐処理😵 リクエストパラメータ によって呼び出すサービス を変えている レスポンスを返す直前で分岐
処理...
© DMM.com 17 ソースコードのあちこちにビジネスロジックが混在 • データアクセス層でのまさかまさかのSQL文を利用した分岐処理😔
© DMM.com 18 ソースコードのあちこちにビジネスロジックが混在 • どこかを修正すれば他のどこかでバグが発生 • 検証作業やバグ修正対応で時間が取られて新規開発がで きない状態に...orz Controller
(ビジネスロジック) Model (ビジネスロジック) DAO (ビジネスロジック) ビジネスロジック修正 Controller (ビジネスロジック) Model (ビジネスロジック) DAO (ビジネスロジック) バグ発生 バグ発生
© DMM.com せっかくリプレースしたのに どうしてこうなった...
© DMM.com 20 設計不足 • 設計スキルの欠如 ◦ そもそもソースコードの何が悪いのか気づけていなかった • 最初に正しい設計をせずにコーディング作業を進めていた
◦ 仕様変更の度にコードがどんどん複雑化していった • バグを埋め込みやすい変更容易性が低い(品質が悪い)コード に なっていた
© DMM.com 改善に向けて
© DMM.com 22 設計のプロフェッショナルに相談 • ミノ駆動さん (@MinoDriven)に相談 • 「良いコード/悪いコードで学ぶ設計入門 」の著者
• アプリケーションアーキテクチャに精通
© DMM.com 23 設計のプロフェッショナルに相談 • 設計の学び直し ◦ ミノ駆動さんのレクチャーを受けながら設計を再学習 ◦ システム改善後も、設計の良し悪しを判断できる力を習得したい
• ソースコードのリアーキテクチャ ◦ MVCからドメインモデリングを活用したレイヤードアーキテクチャへ移行 ▪ MVCだとデータ更新時の制約がコントローラーやモデルに分散しやすい ◦ 変更容易性が高いコードを目指すならば時間をかけてでもリアーキテクチャした方 がいいと判断 以下の活動を通して品質の高いシステム再構築することになった
© DMM.com 24 設計の学び直し • ミノ駆動さんの著書や社内向け設計ガイ ドラインを元にバグが発生しにくくなる設 計を学んだ ◦ 設計の基礎的なことを重点的に学
んだ ▪ カプセル化 ▪ 関心の分離 ▪ 単一責任の原則 ▪ etc ◦ その上でDDDなど応用的なことも学 んだ
© DMM.com 25 リアーキテクチャ • その後以下の流れでリアーキテクチャを進めた ◦ ユースケースの洗い出し ◦ ドメインモデリング
▪ イベントストーミングによるモデルの可視化 ◦ ドメインモデルを元に実装
© DMM.com 26 リアーキテクチャ • その後以下の流れでリアーキテクチャを進めた ◦ ユースケースの洗い出し ◦ ドメインモデリング
▪ イベントストーミングによるモデルの可視化 ◦ ドメインモデルを元に実装 ここから実例をまじえた少しだけ細かい話をしていきます🙇
© DMM.com ユースケース洗い出し • 誰が何をやりたいかを洗い出す • 要件漏れがないようにできる限りステークホルダーを集めて実施 ex.管理者目線でのヘルプのカテゴリーについて考えてみる 27
© DMM.com ユースケース洗い出し • カテゴリーだけでも作成、並べ替え、編集 ...などなど多くのユースケースがある • ただし、データが壊れるのは基本的には更新系なので参照系のユースケースは考えない 28
© DMM.com ドメインモデリングを実施 カテゴリー作成のモデリングについて考えてみる • カテゴリーだけでも作成、並べ替え、編集 ...などなど多くのユースケースがある • ただし、データが壊れるのは基本的には更新系なので参照系のユースケースは考えない 29
© DMM.com 30 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 ex.カテゴリーの作成
© DMM.com 31 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 ex.カテゴリーの作成
© DMM.com 32 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 • モデルに対応する箱を準備 ◦
この部分が実際にコード化される ex.カテゴリーの作成
© DMM.com 33 ドメインモデリングを実施 イベントストーミングと呼ばれる手法でドメインモデルの可視化 • 付箋でイベントや時系列を整理 • モデルに対応する箱を準備 ◦
この部分が実際にコードかされる • データを壊さないための制約(ビジネスロ ジック)を検討 ◦ どうやったらデータを壊せるか、 ユーザーが困るかを考える ex.カテゴリーの作成
© DMM.com 34 モデルや制約をコードに落とし込む
© DMM.com 35 モデルや制約をコードに落とし込む Category作成用モデル
© DMM.com 36 モデルや制約をコードに落とし込む Category作成用モデルはTitleという値を持つ
© DMM.com 37 モデルや制約をコードに落とし込む Titleの生成用関数を用意 生成や更新するときは制約に注意!!
© DMM.com 38 モデルや制約をコードに落とし込む 生成したTitleなどを利用してCategory作成用モデルの生成関数を準備
© DMM.com 39 モデルや制約をコードに落とし込む このように制約を守って安全に生成されたモデルが DBに保存される(永続化)
© DMM.com 40 コード改善後 • ビジネスロジック(制約)がドメインモデルに集約された Controller (ビジネスロジック) Model (ビジネスロジック)
DAO (ビジネスロジック) ドメインモデル (ビジネスロジック) バラバラだったビジネスロジックを ドメインモデルに集約
© DMM.com 41 コード改善後 • ビジネスロジック(制約)がドメインモデルに集約された • もし仕様変更があった場合でも修正範囲はモデル内にとどまる • 最初に制約を意識してドメインモデリングをしたので可能な限りバグを減
らせる interface (リクエスト制御) infrastructure (データ永続化) ドメインモデル (ビジネスロジック) 修正 interface (リクエスト制御) infrastructure (DB永続化) ドメインモデル (ビジネスロジック) 影響なし 影響なし
© DMM.com なんとかバグを埋めにくく変更容易性が高いコード を実装(設計)できるようになった!
© DMM.com 43 リアーキテクチャ後は... 様々な成績が改善傾向 改善前(半年間) 改善後(半年間) Findy Team+の詳細比較
© DMM.com 44 リアーキテクチャ後は... 特にレビュー時間(レビューから承認までの時間)が改善
© DMM.com 45 リアーキテクチャ後は... レビュー時間の改善に伴いリードタイムも改善 改善前 改善後 Findy Team+のリードタイムサマリ
© DMM.com リアーキテクチャで 開発生産性が上がってた
© DMM.com 47 レビュー時間が改善した要因 • シンプルにコードの可読性が上がった • ビジネスロジックがモデルに集約されて理解しやすくなった • コード実装前にモデリングを行うことでレビュワーを含むチーム全
体での仕様の理解が早くなった
© DMM.com 48 まとめ • バグを減らすためにリアーキテクチャを実施し、コードの品質が向上した • その結果、開発生産性が向上し、特にレビュー時間の短縮が顕著だった • レビュー時間はコード品質の一つの定量的な指標になり得ると改めて実感
• 反省点としてそのようなリアーキテクチャの効果を、事前に定量的に予測・検討し ながら進めるべきだったかもしれない... • 今後はFindy Team+などを活用し、コードだけでなくチーム全体の改善目標を定 量的に設定していきたい