縦割りが悪いのでも、横断が正しいのでもない――組織を動かす標準と制度

組織の問題を語る場面では、「縦割り組織だから物事が進まない」「部門の壁をなくし、横断的に連携しなければならない」といった説明が頻繁に使われます。特に「縦割り」という言葉は、官僚主義、部門最適、責任転嫁、情報共有の不足などをまとめて表す否定的な言葉になっています。

その対策として、部門横断、マトリクス組織、クロスファンクショナルチームといった考え方が語られます。しかし、縦割りであること自体が組織を悪くするのでしょうか。反対に、横のつながりを増やせば組織は良くなるのでしょうか。私は、どちらも組織の良し悪しを直接決めるものではないと考えています。

縦割りは、責任や専門性を一定の単位に整理するための構造です。横断的な関係は、複数の責任領域にまたがる仕事を処理するための構造です。どちらも目的に応じて選択される手段であり、それ自体に善悪はありません。本当に問題なのは、組織を縦か横かという形だけで捉え、その組織がどのような標準と制度によって動いているのかを分析しないことです。

縦割りは複雑さを管理するためにある

組織が小さいうちは、一人の人間が顧客対応、設計、実装、運用、請求まで担当できます。しかし、事業の規模が大きくなれば、すべての人がすべての業務を理解し、すべての意思決定に参加することはできません。そこで、組織は仕事を一定の単位に分けます。

営業、設計、開発、運用、経理、法務、人事などに組織を分けるのは、それぞれの専門性を蓄積し、判断範囲を限定し、責任の所在を明らかにするためです。縦割りには、専門性を蓄積する、責任範囲を限定する、判断者を明確にする、品質管理の単位を作る、業務を反復可能にする、人材育成の軸を作る、問題の影響範囲を局所化するといった役割があります。

法務部門を独立させるのは、他部門との関係を断つためではありません。法的判断を専門的に扱い、誰がその判断に責任を持つのかを明確にするためです。運用部門と開発部門を分ける場合も同様です。それぞれが異なる時間軸、品質基準、責任を持つから分けます。縦割りとは、本来、組織を分断する仕組みではなく、複雑な仕事を責任を持って管理できる単位へ分解する仕組みです。

横断的な関係も仕事を処理するための手段である

一方で、現実の仕事は組織図の境界に従って発生するわけではありません。新しいサービスを開始するには、営業、設計、開発、運用、法務、経理など、複数の部門が関与します。サイバーセキュリティ、事業継続、顧客体験なども、一つの部門だけでは完結しません。そのため、横断的な関係が必要になります。

しかし、横の関係を増やせば、組織が自動的に良くなるわけではありません。関係者を増やせば、共有される知識や視点は増えます。その一方で、調整、説明、承認、会議も増えます。横断責任者を置けば、全体を見渡せる可能性がありますが、既存の部門長との権限分担が定義されていなければ、担当者は複数の責任者から指示を受けることになります。

マトリクス組織も同じです。職能と事業という二つの視点を持てることは利点ですが、両方を同じ強さの指揮命令系統にすれば、優先順位が衝突するたびに調整が必要になります。縦割りを悪と決めつけることも、横断的な連携を善と決めつけることも、同じ種類の短絡的な判断です。

組織図は構造を示すが、動作を示さない

組織図を見ると、どの部門が存在し、誰が誰に所属しているのかは分かります。しかし、組織図だけでは、その組織が実際にどのように仕事を進めるのかは分かりません。誰が案件を開始できるのか、どの情報がそろえば業務を開始するのか、誰が技術的な実現可能性を判断するのか、何をもって成果物の完成とするのかは、通常の組織図には書かれていません。

納期と品質が衝突した場合に何を優先するのか、標準外の案件を誰が承認するのか、問題が起きた場合にどこへ判断を移すのか、既存の手順を誰が変更するのか。これらが定義されていなければ、縦割り組織でも横断組織でも、仕事は個人間の調整によって進められます。

詳しい人に直接相談する。権限を持っていそうな人へ根回しする。関係者を集めて会議を開く。過去の経緯を知っている人に判断してもらう。このような運用は一時的には機能します。しかし、それは組織が機能しているのではなく、特定の個人が組織設計の不足を補っている状態です。組織図は構成要素と所属関係を示しますが、組織を実際に動かすには別に動作規則が必要です。

組織における標準とは何か

ここでいう標準とは、組織運営に必要なものすべてを指す言葉ではありません。標準とは、反復して発生する仕事について、どの条件で開始し、何を基準に判断し、何を受け渡し、何をもって完了とするのかを事前に共有した規則です。

要素	定義する内容
開始条件	業務を開始するために必要な情報や前提条件。不足時に受け付けるのか、差し戻すのかも含む。
判断基準	技術的な実現可否、標準構成への適合、運用可能性、セキュリティ基準、費用対効果など。
入力と出力	どの部門が何を受け取り、何を返すのか。実現可否、前提条件、リスク、概算費用、回答期限など。
完了条件	成果物、レビュー、試験、承認、証跡、運用引き継ぎなどの受け入れ条件。
例外処理	標準から外れる案件を判断する経路、承認者、記録方法、有効期限、再評価時期。
更新方法	標準自体を誰がどの手続きで見直すのか。同じ例外が繰り返される場合の変更方法。

この意味で、標準は単なる作業マニュアルではありません。仕事を組織として反復可能にするための判断規則です。標準がなければ、同じ種類の仕事であっても、担当者、部門、時期、関係者の力関係によって処理が変わります。

横断的な協働を具体化した事例

横断的な関係をどのように具体化するかを考える事例として、米国政府監査院が調査した U.S. Access Board と他の連邦機関による協働があります。Access Board は、障害のある人のためのアクセシビリティ指針の策定、技術支援、連邦施設に関する要件の執行などを担う組織です。業務の性質上、運輸省など他の機関との協働が必要になります。

GAO が調査した道路空間のアクセシビリティ指針策定では、関係機関が共通の成果を設定し、Access Board が主導することを明確にしていました。関係者は定期的に参加し、それぞれの専門知識、職員の時間、必要な分析費用などを提供していました。さらに、共通用語の使用、進捗の追跡、関係者間での情報共有も行われていました。

この調査は、策定された指針がどれだけ社会的成果を生んだかを測定したものではありません。したがって、横断的な協働の成功を最終的に証明する事例として扱うべきではないでしょう。それでも、共通の成果を定義する、主導する組織を決める、各組織が提供する専門性や資源を明らかにする、共通の用語を使用する、進捗を追跡する、継続的に情報を共有するといった条件は示しています。

つまり、機関同士を横につなげただけではありません。横断的な仕事の進め方を具体化していました。なお、この事例では、一部の協働方法が詳細な書面として固定されていなくても、会議や電子メールなどによって継続的に意思疎通されていたため、GAO は実務上の代替手段が存在すると評価しています。標準とは、必ずしも大量の規程を作ることではありません。関係者が同じ前提と判断規則で仕事を進められる状態を作ることです。

横断的につながっていても事故は防げない

反対に、複数の組織や専門家が関与していることが、安全や全体最適を保証するわけでもありません。2003 年のスペースシャトル・コロンビア号事故を調査したコロンビア号事故調査委員会は、技術的な原因だけでなく、NASA の組織文化や、技術者と管理者の間のコミュニケーションも調査しました。NASA は事故調査委員会の概要を公開しています。

シャトル計画には、複数の NASA 施設、民間人、請負企業が関与していました。多くの組織が横断的に関係する大規模な計画でしたが、打ち上げ日程を維持する圧力、資源上の問題、安全体制の不足が事故の要因になったとされています。委員会が提案したのは、さらに多くの関係者を会議へ参加させることではありませんでした。

提案されたのは、技術要件とその適用除外に責任を持つ独立した技術権限を設置し、危険を体系的に管理することでした。さらに、その独立した権限を、日程や事業コストの責任から切り離すべきだとしています。これは、縦の分離を弱めるのではなく、むしろ特定の責任を独立させる提案です。

技術的安全性を判断する役割と、日程や費用を管理する役割を分け、両者が衝突した場合にも技術判断が組織内の力関係で失われないようにする。この事例は、縦割りが常に悪いわけではないことを示しています。分離すべき責任を分離せず、複数の目的を同じ指揮系統へ押し込むことが、かえって危険になる場合があります。同時に、横断的な関係が存在するだけでは、組織全体の判断が正しくなるわけでもありません。

標準と、それを機能させる制度的基盤は別である

標準を定義しても、それだけで組織が標準どおりに動くとは限りません。ここで、標準と制度的基盤を分けて考える必要があります。標準は、何をどのように判断し、処理するかを定義します。制度的基盤は、その標準に基づいて実際に行動できる状態を作ります。

制度的基盤	意味
権限	標準に基づいて承認、拒否、停止できること。
評価	標準を守った行動が不利益にならないこと。
資源	標準を実行するための人員、時間、予算があること。
可視性	遅延、違反、例外を把握できること。
統治	役職や部門を問わず、標準が適用されること。

この二つを混同してはいけません。「安全上の問題があれば報告する」という標準があっても、報告した人が納期遅延の責任を負わされるなら、その標準は機能しません。「品質責任者が承認する」と書かれていても、その判断を上位者が理由もなく覆せるなら、品質責任者には実質的な権限がありません。

「部門横断で協力する」と定めても、評価制度が各部門の個別目標だけを対象としていれば、各部門は自部門の成果を優先します。標準は仕事の動作を定義し、制度的基盤はその動作を組織の中で実行可能にします。どちらか一方だけでは、組織は安定して機能しません。

トヨタ生産方式に見る標準と権限

標準と制度的基盤の違いを考える上で、トヨタ生産方式の「自働化」は参考になります。トヨタの公式説明では、設備や品質の異常、作業の遅れなどが発生した場合、設備が自動的に停止するか、作業者自身が停止ひもを引いてラインを止められます。停止するとアンドンが点灯し、異常の場所が関係者へ通知されます。

ここには複数の要素があります。まず、何を異常と判断するかを決める標準があります。次に、異常を発見した作業者が工程を止められる権限があります。さらに、異常の発生を周囲へ知らせる可視化の仕組みがあります。そして、発生した異常を再発防止へつなげる改善活動があります。

「品質を大切にする」という理念だけではなく、標準と制度的基盤が組み合わされています。もちろん、これはトヨタ自身による生産方式の説明であり、その説明だけで、あらゆる現場で常に同じ効果が得られていることまで証明するものではありません。それでも、重要な原則は確認できます。規則を書くだけではなく、その規則に基づいて行動できる権限と、異常を把握する仕組みが必要だということです。

横断責任者の標準を定義する

縦割り組織の対策として、サービス責任者、プロダクト責任者、プロジェクト責任者などを置くことがあります。しかし、「全体最適を担当する」「部門間を調整する」とだけ定義しても、実務上の役割にはなりません。営業、設計、開発、運用、セキュリティ部門が関与するサービス開発を例にすると、横断責任者にも標準が必要です。

要素	横断責任者に必要な定義
開始条件	複数部門の作業が必要であり、サービス全体の予算と責任者、顧客要求、事業目的、関係部門からの情報がそろっていること。
判断基準	サービス全体の優先順位、リリース対象、部門間で競合した納期、確保済み予算の配分などを誰が判断するか。
入力と出力	専門部門から作業見積もり、技術的制約、品質リスク、必要人員、依存関係、実施可能時期を受け取り、優先順位や判断結果を返すこと。
完了条件	サービス全体の受け入れ条件、専門部門の品質確認、運用引き継ぎ、残存リスクの記録、顧客や契約に関わる条件を満たすこと。
例外処理	技術的安全性と納期の衝突、資源不足、部門間の優先順位不一致、重大な標準逸脱を上位判断へ移す条件。
更新方法	案件完了後や重大問題の後に、開始条件、役割分担、入力情報、完了条件を見直すこと。

このように定義されて初めて、横断責任者は組織上の役割になります。定義がなければ、単なる会議の司会者になるか、既存の部門責任者へ介入する第二の上司になります。横断責任者が全体を管理することと、専門部門の内部判断へ無制限に介入することは別です。

標準を増やせばよいわけでもない

標準が必要だからといって、すべての仕事を細かく規定すればよいわけではありません。標準の設計、理解、運用、更新にはコストがかかります。すべての相談に正式な申請を求めれば、小さな確認や探索的な試行まで遅くなります。細かな承認条件を大量に作れば、現場は成果を出すことより、規程へ形式的に適合することへ時間を使うようになります。

標準を管理する部門だけが変更権限を持てば、その部門が新しいボトルネックになります。そのため、標準には適用範囲と粒度の設計が必要です。影響の大きい判断は厳密に管理し、軽微な相談や情報共有には裁量を残す。繰り返し発生する業務を優先して標準化し、不確実性の高い仕事には探索の余地を残す。同じ例外が続く場合は標準自体を見直し、不要になった標準は廃止する必要があります。

標準とは、仕事を止めるための規則ではありません。同じ問題を毎回ゼロから調整せず、組織として再現可能な判断を行うためのものです。厳密に管理する領域と、裁量を残す領域を分けなければ、標準そのものが組織の新しい停滞要因になります。

組織構造自体を変えるべき場合もある

縦割りが悪ではないからといって、現在の組織構造を常に維持すべきだという意味ではありません。日常業務の大半が部門間の調整を必要とし、同じ関係者が毎回集まり、例外処理が通常処理になっている場合は、責任を分ける軸が実際の仕事に合っていない可能性があります。

例えば、ある製品について企画、開発、運用が常に一体で判断する必要があるにもかかわらず、それぞれが完全に別の部門となっていれば、小さな変更にも部門間調整が必要になります。この場合は、部門間の手順を追加するだけでなく、製品単位のチームへ責任を移すなど、組織構造そのものを見直した方がよいかもしれません。

ただし、それも「縦割りだから悪い」という理由ではありません。調整の頻度、専門性の維持、品質、変更速度、責任範囲などを分析した結果として、責任を分ける軸を変えるのです。構造を変更することと、構造に善悪を付けることは別です。

縦か横かという議論で分析を終わらせない

「縦割りが悪い」という説明だけでは、問題の所在も、変更すべき対象も明らかになりません。確認すべきなのは、仕事の開始条件、判断基準、入力と出力、完了条件、例外処理、更新方法が定義されているかです。さらに、その標準を実行するための権限、評価、資源、可視性、統治が存在するかを確認する必要があります。

標準があっても、それを行使できる制度がなければ機能しません。制度があっても、何を判断すべきかという標準がなければ、権限は個人の裁量になります。縦割りにも横断にも、それ自体としての善悪はありません。縦の責任分割が必要な場合もあれば、横断的な協力が必要な場合もあります。多くの組織では、その両方が同時に必要です。

縦割りが組織を壊すのではありません。横につながれば組織が良くなるわけでもありません。縦か横かという二次元の形だけで組織を評価し、組織を実際に動かす標準と制度を分析しないことこそ、組織設計を放棄した思考停止なのです。

参考情報

• GAO: ACCESS BOARD – Interagency Collaboration Could Help Ensure Effective Implementation of Public Rights-of-Way Accessibility Guidelines
• NASA: Columbia Accident Investigation Board – Synopsis
• Toyota Production System

関連する記事