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
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Search
Rakus_Dev
October 06, 2022
Technology
0
1.8k
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
Rakus_Dev
October 06, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
【TECH PLAY Product Management Conference】AI時代にどんなPdMが求められているのか? 〜私たちが見てきたリアルから考える〜 / techplay-pdmconf-ai
rakus_dev
0
210
『楽楽電子保存』開発チームが挑む「AI駆動開発」の全貌 / rakustechcon2025-rakurakudenshihozon
rakus_dev
1
530
数字と感情で語るスクラム導入効果。『楽楽勤怠』開発チームの変革の軌跡 / rakustechcon2025-rakurakukintai
rakus_dev
0
520
分割と統合で学んだサイロ突破術—『楽楽販売』開発組織10年の軌跡と持続的成長の仕組み / rakustechcon2025-rakurakuhanbai
rakus_dev
0
500
『メールディーラー』へのAI機能実装─"20年"の歴史を持つ製品への導入プロセス / rakustechcon2025-maildealer
rakus_dev
0
500
新サービス『楽楽請求』!何を作るかより"なぜ作るか" 顧客価値から逆算する開発現場のリアル / rakustechcon2025-rakurakuseikyu
rakus_dev
0
510
なぜ、成熟市場で"売上120%成長"を続けられるのか?『配配メール』の顧客志向型プロダクト開発戦略 / rakustechcon2025-haihaimail
rakus_dev
0
490
『楽楽精算』15年の進化と未来への挑戦 〜経理の"楽"から、すべての働く人の"楽"へ〜 / rakustechcon2025-rakurakuseisan
rakus_dev
0
520
AI時代にプロダクトマネジメントは必要だけどプロダクトマネージャーは役割として必要なのだろうか? / Product Management in the Age of AI
rakus_dev
0
230
Other Decks in Technology
See All in Technology
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
3
260
知られざるprops命名の慣習 アクション編
uhyo
11
2.5k
帳票Vibe Coding
terurou
0
140
マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ
grimoh
1
240
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
2
200
ABEMAにおける 生成AI活用の現在地 / The Current Status of Generative AI at ABEMA
dekatotoro
0
660
EKS Pod Identity における推移的な session tags
z63d
1
200
ソフトウェア エンジニアとしての 姿勢と心構え
recruitengineers
PRO
4
760
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
GitHub Copilot coding agent を推したい / AIDD Nagoya #1
tnir
3
4.6k
JOAI発表資料 @ 関東kaggler会
joai_committee
1
340
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
6
620
Featured
See All Featured
Making Projects Easy
brettharned
117
6.3k
Optimizing for Happiness
mojombo
379
70k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Speed Design
sergeychernyshev
32
1.1k
Being A Developer After 40
akosma
90
590k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Why Our Code Smells
bkeepers
PRO
338
57k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Transcript
#RAKUSMeetup ©2022 RAKUS Co., Ltd. レガシーになりゆく システムとの向き合い方 株式会社ラクス 開発本部 東京開発統括部
楽楽勤怠開発部 楽楽勤怠開発1課 井上 大輔
#RAKUSMeetup 目次 - 自己紹介 - 楽楽勤怠サービス概要 - レガシーとは - 現在の課題
- 課題に対する施策 - レガシーの進行を止めるために - まとめ
#RAKUSMeetup - 井上 大輔 / Daisuke Inoue - 経歴 -
2014年 : 銀行案件の孫請SE - 2017年 : 中堅企業で受託開発 - 2017年 : ナビゲーション企業で自社プロダクト開発 - 2021年 : 通信事業会社で自社プロダクト開発 - 2021年 : 株式会社ラクスで楽楽勤怠開発 - 現在 - 楽楽勤怠バックエンド開発に従事 - 勤怠計算チームに所属 自己紹介
#RAKUSMeetup 楽楽勤怠 - サービス概要 - 2020年10月1日リリース - クラウド上で勤怠管理ができるシステム
#RAKUSMeetup 楽楽勤怠システム構成 - フロントエンド - Vue.js, TypeScript - バックエンド -
SpringBoot, Java, PostgreSQL
#RAKUSMeetup 本日のお題 - レガシーの進行を食い止めたい - リリースから約2年 - まだ食い止められるはず - どう食い止めていくのか?
#RAKUSMeetup レガシーとは - レガシーコードとは、単にテストのないコード - テストのないコードは悪いコードである。テストがあれば、検証し ながらコードの動きを素早く変更することができる。テストがなけ れば、コードが良くなっているか悪くなっているかが本当にはわ からない。
#RAKUSMeetup レガシーの何がいけないのか? - 事業成長のために機能がまだまだ足りない - 必須機能、競合他社機能、差別化機能 - 一定の品質を保ち、速度を下げずに開発しなければならない - テストがないと品質を担保できない
- テストがないと仕様が把握できず、開発に時間がかかる
#RAKUSMeetup なぜレガシーになりつつあるの? - 楽楽勤怠では早期PMF実現のために早急な機能開発 - PMF : Product Market Fit
- カスタマー(顧客)の課題を満足させる製品を提供し、 それが適切な市場に受け入れられている状態 - システム設計者が退職し、システムの複雑化が加速 - プロダクト改善への工数が取れずにいた
#RAKUSMeetup - 設計方針とアーキテクチャ - システム設計者曰く実践ドメイン駆動設計を参考に - ドメイン駆動設計 - ヘキサゴナルアーキテクチャ 現在の課題の前に
#RAKUSMeetup - 複雑なビジネス要件を 可能な限りシンプルにモデリングするために使う - ドメインエキスパートと開発者が同じ土俵に上がることで 開発者視点だけではなく業務側の視点を踏まえた ソフトウェアを作れるように - 対象ソフトウェアを理解している人が
一部の人たちだけという状態をなくす ドメイン駆動設計
#RAKUSMeetup - システムを外部と内部の2つの領域にわける - リクエストはHTTP入力ポートを経て到達し ハンドラーがアダプターとして振る舞い 処理をアプリケーションサービスに委譲 - クライアントやストレージが確定しないうちから アプリケーション全体とドメインモデルの
設計やテストが実施可能 ヘキサゴナルアーキテクチャ
#RAKUSMeetup - 初めての試み - 書籍を参考に見様見真似で実践 - 緩やかな制約のもとで開発 - 他プロダクトの思想も 思想をとりいれつつも
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup アプリケーション層からのテストのみ - 複雑なビジネス要件を満たすために 何百パターンもある秘伝のテストクラス - ドメインモデルに対する単体テストはほぼ存在しない - テストがないのでドメインモデルのアップデートに 及び腰になってしまう
- ドメイン駆動設計が実践できない
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念が存在
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - Validator、Policyなどに ビジネスロジック - Employeeは不完全体で 作成できてしまう - 設定される項目の値に対する 責務がアプリケーションサー
ビスに ビジネスロジックが他のクラスに
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - どこからでも参照更新が可能 - どこで更新されたのか追えず 影響範囲の把握が困難 - アーキテクチャテストで チェックしているが 抜け道が存在
フィールド変数がpublic
#RAKUSMeetup - ビジネスロジックがドメインモデルに存在せず 他のクラスに任せている - 貧血ドメインモデル - 独自ORMによりフィールド変数がpublic - 若手の教育観点から参考にしてほしくない
- APIインターフェースに顔を出している - アーキテクチャの考え方から外れている 依存体質なドメインモデル
#RAKUSMeetup - APIのリクエストパラメータに ドメインモデルが利用 - アプリケーション層を突き 破っており、アーキテクチャか ら外れている - ドメイン層の実装が
コントローラー層に影響 APIインターフェースにも露出
#RAKUSMeetup 現在の課題 - アプリケーション層からのテストのみ - 依存体質なドメインモデル - モデリングされていない概念
#RAKUSMeetup - アプリケーションサービス内で プリミティブ型定義の変数が 再代入されていく - 膨大な処理の中で 今この変数がどんな状態を 表しているのか追えない モデリングされていない概念
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup ドメインモデルにビジネスロジック① - 他クラスに委譲していたロジックを そのままドメインモデルに移行 - 移行したロジックに対してテストを書く - 影響範囲が少なくできそう
#RAKUSMeetup ドメインモデルにビジネスロジック② - ドメインモデルを生成する際に チェックもしてしまう - 項目に対する責務が アプリケーションサービスから ドメインモデルへ -
処理が大きく変わるので 書き換え量を鑑みて判断
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - ORMはDTOを利用するように - DataTransferObject - DBと疎結合 - ORM仕様に依存しない DTOでドメイン層とインフラ層を分離
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup - コントローラー層に新規クラス作成 - 元々利用していたドメインモデルを そのままコピー - 随時不要なロジック削除 - ドメインモデル修正による
外部影響がなくなる APIインターフェース用クラス作成
#RAKUSMeetup - アプリケーション層からのテストのみ - ドメインモデルのテストを書く - 依存体質なドメインモデル - ビジネスロジックをドメインモデルへ -
DTOを使ってドメイン層とインフラ層を切り離す - APIインターフェース用のクラスを新たに作成 - モデリングされていない概念が存在 - 状態に適切な名称をつけてモデリングし、切り出す 課題に対する施策
#RAKUSMeetup モデリングして切り出す - 項目をドメインモデルとして定義 - ビジネスロジックを切り出し ドメインモデルに移行 - 特定ドメインに対して 見通しが良くなる
- 1つずつ処理を追って 1つずつ切り出す
#RAKUSMeetup - 湧き上がる気持ちを抑えて冷静に - 全施策実践するぞ - ドメインモデル図全部書くぞ - 全書き換えしてリファクタリング -
アーキテクチャ刷新 - ドメインモデルの単体テスト全部書くぞ - 全てやると膨大なタスクで潰れちゃう レガシーの進行を止めるために
#RAKUSMeetup - 効果が大きそうなコア機能から - 小さくコツコツ着実に - まずはモデリングして切り出しテスト書く - ドメインを絞ることでドメインの理解が深まる -
既存テストはデグレチェックとして活用 - たとえ小さいドメインだとしても ドメインエキスパートや有識者とすり合わせ - ユースケース図及びドメインモデル図で俯瞰 レガシーの進行を止めるために
#RAKUSMeetup まとめ - レガシーになりつつあっても事業の歩みは止められない - 湧き上がる気持ちを抑えて冷静に - コア機能から小さくコツコツ着実に