12 Jan 2020

組織デザインについて書いたり話したりするたびに、私はそれを後悔しています。 しかし、私は再びこのことについて長い間考え、そしてここにその結果を示します。 Strap thefuck in.

ある時点で、すべての組織は、それが減速していることに気付きます。 フィーチャーは出荷に時間がかかり、人々は会議でますます多くの時間を費やし、誰もが見積もりと計画についてパニックになる。 BプレイヤーがCプレイヤーを採用する」という本質論的なデタラメを内面化した場合、バーや採用について神経質になることもあるかもしれません。 もし私たちが不安で不確かなら、アジャイルやスクラムやその他について宗教的になるかもしれません。 もし、私たちが現代主義的な空想にふける傾向があるならば、私たちは、人間が一緒に働くという20万年の歴史を持つ産業を破壊しようと、イノベーション・トークンを使うことを決めるかもしれません。 また、このようなアプローチは、結果をもたらすことはほとんどありません。

Our Dogmatic Slumber

Most explanations of organizational success or failure are crap. Emicアカウント、すなわち、組織内のthosefromは、組織内に存在するそれらの概念と物語に限定されます。 それらは構造的に自己物語として機能し、グループ内のアイデンティティと目的の感覚を促進するかもしれませんが、それらは重力の井戸に相当する認識論から来るので、その組織の外での説明力は通常ひどいものです。

エティックな視点、つまり組織の外からの視点を取ると、組織の成功や失敗に対するエピック説明は他の組織で容易に利用できる反事実を持っているということがわかります。 もし、アジャイル、フラットな組織、コードレビュー、モノレポ、オープンオフィス、ファンシータイプシステムなどが、実際にそう言われるような原因因子であるならば、なぜ、多くの組織がそれらのプラクティスを採用しても成功しないのだろうか？ なぜそれらの慣行を欠いている他の成功したorganizationwhichがありますか？

そして、もっと重要なことは、ある特定の文脈だけでなく、すべての可能な組織全体で、組織のパフォーマンスに関するある一連の要因の超越性を決定することができるでしょうか？

目を凝らすと、仕事をする組織は、信じられないほど複雑で、ダイナミックで、分散した、並列のプロセスであることがわかります。 少なくとも、1842 年に Manabrea が Babbage に彼の分析機械についてコメントしたときまでさかのぼります。 しかし、カントが『純粋理性批判』において主観的経験の必要な前提条件を導き出そうとしたように、私たちは組織ができることの境界と、組織が成長するときのそのダイナミクスを概説することができます。 その境界の内側で起こることは実行と努力の問題であり、その境界の外側で起こることは不可能なことである」

組織を並列プロセスとしてモデル化することは、組織を設計する方法に情報を与えることができる。

天井は低い

組織の労働能力は、新しいメンバーが加わるにつれて、せいぜい直線的に拡大する。 アムダールの法則は、固定タスクが与えられた場合、NNN個のプロセッサを利用する並列ソリューションは、最大でもNNN倍で順次ソリューションより速く実行されることを示す。

並列リソースが追加されると、タスクの並列化可能部分にかかる総時間はゼロに減少し、対照的にタスクの順次部分にかかる総時間は床値より下がることがない。 このことは、ソフトウェアを書こうとする人の集団にとっても、銀河の星の振る舞いをモデル化しようとするCPUの集団にとっても同じことである。 直感的には、大きな組織は超線形行動をとるように思われるが、雇用が方程式の唯一の変数であるなら、これは文字通りありえないことである。 したがって、超線形生産性の唯一の希望は、実行されているタスクを変更することです。 ありがたいことに、作業能力は生産性と同じではない。

組織がより多くの従業員を雇用すればするほど、生産性向上のための作業は常に優先されなければならない。

従業員が増えれば増えるほど、生産性向上への取り組みは常に優先されなければならない。すべての従業員が、絶えず影響を与え続ける問題に取り組めるよう、社内のツール、トレーニング、サービスを開発し、提供しなければならない。

そして、最後に、作業能力に関するこの線形境界は天井であり、床ではないことを強調しなければならない。 作業能力の足かせとなる要因は他にもたくさんあり、組織全体で生産性を向上させることが重要です。

The Floor Is Lava

新しいメンバーが増えると、制約コストは超線形に増加します。 タスクに対する並列ソリューションは、完全に同時であることはまれであり (実際、そのようなタスクは「恥ずかしいほどの並列」と正しく呼ばれます)、多くの場合、いくつかの連続した重要なセクションが必要です。 クリティカルセクションに入るのを待っているCPUや人の列は待ち行列としてモデル化することができ、待ち行列のサイズが大きくなると待ち行列のサイクルタイムがどのように変化するかを理解するために待ち行列理論を使用することができるようになります。 順次区間をG/G/1G/1G/1待ち行列としてモデル化した場合、すなわち、到着プロセスやサービス時間分布について何ら仮定することなく、単一の待ち行列サーバ（すなわち と仮定すると、平均待ち時間のKingmanの式が得られます。

E(Wq)≈(ρ1-ρ)(ca2+cs22)τmathbb E(W_q) \approx \left( \frac{rho}{1-rho} \right) \left( \frac{c_a^2+c_s^2}{2}right) \tauE(Wq)≈(1-ρρρ)(2ca2+cs2)τ

Notably, に対して非線形に増加し、cac_aca（到着数の変動係数）、 csc_scs（サービス時間の変動係数）に対して二次関数的に増加します。 (これは、キューは空か溢れているかのどちらかであるという直感を定量化したものです。)

これによる非直線性は、ashared resource を争う人々の数を増やすことは ρρを増やすことと同じであるため、私たちは立ち止まるべきです。 このようなリソースの競合が管理されない場合、組織の成長によって待ち時間が壊滅的に増加する可能性があります。 ある時点で、新しいメンバーを追加すると、組織全体の生産性は向上するどころか、低下してしまう可能性があります。 (これは、サーバーが過負荷になったときに見られる待ち時間の急上昇の組織版です。)

これらの共有リソースは、バスルームやプリンターなどの物理的なものとは限りません。ソース コード リポジトリ内のファイルやバグ追跡システム内のチケットなどのデジタルなものや、コード レビューや作業割り当てなどの組織的なものである場合もあります。 7877>

一般的に適用されるが、成功することはほとんどない戦略は、内部リソースの競合を回避するエンドランとして、外部リソース（コンサルタント、代理店、スタッフ増強など）を使用することである。 これは、待ち時間の2次スパイクを発生させ、利用率を増加させ、さらに待ち時間の超直線スパイクを発生させます（待ち行列理論は過酷な愛人です）。 7877>

重層化されたアプリケーションと同様に、組織を設計する人と行われている仕事の間の距離が長ければ長いほど、管理されていない競合のポイントが発生するリスクが高くなります。 トップダウンの組織的手法は、スライドに記載されると並行した作業のように見えるが、実際には高度な相互依存性と連動性を持つ細分化につながる可能性がある。 また、”Secondary “は “Secondary “の略称であり、”Secondly “は “Secondly “の略称である。 333人のグループには333のダイアド、444人のグループには666、555人のグループには101010、NNN人のグループにはN2-N2frac{N^2-N}{2}2N2-Nの可能なダイアドを持つ。 ポイントツーポイントコミュニケーション（つまり、お互いに話すこと）は、これらのダイアドのサブセットの活性化としてモデル化できる。

他の組織よりもおしゃべりな組織がある一方で、このコミュニケーションは情報の共有と行動の調整にとって不可欠である。 しかし、それは無料ではない。 コミュニケーションには時間がかかります。

このような点間コミュニケーションに関与するエンティティ数を減らすためのバッチ戦略としてグループ会議を考えることができるが、この戦略の有効性はグループの相対的重複度とグループ構造に大きく依存する。 グループの重なり具合は、基本的にコミュニケーションに必要なダイアドの割合と同じ要素である。 グループサイズに制限がある場合、コヒーレンスコストの増加は一定の要因で減少するが、それでも二次関数的に成長する。 コヒーレンスを無視し、ダーティに走ろうとするのは魅力的かもしれませんが、微妙なコヒーレンスにも莫大なビジネス・コストがかかるのです。 7877>

組織設計の観点からは、これは、組織のプロセスにおいて、相談する人々の種類と数の両方を制限することを意味します。 責任割り当てマトリックスに人やグループが1つ増えるごとに、そのマトリックスの面積は幾何級数的に増加する。 また、これらのペアワイズコミュニケーションは、コストが発生するために正式である必要も、計画されている必要も、よく知られている必要もないことも注目すべき点です。 従業員ハンドブックもカレンダーも、組織内の仕事がどのように行われるかを正確に表しているわけではありません。 あなたの組織にゾンビが配置されていない限り、組織のメンバーは常に実際の仕事を成し遂げるために標準的な動作手順を破壊しています。 アリでさえも、即興で仕事をする。 これらの隠されたコストの正確な会計は、それが起こっているときに、正直、非難なし、および継続的な仕事のエンドツーエンドの分析によって開発される。

時空を超える原理

仕事は並列に、グループは小さく、リソースはローカルにしておく

NNNが増加すると超線形に難解になってしまう一連の問題に直面したときに、最善の策はNNNを小さく保つことだ。 もし組織の意図が、より多くの人を雇うことによって価値の提供を増やすことであるならば、仕事の努力は可能な限り独立したものでなければならない。 リーダーは、戦略上並列とみなされる作業努力が実際に並列であることを保証するためのプラクティスとプロセスを開発する必要があります。 また、共有リソースが競合しないように継続的に管理し、可能であれば、あるグループが必要とするリソースをそのグループに配置する（例えば、設計が多く含まれる場合は、そのグループに設計者を配置する）べきである。 8758>

If an organization is largely working on the same types of problems they were in previous years, it’s scause for concern.これは、ある組織が前年と同じ種類の問題に取り組んでいる場合、懸念を抱かせる原因となります。 内部ツーリングに専念するチームは、人員を配置し、ツールの構築とプロセスの最適化を明確に指示して、同僚の生産性の向上を支援する必要があります。 組織の働き方を改善することに専念する組織の割合が低下し始めたら、グローバルまたはローカルな最大値に達したかどうか、自問自答してみてください。

If your work product-e.g. codebase, documents, etc. – can be factored into independent modules, do do.

If your work product-e.g. codebase, documents, etc. – be factored into independent modules, do. そこでのキーワードは独立です。 あなたのたわごとを100のマイクロサービスに分割しても、何かを成し遂げるために、誰もがそのうちの10を変更する必要がある場合は役に立ちません。 問題によっては、パーティションに特に従順でないものもあります。 もし、問題が定点であれば、作業の逐次比率を最適化する方法を検討します。 その問題に体を投げ出しても、クラスター・ファックを生み出すことになることを知っておいてほしい。 このような場合、「己の信念を貫く」ことが重要です。 もし、幸運にもトラクションを得ることができれば、彼らはこれを倍増させる。 オーバー。 何度も何度も。 何度も何度も。

このような事態を避けるために、組織のリーダーは、製品ポートフォリオの開発を明確な目標として掲げなければなりません。 組織のoverallbusiness戦略を補完するものでありながら、主要製品とは自然に共存しない機能や製品のアイデアは、独立したチームによってseparateproductsとして開発することができる。 また、ツール、ライブラリ、フレームワークをフォースマルチプライヤーチームで開発し、新製品の市場投入までの時間と既存製品の維持コストの両方を削減することができます。 成功しない新製品は、同じような複雑さの機能よりも劇的に低いコストで、潔く市場から撤去することができます。 結局のところ、製品から機能を削除するには、機能を追加するのと同じ競合コストと一貫性コストがかかります。 製品ポートフォリオの美徳の具体例として、Amazon Web Services を単一の製品として想像してみてください。10 万人の破滅的な魂によってスタッフされ、仮想マシン、データベース、データレイク、ロボットアプリケーション、拡張現実アプリケーション、IoT dingus などをプロビジョンし操作できる一連のボタンだけの UI を前面に出しています。 そのような生き物は、それ自身のweight.7877>

その代わりに、Amazon Web Servicesは、相乗効果の高い製品のポートフォリオです内破するでしょう。 EC2は独自の独立した機能セットを持ち、独立した従業員によって開発、運用されています。 そのニーズが他のAWS製品で提供できる場合（たとえば、S3に仮想マシンイメージを格納したり、CloudWatchにメトリックを送信したり）、製品間の統合が導入されます。 この製品構造により、Amazonが既存製品のサポートと開発を継続しながら、毎年膨大な数の新製品を提供することを可能にする、高度な同時進行型の組織構造を実現しています。

組織が成熟するにつれ、アドホックな役割が完全なチームへと発展していくことが多い。 このような専門化は、しばしば内部のスケールメリットを構築するために重要ですが、新しい構成員の正式な参加は抑制する必要があります。 責任分担マトリックスの各列は、必要な相互作用の可能性を幾何級数的に拡大するものであり、マトリックスの各分担は、待機を必要とする調整ポイントです。 マトリックスが2つのグループ間のハイタッチな関係を示している場合（例えば、ある機能に取り組むエンジニアのグループと、その機能の法的コンプライアンスを確保しようとする弁護士）、それらのメンバーをコロケーションすることによってその相互作用のコストを削減する努力がなされるべきです（例えば。

ミーティングやステータス更新の失敗の大きな原因は、組織のリーダーが、誰が何をしているかを常に把握しておきたいという願望である。 この状況認識は確かに重要だが、会議を招集したり、Slackでメッセージを送ったり、廊下で人を捕まえたりしてそれを維持しようとすることは、組織の生産性に対するシステム上の大きな足かせとなる。

組織が拡大する中で開発状況を把握するための優れたモデルは、グループが通常の仕事の流れの一部としてステータス更新を発行することである。 リーダーは非同期でこれらのアップデートを読み、必要があれば、質問やフィードバックの提供など、追加の同期的な会話を開始することができます。

同期的な会議は、複雑な問題に関する低遅延コラボレーション用に予約されるべきです。 企業は、有限な人生の一部をパートナーや子供、ペット、あるいは超変わった趣味と一緒に過ごせないことに対して補償を受ける人々の集団です。 彼らは、自分の仕事が価値と意味を持つことを保証することによって、その時間を尊重する組織のメンバーであるべきなのです。 7877>

この投稿をレビューしてくれた様々なFiascanに感謝します。 この記事中のいかなる間違いも、彼らではなく私が犯したものです

。