組織パターン
https://images-fe.ssl-images-amazon.com/images/I/61UpQguFh5L.jpg
(読書開始 : 2019-07-27 / 読了 : 2020-05)
内容
第 1 部 歴史と導入
1. パターンと組織パターンの概要
本書には 4 つのパターン言語がある :
4 つのパターン言語がそれぞれ別の組織を構築するわけではない
健全な組織は、これら 4 つのパターン言語に由来するパターンを同時に複数示す
たいていのシステムと同じように構造を持っている
構造とは？ : 例えば階層と権威、トップダウンの統制など
構造は文化の一部
文化が重要
組織に対する工学的アプローチは伝統的に事後検証を行うという過ちを犯してきた
そして、そこに文化が寄与していることが無視されてきた
文化の中に生きていると、文化を見ることは難しい
我々は大失敗を待たずに先手を打って企業文化の育成と修復を行うことができる
ソフトウェアの世界ではアーキテクチャという言葉でシステム構造の統合を説明することがある 組織についても同様にアーキテクチャと単語で説明できるかも
組織内の構造と組織間の関係性から構築される
この構造がパターン
2. パターンの登場
パターンは発明されるものではなく発見されるもの
組織の保守というドメインについて、隠されたパターンを見つけ出し、それを書き留めたものが本書
本書では日本や中国のチームは対象にしていない (ので、文化的に合わない可能性はある)
パスツール研究では 2 種類の絵が用いられた
これらの標準は 1980 年代後半から 1990 年代前半にかけてソフトウェア開発に対する影響を広げた
これらは、プロセスの再現性に焦点を合わせている : 振れ幅を小さくすること
統計的なプロセスコントロール :
プロセスを理解できれば改善できる
理解するためには一貫した構造がなければならない
構造が一貫しているためには、プロセス改善の第一歩がプロセスの振れ幅を減らすようになっていなければならない
現代のほとんどの組織にあるプロセス文化は、プロセスを文書化することに強く着目しているが、文書化されたプロセスは日々の実践に沿っていない
プロセス文化が組織の振る舞いにおける重要な振れ幅を無視している
これはマーケット不確実性や、人間の知性や本能に根ざしたあらゆるプロセスから生じる不確実性に対処する鍵である プロセスを強調する組織はプロセス定義ドキュメントを開発活動のゴールだとみなすが、問題がある
実践とプロセス定義とが経験的にすり合わされることがない
プロセスのモデルが不十分 : タスクやイベントといった見方に焦点を絞り、成果物やロール、アクター、エージェントといったものを二次的な抽象物として置き去りにする
なぜタスクに着目するのか？
期間を予測して短縮しようとするため (個々の作業の期間に着目することで期間の全体を管理しようとする)
品質を高めようと必死になるため (方法論的なレビューで、明確なタスク・イベントというベンチマークが形成される)
こうしたモデルによってプロセスタスクと成果物が切り離されるという病に、ほとんどの組織が感染しているのではないか
プロセスタスクと成果物が切り離されるというのがいまいちよくわかってない nobuoka.icon
長期間にわたって安定するようなプロセスの抽象を捉えることができない
タスクやイベントといった側面を中心としてプロセス改善プログラムを構築している組織が多い
プロセスがよく理解されている場合 (障害報告フローなど) は、秩序立てられる場合も多い
しかし、ソフトウェアアーキテクチャや設計、実装、検証のような中核的なプロセスは、タスクという見方からはほとんど理解できない
高度な開発技術を持つ開発組織において、タスクの優先順位が頻繁に切り替わっていることに気づいた
そのような組織では、タスクをプロセス構造の安定した構成要素だと考えられない
研究対象の例) 開発者の 8 割が、公式の共通プロセスではなく、公式に認められた例外的なプロセスの元で作業していた
その理由のほとんどは、プロジェクトのプロセス標準ではプロセスの本質的で安定した構造が捉えられていないため
鎖のようにタスクをつなげるというモデルが安定した構造を捉えられていない理由の一つは、最近のソフトウェア開発で高度に並列化が進んでいること
研究対象の組織の多くが、要件定義や設計・実装を並行して進めていた
イテレーティブでインクリメンタルな設計文化では、成功を収めると同時に、プロセスについての自覚も育っている
プロジェクトマネージャはイテレーティブかつインクリメンタルな技術をプロセスの各段階を規定するプロセス標準と組み合わせようとしてうまくいかないでいる
並行エンジニアリングを行っている組織にとっては、ロールを基にしたモデルの方が、タスクやイベントを基にしたモデルよりもうまく当てはまりそう
組織を改善する際に、明示的にプロセスを基にするアプローチがあるが、それが引き起こす問題に対して明示的にロールを基にするモデリングアプローチで立ち向かおうとしている
あらゆる文化において、「真の」 組織の定義は、「アクターやロールが共通の関心や目的によって結びつけられている」 という観点から行える
インストゥルメンタルな組織とは 「組織のふるまいを規定する道具」
実地調査でインストゥルメンタルな組織モデルを構築した
エンジニア視点で
組織を分析するためのツールとして CRC カード (もともとソフトウェアの設計用; インデックスカード 1 枚が 1 つのオブジェクトを表す) を使用 システムというロールプレイング活動において、クラスが持つ責務と協力関係を記録し、追跡するのに使われる
組織分析においては各インデックスカードがロールを表す
出てきた 3 つの評価基準 :
ロールの数 : (人数ではなくロール)
コミュニケーションの集中度 : 潜在的に他のロールとコミュニケーションする可能性がある中で、実際に使われているコミュニケーションパスの割合
コミュニケーションの強度比 : 最もパスが多いロールのコミュニケーションパスの数の、組織全体のロールがもつコミュニケーションパスの平均値に対する割合
(これが集中度っぽい気もするけどそうでもないのかな nobuoka.icon)
本書のパターン言語自体は安定しているが、組織は常に変化するし、変化の方向を常に予想できるわけでもない ダイナミクスはパターンの適用と、適用する順序に由来する
順序が極めて重要。 パターン言語のための順序があり、それらは物語として説明される
順序を保てば次のことができる
構造を保つ
一度に一つずつ進めていける
各段階において組織全体を考慮に入れる
パターン自体を何万回と繰り返せる
3. 本書の使い方
まずはパターンを読む
本書の最後にはパトレット (パターンについての簡単なリファレンス) もある 次にパターンを適用する
難しい。 組織の文化を変えるのは一筋縄ではいかないし、痛みを伴うこともあれば危険なことすらある
組織の原則 (6 章) を先に読むこと
一度に一つのパターンを適用すること。 うまくいっていないようだったら戻ること
パターンを使うのが正しいのは、組織に実際に存在するフォースを解決する限りにおいてのみ
新しいパターンやパターンの更新が必要になるだろうので、パターンを更新する
第 2 部 パターン言語
プロジェクトマネジメントと組織の漸近的成長のパターン言語は設計 (デザイン) のための言語
構築すべき対象物の基礎が作られる。 今回の場合は組織
組織スタイルと人とコードのパターン言語は、構築のための言語
4. 組織デザインパターン
アレグザンダーの用法では、デザインパターンとは、建物の幾何学と部品間の主要な関係を理解するために使われる ソフトウェアにおけるアーキテクチャっぽい
この章に出てくるパターンとその関係