フレームワークを減らすことがチームのベロシティを高める理由

「フレームワークを減らす」と「ベロシティ」は本当に何を指すのか

「フレームワークを減らす」とは、技術スタックを単一のツールに縮小することを意味するわけではありません。むしろ「同じ種類のものを作るための手段」を意図的に限定することで、チームがコード、スキル、パターン、ツールを共有できるようにし、毎回それらを再発明する必要をなくすことを指します。

「フレームワークスプロール」はどんな状態か

フレームワークスプロールは、組織が重複したフレームワークを蓄積してしまうときに起きます――買収、強いチーム自律性、あるいは「試してみよう」で導入されたものが廃止されずに残る、などが原因です。

よくある例：

• 会社内に3つのWebスタック：あるチームはReact、別のチームはAngular、さらに別のチームはVue――それぞれビルドツール、ルーティング、状態管理が違う。
• 複数のモバイル戦略：あるアプリはネイティブiOS/Android、別のはReact Native、別のはFlutter。
• 類似サービスで異なるバックエンドフレームワーク（例：Spring Boot、Express、Django）を採用し、それぞれ慣習やデプロイ手順が違う。

どれも自動的に間違っているわけではありません。問題は、バラエティがサポート能力を上回るときです。

「チームのベロシティ」は実務でどう現れるか

ベロシティは「何ストーリーポイントを消化したか」だけではありません。現実のチームでは以下のように現れます：

• Lead time: 作業開始から本番反映までにかかる時間
• Throughput: ヒーロー的対応なしに週／月ごとに提供できる価値の量
• Predictability: 見積もりや納期が一貫して信頼できるか
• Recovery time: インシデントやロールバックをどれだけ速く解決できるか

フレームワークが増えると、これらの指標は悪化しがちです。変更ごとにより多くの文脈理解、翻訳、個別のツールが必要になるためです。

「フレームワークを減らす」は「永遠に一つを使え」という意味ではない

統合は戦略であって永続的契約ではありません。健全なアプローチは、現状に合う小さなセットを選び、レビュー時点（年次など）を設け、切り替えは移行計画を伴う意図的な決定にすることです。

その代償として、各チームのお気に入りツールでの局所最適を多少犠牲にしますが、得られるのはシステムレベルの利点（オンボーディングの高速化、共有コンポーネント、簡素なCI/CD、エッジケース障害の減少）です。本記事の残りでは、そのトレードオフがいつ価値を生むか、逆にいつ価値が小さいかを扱います。

多数のフレームワークが生む隠れたコスト

チームは「もう一つだけフレームワークを導入しよう」と採用しても、直ちにコストを感じないことが多いです。税は小さな遅れ（会議の増加、PRの長期化、設定の複製）として現れ、それが累積して、全員が一生懸命働いていても配送が遅く感じられるようになります。

意思決定の回数が増える

同じ機能を作るのに複数の許容可能な方法があると、エンジニアは作る時間よりも選ぶ時間を費やします。ここはFramework Aのルーティングを使うべきか、Framework Bか？状態管理はどれか？テストランナーは？各選択が30分かかったとして、多数のチケットで繰り返せば数日を食いつぶします。

知識が断片化する

混在したスタックでは改善が広がりません。あるフレームワークで学んだパフォーマンス改善、アクセシビリティのパターン、エラーハンドリングが別のフレームワークではそのまま使えないことが多い。結果として同じバグが再発し、同じ教訓を別々のチームが学び直すことになります。

レビューが遅くなりリスクが高まる

一貫性のないパターンはレビュアーに文脈スイッチを強います。PRは「正しいか？」だけでなく「このフレームワークではどうやるべきか？」も問われます。レビュー時間が長くなり、微妙なフレームワーク固有のエッジケースが見逃されることが増え、バグリスクが上がります。

重複作業が常態化する

フレームワークスプロールは以下の領域での重複を生みがちです：

• UIコンポーネントとデザインシステムの統合
• ルーティングとデータフェッチの慣習
• 状態管理の選択
• テストパターンとツール
• ビルドパイプラインとローカル開発セットアップ

結果は余分なコードだけでなく余分な保守です。フレームワークが1つ増えるごとにアップグレード、セキュリティパッチ、運用方法の会話が一つ増えます。

認知負荷：なぜ開発者は遅くなるのか

ベロシティは単にタイプ速度ではなく、問題を理解し、安全に変更し、自信を持ってデプロイできる速さです。フレームワークスプロールは認知負荷を高め、開発者が「アプリがどう作られているか」を覚えている時間が増え、ユーザーのニーズを解く時間が減ります。

コンテキストスイッチングは実際のコスト

複数のフレームワークを扱うと、各タスクに隠れたウォームアップコストがつきます。文法、慣習、ツールを切り替える精神的コストがかかります。ルーティングパターン、状態管理のデフォルト、テストライブラリ、ビルド設定の小さな違いでも摩擦が生まれます。

この摩擦はレビューの遅延や「ここではどうやるの？」というメッセージの増加、変更のリードタイム延長として現れます。1週間で見ると、1回の大きな遅れではなく、数十回の小さな遅れの積み重ねです。

デバッグが難しくなる

標準化は挙動を予測可能にし、生産性を高めます。標準化がないとデバッグは宝探しになります：

• ログが別の場所にあり、形式が違うか重要なコンテキストを欠く
• エラーバウンダリーや障害モードが異なるため、同じバグでも見え方が違う
• ローカルコマンドや環境変数が一貫していないため再現が遅れる

結果として、診断にかかる時間が増え、作る時間が減ります。

統合がエッジケースを増やす

認証、分析、エラー報告などの一般的な統合は退屈なほど単純であるべきです。フレームワークが多いと、それぞれの統合に特別なグルーコードや処理が必要になり、エッジケースと静かに壊れる箇所が増えます。運用負荷が上がりオンコールはよりストレスフルになります。

自信が下がりリファクタが遅くなる

チームのベロシティは自信あるリファクタに依存します。コードベースを深く理解する人が少ないと、エンジニアは構造的改善に踏み切れず、問題の周辺をパッチするだけになります。結果として複雑性が増え、認知負荷がさらに高まります。

フレームワークを減らしても難しい問題が消えるわけではありませんが、「どこから始めるのか？」という時間と集中力を消耗する場面を減らせます。

オンボーディング、採用、クロスチーム協力への影響

フレームワークスプロールは機能配信を遅らせるだけでなく、人が一緒に働くことを難しくします。チームごとに独自の「作り方」があると、組織は立ち上げ時間、採用の摩擦、協働の弱体化で代償を払います。

オンボーディング：ランプアップが積み重なる

新入社員はプロダクト、顧客、ワークフローを学ぶ必要があります。さらに複数のフレームワークを学ばなければならないと、オンボーディング時間が伸びます――特に「ここではこう作る」がチームごとに違う場合に顕著です。

反復を通じて自信をつける代わりに（「ページはこう構成する」「データはこう取得する」「テストはこう書く」）、新入社員は常にコンテキストを切り替えます。結果、他者の待ち時間が増え、小さなミスが増え、独立して責任を持てるまでに時間がかかります。

メンタリング：専門知が薄まる

メンタリングはシニアが問題を素早く見つけ移転可能なパターンを教えるときに最も効果的です。多くのフレームワークがあると、シニアは複数のスタックに分散し、メンタリングは効率を失います。

その結果：

• フレームワークごとの真のエキスパートが減る
• 「助けられるが、少し疎い」という支援が増える
• 助言が他チームにそのまま通用しない

共有フレームワークを絞ると、シニアはレバレッジを効かせて指導できます。学んだことが複数のリポジトリで即座に再利用されます。

採用と面接：ターゲットが明確になる

長い「必須フレームワーク」リストがあると採用は難しくなります。候補者は自ら門をくぐらなくなったり、面接がツールのトリビアに陥りがちです。

標準スタックがあると、採用は基礎（プロダクト思考、デバッグ、適切なレベルのシステム設計）にフォーカスでき、フレームワーク固有の知識は一貫したオンボーディングで補えます。

クロスチーム協力：共有パターンが速度を生む

ペアリング、コードレビュー、インシデント対応などのクロスチーム支援は共有パターンがあると機能します。プロジェクトの構造が認識できれば、人は自信を持って貢献し、レビューは速くなり、緊急時にも対応しやすくなります。

少数のフレームワークに標準化することで、「どのエンジニアでも手伝える」範囲が劇的に広がります。

再利用と一貫性：コンポーネント、パターン、ドキュメント

少数のフレームワークを共有すれば、再利用は実現可能な日常になります。同じ部品で多くの製品を組めるため、問題の再解決に費やす時間は減り、出荷が増えます。

共有コンポーネントが本当に共有される

デザインシステムは採用が容易でこそ意味を持ちます。スタックが少なければ、1つのUIコンポーネントライブラリがほとんどのチームでそのまま使え、複数の移植版（React版、Vue版、レガシー版）を作る必要がなくなります。結果として：

• ボタン、入力、モーダル、レイアウトの単一の真実の源
• デザイン更新やバグ修正の迅速な展開
• アプリごとの振る舞いについての無駄な議論が減る

再利用可能なユーティリティが繰り返し作業を減らす

フレームワークの多様性は同じユーティリティを複数回作り直すことを強います。標準化で次のような共通パッケージが実用的になります：

• フォームとバリデーション（共通のエラーメッセージ、一貫したルール）
• i18n（1つのメッセージ形式、1つのフォールバック戦略）
• ロギングと分析（イベントの一貫性、デバッグの容易さ）

「うちのアプリは違う」ではなく、チームが頼れるポータブルパターンが得られます。

一貫性はアクセシビリティと品質チェックを向上させる

入力コンポーネントにキーボード操作、フォーカス状態、ARIA属性が組み込まれていれば、それらの改善は自動的に全プロダクトに波及します。同様に、共有のリンティング、テストヘルパー、レビューチェックリストは多くのリポジトリに適用できると意味を持ちます。

ドキュメントの重複と特殊扱いが減る

フレームワークが増えるごとにセットアップガイド、コンポーネント使用法、テスト慣習、デプロイノートが増えます。スタックを絞ればドキュメントはより明確で充実し、より多くの人に使われるため品質も上がります。新参者が内部プレイブックを読むときの“特殊ケース”や部族的回避策が減る利点は大きいです。

ツールと運用：CI/CD、セキュリティ、観測性

ベロシティはコードを書くだけでなく、そのコードをビルド、テスト、出荷、運用する速さにも依存します。小さな合意されたフレームワークセットを使えば、「本番機械」は簡素になり、目に見えて速くなります。

ビルドが似ていればCI/CDは簡単になる

フレームワークスプロールがあると、各リポジトリで特別なパイプラインロジックが必要になります：ビルドコマンドが違う、テストランナーが違う、コンテナ化手順が違う、キャッシュ戦略が違う。標準化すればバリエーションは減ります。

一貫したビルド／テスト手順であれば：

• パイプラインテンプレートをチーム間で再利用できる
• キャッシュヒット率が上がりビルド時間が短縮される
• ログとステージが馴染み深いため失敗解析が容易になる

特注のパイプラインではなく、ほとんどのプロジェクトが少しの調整で採用できる「推奨パターン」が持てます。

セキュリティ更新が予測可能になり、実行される

多様なフレームワークは依存関係の表面積を広げます。脆弱性アドバイザリの追跡数が増え、パッチの種類が増え、アップグレードで壊れる確率が上がります。

フレームワークを絞れば以下を標準化できます：

• 依存性更新の頻度（週次／月次）
• 更新用の自動PR
• バージョンサポート方針（何が「サポート」かと「レガシー」か）
• セキュリティスキャンの設定

こうしておけば、セキュリティ作業は火消しではなく日常メンテナンスになります。特に高優先度の脆弱性が出たときに、多数のリポジトリに対して素早くパッチを当てやすくなります。

観測性の標準化が容易になる

ログ、メトリクス、トレースは一貫していると最も役に立ちます。フレームワークごとにミドルウェアスタックやリクエストIDの取り扱い、エラーバウンダリーが異なると観測性は分断されます。

少数のスタックなら共通のデフォルト（構造化ログ、共有ダッシュボード、一貫したトレース）を合わせやすくなり、チームは「テレメトリを動かす」作業に時間を取られるよりも、それを使って信頼性を高めることに時間を使えます。

ツール投資の波及効果

リンター、コード生成、テンプレート、スキャフォールディングは作るのが高コストです。多くのチームがほとんど調整なく使えるときにこそ効果を発揮します。

標準化すれば、プラットフォームやイネーブルメントの取り組みはスケールします：1つの良いテンプレートが多数のプロジェクトを加速し、1セットの慣習が組織全体のレビューサイクルを短くします。

関連例として：一部のチームは Koder.ai のような「vibe-coding」プラットフォームを使い、内部ツールの新規生成を舗装路スタックに沿う（例：ReactフロントエンドとGo＋PostgreSQLバックエンドをチャットワークフローから生成）ようにして、出力が組織のデフォルトに自然に合うようにしつつ、ソースコードとしてエクスポートして通常のリポジトリとして保守できるようにしています。

どの少数セットを選ぶか

フレームワークを絞ることは、永遠に1つを選ぶことではありません。デフォルトスタックを定義し、許容する短く明確な代替リストを決めることで、毎スプリント根本的な議論に時間を取られずに迅速に動けます。

「デフォルトスタック」から始める（リストは短く）

主要な領域ごとに1つのデフォルトを目標にしてください（例：フロントエンド、バックエンド、モバイル、データ）。どうしても選択肢が必要ならプラットフォームごとに1～2つに留めます。簡単なルール：新規プロジェクトが会議なしでデフォルトを選べること。

デフォルトがうまく機能する条件：

• チームやプロダクトラインで共通している
• 共有ツール（テンプレ、CIステップ、セキュリティスキャン）でサポートされている
• 内部の例と再利用可能なコンポーネントがある

ツール具体議論の前に意思決定基準を定める

説明しやすく、ゲーム化しにくい基準で合意してください：

• 成熟度: 安定したリリース、予測可能なアップグレード経路
• エコシステム: ライブラリ、統合、採用のしやすさ
• パフォーマンス要件: 要件が正当化する場合のみ最適化する
• サポート性: 長期保守、セキュリティパッチ、運用負担

フレームワークが高評価でも運用の複雑さ（ビルド時間、ランタイムチューニング、インシデント対応）を増やすなら、それは真のコストとして扱ってください。

軽量なガバナンスを加える（官僚化しない）

例外を承認する小さなグループ（多くはプラットフォームチームや上級ICの評議）を作り、迅速に運用します：

• 短い申請テンプレ：ユースケース、トレードオフ、出口計画
• 決定のSLA（例：3–5営業日）
• リストを剪定するための定期レビュー（四半期または年2回）

標準を一目で分かる場所にドキュメント化する

デフォルトスタック、承認済みリスト、例外プロセスを1つの信頼できる情報源（例：/docs/engineering-standards）に置き、プロジェクトテンプレやオンボーディング資料からリンクしてください。

大掛かりな書き換えなしの実用的移行計画

フレームワークを減らすことは劇的な書き換えを必要としません。安全な移行は地味に進み、価値を出しながらリスクを下げます。

1) 新しい作業から始める

標準スタックを新規作業のデフォルトにします：新しいアプリ、新しいサービス、新しいUIサーフェス、内部ツール。これだけでスプロールの拡大を止めつつレガシーコードには触らない選択肢を残せます。

安定していて価値を出しているレガシーアプリは当面放置して構いません。強制的な書き換えは凍結や期限の逸脱、チームの分散を招きます。移行は実際のプロダクト変更に紐づけて進めましょう。

2) ストレンジャー手法：機能やページ単位で移行する

モダン化が必要なときは自然な境界で移行します：

• 既存プロダクトの新しいページやルート
• 機能モジュール（チェックアウト、プロフィール、管理画面）
• APIサーフェスやバックグラウンドジョブ

パターンは単純：旧システムを稼働させたまま、機能の一切片を新スタックに向け、これを繰り返して新実装が徐々に旧実装を締め上げ（strangle）ていきます。残った旧コードが小さくなったら安全に退役させます。

3) 正しい選択を簡単にする

人は最も楽な道を選びます。テンプレやスターターキットで標準を組み込み「正しい選択」を簡単にしてください：

• Lint、テスト、CI、デプロイが事前設定されたリポジトリテンプレ
• マーケティングサイト、ダッシュボード、APIなどの「ゴールデンパス」スターター
• チームが安心してコピーできるサンプルコンポーネントとパターン

これらを分かりやすい場所に置き、内部ドキュメント（例：/engineering/stack、/engineering/starter-kits）からリンクします。

4) アップグレードと非推奨をプロダクトロードマップのように扱う

移行は「誰の仕事でもない」となると失敗します。廃止するフレームワークや依存に対しては：

• スケジュール（発表日、"新規利用不可"日、サポート終了日）
• オーナー（プラットフォームチームまたは名指しの保守者）
• サポートされる代替と移行ガイド

進捗と例外は公開し、チームが破壊的変更に突然直面して計画が狂うことがないようにします。

例外を扱う（スプロールを再発させないために）

標準化は現実的でなければ続きません。非標準のフレームワークが正しい選択となる場面はありますが、「1例外」が5つ、10個に膨らまないようにルールを持つ必要があります。

例外が妥当なとき

以下のような明確で防御可能な理由がある場合のみ例外を許可します：

• 独自要件: 標準スタックでは満たせない機能（例：オフライン優先、特殊レンダリング、デバイス制約）
• ハードな制約: ベンダーSDK、顧客環境、遺産統合などが選択を制約する場合
• コンプライアンス／セキュリティ: 監査済みコンポーネントや規制環境

理由が「チームが好きだから」だけなら、それは測定可能な成果で裏付けられるまでは嗜好として扱ってください。

承認前にサポート計画を必須にする

すべての例外には軽量な“サポート契約”を添えて承認させます：

• 名指しのオーナー（保守とインシデント対応）
• ドキュメント: ビルド、テスト、デプロイ、デバッグ手順と共通障害モード
• アップグレード経路: サポートするバージョン、アップデート頻度、廃止トリガー

これがない承認は将来の運用コストを無担保で増やすことになります。

例外に期限を設ける

例外は更新されない限り期限切れにするべきです。シンプルなルール：6–12か月ごとに見直す。見直しでは次を問います：

• 元の制約はまだ有効か？
• 例外は測定可能な価値を出したか？
• 合理的な労力で標準スタックへ移行できるか？

「お気に入りフレームワーク」を防ぐための定量基準

個人の好みと実際の必要性を分けるためのチェックリストを用意してください：パフォーマンス目標、コンプライアンス要件、総所有コスト、採用／オンボーディングへの影響、CI/CDや観測性との統合性など。これを満たさないならスタックに入れるべきではありません。

ベロシティが本当に改善したかどうかを測る方法

フレームワークを絞ることは賭けです：スプロールを減らせば認知負荷が下がり開発生産性が上がるはずです。移行が成功したかを知るには、移行期間の感触だけでなく定量的な成果を追ってください。

ベースラインを取って傾向を比較する

比較のためにベースライン期間（例：統合前の6–8週間）を選び、標準スタックで実際の作業を出した後の定常期と比較します。移行期の一時的低下は予期し、重要なのは変化が吸収された後の傾向です。

デリバリ指標（エンドツーエンド）を追う

アイデアから稼働までのパスを反映する少数の指標を追ってください：

• リードタイム／サイクルタイム: 作業開始から本番までの時間
• デプロイ頻度: デプロイの増加はベロシティ改善のしばしばの指標
• 変更失敗率: インシデントやロールバックを引き起こす割合

これらはプラットフォームチームやイネーブルメント組織にとって追跡しやすく、操作されにくい指標です。

オンボーディングと協業を測る

統合はオンボーディング時間を短縮するはずです。追うべき指標：

• 最初のマージPRまでの時間
• 最初の機能を出すまでの時間

また、共有コンポーネントやパターンがどれだけ再利用され再作業が減ったかの信号も見てください。

品質指標：レビュー時間と欠陥

PRレビュー時間、手戻りループ、欠陥率を標準化前後で監視してください。速さは品質が保たれてこそ価値があります。

定性的フィードバックも忘れずに

感じ方やドキュメント品質、デプロイ時の自信などを短い定期アンケート（5問程度）で取り、指標では掬えない点をインタビューで補完してください。

合意を得る：エンジニア、マネージャー、リーダーシップ

フレームワークを絞る決定は技術的判断以上に信頼の問題です。「1つのスタックを強いるとイノベーションが潰れるのでは」「ロックインが強まるのでは」「チームの自律性を奪うのでは」といった不安に直接応えることが重要です。

よくある懸念（と応答）

「これでイノベーションが止まるのでは？」 目的は配信を速めることであって実験を減らすことではありません。時間枠を設けた試験を奨励し、成功した実験は広く採用しやすくすることを求めてください。

「ロックインされるのでは？」 ロックインの原因は選んだフレームワークよりもカスタムのグルーや部族知識にあることが多いです。APIやデザイントークン、サービス契約といった境界を文書化しておけば、フレームワーク選択が広がりすぎることを防げます。

「チームの自律性が奪われる」 自律性は成果を出す力です。プラットフォームは単に作業のばらつきを減らして、成果を出すための余地を広げます。

「舗装路（paved road）」モデル

デフォルトでよくサポートされたスタック（テンプレ、ライブラリ、ドキュメント、オンコール対応可能なツール群）を提供し、例外は明確なプロセスで扱う――これが実用的で受け入れられやすいアプローチです。

効果的なコミュニケーション

標準化についてはRFCプロセスを走らせ、定期的なオフィスアワーを開催し、移行サポート（サンプル、ペアリング支援、「簡単にできること」バックログ）を提供してください。選んだフレームワーク、サポートするバージョン、"サポート"の意味を簡潔にまとめたページを公開します。

リーダー向けチェックリスト（変更を後押しするために）

• オーナー（プラットフォームまたはイネーブルメント）を指名し支援作業に資金を割く
• 成功指標（オンボーディング時間、ビルド時間、インシデント率）を設定する
• ロードマップで移行キャパシティを確保する
• 舗装路への適応を評価し、英雄的な例外を評価しすぎない（報酬設計）
• 定期的に決定を見直すことを約束する

FAQと次のステップ

FAQ

複数のフレームワークが正当化されるのはいつ？

短命の実験で学習速度が長期保守より重要な場合、買収した製品で即時リファクタできない場合、ランタイム制約が真に異なる場合などは合理的です。重要なのはこれらを出口計画付きの例外として扱うことです。

「標準化」対「モジュール化」対「リライト」はどう決める？

• 標準化：製品が何年も維持され、チームが頻繁に協力・共有するなら
• モジュール化：デザインシステム、認証、ロギング、APIクライアントなどを抽出して共有できるなら、すぐに全アプリを同じフレームワークにする必要はない
• リライト：現在のシステムが重要目標（セキュリティ、パフォーマンス、保守性）を阻んでいて、漸進的な変更で達成できない場合のみ

既に別スタックに大きく投資しているチームがいる場合は？

その仕事を否定しないでください。まずはインターフェース（コンポーネント契約、API慣習、観測性、CI/CD要件）で合わせ、次に新規作業のデフォルトを決めて、変更が多い領域（最も頻繁に変わる部分）から段階的に収束させていきます。

次のステップ（実務的で穏当）

1. 現状のフレームワークとオーナーをインベントリ化する（バージョンとアプリの重要度を含む）
2. 新規プロジェクト用のデフォルトスタックを選び、例外パスを文書化する
3. 共有ビルディングブロック（コンポーネント、lint、テンプレ、セキュリティベースライン）を作る
4. 60–90日で改善点と課題をレビューする

より深いガイダンスは /blog/engineering-standards を参照してください。イネーブルメントツールやプラットフォームサポートを評価しているなら /pricing も参考になります。