Engineering Org Consulting
エンジニア組織の不調を「誰かのせい」ではなく、見えていなかった仕組みの問題として捉え直す。git履歴という客観的な痕跡から組織を読み、設計で解いていくコンサルティングです。
30分の観測デモを相談するThe cost of not seeing
離脱の兆候は、辞表が出る2〜3ヶ月前から痕跡に現れています。気づけるかどうかが、唯一の分かれ目です。
※ 中堅以上のソフトウェアエンジニアを想定した一般的な概算。実際は職位・採用チャネル・立ち上がり期間により幅があります。
Why now
生成AIの普及とチームのスケール化で、この数年、組織の壊れ方そのものが質的に変わりました。これまでと同じ「見え方」では、もう間に合わない。次の3つの点で、観測の必要性が上がっています。
観測が欠けた組織では、まず長命コードの書き手と負債清掃役が、声を上げずに離れる。残るのは「声の大きい人」に最適化された組織。
エンゲージメントや DevEx は「その週、誰が何をしたか」を測る。だが「半年後、何が構造として残っているか」は、主観のメモと印象でしか捉えられてこなかった。
生成AIはコード量を爆発させるが、既存構造との整合は保証しない。設計意図を持たないコードは、構造の変化に耐えきれない。量が増えるほど、重力（構造）の観測系が要る。
How we work
切り離せない4つの工程を、一つの手で通します。人を動かすのではなく、仕組みを動かす。
git履歴を体系的に読む。主観・政治の入らない痕跡から、事実の分布を拾う。
事実を、原理・構造・実装の3層に並べ直す。どの層に、どんなひずみが出ているかを言語化する。
内側から順に手を入れる。個人の足場 → 組織の仕組み → 日々の運用。内側が整わないと、外側の施策は空回りする。
マネージャーの日常実務に、観測を作法として埋め込む。撤収後も、内部だけで観測と運用が回る状態まで持っていく。
The instrument — EIS
観測の土台は、自社開発のオープンソース CLI「EIS（Engineering Impact Signal）」。git log と git blame だけを材料に、忙しさではなく構造への貢献を測ります。外部API・AIは不要で、コードの中身には触れません。
外部API・AIを必要とせず、コードの中身には触れません。見るのは履歴のメタデータだけ。各軸は独立しており、合算ではなく分布として読みます。
How it differs
どれも効いていないのではなく、どれも「症状」に処方されている。EISが見るのは、組織の内部構造です。
| 比較対象 | 既存の測定 | EIS / 当社 |
|---|---|---|
| McKinsey DVI | 経営向けの外部診断（主観中心） | 現場で毎月使える内部診断。主観を介さず更新される。 |
| LinearB | いつ出したか・どれだけ速いかを測る | 出したコードが残ったかを測る。耐久性のあるコードを書いた人を特定する。 |
| DX / DevEx | どう感じているか（サーベイ） | 何が起きているか。回答不要・毎月自動更新。サーベイと併用すると主観と構造のズレが見える。 |
| DORA | チームの外形（速度・安定）を測る | チームの内部構造（誰が設計を握り、誰が抜けたら困るか）を測る。 |
The 12 weeks
3ヶ月の基本形。観測から定着まで、2週サイクルで微調整しながら通します。
Our discipline
観測が持続する条件は、観測される側の尊厳が保たれていること。それだけです。
個人の数値は、本人と直属上司までで閉じる。考課を上書きする材料にはしない。
「誰が悪い」ではなく「どこに偏りがあるか」を制度に反映する。個人を裁くのではなく、偏りを防ぐ仕組みに活かす。
観測結果は、本人のキャリア設計・内省に最初に還す。外から採点する道具には、決してしない。
Contact
提案は結論ではなく、観測の入口です。30分あれば、貴社のコードベースから何が読めるか、具体でお見せできます。観測対象は git履歴のメタデータのみで、コードの中身には触れません。
contact@orbitlens.io