公開日
デッドコード削除で障害発生率 76%→24%！Metaによるコード改善の取り組み
大規模なソフトウェア開発プロジェクトにおいて、迅速な機能開発とコード品質の維持は、しばしば相反する課題として立ちはだかります。日々の開発の中で、知らず知らずのうちに「技術的負債」が蓄積し、将来の開発速度の低下や品質問題を引き起こすことは少なくありません。世界最大級のIT企業であるMeta社も、この普遍的な課題と無縁ではありません。
本記事では、Meta社がどのようにしてこの課題に取り組み、膨大なコードベースの品質を維持・向上させつつ、迅速な開発サイクルを両立させているのか、その具体的な実践と効果を詳細に報告した学術論文「Code Improvement Practices at Meta」（2025年）に基づいて紐解いていきます。Meta社におけるコード改善への驚くべきコミットメントと、その多角的なアプローチから、私たちの開発現場にも活かせるヒントを探ります。
Metaにおけるコード改善の重要性と背景
技術的負債：コード品質を蝕む静かな脅威
ソフトウェア開発において「技術的負債」という言葉を耳にすることがあります。これは、短期的な開発速度を優先した結果、将来的に追加の修正コストや品質低下を招く可能性のある、設計上・実装上の不備や近道のことです。本論文によれば、このような技術的負債は、コードの複雑化、バグの増加、メンテナンス性の低下を引き起こし、最終的には開発チームの生産性を著しく損なうと指摘されています。
放置された技術的負債は、雪だるま式に膨れ上がり、新しい機能の追加や既存機能の修正をますます困難にします。Meta社のような、日々進化し続ける巨大なコードベースを持つ企業にとって、この技術的負債への対策は、持続的な成長とイノベーションのために不可欠な取り組みなのです。
大規模開発特有の課題とコード品質
Meta社の開発規模は非常に大きく、数多くのエンジニアが広範囲なプロダクトに関わっています。このような環境では、コードの一貫性を保ち、品質を維持することは一層困難になります。開発者の入れ替わりや、短期間での機能リリースへのプレッシャーも、コード品質への配慮を難しくする要因となり得ます。
本論文は、Meta社が迅速なソフトウェアデリバリーを重視しつつも、コードの”自然な劣化”（natural code decay）を食い止め、コードベースを保守可能な状態に保つために、意識的な努力を続けていることを明らかにしています。その取り組みの一つが、本記事のタイトルにもあるように、全ソフトウェア変更の実に14%以上をコード改善活動に充てているという事実です。これは、コード品質に対するMeta社の強いコミットメントを示しています。
Metaのコード改善：3つの主要アプローチ
Meta社では、コード品質を維持・向上させるために、単一の方法に頼るのではなく、多様なアプローチを組み合わせて実践しています。本論文では、これらの活動が、個々のエンジニアの自発的な取り組みから、組織的なプログラム、そして戦略的な大規模改修に至るまで、多層的に展開されていることが報告されています。
エンジニア主導の有機的な改善：日々の積み重ね
最も基本的なコード改善は、日々の開発業務の中でエンジニア自身が気づき、自発的に行うものです。これには、コードの可読性を高めるための小さなリファクタリング、不要になったコードの削除（デッドコード削除）、コメントの追加や修正などが含まれます。
本論文の分析によると、Meta社ではコミットメッセージに「cleanup」「remove」「refactor」といったキーワードが含まれるものが多数存在し、こうしたボトムアップの有機的な改善活動が活発に行われていることが示唆されています。実際、下記の表が示すように、「remove, delete, unneeded（削除、不要）」といったキーワードに関連する変更が全Diffの約7.26%を占めるなど、エンジニアが日常的にコードの健全化に貢献している様子がうかがえます。これらの積み重ねが、コードベース全体の健康を支える基盤となっています。
各キーワードで捕捉されたDiffの割合
| キーワード | 選択されたDiffの割合 |
|---|---|
| remove, delete, unneeded | 7.26% |
| better engineering | 4.28% |
| clean | 3.01% |
| refactor, rework | 1.47% |
| dead | 0.52% |
異なるキーワードを使用している選択されたDiffには重複があるため、各キーワードの割合の合計は16.5%になりますが、いずれかのキーワードの影響を受けるDiffの総割合は14.2%です。
「Better Engineering (BE)」：ゲーミフィケーションによる促進
Meta社には、「Better Engineering (BE)」と呼ばれる、より構造化されたコード改善プログラムが存在します。このプログラムは2016年に開始され、エンジニアリングの生産性向上を目的として、ツール、コードベース、そして開発文化そのものの改善を推進しています。
BEの興味深い特徴の一つが、ゲーミフィケーションの要素を取り入れている点です。エンジニアは、特定のコード改善活動（例：コードレビュー、バグ報告、高カバレッジのテスト作成など）を行うことで、「バッジ」を獲得できます。これらのバッジはエンジニアのプロフィールに表示され、貢献を可視化し、モチベーション向上に繋がっています。
Meta社におけるBetter Engineeringバッジの例
このようなバッジは、質の高いエンジニアリング活動を奨励し、組織全体でコード改善に取り組む文化を醸成するのに役立っています。
BEプログラムでは、チームにエンジニアリング時間の20%～30%をBE関連プロジェクトに割り当てるよう推奨しており、組織としてコード改善に時間を投資することの重要性を示しています。
戦略的リエンジニアリング：大規模なコード刷新
日々の改善やBEプログラムに加えて、Meta社では特に複雑化した部分や、大量のデッドコードが蓄積した箇所などを対象に、戦略的かつ大規模なリエンジニアリングイニシアチブも実施しています。これらは、特定の技術的負債を根本的に解消し、コードベースの健全性を大幅に回復させることを目的とした、計画的な取り組みです。
本論文では、いくつかのリエンジニアリングタスクの類型が紹介されています。
Metaにおけるリエンジニアリングタスクの種類と説明
| タイプ | 説明 | リスク |
|---|---|---|
| Dead code removal | 未使用のメソッド、データフィールド、クラス、ビルドターゲット、設定、機能フラグなどを削除 | 「dead」と判断されたものが緊急時に実は使用されていた、または進行中の作業だった場合など |
| Cyclomatic Complexity, CCN-based decomposition | コードの複雑性を低減するための様々なタスク。フィールドやクラスのリファクタリング、クラスフィールドへのアクセス統一、コードの適切な場所への移動、クラスの論理ユニットへの再編成などを含む。 | タスクの多様性によりリスクは変動 |
| Large class decomposition | 「スーパークラス」内の密結合したコードを抽出し、新しく作成されたクラスに移動するサブクラス抽出。 | 通常3ステップでリスクを低減： 1. 新クラス宣言 2. メソッド移動 3. 実装ファイル移動 |
| Platformization | 依存性逆転を用いたService Locatorパターンの置き換え。データ依存性や状態変更を適切に捉えるDAG実行フレームワークへの移行を可能にするなど。god-objectの分解など。 | Service Locatorは密結合と暗黙的依存性を招き、コードとシステム状態の把握を困難にする |
これらの大規模なリエンジニアリングは、相応の工数を要するものの、将来の開発効率や品質に大きなプラスの効果をもたらすことが期待されます。
コード改善の優先順位付け：Metaの判断基準
Meta社のように広大なコードベースを抱える環境では、改善すべき箇所は無数に存在します。しかし、開発リソースは有限であるため、どの改善タスクに優先的に取り組むべきかを見極めることが極めて重要になります。
優先順位付けの重要性
効果的な優先順位付けは、限られたリソースの中で最大の改善効果を生み出すために不可欠です。闇雲に手をつけるのではなく、最も問題が大きい箇所や、改善によるリターンが大きい箇所から着手することで、効率的にコード品質と開発者体験を向上させることができます。本論文では、Meta社がこの優先順位付けのために、様々な指標や情報を活用していることが示されています。
Metaが用いる主要な判断基準
本論文では、コード改善、特に大規模なリエンジニアリングの対象を選定する際に、エンジニアが考慮する約20の基準が特定されたと述べられています。これらの基準は、コードの技術的な側面だけでなく、開発プロセスやチームの状況など、多角的な視点を含んでいます。以下に示されている主要な判断基準のいくつかを抜粋して紹介します。
Metaがコード改善の優先順位付けに用いる代表的な指標
| 指標カテゴリ | 具体的な指標例 (一部) | 目的・着眼点 |
|---|---|---|
| 開発時間 | TotDAT (総オーサリング時間), AvgDAT (平均オーサリング時間) | 変更に多くの時間がかかっているファイルは改善の価値が高い可能性がある |
| 変更頻度 | NDiff2Y (過去2年間の変更回数) | 頻繁に変更されるファイルは、改善効果が波及しやすい |
| 品質・信頼性 | noutages (障害関連の変更数), outagelevel (障害の深刻度) | 障害が多い、または深刻な障害を引き起こしたファイルは優先的に対処すべき |
| 開発体制 | nAuthor (オーサー数), knowLost (退職者による変更割合) | 多くの開発者が関わる、または主要な知識を持つ開発者が不在のファイルはリスクが高い |
| コード特性 | sloc (コード行数), complexity (サイクロマティック複雑度) | 大規模で複雑なコードは理解や変更が困難 |
| 依存関係 | Pagerank and centrality (コード依存関係における中心性) | 他の多くのコードから依存されている中心的なファイルは、影響範囲が広く改善のインパクトが大きい |
Metaのエンジニアは、これらの指標を総合的に評価することで、どのコード領域が最も改善を必要としているのか、そして改善によってどのような効果が期待できるのかを、データに基づいて判断しています。
コード改善の効果測定：Metaの事例
コード改善への投資は、具体的にどのような成果をもたらすのでしょうか？本論文では、Meta社が実際に行ったリエンジニアリング活動が、開発の品質、効率、そしてコード構造に与えた影響を定量的に評価しています。
品質への影響：障害発生リスクは減少したか？
リエンジニアリングの主な目的の一つは、バグの発生を減らし、ソフトウェアの品質を向上させることです。本論文では、リエンジニアリング対象となったファイル群に関連する変更が、重大なインシデント（SEV: Severe Event）を引き起こした割合を比較しています。
リエンジニアリングによるSEV（重大インシデント）を引き起こすDiffの割合の変化
| リエンジニアリングタイプ | 期間 | SEVなしDiffの割合 | SEVトリガーDiffの割合 |
|---|---|---|---|
| Dead code removal | 前 | 57% | 76% |
| 後 | 43% | 24% | |
| CCN-driven decomp. | 前 | 72% | 80% |
| 後 | 28% | 20% |
デッドコード削除やCCN(複雑度指標)駆動の分解で顕著な改善が見られました。数値は、各期間における全Diffと、そのうちSEVを引き起こしたDiffの割合を示しています。
特に「デッドコード削除」と「CCN駆動の分解」を行ったケースでは、SEVを引き起こす変更の割合がリエンジニアリング後に大幅に減少していることが分かります。これは、コードがシンプルになり、予期せぬ副作用が減った結果と考えられます。
開発効率への影響：コーディング時間は短縮されたか？
コードが整理され、理解しやすくなることで、開発効率の向上が期待されます。本論文では、コード変更にかかる時間（DAT: Diff Authoring Time）と、変更作業中の編集セッション(プルリクエスト単位)数を比較しています。
リエンジニアリングによるDiff Authoring Time (DAT) の中央値の変化
| リエンジニアリングタイプ | DATの相対的変化 |
|---|---|
| Dead code removal | 0.59 |
| CCN-driven decomp. | 0.23 |
| Large class decomp. | 0.41 |
| Platformization | 0.52 |
全てのリエンジニアリングタイプにおいて、DATの中央値が23%から59%削減されたことを示しています。これは、開発者がより迅速にコードを理解し、変更を行えるようになったことを意味します。
リエンジニアリングによる編集セッション数の中央値の変化
| リエンジニアリングタイプ | 編集セッション数の相対的変化 |
|---|---|
| Dead code removal | 0.19 |
| CCN-driven decomp. | 0.41 |
| Large class decomp. | 0.67 |
| Platformization | 0.65 |
同様に、編集セッション数も大幅に減少しており、特に大規模クラス分解やプラットフォーム化では65%以上の削減が見られました。これは、開発者が少ないコンテキストスイッチで作業を完了できるようになったことを示唆しています。
コード構造への影響：複雑さは解消されたか？
コードの複雑性は、バグの温床となりやすく、保守性を低下させる大きな要因です。リエンジニアリングは、この複雑性を低減することも目的としています。
リエンジニアリングによるサイクロマティック複雑度(コードの複雑度指標)の平均的減少率
| リエンジニアリングタイプ | サイクロマティック複雑度の平均減少率 |
|---|---|
| Dead code removal | 7% |
| CCN-driven decomp. | 26% |
| Large class decomp. | 7% |
特にCCN駆動の分解ではサイクロマティック複雑度が平均で26%減少し、コード構造がよりシンプルになったことが示されています。デッドコード削除や大規模クラス分解でも7%の減少が見られました。
Metaの事例から学ぶ、私たちの開発現場で活かせるヒント
Meta社の先進的なコード改善プラクティスは、多くの開発組織やエンジニアにとって貴重な示唆を与えてくれます。以下に、私たちが学べる主要なポイントをまとめます。
継続的な改善文化の醸成
Meta社の取り組みは、コード改善が一過性のイベントではなく、日々の開発プロセスに組み込まれた継続的な活動であることを示しています。エンジニア主導の小さな改善から、組織的なプログラム、戦略的な大規模改修まで、あらゆるレベルで改善意識を持ち、実践することが、コードベースの健康を長期的に維持する鍵となります。
データとツールによる客観的な意思決定
Meta社では、コード改善の優先順位付けや効果測定に、様々なメトリクスやデータを活用しています。感覚や経験だけに頼らず、客観的なデータに基づいて意思決定を行うことで、より効果的かつ効率的な改善活動が可能になります。また、BEプログラムにおけるバッジシステムのようなツールは、エンジニアのモチベーションを高め、改善活動を促進する上で有効です。
多様なアプローチの組み合わせ
コードの課題は多様であり、単一の解決策で全てに対応することは困難です。Meta社は、ボトムアップの自発的な活動、ゲーミフィケーションを取り入れたプログラム、そしてトップダウンの戦略的なリエンジニアリングといった、複数のアプローチを柔軟に組み合わせています。自社の状況や課題に応じて、これらのアプローチを参考に最適な方法を選択・組み合わせることが重要です。
まとめ
本記事では、Meta社が実践するコード改善の多岐にわたる取り組みと、その具体的な効果について解説しました。全変更の14%以上をコード改善に充てるというMeta社の姿勢は、コード品質に対する強い意志の表れであり、技術的負債と向き合い、持続可能な開発を目指すすべての組織にとって大きな示唆を与えてくれます。特に、デッドコード削除による重大インシデントの劇的な削減効果は特筆すべき点です。
Meta社の事例は、継続的な改善文化の醸成、データとツールに基づく客観的な意思決定、そして多様なアプローチの組み合わせによって、巨大なソフトウェアシステムであってもその品質を維持し、進化させ続けることが可能であることを力強く示しています。本記事で紹介したMeta社の取り組みが、皆さんの開発現場におけるコード品質向上のための一助となれば幸いです。
開発生産性やチームビルディングにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: