2025年10月10日·1 分
フレームワークを減らすことがチームのベロシティを高める理由
フレームワークを減らすとコンテキスト切替が減り、オンボーディングが簡素化され、共有ツールが強化されます――結果としてチームは驚きが少なくより速く機能を出せるようになります。
フレームワークを減らすとコンテキスト切替が減り、オンボーディングが簡素化され、共有ツールが強化されます――結果としてチームは驚きが少なくより速く機能を出せるようになります。
「フレームワークを減らす」とは、技術スタックを単一のツールに縮小することを意味するわけではありません。むしろ「同じ種類のものを作るための手段」を意図的に限定することで、チームがコード、スキル、パターン、ツールを共有できるようにし、毎回それらを再発明する必要をなくすことを指します。
フレームワークスプロールは、組織が重複したフレームワークを蓄積してしまうときに起きます――買収、強いチーム自律性、あるいは「試してみよう」で導入されたものが廃止されずに残る、などが原因です。
よくある例：
どれも自動的に間違っているわけではありません。問題は、バラエティがサポート能力を上回るときです。
ベロシティは「何ストーリーポイントを消化したか」だけではありません。現実のチームでは以下のように現れます：
フレームワークが増えると、これらの指標は悪化しがちです。変更ごとにより多くの文脈理解、翻訳、個別のツールが必要になるためです。
統合は戦略であって永続的契約ではありません。健全なアプローチは、現状に合う小さなセットを選び、レビュー時点（年次など）を設け、切り替えは移行計画を伴う意図的な決定にすることです。
その代償として、各チームのお気に入りツールでの局所最適を多少犠牲にしますが、得られるのはシステムレベルの利点（オンボーディングの高速化、共有コンポーネント、簡素なCI/CD、エッジケース障害の減少）です。本記事の残りでは、そのトレードオフがいつ価値を生むか、逆にいつ価値が小さいかを扱います。
チームは「もう一つだけフレームワークを導入しよう」と採用しても、直ちにコストを感じないことが多いです。税は小さな遅れ（会議の増加、PRの長期化、設定の複製）として現れ、それが累積して、全員が一生懸命働いていても配送が遅く感じられるようになります。
同じ機能を作るのに複数の許容可能な方法があると、エンジニアは作る時間よりも選ぶ時間を費やします。ここはFramework Aのルーティングを使うべきか、Framework Bか？状態管理はどれか？テストランナーは？各選択が30分かかったとして、多数のチケットで繰り返せば数日を食いつぶします。
混在したスタックでは改善が広がりません。あるフレームワークで学んだパフォーマンス改善、アクセシビリティのパターン、エラーハンドリングが別のフレームワークではそのまま使えないことが多い。結果として同じバグが再発し、同じ教訓を別々のチームが学び直すことになります。
一貫性のないパターンはレビュアーに文脈スイッチを強います。PRは「正しいか？」だけでなく「このフレームワークではどうやるべきか？」も問われます。レビュー時間が長くなり、微妙なフレームワーク固有のエッジケースが見逃されることが増え、バグリスクが上がります。
フレームワークスプロールは以下の領域での重複を生みがちです：
結果は余分なコードだけでなく余分な保守です。フレームワークが1つ増えるごとにアップグレード、セキュリティパッチ、運用方法の会話が一つ増えます。
ベロシティは単にタイプ速度ではなく、問題を理解し、安全に変更し、自信を持ってデプロイできる速さです。フレームワークスプロールは認知負荷を高め、開発者が「アプリがどう作られているか」を覚えている時間が増え、ユーザーのニーズを解く時間が減ります。
複数のフレームワークを扱うと、各タスクに隠れたウォームアップコストがつきます。文法、慣習、ツールを切り替える精神的コストがかかります。ルーティングパターン、状態管理のデフォルト、テストライブラリ、ビルド設定の小さな違いでも摩擦が生まれます。
この摩擦はレビューの遅延や「ここではどうやるの？」というメッセージの増加、変更のリードタイム延長として現れます。1週間で見ると、1回の大きな遅れではなく、数十回の小さな遅れの積み重ねです。
標準化は挙動を予測可能にし、生産性を高めます。標準化がないとデバッグは宝探しになります：
結果として、診断にかかる時間が増え、作る時間が減ります。
認証、分析、エラー報告などの一般的な統合は退屈なほど単純であるべきです。フレームワークが多いと、それぞれの統合に特別なグルーコードや処理が必要になり、エッジケースと静かに壊れる箇所が増えます。運用負荷が上がりオンコールはよりストレスフルになります。
チームのベロシティは自信あるリファクタに依存します。コードベースを深く理解する人が少ないと、エンジニアは構造的改善に踏み切れず、問題の周辺をパッチするだけになります。結果として複雑性が増え、認知負荷がさらに高まります。
フレームワークを減らしても難しい問題が消えるわけではありませんが、「どこから始めるのか？」という時間と集中力を消耗する場面を減らせます。
フレームワークスプロールは機能配信を遅らせるだけでなく、人が一緒に働くことを難しくします。チームごとに独自の「作り方」があると、組織は立ち上げ時間、採用の摩擦、協働の弱体化で代償を払います。
新入社員はプロダクト、顧客、ワークフローを学ぶ必要があります。さらに複数のフレームワークを学ばなければならないと、オンボーディング時間が伸びます――特に「ここではこう作る」がチームごとに違う場合に顕著です。
反復を通じて自信をつける代わりに（「ページはこう構成する」「データはこう取得する」「テストはこう書く」）、新入社員は常にコンテキストを切り替えます。結果、他者の待ち時間が増え、小さなミスが増え、独立して責任を持てるまでに時間がかかります。
メンタリングはシニアが問題を素早く見つけ移転可能なパターンを教えるときに最も効果的です。多くのフレームワークがあると、シニアは複数のスタックに分散し、メンタリングは効率を失います。
その結果：
共有フレームワークを絞ると、シニアはレバレッジを効かせて指導できます。学んだことが複数のリポジトリで即座に再利用されます。
長い「必須フレームワーク」リストがあると採用は難しくなります。候補者は自ら門をくぐらなくなったり、面接がツールのトリビアに陥りがちです。
標準スタックがあると、採用は基礎（プロダクト思考、デバッグ、適切なレベルのシステム設計）にフォーカスでき、フレームワーク固有の知識は一貫したオンボーディングで補えます。
ペアリング、コードレビュー、インシデント対応などのクロスチーム支援は共有パターンがあると機能します。プロジェクトの構造が認識できれば、人は自信を持って貢献し、レビューは速くなり、緊急時にも対応しやすくなります。
少数のフレームワークに標準化することで、「どのエンジニアでも手伝える」範囲が劇的に広がります。
少数のフレームワークを共有すれば、再利用は実現可能な日常になります。同じ部品で多くの製品を組めるため、問題の再解決に費やす時間は減り、出荷が増えます。
デザインシステムは採用が容易でこそ意味を持ちます。スタックが少なければ、1つのUIコンポーネントライブラリがほとんどのチームでそのまま使え、複数の移植版（React版、Vue版、レガシー版）を作る必要がなくなります。結果として：
フレームワークの多様性は同じユーティリティを複数回作り直すことを強います。標準化で次のような共通パッケージが実用的になります：
「うちのアプリは違う」ではなく、チームが頼れるポータブルパターンが得られます。
入力コンポーネントにキーボード操作、フォーカス状態、ARIA属性が組み込まれていれば、それらの改善は自動的に全プロダクトに波及します。同様に、共有のリンティング、テストヘルパー、レビューチェックリストは多くのリポジトリに適用できると意味を持ちます。
フレームワークが増えるごとにセットアップガイド、コンポーネント使用法、テスト慣習、デプロイノートが増えます。スタックを絞ればドキュメントはより明確で充実し、より多くの人に使われるため品質も上がります。新参者が内部プレイブックを読むときの“特殊ケース”や部族的回避策が減る利点は大きいです。
ベロシティはコードを書くだけでなく、そのコードをビルド、テスト、出荷、運用する速さにも依存します。小さな合意されたフレームワークセットを使えば、「本番機械」は簡素になり、目に見えて速くなります。
フレームワークスプロールがあると、各リポジトリで特別なパイプラインロジックが必要になります：ビルドコマンドが違う、テストランナーが違う、コンテナ化手順が違う、キャッシュ戦略が違う。標準化すればバリエーションは減ります。
一貫したビルド／テスト手順であれば：
特注のパイプラインではなく、ほとんどのプロジェクトが少しの調整で採用できる「推奨パターン」が持てます。
多様なフレームワークは依存関係の表面積を広げます。脆弱性アドバイザリの追跡数が増え、パッチの種類が増え、アップグレードで壊れる確率が上がります。
フレームワークを絞れば以下を標準化できます：
こうしておけば、セキュリティ作業は火消しではなく日常メンテナンスになります。特に高優先度の脆弱性が出たときに、多数のリポジトリに対して素早くパッチを当てやすくなります。
ログ、メトリクス、トレースは一貫していると最も役に立ちます。フレームワークごとにミドルウェアスタックやリクエストIDの取り扱い、エラーバウンダリーが異なると観測性は分断されます。
少数のスタックなら共通のデフォルト（構造化ログ、共有ダッシュボード、一貫したトレース）を合わせやすくなり、チームは「テレメトリを動かす」作業に時間を取られるよりも、それを使って信頼性を高めることに時間を使えます。
リンター、コード生成、テンプレート、スキャフォールディングは作るのが高コストです。多くのチームがほとんど調整なく使えるときにこそ効果を発揮します。
標準化すれば、プラットフォームやイネーブルメントの取り組みはスケールします：1つの良いテンプレートが多数のプロジェクトを加速し、1セットの慣習が組織全体のレビューサイクルを短くします。
関連例として：一部のチームは Koder.ai のような「vibe-coding」プラットフォームを使い、内部ツールの新規生成を舗装路スタックに沿う（例：ReactフロントエンドとGo＋PostgreSQLバックエンドをチャットワークフローから生成）ようにして、出力が組織のデフォルトに自然に合うようにしつつ、ソースコードとしてエクスポートして通常のリポジトリとして保守できるようにしています。
フレームワークを絞ることは、永遠に1つを選ぶことではありません。デフォルトスタックを定義し、許容する短く明確な代替リストを決めることで、毎スプリント根本的な議論に時間を取られずに迅速に動けます。
主要な領域ごとに1つのデフォルトを目標にしてください（例：フロントエンド、バックエンド、モバイル、データ）。どうしても選択肢が必要ならプラットフォームごとに1～2つに留めます。簡単なルール：新規プロジェクトが会議なしでデフォルトを選べること。
デフォルトがうまく機能する条件：
説明しやすく、ゲーム化しにくい基準で合意してください：
フレームワークが高評価でも運用の複雑さ（ビルド時間、ランタイムチューニング、インシデント対応）を増やすなら、それは真のコストとして扱ってください。
例外を承認する小さなグループ（多くはプラットフォームチームや上級ICの評議）を作り、迅速に運用します：
デフォルトスタック、承認済みリスト、例外プロセスを1つの信頼できる情報源（例：/docs/engineering-standards）に置き、プロジェクトテンプレやオンボーディング資料からリンクしてください。
フレームワークを減らすことは劇的な書き換えを必要としません。安全な移行は地味に進み、価値を出しながらリスクを下げます。
標準スタックを新規作業のデフォルトにします：新しいアプリ、新しいサービス、新しいUIサーフェス、内部ツール。これだけでスプロールの拡大を止めつつレガシーコードには触らない選択肢を残せます。
安定していて価値を出しているレガシーアプリは当面放置して構いません。強制的な書き換えは凍結や期限の逸脱、チームの分散を招きます。移行は実際のプロダクト変更に紐づけて進めましょう。
モダン化が必要なときは自然な境界で移行します：
パターンは単純：旧システムを稼働させたまま、機能の一切片を新スタックに向け、これを繰り返して新実装が徐々に旧実装を締め上げ（strangle）ていきます。残った旧コードが小さくなったら安全に退役させます。
人は最も楽な道を選びます。テンプレやスターターキットで標準を組み込み「正しい選択」を簡単にしてください：
これらを分かりやすい場所に置き、内部ドキュメント（例：/engineering/stack、/engineering/starter-kits）からリンクします。
移行は「誰の仕事でもない」となると失敗します。廃止するフレームワークや依存に対しては：
進捗と例外は公開し、チームが破壊的変更に突然直面して計画が狂うことがないようにします。
標準化は現実的でなければ続きません。非標準のフレームワークが正しい選択となる場面はありますが、「1例外」が5つ、10個に膨らまないようにルールを持つ必要があります。
以下のような明確で防御可能な理由がある場合のみ例外を許可します：
理由が「チームが好きだから」だけなら、それは測定可能な成果で裏付けられるまでは嗜好として扱ってください。
すべての例外には軽量な“サポート契約”を添えて承認させます：
これがない承認は将来の運用コストを無担保で増やすことになります。
例外は更新されない限り期限切れにするべきです。シンプルなルール：6–12か月ごとに見直す。見直しでは次を問います：
個人の好みと実際の必要性を分けるためのチェックリストを用意してください：パフォーマンス目標、コンプライアンス要件、総所有コスト、採用／オンボーディングへの影響、CI/CDや観測性との統合性など。これを満たさないならスタックに入れるべきではありません。
フレームワークを絞ることは賭けです：スプロールを減らせば認知負荷が下がり開発生産性が上がるはずです。移行が成功したかを知るには、移行期間の感触だけでなく定量的な成果を追ってください。
比較のためにベースライン期間（例：統合前の6–8週間）を選び、標準スタックで実際の作業を出した後の定常期と比較します。移行期の一時的低下は予期し、重要なのは変化が吸収された後の傾向です。
アイデアから稼働までのパスを反映する少数の指標を追ってください：
これらはプラットフォームチームやイネーブルメント組織にとって追跡しやすく、操作されにくい指標です。
統合はオンボーディング時間を短縮するはずです。追うべき指標：
また、共有コンポーネントやパターンがどれだけ再利用され再作業が減ったかの信号も見てください。
PRレビュー時間、手戻りループ、欠陥率を標準化前後で監視してください。速さは品質が保たれてこそ価値があります。
感じ方やドキュメント品質、デプロイ時の自信などを短い定期アンケート（5問程度）で取り、指標では掬えない点をインタビューで補完してください。
フレームワークを絞る決定は技術的判断以上に信頼の問題です。「1つのスタックを強いるとイノベーションが潰れるのでは」「ロックインが強まるのでは」「チームの自律性を奪うのでは」といった不安に直接応えることが重要です。
「これでイノベーションが止まるのでは？」 目的は配信を速めることであって実験を減らすことではありません。時間枠を設けた試験を奨励し、成功した実験は広く採用しやすくすることを求めてください。
「ロックインされるのでは？」 ロックインの原因は選んだフレームワークよりもカスタムのグルーや部族知識にあることが多いです。APIやデザイントークン、サービス契約といった境界を文書化しておけば、フレームワーク選択が広がりすぎることを防げます。
「チームの自律性が奪われる」 自律性は成果を出す力です。プラットフォームは単に作業のばらつきを減らして、成果を出すための余地を広げます。
デフォルトでよくサポートされたスタック（テンプレ、ライブラリ、ドキュメント、オンコール対応可能なツール群）を提供し、例外は明確なプロセスで扱う――これが実用的で受け入れられやすいアプローチです。
標準化についてはRFCプロセスを走らせ、定期的なオフィスアワーを開催し、移行サポート（サンプル、ペアリング支援、「簡単にできること」バックログ）を提供してください。選んだフレームワーク、サポートするバージョン、"サポート"の意味を簡潔にまとめたページを公開します。
複数のフレームワークが正当化されるのはいつ？
短命の実験で学習速度が長期保守より重要な場合、買収した製品で即時リファクタできない場合、ランタイム制約が真に異なる場合などは合理的です。重要なのはこれらを出口計画付きの例外として扱うことです。
「標準化」対「モジュール化」対「リライト」はどう決める？
既に別スタックに大きく投資しているチームがいる場合は？
その仕事を否定しないでください。まずはインターフェース（コンポーネント契約、API慣習、観測性、CI/CD要件）で合わせ、次に新規作業のデフォルトを決めて、変更が多い領域（最も頻繁に変わる部分）から段階的に収束させていきます。
より深いガイダンスは /blog/engineering-standards を参照してください。イネーブルメントツールやプラットフォームサポートを評価しているなら /pricing も参考になります。
「Fewer frameworks」は、同じ種類のプロダクトを作るための重複する手段の数を制限することを意味します（例：Web UIのデフォルトスタックを1つ、サービス用フレームワークを1つ）。これにより、スキル、コンポーネント、ツール、運用慣行を再利用しやすくなります。
単一ツールに全てを縮小する必要はなく、例外を禁止するという意味でもありません。不要な多様性を減らすことが目的です。
フレームワークスプロールは、同じ問題を解く複数のスタックが蓄積されるときに起きます（高いチームの自律性、買収、試験的導入がそのまま残るなど）。
簡単なチェック：2つのチームがコンポーネントを簡単に共有できない、コードレビューが共有できない、オンコールの応援ができないと感じるなら、それはスプロールのコストを払っている兆候です。
ストーリーポイントではなくエンドツーエンドで測ります。役立つ指標：
統合前にベースラインを取り、移行中の一時的な低下を予期して、定常化した後の推移を比較してください。
はい、合理的なケースはあります：制約が本当に異なる場合や期間が限定されている場合。典型的な有効ケース：
これらは例外として扱い、明確な所有者とレビュー日を付けて管理してください。
各主要サーフェス（Web、サービス、モバイル、データ）に対してデフォルトスタックを1つ決め、許容される代替を1～2個に絞ります。議論を始める前に評価基準を合意しておくと無限議論を避けられます：
新規プロジェクトが会議なしにデフォルトを選べることを目標にしてください。
官僚化しない軽量ガバナンスが鍵です：
全てを /docs/engineering-standards のような一箇所にまとめておくと便利です。
大掛かりな書き直しは避けます。安全なパターン：
こうすることでリスクを下げつつ継続的に価値を出せます。
例外承認時に軽い“サポート契約”を要求してください：
これがないと将来の運用コストを無予算で承認することになります。
統合は通常、採用やオンボーディングを助けます：
「最初のマージされたPRまでの時間」や「最初の機能を出すまでの時間」を追うと効果が見えやすいです。
エンジニアとリーダー両方の不安に対応することが重要です：
「舗装された道（paved road）」モデル：デフォルトのよくサポートされたスタックを提供し、例外プロセスを明確にして可視化することが効果的です。