これはFOLIOアドベントカレンダー2025の9日目の記事です。
はじめに
色んな企業のEMやVPoEの方が自社の組織構造、組織デザインについて発信されています。 Spotifyモデルやチームトポロジーなど、いわゆる「新しい組織論」を取り入れた話もよく目にしますし、勉強になるし面白いですよね。
一方で、「そもそも伝統的な組織論ってどういう発想なんだろう？」 という基本に立ち返る機会は、意外と少ないのではないでしょうか。 今回は、沼上幹の『組織デザイン』をベースにして、組織構造の最も基本的な形である ヒエラルキー（階層構造） について整理します。 ヒエラルキーはしばしば「古い」「硬直的」といったイメージで語られますが、そもそもどういう機能や目的があるか、そして組織をより機能させるための方法を紹介できればと思います。
「階層構造＝古いもの」と思っていた方も、少し違った見え方が得られるかもしれません。
ヒエラルキーは何のためにあるのか
そもそも、組織はなぜ階層構造（ヒエラルキー）を持つのでしょうか。 「上位者が意思決定を行うため」「管理のため」といった説明は一般的ですが、『組織デザイン』ではもう少し機能的な捉え方が示されています。
まず前提として、多くの組織は「標準化」によって分業をスムーズに進めようとします。 たとえば業務をマニュアル化してプロセスを標準化したり、仕様書の共有によってインプットやアウトプットの形式を揃えたりといった取り組みです。 こうした標準化によって
- 担当者が変わっても同じ成果が得られるようになる（プロセスの標準化）
- チーム間の連携が効率的になる（インプット・アウトプットの標準化）
といった形で、組織としての機能を高めていきます。
しかし現実には、残念なことに、どれだけ標準化を進めても想定外の状況（例外）が発生します。 顧客から急な仕様変更が入る、隣のチームと依存関係がある部分で調整が必要になる、あるいはメンバー間で意見や判断が食い違う...などといったことは日常的に起こります。
こうした「標準化では処理しきれない事象」を扱うために必要なのが、ヒエラルキーが持つ “事後の調整機能” です。 現場の担当者が判断するには情報や権限が不足している場合、より広い視野を持つ上位層が状況を調整し、組織全体として整合性をとる役割を担います。
つまりヒエラルキーは標準化（事前の調整）では吸収しきれない問題を扱う事後の調整機能、いわば例外処理機構としての機能を持っていると言えます。
階層構造やヒエラルキーは時代遅れとみなされることもありますが、例外処理が頻発する現実の組織において、依然として重要な仕組みであることは押さえておくべき点だと感じています。
ヒエラルキーとしての例外処理能力を高める方法
ここまで、ヒエラルキーが「標準化では吸収しきれない例外を扱う事後の調整機能」であることを見てきました。 では、この“例外処理機構としての階層”をより健全に、効果的に機能させるにはどうすればよいのでしょうか。
本書では、
- 標準化の質を高めること
- 現場の問題解決能力を向上させること
- 階層上での判断を担うマネージャーの能力を伸ばすこと
が挙げられています。 それぞれについて整理してみます。
標準化を進める
まず、例外処理能力を高めるうえで意外と見落とされがちなのが、標準化そのものの質を高めることです。
標準化が進むほど「例外として扱っていた問題」が次第に“想定内の出来事”として扱えるようになります。 その結果、現場レベルで処理できる範囲が広がり、上位層が吸収すべき例外の「量」が減少します。
エンジニアリングの現場では、具体的には次のような取り組みが挙げられます。
- README や Contributing ガイドを整備して、開発フローの曖昧さを取り除く
- API 仕様やデータモデルをドキュメント化し、チーム間のインターフェースを明確にする
- 障害時のハンドリング方針や、エスカレーション基準を共有して判断の迷いを減らす
こうした取り組みはすべて、事前の調整（=標準化）を強化する行為です。 ドキュメントや仕様の明確化は、 例外を減らして階層の例外処理能力を高める という観点からも有益なのです。
メンバー・チームの問題解決能力を高める
次に重要なのが、現場の問題解決能力を伸ばすことです。
標準化では処理しきれない問題が発生したとき、現場が自律的に判断できる範囲が広いほど、組織全体の例外処理能力は自然と向上します。 特に本書では、複数の職能や経験をもつ多能工の知見・調整能力は、例外への対応において大きな武器になると述べられています。 エンジニアでも、フルスタックエンジニアや複数のチームでの経験をもつメンバーの存在がありがたい、というのは実感がある方も多いかと思います。
エンジニアリングの現場では、具体的には次のようなケースが挙げられます。
- 他チームの API 設計思想を理解しておくことで、仕様の解釈違いを現場レベルで解消できる
- DB やインフラに関する最低限の知識があれば、問題の原因や解決策のアタリを自分たちでつけられる
- 過去の類似トラブル対応の経験から、調査やデバッグの方針をすばやく決められる
こうした能力が育つことは、単に調査や解決のスキルが上がるだけでなく、エスカレーションの判断やスピードを高めることにもつながり、結果として組織全体の例外処理能力を底上げします。
マネージャーの例外処理能力を高める
これは言うまでもなく、一朝一夕で身につくものではありません。 技術的な背景の理解、関係者の利害調整、チーム全体のロードマップの把握、意思決定の質など、どれも日々の実務や研修の中で少しずつ鍛えられていく性質のものです。
では、どのような場面でこの能力は育っていくのでしょうか。エンジニアリング組織では、例えば次のような状況が典型的です。
- 複数チームが関わる機能開発で、仕様変更やスケジュール調整の落としどころを決める
- 障害対応で、再発防止にどこまでリソースを割くか、どの改善を後回しにするかを判断する
- プロダクトの優先度とエンジニアリング負債の返済をどうバランスするか意思決定する
これらはいずれも正解が一つではなく、状況依存の判断が求められます。 そのため、知識だけでは対応できず、実際のマネジメント経験を積み重ねることで徐々に精度が上がっていきます。
一方で、座学としてフレームワークや概念を学んでおくことも、判断の前提を整理したり、思考の幅を広げたりするうえで大きな助けになります。 実務と知識の両方を少しずつ積み重ねることで、マネージャーの判断力・例外処理能力がより洗練されていくでしょう。
例えば、以下の田口さんの記事でも触れられているように、FOLIOではマネージャーへの実務フィードバックや勉強会といった取り組みを通じて、マネージャーの成長を組織として支援しています。こうした環境は、日々の経験と知識を積み重ねていくうえで大きな助けになると感じています。
そのうえで、例外処理能力をより発揮しやすくするポイントとして、組織のマネージャーが"アジェンダ"を持つことが挙げられます。 「いま何が重要なのか」「次に何が重要になるのか」といったテーマやロードマップ(＝アジェンダ)を明確に持っていることで、判断の軸がぶれにくくなり、時間やリソースの配分を一貫性のあるものにしやすくなります。
ヒエラルキーを補強する水平関係
階層構造は、標準化では扱いきれない例外を吸収する“事後の調整機能”として重要な役割を持ちます。 一方で、ヒエラルキーだけに依存すると、どうしても調整の経路が「縦方向」に偏りがちです。 その結果、現場同士の細かな連携や、専門領域をまたぐ調整が遅くなることがあります。
こうした弱点を補うために、水平関係（横のつながり） を意識的に強化することが有効だとされています。
メンバー同士が直接折衝できるネットワーク
まず重要なのが、メンバー間で直接コミュニケーションできる関係があることです。
- 隣のチームの担当者と気軽に相談できる
- デザイナーや QA と仕様の意図をすぐに確認できる
といった “Know Who(誰が何を知っているか／誰に相談できるか)” の関係があると、相手の専門性や判断のクセがわかっていることで、階層を経由せずに低い調整コストで解決できる課題が増えます。
このネットワークを組織的に強化する方法として、集合研修(例: 新卒研修)やジョブローテーション(≒多能工育成)が挙げられます。 異なる職能やチームをまたいだ経験のあるメンバーが各チームに点在することで、組織間でのすり合わせがスムーズになり、日常的な業務での例外処理能力が改善します。
マネージャー層の連絡会・定期的なすり合わせ
次に、マネージャー同士が横でつながり、定期的に“アジェンダ”をすり合わせていることも欠かせません。 マネージャー間で現在の状況や課題意識を共有し、"連絡会"のような形で定期的に組織全体としてどの方向に向かうべきかを調整することが、中長期的な意思決定のスピードと一貫性を大きく高めます。
ただし、こうした連絡会は運営していくうちに人数が増えすぎるという問題が起こりがちです。 人数が多いと本音を出しづらくなり、前提や懸念が表に出にくくなるため、形式的な会議に陥りやすくなります。 そのため、腹を割って話せる人数のまま運営し続けることが重要とされています。
PdM のように“横串を通す役割”を強化する
もう一つの水平関係として挙げられるのが PdM のような機能横断で“横串”を通す存在です。
- 複数チームの要求を並べて優先度を決める
- 技術的制約とビジネス要件を同時に考慮する
- 部門間の利害調整を進める
といった機能は、本来の階層構造だけではカバーしきれないことが多い領域です。 プロダクト全体の視点で複数のチームをまたいで調整できる存在がいると、縦方向だけでは捉えづらい課題を拾い上げ、プロダクトの改善や事業の推進を進めやすくなります。
さらに、PdM の権限を強めるために、人事評価への関与を持たせるといった方策も紹介されています。 評価に関与できることで、チーム横断の働きかけが実効性を持つようになり、いわゆる“強いPdM”として意思決定を通しやすくなる、という意図があります。
おわりに
ここまで、ヒエラルキーの役割や、それを補完する水平関係について整理してきました。 「階層構造は古い」「もっとフラットな組織がよい」といった議論を耳にすることも多いですが、改めて伝統的な組織論に触れてみると、ヒエラルキーには例外処理を行うための仕組みという、実務的な機能があることを改めて実感します。
今回とりあげた標準化、現場の問題解決能力向上、マネージャー育成、ネットワーク形成など、どれも一つ一つは基本的な施策ではありますが、“例外処理機構”という視点でみると、改めて学びの多い内容だったと感じています。
2004年の本ではありますが、今回取り上げたもの以外にも分業(水平/垂直分業、制約理論...)や組織構造(職能組織、事業部組織、マトリクス組織...)などの基本的な概念を幅広く押さえており、教科書的な良書だと思います。 組織マネジメントに関わる方は、流行りのモデルや抽象的なフレームワークだけでなく、こうした伝統的/教科書的な視点に触れることで、組織を見る解像度が上がるきっかけになるのではないでしょうか。
この記事が、みなさんが所属する組織の構造や動きを“例外処理機構”という新しい視点から組織を捉え、新しい気づきにつながれば幸いです。
