組織の勉強の一環として「組織パターン」読んだ。
この本は、チームや組織が、よく陥る問題とその解決策について、組織パターンという形でまとめて教えてくれる。パターンは
- パターンの名前と重要度
- ・・・の後にコンテキスト
- 星三つのあとにパターンの背後にあるフォースやトレードオフ
- それゆえの後に解決策
- 星三つのあとに、なぜそのパターンがうまくいくか
- そのあとに他パターンへの参照
のように書かれていて、特定問題が起こる背景や、そのとき解決の一案、さらにその解決策がなぜ効果的かというのが分かるようになっている。ただし、この本の最後の方に「組織パターンはインスピレーションをもたらすのに使うべきで、そのまま適用するべきではない」と書かれているように、そのまま適用するというより、気づきを得て自分の考えのサポートにする使い方が良いのだろう。
この本を読むと、チームや会社に対して自分が感じている「なんとなく良くない」ことを言語化したり、自分が気づいてなかった「実は良くないこと」を発見することができたり、それらの問題の解決の糸口をつかめたりということができる。また、逆に自分が気づかずにやっていた良いパターンの発見にも役立つ。そのため、「なんとなく良くない感じがしているのだけ何が良くないのか分からない...」と感じている人には、参考になるだろう。
個人的に面白かったなと思ったのは、以下の点。
- 誰か一人を犠牲にするパターン
- 余計な作業が細かく積み重なると、集中を奪い、チームの力を蝕んでしまう
- 誰か一人余計な作業に割り当てて、その作業を終わらせる
- 【感想】よくやってしまうのは、全員に面倒事を分配しがちになってしまい、結果として重要プロジェクトのリリースが遅れるということがあるので、面白い
- シナリオが問題を定義する
- 賢い愚者
- 成功報酬
- 個人に報酬を与えることにより、企業の価値体系に合ったビジネスの目的を達成するように仕向けることが重要
- 成功に導くような振る舞いに報酬を与える
- 組織が価値を置くものについて報酬を与えるようにする
- 組織内で共有された「達成すべき重要事項」という価値体系に基づいて報酬を与えるのが一番
- 【感想】どの組織の本でも、成功報酬を組織が価値を置いているものに適切に与えることが重要と書かれているので、その一種であろう。成功に導くような振る舞いに報酬を与えるというのが面白い。成功報酬を組織が価値を置いているものに与えることで、組織の行動を徐々に変化させることができるのだろう
- コンウェイの法則
組織についての勉強として、次はなぜ評価制度がありどういう効果があるのかについて知りたいので、人事管理入門という本を読もうと思う。
読書メモ
- 改善する時、間違って行っていることを見つけ、プロセス内でエラーが発生している場所を見定め、それを適正化することが多い。プロセス全体が間違っているかもしれないと考えられることはほとんどない 88
- 各パターンはシステムに構造を付け加えることで問題を解決する 487
- パターンの短い定義 494
- 繰り返し発生する構造的な形で、あるコンテキストにおける問題を解決するもの。なんらかの全体の全体性あるいはシステムに寄与し、美的あるいは文化的な価値を反映する
- パターン言語 505, 1064
- パターンの名前と重要度
- ・・・の後にコンテキスト
- 星三つのあとにパターンの背後にあるフォースやトレードオフ
- それゆえの後に解決策
- 星三つのあとに、なぜそのパターンがうまくいくか
- そのあとに他パターンへの参照
- 四つのパターン言語 614, 649
- プロジェクトマネジメントのためのパターン言語: スケジュールやプロセス、タスクなど、特に仕事がうまく進むよう支援するのに必要な構造に焦点
- 組織の漸進的成長のためのパターン言語: 組織とプロセスを同時に成長させる方法
- 組織スタイルのためのパターン言語: 組織におけるロール同士の関係性の構造に目を向け、これらの関係性が別の組織スタイルへの前触れとなっていることを検証する
- 人とコードのためのパターン言語: 組織の構造と組織が生み出す成果物との間には密接な関係があるというコンウェイの法則を拡張する
- パターンを順序に従って一つずつ適用し、フィードバックを受けながら、時間をかけて発展させていく必要がある 979
- 一度に一つのパターンを適用しなさい。そして、うまくいっていないようだったら戻りなさい 1140
- プロジェクトマネジメントのためのパターン言語のつながり図 1272
- 信頼で結ばれた共同体 1301
- チーム内の人間が互いに信頼し合うことが欠かせない。そうでなければ、何かをやりとげることは難しいだろう
- 信頼していることを明示的に表現する行為をする。重要なのは、こうした活動が目に見えてはっきりとしていなければならない
- 信頼は、顧客も含め全員の間で築かなければならない
- 信頼というものは伝染しやすく、組織の中をトップダウンで効果的に広がっていく
- プロトタイプを構築せよ 1600
- 要件や設計上の判断をテストして、コストを浪費したり期待を裏切ったりするリスクを低減しなければならない
- プロトタイプを作る目的: 潜在的なニーズを含む要件の理解、顧客と一緒に要件を検証して顧客を巻き込む、システムにおける人間とコンピュータのやり取りについて検討すること、設計上の判断について費用対効果を検討すること
- プロトタイプは捨てることが重要
- リスケは一度だけ大きくする 1710
- 細かいリスケを続けると、誰もスケジュールを信じなくなる
- 作業の分割 1766
- プロダクトバックログの分割と、優先度の決定みたいな感じ
- ワークキュー 1812
- プロダクトバックログは一つずつスケジュールするのではなくて、単純に優先度順にしましょうという感じ
- 緊急度や優先度が高い項目を上に
- 開発者がプロセスをコントロールする 1926
- うまくいっている組織は有機的に機能していて、中央集権的なコントロールは最低限に抑えられている
- ある機能を作るときは、開発者が最初から最後までやる。要件を理解する、設計する、実装する、テストするなど。
- 作業が内側に流れる 1961 ※
- ある程度の中央集権化と指示は必要だが、行き過ぎると中央がボトルネックになる
- 顧客をはじめとしたステークホルダーから開発者へと、作業が流れ込むべきだ。作業がマネージャーから流れ出すべきではない
- 誰か一人を犠牲にする 2165 ※
- 余計な作業が細かく積み重なると、集中を奪い、チームの力を蝕んでしまう
- 誰か一人余計な作業に割り当てて、その作業を終わらせる
- 託児所 2240
- 新人教育も、一人が新人全員の教育に割り当てる
- 誰か一人を犠牲にすると同じ
- 組織の漸進的成長のためのパターン言語のつながりの図 2497
- 組織を細かくする 2542
- 技術マネージャーのグループは10人まで
- 人月の神話感
- 段階的に人を増やす 2626
- 雇用は段階的に、プロジェクトの成長の段階に応じて必要な人を入れる
- 顧客たちを巻き込め 2713 ※
- 顧客とのコミュニケーションは「顧客満足度」グループだけで負うべき責務ではない
- 開発者もアーキテクトも、自由にそして頻繁に顧客と話をすべき
- 防火壁や門番を使って、顧客と開発者とのやりとりを注意深く調整する必要もある
- シナリオが問題を定義する 2859 ※
- システムの機能的な要件をユースケースとして表現
- 確かに仕様では議論が進まないが、ユースケースや画面を作ると議論がされるように感じる
- 防火壁 2887
- 外部の協力者が増えるにつれて、コミュニケーションオーバーヘッドは加速度的に増える
- 開発担当者を外部のロールとのやりとりから守るマネージャーロールを作る。このロールの責任は「ペストを寄せ付けない」ことにある
- 門番 2932
- プロジェクトの外部から来る最先端の情報や二時的な情報を、プロジェクトメンバーに翻訳して伝える
- マーケティングと開発とのかけはし
- 防火壁とバランスが取られる
- 役に立つ情報が効率的に流れるようにするパターンで、防火壁が気をそらすような情報の流れを妨げるのと対照的
- 目的の統一 3009 ※
- 最終的にプロダクトがどうなるべきかが曖昧になっていると、一貫して作れない
- プロジェクトのリーダーは全員に共通のビジョンと目的を教え込まなければならない
- このプロダクトは何をすることになっているのか？誰が顧客なのか？このプロダクトはどうやって顧客に役に立つのか？スケジュールは？スケジュールを確約できると誰もが感じているか？競争相手は誰なのか？
- コミュニケーションはビジョンを共有するための手段にすぎない
- スカンクワークス 3085 ※
- イノベーションのジレンマ的な
- イノベーションのアイデアを取り込みつつ、通常通りサービスを進歩させていく
- アイデアを試し続けるチームを作る
- その組織は強力な防火壁で支え、上位の経営陣や資金提供者たちの詮索に邪魔されないようにする
- 人気者と婦長と門番 3289
- 婦長は組織を育てることに関心があり内側に集中する
- 門番は外側に集中し、組織が次に向かうべき大きな方向性を常に探す
- 人気者は両者の中間だが、どちらとも異なっている
- 賢い愚者 3492 ※
- コンフリクトを起こす必要性みたいな話
- 人間同士のダイナミクスは、時に、よいアイデアを口にしたり、悪いアイデアを取り除いたりすることの妨げになる
- 誰かが触媒となって、時々グループの内省を促す必要性
- ポイントは、組織が内部からの批判を喜んで受け入れなければならないこと
- トラックナンバーはほどほどに
- 完全なる属人性は避けたほうが良いが、属人性を排するのに多大なコストをはらうのも無駄という話
- 成功報酬 3732 ※
- 個人に報酬を与えることにより、企業の価値体系に合ったビジネスの目的を達成するように仕向けることが重要
- 成功に導くような振る舞いに報酬を与える
- 組織が価値を置くものについて報酬を与えるようにする
- 組織内で共有された「達成すべき重要事項」という価値体系に基づいて報酬を与えるのが一番
- 組織構築パターンの関係性の図 4098
- 分割統治 4277
- 成長した組織をどう分割するか
- 強力な相互関係がありながら、組織の他の部分との結合度が低いロールのクラスタを見つけよう。そして、そのロール郡を中心にして、今あるものとは別の組織とプロセスを形成しよう
- ただし、組織の中には、はっきりとしたサブドメイン(プロジェクトが成功し、拡大してマーケットが確保できるようになったら、部署に成長するもの)が必要
- 機能単位の垂直分割のイメージかな？マイクロサービスでの分割に通ずるものがある
- コンウェイの法則 4318 ※
- ビジネスの主構造、組織の構造、ソフトウェアの構造の三つを整合させたものが、長期的に見て最善の構造
- 三つを整合させるアプローチとして
- 主要なソフトウェアの成果物をドメイン分析の考慮点を中心に設計し、組織とアーキテクチャを揃える
- ビジネス上のニーズを中心に組織を設計し、アーキテクチャが組織に従うようにする
- アーキテクチャが安定していない状況で組織をアーキテクチャによって境界づけてはならない
- 関連: 組織はマーケットに従う 4453、組織は拠点配置に従う
- 拠点が離れていてもコミュニケーションが貧弱にならない条件(リモートワークの成功) 4419
- すべての拠点を合計しても、プロジェクトの開発者の数が少ない
- ほとんどのコミュニケーションがEメール(広く分散され、非同期のコミュニケーション)のようなもので行われている
- 関わる人が一定期間一緒にいて、お互いを知っていると感じている
- 「不必要」な移動のせいでメンバーが疲れてしまうことのない程度に、必要に応じて喜んで移動する人たちである
- コミュニケーションの強度比 4630
- 負荷の偏りを可視化する
- 「最も忙しいロールのコミュニケーションパスの数」と「ロールあたりのコミュニケーションパスの数の平均」との比率として定義
- コミュニケーションの強度比を2かそれ以下に保つ必要あり
- ハイコンテキストで成熟した領域では、機械化が実現できる 4771
- これは流動状態では機械化はできないけど、特化状態ならできるみたいな話とかぶる
- 流動状態と特化状態は、プロダクトよりもっと小さい機能単位でも起こると考えておく
- デイリーミーティングで言い合うことの例 5330
- 1. 前回のミーティング以降何をしたか、2. どんな障害に行き当たったか、3. 次のミーティングまでに何をするのか
- 疲弊しつつある組織は、学習するための時間をとれず、学ぶことができない 6099
- 危機によって学習の機会が生み出される。その危機について事後分析を行えば、組織が大いに学習するための種を蒔ける 6216
- AT&Tの組織変革においての主要な原則の一つ: 一度に変えようとしてよいのは三つまで
- 文化は中核的には安定を望むので、緩やかに変えていく必要がある
- 組織からのフィードバックにはフィルターをかけ、総じて人は変化に抗うということを心に留めておく必要がある 6501 ※
- フィードバックだけでなく、組織の全体感を向上させる方向に向かっているかを適切に見る
- 文化の中でパターンが受け入れられるのには時間がかかる。自分でいつまで待つかを判断する
- 人間組織の適切な変化は合意のプロセスから生じるし、合意を形成するには時間も集中力も必要 6518
- 組織パターンはインスピレーションをもたらすのに使うべきで、そのまま適用するべきではない 6586 ※
- パターンから現在の組織の問題の発見の手がかりとし、解決の緒を考える切っ掛けとする
- 優れた組織は、プロセスだけに注目しない。プロセスは構造から現れ、構造は価値観から現れるため 6777 ※
- 組織学習にはシングルループ、ダブルループ、トリプルループがある 6777
- シングルループはよくあるふりかえりで、Howを変化させる
- ダブルループは組織における洞察を刷新する
- トリプルループは、我々はどんなビジネスをやりたいのか？我々にとって価値と原則は何か？に答える手助けをする学習
- シングルループは1日、ダブルループは1ヶ月、トリプルループは1年以上と、かかる時間が違うことに注意
- 偉大な組織はトリプルループを適切に行なっている
- 全ての組織パターンの要約 7749 ※
