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

「レガシーをぶっつぶせ。」での講演資料です。
https://genbade-ddd.connpass.com/event/127494/

・設計の工夫
・登り方の工夫
・非エンジニアの同意と承認の工夫

Transcript

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