AI駆動開発は、組織全体で設計する

AI駆動開発勉強会 沖縄支部 第4回 @ コザ　の発表資料です

Transcript

1. AI駆動開発は、組織全体で設計する 村濱 一樹 / Scalebase株式会社 VPoE AI駆動開発勉強会 沖縄支部 第4回 @ コザ 1
2. 自己紹介 村濱 一樹 (@muraaaaa_san) Scalebase株式会社 執行役員 VPoE 担当: 組織・採用・評価制度 Claude Code / AIを浸透・活用に励んでます 2
3. Scalebase とは 3
4. 今日話したいこと AI駆動開発は、組織全体で設計するもの だと思ってます しばらくAI駆動を推進して起きた変化について話します 4
5. まず、開発の中で起きてること 5
6. 開発でも、AI 活用は引き続き 最近は、直接コードを書く以外にも AI を広げてます QA の補強 ヘルプの自動書き換え 一次調査の自動化（MCP連携） 6
7. QA の補強 スピードは十分に出てきたので、品質保証の文脈もしっかりやり始めてます 開発の 各フェーズ で、AI が自動で品質を担保する仕組みを入れてます Commit前: 自動フォーマット・コンパイル・lint 実装中: テスト書き忘れの自動検知 機能完成後: テスト戦略の判定と自動実行 CI 失敗時: 失敗の自動分析と Issue 起票 7
8. Commit 前: 自動品質チェック git commit する直前に Claude が4つを自動でやります コードの見た目を整える インデント・改行・空白の統一（フォーマット） 型の不一致やコード破損を検知 val x: Int = "abc" みたいな書き間違いをコミット前に弾く テストコード自体が壊れてないか確認 テストコードのコンパイルエラーで本体だけ通す事故を防ぐ 未使用コードや古い書き方を自動修正 使ってない import を消す、新しい構文に直す 8
9. どうやって実現しているか Claude Code の Hook 機能 を使っています .claude/settings.json に下記を設定: PreToolUse hook: matcher: Bash(git commit*) command: ./sbtc "scalafmtAll; compile; Test/compile; scalafixAll" git commit が呼ばれた瞬間に Hook が発火 通れば → そのまま commit 失敗したら → Claude がエラーを読んで、自分で修正・再 commit 9
10. 実装中: テスト書き忘れの自動検知 実装コード や proto 定義を変更すると、Rule が自動で Claude に指示します 1. 対応するテストコード (*Spec.scala ) を確認 2. 実装変更がテスト更新を要するか判定 → 必要なら修正提案 3. テストがなければ、追加するかユーザーに確認 4. 影響を受けるテストを実行 「テスト書き忘れ」が、ほぼ起きません 10
11. どうやって実現しているか Claude Code の Rule 機能 を使っています .claude/rules/ 配下に置くと、常時 Claude に読まれる → コード変更のたび自動でチェックが走る .claude/rules/testing-skill-reference.md : # Test Verification Rule on Implementation Changes When implementation code or proto definitions are modified, perform: 1. Check if corresponding test code exists (*Spec.scala) 2. If tests exist: Determine if test updates are needed 3. If no tests exist: Ask whether tests should be added 4. Run affected tests 11
12. 機能完成後: テスト戦略の自動判定 feature-testing Skill が機能実装後に走ります 1. テスト戦略を判定: Browser integration test（UI変更、API+画面） CI-only verification（内部ロジック、リファクタ） 2. テストプランを Issue にコメント 3. ブラウザ自動テスト or CI チェックを実行 4. 結果を Issue に報告 12
13. どうやって実現しているか Claude Code の Skill 機能 を使っています .claude/skills/feature-testing/SKILL.md を設置: --- name: feature-testing description: After feature implementation, determine testing strategy (browser integration test or CI-only) and report results to the issue --- # Feature Testing Flow 1. Determine testing strategy 2. Prepare test plan 3. Execute tests 4. Report test results 13
14. Skill に組み込んだルール NEVER report test results to the issue if tests are incomplete or have not been executed. Only report facts that were actually verified. 意訳: テストが未完了・未実行の場合は、絶対に結果を Issue に報告しない 実際に確認した事実だけを報告する AI に嘘をつかせないようにして Skill に組み込んでます 14
15. 例: テストプランと結果を Issue に投稿 テストプラン（事前） テスト結果（事後） 15
16. ブラウザも操作させてテスト chrome-devtools MCP 経由で、Claude がブラウザを直接操作します ページ遷移 (navigate_page ) フォーム入力 (fill_form ) クリック (click ) 要素の待機 (wait_for ) スクリーンショット (take_screenshot ) DOM スナップショット取得 (take_snapshot ) 人がブラウザを触るのと 同じこと を Claude がやってくれます 16
17. ログインも、Skill で自動化 ログインが必要な画面に当たったら、browser-login Skill が自動で起動 1. ログイン画面にリダイレクトを検知 ↓ 2. セッションクリア（localStorage / cookie 全消し） ↓ 3. ログインフォーム入力 → 送信 ↓ 4. 「ホーム」表示を待機して完了確認 ↓ 5. 元々アクセスしたかった URL に戻る → 認証の壁も突破したうえで、ブラウザテストをしてくれます 17
18. CI 失敗時: 自動分析と Issue 起票 E2E テストが落ちると、Claude が自動で分析して Issue を起票します 例: #1031 E2E Failure [stable-dev] 根本原因の分析と、関連 PR の紐付けまで自動 18
19. どうやって実現しているか GitHub Actions の workflow_run トリガーで、E2E 失敗時に Claude API を直接呼んで 分析します 1. デイリーリグレッション (9:00 / 16:00 JST) で E2E 実行 2. 失敗 → workflow_run トリガーで分析ワークフロー起動 3. レポート artifact + 関連リポジトリのマージ済み PR を収集 4. Claude API (claude-sonnet-4-6) を curl で叩いて分析 5. GitHub Issue を作成 or 既存 Issue にコメント追加 → 毎日のリグレッションが落ちたら、自動で Issue が立つ 19
20. Issue 管理の細かいところ E2E Failure [stable-dev] labels: automated / e2e-failure / runner:stable-dev 1ランナーにつき1つの open Issue を維持 初回失敗 → 新規 Issue 起票 連続失敗 → 既存 Issue に Recurrence - YYYY-MM-DD コメント追加 修正されて成功しても Issue は open のまま、人がクローズする 同じ失敗で Issue が重複しないようにしています 20
21. ヘルプの自動書き換え helpdesk-sync-reviewer Agent が PR の変更からヘルプ更新の必要性を判定します 1. PR の差分を検知（機能追加・仕様変更・挙動修正） 2. 該当するヘルプドキュメントを横断検索 (apps/dashboard/src/app/help/_contents/ 配下: 見積 / 契約 / 設定 / テンプレート / 通知 等) 3. 更新が必要なドキュメントを特定 → 差分を提案 4. ユーザーに「PRに含める / 別PR / 後で対応」を聞く 「実装したけどヘルプ未更新」がなくなりました 21
22. 一次調査の MCP 連携 開発だけじゃなく、Slack / Notion / Datadog の MCP にも繋いで 一次調査をやり始めました アラート起票時の調査 過去事例の Notion からの参照 Datadog のメトリクスとログを横断 22
23. アラート対応のフロー 23
24. 例: アラート発火時の自動調査 alert-triage という Skill が、ソースコードやDatadogなど様々な情報から原因を調査し、Slackに投稿 アラート調査結果 概要: subscription-ctx リーダーDB プールのコネクション枯渇 （12本全て使用中、認証処理がタイムアウト） 影響: monolith-api の認証処理（ログイン/API呼び出しが失敗の可能性） 原因: 同日 17:11 の RDS CPU アラートと相関（RDS 高負荷で接続応答不能と推定） 対応: Pod 再起動で回復済み（接続数 12本は少ない可能性、再発リスクあり） → エンジニアの対応工数も大分減りました 24
25. ここから、開発を飛び越えた話 25
26. CS チームも組織的に AI 活用してます Salesforce CLI でペルソナ構築支援 Notion MCP でプロバイダー情報からスタッフ回答を確認 Slack / Notion / Gmail 横断で朝一タスクチェック 他システムからのデータ移行時の名寄せルールを Claude が生成 ペイメント周りの収益関連クエリ作成 案件引き継ぎ: Notion議事録 + Slackやり取りから顧客状況を把握 → チームで AI 活用 MTG も実施、共有と標準化を進めてます 26
27. Skill を全社配布する仕組みも CS MTG のアクションアイテム: Claude スキルのファイル化と配布方法を検討・実装 CS チーム向けの共有スキルリポジトリ作成 個人用プラグインとして、各自の環境にインストール フィードバックを集めて精度向上 将来的には組織レベルのプラグイン機能へ エンジニア発の仕組みを、非エンジニアに配布するルートを設計中 27
28. プロダクトにも、AI を組み込みました Scalebase AI Agent ブランドで、AI 機能を継続的にリリースしています 28
29. 第1弾: 契約登録エージェント 営業書面（PDF）から 契約データを Scalebase に自動登録 契約登録時間 90% 削減 （数分の入力 → 数十秒の確認） ヒューマンエラー対策にも効く 決算リードタイムも数日短縮 29
30. 第2弾: Scalebase MCP α版 顧客自身の AI ツールから Scalebase を直接操作できる 顧客の AI ツール (Claude Desktop / Claude Code / Cursor) ↓ Scalebase MCP ↓ Scalebase API ユースケース: 経理: 入金消込CSV → 数百件の請求を一括処理 営業: 商談クロージング → 顧客作成 → 契約 → 請求を一気通貫 分析: Salesforce 売上予測 × Scalebase 実績 → AI が予実差異レポート 30
31. 採用にも、AI を活用しています 候補者の評価、スカウト文面の提案、面接準備 採用業務そのもの に、Claude を組み込んでます 31
32. 例: YOUTRUST スカウトの自動評価 候補者評価結果 マッチ度: 中（72点） おすすめポイント: ・TypeScript 5年以上、DDD 3年以上 気になる点: ・フロント経験の記載なし ┗ by Claude Code レジュメのチェックなど時間がかかっていたこともスムーズに 32
33. 採用ターゲットも、変えています 求めるスキルセットそのものが、変わってきました コードを書く力は、AI で誰でも上がる だから、AI を前提に動ける人 を見るようになりました 33
34. 組織の価値観にも、AI を乗せました 会社の行動指針 5つのうちの1つに、こう書いてます AIに熱狂し、常識を変える テクノロジーの進化を誰よりも楽しみ、使い倒す。 AIを相棒とし、これまでの「当たり前」を覆す。 会社全体の価値観として、明確に AI が組み込まれてます 34
35. エンジニア向けの行動指針も作りました 会社の行動指針を、エンジニア向けにシンプルに 2つ に翻訳 1. 顧客が真に感動するものを、領域を越え届けよう 2. AIを主役に、速度で期待を超えていこう 特に2つ目は、エンジニアに 「ドライバーを AI に譲る覚悟」 を求めています 「自分で書いた方が早い」を一度手放して、AI に渡せる形に整え直す 35
36. エンジニアの動き方の変化 Before After 仕事の中心 コードを書く 顧客の業務を変える AIの位置づけ 助手席（補助） 主役（書き手） 役割の線引き 職種で区切る 領域を越えて担う 速さと品質 トレードオフ 速さを「型」で支える エンジニア個人の動き方まで、価値観として明文化 しています 36
37. エンジニアの役割も、変わってきます 37
38. 例: エンジニアが「領域を越える」 少し前まで PdM が仕様を考える エンジニアは実装に集中 今 エンジニアが 問いを立てる ところから入る 自分で Insight（顧客の声・要望データ） を見に行く 顧客と直接コミュニケーション を取る 行動指針が言ってる 「顧客が真に感動するものを、領域を越え届けよう」 の動きが、エンジニア発で始 まっています 38
39. 例: エンジニアが自分で情報収集 エンジニアが、各データソースを Claude Code で横断して分析してます Slack #product-request から顧客要望を取得（Notion インサイト連携） Notion インサイト DB で詳細を確認 Datadog でメトリクス・ログを参照 Jenkins ジョブ実行履歴 で運用負荷を測定（jenkins-stats Skill） GitHub PR/Issue で実装影響範囲を分析 PdM の指示待ちじゃなく、自分で情報を集めて、企画まで起こす 39
40. 例: インサイト633件を分類した PR 3ヶ月分の Slack #product-request を全件取得（19ページ分）→ Claude が分類 Scalebase インサイト分析レポート（633件） Frontend完結: 19件 ( 3%) Front/Back 軽量: 305件 (48%) ← 請求書/帳票118件、CSV/レポート77件 Front/Back 重量: 160件 (25%) ← 契約柔軟性75件、収益認識47件 Backend完結: 134件 (21%) ← 一括改定64件、会計連携43件 温度感別、顧客別、機能企画別までブレイクダウン 40
41. だからこそ、FDE という言葉が 41
42. これからの話 42
43. それぞれの役割を、変えていく 43
44. 結果として、少人数で圧倒的に動ける ひとりで複数の機能を、数倍の速度で動かせる。 「人を増やそう」という議論を、AI で成立させて不要にする。 少人数で回せる → コミュニケーションコストも、事業のコストも下がる。 生まれた余力を、個人への還元 や 新しい挑戦への投資 に振り向ける → これが、私たちが目指している 「組織でやる AI駆動」 44
45. AIで速度を作り、時間を顧客に向ける 行動指針が描いているサイクル: 1. AIで速度を作る 2. 生まれた時間で 顧客に向き合う 3. 顧客から得た理解を、AIに渡す 4. また AI で速度を作る これを ひとりひとりが自律的に まわしていく組織を、これから作っていきたいです 45
46. ありがとうございました 村濱 一樹 / @muraaaaa_san Scalebase株式会社 VPoE 一緒に 「組織でやる AI 駆動」 やりませんか 積極採用中（エンジニア / PdM / CS / 営業） 気軽に @muraaaaa_san まで is.gd/5BQN7d 46