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

https://jsconf.jp/2025/ja/talks/line-yahoo-sponsor-session

Transcript

1. © LY Corporation 老舗の知恵とAIの二刀流で挑む Yahoo!知恵袋の事故らない進化 LINEヤフー株式会社 津村光輝
2. © LY Corporation 自己紹介 2 • 2022/04 新卒でヤフー株式会社に入社 • 2022/06-2023/12 Yahoo!しごとカタログ • 2023/04-現在 Yahoo!知恵袋 経歴 津村 光輝(@l1lhu1hu1)
3. © LY Corporation 機能・ページ • AI回答機能 • カウンセラー・占い師相談 • おすすめ質問レコメンド機能 新機能今でも増えています！ 3 Yahoo!知恵袋の紹介 基本情報 • 登録利用者数5,200万人以上、回答数6億5,000 万件以上を有する(2024年4月時点)2004年か らあるQ&Aサイト(21周年 ) • Node.js, React, Express.js等を利用
4. © LY Corporation 4 概要 4 21年間続くYahoo!知恵袋は現在も様々な新機能が日々追加されています。た だ、歴史の長さの分だけ問題も多く、解決が困難な問題も多く存在します。 • 利用ライブラリのバージョンが古い • 膨大な量のコードコピー • JavaScriptで書かれていて型情報がない • 掃除忘れコード、絶対に通らない条件分岐、マジックナンバー
5. © LY Corporation 5 概要 5 我々はこういった問題に対して老舗の知恵と生成AIで解決に挑んでいます！ 今日はその取り組みの一部を紹介します！ 皆様の身近にある問題の解決の参考にして頂けるとうれしいです！ ※ 質問・雑談・フィードバックは(Xでも対面でも)大歓迎です！ LINEヤフーのブースにも良かったら来てください！
6. © LY Corporation 6 Agenda 6 Yahoo!知恵袋における以下の取り組みの紹介 • 品質と効率の両立の実現に向けての取り組み • 事故からの迅速な復旧の実現に向けての取り組み
7. © LY Corporation 7 Agenda 7 Yahoo!知恵袋における以下の取り組みの紹介 • 品質と効率の両立の実現に向けての取り組み • 事故からの迅速な復旧の実現に向けての取り組み
8. © LY Corporation 品質と効率の両立の実現 8
9. © LY Corporation 9 品質と効率の両立の実現 9 品質と効率の両立の実現を支える日常的な取り組みを紹介 • 定期開催イベント • レビュー 品質と効率の両立の実現
10. © LY Corporation 10 品質と効率の両立の実現 10 品質と効率の両立の実現を支える日常的な取り組みを紹介 • 定期開催イベント • FE定例 • FE Meetup • No Meeting Day • レビュー 品質と効率の両立の実現
11. © LY Corporation 11 品質と効率の両立の実現 11 品質と効率の両立の実現を支える日常的な取り組みを紹介 • 定期開催イベント • FE定例 • FE Meetup • No Meeting Day • レビュー 品質と効率の両立の実現
12. © LY Corporation 12 No Meeting Day 12 No Meeting Dayとは • 品質改善・効率化・学習を自由に行って良い日(月一で開催) • 案件に関するMeetingをいれることは禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
13. © LY Corporation 13 No Meeting Day 13 No Meeting Dayとは • 品質改善・効率化・学習を自由に行って良い日(月一で開催) • 案件に関するMeetingをいれることは禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
14. © LY Corporation 14 ライブラリの更新で発生した問題の解決 14 前提 • Yahoo!知恵袋ではStorybookの5系を利用、storyをjson形式で管理 • Storybookのバージョンアップを行った • storiesOf APIを利用できなくなり、CSF(Component Story Format)形式 に書き直す必要があった 解決するために、codemodでCSF形式での置き換えを実行 品質と効率の両立の実現 No Meeting Day
15. © LY Corporation 15 ライブラリの更新で発生した問題の解決 15 問題 • Codemodで変換の大部分は成功したが、一部ファイルは変換に失敗 • 変換に失敗したコンポーネントはStorybook上からは確認ができない • 手動で変換するのには時間がかかる 解決策 • Codemodで変換に失敗したstoryファイルの修正をClineで行う • 事前準備・当日の進め方の流れで説明 品質と効率の両立の実現 No Meeting Day
16. © LY Corporation 16 16 事前準備 1. Storybook上で表示ができていないコンポーネントの調査 2. 1で見つけたファイルの一部を手作業で変換する 3. 手作業でやった内容を指示に落とし込む 4. 3で作成した指示をClineに与えて試す 事前準備で変換に成功した指示をNo Meeting Day当日に配布 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決
17. © LY Corporation 17 17 事前準備で作成した指示の内容(詳しくはAppendixを参照) • 前提・大まかな修正手順・禁止事項 • 細かい修正手順(ステップに分けて4つほど) • 修正前後のファイル例 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決
18. © LY Corporation 18 18 当日の進め方 • 事前準備で作成した指示の共有 • 分担を決めて、Clineを利用して各自実施 • 作成に失敗した場合は追加指示で修正 or 手動修正 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決
19. © LY Corporation 19 19 結果 • 手直しが必要な場合もあったが、storyファイル追加は概ね成功、手動で追加 するよりも圧倒的に早かった • 目で見てstoryとして機能しているかの動作確認する部分は時間がかかった 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決
20. © LY Corporation 20 20 得られた知見 • Codemodの結果を修正するよりゼロから生成AIで作り直すほうが早い • 今後似たようなファイル変換を行う場合は以下の流れが良いのかも？ • 生成AIでファイル変換ができないか少し試す • 試した結果上手くできそうであれば、生成AIでファイル変換 • もし上手くいかない場合は、生成AIでcodemodを作成してファイル変換 品質と効率の両立の実現 No Meeting Day ライブラリの更新で発生した問題の解決
21. © LY Corporation 21 No Meeting Day 21 No Meeting Dayとは • 問題解決・効率化・学習の場(月一で一日開催) • 案件に関するMeetingをいれることが禁止 FEチームでは日頃中々解決ができていない問題の解決を行っている • ライブラリの更新で発生した問題の解決 • テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
22. © LY Corporation 22 22 前提 Controller部分のユニットテストはサーバーを立て、そのサーバーにリクエスト を投げることで行っている(※統合テストやE2Eではない) 問題 • テストが失敗した場合に実行が完了するまでに数十秒かかる • テストが失敗した場合のログから原因かの特定が困難 開発効率を落とす要因になってしまっている テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
23. © LY Corporation 23 23 ユニットテストの書き直しで解決 • リクエストを送る方式での検証をやめ、関数呼び出しでの検証に変更 • 各ユニットテストは500-1000行程度 • 特に変更頻度の高いcontrollerが対象 • Claude Code/Clineを用いて手分けしてゼロから書き直した 当日の流れ • ライブコーディング(1時間) • 各自担当箇所の実装 • 成果物の共有、うまくいったこと、困ったことの共有(30分) テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
24. © LY Corporation 24 24 結果 各自担当のcontrollerのユニットテストをゼロから書き直すことに成功 得られた知見 • 1つ例となるテストファイルがあると品質が安定 • 1つのテストケースを丁寧に作ってから残りを作ると品質が安定 • 大まかに作ってから詳細化のようにステップに分けて実施することが重要 • 旧テストの仕様を出力し、ベースにするよう指示を出すと漏れにくい • 出した指示を記録しておくと他のテストで指示の再利用が可能 テストで発生している問題の解決 品質と効率の両立の実現 No Meeting Day
25. © LY Corporation 25 25 取り組んだこと • Codemodで置き換えに失敗したファイルの修正 • 実行に時間がかかるユニットテストのゼロからの書き直し(各500-1000行) 結果 • 置き換えに失敗したファイルの修正に成功(まだ全てではない) • 各自担当のcontrollerのユニットテストをゼロから書き直すことに成功 • 様々な知見が得られた(一部抜粋) • 旧テストの仕様を出力し、ベースにするよう指示を出すと漏れにくい • 出した指示を記録しておくと他のテストで指示の再利用が可能 No Meeting Day: まとめ 品質と効率の両立の実現 No Meeting Day
26. © LY Corporation 26 品質と効率の両立の実現 26 品質と効率の両立の実現を支える日常的な取り組みを紹介 • 定期開催イベント • FE定例 • FE Meetup • No Meeting Day • レビュー 品質と効率の両立の実現
27. © LY Corporation 27 レビュー時に発生する問題 27 レビュー時によく発生する問題 • 質問なのか絶対に直してほしい指摘なのかが文面から判断しづらい • 修正されたコードが多すぎて実装ミスを見逃す • 同じ内容に関する議論が何度も色々な場所で行われる • etc. 品質と効率の両立の実現 レビュー
28. © LY Corporation 28 レビュー時に発生する問題 28 レビュー負荷が高まると、レビュワーもレビュイーも疲弊してしまい • 重大なバグを見逃したままマージしてしまう • 付け焼き刃のような実装になってしまう • 険悪な雰囲気になってしまうことも... 生成AIの普及によって高速にコードが生成されようになるので、今後これら の問題は更に起こりやすくなると考えられる 今回はこの問題にどう対処しているかを紹介 品質と効率の両立の実現 レビュー
29. © LY Corporation 29 レビュー負荷を減らすには 29 より重要な問題解決に時間を割くために以下を意識して取り組んでいる • 余分なやりとりを減らす • 見落としを防止する 品質と効率の両立の実現 レビュー
30. © LY Corporation 30 レビュー負荷を減らすには 30 より重要な問題解決に時間を割くために以下を意識して取り組んでいる • 余分なやりとりを減らす • 見落としを防止する 品質と効率の両立の実現 レビュー
31. © LY Corporation 31 余分なやりとりを減らす取り組み 31 問題: いつまでにレビューすればよいかわからない 解決策: レビュー依頼時に期限とリリース日をレビュワーに知らせるルール 問題: レビューコメントの意図が分かりづらい 解決策: レビュワーがコメントのprefixとしてquestion、must、optional、 commentのいずれかをつけるルール 問題: 色々な場所で同じ議論を何度もしてしまう 解決策: コーディングルールの反映 品質と効率の両立の実現 レビュー
32. © LY Corporation 32 余分なやりとりを減らす取り組み 32 問題: 実装の大方針に誤りがあり、やり取りが長期化する 解決策: 修正が長期間に及ぶ場合は設計レビューを必須とするルール 問題: 前提となる仕様がわからず文面で何度もやりとりが発生する 解決策: 対面レビュー 品質と効率の両立の実現 レビュー
33. © LY Corporation 33 レビュー負荷を減らすには 33 より重要な問題解決に時間を割くために以下を意識して取り組んでいる • 余分なやりとりを減らす • 見落としを防止する 品質と効率の両立の実現 レビュー
34. © LY Corporation 34 見落としを防止する取り組み 34 問題: レビューで問題を見落とす 解決策: • AIレビューボットで問題箇所にコメントの自動追加 • 修正が及ぼす影響ファイルをグラフで可視化 • 一定のパターン(以下例)に該当した場合にコメントの自動追加 • PRの変更行数が設定した閾値を超えた場合 • PR内でpackage.jsonに変更があった場合 • PRに残TODOコメントがあった場合 品質と効率の両立の実現 レビュー
35. © LY Corporation 35 品質と効率の両立の実現: まとめ 35 品質と効率の両立の実現を支える日常的な取り組みとして以下を紹介 • 生成AIを活用した取り組み • Codemodで解決できなかった問題の解決 • ゼロからのテストコードの書き直しで解決 • レビューの負荷を下げる取り組みの実施 • レビューでの余分なやり取りを減らす取り組みの紹介 • レビュー見落としを防止する取り組みの紹介 品質と効率の両立の実現
36. © LY Corporation 36 Agenda 36 Yahoo!知恵袋における以下の取り組みの紹介 • 品質と効率の両立の実現に向けての取り組み • 事故からの迅速な復旧の実現に向けての取り組み
37. © LY Corporation 事故からの迅速な復旧の実現 37
38. © LY Corporation 38 事故からの迅速な復旧の実現 38 Yahoo!知恵袋で事故(障害)が起こるとユーザー数が多い分、少しの時間の事 故でも大きな被害になってしまう 事故が起きた時に被害を最小化するために迅速な復旧ができる必要があり、 そのために様々な対策を行っている • Blue/Green Deploy • Canary Release • 事故からの復旧手順書の整備 • etc. 事故からの迅速な復旧の実現
39. © LY Corporation 39 事故からの迅速な復旧の実現 39 今回は以下の取り組みについてを紹介 • Fail Soft • Feature Flag 事故からの迅速な復旧の実現
40. © LY Corporation 40 事故からの迅速な復旧の実現 40 今回は以下の取り組みについてを紹介 • Fail Soft • Feature Flag 事故からの迅速な復旧の実現
41. © LY Corporation 41 41 ランキングモジュールの表示に失敗すると 発生していた問題 事故からの迅速な復旧の実現 Fail Soft 質問文 回答文 ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー
42. © LY Corporation 42 42 ページ全体の表示に失敗 発生していた問題 事故からの迅速な復旧の実現 Fail Soft 質問文 回答文 ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー
43. © LY Corporation 発生していた問題 • 外部連携システムで不具合が起きると、Yahoo!知恵袋も巻き添えになる • 外部連携システムが増えれば増えるほど、そのリスクが増大する 43 発生していた問題 事故からの迅速な復旧の実現 Fail Soft
44. © LY Corporation 発生していた問題 • 外部連携システムで不具合が起きると、Yahoo!知恵袋も巻き添えになる • 外部連携システムが増えれば増えるほど、そのリスクが増大する Fail Softの考え方を導入することで解決！ 44 発生していた問題 事故からの迅速な復旧の実現 Fail Soft
45. © LY Corporation 45 Fail Softとは 45 障害や過負荷を検知した時に重要ではない機能から意図的に止め、コア機能 を動かし続けるための設計・運用の考え方 出典: https://csrc.nist.gov/glossary/term/fail_soft 事故からの迅速な復旧の実現 Fail Soft
46. © LY Corporation 46 Yahoo!知恵袋に適用する場合 46 Yahoo!知恵袋に存在する機能は大きく2つに分類できる 主機能 副機能 事故からの迅速な復旧の実現 Fail Soft
47. © LY Corporation 47 47 Yahoo!知恵袋に存在する機能は大きく2つに分類できる 主機能 • ページを訪問する目的になるようなコアの機能 • 停止すると価値喪失に直結するコアな機能 副機能 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
48. © LY Corporation 48 48 Yahoo!知恵袋に存在する機能は大きく2つに分類できる 主機能 • ページを訪問する目的になるようなコアの機能 • 停止すると価値喪失に直結するコアな機能 副機能 • 主機能以外の機能 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
49. © LY Corporation 49 49 Yahoo!知恵袋に存在する機能は大きく2つに分類できる 主機能 • ページを訪問する目的になるようなコアの機能 • 停止すると価値喪失に直結するコアな機能 副機能 • 主機能以外の機能 ここを守る！ 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
50. © LY Corporation 50 50 質問文 回答文 ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー Yahoo!知恵袋の質問詳細ページの構成 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
51. © LY Corporation 51 51 質問文と回答文が主機能 質問文(主機能) 回答文(主機能) ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
52. © LY Corporation 52 52 質問文(主機能) 回答文(主機能) ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー 質問文と回答文以外は表示されなくても役割を果たせる 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
53. © LY Corporation 53 53 質問文(主機能) 回答文(主機能) ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー 例えば、ランキングが表示されなくても役割を果たせる 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
54. © LY Corporation 54 54 質問文(主機能) 回答文(主機能) ランキング おすすめ質問一覧 広告 カテゴリー一覧 ヘッダー 主機能が利用できない場合は役割を果たせない 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
55. © LY Corporation 55 55 主機能が利用できない場合はエラーページに遷移 事故からの迅速な復旧の実現 Fail Soft Yahoo!知恵袋に適用する場合
56. © LY Corporation 56 実現方法 56 外部連携システムのAPIからエラーが返ってきた場合 • もし主機能に関するデータであればエラーページにリダイレクトする • それ以外であれば後続処理を続行し問題のあった機能を無効化 事故からの迅速な復旧の実現 Fail Soft
57. © LY Corporation 57 Fail Soft: まとめ 57 発生していた問題 • 外部連携システムで不具合が起きると、Yahoo!知恵袋も巻き添えになる • 外部連携システムが増えれば増えるほど、そのリスクが増大する Fail Softの考え方の導入によって • 副機能用の情報取得の失敗時でも主機能は継続して利用できるように！ • 主機能が利用できない場合はエラーページに遷移するようにしている 事故からの迅速な復旧の実現 Fail Soft
58. © LY Corporation 詳しくはシステムトラブルに強いWebフロントエンドを作る方法を ご確認ください！ 58 Fail Soft: まとめ 事故からの迅速な復旧の実現 Fail Soft
59. © LY Corporation 59 事故からの迅速な復旧の実現 59 今回は以下の取り組みについてを紹介 • Fail Soft • Feature Flag 事故からの迅速な復旧の実現
60. © LY Corporation 複数人で同じレポジトリの修正を行い、同じ日にリリースする場合コンフリクト が発生する場合がある。そういった日に事故が起きると対応が困難。 復旧方法 • 問題が起きた日のリリース全体をrevertして無事な機能だけ再リリース • 問題が起きた日のリリース全体のうち問題のあった機能だけをrevertする どちらとも事故からの復旧に時間を要するため、Feature Flagの導入を検討 60 発生していた問題 事故からの迅速な復旧の実現 Feature Flag
61. © LY Corporation 61 61 特定の機能を有効化・無効化するための仕組み • 機能ごとのスイッチがあるイメージ • フラグの切り替えで問題があった機能のみの無効化が可能 説明 機能名 有効か 質問投稿機能 false 回答投稿機能 true ランキングモジュール表示機能 true 事故からの迅速な復旧の実現 Feature Flag
62. © 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
63. © LY Corporation 63 63 Yahoo!知恵袋 FEシステム ABテスト管理 システム 実現方法(2/5) リクエスト cookie ユーザーに割り当てる bucket一覧 レスポンス ユーザー 開発者 操作 事故からの迅速な復旧の実現 Feature Flag
64. © 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
65. © 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
66. © 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
67. © LY Corporation 67 67 ABテスト管理 システム 実現方法 リクエスト cookie bucket一覧 feature flag一覧 レスポンス ユーザー 開発者 操作 Feature名 デフォルト値 feat1 true feat2 false feat3 false Yahoo!知恵袋 FEシステム 事故からの迅速な復旧の実現 Feature Flag
68. © LY Corporation Feature Flag: まとめ 問題: 事故が起きた場合に復旧に時間がかかる 一部解決: • 問題のある機能のFeature Flagをオフにし迅速な復旧が可能に • 次のリリースまでに落ち着いて修正する選択肢が増えた 副次的な効果として本番環境でのみ起こる問題の原因特定が行いやすくなった 68 事故からの迅速な復旧の実現 Feature Flag
69. © LY Corporation Feature Flag: まとめ Yahoo!知恵袋におけるFeature Flag活用〜安全で柔軟なリリースを目指してを 詳しくはご確認ください！ 69 事故からの迅速な復旧の実現 Feature Flag
70. © LY Corporation 70 事故からの迅速な復旧の実現: まとめ 70 事故からの迅速な復旧の実現 • Yahoo!知恵袋では事故発生時の被害を緩和する様々な対策を実施 • Fail Softを導入で外部連携システムの不具合からの影響を緩和 • Feature Flagを活用で事故からの迅速な復旧を実現
71. © LY Corporation 全体まとめ 71
72. © LY Corporation 72 全体まとめ 72 Yahoo!知恵袋の事故らない進化を支える老舗の知恵と生成AI活用を紹介 • Codemodで変換に失敗したファイルを生成AIを活用して修正した事例 • 実行時間が長いユニットテストを生成AIを活用した書き直し事例 • レビュー負荷を下げるための取り組み • Fail Softで外部連携システムの不具合からの影響を減らす取り組み • Feature Flagで事故からの迅速な復旧を実現する取り組み 皆様の身近にある問題の解決の参考にして頂けるとうれしいです！
73. © LY Corporation 73 参考・引用 73 Yahoo!知恵袋、サービス開始20周年を記念した特集サイトを公開 https://www.lycorp.co.jp/ja/news/release/007875 回答のつかない質問を減らすために https://chiebukuro.yahoo.co.jp/topic/ai/answer.html
74. © LY Corporation ご清聴ありがとうございます！
75. © 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 ライブラリの更新で発生した問題の解決
76. © 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 ライブラリの更新で発生した問題の解決
77. © LY Corporation 77 開発プロセス 77 1. 設計(6日以上かかりそうな実装のみ必須) 2. 設計レビュー(2人以上からのApprove必須) 3. 実装 4. 実装レビュー(2人以上からのApprove必須) 5. dev/stgリリース 6. 動作確認 7. prodリリース 8. 動作確認 品質と効率の両立の実現 開発プロセス
78. © LY Corporation 78 定期開催イベント 78 No Meeting Day実施内容例 • 業務に役立ちそうなライブラリ触る(OGPとか) • 宝探し(無駄なログの削減等) • デザインシステムのコンポーネント実装 • 生成AIの活用をサービス全体で広める活動等が行われている 品質と効率の両立の実現 No Meeting Day
79. © LY Corporation 79 定期開催イベント 79 品質と効率の両立の実現 FE定例(週に二回一時間ずつ開催) • 問題の共有や問題が起きていないかの確認や方針決めが目的の会 • 例: 担当決め、CWVやissue確認、設計・実装相談、再発防止策議論 FE Meetup(月に一回一時間以内で開催) • 知見の共有が目的の会 • 例: Chrome Built-in AI、生成AI活用事例紹介 No Meeting Day(月に一回一日開催) • 日頃取り組めていない問題の解決や業務の効率化や学習が目的の会 • 例: 手動コーディング禁止デー、様々なMCPサーバー触るデー