AI前提のプロダクト開発組織を目指して、minneの2026年の現在地

情報元による記事紹介

はじめに minneでAI前提のプロダクト開発組織づくりを進めています。これまでは個別の仕組みについて書いてきましたが（PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていく、Claude Code Actionで複数リポジトリを横断して情報を参照し調査・実装を進めてもらおう）、この記事では組織とプロセスの側がどう変わったかを短くまとめます。2026年9月時点の現在地です。 AI自律マージ率 minneでは「PRサイズラベルの自動付与 → AIレビュー＆Approve → 条件付きauto merge」の3段構えを運用しています...

AIによる記事の要点

情報元の記事をもとに自動生成しています。誤りや省略が含まれる場合があります。詳細は元記事で確認してください。

【概要】 minneはAI前提のプロダクト開発組織への転換を進めており、2026年9月時点での組織構造とプロセスの変化をまとめた。PRサイズ自動付与→AIレビュー&Approve→条件付きauto mergeの3段構えで運用し、職能の垣根を越えた開発体制を実現している一方で、検証作業の負荷増加と自動判定の妥当性検証が新たな課題となっている。 【具体的なポイント】 ・**組織構造の変化**：従来の「WebはRails、モバイルはiOS/Android」という職能分離から、設計段階でWebエンジニア2人とモバイルエンジニア5人が協働し、サーバーサイド実装をモバイルエンジニアが担当する体制に転換した。AIが既存コード規約に沿った実装を担えるようになったため、フレームワーク経験の有無が越境の障壁になりにくくなった。 ・**自動マージの運用実績**：人間の手を介さずAIのApproveからマージまで完了したPRの割合を直近30日で測定・監視している。具体的な割合数値は本文に記載されていない。 ・**検証作業の増加と生産性**：週1サイクルのうちリリースと検証に日数を取られ、実装に充てられるのは実質2日ほどだが、AI前提の開発によって従来の1週間1スプリントと同程度かそれ以上のアウトプットをデリバリーできている。一方でモバイルの検証作業自動化が今後の課題である。 ・**バックテスト体制の整備**：AIのApprove判定の妥当性を後から再検証するため、月1回の頻度でサーバーサイドとモバイルそれぞれでバックテストを実施している。内部統制の観点から、サイズ判定の根拠がPRに残っているか、導入時点からの期間を抜けなくカバーできているか、全件を対象にできているかが論点になった。 ・**判定指標の設計**：サイズラベルは差分行数ではなく影響範囲で決定し、行数は検知に使うのみとしている。「XSなのに600行消えている」という乖離は見直す価値のあるサインとして機能し、判定に使っていない指標を検知に使うことでAIの判定を同じ物差しで確かめる構造を避けている。 ・**検証の二段構え**：全件を機械が見て怪しいものだけ人が見る体制とし、人が目視する量をゼロにはせず絞ることで、全件を人が見る運用の継続不可能性と同じ仕組みで同じ仕組みを確かめる問題を回避している。 ・**プロセス設計の重要性**：ツールの使い方よりも、チームの分け方・リリースの刻み方・自動化した判断の検証方法といったプロセス側の設計のほうが効いているというのが現時点の実感である。 【注目点】 検証作業の負荷が倍になった一方で、AI前提の開発により従来と同等以上のアウトプットを実現している点が、単なるツール導入ではなく組織プロセスの再設計がもたらした効果を示唆している。今後はモバイル検証の自動化と自動マージ対象サイズの拡大が進められる予定である。 **用語** - **auto merge｜AIの承認後、人間の確認なしに自動でコードをマージする機能** - **バックテスト｜過去のデータを使ってAIの判定が正しかったか後から検証する作業** - **PRサイズラベル｜プルリクエストの変更量を自動で分類するタグ**