Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
レガシーを
ぶっつぶせ。
QualityとDeliveryを両⽴させ
るために僕らがやったこと
Yahoo! Japan / Engineer / 関⼝ 岳志
レガシーを
ぶっつぶせ。
保守性
パフォーマンス
可⽤性
Quality
⼯期
予算
技術⼒
制約
... ...
「制約の中Quality⾼いものを作り維持し続けること」
レガシーを
ぶっつぶせ。
1. 設計の⼯夫 [Q]
2. 登り⽅の⼯夫 [Q&D]
3. ⾮エンジニアの同意と承認の⼯夫 [D]
レガシーを
ぶっつぶせ。
設計の⼯夫
アプリケーションアーキテクチャをどうしたか
ドメイン層のコンポーネント分割はどうしたか
レガシーを
ぶっつぶせ。
ForefrontGW
UI/UX
APIGW
Data
JobScheduler
MicroserviceAPI
Orchestration
API
Integration
アーキテクチャのコンセプト
UI/UXとA...
レガシーを
ぶっつぶせ。
Web
Itʼs 現⾏
⼤量のビジネスロジック
役割が重複したIF
役割が過多なIF
全部取れるIF が乱⽴
荒れたデータ構造
キャッシュの乱⽴
API
Data
レガシーを
ぶっつぶせ。
まずはAPIをきれいに
APIのあるべき姿とは
DDDのドメイン層
ビジネスロジックが集約
様々なところから呼ばれる
⾼凝集・疎結合で⾼い再利⽤性
Web
API
Data
レガシーを
ぶっつぶせ。
api-プラン api-部屋
実際の刷新の進め⽅のイメージ
web-現⾏プランページ
api-プランA
api-プランB api-全部取れる
api-プラン部屋
加⼯ 統合 計算
ドメイン単位に
分割して抽出
レガシーを
ぶっつぶせ。
web-在庫ページ
api-プラン api-部屋 api-プラン部屋
WebとAPIの乖離
統合・加⼯
レガシーを
ぶっつぶせ。
そのためにこうする
Orchestration
Web
API
Data
Web
API
Data
レガシーを
ぶっつぶせ。
orc-在庫
web-在庫ページ
api-プラン api-部屋 api-プラン部屋
Orchestration
統合・加⼯
レガシーを
ぶっつぶせ。
これでWebとAPIがきれいに
Orchestration
Web
API
Data
UIUX
API
Data
レガシーを
ぶっつぶせ。
APIが荒れたDataの影響を受ける
Orchestration
UIUX
API
Data
データ定義が荒れているため
それを操作するAPIが腐敗する
具体的にはJavaでいう
Repositoryパッケージ
レガシーを
ぶっつぶせ。
api-プラン api-部屋
プランTBL 部屋TBL
プランTBL
プランTBL
プランTBL
プランTBL⾊々混ざった
TBL
プラン系TBL
プラン系TBL
プラン系TBL
部屋系TBL
プラン系TBL
プラン系...
レガシーを
ぶっつぶせ。
そのためにこうする
Orchestration
Web
API
Data
UIUX
API
Data
Integration
レガシーを
ぶっつぶせ。
api-プラン api-部屋
プランTBL
プランTBL
プランTBL
プランTBL⾊々混ざった
TBL
プラン系TBL
プラン系TBL
プラン系TBL
部屋系TBL
プラン系TBL
プラン系TBL
プラン系TBL
⾊...
レガシーを
ぶっつぶせ。
GW系
Orchestration
Web
API
Data
UIUX
API
Data
Integration
ForefrontGW
APIGW
レガシーを
ぶっつぶせ。
ForefrontGW
UI/UX
APIGW
Data
JobScheduler
MicroserviceAPI
Orchestration
API
Integration
という感じでここに⾏き着いた
JobSch...
レガシーを
ぶっつぶせ。
続いてDDDの話..
レガシーを
ぶっつぶせ。
UI/UX
Data
Orchestration
API
Integration
商材 My 社内ツール
など
商材 予約 ユーザ Infrastructure
など
など
商材 販促
コード
マスタ
画⾯単位
ドメイ...
レガシーを
ぶっつぶせ。
0) インプット
1) 対象コンポーネントとメンバーを決定
2) 関⼼事の各⾃理解
3) チームの⾔語基盤を作る
4) ⾻格を説明する
5) モデルと実装を紐付ける
分割の流れ
レガシーを
ぶっつぶせ。
書籍
DDDワークショップ参加
0) インプット
レガシーを
ぶっつぶせ。
対象は「予約」
メンバーはDev3名、Dir1名、Cre2名
DDDをある程度理解しているのは⾃分のみ
概念や分割の流れを説明
1) 対象コンポーネントとメンバーを決定
レガシーを
ぶっつぶせ。
2) 関⼼事の各⾃理解
※画像はイメージ
レガシーを
ぶっつぶせ。
3) チームの⾔語基盤を作る
※画像はイメージ
レガシーを
ぶっつぶせ。
4) ⾻格を説明する
※画像はイメージ
レガシーを
ぶっつぶせ。
5) モデルと実装を紐付ける
※画像はイメージ
レガシーを
ぶっつぶせ。
インプットは付け焼き刃じゃ無理
予約が難しすぎた
モチベーションや向き不向きの差
学び
レガシーを
ぶっつぶせ。
設計の⼯夫まとめ
レイヤードは必ずやる⼯程なのでご参考に
この設計で何がどうよくなったかは別のパートで説明
レガシーを
ぶっつぶせ。
登り⽅の⼯夫
安全に確実に登頂完了するためにどう進めたか
その中でのハマりポイント、学び
レガシーを
ぶっつぶせ。
○:製造コスト”だけ”は少ない
✕:品質的なリスク
✕:⼯期的なリスク
✕:案件Goを通せない
and 案件特質上失敗したら⼆度とできない..
⼀括全⾯刷新はやらない
レガシーを
ぶっつぶせ。
スモールスタートで刷新
並⾏稼動して検証
品質を満たせば残りを対応開始
実績ができた現⾏コンポーネントは削除
全て対応
現⾏システム
段階的な刷新の流れ
LB
LB
レガシーを
ぶっつぶせ。
スモールスタートどうやったか
トラベルのMyページを対象
UIUX、Orc、API、Itgを刷新
⼀部現⾏APIを使⽤、Dataは現⾏を使⽤
カナリアリリースで現⾏と並⾏稼動して効果検証
レガシーを
ぶっつぶせ。
システム構成のイメージ
orc-My
web-Myページ
巨⼤API
web-Myページ
api-user
Data
api-hotel
itg-user itg-hotel
Proxy
/my/
10%を流す。ユーザ...
レガシーを
ぶっつぶせ。
検証項⽬
システム視点
機能落ちしていないか
障害が発⽣しないか
メトリクス値は問題ないか
パフォーマンスに問題ないか
など
保守性視点
開発効率は向上したか
※詳細別パート
運⽤フローは回るか
障害対応フローは回るか...
レガシーを
ぶっつぶせ。
〜検証完了
orc-My
web-Myページ
巨⼤API
web-Myページ
api-user
Data
api-hotel
itg-user itg-hotel
Proxy
/my/
100%を流す
api-user...
レガシーを
ぶっつぶせ。
スモールスタートでハマったこと
暗中模索
分からないこと不安が多すぎる
ローカル開発、新⾔語、新技術、開発フローなど
仕様書の消失
正解の資料が無い!
新しいことをたくさんやりたい欲求
せっかくなので⾊々チャレンジした...
レガシーを
ぶっつぶせ。
技術⼒・PM⼒
サービス理解
同等の⼈
壁打ち
中⼼的に進める⼈と壁打ち役の選定
暗中模索対策
レガシーを
ぶっつぶせ。
仕様書の消失対策
DDDで書き起こすチャンスと捉える
ビジネスモデルの理解、共通認識が強⼒に出来る
改めて⾒直すことで新しい課題なども⾒つかる
ソースは画⾯、⼀部ロジック
レガシーを
ぶっつぶせ。
新しいことをやりたい欲求対策
スモールスタート内で、基本的なこと+3個まで
せっかくなので⾊々やりたくなるがグッとこらえる
ただでさえ難しいことをやっているため
Deliveryの確度を担保する
レガシーを
ぶっつぶせ。
スモールスタートで刷新
並⾏稼動して検証
品質を満たせば残りを対応開始
実績ができた現⾏コンポーネントは削除
全て対応
現⾏システム
ここからは残りの刷新
LB
LB
レガシーを
ぶっつぶせ。
残りの刷新で⼯夫していること
きれいを維持する
ここから⼈が増えてぐちゃぐちゃになりがち
対応コストをなるべく減らす
トータルコストをなるべく抑えたい
最終的にシステムに組織をあわせたい
憧れの逆コンウェイの法則のために
レガシーを
ぶっつぶせ。
きれいを維持する - 1
きれいを維持するWGを作る
APIの置き場所や命名等で困ったらここにチケット起案
サービス理解・技術⼒が⾼いメンバーで構成
ここでちゃんと品質をグリップする
レガシーを
ぶっつぶせ。
きれいを維持する - 2
サービス全体のガイドラインを制定
各レイヤーのガイドラインを制定
逸脱する場合は承認フローを通す
基本的に⾮重要コンポーネントで許容
実績が確認されれば、選択肢としてガイドラインに追加
レガシーを
ぶっつぶせ。
選択と集中
重要コンポーネントは完璧に
それ以外は効率的に
全てのコンポーネントを
全⼒投球で完璧に
対応コストをなるべく減らす
レガシーを
ぶっつぶせ。
どう効率化しているか
コンピューティング ⾔語 関連技術 アーキテクチャ
完璧にやる
効率的にやる 現⾏から
変えない
現⾏から
変えない
レガシーを
ぶっつぶせ。
重要コンポーネントの定義の仕⽅
KPI貢献度 & 保守コスト が⾼いものが重要
斜陽だがKPI貢献しているもの=効率的
斜陽でKPI貢献がなくなる=クローズ
⼤きな投資を予定しているものは除外
レガシーを
ぶっつぶせ。
最終的にシステムに組織をあわせたい
「システムにあった組織に再編成」が最終⽬標
現実的な個数にコンポーネント分割する必要がある
特定のコンポーネントが⼀⼈しか知らない状態は避ける
各レイヤーでプロフェッショナルが欲しい
レガシーを
ぶっつぶせ。
登り⽅の⼯夫まとめ
難度が⾼いので⼯夫して安全に登る
レガシーを
ぶっつぶせ。
⾮エンジニアの同意と承認の⼯夫
決済責任者やエンジニア以外の職種へ
伝え⽅、巻き込み⽅
レガシーを
ぶっつぶせ。
サービスKPIにどう貢献するか
サービスを
適切な単位で分割できる
各コンポーネントが
⾼凝集・疎結合になる
変化に強くなる
ビジネスメリットで語るべき
レガシーを
ぶっつぶせ。
実績値
(開発効率の
向上度合)
概算値
外部引⽤
⼀般論
実績値で語るべき
レガシーを
ぶっつぶせ。
LB
特定コンポーネントを刷新
並⾏稼動して検証
品質を満たせば他のコンポーネントも対応開始
実績ができたコンポーネントは削除
全て対応
現⾏システム
承認どこでとるか
LBここ と ここ
レガシーを
ぶっつぶせ。
スモールスタート前の承認のとり⽅
ビジネスメリット x ⼀般論でゴリ押し
スモールスタートして効果検証してFBする事も約束
Y!は全社の取り組みで技術刷新をしているので追い⾵
⼯数は全体のこれだけっていうのも強調
レガシーを
ぶっつぶせ。
実績値のとり⽅
刷新前後のシステム上で全く同じPDCA案件を開発
全開発⾏程のコストを⽐較
レガシーを
ぶっつぶせ。
フェーズ 現⾏ 刷新後 勝ち負け
レガシーを
ぶっつぶせ。
Good
全⾏程で減少
特にテストが減少
副次効果で⼯期短縮
Bad
詳細設計増加
UT増加
結果のサマリ
合算で28%効率向上
レガシーを
ぶっつぶせ。
開発効率 → サービスの巡航速度
PDCAサイクルの速度
128%向上
10回打席に⽴っていたなら13回になる
⼯期も縮まるのでより早くリリースが出来る
⼤規模開発ならより効果が出る⾒込み
⾮エンジニア向けにパッケージ...
レガシーを
ぶっつぶせ。
残りの承認のとり⽅
ビジネスメリット x 実績値
これで残りを進めていいかの承認を取る
問題なければ残りの⼯数を精緻⾒積もり、スケジュール
策定
この量を取りに⾏くのでしっかり
レガシーを
ぶっつぶせ。
⾮エンジニアの同意と承認の⼯夫のまとめ
ビジネスメリットと実績値で語る
レガシーを
ぶっつぶせ。
EOP
良い刷新ライフを!
Upcoming SlideShare
Loading in …5
×

QualityとDeliveryを両立させるために僕らがやったこと

1,766 views

Published on

・設計の工夫
・登り方の工夫
・非エンジニアの同意と承認の工夫
2019/5/11に行われた「レガシーをぶっつぶせ。」での講演資料です。
https://genbade-ddd.connpass.com/event/127494/

Published in: Technology
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

QualityとDeliveryを両立させるために僕らがやったこと

  1. 1. レガシーを ぶっつぶせ。 QualityとDeliveryを両⽴させ るために僕らがやったこと Yahoo! Japan / Engineer / 関⼝ 岳志
  2. 2. レガシーを ぶっつぶせ。 保守性 パフォーマンス 可⽤性 Quality ⼯期 予算 技術⼒ 制約 ... ... 「制約の中Quality⾼いものを作り維持し続けること」
  3. 3. レガシーを ぶっつぶせ。 1. 設計の⼯夫 [Q] 2. 登り⽅の⼯夫 [Q&D] 3. ⾮エンジニアの同意と承認の⼯夫 [D]
  4. 4. レガシーを ぶっつぶせ。 設計の⼯夫 アプリケーションアーキテクチャをどうしたか ドメイン層のコンポーネント分割はどうしたか
  5. 5. レガシーを ぶっつぶせ。 ForefrontGW UI/UX APIGW Data JobScheduler MicroserviceAPI Orchestration API Integration アーキテクチャのコンセプト UI/UXとAPIを きれいな状態で保つ!
  6. 6. レガシーを ぶっつぶせ。 Web Itʼs 現⾏ ⼤量のビジネスロジック 役割が重複したIF 役割が過多なIF 全部取れるIF が乱⽴ 荒れたデータ構造 キャッシュの乱⽴ API Data
  7. 7. レガシーを ぶっつぶせ。 まずはAPIをきれいに APIのあるべき姿とは DDDのドメイン層 ビジネスロジックが集約 様々なところから呼ばれる ⾼凝集・疎結合で⾼い再利⽤性 Web API Data
  8. 8. レガシーを ぶっつぶせ。 api-プラン api-部屋 実際の刷新の進め⽅のイメージ web-現⾏プランページ api-プランA api-プランB api-全部取れる api-プラン部屋 加⼯ 統合 計算 ドメイン単位に 分割して抽出
  9. 9. レガシーを ぶっつぶせ。 web-在庫ページ api-プラン api-部屋 api-プラン部屋 WebとAPIの乖離 統合・加⼯
  10. 10. レガシーを ぶっつぶせ。 そのためにこうする Orchestration Web API Data Web API Data
  11. 11. レガシーを ぶっつぶせ。 orc-在庫 web-在庫ページ api-プラン api-部屋 api-プラン部屋 Orchestration 統合・加⼯
  12. 12. レガシーを ぶっつぶせ。 これでWebとAPIがきれいに Orchestration Web API Data UIUX API Data
  13. 13. レガシーを ぶっつぶせ。 APIが荒れたDataの影響を受ける Orchestration UIUX API Data データ定義が荒れているため それを操作するAPIが腐敗する 具体的にはJavaでいう Repositoryパッケージ
  14. 14. レガシーを ぶっつぶせ。 api-プラン api-部屋 プランTBL 部屋TBL プランTBL プランTBL プランTBL プランTBL⾊々混ざった TBL プラン系TBL プラン系TBL プラン系TBL 部屋系TBL プラン系TBL プラン系TBL プラン系TBL プランTBL 部屋TBL ⾊々混ざった TBLキャッシュ 先にDataを整理するのはリスク
  15. 15. レガシーを ぶっつぶせ。 そのためにこうする Orchestration Web API Data UIUX API Data Integration
  16. 16. レガシーを ぶっつぶせ。 api-プラン api-部屋 プランTBL プランTBL プランTBL プランTBL⾊々混ざった TBL プラン系TBL プラン系TBL プラン系TBL 部屋系TBL プラン系TBL プラン系TBL プラン系TBL ⾊々混ざった TBLキャッシュ Integration /plans/ /plan/{id} itg-プラン itg-部屋 /rooms/ /room/{id}
  17. 17. レガシーを ぶっつぶせ。 GW系 Orchestration Web API Data UIUX API Data Integration ForefrontGW APIGW
  18. 18. レガシーを ぶっつぶせ。 ForefrontGW UI/UX APIGW Data JobScheduler MicroserviceAPI Orchestration API Integration という感じでここに⾏き着いた JobSchedulerはジョブ管理
  19. 19. レガシーを ぶっつぶせ。 続いてDDDの話..
  20. 20. レガシーを ぶっつぶせ。 UI/UX Data Orchestration API Integration 商材 My 社内ツール など 商材 予約 ユーザ Infrastructure など など 商材 販促 コード マスタ 画⾯単位 ドメイン単位 DDD データ単位 コンポーネント分割イメージ
  21. 21. レガシーを ぶっつぶせ。 0) インプット 1) 対象コンポーネントとメンバーを決定 2) 関⼼事の各⾃理解 3) チームの⾔語基盤を作る 4) ⾻格を説明する 5) モデルと実装を紐付ける 分割の流れ
  22. 22. レガシーを ぶっつぶせ。 書籍 DDDワークショップ参加 0) インプット
  23. 23. レガシーを ぶっつぶせ。 対象は「予約」 メンバーはDev3名、Dir1名、Cre2名 DDDをある程度理解しているのは⾃分のみ 概念や分割の流れを説明 1) 対象コンポーネントとメンバーを決定
  24. 24. レガシーを ぶっつぶせ。 2) 関⼼事の各⾃理解 ※画像はイメージ
  25. 25. レガシーを ぶっつぶせ。 3) チームの⾔語基盤を作る ※画像はイメージ
  26. 26. レガシーを ぶっつぶせ。 4) ⾻格を説明する ※画像はイメージ
  27. 27. レガシーを ぶっつぶせ。 5) モデルと実装を紐付ける ※画像はイメージ
  28. 28. レガシーを ぶっつぶせ。 インプットは付け焼き刃じゃ無理 予約が難しすぎた モチベーションや向き不向きの差 学び
  29. 29. レガシーを ぶっつぶせ。 設計の⼯夫まとめ レイヤードは必ずやる⼯程なのでご参考に この設計で何がどうよくなったかは別のパートで説明
  30. 30. レガシーを ぶっつぶせ。 登り⽅の⼯夫 安全に確実に登頂完了するためにどう進めたか その中でのハマりポイント、学び
  31. 31. レガシーを ぶっつぶせ。 ○:製造コスト”だけ”は少ない ✕:品質的なリスク ✕:⼯期的なリスク ✕:案件Goを通せない and 案件特質上失敗したら⼆度とできない.. ⼀括全⾯刷新はやらない
  32. 32. レガシーを ぶっつぶせ。 スモールスタートで刷新 並⾏稼動して検証 品質を満たせば残りを対応開始 実績ができた現⾏コンポーネントは削除 全て対応 現⾏システム 段階的な刷新の流れ LB LB
  33. 33. レガシーを ぶっつぶせ。 スモールスタートどうやったか トラベルのMyページを対象 UIUX、Orc、API、Itgを刷新 ⼀部現⾏APIを使⽤、Dataは現⾏を使⽤ カナリアリリースで現⾏と並⾏稼動して効果検証
  34. 34. レガシーを ぶっつぶせ。 システム構成のイメージ orc-My web-Myページ 巨⼤API web-Myページ api-user Data api-hotel itg-user itg-hotel Proxy /my/ 10%を流す。ユーザ固定
  35. 35. レガシーを ぶっつぶせ。 検証項⽬ システム視点 機能落ちしていないか 障害が発⽣しないか メトリクス値は問題ないか パフォーマンスに問題ないか など 保守性視点 開発効率は向上したか ※詳細別パート 運⽤フローは回るか 障害対応フローは回るか など
  36. 36. レガシーを ぶっつぶせ。 〜検証完了 orc-My web-Myページ 巨⼤API web-Myページ api-user Data api-hotel itg-user itg-hotel Proxy /my/ 100%を流す api-user, api-hotel 分
  37. 37. レガシーを ぶっつぶせ。 スモールスタートでハマったこと 暗中模索 分からないこと不安が多すぎる ローカル開発、新⾔語、新技術、開発フローなど 仕様書の消失 正解の資料が無い! 新しいことをたくさんやりたい欲求 せっかくなので⾊々チャレンジしたい FW、テストツール、設計思想 など
  38. 38. レガシーを ぶっつぶせ。 技術⼒・PM⼒ サービス理解 同等の⼈ 壁打ち 中⼼的に進める⼈と壁打ち役の選定 暗中模索対策
  39. 39. レガシーを ぶっつぶせ。 仕様書の消失対策 DDDで書き起こすチャンスと捉える ビジネスモデルの理解、共通認識が強⼒に出来る 改めて⾒直すことで新しい課題なども⾒つかる ソースは画⾯、⼀部ロジック
  40. 40. レガシーを ぶっつぶせ。 新しいことをやりたい欲求対策 スモールスタート内で、基本的なこと+3個まで せっかくなので⾊々やりたくなるがグッとこらえる ただでさえ難しいことをやっているため Deliveryの確度を担保する
  41. 41. レガシーを ぶっつぶせ。 スモールスタートで刷新 並⾏稼動して検証 品質を満たせば残りを対応開始 実績ができた現⾏コンポーネントは削除 全て対応 現⾏システム ここからは残りの刷新 LB LB
  42. 42. レガシーを ぶっつぶせ。 残りの刷新で⼯夫していること きれいを維持する ここから⼈が増えてぐちゃぐちゃになりがち 対応コストをなるべく減らす トータルコストをなるべく抑えたい 最終的にシステムに組織をあわせたい 憧れの逆コンウェイの法則のために
  43. 43. レガシーを ぶっつぶせ。 きれいを維持する - 1 きれいを維持するWGを作る APIの置き場所や命名等で困ったらここにチケット起案 サービス理解・技術⼒が⾼いメンバーで構成 ここでちゃんと品質をグリップする
  44. 44. レガシーを ぶっつぶせ。 きれいを維持する - 2 サービス全体のガイドラインを制定 各レイヤーのガイドラインを制定 逸脱する場合は承認フローを通す 基本的に⾮重要コンポーネントで許容 実績が確認されれば、選択肢としてガイドラインに追加
  45. 45. レガシーを ぶっつぶせ。 選択と集中 重要コンポーネントは完璧に それ以外は効率的に 全てのコンポーネントを 全⼒投球で完璧に 対応コストをなるべく減らす
  46. 46. レガシーを ぶっつぶせ。 どう効率化しているか コンピューティング ⾔語 関連技術 アーキテクチャ 完璧にやる 効率的にやる 現⾏から 変えない 現⾏から 変えない
  47. 47. レガシーを ぶっつぶせ。 重要コンポーネントの定義の仕⽅ KPI貢献度 & 保守コスト が⾼いものが重要 斜陽だがKPI貢献しているもの=効率的 斜陽でKPI貢献がなくなる=クローズ ⼤きな投資を予定しているものは除外
  48. 48. レガシーを ぶっつぶせ。 最終的にシステムに組織をあわせたい 「システムにあった組織に再編成」が最終⽬標 現実的な個数にコンポーネント分割する必要がある 特定のコンポーネントが⼀⼈しか知らない状態は避ける 各レイヤーでプロフェッショナルが欲しい
  49. 49. レガシーを ぶっつぶせ。 登り⽅の⼯夫まとめ 難度が⾼いので⼯夫して安全に登る
  50. 50. レガシーを ぶっつぶせ。 ⾮エンジニアの同意と承認の⼯夫 決済責任者やエンジニア以外の職種へ 伝え⽅、巻き込み⽅
  51. 51. レガシーを ぶっつぶせ。 サービスKPIにどう貢献するか サービスを 適切な単位で分割できる 各コンポーネントが ⾼凝集・疎結合になる 変化に強くなる ビジネスメリットで語るべき
  52. 52. レガシーを ぶっつぶせ。 実績値 (開発効率の 向上度合) 概算値 外部引⽤ ⼀般論 実績値で語るべき
  53. 53. レガシーを ぶっつぶせ。 LB 特定コンポーネントを刷新 並⾏稼動して検証 品質を満たせば他のコンポーネントも対応開始 実績ができたコンポーネントは削除 全て対応 現⾏システム 承認どこでとるか LBここ と ここ
  54. 54. レガシーを ぶっつぶせ。 スモールスタート前の承認のとり⽅ ビジネスメリット x ⼀般論でゴリ押し スモールスタートして効果検証してFBする事も約束 Y!は全社の取り組みで技術刷新をしているので追い⾵ ⼯数は全体のこれだけっていうのも強調
  55. 55. レガシーを ぶっつぶせ。 実績値のとり⽅ 刷新前後のシステム上で全く同じPDCA案件を開発 全開発⾏程のコストを⽐較
  56. 56. レガシーを ぶっつぶせ。 フェーズ 現⾏ 刷新後 勝ち負け
  57. 57. レガシーを ぶっつぶせ。 Good 全⾏程で減少 特にテストが減少 副次効果で⼯期短縮 Bad 詳細設計増加 UT増加 結果のサマリ 合算で28%効率向上
  58. 58. レガシーを ぶっつぶせ。 開発効率 → サービスの巡航速度 PDCAサイクルの速度 128%向上 10回打席に⽴っていたなら13回になる ⼯期も縮まるのでより早くリリースが出来る ⼤規模開発ならより効果が出る⾒込み ⾮エンジニア向けにパッケージング
  59. 59. レガシーを ぶっつぶせ。 残りの承認のとり⽅ ビジネスメリット x 実績値 これで残りを進めていいかの承認を取る 問題なければ残りの⼯数を精緻⾒積もり、スケジュール 策定 この量を取りに⾏くのでしっかり
  60. 60. レガシーを ぶっつぶせ。 ⾮エンジニアの同意と承認の⼯夫のまとめ ビジネスメリットと実績値で語る
  61. 61. レガシーを ぶっつぶせ。 EOP 良い刷新ライフを!

×