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

107 Views

November 11, 19

スライド概要

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/

profile-image

Yahoo!デベロッパーネットワーク

@ydnjp

スライド一覧

エンジニア・デザイナー向けのヤフー公式アカウント。イベント/登壇情報/ブログ記事など、ヤフーの技術・デザインに関わる情報を発信します。

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

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.

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

35.

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

36.

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

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 良い刷新ライフを!