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

by microCMS

Embed

Start on current slide

Slide 1

Slide 1 text

microCMSの開発組織 2026 AI活用で進化するチームのかたち株式会社microCMS ⼤⻄智也

Slide 2

Slide 2 text

2 Index ● 技術スタック 2026 ● チームと役割 ● 品質向上の取り組み ● AIツールとその活⽤‧ガバナンス ● AIとの向き合い⽅

Slide 3

Slide 3 text

3 株式会社microCMS 開発部⻑⼤⻄智也 @TomoyaOnishi ● ● 旧ヤフー株式会社で約10年ソフトウェアエンジニアを経験 ○ メール、ヤフオク、PayPayフリマ、CTO室 ○ iOS、Webフロント、バックエンド、機械学習... 2022年5⽉にmicroCMSに⼊社 ○ ● 組織やバックエンドの課題解決を中⼼に業務趣味 ○ ゲーム、ドライブ、個⼈開発、Apple、AI

Slide 4

Slide 4 text

4 技術スタック 2026

Slide 5

Slide 5 text

5 技術スタック（バックエンド） ● ⾔語 ○ ● ○ ● Terraform DynamoDB、S3 検索 ○ OpenSearch AWS WAF、Cloudﬂare WAF フロントエンドとのリアルタイム通信 AppSyncEvent ○ ● Lambda、ECS、SQS データベース、ストレージ保護、レートリミット ○ ● 実⾏基盤 ○ ● Go, Node.js IaC ○ ● ● フィーチャーフラグ LaunchDarkly ○ ● その他 ○ Imgix、Stripe、HubSpot

Slide 6

Slide 6 text

6 技術スタック（フロントエンド） ● ⾔語 ○ ● ○ ● ● TanStack Query AppSyncEvent フィーチャーフラグ ○ ● React Router バックエンドとのリアルタイム通信 ○ Vite、Vitest 状態管理、API ルーティング ○ React ビルド、テスト ○ ● TypeScript UIライブラリ ○ ● ● LaunchDarkly Lint, Format ○ Biome

Slide 7

Slide 7 text

7 技術スタック（監視、QA） ● メトリクス監視、分析、ダッシュボード ○ ● Sentry 分散トレーシング ○ ● Checkly エラートラッキング ○ ● CloudWatch 外形監視 ○ ● Grafana、 OpenTelemetry テスト管理 ○ Qase

Slide 8

Slide 8 text

8 技術スタック（開発環境） ● レポジトリ ○ ● 開発環境 ○ ● devcontainer ■ ツールやバージョン、開発に関する仕組みを共通化 ■ バージョン違いや環境の差異によるエラーの解決など無駄を減らすツール管理 ○ ● モノレポ mise タスクランナー ○ Task(Go)

Slide 9

Slide 9 text

9 チームと役割

Slide 10

Slide 10 text

10 チームと役割ストリームアラインドチームプラットフォームチーム • 顧客に価値を届ける (Delivery) • バックエンドの信頼性の向上 • 新機能、改善、SDK • オブザーバビリティ • フロントエンド＆ API • CI/CD、開発環境などの開発者体験の向上

Slide 11

Slide 11 text

11 チームと役割 QAチーム • 正社員として1⼈採⽤ • ⾃動テストの整備 • 品質とリードタイムの向上 • 開発チームとのコラボレーション • 受け⼊れテスト ◦バグバッシュ QAチームが⽴ち上がったことで品質向上をより強⼒に推進

Slide 12

Slide 12 text

12 品質担保の観点 ● 正確性（Correctness） ○ ● ● サービスが仕様通りか信頼性（Reliability） ○ サービスが不安定なく使えるか ○ 稼働率、エラー率、レイテンシー健全性（Engineering Health） ○ 設計が壊れていないか、⼀貫性があるか ○ 効率的に運⽤できるか ○ システム設計、コードヘルス、CI/CD、開発環境の整備など ○ = 秩序をもたらす

Slide 13

Slide 13 text

13 品質担保の観点正確性信頼性健全性 Correctness Reliability Engineering Health ストリームアラインドチーム QAチームプラットフォームチーム

Slide 14

Slide 14 text

14 チャプター ● チームを横断する技術、運⽤の意思決定が曖昧になることがあった ● Go チャプター Go Chapter コード設計、lintルール、ライブラリ選定、運⽤フローなどを主体的に意思決定する役割 ● チーム横断で横串となるグループ ● AIで課題の発⾒も⾼速化したため、意思決定のフロントエンドチャプター Frontend Chapter 速度がより重要にアラートチャプター Alert Chapter

Slide 15

Slide 15 text

15 品質向上の取り組み

Slide 16

Slide 16 text

16 品質向上の取り組み ● ● ● 複数のレイヤーの⾃動テストをさらに拡充 ○ スモールテスト（ユニット） ○ ミディアムテスト ○ ラージテスト（E2E）外形監視やメトリクス監視などを強化 ○ Checkly、Grafana ○ 顧客よりも早く気づく取り組み AIコンテキストの拡充 ○ ⽣成するコードは品質に直結する

Slide 17

Slide 17 text

品質向上の取り組み ● リリース⽅法の変更 ○ リリース頻度を週１から継続的デプロイに ● ○ 価値提供のリードタイムを短く ○ 不具合を素早く修正今年はすでに300回超のデプロイ

Slide 18

Slide 18 text

18 品質向上の取り組み ● QAエンジニアの採⽤ ○ ● 受け⼊れテストの作成、実施 ■ エンジニアから作業を巻き取り、効率化 ■ 知⾒を集約 ○ 外形監視、⾃動テストの整備をより強化 ○ テストの知⾒をコンテキスト化し、AIの⾃動テストの精度向上 Change Failure Rateの計測を開始 ○ 不具合のあったリリース / リリース数

Slide 19

Slide 19 text

19 AIツールとその活⽤‧ガバナンス

Slide 20

Slide 20 text

20 コーディング ● ● Cursor ● Claude Code ● Codex Cursorを中⼼としつつ、好みで選択可能 ○ 現時点で絞ることは難しい ● コンテキストファイルは symlink で共有 ● メイン⾔語のGoはAI時代にマッチ ● ○ 強い静的型付けで、⽂法がシンプル ○ ⼈が書いてもAIが書いてもほぼ同じ ○ lintやコンテキストで制御する必要がない AIの使い⽅も現時点では統⼀していない ○ 仕様駆動？プラン？ ○ ハーネス？ループ？

Slide 21

Slide 21 text

21 コードレビュー ● CodeRabbit ○ ● Cursor Bugbot ○ ● コードの⼀貫性など汎⽤的な指摘不具合特化 Cursor Security Reviewer ○ セキュリティ特化 ● レビューは疲れるので積極的に負荷を減らす

Slide 22

Slide 22 text

その他の活⽤事例 ● Qase MCP ○ テストケースの観点チェック、作成⽀援をトライアル中 ○ 仕様からテストケース作成までの⾃動化を⽬指す ● ● Notion、Slack ○ 情報収集 ○ コーディングプラン作成 GitHub ○ ● リリースノートから不具合の原因調査 Sentry ○ アラートの⼀次調査とトリアージ

Slide 23

Slide 23 text

23 ⽣産性は上がったのか？ ● Cursor導⼊（2025年2⽉）前と⽐べてさまざなメトリクスが⼤幅上昇した ○ ⽉間PRマージ数 ■ ○ ⽉間リリース数 ■ ○ 9.0→16.6 マージまでのリードタイム ■ ○ 18.7→51.4 ⼀⼈当たりPR数 ■ ○ 143 → 317 2時間以内エンジニア数がほぼ⼀定全体としては⼤幅に⽣産性が向上したと⾔える

Slide 24

Slide 24 text

24 ソフトウェアガバナンス ● 各ソフトウェアは社内規定に則り、法務‧データプライバシーなどの観点で承認を得て利⽤する ● MCPやCLI呼び出しなどで境界が曖昧になりつつある ○ 個⼈情報取り扱いOKのツールと、NGのツールがMCPで接続してしまうなどが発⽣しないように管理

Slide 25

Slide 25 text

25 ソフトウェアガバナンス ● 昨今のセキュリティインシデント多発を受けて、利⽤可能なソフトウェアを強めに絞った ○ CLI、依存ライブラリ、Chrome、Cursorなどの拡張機能など全てのソフトウェアを整理 ● 開発環境はdevcontainerで統⼀ ● 特にCIで動かす軽微なものはAIで⾃作 ● 好みのソフトウェアよりもセキュリティやチームでの効率を優先 ○ ● AIの登場により⽣産性向上のボトルネックはツールではなくなったか（？） MCPなどの設定は設定ファイルで共有

Slide 26

Slide 26 text

多層的なセキュリティ対策 ● GitHub Enterprise ○ SAMLログイン必須 ○ ActionsのPinning必須 ○ ポリシー整備 ● Takumi Guardなどのレジストリプロキシ ● Cursor Security Agents ● ● ○ Security Reviewer ○ Vulnerability Scanner セキュリティソフト ○ 振る舞い検知型 ○ 不審なネットワークの監視‧遮断 Checkov, OSV-Scanner ...

Slide 27

Slide 27 text

27 AIとの向き合い⽅

Slide 28

Slide 28 text

28 AI活⽤のチーム⽅針 ● 世の中にはAI強気派と保守派がいる ○ 強気派：ソフトウェア開発の知識は不要になる、全てAIに任せれば良い ○ 保守派：AIは強⼒なツールだが、ソフトウェア開発の知識やエンジニアリング能⼒は今後も重要 ● 様々な論があるので、あとはチームでの決めの問題 ● microCMSは「保守派」の地に⾜をつけたスタンスを採⽤し、チームの認識を合わせた

Slide 29

Slide 29 text

29 なぜ「保守派」としたか ● 業務レベルのシステムがAIで完全に置き換わるのは⻑期的な話 ● 最終的な変更の責任はエンジニアが負う ● 知識がないエンジニアが知識のあるエンジニアを上回るイメージが持てない ○ 現時点ではAIはレバレッジをかけるツール ● AI関係なくソフトウェアエンジニアとして成⻑はしてほしい ● いずれにせよAIを積極的に使うので取り残されるわけでもない

Slide 30

Slide 30 text

30 具体的には ● ● ● AIが⽣成した「変更」は理解しておく ○ ≠ コードを1⾏ずつ確認する ○ どのような変更か、なぜ必要なのか品質への責任は持ち続ける ○ AIで⽣産性が上がっても品質が落ちては意味がない ○ リリース数が増えるので割合が同じでもダメチーム開発のルールは守る ○ AIが⽣成したコードであっても、「アーキテクチャ、コーディングルール、ライブラリの使い⽅、慣習」を守る ○ 逸脱すると他のメンバーにストレスを与え、コードヘルスが低下する ○ ルールが適切でない場合は、提案する

Slide 31

Slide 31 text

31 AIで生産性を上げながらも、ソフトウェアエンジニアとしての成長、責任は手放さない

Slide 32

Slide 32 text

32 本⽇話せなかった、働き⽅や⽂化については⼤きく変化はないため、前回の資料をご覧ください 🙏 https://speakerdeck.com/microcms/ microcmsnokai-fa-zu-zhi-deep-dive-i nto-microcms

Slide 33

Slide 33 text

33 採⽤情報

Slide 34

Slide 34 text

34 採⽤情報 ● ● プラットフォームチーム ○ インフラの管理 ○ バックエンドの⾮機能要件の改善 ○ CI/CD、開発環境などの開発者体験の改善こんな⽅に来てほしい ○ Goの経験がある ○ サーバーレスなAWSの経験がある ■ Lambda, ECS, CloudFront, DynamoDB, SQS, S3, OpenSearch ○ バックエンドの改善経験がある ○ コミュニケーションをしっかり取りつつ、⾃律してタスクを進められる詳細‧応募はこちら

Slide 35

Slide 35 text

35 ご清聴ありがとうございました！