『組織パターン』 の 4.2 節で説明されるパターン言語たちのこと。

フィードバックと洞察を利用して組織を強化して、微調整するためのパターン。 人間の本性と人間の組織についてのパターンであり、ソフトウェア開発の組織に限ったパターンではない。

4.2.1 : 信頼で結ばれた共同体

4.2.2 : 組織を細かくする (大規模なソフトウェアシステム (25 KSLOC 以上が目安) を開発するために基本は 10 人を集める。 終盤に人を追加したり、期日から逆算して作業しようとしたりするのはやめる)

4.2.3 : 段階的に人を増やす

4.2.4 : 徒弟制度 (新しく雇った人を徒弟制度を通じて職人に育て上げる。 期間としては半年から 1 年かかる)

4.2.5 : ソロ・バイオリニスト (大規模でない (25 KSLOC 未満が目安) ソフトウェアシステム開発においては、システム全体の設計と実装を、最も生産性の高い 1 人か 2 人で行う)

4.2.6 : 顧客たちを巻き込め (顧客を開発者やアーキテクトに密接に結び付けるべきで、可能であれば顧客をこちらの環境に巻き込むこと)

4.2.7 : 顧客の代理 (顧客と直接会うことが難しい場合は、プロジェクト内に顧客の代理を立てる)

4.2.8 : シナリオが問題を定義する (システムの機能的な要件をユースケースとして表現する)

4.2.9 : 防火壁 (情報のやり取りは大事だが、多くの割り込みはノイズになる。 外部のロールとのやりとりから開発者を守るためのマネジャーロールが作ると良い)

4.2.10 : 門番 (プロジェクト外部の最先端の情報や二次的な情報をプロジェクトメンバーに伝えるために、魅力的な性格を備えた人気者を門番のロールに割り当てる)

4.2.11 : 自分たちで選んだチーム (チームメンバーを自分たちで選ぶようにして、熱心なチームを作る)

4.2.12 : 目的の統一 (プロジェクトのリーダーは、チームメンバー全員に共通のビジョンと目的を教え込まなければならない)

4.2.13 : チームのプライド (プロジェクトに好い印象を持っていて、自信があるのが大事。 チームが精鋭主義を感じられるようにする)

4.2.14 : スカンクワークス (イノベーションの取り込みについてリスクが高くならないよう、コストの限られたチームでアイデアを試し、アイデアに自信をつけるようにする)

4.2.15 : パトロン

4.2.16 : 多様な集団 (集団思考に似た機能不全に陥らないように、チームを作るときには個々人の性格や経験してきたことを考慮に入れる)

4.2.17 : 人気者 (組織という社会的な存在がスムースに機能するために、社会的なプロセスを助ける)

門番や婦長は人気者の一例

婦長は組織を育てることに関心があり、内側に集中する

門番は外側に集中し、組織が次に向かうべき大きな方向性を常に探す

人気者は両者の中間

4.2.18 : 婦長 (チームが統一感を持ち続けるために必要な、社会的・対人的活動に責任を持つ)

4.2.19 : 全体論的多様性 (プロジェクトに必要な複数のスキルを別々の組織が持っていることがある。 チームをまたがるコミュニケーションは非効率で不完全なものになりやすい。 よって、各機能やデリバリーする機能のまとまりごとに小さいチームを作り、その機能のデリバリーに責任を持たせる)

4.2.20 : 偉人 (居なくなるとプロジェクトに深刻な影響が出るような人がいる場合、その人にちなんだロールを用意し、そのロールを果たすことを名誉とする。 それによってそのロールの引継ぎを円滑にする)

4.2.21 : 賢い愚者

4.2.22 : ドメインエキスパート

4.2.23 : スキルに応じたサブシステム

4.2.24 : トラックナンバーはほどほどに

4.2.25 : 成功報酬

4.2.26 : 失敗プロジェクトの通夜

4.2.27 : 手を止めて始めた作業を中断するな

4.2.28 : ペアで開発する

4.2.29 : 品質管理を巻き込め

4.2.30 : アプリケーションの設計はテストの設計により境界付けられる

4.2.31 : 雇われアナリスト

4.2.32 : グループでの検証