組織は生き物、組織としての最適解の見つけ方_#1_Dynamicな組織を作る
PdMについて学習し、最後にPdMのスキルを深堀りするために、もっと知りたいことが出てきました。
A）ユーザーとの関係強化と製品への反映方法
B）UXの基礎
C）これからのビジネスに必要な人材要件
D）組織変更の仕方
A、B、Cとかなり良い本にも出会うことができ、読み進めることができました。
PdMについてのまとめ
A）ユーザーとの関係強化と製品への反映方法
B）UXの基礎
C）これからのビジネスに必要な人材要件
そしていよいよ、組織について学んでいきます。
正直PdMの実務経験がない中でいきなり組織の話まで行ってよいものか・・と疑問はありました。
ただ組織の問題はビジネスを進めるうえで常に付きまといます。
曲がりなりにも4年間ほど組織の長を務めさせてもらう期間もあり、そのとき感じたのは
「組織は生き物、常に変化しなければいけない」
でした。なので今回は少し大げさかもしれませんが、こんな経験も含めてタイトルをつけさせてもらいます。
それでは早速進めていきます。
文字数：約6,400
参考図書
第1章 デリバリーの手段としてのチーム
①静的モデル（組織図・マトリクスマネジメント）の問題
■組織図の問題
・近年、システムが人間の日々の活動のあらゆる側面に影響を与えている
・複雑で相互に接続されたソフトウェアシステムは構築も運用もチームでの活動となり、さまざまなプラットフォームをまたいで、さまざまなスキルを持つ人たちの力を結集する必要がある
・組織図に過度に依存して仕事を分割、管理している組織は早いペースでのデリバリーとイノベーションへの適応の両立に必要な環境を作り出すのに失敗している事が多い
・かつてないほど競争の激しいマーケットで生き抜くには状況の変化を感知し、それを踏まえて進化できるチームや人が必要
・ここからはビジネスの速度と安定性を実現する技術組織の適応型設計モデルのひとつとして、チームトポロジーについて紹介する
◼️ 組織のコミュニケーション構造
・組織図はソフトウェアシステムの構築においては、規制やコンプライアンスの遵守に役立つ
・一方で組織図に依存すると、アウトカムの不確実性が高く、コラボレーションを重視する状況では、やるべき仕事を分割する基本原則となってしまう
・速度と安全性のバランスを取るには、効果的なコラボ可能な疎結合（分けるのが簡単な結合）で長続きするチームが望まれる
＜組織図の問題＞
・組織図は実際のコミュニケーションは表現できない
・組織図の構造に基づく意思決定は、組織の一部分に最適化されがち
・コミュニケーション不足の不適切なプロセスによって硬直化したチーム構造がデリバリーを遅くする
・組織図に囚われると、仕事の割当や責任について効果的な判断ができない
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P2〜P7
■組織図からの脱却（チームトポロジー）
・すべての組織には、1つではなく3つの異なる組織構造がある
1、公式な構造（＝組織図）
コンプライアンス遵守を円滑にする
2、非公式な構造
個人間の「影響力の領域」
3、価値創造構造
個人間やチーム間の能力に基づいて実際にどう仕事を終わらせるか
・成功のカギは、非公式構造と価値創造構造のインタラクション（＝人とチームインタラクション）
・チームに権限を与え、チームを基本的な構成要素とすることで、個人は単なる人の集まりでなくチームとして密接に連携する
・組織図やマトリクス組織のように単一で静的な組織構造を利用していては、現代のソフトウェアシステムで効果的なアウトカムは生み出せなくなっている
・チームの成長やインタラクションを考慮にいれた状況に適応した動的な組織モデルが必要
◼️ チームトポロジー：チームについての新しい考え方
・チームトポロジーはさまざまなチームが技術や組織の成熟に応じてどう進化するかに目を向けている
・技術やプロダクトの探索段階では、成功のためにチームの境界がオーバーラップしたコラボの多い環境が必要
・ゴールは顧客のニーズに合うソフトウェアをチームがより簡単に構築、実行しオーナーシップを持てるようにすること
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P7〜P10
■コンウェイの法則と認知負荷
◼️ コンウェイの法則
・1968年にメルビン・コンウェイが、組織構造とその結果としてのシステム設計の関係性を考察したもの
・コンウェイの法則とは、『組織の本当のコミュニケーションと結果として得られるソフトウェアアーキテクチャには強い相関関係がある』
・コンウェイの法則から言えることは、チーム構造は要求されるソフトウェアアーキテクチャと一致しなければならない。
◼️ 認知負荷とボトルネック
・短期記憶のリソースには限界があるように、チーム全員の認知容量にも限界がある
・限界があることは当たり前と思いながらも、チームの責任やソフトウェアの担当範囲を割り当てるときに認知負荷について議論することはない
・背景には認知負荷の定量化が難しいことがある
・認知負荷を考慮しないとチームの責任範囲と担当領域は広がり過ぎる
・チームへの要求は通常、時間と共に増え続ける
・新規サービスの開発では、チームの時間はすべて使えて認知負荷などないかのように計画される
・チームの認知負荷を上回るとデリバリーがボトルネックとなる。そして遅延、品質問題からチーム内のモチベーション低下につながる
・内発的モチベーションの3つの要素
1、自律：要求や優先順位の度重なる変更はダメ
2、熟達：多芸ほど無芸
3、目的：広すぎる責任範囲はダメ
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P10〜P16
②コンウェイの法則が重要な理由
■コンウェイの法則の理解
◼️ コンウェイの法則を理解する
・システムのアーキテクチャと組織のアーキテクチャが対立する場合、組織が勝つ
・指揮命令系統がどうかに関係なく、組織内のコミュニケーションパスが、組織が考案できるソリューションの種類を限定する
・コンウェイの法則を利用した組織設計は、効果的にソフトウェア設計を大幅に加速させ、さほど効果のない設計を回避させることにつながる
◼️ 逆コンウェイ戦略
・逆コンウェイ戦略とは『組織はチーム構造と組織構造を進化させ、望ましいアーキテクチャを実現する考え方』
・逆コンウェイ戦略を選択することで、ソフトウェアが完成するより前に、チーム間の相互のコミュニケーションを再構成できる
・4つのシステムアーキテクチャと組織の例（本書参照）
◼️ チーム内のフローを良くするソフトウェアアーキテクチャ
・チーム編成する前にソフトウェアアーキテクチャの理解が必要
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P17〜P27
■コンウェイの法則に準拠した組織設計
◼️ 組織設計には技術的知識が必要
・どのサービスを構築すべきか、どのチームが構築すべきかということをマネージャーに決めてもらっている以上、システムのアーキテクチャもマネージャーに決めてもらっているのと同じになってしまう
・人事や部門長は自分達の組織への決定がソフトウェアアーキテクチャの生存可能性に与える影響など理解していない
・技術リーダーの意見を聞かずにチームの形成、責任、境界に決定を下すことは非常に非効率
・組織設計にはエンジニアを巻き込む
◼️ 不必要なコミュニケーションを制限する
・どの仕事には強力なコラボが必要で、どの仕事には必要ないのかという期待値の設定が重要
・必要なのは特定のチーム間の集中的なコミュニケーション
◼️ コンウェイの法則適用の注意点
1、ツールの選択
・組織はそのコミュニケーション構造を反映した設計を生み出す
・それゆえ、チーム間のインタラクションに共有ツールが及ぼす影響には気を配る
・チームにコラボして欲しければ、共有ツールは有効
・一方、チーム間の明確な責任境界が欲しければ、別のツールを使うか、同じツールを別インスタンスで使うのが最適
例1）SW開発とIT運用の連携が必要な場合、チケット管理ツールと問題管理ツール（バックログ）を2チームがそれぞれで持つと、チーム間のコミュニケーションがうまくいかないことが多い
例2）本番環境にセキュリティアクセス可能なチームだけが使えるようにすると、ツールへのアクセス権限によってチーム間のコミュニケーションの断絶を促進しかねない
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P27〜P35
③チームファースト思考
■小さなチーム
◼️ 長続きする小さなチームを標準とする
・チームとは5〜9人のメンバーから成る安定したグループで共有されたゴールのために働く単位のこと
・ソフトウェアの設計、提供、運用におけるすべての側面において、チームから始める
・強い信頼関係があるとチームは実験しイノベーションを起こすことができる
・「ソフトウェアアーキテクチャ」と「チームが効果的にアーキテクチャのオーナー」であり続けるためには、新しいチームのグルーピングに沿ったやり方に合わせる必要がある
・チームが効果的に働けるようになるには時間がかかる
・チームを安定させる必要はあるが、固定してはいけない（内部メンバーの入れ替わりはあっても組織としてチームの存在と立ち位置はキープしておく）
・「年次個人評価」と「MBO」を廃止し、個人のパフォーマンスでなく、チーム全体の活動に対してチームに報酬を与える
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P36〜P46
■忘れられがちな、チームの認知負荷
◼️ チームの認知負荷に合うように責任範囲を制限する
・ソフトウェアデリバリーで摩擦を増やす要因のうち最も認知されていないものが、『チームが扱うコードベースのサイズと複雑さ』であり、チームに際限のない認知負荷をもたらす
・認知負荷はコーディングより運用やインフラチームに当てはまる
・チームファースト思考では、チームの責任範囲をチームが扱える認知負荷に合わせる
・3つの認知負荷
1、課題内在性負荷
＋問題の領域の本質的なタスクに関連
例）Javaクラスの構造は？新規メソッドを作成するには？など
基本的なプログラミングの知識と開発に利用する言語の知識
2、課題外在性負荷
＋タスクが実施される環境に関連
例）このサービスを構成するには？
テスト環境を動的に起動するための覚えにくいコンソールコマンドの詳細など
3、学習関連負荷
＋学習を進めたり高性能を実現したりする上で特別な注意が必要なタスクに関連するもの
例）このサービスはあのサービスとどのように関わるべきか
動画処理アルゴリズムなど開発しているアプリケーションのビジネスドメインなど
・差し当たって対処しなければいけない課題内在性負荷と外在性負荷を継続的に下げていく事が必要
・そのためには、研修、実践、自動化など活用する
・素早く簡単に認知負荷を知る方法は『中立的な立場から、“頼まれた仕事に対して効果的でタイムリーな対応ができているか”と尋ねる』
・認知負荷の計測にドメインの複雑度（＝ソフトウェアで解こうとしている問題がどれだけ複雑か）に注意を払う
・例として異なるドメインとして、「ビルド」「継続的インテグレーション」「継続的デリバリー」「テスト自動化」「インフラ自動化」などのこと
・チームにとって適切なドメイン数や種類の答えはない
・各チームが取り扱うドメインを特定しそれを
1、シンプルさ：明確な作業手順がある
2、煩雑さ：変更の分析が必要で適切なソリューション提供までに数回の繰り返しが必要
3、複雑さ：ソリューション提供までに、多くの実験、探索が必要
で因数分解する
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P46〜P56
■チームAPI
◼️ チームAPIを設計し、チームインタラクションを促す
・API（ Application Programming Interface ）はプログラムがソフトウェアとやり取りするための方法を記述した仕様であり、これをチームに転用すると
1、コード：チームが作成しているライブラリ、クライアント、UIなど
2、バージョン管理：変更点へのコミュニケーションルール
3、Wikiとドキュメンテーション：チームがオーナーシップを持つソフトウェアのハウツー
4、プラクティスと原則：チームが好む働き方
5、コミュニケーション：リモートコミュニケーションツールの定義
6、仕事に関する情報：チームが現在取り組んでいること、次にリリースするもの、中期的な全体優先度など
7、その他：他のチームとやり取りするために必要なことすべて
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P56〜P69
①~③の要約
①静的モデルの問題
・コンウェイの法則では、ソフトウェアアーキテクチャとチームインタラクションを同時設計する利点を説く
・チームトポロジーはチームの目的と責任を明確にし、チーム間の相互関係の効果を向上させる
・チームトポロジーでは、戦略的適応性の実現のために組織を調整し、ソフトウェアシステムの構築において人間的なアプローチを利用する
②コンウェイの法則が重要な理由
・組織はそのコミュニケーションパスを反映した設計を作る
・組織設計はソリューション探索の制約になり、取り得るソフトウェア設計を限定する
・全員が他のすべての人とコミュニケーションするように求めるのは混乱のもと
・チーム内のフローがよくなるようなソフトウェアアーキテクチャを選択する
・明瞭なチームインタラクションだけにコミュニケーションパスを限定することで、モジュール化した疎結合なシステムが生まれる
③チームファースト思考
・チームはソフトウェアデリバリーにおける最も効果的な手段であり、個人ではない
・ダンバー数（チーム上限数）を踏まえてグループ内のチーム数を制限
・チームの認知負荷の許容量に合わせて責任を限定する
・チームごとに明確な責任の境界を作る
・チームの成功の助けとなるよう作業環境を整える
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P1
＜所感＞
少し読んだ（P10くらいまで）感想
あっ…この本絶対面白いしタメになる
でした。
こんなに良書に出会いまくって良いのか、と思うほど素晴らしいです。
従来の組織（組織図、マトリクス組織）をStaticと表現してくれた瞬間に何か私の中で氷解した気がしました。
従来型のOTV（One Time Value）は、売れる商品を作り、売れれば一気に大量生産
つまりStaticで人および組織の『慣れ』と言うファクターが組織力を高めていました。
ただユーザーへの提供価値が猛烈に変化する課題解決になったいま、ビジネスはリテンション/リカーリング型に変化しています。
これはビジネスの流行りではなく必然です。
ビジネスモデルの変化に言及したノウハウ本は溢れかえっています。
ただ組織について触れたものは見たことありませんでした。
まさにこの本です。
これはバイブルです。
っていうか、JMAM（日本能力協会マネジメントセンター）の本ははずれがない！
他の本も読んでみます。
この記事が気に入ったらサポートをしてみませんか？