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
100
Other Decks in Technology
See All in Technology
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
1.3k
robocopy の怖い話/scary-story-about-robocopy
emiki
0
420
AI駆動開発 with MixLeap Study【大阪支部 #3】
lycorptech_jp
PRO
0
290
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
1.4k
AI人生苦節10年で会得したAIがやること_人間がやること.pdf
shibuiwilliam
1
250
興味の胞子を育て 業務と技術に広がる”きのこ力”
fumiyasac0921
0
500
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
100
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
250
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
320
生成AIによる情報システムへのインパクト
taka_aki
1
230
2025新卒研修・HTML/CSS #弁護士ドットコム
bengo4com
3
4.4k
20250728 MCP, A2A and Multi-Agents in the future
yoshidashingo
1
180
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
524
40k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
How to Ace a Technical Interview
jacobian
278
23k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
182
54k
The Cost Of JavaScript in 2023
addyosmani
51
8.7k
Making Projects Easy
brettharned
117
6.3k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
A designer walks into a library…
pauljervisheath
207
24k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Faster Mobile Websites
deanohume
308
31k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
530
Bash Introduction
62gerente
613
210k
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+などを活用し、コードだけでなくチーム全体の改善目標を定 量的に設定していきたい