Post
JA EN

技術選定を各自の裁量に委ねた組織で、静かに壊れていくもの ─ 「標準がない」の重症度を6つの軸で診断する

Posted
By
47 min read
技術選定を各自の裁量に委ねた組織で、静かに壊れていくもの ─ 「標準がない」の重症度を6つの軸で診断する
  • 想定読者： エンジニア数十〜数百人規模の組織で、技術のばらつき・老朽化・知識の非蓄積に困っているCTO・VPoE・EM・テックリード
  • 前提知識： チーム開発の実務経験。Platform Engineering や Golden Path の知識は不要。着手の手順と社内提案の通し方は姉妹記事（末尾にリンク）で扱う
  • 所要時間： 通読 約18分／要点把握 約6分

概要

エンジニアが数十人を超えた組織で、よく似た症状が同時に出ることがある。技術選定は各チーム・各人の裁量に任され、使われている技術が広く散らばっている。一方で主力プロダクトの足回りは古びていて、そろそろ入れ替えるべきなのに、いつ何をどう替えるかの方針はどこにもない。ナレッジを置く場所は用意されているが、他チームの記事を開いても自分の環境に転用できず、実質的に誰も読んでいない。新人がいつ戦力になるかは誰も測っていない。インシデントの振り返りは制度としてあるが、中身が薄く、似た障害が別の場所で再発する。そして中堅以上のエンジニアが「ここでは経験が積み上がらない」と言って辞めていく。

これらは別々の問題に見えて、ひとつの構造から出ている。技術の多様性が高すぎると、組織が蓄積したはずの知識の「転用可能性」がゼロに近づく。転用できない知識は、書いても読まれず、読まれない文書は更新されず、更新されない文書は次の人が最初から解き直す。学習の複利が効かなくなり、複利が効かない場所からは、複利を期待している人ほど先に離れる。

さらに厄介なのは、この状態では古くなったものを退役させる決定も下せないことだ。刷新の判断基準がないので、レガシーの入れ替えは有志の個人プレーになる。その結果、古い技術は残ったまま新しい技術がもう一つ増える。モダナイゼーションが、分散を加速させる装置として働く。

Spotify はこの種の状態を自分たちの言葉で rumour-driven development（噂駆動開発） と呼んだ1。自律的なチームへの強いコミットが、開発者ツールの断片化したエコシステムを生み、知識の伝達が非公式な人づての関係に依存するようになった、と彼らは書いている。自律性が悪いのではない。自律性を支える共通の土台を作らないまま自律性だけを配ると、こうなる。

本記事は、この状態がなぜ起きるのかを分解し、「標準があるか・ないか」の二択ではなく 6つの軸 × 5段階の重症度 として診断できるようにする。自分の組織がどこにいるかを、体感に頼らず観測できる事実から判定するための道具立てだ。何から着手し、どう社内で通すかは、姉妹記事「「標準がない」組織で、何から着手し、どう提案を通すか」のほうで扱う。

症状は6つの軸に分かれている

冒頭に並べた症状を、独立して測れる軸に分解する。

  1. 技術選定のガバナンス（何を新しく使うかを、誰が、どんな基準で決めるか）
  2. 技術の更新と退役（古くなったものを、いつ、どう捨てるか）
  3. ナレッジの再利用性（蓄積された情報が、他のチームで実際に使えるか）
  4. オンボーディングの可視性（新しく入った人が戦力になるまでを測っているか）
  5. 失敗からの学習（インシデントや失敗が、次の設計を変えているか）
  6. 横断的な共通基盤（何がどこまで揃っているか）

軸1と軸2を分けたのは、この2つが同じ「技術選定の方針」に見えて、実際にはまったく別の難しさを持つからだ。新しく何を選ぶかは、選ぶ人が自分で決めれば済む。古いものをいつ捨てるかは、動いているシステムと、それを支えている人の担当領域を変える話になる。前者だけを整えて後者を放置している組織は多い。

多くの組織はこの6軸がバラバラに進行している。たとえば共通のAPI基盤やクラウドアカウント管理だけは横断で揃っているのに、その上のアプリケーション層は完全に無法地帯、という組み合わせは珍しくない。インフラだけ揃っている状態は、実は最も誤解を生みやすい。「うちは横断で整備している」という自己認識を作ってしまうが、エンジニアが日々触れる層はまったく揃っていないからだ。

悪循環の形

6つの軸は独立に測れるが、悪化するときは連動する。

flowchart TB
    A[技術選定に基準がない] --> B[技術スタックが分散]
    A --> H[退役の方針もない]
    H --> I[刷新が個人プレーになり<br>技術がもう1つ増える]
    I --> B
    B --> C[他チームの知見が<br>転用できない]
    C --> D[ドキュメントが<br>読まれず更新されない]
    D --> E[同じ問題を<br>各所でゼロから解く]
    E --> F[中堅が「積み上がらない」<br>と感じる]
    F --> G[離職・異動で<br>暗黙知が消える]
    G --> A

この輪のどこかを切らないと、施策は全部飲み込まれる。ドキュメント整備を号令しても、C が解決していなければ D は戻らない。同じように、レガシー刷新プロジェクトを立ち上げても、A が空白のままなら I を通って B に戻るだけだ。

以下、この輪がどこでどう回っているかを、5つのメカニズムに分けて見ていく。

メカニズム1：多様性が知識の転用可能性を殺す（軸3）

ナレッジ置き場が形骸化する理由は、たいてい「書く文化がない」に帰着させられる。だが技術が分散した組織では、その手前で条件が壊れている。

ある知識が他チームに役立つには、読み手の環境と書き手の環境に十分な重なりが必要になる。使っている言語もフレームワークもCIもデプロイ方式もログ基盤も違えば、「うちのチームのDB接続プーリングのハマりどころ」は、他チームにとって固有名詞の羅列にしかならない。書き手も、それを薄々わかっている。だから書く手が止まる。書いても抽象度の高い一般論になり、一般論は検索でも見つからず、見つかっても役に立たない。

技術の多様性が上がるほど、1本のドキュメントが到達できる読者の数は減る。到達読者が減れば、書く側の期待効用が下がる。これは文書量の話ではない。投資対効果の話だ。この構造を放置したまま「もっと書こう」と言っても、書かれるのは監査用の死んだ文書だけになる（この現象自体の詳細は「ドキュメンテーション・シアター」で扱った）。

ここが出発点になる。以降のメカニズムは、すべてこの転用可能性の欠如から派生している。

メカニズム2：計測がないと、悪化していることに気づけない（軸4）

オンボーディングを測っていない組織は、実は「悪化しているかどうか」を判定する手段を持っていない。新人が立ち上がるのに4ヶ月かかっていても、それが3年前は2ヶ月だったのか5ヶ月だったのかがわからない。技術の分散は年単位でじわじわ進むので、測っていない限り、変化は「そういうもの」として吸収される。

DX Core 4 は、この立ち上がりの指標として time to 10th PR（10本目のPRまでの時間） を挙げている2。最初のコミットまでの時間は、サインアップやアカウント登録に伴う雑務で不自然に速くなるため、継続的に貢献できる状態への到達を測るなら10本目のほうが素直だ、という理屈だ。この1指標を取るだけでも、技術がバラけたチームほど立ち上がりが遅いという傾向が見えることがある。ただしこれは筆者の見立てであって、公表された実証データがあるわけではない。自組織で測って確かめてほしい。

計測の不在が厄介なのは、それ自体は誰も困らせないところにある。困っていないから優先度が上がらず、優先度が上がらないから測られず、測られないから悪化が可視化されない。この軸は、他の5軸の悪化を検出する唯一のセンサーでもある。

メカニズム3：方針がないと、古いものも動かせない（軸1・軸2）

技術選定に基準がない組織は、新しい技術が増える方向にだけ壊れるわけではない。古い技術が退役しない方向にも、同じだけ壊れる。

退役の判断は、新規採用の判断よりはるかに重い。動いているシステムを止める話であり、その技術を担当してきた人の仕事を変える話でもある。誰が決めるかが決まっていなければ、誰も決めない。結果として、明らかに寿命が来ているフレームワークやランタイムが、サポート切れの数年後まで残る。

そして、いざ危機感を持った誰かが刷新に動くと、方針がないぶん、その人の好みで新しい技術が選ばれる。古いシステムは移行しきれずに残り、新しいシステムが並走する。技術は1つ減るどころか1つ増える。数年後、その刷新を主導した人が辞めると、今度は「新しかったはずの技術」が誰も触れないレガシーになる。この経路をたどった組織は、刷新を頑張った回数だけ技術が増えている。

Stack Overflow の2024年調査では、開発者が挙げる困りごとの1位が技術的負債で62.4%、2位と3位が「ビルドのための技術スタックの複雑さ」（32.9%）と「デプロイのための技術スタックの複雑さ」（32.3%）だった3。1位と2位・3位は別々の問題として集計されているが、実態としては同じ穴の両側だ。捨てられなかった古いものと、増えすぎた新しいもの。どちらも技術のライフサイクルを決める主体が組織に存在しないことから来ている。

メカニズム4：失敗共有が形骸化するのは、学習ループの問題（軸5）

インシデント共有が「次から気をつけます」で終わるのは、担当者の姿勢の問題として語られやすい。だが Argyris の枠組みで見ると、これはシングルループ学習で止まっている状態にすぎない4。シングルループは行動を直す。ダブルループは、その行動を生んだ方針・前提・インセンティブそのものを問い直す。

「なぜこの設計を選んだのか」「なぜこの技術を使っていたのか」「なぜサポート切れのまま動かしていたのか」に踏み込むと、必然的に技術選定と退役の話になる。そしてそこに組織としての基準がなければ、議論はそこで行き止まる。行き場がないので、行動レベルの反省で切り上げるしかない。形骸化は結果であって原因ではない。

Argyris は『Overcoming Organizational Defenses』(1990) で、当事者の当惑や脅威を防ぎ、同時に学習も妨げるあらゆる方針・慣行・行動を「組織的防御ルーチン」と定義した4。中身の薄いポストモーテムは、まさにこの定義に当てはまる。誰も傷つかず、何も変わらない。

つまり「もっと深く振り返ろう」と促しても効かない。深く振り返った先に、変えられるものが存在しないからだ。運用面の詳細は「Blameless postmortem の運用詳細」に分けて書いた。

メカニズム5：中堅が先に辞める（軸3・軸2）

「経験が積み上がらない」という感覚は、キャリアの中盤にいる人ほど鋭く効く。若手にとっては、バラバラな技術に触れること自体が学習になる。だが中堅は、自分の投じた時間が次の問題を速く解く力に変換されているかを見ている。毎回ゼロから解いている感覚は、そのまま「ここにいる時間の目減り」として認識される。

ソフトウェア専門職224人を対象にした調査研究では、職務満足と job embeddedness（組織への埋め込み度）が離職意向の有力な予測因子として挙がっている5。埋め込み度は、その組織でしか通用しない資産の蓄積と、組織を離れると失われるつながりの量で決まる。この枠組みから推測すると、技術がバラバラで知識が個人に閉じている組織は、皮肉なことに組織側の資産が薄いぶん、埋め込み度も上がりにくいことになる。辞めるコストが低い。ここは研究が直接検証した結論ではなく、埋め込み度の定義から導いた推論だと断っておく。

軸2（更新と退役）は、ここにも効いてくる。古い技術の担当に固定された中堅は、市場価値が目減りしていく感覚を毎日持つ。刷新の方針がないので、いつ解放されるかもわからない。辞める理由としては、これがいちばん静かで、いちばん強い。退職面談では「新しい挑戦がしたくて」と言われるので、組織側にはこの構造が見えない。

そして辞めた人が持っていた暗黙知が消えることで、輪が最初に戻る。

悩ましいのは、統制すれば解決するわけではないこと

Stack Overflow の2025年開発者調査で、転職について「検討していない」と答えた開発者は45.6%にとどまる。「やや検討」28.8%と「強く検討」14.8%を足すと43.6%が検討中で、過去1年に実際に転職した人（自発8.8%・非自発2%）まで含めれば半数を超える。そして職務満足に寄与する属性のランキングで1位に来たのは、自分のタスクを自分で管理する自律性と信頼 だった6。

ここが標準化の議論を難しくする。統制を強めれば自律性が削がれ、放置すれば積み上がらない。どちらの方向にも離職要因がある。この緊張の解き方は姉妹記事の主題になるが、診断の段階で押さえておくべきなのは、「揃っていない」を「統制が足りない」と読み替えた時点で、処方を間違えるということだ。揃えるべきは経路であって、人の裁量ではない。

重症度を6つの軸で診断する

ここからが本題の道具立てになる。軸ごとにレベル0から4を定義する。自組織がどこにいるかを、印象ではなく観測可能な事実で判定してほしい。

軸1：技術選定のガバナンス

Lv状態観測できるサイン
0基準なし誰が何を選んだか、選定理由がどこにも残っていない
1暗黙の慣行「だいたいこれ」があるが明文化されず、新規プロジェクトで揺れる
2推奨リストあり推奨技術の一覧は存在するが、外れたときの手続きがない
3逸脱に手続きがある推奨外を選ぶ場合、理由の記録（ADR等）と合意プロセスがある
4推奨が更新される現場からの提案で推奨リスト自体が定期的に入れ替わる

Lv2 と Lv3 の間に大きな段差がある。リストを作るだけなら1日で終わるが、逸脱の手続きがないリストは「守らなくていいリスト」として扱われる。

軸2：技術の更新と退役

Lv状態観測できるサイン
0把握していない何がどのバージョンで動いているか、組織として一覧できない
1一覧はある棚卸しはしたが、更新するかどうかの判断は各チーム任せ
2危機ベースで動くサポート切れや脆弱性が出たときだけ、その都度対応する
3退役の基準がある「新規では使わない」技術が明示され、移行の期限がある
4移行が支援される退役対象からの移行に、共通の手順・工数枠・担当が付く

Lv2 が最も多い。そして Lv2 は「回っているように見える」ので、危機感が出にくい。判定基準は、サポート切れになっていないもののうち、今後3年で切れるものを言えるかに置くといい。言えないなら Lv1 以下だ。

Lv3 の「新規では使わない」という宣言は、コストがほぼゼロなのに効果が大きい。既存を止める必要がなく、それ以上増えなくなるからだ。

軸3：ナレッジの再利用性

Lv状態観測できるサイン
0置き場もない情報はチャットのログと個人の頭の中だけ
1置き場だけあるWikiはあるが、他チームのページを開いても自分に転用できない
2一部で共有が成立同じ技術を使う数チームの間でだけ知見が流通している
3横断で参照される他チームのドキュメントを読んで問題が解決した実例が出る
4参照が計測されているアクセスログやオーナー・レビュー期限で文書の生死を管理している

Lv1 は最も多く、そして最も誤診されやすい。「ナレッジ共有基盤はあります」という報告は Lv1 でも成立してしまう。判定基準は存在ではなく 他チームのページで実際に問題が解けた事例が今月あったか に置くといい。

軸4：オンボーディングの可視性

Lv状態観測できるサイン
0未計測新人が戦力になるまでの期間を誰も知らない
1体感のみ「だいたい3ヶ月くらい」という共通認識はあるが数字がない
2数字があるtime to 10th PR などを取っているが、施策と紐づいていない
3差分が見えるチーム間・技術スタック間で立ち上がり時間の差を比較している
4改善が回っている立ち上がりのボトルネックを特定し、環境構築や文書を直して数字が動く

Lv0 から Lv2 への移行は、多くの組織で1週間程度の作業で済む。PRのデータはすでにあるからだ。にもかかわらず着手されないのは、測ったあとに何をするかが決まっていないからで、これは軸1が Lv2 以下だと本当に打ち手がないことと表裏になっている。

軸5：失敗からの学習

Lv状態観測できるサイン
0共有なし障害は当事者チームで閉じる
1儀式化ポストモーテムはあるが「次から気をつける」で終わる
2対策が出るアクションアイテムは出るが、追跡されず半分以上が放置
3前提を問う「なぜその設計・その技術だったのか」まで踏み込む
4標準に還る学びが推奨技術やテンプレート、退役リストの変更に反映される

Lv1 から抜けられない最大の原因は、メカニズム4で見たとおり、議論の行き先がないことだ。Lv3 に必要なのは心理的安全性だけではない。「設計判断を変えられる場所」が組織にあることも要る。

軸6：横断的な共通基盤

Lv状態観測できるサイン
0何も揃っていないクラウドアカウントすらチームごとにバラバラ
1インフラ層のみ共通API基盤・アカウント管理は揃うが、その上は自由
2雛形があるサービス作成のテンプレートがあるが、使わない選択も普通
3Golden Path がある推奨経路を通るのが最も速く、多くの新規サービスがそこを通る
4経路が製品として運用利用状況を見て改善され、逸脱理由がフィードバックされる

Lv1 は罠だ。インフラだけが揃っている状態は、経営層から見ると「標準化は進んでいる」に見え、現場から見ると「何も揃っていない」に見える。この認識のズレが、改善の優先度を下げ続ける。

総合判定

6軸のレベルを並べてみてほしい。冒頭に挙げた状態は、おおむね次のプロファイルになる。

軸レベル
1. 技術選定のガバナンス0〜1
2. 技術の更新と退役0〜2
3. ナレッジの再利用性1
4. オンボーディングの可視性0
5. 失敗からの学習1
6. 横断的な共通基盤1

全軸が0〜1に張り付いている状態を フェーズA（未着手）、一部の軸が2〜3に上がっているのを フェーズB（まだら）、大半が3以上を フェーズC（機能している） と呼ぶことにする。

6軸のレベルは足し算ではなく掛け算に近い。どれかが1のまま残ると、他を3や4に上げても全体は1に引きずられる。だから診断の目的は、伸ばせる軸を探すことではない。最も低い軸を見つけることにある。どの組み合わせがどう詰まるかは、姉妹記事のフェーズBの節で具体例を挙げた。

まとめ

技術選定を各自の裁量に委ねた組織で壊れるのは、技術そのものではなく 知識の転用可能性 だ。転用できないから書かれず、書かれないから測られず、測られないから悪化に気づかず、気づかないから失敗の振り返りが行動レベルで止まり、止まるから同じ問題が別の場所で繰り返される。中堅以上が先に離れるのは、この複利の不在をいちばん正確に見積もれる層だからだ。

方針の不在は、新しい技術が増える方向と、古い技術が減らない方向の、両方に効く。刷新の基準がないまま誰かが動くと、古いものが残ったまま新しいものが1つ増える。モダナイゼーションを頑張った回数だけ技術が増えている組織は珍しくない。

診断は「標準があるか」の二択で下すものではない。6つの軸それぞれのレベルで見る。技術選定のガバナンス、技術の更新と退役、ナレッジの再利用性、オンボーディングの可視性、失敗からの学習、横断的な共通基盤。インフラだけが揃っている状態（軸6の Lv1）は、経営層と現場で認識が割れる典型的な罠になる。

そして注意すべきは、この診断結果を「統制が足りない」と読まないことだ。開発者の職務満足に最も効く属性は自律性と信頼であり、統制を強める方向の処方は別の離職要因を作る。揃えるべきは経路であって、人の裁量ではない。

何から着手し、社内でどう通すかは、姉妹記事「「標準がない」組織で、何から着手し、どう提案を通すか」で扱っています。エンジニア約200人で2,000サービスを回す Monzo、標準を義務化しない Netflix、現場のギルドが標準を運営する Zalando の実装を読んだうえで、フェーズ別の打ち手と、必要性を感じてもらえない相手を説得するための材料を整理しました。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem - Spotify Engineering (2020). 【信頼性: 中〜高】自社事例の一次情報。定量的な効果測定ではなく実践報告 ↩︎

  2. Measuring developer productivity with the DX Core 4 - Abi Noda, Laura Tacho, Margaret-Anne Storey, Michaela Greiler / DX (2024). 【信頼性: 中〜高】DORA・SPACE・DevEx の各フレームワーク作成者が関与。導入企業の効果数値は自己申告ベース ↩︎

  3. Developers want more, more, more: the 2024 results from Stack Overflow’s Annual Developer Survey - Stack Overflow (2025). 【信頼性: 中〜高】2024年調査の集計。自己選択バイアスあり ↩︎

  4. Chris Argyris: theories of action, double-loop learning and organizational learning - infed.org. 【信頼性: 中】解説記事。シングル／ダブルループ学習の区別はこのページに基づく。「組織的防御ルーチン」の定義は一次文献 Argyris, C. (1990) Overcoming Organizational Defenses: Facilitating Organizational Learning, Allyn & Bacon（ISBN 978-0205123384）の記述 ↩︎ ↩︎2

  5. Staying or Leaving? How Job Satisfaction, Embeddedness and Antecedents Predict Turnover Intentions of Software Professionals - Kuutila et al. (2025). 【信頼性: 中〜高】n=224 のサーベイ研究。arXiv 版はプレプリントだが ICSE 2026 research track に採択済み。単一研究であり、他の研究との一致は下記 ICSIM 2024 の文献も参照 ↩︎

  6. 2025 Stack Overflow Developer Survey - Work - Stack Overflow (2025). 【信頼性: 中〜高】調査全体は49,756件の回答・177カ国。ただし転職に関する設問の回答は35,451件、職務満足の属性ランキングは24,900件（上位5カ国）で、設問ごとに母数が異なる。自己選択バイアスあり ↩︎

マネジメント・組織
技術標準化 ナレッジマネジメント オンボーディング 技術的負債 組織学習
This post is licensed under CC BY 4.0 by the author.