沼上幹の『組織デザイン』は、日々の組織運営や設計について考えるヒントが数多く散りばめられた良書である。抽象度が高く極めて理論的なため通読するのが一苦労なのだが、組織において責任ある立場を担う方には一読をお勧めしたい。

沼上によれば、組織の統合を図る手段のうちもっとも重要なのは、「標準化」と「例外処理」である。今回はこの2つの概念にフォーカスして組織設計・組織開発のポイントを概観する。

1. 標準化とは何か

まずは、そもそも組織とは何かを抽象的に定義することから始めよう。組織とはある特定のアウトプットを産出するために、分業を前提として組成されるユニット（≒部/室/チームなど組織における意味ある単位）の集合体である。組織を構成するあらゆるユニットのミッションは抽象的に定義すると「あるインプットから、あるアウトプットを生み出すこと」となる。全てのユニットのアウトプットが結合したものが、組織のアウトプットだ。

例えば、開発チームは要件というインプットから機能というアウトプットを生み出すことが、カスタマーサポートチームは顧客問い合わせというインプットから回答というアウトプットを生み出すことが、それぞれミッションである。全てのユニットは、特定のインプットとアウトプットの組み合わせを割り振られており、そのすべてが組織全体のアウトプットの一部となっている。これが組織の抽象的な定義である。

次に、「標準化」を定義していこう。「標準化」とは、インプットからアウトプットを生み出すプロセス全体において、統一的な基準を適用することで処理能力を向上させる取り組みのことである（言うまでもないが、処理能力を向上させない取り組みは標準化でもなんでもないから、直ちにやめなければいけない）。標準化の成否は、ユニットが責任を持つプロセス全体のアウトプットの産出量と品質によって判断される。

「標準化」をもう少し細かく見ていこう。沼上の分類によると、「標準化」には大きく分けると3つの類型がある。

1. インプットコントロール

2. プロセスコントロール

3. アウトプットコントロール

それぞれについて簡単に定義を確認する。まずインプットコントロールは、ユニットがアウトプット産出プロセスにおいて利用するインプットの規格を統一する試みである。インプットの規格が統一されていないと、例えばフォーマットの決まっていない仕様書が回ってくるとか、ネジ穴の大きさがマチマチであるとか、四方八方から依頼が飛んでくるといったインプット側の処理に負荷をかける状況が出現する。多くの場合、統一された規格/フォーマットを運用することで、ユニットのインプット処理プロセスの負荷はグンと下げることができる。

次に、プロセスコントロールは、ユニットのアウトプット産出プロセスそのものをこまかく定義し運用することである。複雑な処理が求められるユニットの場合は、アウトプットの産出プロセスに対して中間管理を行うことが効果的である場合が多い。例えば、ソフトウェア開発では、要件定義書、基本設計書、詳細設計書、のように細かく中間プロセスを監督することウォーターフォール型開発が、品質担保を行う上で長らくベストプラクティスとされてきた。

プロセスコントロールは、しかし、不確実な環境への対処には弱い。中間管理がプロセスを細分化・固定化するため、柔軟に変化に対応することを難しくするためである。

最後に、アウトプットコントロールとは、ユニットが産出するアウトプットの評価指標を統一的に定義することである。ユニットに求めるアウトプットの評価指標を明確にした上で、それが満たされていれば、プロセスそのものは柔軟に変更する自律性を与えるのがポイントである。

アウトプットコントロールができていない状況とは、ユニットが何で評価されるのかが定義されていない状況であると考えて良い。多くの場合、アウトプットの量や質に対して問題を抱えているユニットは、一体全体何をもって評価されるのかを本人たちが明確に理解していない。評価指標がうまく定義・コミュニケーションされ、同時に適切な自律性が与えられていれば、ユニットには評価指標を改善するために最適なプロセスを組成する力学が生まれる。そうでなければ力の入れどころがわからず、迷走してしまうのだ。

この3つのコントロールは決して互いに排他的であるわけではなく、すべてがいい塩梅で組織設計に活用される必要がある。不確実性の高い市場に身を置いているのであれば、特に力点は自律性に基づいたプロセスの柔軟な運用を可能にするアウトプットコントロールに置かれるべきだが（アジャイルもリーンも適切なアウトプットコントロールを前提としたプロセス最適化の試みである）、組織設計者は「標準化」によって強いレバレッジが効く部分を見極めて、常に適切な手当てを施す必要がある。

以上が、「標準化」の概念整理である。

2. 例外処理とは何か

次に、「例外処理」を見ていこう。「例外処理」とは、ユニットのアウトプット産出プロセスの中で、プロセス内に定義されていない処理を要求された際の対応である。プログラム的に言えば、エラーハンドリングと同等の処理だと考えて良い。

具体的な例で考えてみよう。例えば、開発チームが開発を進める過程で、予定リリース日の遅延が必要となりうるリスクが検出されたとする。このリスクハンドリングを行うプロセスを当該ユニットが持たない場合、「例外処理」が走ることになる。最も典型的な「例外処理」のパターンは、エスカレーション、つまり組織ヒエラルキーにおける上位階層に判断を仰ぐことである。

多くの場合「例外処理」はエスカレーションを通じて解消されるため、「例外処理」に係る処理の負荷が大きければ、必然的に組織の階層は深くなっていく。これには、組織が扱っているドメインの複雑性などの外因的な要因も影響しているが、「例外処理」そのものの処理に係る負荷の大きさは先ほどの「標準化」によってある程度低減させることができる。つまり、「標準化」を通じてエスカレーションされる事例を類型化し、下位ユニットのアウトプット産出プロセスの中に組み込んでしまうことができるのだ。これが「例外処理」の「標準化」である。

少し抽象的になってしまったので具体例で考えてみる。先ほどの開発チームの事例を引き続き使うと、「計画からの遅延リスクへの対応判断」は、遅延が一定範囲に収まる場合は、チーム内で計画変更の要否を判断し上席には報告のみで済ませて良いと定義するとどうだろうか。この「計画からの遅延リスクへの対応判断」という「例外処理」の負荷が、下位ユニットの正常処理に組み込まれ、組織全体が「例外処理」に割く必要のあるリソースが低減するのだ。

組織の階層が不必要に深くなっているように感じる場合、第一に「標準化」が適切に機能していないことを疑うべきである。各階層において、何をインプットとし何をアウトプットとするのかという正常処理がきちんと定義されているか。インプット・プロセス・アウトプットそれぞれへの「標準化」が適切に行われているか。上位階層への「例外処理」がどのような場合に行われるかが定義されているか。「例外処理」のうち、下位ユニットの正常処理に組み込めるものはないか。この順序であらゆるプロセスを整理・検討していくと、本当にその組織に必要な階層の深さを発見できるはずだ。

3. 組織が機能していないのはどういう時か

ここまでで、「標準化」と「例外処理」に関する基本的な概念の整理ができたので、これらを活用して典型的な組織問題の分析を行ってみよう。

組織が機能していないのは、「標準化」と「例外処理」のどちらか（多くの場合どちらも）が不適切に設計されている場合である。逆に言えば、どちらも常に適切にリファクタリングすれば、組織は適切に機能すると考えて良い。

例えば、「管理職の負荷が大きい」という普遍的な問題を考えてみよう。この原因の１つを、「管理職がありとあらゆるコミュニケーション（会議/チャット/メールなど）に呼び出されていて、認知資源を割かれていること」だと仮定して対処を考えてみる。これは要するに、「例外処理」が不適切な回数呼び出されていて、組織の総合的なスループットを下げているという状況だ。

最初に、このチームは何をインプットとして、何をアウトプットするチームか、きちんと定義できているかを確認する。できていなければ、ここから見直す必要がある。ここでは簡便に「要件定義」を元に「ソフトウェアの機能」を生み出す開発チームであると仮定しておく。

次にインプットに「標準化」の余地がないかを考えてみる。どうやら、要件の大元となるリーガルチームやカスタマーサポートのチームが違う方法でコミュニケーションをとっていて、チームが対応に苦慮しているようだ（片方はメール、片方はチャット）。この場合は、インプットの方法を統一してもらうように管理職がリーガルやCSのカウンターパートに対して交渉するべきである。ついでにコミュニケーションのフォーマットも決めてあげれば、このプロセスに係るチーム負荷は一気に下がるはずだ。

他のチームとのインターフェースは「標準化」のレバレッジが効きやすい領域だから、常に注意を向ける必要がある。（ちなみにインプットを与える側にとっては、これがアウトプットコントロールになる）

では、プロセスはどうだろうか。このチームは、CS担当とリーガル担当を割り振ってそれぞれ別々に開発を行っている。担当者は2〜3名ずつだ。CS担当とリーガル担当は開発プロセスも別々に行っていて、お互いのドメインに対する理解は極めて浅い。そのため、チーム全員で処理内容を振り返って、漸進的にプロセス最適化するというフローが回らない状況になっている。エスカレーション内容に、チーム内でのコミュニケーションがうまく回らない、他のメンバーの引き継ぎがなくて困っている、といった内容が多いのがその証拠である。この対応には、担当制を解体しドメインに対する理解を深めるために、プロセスにスクラムを導入するなどのコントロールが考えられるだろう。

さて、一番多かったエスカレーションの内容は「これをやって良いのかわからないので許可が欲しい」というものだったとしよう。これはアウトプット・コントロールと「例外処理」の設計に係る問題だ。そういう場合は、このチームの成果は何の指標で計測するのか、そしてそれを元にどの程度プロセスの自律性を担保されるのか、定義することから始める必要がある。

まずは、アウトプットの計測指標を管理職が取捨選択して決めることが肝心だ（例えば、CS関連であれば顧客問い合わせのオンライン解決率とか）。そして指標をもとに、チームがアウトプットの産出プロセスにどの程度の自律性を持つかを定義しよう。そうすれば、これまで管理職にエスカレーションされていたであろう「誰々を何の業務にアサインしてよいか」といった、中間プロセスに関する「例外処理」の大半を減らすことができる。

以上が、「標準化」と「例外処理」の概念を通じた組織問題の分析となる。簡単ではあるが、２つの概念の有用性が伝わっていれば幸いである。

4. 終わりに

ここまで、分業を前提とした組織内ユニットのミッションは、特定のインプットからアウトプットを生み出すというプロセスであり、それは「標準化」と「例外処理」の設計を通じて最適化されることを、具体的なケーススタディと共に確認してきた。最後に、これらの概念を、異なる立場の人がどのように活用していくべきかについて私見を述べて結びとしたい。

まずメンバーレイヤーの方は、徹底的に「標準化」を追求することから始めるべきだろう。自分たちのアウトプット産出プロセスのどの部分に余分が生じているのかを見極め、それに効果のあるコントロールを導入する。そして、余った出力で、ヒエラルキーの上位階層にエスカレーションしていた「例外処理」≒「より複雑で創造的で楽しい」仕事を巻き取っていくべきだ。

よくある問題として「業務の属人性が高いこと」が挙げられる。属人的に業務が行われてはいけない理由は、プロセスの「標準化」の妨げになるからである。属人的に行われている処理は外部には見えない。見えないものは変えられない。だから、ダメなのだ。

ソフトウェア開発では、バス係数という属人性を図る指標が重視される。バス係数とは「何人消えたらプロセスが立ち行かなくなるか」を示す指標であり、小さいほどプロセスの属人性が高くブラックボックス化しているプロセスが多いということだ。バス係数の低いプロセスがたくさんあるチームは、ブラックボックスを放置し、プロセスに対する「標準化」の責任を放棄しているのと同じで、組織における意味ある単位として成立していない。まずは、個人ではなく「チーム」がプロセスをよくしていく責任を持っているという意識を持つことから始めよう。

そして管理職の方は、「標準化」思考が弱いユニットには、標準化に向けた気づきのきっかけを与えることに注力するべきだ。多くの場合、こうしたユニットでは、プロセスが「誰かから与えられたもの」であり、「借り物」になっている。プロセスは「自分のもの」であり、「自由に変えられるもの」であると思ってもらうには、アウトプットコントロールと自律性をセットにして定義することが効果的だ。内発的な動機を引き出すような目標設定と、その達成に向けたプロセス改善の積み重ねを通じた自己効力感の獲得こそが、組織を強くする。

「例外処理」の最適化は、管理職にしかできないことだ。チームの結果指標を適切に定義したうえで、「これは皆さんの判断でやってください」とコミュニケーションできているか。もっと言えば、あなた自身がどのプロセスに責任を持っている「機能」なのか、適切に定義し伝えられているか。その辺りを明確にすれば、組織がどのような形であるべきかというトータルな思考が可能になる。僕も頑張るので、一緒に頑張りましょう。