---
title: QualityとDeliveryを両立させるために僕らがやったこと #genbadeddd #mixleap
tags:  #genbadeddd #mixleap  
author: [Yahoo!デベロッパーネットワーク](https://www.docswell.com/user/ydnjp)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V4EQPQZWJP.jpg?width=480
description: 2019/8/31 にヤフー大阪オフィスで開催したドメイン駆動設計（DDD）のカンファレンスで発表したスライドです。技術刷新の肝は、数多の制約の中Qualityの高いものを作り維持し続けることだと考えております。実際に数百人月規模のシステムの刷新を推進し、ぶつかった壁とそれをどう乗り越えたかを3つのパートで説明させて頂きます。 1) 設計の工夫 2) 登り方の工夫 3) 非エンジニアの同意と承認の工夫  「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス」 https://yahoo-osaka.connpass.com/event/138020/ 「設計の楽しさを伝えたい！「Mix Leap Study 特別編 レガシーをぶっつぶせ。現場でDDD！」を開催しました」 https://techblog.yahoo.co.jp/entry/20190909749503/
published: November 11, 19
canonical: https://www.docswell.com/s/ydnjp/ZEJM65-2019-11-11-122403
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V4EQPQZWJP.jpg)

レガシーを
ぶっつぶせ。
QualityとDeliveryを両⽴させ
るために僕らがやったこと
Yahoo! Japan / Engineer / 関⼝ 岳志


# Page. 2

![Page Image](https://bcdn.docswell.com/page/DKJ4YN31E1.jpg)

レガシーを
ぶっつぶせ。
Quality
制約
可⽤性
予算
パフォーマンス
⼯期
保守性
技術⼒
...
...
「制約の中Quality⾼いものを作り維持し続けること」


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PLE16515JG.jpg)

レガシーを
ぶっつぶせ。
1. 設計の⼯夫 [Q]
2. 登り⽅の⼯夫 [Q&amp;D]
3. ⾮エンジニアの同意と承認の⼯夫 [D]


# Page. 4

![Page Image](https://bcdn.docswell.com/page/8GEWW58WE2.jpg)

レガシーを
ぶっつぶせ。
設計の⼯夫
アプリケーションアーキテクチャをどうしたか
ドメイン層のコンポーネント分割はどうしたか


# Page. 5

![Page Image](https://bcdn.docswell.com/page/W47Z5N82E3.jpg)

レガシーを
ぶっつぶせ。
ForefrontGW
JobScheduler
UI/UX
アーキテクチャのコンセプト
UI/UXとAPIを
きれいな状態で保つ！
APIGW
MicroserviceAPI
Orchestration
API
Integration
Data


# Page. 6

![Page Image](https://bcdn.docswell.com/page/KYJ698K6JV.jpg)

レガシーを
ぶっつぶせ。
Itʼs 現⾏
Web
⼤量のビジネスロジック
API
役割が重複したIF
役割が過多なIF
全部取れるIF が乱⽴
Data
荒れたデータ構造
キャッシュの乱⽴


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5GJ5N9P5E4.jpg)

レガシーを
ぶっつぶせ。
まずはAPIをきれいに
APIのあるべき姿とは
Web
DDDのドメイン層
ビジネスロジックが集約
API
様々なところから呼ばれる
⾼凝集・疎結合で⾼い再利⽤性
Data


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4LE32Y35J5.jpg)

レガシーを
ぶっつぶせ。
実際の刷新の進め⽅のイメージ
web-現⾏プランページ
加⼯
統合
計算
ドメイン単位に
分割して抽出
api-プラン
api-プランA
api-プラン部屋
api-プランB
api-全部取れる
api-部屋


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V8EDZ54Y7G.jpg)

レガシーを
ぶっつぶせ。
WebとAPIの乖離
web-在庫ページ
統合・加⼯
api-プラン
api-部屋
api-プラン部屋


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4V7PDGM278.jpg)

レガシーを
ぶっつぶせ。
そのためにこうする
Web
Web
Orchestration
API
Data
API
Data


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L2JV169X7Q.jpg)

レガシーを
ぶっつぶせ。
Orchestration
web-在庫ページ
統合・加⼯
orc-在庫
api-プラン
api-部屋
api-プラン部屋


# Page. 12

![Page Image](https://bcdn.docswell.com/page/Z5EG2NZREL.jpg)

レガシーを
ぶっつぶせ。
これでWebとAPIがきれいに
UIUX
Web
Orchestration
API
API
Data
Data


# Page. 13

![Page Image](https://bcdn.docswell.com/page/V4JQPQLY7P.jpg)

レガシーを
ぶっつぶせ。
APIが荒れたDataの影響を受ける
データ定義が荒れているため
UIUX
それを操作するAPIが腐敗する
具体的にはJavaでいう
Orchestration
Repositoryパッケージ
API
Data


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DK74YNDZJ1.jpg)

レガシーを
ぶっつぶせ。
先にDataを整理するのはリスク
api-プラン
api-部屋
部屋TBL
部屋TBL
プランTBL
プランTBL
プラン系TBL
プラン系TBL
プラン系TBL
⾊々混ざった
TBL
キャッシュ
プランTBL
プランTBL
プランTBL
プランTBL
⾊々混ざった
TBL
プラン系TBL
プラン系TBL
プラン系TBL
部屋系TBL


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PLJ165ZD7G.jpg)

レガシーを
ぶっつぶせ。
そのためにこうする
UIUX
Web
Orchestration
API
API
Integration
Data
Data


# Page. 16

![Page Image](https://bcdn.docswell.com/page/8GJWW598J2.jpg)

レガシーを
ぶっつぶせ。
Integration
api-プラン
/plans/
api-部屋
/rooms/
/room/{id}
/plan/{id}
itg-部屋
itg-プラン
プラン系TBL
プラン系TBL
プラン系TBL
⾊々混ざった
TBL
キャッシュ
プランTBL
プランTBL
プランTBL
プランTBL
⾊々混ざった
TBL
プラン系TBL
プラン系TBL
プラン系TBL
部屋系TBL


# Page. 17

![Page Image](https://bcdn.docswell.com/page/W4EZ5N99J3.jpg)

レガシーを
ぶっつぶせ。
GW系
ForefrontGW
Web
UIUX
APIGW
Orchestration
API
API
Integration
Data
Data


# Page. 18

![Page Image](https://bcdn.docswell.com/page/KY7698KD7V.jpg)

レガシーを
ぶっつぶせ。
という感じでここに⾏き着いた
JobSchedulerはジョブ管理
ForefrontGW
JobScheduler
UI/UX
APIGW
MicroserviceAPI
Orchestration
API
Integration
Data


# Page. 19

![Page Image](https://bcdn.docswell.com/page/5G75N9P8J4.jpg)

レガシーを
ぶっつぶせ。
続いてDDDの話..


# Page. 20

![Page Image](https://bcdn.docswell.com/page/V9J2526VJR.jpg)

レガシーを
ぶっつぶせ。
コンポーネント分割イメージ
UI/UX
商材
Orchestration
My
社内ツール
画⾯単位
など
API
商材
予約
ユーザ
Integration
商材
Data
販促
Infrastructure
など
コード
マスタ
ドメイン単位
DDD
データ単位
など


# Page. 21

![Page Image](https://bcdn.docswell.com/page/5DEYKY9Q7M.jpg)

レガシーを
ぶっつぶせ。
分割の流れ
0) インプット
1) 対象コンポーネントとメンバーを決定
2) 関⼼事の各⾃理解
3) チームの⾔語基盤を作る
4) ⾻格を説明する
5) モデルと実装を紐付ける


# Page. 22

![Page Image](https://bcdn.docswell.com/page/2VJNRPL2E8.jpg)

レガシーを
ぶっつぶせ。
0) インプット
書籍
DDDワークショップ参加


# Page. 23

![Page Image](https://bcdn.docswell.com/page/GYE9M34DJ3.jpg)

レガシーを
ぶっつぶせ。
1) 対象コンポーネントとメンバーを決定
対象は「予約」
メンバーはDev3名、Dir1名、Cre2名
DDDをある程度理解しているのは⾃分のみ
概念や分割の流れを説明


# Page. 24

![Page Image](https://bcdn.docswell.com/page/5GE8LMQ5JD.jpg)

レガシーを
ぶっつぶせ。
2) 関⼼事の各⾃理解
※画像はイメージ


# Page. 25

![Page Image](https://bcdn.docswell.com/page/MLELL3X3ER.jpg)

レガシーを
ぶっつぶせ。
3) チームの⾔語基盤を作る
※画像はイメージ


# Page. 26

![Page Image](https://bcdn.docswell.com/page/54JMMDLMJW.jpg)

レガシーを
ぶっつぶせ。
4) ⾻格を説明する
※画像はイメージ


# Page. 27

![Page Image](https://bcdn.docswell.com/page/ZPJRV4KLE9.jpg)

レガシーを
ぶっつぶせ。
5) モデルと実装を紐付ける
※画像はイメージ


# Page. 28

![Page Image](https://bcdn.docswell.com/page/NPEXZ256JX.jpg)

レガシーを
ぶっつぶせ。
学び
インプットは付け焼き刃じゃ無理
予約が難しすぎた
モチベーションや向き不向きの差


# Page. 29

![Page Image](https://bcdn.docswell.com/page/63EK8M6GJD.jpg)

レガシーを
ぶっつぶせ。
設計の⼯夫まとめ
レイヤードは必ずやる⼯程なのでご参考に
この設計で何がどうよくなったかは別のパートで説明


# Page. 30

![Page Image](https://bcdn.docswell.com/page/4L732Y65E5.jpg)

レガシーを
ぶっつぶせ。
登り⽅の⼯夫
安全に確実に登頂完了するためにどう進めたか
その中でのハマりポイント、学び


# Page. 31

![Page Image](https://bcdn.docswell.com/page/V87DZ5VYJG.jpg)

レガシーを
ぶっつぶせ。
⼀括全⾯刷新はやらない
○：製造コスト”だけ”は少ない
✕：品質的なリスク
✕：⼯期的なリスク
✕：案件Goを通せない
and 案件特質上失敗したら⼆度とできない..


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4VJPDGV2J8.jpg)

レガシーを
ぶっつぶせ。
段階的な刷新の流れ
LB
LB
全て対応
品質を満たせば残りを対応開始
実績ができた現⾏コンポーネントは削除
スモールスタートで刷新
並⾏稼動して検証
現⾏システム


# Page. 33

![Page Image](https://bcdn.docswell.com/page/L2EV16ZXJQ.jpg)

レガシーを
ぶっつぶせ。
スモールスタートどうやったか
トラベルのMyページを対象
UIUX、Orc、API、Itgを刷新
⼀部現⾏APIを使⽤、Dataは現⾏を使⽤
カナリアリリースで現⾏と並⾏稼動して効果検証


# Page. 34

![Page Image](https://bcdn.docswell.com/page/Z57G2N4R7L.jpg)

レガシーを
ぶっつぶせ。
システム構成のイメージ
/my/
Proxy
web-Myページ
10%を流す。ユーザ固定
web-Myページ
orc-My
巨⼤API
Data
api-user
api-hotel
itg-user
itg-hotel


# Page. 35

![Page Image](https://bcdn.docswell.com/page/V4EQPQGYJP.jpg)

レガシーを
ぶっつぶせ。
検証項⽬
システム視点
機能落ちしていないか
障害が発⽣しないか
保守性視点
開発効率は向上したか
※詳細別パート
メトリクス値は問題ないか
運⽤フローは回るか
パフォーマンスに問題ないか
障害対応フローは回るか
など
など


# Page. 36

![Page Image](https://bcdn.docswell.com/page/DKJ4YN5ZE1.jpg)

レガシーを
ぶっつぶせ。
〜検証完了
/my/
Proxy
web-Myページ
100%を流す
web-Myページ
orc-My
巨⼤API
api-user
api-hotel
api-user, api-hotel 分
itg-user
itg-hotel
Data


# Page. 37

![Page Image](https://bcdn.docswell.com/page/PLE165WDJG.jpg)

レガシーを
ぶっつぶせ。
スモールスタートでハマったこと
暗中模索
分からないこと不安が多すぎる
ローカル開発、新⾔語、新技術、開発フローなど
仕様書の消失
正解の資料が無い！
新しいことをたくさんやりたい欲求
せっかくなので⾊々チャレンジしたい
FW、テストツール、設計思想 など


# Page. 38

![Page Image](https://bcdn.docswell.com/page/8GEWW568E2.jpg)

レガシーを
ぶっつぶせ。
暗中模索対策
中⼼的に進める⼈と壁打ち役の選定
壁打ち
技術⼒・PM⼒
サービス理解
同等の⼈


# Page. 39

![Page Image](https://bcdn.docswell.com/page/W47Z5NY9E3.jpg)

レガシーを
ぶっつぶせ。
仕様書の消失対策
DDDで書き起こすチャンスと捉える
ビジネスモデルの理解、共通認識が強⼒に出来る
改めて⾒直すことで新しい課題なども⾒つかる
ソースは画⾯、⼀部ロジック


# Page. 40

![Page Image](https://bcdn.docswell.com/page/KYJ698DDJV.jpg)

レガシーを
ぶっつぶせ。
新しいことをやりたい欲求対策
スモールスタート内で、基本的なこと＋3個まで
せっかくなので⾊々やりたくなるがグッとこらえる
ただでさえ難しいことをやっているため
Deliveryの確度を担保する


# Page. 41

![Page Image](https://bcdn.docswell.com/page/5GJ5N938E4.jpg)

レガシーを
ぶっつぶせ。
ここからは残りの刷新
LB
LB
全て対応
品質を満たせば残りを対応開始
実績ができた現⾏コンポーネントは削除
スモールスタートで刷新
並⾏稼動して検証
現⾏システム


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V9E252ZVER.jpg)

レガシーを
ぶっつぶせ。
残りの刷新で⼯夫していること
きれいを維持する
ここから⼈が増えてぐちゃぐちゃになりがち
対応コストをなるべく減らす
トータルコストをなるべく抑えたい
最終的にシステムに組織をあわせたい
憧れの逆コンウェイの法則のために


# Page. 43

![Page Image](https://bcdn.docswell.com/page/5D7YKYRQJM.jpg)

レガシーを
ぶっつぶせ。
きれいを維持する - 1
きれいを維持するWGを作る
APIの置き場所や命名等で困ったらここにチケット起案
サービス理解・技術⼒が⾼いメンバーで構成
ここでちゃんと品質をグリップする


# Page. 44

![Page Image](https://bcdn.docswell.com/page/2VENRPD278.jpg)

レガシーを
ぶっつぶせ。
きれいを維持する - 2
サービス全体のガイドラインを制定
各レイヤーのガイドラインを制定
逸脱する場合は承認フローを通す
基本的に⾮重要コンポーネントで許容
実績が確認されれば、選択肢としてガイドラインに追加


# Page. 45

![Page Image](https://bcdn.docswell.com/page/GY79M3GDE3.jpg)

レガシーを
ぶっつぶせ。
対応コストをなるべく減らす
選択と集中
全てのコンポーネントを
全⼒投球で完璧に
重要コンポーネントは完璧に
それ以外は効率的に


# Page. 46

![Page Image](https://bcdn.docswell.com/page/5G78LMV5ED.jpg)

レガシーを
ぶっつぶせ。
どう効率化しているか
コンピューティング
⾔語
関連技術
アーキテクチャ
完璧にやる
効率的にやる
現⾏から
変えない
現⾏から
変えない


# Page. 47

![Page Image](https://bcdn.docswell.com/page/ML7LL3537R.jpg)

レガシーを
ぶっつぶせ。
重要コンポーネントの定義の仕⽅
KPI貢献度 &amp; 保守コスト が⾼いものが重要
斜陽だがKPI貢献しているもの＝効率的
斜陽でKPI貢献がなくなる＝クローズ
⼤きな投資を予定しているものは除外


# Page. 48

![Page Image](https://bcdn.docswell.com/page/54EMMD3MEW.jpg)

レガシーを
ぶっつぶせ。
最終的にシステムに組織をあわせたい
「システムにあった組織に再編成」が最終⽬標
現実的な個数にコンポーネント分割する必要がある
特定のコンポーネントが⼀⼈しか知らない状態は避ける
各レイヤーでプロフェッショナルが欲しい


# Page. 49

![Page Image](https://bcdn.docswell.com/page/ZPERV4QL79.jpg)

レガシーを
ぶっつぶせ。
登り⽅の⼯夫まとめ
難度が⾼いので⼯夫して安全に登る


# Page. 50

![Page Image](https://bcdn.docswell.com/page/NP7XZ2R6EX.jpg)

レガシーを
ぶっつぶせ。
⾮エンジニアの同意と承認の⼯夫
決済責任者やエンジニア以外の職種へ
伝え⽅、巻き込み⽅


# Page. 51

![Page Image](https://bcdn.docswell.com/page/637K8MRGED.jpg)

レガシーを
ぶっつぶせ。
ビジネスメリットで語るべき
サービスを
適切な単位で分割できる
各コンポーネントが
⾼凝集・疎結合になる
変化に強くなる
サービスKPIにどう貢献するか


# Page. 52

![Page Image](https://bcdn.docswell.com/page/4LJ32Y8575.jpg)

レガシーを
ぶっつぶせ。
実績値で語るべき
概算値
外部引⽤
⼀般論
実績値
(開発効率の
向上度合)


# Page. 53

![Page Image](https://bcdn.docswell.com/page/V8JDZ5MYEG.jpg)

レガシーを
ぶっつぶせ。
承認どこでとるか
ここ と ここ
LB
全て対応
LB
品質を満たせば他のコンポーネントも対応開始
実績ができたコンポーネントは削除
特定コンポーネントを刷新
並⾏稼動して検証
現⾏システム


# Page. 54

![Page Image](https://bcdn.docswell.com/page/4VEPDGR2E8.jpg)

レガシーを
ぶっつぶせ。
スモールスタート前の承認のとり⽅
ビジネスメリット x ⼀般論でゴリ押し
スモールスタートして効果検証してFBする事も約束
Y!は全社の取り組みで技術刷新をしているので追い⾵
⼯数は全体のこれだけっていうのも強調


# Page. 55

![Page Image](https://bcdn.docswell.com/page/L27V16RXEQ.jpg)

レガシーを
ぶっつぶせ。
実績値のとり⽅
刷新前後のシステム上で全く同じPDCA案件を開発
全開発⾏程のコストを⽐較


# Page. 56

![Page Image](https://bcdn.docswell.com/page/Z5JG2NMRJL.jpg)

レガシーを
ぶっつぶせ。
フェーズ
現⾏
刷新後
勝ち負け


# Page. 57

![Page Image](https://bcdn.docswell.com/page/V47QPQRYEP.jpg)

レガシーを
ぶっつぶせ。
結果のサマリ
Good
全⾏程で減少
特にテストが減少
副次効果で⼯期短縮
Bad
詳細設計増加
UT増加
合算で28%効率向上


# Page. 58

![Page Image](https://bcdn.docswell.com/page/DKE4YN8Z71.jpg)

レガシーを
ぶっつぶせ。
⾮エンジニア向けにパッケージング
開発効率 → サービスの巡航速度
PDCAサイクルの速度
128%向上
10回打席に⽴っていたなら13回になる
⼯期も縮まるのでより早くリリースが出来る
⼤規模開発ならより効果が出る⾒込み


# Page. 59

![Page Image](https://bcdn.docswell.com/page/PL71652DEG.jpg)

レガシーを
ぶっつぶせ。
残りの承認のとり⽅
ビジネスメリット x 実績値
これで残りを進めていいかの承認を取る
問題なければ残りの⼯数を精緻⾒積もり、スケジュール
策定
この量を取りに⾏くのでしっかり


# Page. 60

![Page Image](https://bcdn.docswell.com/page/8G7WW5R872.jpg)

レガシーを
ぶっつぶせ。
⾮エンジニアの同意と承認の⼯夫のまとめ
ビジネスメリットと実績値で語る


# Page. 61

![Page Image](https://bcdn.docswell.com/page/W4JZ5NR973.jpg)

レガシーを
ぶっつぶせ。
EOP
良い刷新ライフを！


