microCMSの開発組織 2026：AI活用で進化するチームのかたち

microCMS Meetup 2026 SESSION3で発表したスライドです。
https://microcms.connpass.com/event/394654/

1. microCMSの開発組織 2026 AI活用で進化するチームのかたち 株式会社microCMS ⼤⻄ 智也
2. 2 Index • 技術スタック 2026 • チームと役割 • 品質向上の取り組み • AIツールとその活⽤‧ガバナンス • AIとの向き合い⽅
3. 3 株式会社microCMS 開発部⻑ ⼤⻄智也 @TomoyaOnishi • • 旧ヤフー株式会社で約10年ソフトウェアエンジニアを経験 ◦ メール、ヤフオク、PayPayフリマ、CTO室 ◦ iOS、Webフロント、バックエンド、機械学習... 2022年5⽉にmicroCMSに⼊社 ◦ • 組織やバックエンドの課題解決を中⼼に業務 趣味 ◦ ゲーム、ドライブ、個⼈開発、Apple、AI
4. 4 技術スタック 2026
5. 5 技術スタック（バックエンド） • ⾔語 ◦ • ◦ • Terraform DynamoDB、S3 検索 ◦ OpenSearch AWS WAF、Cloudflare WAF フロントエンドとのリアルタイム通信 AppSyncEvent ◦ • Lambda、ECS、SQS データベース、ストレージ 保護、レートリミット ◦ • 実⾏基盤 ◦ • Go, Node.js IaC ◦ • • フィーチャーフラグ LaunchDarkly ◦ • その他 ◦ Imgix、Stripe、HubSpot
6. 6 技術スタック（フロントエンド） • ⾔語 ◦ • ◦ • • TanStack Query AppSyncEvent フィーチャーフラグ ◦ • React Router バックエンドとのリアルタイム通信 ◦ Vite、Vitest 状態管理、API ルーティング ◦ React ビルド、テスト ◦ • TypeScript UIライブラリ ◦ • • LaunchDarkly Lint, Format ◦ Biome
7. 7 技術スタック（監視、QA） • メトリクス監視、分析、ダッシュボード ◦ • Sentry 分散トレーシング ◦ • Checkly エラートラッキング ◦ • CloudWatch 外形監視 ◦ • Grafana、 OpenTelemetry テスト管理 ◦ Qase
8. 8 技術スタック（開発環境） • レポジトリ ◦ • 開発環境 ◦ • devcontainer ▪ ツールやバージョン、開発に関する仕組みを共通化 ▪ バージョン違いや環境の差異によるエラーの解決など無駄を減らす ツール管理 ◦ • モノレポ mise タスクランナー ◦ Task(Go)
9. 9 チームと役割
10. 10 チームと役割 ストリームアラインドチーム プラットフォームチーム • 顧客に価値を届ける (Delivery) • バックエンドの信頼性の向上 • 新機能、改善、SDK • オブザーバビリティ • フロントエンド ＆ API • CI/CD、開発環境などの開発者体験の向上
11. 11 チームと役割 QAチーム • 正社員として1⼈採⽤ • ⾃動テストの整備 • 品質とリードタイムの向上 • 開発チームとのコラボレーション • 受け⼊れテスト ◦バグバッシュ QAチームが⽴ち上がったことで品質向上をより強⼒に推進
12. 12 品質担保の観点 • 正確性（Correctness） ◦ • • サービスが仕様通りか 信頼性（Reliability） ◦ サービスが不安定なく使えるか ◦ 稼働率、エラー率、レイテンシー 健全性（Engineering Health） ◦ 設計が壊れていないか、⼀貫性があるか ◦ 効率的に運⽤できるか ◦ システム設計、コードヘルス、CI/CD、開発環境の整備など ◦ = 秩序をもたらす
13. 13 品質担保の観点 正確性 信頼性 健全性 Correctness Reliability Engineering Health ストリームアラインドチーム QAチーム プラットフォームチーム
14. 14 チャプター • チームを横断する技術、運⽤の意思決定が曖昧に なることがあった • Go チャプター Go Chapter コード設計、lintルール、ライブラリ選定、運⽤フ ローなどを主体的に意思決定する役割 • チーム横断で横串となるグループ • AIで課題の発⾒も⾼速化したため、意思決定の フロントエンド チャプター Frontend Chapter 速度がより重要に アラート チャプター Alert Chapter
15. 15 品質向上の取り組み
16. 16 品質向上の取り組み • • • 複数のレイヤーの⾃動テストをさらに拡充 ◦ スモールテスト（ユニット） ◦ ミディアムテスト ◦ ラージテスト（E2E） 外形監視やメトリクス監視などを強化 ◦ Checkly、Grafana ◦ 顧客よりも早く気づく取り組み AIコンテキストの拡充 ◦ ⽣成するコードは品質に直結する
17. 品質向上の取り組み • リリース⽅法の変更 ◦ リリース頻度を週１から 継続的デプロイに • ◦ 価値提供のリードタイムを短く ◦ 不具合を素早く修正 今年はすでに300回超のデプロイ
18. 18 品質向上の取り組み • QAエンジニアの採⽤ ◦ • 受け⼊れテストの作成、実施 ▪ エンジニアから作業を巻き取り、効率化 ▪ 知⾒を集約 ◦ 外形監視、⾃動テストの整備をより強化 ◦ テストの知⾒をコンテキスト化し、AIの⾃動テストの精度向上 Change Failure Rateの計測を開始 ◦ 不具合のあったリリース / リリース数
19. 19 AIツールとその活⽤‧ガバナンス
20. 20 コーディング • • Cursor • Claude Code • Codex Cursorを中⼼としつつ、好みで選択可能 ◦ 現時点で絞ることは難しい • コンテキストファイルは symlink で共有 • メイン⾔語のGoはAI時代にマッチ • ◦ 強い静的型付けで、⽂法がシンプル ◦ ⼈が書いてもAIが書いてもほぼ同じ ◦ lintやコンテキストで制御する必要がない AIの使い⽅も現時点では統⼀していない ◦ 仕様駆動？プラン？ ◦ ハーネス？ループ？
21. 21 コードレビュー • CodeRabbit ◦ • Cursor Bugbot ◦ • コードの⼀貫性など汎⽤的な指摘 不具合特化 Cursor Security Reviewer ◦ セキュリティ特化 • レビューは疲れるので積極的に負荷を減らす
22. その他の活⽤事例 • Qase MCP ◦ テストケースの観点チェック、 作成⽀援をトライアル中 ◦ 仕様からテストケース作成までの ⾃動化を⽬指す • • Notion、Slack ◦ 情報収集 ◦ コーディングプラン作成 GitHub ◦ • リリースノートから不具合の原因調査 Sentry ◦ アラートの⼀次調査とトリアージ
23. 23 ⽣産性は上がったのか？ • Cursor導⼊（2025年2⽉）前と⽐べてさまざなメトリクスが⼤幅上昇した ◦ ⽉間PRマージ数 ▪ ◦ ⽉間リリース数 ▪ ◦ 9.0→16.6 マージまでのリードタイム ▪ ◦ 18.7→51.4 ⼀⼈当たりPR数 ▪ ◦ 143 → 317 2時間以内 エンジニア数がほぼ⼀定 全体としては⼤幅に⽣産性が向上したと⾔える
24. 24 ソフトウェアガバナンス • 各ソフトウェアは社内規定に則り、法務‧データプライバシーなどの観点で承認を得て利⽤する • MCPやCLI呼び出しなどで境界が曖昧になりつつある ◦ 個⼈情報取り扱いOKのツールと、NGのツールがMCPで接続してしまうなどが 発⽣しないように管理
25. 25 ソフトウェアガバナンス • 昨今のセキュリティインシデント多発を受けて、利⽤可能なソフトウェアを強めに絞った ◦ CLI、依存ライブラリ、Chrome、Cursorなどの拡張機能など全てのソフトウェアを整理 • 開発環境はdevcontainerで統⼀ • 特にCIで動かす軽微なものはAIで⾃作 • 好みのソフトウェアよりもセキュリティやチームでの効率を優先 ◦ • AIの登場により⽣産性向上のボトルネックはツールではなくなったか（？） MCPなどの設定は設定ファイルで共有
26. 多層的なセキュリティ対策 • GitHub Enterprise ◦ SAMLログイン必須 ◦ ActionsのPinning必須 ◦ ポリシー整備 • Takumi Guardなどのレジストリプロキシ • Cursor Security Agents • • ◦ Security Reviewer ◦ Vulnerability Scanner セキュリティソフト ◦ 振る舞い検知型 ◦ 不審なネットワークの監視‧遮断 Checkov, OSV-Scanner ...
27. 27 AIとの向き合い⽅
28. 28 AI活⽤のチーム⽅針 • 世の中にはAI強気派と保守派がいる ◦ 強気派：ソフトウェア開発の知識は不要になる、全てAIに任せれば良い ◦ 保守派：AIは強⼒なツールだが、ソフトウェア開発の知識やエンジニアリング能⼒は 今後も重要 • 様々な論があるので、あとはチームでの決めの問題 • microCMSは「保守派」の地に⾜をつけたスタンスを採⽤し、チームの認識を合わせた
29. 29 なぜ「保守派」としたか • 業務レベルのシステムがAIで完全に置き換わるのは⻑期的な話 • 最終的な変更の責任はエンジニアが負う • 知識がないエンジニアが知識のあるエンジニアを上回るイメージが持てない ◦ 現時点ではAIはレバレッジをかけるツール • AI関係なくソフトウェアエンジニアとして成⻑はしてほしい • いずれにせよAIを積極的に使うので取り残されるわけでもない
30. 30 具体的には • • • AIが⽣成した「変更」は理解しておく ◦ ≠ コードを1⾏ずつ確認する ◦ どのような変更か、なぜ必要なのか 品質への責任は持ち続ける ◦ AIで⽣産性が上がっても品質が落ちては意味がない ◦ リリース数が増えるので割合が同じでもダメ チーム開発のルールは守る ◦ AIが⽣成したコードであっても、「アーキテクチャ、コーディングルール、ライブラリの 使い⽅、慣習」を守る ◦ 逸脱すると他のメンバーにストレスを与え、コードヘルスが低下する ◦ ルールが適切でない場合は、提案する
31. 31 AIで生産性を上げながらも、 ソフトウェアエンジニアとしての成長、責任は手放さない
32. 32 本⽇話せなかった、働き⽅や⽂化については⼤きく変化は ないため、前回の資料をご覧ください 🙏 https://speakerdeck.com/microcms/ microcmsnokai-fa-zu-zhi-deep-dive-i nto-microcms
33. 33 採⽤情報
34. 34 採⽤情報 • • プラットフォームチーム ◦ インフラの管理 ◦ バックエンドの⾮機能要件の改善 ◦ CI/CD、開発環境などの開発者体験の改善 こんな⽅に来てほしい ◦ Goの経験がある ◦ サーバーレスなAWSの経験がある ▪ Lambda, ECS, CloudFront, DynamoDB, SQS, S3, OpenSearch ◦ バックエンドの改善経験がある ◦ コミュニケーションをしっかり取りつつ、⾃律してタスクを進 められる 詳細‧応募はこちら
35. 35 ご清聴ありがとうございました！