EIS と DORA・SPACE・LinearB —— 観測する対象の違い

どのフレームワークも、実在する何かを測っている。問いはただひとつ —— それが何を闇に置き去りにしているか、だ。

2026 年の計測フレームワーク地図

エンジニアリングリーダーが手にできる計測フレームワークは、かつてないほど増えた。

• DORA —— デリバリー性能のゴールドスタンダード
• SPACE —— Microsoft Research 発の多次元開発者生産性フレームワーク
• LinearB —— エンジニアリングワークフロー指標を追う商用プラットフォーム
• CodeScene —— ホットスポット検出を持つ振る舞い指向のコード解析
• git-fame / git-quick-stats —— 素朴な git 帰属ツール

どれも何か実体のあるものを捉えている。ただ、複数のチームで使い回しているうちに、同じ盲点に何度もぶつかるようになった —— どのフレームワークも、あるエンジニアが書いたコードが今も立っているかどうかを教えてくれない。

この問い —— あなたのコードは生き残ったか？ —— こそが、EIS (Engineering Impact Signal) を作った動機だ。この記事は勝者を決めるための比較ではない。それぞれのフレームワークが何を見ていて、何を見ていないか、そしてその隙間がどこにあるかを整理するためのものだ。

DORA: The Pipeline Telescope

何を測るか: デプロイ頻度、変更リードタイム、変更失敗率、平均復旧時間。

正しく捉えていること: DORA は業界に初めて、実証に裏打ちされたデリバリー性能フレームワークをもたらした。4 指標は定義が明快で、計測可能で、組織成果と相関する。毎年の State of DevOps レポートは縦断的エビデンスを積み上げてきた。

闇に置き去りにしていること:

• 個人解像度はゼロ。 DORA は設計上チーム／組織の単位でしか動かない。チームが速くシップできているかはわかるが、その速度を作っている構造を誰が築いているかはわからない。
• コードの耐久性が見えない。 チームが DORA のエリート指標を叩き出しながら、裏で巨大な技術的負債を積み上げている、という状態は成立する。デプロイが速いことは、そのコードが来期も生き残るかどうかについて何も語らない。
• アーキテクチャは観測されない。 システムを形作ったのは誰か。設計知識を抱えているのは誰か。DORA はそもそも訊かない。

ポジション: DORA はデリバリーのヘルスチェックだ。「このチームはどれくらい速く・安全にシップしているか？」という問いに答える —— 重要だが、狭い問いだ。

SPACE: The Survey Telescope

何を測るか: Satisfaction & well-being（満足と健全性）、Performance（成果）、Activity（活動）、Communication & collaboration（協働）、Efficiency & flow（効率とフロー）。Microsoft Research・GitHub・University of Victoria が提唱した。

正しく捉えていること: SPACE は「生産性は多次元である」——つまり単一指標は必ずゲームされるか誤解される——という前提を正面から認めた。満足度やフローといった主観指標を、客観指標と並べて正当化した。これは重要な知的前進だった。

闇に置き去りにしていること:

• ツールではなくフレームワークだ。 SPACE は何のカテゴリを測るべきかを語るが、どう測るかは規定しない。運用化にはサーベイ、テレメトリ連携、相応の組織的労力が必要になる。
• サーベイデータは急速に劣化する。 Q1 に取った開発者満足度は Q2 の現実を映しているとは限らない。サーベイはスナップショットであり、社会的望ましさバイアスを免れない。
• コードレベルの観測は不在。 SPACE の「Performance」次元にはコードレビュー速度やコード品質が含まれるが、測り方は指定されない。コードが生き残るか、誰がアーキテクチャを所有しているか、バスファクターのリスクはどこにあるか —— これらはフレームワーク外だ。
• 個人シグナルは政治的に扱われる。 SPACE を個人レベルの測定に使うことは、著者たち自身が明示的に非推奨としている。結果として、個人の貢献という問いは未解決のまま置かれる。

ポジション: SPACE は生産性を考えるための、最も思慮深いメタフレームワークだ。何を測るかを決めるときの出発点として正しい。ただし、実測を担うツールは別に必要になる。

LinearB: The Workflow Telescope

何を測るか: サイクルタイム、コーディング時間、レビュー時間、デプロイ頻度、PR サイズ、開発者のワークロード。Git とプロジェクト管理ツール連携を持つ商用プラットフォーム。

正しく捉えていること: LinearB は実行可能なワークフロー分析を提供する。開発サイクルのボトルネック——長いレビュー時間、過大な PR、偏ったワークロード——を可視化する。ベンチマーク機能で業界データとの比較も可能だ。

闇に置き去りにしていること:

• インパクトより活動量。 LinearB はいつ・どれだけ速くコードが書かれレビューされたかを測る —— それが残ったかどうかは測らない。翌スプリントに全部書き直される小さな PR を 50 本シップしたエンジニアが、生産的に見えてしまう。
• コード耐久性は不在。 生存分析がない。残り続けるコードと、すぐに書き換わるコードの区別がない。
• アーキテクチャは不透明。 誰がアーキテクチャ上の判断に寄与しているか。誰が重要モジュールの知識を抱えているか。LinearB が追うのはワークフローであって、構造的影響力ではない。
• プロプライエタリかつ SaaS 専用。 リポジトリとプロジェクト管理ツールを接続する必要がある。観測方法論はオープンではない。

ポジション: LinearB はエンジニアリングワークフローのオプティマイザだ。開発プロセスを可視化し、摩擦点を特定する。「プロセスのどこが遅いか？」には答えるが —— 「コードベースの構造的な健全性はどうか？」には答えない。

CodeScene: The Behavioral Telescope

何を測るか: コードヘルス、ホットスポット、コードレベルの複雑性トレンド、組織結合、知識分布。

正しく捉えていること: CodeScene は哲学的に EIS に最も近い。コードの振る舞いパターンを分析し、ホットスポット（頻繁に変更される複雑なコード）を特定し、組織パターンを検出する。X-ray 機能はファイル内の複雑性トレンドを見せる。プロセスだけではなく、コード自身について問いを立てる道具だ。

闇に置き去りにしていること:

• エンジニアトポロジーは限定的。 CodeScene は知識サイロと組織パターンを特定するが、エンジニアを複数軸（Role, Style, State）で分類しない。知識が偏っていることは見えても、それを抱えているのがどんな種類のエンジニアかは見えない。
• 生存分析の立て方が違う。 CodeScene はコードの年齢や変更頻度を追うが、時間減衰による生存重み付けは適用しない。変更圧の下で耐え続ける堅牢な生存（robust survival）と、誰も触らないから残っているだけの休眠生存（dormant survival）の区別がない。
• プロプライエタリな方法論。 スコアリングアルゴリズムは完全には公開されていない。EIS は全ての式をホワイトペーパーで公開している。
• Module topology の立て方が違う。 CodeScene は組織結合とホットスポットをマップする。EIS は変更圧、co-change coupling、モジュール生存、オーナーシップ断片化をマップし、そのうえで 3 軸（Coupling / Vitality / Ownership）でモジュールを分類する。

ポジション: CodeScene はコードレベルの健全性モニタリングと組織リスク検出に強い。EIS とは解像度が違う —— コードの健康に寄っており、エンジニア個人の構造的指紋には寄っていない。

git-fame と git-quick-stats: The Raw Data

何を測るか: 著者ごとの行数、コミット数、ファイル単位の帰属。

この種のツールはクイックサマリには便利だが、測っているのは量であってインパクトではない。自動生成コードを 50,000 行書いたエンジニアがランキングを支配する。システム全体が依存するアーキテクチャを 500 行書いたエンジニアは、見えないままだ。

EIS は同じ生データ（git log、git blame）から出発するが、その上に以下を足している:

• 時間減衰 Survival —— 古いコードは新しいコードより重みが小さい
• Robust と Dormant の区別 —— 変更圧の下で生き残ったコードと、触られない片隅で生き残っただけのコード
• Debt cleanup の追跡 —— 他人のバグを直しているのは誰か
• アーキテクチャパターン検出 —— 構造的に重要なファイルへの貢献
• 3 軸エンジニアトポロジー —— 「どれだけ」ではなく「どんな種類か」

The Gap: どのフレームワークも測らないもの

既存のフレームワークが未回答のまま残す、核心の問いがある:

このエンジニアが書いたコードのうち、今もどれだけ立っているか —— そしてそれは良いコードだから立っているのか、誰も触らないから立っているのか？

これが生存の問いだ。そして、これがすべてを変える。

2 人のエンジニアを思い浮かべてほしい:

• Engineer A は四半期で 200 本の PR をシップする。DORA 指標はエリートだ。LinearB はサイクルタイムの速さを示す。だが 6 ヶ月後、そのコードの 80% は他の誰かに書き直されている。
• Engineer B は四半期で 40 本の PR しかシップしない。どの活動量指標でも控えめだ。だがそのコードはシステムの構造的背骨を形作っている —— 2 年経った今も残り、活発な変更圧の下で生き残っている。

DORA には速いチームが見える。LinearB には高いスループットが見える。SPACE は満足度を捕まえるかもしれない。だが、どれも Engineer B がコードベースの重力の中心であることは見ない。

EIS はそれを見る。なぜなら、答えるために git blame を必要とする問い —— 何が生き残ったか？ —— を立てているからだ。

競合ではなく、相補

これらのフレームワークはライバルではない。空の異なる部分に向けられた望遠鏡だ。

DORA        → 「デリバリーパイプラインは健全か？」
SPACE       → 「生産性のどの次元が重要か？」
LinearB     → 「ワークフローのボトルネックはどこか？」
CodeScene   → 「コードのどこが不健全か？」
EIS         → 「構造を形作ったのは誰か —— そしてそれは耐えているか？」

成熟したエンジニアリング組織は、DORA をデリバリーヘルスに、LinearB をプロセス最適化に、そして EIS をあらゆるものが動くための構造を、実際に作っているのは誰かを理解するために、同時に使えるだろう。

もっとも危険な状態は、活動量だけを測っている状態だ。デプロイ頻度とサイクルタイムだけを最適化し、コード生存を観測しないチームは、速くシップしながら不可視の構造的負債を積み上げていく。コードは書き換わり続け、アーキテクチャは浸食され、そして全体を静かに支えているエンジニアたち —— Anchor、Cleaner、Dark Matter —— は見えないままになる。

フル比較表

自分で試す

brew tap machuz/tap && brew install eis
cd your-repo
eis analyze .

API キー不要。AI トークン不要。SaaS 連携不要。git log と git blame だけだ。

自分のコードベースに望遠鏡を向けて、他のフレームワークには見せられないものを見る —— 構造を形作ったのは誰で、それは耐えているのか。

完全な方法論は Whitepaper · GitHub を参照。

The Git Archaeology Series

この記事は単体で読める比較記事だ。git 履歴がエンジニアリング組織について何を明かしうるかの全貌を知りたければ:

• Chapter 0: What If Git History Could Tell You Who Your Strongest Engineers Are?
• Chapter 1: Measuring Engineering Impact from Git History Alone
• 全シリーズ（全 17 章）

GitHub: eis —— CLI ツール、式、方法論のすべてがオープンソース。

役に立ったなら: Sponsor on GitHub