エンジニア向けコミュニティZennの開発チームを支える自動化の仕組み.pdf

Transcript

1. 2024年11⽉09⽇(⼟) オープンセミナー2024@広島 「XRE - エンジニアを⽀える組織」 エンジニア向けコミュニティZennの開発チームを⽀える ⾃動化の仕組み 新規事業部 Zennチーム dyoshikawa クラスメソッド株式会社
2. スライドはSpeakerDeckにもアップロードしています 2
3. ⾃⼰紹介 3 • https://x.com/dyoshikawa1993 • 広島在住ソフトウェアエンジニア • Next.js / Ruby on Rails / Google Cloud ◦ 以前はAWSサーバレス、バックエンド Node.js、Laravel、Vue.jsなど • 応⽤情報技術者 / AWS Security Specialtyなど
4. ⾃⼰紹介 4 • ⽣成AIをZennに本番導⼊ • Google Cloudイベントで事例 応募し登壇 https://cloudonair.withgoogle.com/events/generative-ai-summit-24-fall https://x.com/classmethod/status/1849319304589979839
5. 今⽇お話すること 5 • はじめに ◦ Zennの紹介 ◦ なぜ⾃動化するのか • 具体的な取り組みをご紹介 ◦ 静的解析、テスト⾃動化、CI/CD、⽣成AI • おわりに ◦ さらに⾃動化していくために ◦ まとめ
6. Zennをご存知の⽅ 🙋 （聞いたことある）
7. Zennで記事を 読んだり書いたりしたことがある⽅ 🙋
8. Zenn（https://zenn.dev）について 8 活発なコミュニティ • 3種類の投稿形式 で知見を発信 できる • 記事の著者が金銭的な対価 を得 られる • 月間PV数 1,300万以上 • 会員数 12万以上 • Publication（※）数 900以上 ※企業または組織、コミュニティなどが、投稿する記事を まとめることができるグループ機能 エンジニアの情報共有
9. Zennのこれまで 9 個人プロジェクトとしてリリース 運営会社がクラスメソッド株式会社に 2020年9月 2021年6月 6人の小さなチーム（※）で運営中 現在 ※エンジニア3名、デザイナー1名、ビジネス1名、オペレーター1名
10. Zennの構成 10 10 イベントデータ Cloud Load Balancing データベース Cloud SQL Analytics 画像など Cloud Storage タスクワーカー Cloud Run 管理画面・API Cloud Run ユーザーAPI Cloud Run HTML / JS Cloud Run Assets Stats BigQuery Scheduled Tasks Cloud Scheduler タスクワーカーへ Monitoring Logging Bulk Tasks Cloud Tasks タスクワーカーへ 著者‧読者 管理者 Gemini Vertex AI
11. なぜ⾃動化するのか？ 11 • 速くて正確だから ◦ 反復的な作業を瞬時に完了できる ◦ うっかりミスがない、疲労や集中⼒低下の影響を受けない • チームの規模はそのままに⽣み出す価値をスケールできる
12. ⽣み出した時間をより創造的なタスクに当てる 12 定型作業 課題 • 既存業務に追われ、フローを改善する時間がない • 新たな課題が⽣じた際も、じっくりと検討するゆとりがないので場当たり的 に⼈⼒で対処することになる ◦ さらに定型作業が増加する悪循環 ⽬の前の業務で1⽇が埋まってしまうと… 😇
13. ⽣み出した時間をより創造的なタスクに当てる 13 定型作業 課題 • 浮いた時間を各種検討に当てられる • 新しい課題に対して、その場の対処に留まらない仕組みづくりができる • 既存業務のさらなる効率化にも着⼿できる ⾃動化により定型作業に割く時間を圧縮できれば… 😎
14. 「現実世界はそんなに単純ではない」 14 それはそう 😇 • このような場合は？ ◦ ⾃動化で削減できる⼯数より仕組みづくりの⼯数の⽅が⼤きい場合は？ ◦ 「単純だが1度しか⾏わないかもしれない作業」を⾃動化すべきか？ • 対象とタイミングの選定を間違えなければ、少ない労⼒で⾼い効果を得ら れるはず ◦ 作業を分解し、⾃動化することで費⽤対効果が⾼い部分を発⾒（対象） ◦ 同じ作業を繰り返すことが確定してから⾃動化を検討（タイミング）
15. 具体的な取り組み
16. コードの静的解析 16 フロントエンド バックエンド Prettier + ESLint + TypeScript RuboCop
17. コードレビューの定型観点を⾃動化できる 17 コードレビューの定型観点とは？ → コーディングスタイルの統⼀
18. コードレビューの定型観点を⾃動化できる 18 • Formatter ◦ スペース、インデント、改⾏の統⼀ https://github.com/prettier/prettier
19. コードレビューの定型観点を⾃動化できる 19 • Linter ◦ 「書き⽅」の統⼀ ▪ JS/TS: `var` を `let` と `const` に ▪ Ruby: `if !foo`を `unless foo` に https://eslint.org/docs/latest/rules/no-var
20. コードレビューの定型観点を⾃動化できる 20 • Formatter/Linterでレビューの定型観点チェックを⾃動化 • レビュアーは⾮定型観点に集中できる ◦ ソフトウェア設計 ◦ パフォーマンス ◦ セキュアコーディング
21. 「型チェック」による静的解析 21 • フロントエンド⾔語としてTypeScript を採⽤ • 実⾏前にエラーを検出できる ◦ 型チェックはテストの⼀種 ▪ 静的テスト ▪ 動的テスト ◦ フロントエンド開発における存在感 • 開発効率の向上 ◦ IDE上において正確なコード補完 https://www.typescriptlang.org
22. テストの⾃動化 22 E2E フロントエンド バックエンド Vitest + React Testing Library RSpec Playwright
23. テストの⾃動化 23 • フロントエンドテスト（Vitest + React Testing Library） ◦ 関数やReact Hooksについて振る舞いを確認するテスト ◦ Reactコンポーネントに対するテストやVRTの導⼊は今後の課題 https://testing-library.com/docs/react-testing-library/example-intro
24. テストの⾃動化 24 • バックエンドテスト（RSpec） ◦ Web APIとしてHTTPリクエスト受信し、RDBへのRead/Writeを含む振る 舞いのテスト https://github.com/rspec/rspec-core
25. テストの⾃動化 25 • E2Eテスト（Playwright） ◦ ブラウザをPlaywrightで操作し、フロントエンドとバックエンドを⼀気通 貫でテストする ◦ E2Eテストの量に注意（テスティングピラミッド/トロフィー） https://martinfowler.com/articles/practical-test-pyramid.html https://kentcdodds.com/blog/the-testing- trophy-and-testing-classifications
26. なぜ「⾃動」テストか？ 26 初期機能A テスト⼯数 1⼈⽉ 機能Bを追加（機能Aに影響） テスト⼯数 1⼈⽉ 機能Cを追加（機能A, Bに影響） テスト⼯数 1⼈⽉ 1⼈⽉でテスト実施 2⼈⽉でテスト実施 3⼈⽉でテスト実施 ⼿動テストの場合
27. なぜ「⾃動」テストか？ 27 初期機能A テストコード作成⼯数 1⼈⽉ 機能Bを追加（機能Aに影響） テストコード作成⼯数 1⼈⽉ 機能Cを追加（機能A, Bに影響） テストコード作成⼯数 1⼈⽉ 1⼈⽉でテストコード作成 1.1⼈⽉で テストコード作成 1.2⼈⽉で テストコード作成 ⾃動テストの場合 0.1⼈⽉で機能Aのテストコードを修正 0.2⼈⽉で機能A, Bのテストコードを修正
28. なぜ「⾃動」テストか？ 28 • サービスの規模が拡⼤してもテスト⼯数が雪だるま式に増加しない ◦ 開発チームの⼈数を増やさなくてもスケールできる • リリースする度にテストカバレッジを上げることも可能 ◦ テストコードは積み上げられる ◦ ⼿動テストでは困難 • リファクタリングタスクに着⼿しやすい ◦ リファクタリング後、再度⾃動テストを回すことで動作担保ができる • 将来にわたって繰り返し実施することが確定している
29. CI/CDの整備 29 GitHub Repository GitHub Actions Cloud Build Artifact Registry Cloud Shell 管理者 静的解析‧ テスト ビルド‧デ プロイコマ ンドの送信 コマンド 実⾏環境 デプロイ コマンドの表⽰ デプロイコマンド を確認‧実⾏ ソースコード 管理 ビルドされた イメージ管理 参照: https://dev.classmethod.jp/articles/zenn_cicid_googlecloud
30. CI/CDの整備 30 • CI（継続的インテグレーション） ◦ コードの変更をリポジトリに⾃動‧頻繁に統合する開発⼿法 ◦ ⾃動テストやビルドを実⾏し、問題を早期発⾒ 参考: https://www.redhat.com/ja/topics/devops/what-is-ci-cd
31. CI/CDの整備 31 • CD（継続的デリバリー/デプロイメント） ◦ CIの後継ステップ ◦ 本番環境にデプロイ可能な状態を常に維持（デリバリー） ◦ 本番環境への⾃動デプロイ（デプロイメント） 参考: https://www.redhat.com/ja/topics/devops/what-is-ci-cd
32. CI/CDの整備 32 • CI（GitHub Actions） ◦ 静的解析チェック、⾃動テスト • CD（Cloud Build） ◦ コンテナイメージビルド、Slack へデプロイコマンドの送信 • ChatOps（Slack）の活⽤ • 管理者はSlackに表⽰されたコマン ドを確認、任意のタイミングでデプ ロイ
33. ⽣成AIの活⽤ 33 意思決定 ⾮定型作業 定型作業 従来⾃動化できた領域 ここも⼀部⾃動化できるかも？ ⽣成AIの登場により…
34. 実際に運⽤業務に適⽤した事例 34 スパム投稿が急増 • 2024 年 6 ⽉ごろ〜 • 特定 URL への誘導などのスパムコ ンテンツが⼤量に投稿される • 読者体験の急激な悪化を懸念し、 早急な対処が必要に スパム投稿で埋めつくされた新着コンテンツ⼀覧（イメージ）
35. 実際に運⽤業務に適⽤した例 35 管理者 違反報告 コンテンツ ① スパム判定 ②違反報告 ③内容を確認して処理 ⽣成AI Geminiを使ってスパム検出システムを構築 スパム疑い投稿85%減少、運⽤コスト75%削減
36. 開発業務における⽣成AI活⽤ 36
37. クラスメソッド社ではGitHub Copilot+内製ツールを開発で使⽤ 37 • GitHub Copilot: コーディング⽀援 • 内製ツール: 汎⽤的な質問⽤途、またOpenAI社以外のモデルを 使⽤したい場合（複数の⽣成AIモデルが使⽤可能） https://classmethod.jp/services/generative-ai/ai-starter/
38. ⽣成AIは全知全能ではない 38 https://www.nhk.jp/p/ts/1M3MYJGG6G/blog/bl/pp2BabPyzp /bp/paOGGOGoma/ https://x.com/ockeghem/status/1834960395062120479 • 次に来る確率が⾼い単語を繋ぎ合わせて ⽂章を出⼒している • 確率で紡がれた⽂章が正しい保証はない
39. ⽣成AIは全知全能ではない 39 • スペシャリストである⾃分×⽣成AIのかけ算で開発する • 成果物の品質に責任を持つのは⼈間であることを忘れない
40. おわりに
41. さらに⾃動化していくために 41 段階を踏んでインクリメンタルに導⼊する • ⼤⾵呂敷を広げると、何も実現せず頓挫しがち • ⼩さく始める ◦ 既存業務を分解し、⾃動化に着⼿しやすい箇所を探す • 組織で⼩さな成功体験を積み重ねる ◦ チーム全員が⾃動化のメリットに腹落ちして、前向きに取り組めるように
42. さらに⾃動化していくために 42 HRTを⼤切にする • 「Humility（謙虚）」「Respect（尊敬）」「Trust（信頼）」 • 課題がない環境など存在しない • 「解決しない（ように⾒える）チームメンバー」を敵視しない ◦ 課題が解決されず残っていることにはほとんどの場合、理由がある • 周囲を責めても、むしろ課題解決から遠ざかる • 「VS誰か」ではなく「VS課題」で考えよう ⾃戒も込めて…
43. まとめ 43 • なぜ⾃動化するのか？ ◦ ⼈間よりも「速くて正確」だから ◦ 時間を⽣み出して、より創造的なタスクに当てたいから • 具体的な取り組み ◦ コードの静的解析 ◦ テストの⾃動化 ◦ CI/CDの整備 ◦ ⽣成AI活⽤ • ⾃動化はインクリメンタルに、そしてHRTを⼤切に