【LeanとDevOpsの科学】「混乱の壁」とは？局所最適化が生む組織の分断と実践的な解決策

「あちらを立てればこちらが立たず」のジレンマに悩んでいませんか？

「開発チームはどんどん新しい機能をリリースしたいと言っているのに、運用チームは障害を恐れてリリースを渋っている」
「営業部門は顧客の要望に応えようと無理な納期を約束してくるが、製造・開発部門は品質を守るために猛反発している」

「混乱の壁」とは何か

「混乱の壁」とは、もともとソフトウェア開発の文脈において、開発（Dev）チームと運用（Ops）チームの間を隔てる、組織的な縦割りの壁を指す言葉です。

この壁が存在すると、両チームはお互いに協調するどころか、競争や対立を引き起こし、結果として組織全体のパフォーマンスを大きく低下させてしまいます。

根本原因は「相反する評価・報奨基準」

なぜこのような壁が発生するのでしょうか。その最大の原因は、それぞれのチームに「相反するローカルな評価基準」を与えてしまっていることにあります。

• 開発チームの評価基準： より多くの新機能や変更を早くリリースすること（スピードと処理量の多さ）。
• 運用チームの評価基準： システムを安定して稼働させ、障害を未然に防ぐこと（安定性の向上と変更の抑制）。

開発側は「変わること」で評価され、運用側は「変わらないこと」で評価されます。それぞれのチームが真面目に自分たちの評価を上げようと努力すればするほど、お互いの目標が真っ向から衝突してしまうのです。この制度の矛盾こそが、壁を強固にする最大の誘因です。

壁の向こう側で起きている惨状

この壁が放置された組織では、極めて不健全な状況が日常化します。

開発チームは、本番環境で本当に安定して動くかどうかが心もとない状態であっても、自分の評価（リリース量）を上げるために、運用チーム側へ仕事を「丸投げ」するようになります。ビジネス価値の低い見せかけの作業を積み重ねるだけで、「自分たちは組織に貢献している」という錯覚を抱きやすくなります。

一方、丸投げされた運用チームは、システムを守るために開発側との連携を遮断しようとします。本番環境への変更を遅らせるために、がんじがらめで厳格な変更管理プロセスを導入し、「プロセスを管理すること」自体が目的化してしまいます。

結果として、リリーススピードが著しく低下し、かつ本番環境でのトラブルも増えるという、「スピードも安定性も失う」最悪の事態を招きます。各自が自分たちのチームの利益（ローカルな成果）ばかりに焦点を当て、本来の「顧客へ価値を届ける」という組織全体のゴールが見失われてしまうのです。

ソフトウェア開発だけじゃない「局所最適化」の罠

この「混乱の壁」は、ソフトウェア開発におけるDevOpsの文脈で語られることが多いですが、本質は「局所最適化（全体ではなく、一部の部署だけの都合を優先してしまうこと）」の問題です。そのため、組織のあらゆる部分で同じような壁が見られます。

たとえば、マーケティング部門と営業部門、あるいはデザイン部門とエンジニアリング部門などでも、「それぞれの部署のKPI（目標）を達成しようとした結果、別の部署の負担が爆発する」という事態は頻繁に起こります。

局所的な視点でパフォーマンスを改善しようとしたときに、「あちらが立てばこちらが立たず」の状況ができてしまえば、たちまちそこに「混乱の壁」が築かれてしまうのです。

混乱の壁を打破するための「グローバルな成果」

では、この壁を取り払うにはどうすればよいのでしょうか。
『LeanとDevOpsの科学』では、「グローバルな成果（組織全体としての成果）」に焦点を当てた共通の評価尺度を持つべきだと強く推奨しています。

具体的には、スピードと安定性を両立させるための「4つの指標」を、開発と運用の共通目標として設定します。

1. デリバリのリードタイム（コードがコミットされてから本番環境で稼働するまでの時間）
2. デプロイ頻度（本番環境へのリリースの頻度）
3. 平均修復時間（障害が発生してから復旧するまでの時間）
4. 変更失敗率（リリースが原因で障害が起きる割合）

「開発はスピード、運用は安定」と分断するのではなく、「両チームが協力して、この4つの指標をバランス良く向上させること」を評価基準にするのです。これにより、全員が同じ方向を向いて協力できる土壌が生まれます。

現場での注意点：チーム指標の死角と個人の貢献

さて、ここまでが書籍における標準的な理論ですが、実際に現場でプロジェクトマネージャーとして組織をまとめる立場からすると、もう一つ気をつけておきたいリスクがあります。

それは、本書で紹介されている4つの指標が、すべて「チーム全体」のパフォーマンスを測るものになっているという点です。

組織の壁を壊すためにチーム指標を重視することは絶対に必要です。しかし、評価をすべてチーム単位にしてしまうと、「個人がどれだけ貢献したか（あるいはサボっているか）が見えにくくなる」という新たな弊害が生まれます。「自分が頑張らなくても、チームの数字が良ければ評価されてしまう（フリーライダー問題）」といった不満が、優秀なメンバーから噴出しかねません。

実践ステップ：チームと個人の評価バランスの取り方

そこで、実務においてはこの「チームの指標」と「個人の指標」のバランスをうまく取ることが重要になります。

本書では、単なる「リリース頻度」や「安定性（バグの少なさ）」だけで評価することを否定しています。しかし、それを「絶対的な目標（ノルマ）」にしないという前提であれば、個人の貢献度を測るための参考値として、無理のない範囲で計測していくことは大切だと私は考えています。

1. 大前提として「共通の4つの指標」を追う
   まずは、対立する部署間に共通のチーム目標を設定し、「グローバルな成果」を最優先事項として共有します。
2. 個人の活動の「健康診断」としてデータを取る
   ノルマにはせず、「このメンバーは最近レビューの回数が多いな」「このメンバーはリリース時のミスが少ないな」といった、個人の特性や貢献度を把握するためのデータ（リリース頻度や対応の正確性など）をゆるやかに計測します。
3. 1on1でのフィードバックに活用する
   計測した個人のデータは、評価の減点材料にするのではなく、「あなたのこの手助けのおかげで、チームの指標がこれだけ良くなったよ」と、1on1でのポジティブなフィードバックや承認に活用します。

まとめ：壁を越えて「顧客への価値」に集中しよう

「混乱の壁」は、悪意のある誰かが意図的に作っているわけではありません。組織が定めた「相反する評価基準（局所最適化）」が、真面目な社員たちを対立させてしまっている結果です。

もしあなたのプロジェクトや組織で、部門間の風通しが悪く対立が絶えないと感じたら、まずは「お互いの評価基準が衝突していないか？」を見直してみてください。そして、チーム全体の共通目標を掲げつつ、個人の頑張りもしっかり見逃さない工夫を取り入れることで、壁は少しずつ崩れていくはずです。