組織再編の意思決定は、終わってから「あれは正解だったのか」と問い直しても、感覚だけでは答えが出ません。体制変更が現場に効いたのかどうかは、関係者の手応えや雰囲気だけで判断できる対象ではないからです。

この記事では、開発組織の再編を「評価しづらさの正体」「3つの観点での見方」「自社の開発データでの検証結果」「データで分かることと分からないことの線引き」という流れで整理します。

Findy Team+ MCP を使い、自社の実データで再編後の変化を追いました（Findy Team+ MCP の詳細は本記事の「Findy Team+ MCP とは」セクションをご参照ください）。同じ問いを抱える方が、自社の再編評価にそのまま転用できる視点を持ち帰れる内容です。

なぜ「体制変更は成功したのか？」に答えるのは難しいのか

体制変更の評価が難しい理由は、3つに分類できます。

1. 予測の難しさ
体制変更は、やってみるまで結果が分かりません。ソースコードのリファクタリングなら「内部構造を変えてもテストが通るから挙動は壊れていない」と事前に検証できますが、組織の再編には同じ安全網がありません。「3チームを2チームにまとめたらどうなるか」を事前にシミュレーションする手段はなく、マネージャーは不確実性のなかで決断を迫られます。

2. 単一の指標では測れない
チームごとに人数も得意領域も目標も異なるため、再編後に「何が先に安定するか」もチームによって変わります。具体的には、あるチームはリードタイムが短くなって早く安定する一方、別のチームはまずPR数を急増させる、というように成功の現れ方がずれます。画一的なものさしを当てても、各チームの変化を正しく捉えられません。

3. 複数の要因が同時に絡む
今回の再編では、メンバーのシャッフル・人数減少・チーム数減少が一度に起きました。さらに新体制への移行と並行して、AIコーディングツールやAIレビューツールの活用も進みました。PR数やレビューコメント数の増加には、このAI活用の効果も寄与しています。複数の要因が重なるため、特定の要因だけを切り出して「これが効いた」と評価するのは困難です。

ある一時点のスナップショットで判断するのではなく、どの側面が改善し、どこにリスクや伸び代が残るのかを多面的かつ継続的に把握する姿勢が重要になります。

体制変更をデータで評価する3つの観点

組織再編の成否を語るとき、一つの数字や印象に頼りがちになります。

• 「前より忙しくなった（気がする）」
• 「xxさんと働けてめっちゃ成長できた（気がする）」
• 「チームワーク生まれてきた（気がする）」
• 「レビューが前より厳しくてマージまでのリードタイムが伸びた（気がする）」

これらの感覚はもちろん重要なアラートになり得ますが、それだけでは次のアクションにつなげることが難しいといえます。

開発組織は速度・品質・量・プロセスが絡み合う複雑なシステムです。再現可能な形で再編を評価するには、観点をあらかじめ定めておく必要があります。

観点1：多面的に見る（速度・品質・量・プロセス）

単一の指標では再編の成否を語れません。「リードタイムが伸びた」という事実だけでは、悪化なのか健全な変化なのか判断できないからです。開発プロセスを速度・品質・量・プロセスの複数次元で同時に見ることが重要です。

速度はリードタイム、つまりPRのコミットからマージまでの所要時間で測ります。品質はレビューの状況を見ます。レビューコメント数やレビューなしマージ率などが手がかりになります。量はPRの作成数・マージ数やIssueの数で捉えます。

プロセスは各フェーズへの分解で評価します。Findy Team+ のサイクルタイム分析では、PRのコミットからマージまでを「①コミット〜オープン ②オープン〜レビュー ③レビュー〜アプルーブ ④アプルーブ〜マージ」の4プロセスに分解できます。どのフェーズが伸びたかまで分解すれば、原因の当たりをつけられます。

組織全体のパフォーマンスを測る代表的な指標群として、Four Keysも併せて見ると、現場の変化を経営の言葉に翻訳しやすくなります ※1 ※2。

観点2：時系列で見る（一過性の混乱か、構造的な問題か）

体制変更の影響を一時点のスナップショットで評価してはいけません。新しいチームは時間をかけて立ち上がるからです。チームの成熟段階を説明する考え方に「タックマンモデル」があります。チームは形成期→混乱期→統一期→機能期という段階を経て成熟するという見方です ※3。

月次の時系列で数値を追えば、変化を正しく読み解けます。たとえば立ち上げ初月の数値悪化は一過性のコストであり、構造的な問題ではないと判断できます。逆に特定のチームでコストが数ヶ月にわたり継続するなら、チーム設計や開発プロセスの根本的な改善が必要だと読み取れます。

時系列で比較するときは、体制変更の前後で比較対象が変わる点にも注意します。チーム数やメンバー構成が変われば、数値の母数も変わります。前後を単純に並べるのではなく、構成の変化を踏まえて解釈します。

観点3：公平な比較基盤を持つ（「感覚」から「数字」へ）

再編後のふりかえりは主観的な感想に流れがちです。「前より忙しくなった気がする」「レビューが厳しくなってマージが遅くなった気がする」といった感覚は、見逃せない重要なアラートです。しかし感覚だけでは次のアクションにつなげにくいという弱点があります。

各フェーズを定量的に分解すれば、感覚だけでは辿り着けない洞察に到達できます。たとえばリードタイムの増減は、フローの遅延ではなくPR規模の変化やAI活用が原因の場合もあります。数字に分解して初めて、本当の原因が見えてきます。

共通の数字を持てば、議論そのものが変わります。「前のチームが良かった」といった政治的になりやすい議論も、同じ数字を基盤にすれば建設的に進められます。再編の評価では、組織全体が信頼できる比較基盤を共有することが何よりも効きます。

Findy Team+ MCP とは

AIから Findy Team+ の指標を直接呼び出し、レポート作成・チーム・個人分析・示唆出しを効率化できる連携機能です。

MCP（Model Context Protocol）は、AIが外部のデータやツールに対話形式でアクセスするための標準プロトコルです。Findy Team+ MCP はこの仕組みを利用しており、Claude Code や Cursor などの MCP 対応クライアントから Findy Team+ の API に直接接続できます。利用開始には、Findy Team+ の管理画面で API キーを発行し、AIクライアントの設定ファイルに接続情報を追加するだけです。

主な特徴は3つあります。

自然言語で分析できます。 「先月のサイクルタイムは？」「開発チームのボトルネックは？」など、普段の言葉で質問するだけで、リードタイム・PR数・レビュー状況・Four Keys といった指標を取得・分析できます。各指標はチーム単位・個人単位のいずれでも取得可能です。

コンテキストを与えてデータに意味を持たせられます。 データだけを見るのではなく、背景やチームの情報をAIに渡すことで、データに意味や解釈を持たせることが可能になります。

他ツールと組み合わせられます。 Notion・Slack・JIRA・Google Calendar などと接続することで、定例レポートの自動作成・共有や、分析フローの自動化にも活用できます。

【自社事例】チーム構造を変更した後の6ヶ月間をMCPで追ってみた

Findy 社内の開発組織では、2025年下期から2026年上期にかけて、3チーム13名から2チーム11〜12名へのチーム構造の変更を実施しました。どんな変更だったかをもう少し補足します。

13名から12名への微減は、単純な人員カットではありません。内訳は、4名が他プロダクトへ異動し、3名が横断チームから編入した入れ替えです。

さらに、新体制は旧チームの延長ではなく、メンバーをいったんバラして再配置しました。各チームの開発プロセスを一部は踏襲したものの、新しくジョインしたメンバーも混在し、チーム内に蓄積されていた暗黙知や協力関係は一定リセットされています。つまり立ち上げ期には、新しい関係づくりや進め方のすり合わせに伴う一過性のコストが乗る前提で、データを読む必要があります。

このチーム構造の変更が開発活動に与えた影響を、Findy Team+ MCP を使って分析しました。Findy Team+ MCP を経由すると、ダッシュボードを開いてスプレッドシートに手動転記して集計する作業を介さず、対話形式の指示だけで複数チーム・複数月のデータを数分で取得・比較できます。

今回は5チーム×半年間×15指標以上のデータを収集しました。ここからは、実際に引き出したデータを、分析した順に追っていきます。

分析にあたって、2つ前提を置いています。1つは、一人あたり指標の分母を旧体制13名、新体制11.5名で算出した点です。もう1つは、この期間にAI活用が同時進行している点です。Claude Code 等のコーディングツールと GitHub Copilot 等のレビューツールを併用しており、アウトプット増には AI 活用の効果も寄与しています。

変更前：3チームのベースラインをMCPで取得する

分析は、変更前の状態をMCP経由でデータを取得するところから始めました。次の表は、2025年10〜12月の旧3チーム合算の月次推移です。

この3チームは、リードタイムの加重平均が5.1h、レビューなしマージ率も0〜5%台で、レビュー規律はおおむね保たれていました。PR作成数は月によって591〜860件と振れがありますが、月平均では713件です。この水準を起点として、変更後の2チームがどう動いたかを追っていきます。

変更後：人数が減ったのにPRは増えた

続いて、変更後の月平均アウトプット量を、旧3チーム合計と新2チーム合計で並べました。

人数を1〜2名減らしたにもかかわらず、総量はいずれの指標でも増加しました。一人あたりに換算すると、その差はさらに明確になります。

一人あたりの PR 作成数は +34.3% に達しました。チーム数を3から2へ減らしたことでチーム間のコミュニケーションコストが下がった影響に加えて、AI コーディングツールの活用拡大も寄与していると考えられます。

速度と品質：リードタイムは微増、だがフローは悪化していない

量が増えたことを確認したら、次は速度と品質を引き出します。アウトプットが増えてもリードタイムや品質がトレードオフになっていないかが気になるところです。

リードタイムは約14%増えました。ただし、サイクルタイムを工程ごとに分解すると、初回レビューまで・レビューから承認・承認からマージの各フェーズはいずれも維持か微改善です。レビューのフロー自体は遅くなっていないことがわかります。

品質面では2つの指標に注目します。

PR あたりコメント数は +24% と増えました。ただ、この数値には AI レビューツールの自動コメントも含まれるため、人手のレビューが厚くなったとは即断できない点は注意が必要です。

レビューなしマージ率は0.7%から3.6%へ上昇しました。

この変化を読み解くには、チームごとの変化を追っていく必要があります。AIに、チームごとの月次推移を聞いてみましょう。

チームA（4〜5名）の月次推移

チームB（7名）の月次推移

チーム別に比較すると、チームBでレビューなしマージ率が特に高い傾向が見られました。

この背景を確認したところ、要因はAIレビューの導入にありました。

チームAにはバックエンド領域のエキスパートが、チームBにはフロントエンド領域のエキスパートが所属しています。AIレビューはまずフロントエンド領域で導入が進み、その推進をチームBのテックリードが担っていたため、チームBの「レビューなしマージ率」の数値に大きな影響がありました。

この結果から、AIレビューの活用は一部チーム・一部領域にとどまっていることがわかります。今後は、チーム間での連携や、バックエンド領域への展開可能性を検討していく必要がありそうです。

このように、組織の状態は単一指標では測れません。アウトプット・速度・品質・チームごとの推移を多面的に重ねて初めて、チーム構造変更の影響や、次の打ち手を立体的に読み取れます。

評価を「一度きり」で終わらせない

体制変更や取り組みの評価は、過去を採点して終わるものではありません。変更後に何が起きているかを速やかに・正確に・多面的に把握し、必要な軌道修正を素早く打つことに本質的な価値があります。「観測 → 判断 → 修正」のサイクルを回し続けてこそ、体制変更は当初の狙いに近づいていきます。

従来、この種の分析には手間がかかりました。ダッシュボードを一つずつ閲覧し、数字を手動でスプレッドシートに転記して集計する。担当者の時間を奪い、頻度を上げにくい作業でした。Findy Team+ MCPを使えば、同じ分析を再現性をもって繰り返せます。観測する時間軸を半年、一年と広げることも容易になります。

運用への接続も進めやすくなります。チームで伸び代と捉えた指標を定期的に取得し、閾値を超えたらアラートを出す。こうした継続運用に組み込めば、変化の兆候を早期に拾えます。

単発の振り返りで満足せず、評価軸を日常運用に組み込みましょう。一度きりの採点ではなく、回り続けるサイクルとして評価を設計する。この発想が、体制変更や取り組みを「やりっぱなし」にしない鍵になります。

まとめ

本記事のポイント

• 体制変更の成否は単一指標では測れません。速度・品質・量・プロセスを多面的に見ることで、初めて全体像がつかめます
• 数字は時系列で追い、一過性の混乱と構造的な問題を区別します
• 共通の数字を基盤にすれば、感覚や政治を排した建設的な議論ができます
• 評価は一度きりにせず、継続モニタリングへ接続します

組織再編の成否をはじめ、開発組織の意思決定は、誰かの印象や声の大きさで決まるものではありません。開発プロセスの各フェーズを定量的に分解し、時系列で追うことで、変化の在り処を具体的に語れるようになります。Findy Team+ はこの可視化を支援し、専任のカスタマーサクセスが運用の立ち上げに伴走します。

Findy Team+ MCPを使えば、対話形式でのデータ取得を効率化でき、同じ分析を継続的に繰り返せます。自社の体制変更の評価や、開発生産性の可視化に関心があれば、2週間の無料トライアルから試せます。まずは手元のデータで、自分たちの変化を確かめてみてください。

参考・出典

※1 Nicole Forsgren, Jez Humble, Gene Kim『Accelerate: The Science of Lean Software and DevOps（邦題：LeanとDevOpsの科学）』IT Revolution Press, 2018 / https://itrevolution.com/product/accelerate/

※2 DORA「DORA’s software delivery performance metrics（Four Keys）」dora.dev, 2024 / https://dora.dev/guides/dora-metrics-four-keys/ （※Four Keys の「サービス復元時間」は、DORA の現行定義では “Failed Deployment Recovery Time” に改称されています〔2023年〕。本記事では一般に普及した呼称を用いています）

※3 Bruce W. Tuckman「Developmental Sequence in Small Groups」Psychological Bulletin, 63(6), pp.384–399, 1965 / DOI:10.1037/h0022100