老舗の知恵とAIの二刀流で挑むYahoo!知恵袋の事故らない進化

by Koki Tsumura

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© LY Corporation 12 No Meeting Day 12 No Meeting Dayとは • 品質改善・効率化・学習を自由に行って良い日(月一で開催) • 案件に関するMeetingをいれることは禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 13

Slide 13 text

© LY Corporation 13 No Meeting Day 13 No Meeting Dayとは • 品質改善・効率化・学習を自由に行って良い日(月一で開催) • 案件に関するMeetingをいれることは禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 14

Slide 14 text

© LY Corporation 14 ライブラリの更新で発生した問題の解決 14 前提 • Yahoo!知恵袋ではStorybookの5系を利用、storyをjson形式で管理 • Storybookのバージョンアップを行った • storiesOf APIを利用できなくなり、CSF(Component Story Format)形式に書き直す必要があった解決するために、codemodでCSF形式での置き換えを実行品質と効率の両立の実現 No Meeting Day

Slide 15

Slide 15 text

© LY Corporation 15 ライブラリの更新で発生した問題の解決 15 問題 • Codemodで変換の大部分は成功したが、一部ファイルは変換に失敗 • 変換に失敗したコンポーネントはStorybook上からは確認ができない • 手動で変換するのには時間がかかる解決策 • Codemodで変換に失敗したstoryファイルの修正をClineで行う • 事前準備・当日の進め方の流れで説明品質と効率の両立の実現 No Meeting Day

Slide 16

Slide 16 text

© LY Corporation 16 16 事前準備 1. Storybook上で表示ができていないコンポーネントの調査 2. 1で見つけたファイルの一部を手作業で変換する 3. 手作業でやった内容を指示に落とし込む 4. 3で作成した指示をClineに与えて試す事前準備で変換に成功した指示をNo Meeting Day当日に配布品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© LY Corporation 20 20 得られた知見 • Codemodの結果を修正するよりゼロから生成AIで作り直すほうが早い • 今後似たようなファイル変換を行う場合は以下の流れが良いのかも？ • 生成AIでファイル変換ができないか少し試す • 試した結果上手くできそうであれば、生成AIでファイル変換 • もし上手くいかない場合は、生成AIでcodemodを作成してファイル変換品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決

Slide 21

Slide 21 text

© LY Corporation 21 No Meeting Day 21 No Meeting Dayとは • 問題解決・効率化・学習の場(月一で一日開催) • 案件に関するMeetingをいれることが禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 22

Slide 22 text

© LY Corporation 22 22 前提 Controller部分のユニットテストはサーバーを立て、そのサーバーにリクエストを投げることで行っている(※統合テストやE2Eではない) 問題 • テストが失敗した場合に実行が完了するまでに数十秒かかる • テストが失敗した場合のログから原因かの特定が困難開発効率を落とす要因になってしまっているテストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 23

Slide 23 text

© LY Corporation 23 23 ユニットテストの書き直しで解決 • リクエストを送る方式での検証をやめ、関数呼び出しでの検証に変更 • 各ユニットテストは500-1000行程度 • 特に変更頻度の高いcontrollerが対象 • Claude Code/Clineを用いて手分けしてゼロから書き直した当日の流れ • ライブコーディング(1時間) • 各自担当箇所の実装 • 成果物の共有、うまくいったこと、困ったことの共有(30分) テストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 24

Slide 24 text

© LY Corporation 24 24 結果各自担当のcontrollerのユニットテストをゼロから書き直すことに成功得られた知見 • 1つ例となるテストファイルがあると品質が安定 • 1つのテストケースを丁寧に作ってから残りを作ると品質が安定 • 大まかに作ってから詳細化のようにステップに分けて実施することが重要 • 旧テストの仕様を出力し、ベースにするよう指示を出すと漏れにくい • 出した指示を記録しておくと他のテストで指示の再利用が可能テストで発生している問題の解決品質と効率の両立の実現 No Meeting Day

Slide 25

Slide 25 text

© LY Corporation 25 25 取り組んだこと • Codemodで置き換えに失敗したファイルの修正 • 実行に時間がかかるユニットテストのゼロからの書き直し(各500-1000行) 結果 • 置き換えに失敗したファイルの修正に成功(まだ全てではない) • 各自担当のcontrollerのユニットテストをゼロから書き直すことに成功 • 様々な知見が得られた(一部抜粋) • 旧テストの仕様を出力し、ベースにするよう指示を出すと漏れにくい • 出した指示を記録しておくと他のテストで指示の再利用が可能 No Meeting Day: まとめ品質と効率の両立の実現 No Meeting Day

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© LY Corporation 28 レビュー時に発生する問題 28 レビュー負荷が高まると、レビュワーもレビュイーも疲弊してしまい • 重大なバグを見逃したままマージしてしまう • 付け焼き刃のような実装になってしまう • 険悪な雰囲気になってしまうことも... 生成AIの普及によって高速にコードが生成されようになるので、今後これらの問題は更に起こりやすくなると考えられる今回はこの問題にどう対処しているかを紹介品質と効率の両立の実現レビュー

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© LY Corporation 31 余分なやりとりを減らす取り組み 31 問題: いつまでにレビューすればよいかわからない解決策: レビュー依頼時に期限とリリース日をレビュワーに知らせるルール問題: レビューコメントの意図が分かりづらい解決策: レビュワーがコメントのprefixとしてquestion、must、optional、 commentのいずれかをつけるルール問題: 色々な場所で同じ議論を何度もしてしまう解決策: コーディングルールの反映品質と効率の両立の実現レビュー

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© LY Corporation 34 見落としを防止する取り組み 34 問題: レビューで問題を見落とす解決策: • AIレビューボットで問題箇所にコメントの自動追加 • 修正が及ぼす影響ファイルをグラフで可視化 • 一定のパターン(以下例)に該当した場合にコメントの自動追加 • PRの変更行数が設定した閾値を超えた場合 • PR内でpackage.jsonに変更があった場合 • PRに残TODOコメントがあった場合品質と効率の両立の実現レビュー

Slide 35

Slide 35 text

© LY Corporation 35 品質と効率の両立の実現: まとめ 35 品質と効率の両立の実現を支える日常的な取り組みとして以下を紹介 • 生成AIを活用した取り組み • Codemodで解決できなかった問題の解決 • ゼロからのテストコードの書き直しで解決 • レビューの負荷を下げる取り組みの実施 • レビューでの余分なやり取りを減らす取り組みの紹介 • レビュー見落としを防止する取り組みの紹介品質と効率の両立の実現

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© LY Corporation 38 事故からの迅速な復旧の実現 38 Yahoo!知恵袋で事故(障害)が起こるとユーザー数が多い分、少しの時間の事故でも大きな被害になってしまう事故が起きた時に被害を最小化するために迅速な復旧ができる必要があり、そのために様々な対策を行っている • Blue/Green Deploy • Canary Release • 事故からの復旧手順書の整備 • etc. 事故からの迅速な復旧の実現

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

© LY Corporation 57 Fail Soft: まとめ 57 発生していた問題 • 外部連携システムで不具合が起きると、Yahoo!知恵袋も巻き添えになる • 外部連携システムが増えれば増えるほど、そのリスクが増大する Fail Softの考え方の導入によって • 副機能用の情報取得の失敗時でも主機能は継続して利用できるように！ • 主機能が利用できない場合はエラーページに遷移するようにしている事故からの迅速な復旧の実現 Fail Soft

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

© LY Corporation 複数人で同じレポジトリの修正を行い、同じ日にリリースする場合コンフリクトが発生する場合がある。そういった日に事故が起きると対応が困難。復旧方法 • 問題が起きた日のリリース全体をrevertして無事な機能だけ再リリース • 問題が起きた日のリリース全体のうち問題のあった機能だけをrevertするどちらとも事故からの復旧に時間を要するため、Feature Flagの導入を検討 60 発生していた問題事故からの迅速な復旧の実現 Feature Flag

Slide 61

Slide 61 text

Slide 62

Slide 62 text

© LY Corporation 62 実現方法(1/5) 62 • 元々ABテスト管理システムを利用している • Feature Flag用のABテストを追加することで実現している ABテスト管理システム … Bucket名 Bucket割当 blue 50% red 50% 質問投稿ボタンの色変更ABテスト Bucket名 Bucket割当環境変数 user 100% feat1=true feat2=false feat3=true inspect 0% Feature Flag用ABテスト NEW! 事故からの迅速な復旧の実現 Feature Flag

Slide 63

Slide 63 text

Slide 64

Slide 64 text

© LY Corporation 64 64 実現方法(3/5) ABテスト管理システム Bucket名 Bucket割当環境変数 user 100% feat1=true feat2=false feat3=true inspect 0% Feature Flag用ABテスト … ユーザー向けのbucket • 常に100%割当 • 環境変数のみ変更する事故からの迅速な復旧の実現 Feature Flag

Slide 65

Slide 65 text

© LY Corporation 65 65 実現方法(4/5) ABテスト管理システム Bucket名 Bucket割当環境変数 user 100% feat1=true feat2=false feat3=true inspect 0% Feature Flag用ABテスト … 開発者向けのbucket • 常に0%割当 • 問題発生時の検証用事故からの迅速な復旧の実現 Feature Flag

Slide 66

Slide 66 text

© LY Corporation 66 66 実現方法(5/5) ABテスト管理システム Bucket名 Bucket割当環境変数 user 100% feat1=true feat2=false feat3=true inspect 0% feat1=true feat2=true feat3=true Feature Flag用ABテスト … 例: feat2で問題が起きた場合 1. userのfeat2をfalse, inspectのfeat2をtrueに設定 2. 自分にinspect bucketを割り当てて検証事故からの迅速な復旧の実現 Feature Flag

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

© LY Corporation 72 全体まとめ 72 Yahoo!知恵袋の事故らない進化を支える老舗の知恵と生成AI活用を紹介 • Codemodで変換に失敗したファイルを生成AIを活用して修正した事例 • 実行時間が長いユニットテストを生成AIを活用した書き直し事例 • レビュー負荷を下げるための取り組み • Fail Softで外部連携システムの不具合からの影響を減らす取り組み • Feature Flagで事故からの迅速な復旧を実現する取り組み皆様の身近にある問題の解決の参考にして頂けるとうれしいです！

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

© LY Corporation 75 75 実際に使用した指示(1/2) `src/components/**/**/*.stories.tsx` はCSF(Component Story Format)形式で書かれていて、コンポーネントの実装と同じ階層にあります。全てのコンポーネントに対して、将来的にstories.tsxを用意する予定ですが、現在は一部のコンポーネントにのみ用意されています。もしコンポーネント用のstories.tsxが存在しない場合は、コンポーネントの実装と同じ階層に新たに作成してください。コンポーネントと同じ階層にあるdata.jsonをベースにコンポーネント名.stories.tsxは作成してください。コンポーネント名.stories.tsxでは、data.jsonを importしないでください。品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決

Slide 76

Slide 76 text

© LY Corporation 76 76 実際に使用した指示(2/2) コンポーネントのstories.tsxを修正する際は、以下の手順で進めてください。 1. 対象のコンポーネントの実装ファイルを確認し、どのようなpropsが必要かを把握する。 2. 対象のコンポーネントが存在するディレクトリをlsして、data.jsonが存在するかを確認する。 data.jsonが存在する場合は、それを参考にしてstories.tsxを追加 or 修正する。 4. data.jsonが存在しない場合は、コンポーネントの実装を参考にして新たにstories.tsxを作成する。以下にBadge component用のdata.jsonの例を示します。(略) 以下にBadge component用のstories.tsx(Badge.stories.tsx)の例を示します。(略) 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

© LY Corporation 79 定期開催イベント 79 品質と効率の両立の実現 FE定例(週に二回一時間ずつ開催) • 問題の共有や問題が起きていないかの確認や方針決めが目的の会 • 例: 担当決め、CWVやissue確認、設計・実装相談、再発防止策議論 FE Meetup(月に一回一時間以内で開催) • 知見の共有が目的の会 • 例: Chrome Built-in AI、生成AI活用事例紹介 No Meeting Day(月に一回一日開催) • 日頃取り組めていない問題の解決や業務の効率化や学習が目的の会 • 例: 手動コーディング禁止デー、様々なMCPサーバー触るデー