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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

レガシーを ぶっつぶせ。 暗中模索対策 中⼼的に進める⼈と壁打ち役の選定 壁打ち 技術⼒・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 良い刷新ライフを！