fkm_y' log

技術や日常のログ

「組織パターン」を読んだ

読書

組織パターン

組織パターン

Amazon

組織やチームの勉強のために「組織パターン」を読んだ。

対象となる読者はマネジメント層だけでなく開発者も含まれていました。また対象となるフェーズは運用フェーズではなく、プロダクトの新規開発を少人数で進めるときもしくは組織を拡大するフェーズに読むと活用できそうな内容でした。

また組織やチームの抽象的な問題がパターンとして言語化されているので、見えていない問題の認知や、認知しているけど対応できていない課題に対する改善策、なんとなくやってるこれはパターンだったんだという発見などの気づきを得るきっかけになりそうな本でした。

読み始めた時は理解しにくいと感じたが読み進めると徐々に全容が見えてきた。パターンの読み方について読み始めは理解が足りていなかったのが原因だったのでパターンの読み方についてメモしておく。

パターンの読み方

全体としては数々のパターンの紹介のあとにケーススタディが紹介される構成となっており、各パターンは以下のような構成で書かれていた。

  • パターンの名前と重要度
    • 重要度は*の数で表されていて0~2まである。
  • …の後に、コンテキスト
  • * * *の後に、問題を定義するフォース
  • それゆえ：の後に、解決策
  • * * *の後に、そのパターンがうまくいく根拠

4つのパターン言語

各パターン言語内のパターンをどの順番で適用していけば良いか、書籍内の表では表されている。

  • プロジェクトマネジメントのためのパターン言語
    • 組織のプロジェクトをマネジメントする
  • 組織の漸進的成長のためのパターン言語
    • 組織が時間をかけて成長し発達する方法
  • 組織スタイルのためのパターン言語
    • 組織が機能する方法に対する一般的アプローチ
  • 人とコードのためのパターン言語
    • 人間がどのようにコードに影響を及ぼすか、またコードの設計が人間にどのような影響を及ぼすか

印象に残った内容

  • 「4.1.9 細かいリスケをしない」
    • リスケは細かくするのではなく一度だけ大きく行う。細かいリスケを常に行っているとスケジュールの信憑性が下がり、切迫感が失われチームの士気も下がる。
    • 【感想】こういうプロジェクトに参加したことがあるがリスケのコストも高まり、スケジュールに関するチームの遵守意識も下がっていくので良いことがない。
  • 「4.1.22 誰か一人を犠牲にする」
    • 余計な作業にが細かく積み重なると、集中する時間を邪魔され、チームの力を蝕む。
    • 誰か一人を余計な作業に割り当てる。
    • 【感想】具体的には問い合わせ対応やバグ対応が思い浮かぶ。障害対応時は判断が難しいところだけど、同様に全員を張り付かせないようにしてプロジェクトが進んでる状況を作る必要があると思う。「常に誰かが進捗させる」や「託児所」「徒弟制度」などのパターンが関連する。
  • 「4.1.23 託児所」
    • 職人たちが新人を鍛えるのにすべての時間を費やさないように職人を一人、新人全員の教育に割当、その他の人たちでシステムを開発する。
    • 【感想】オンボーディング担当を割り振ることをよくするのでそれと同じと思う。過去に複数人のオンボーディングを担当したが結構たいへんだったので、これをする場合は専任化や小さなタスクのみを割り振るなどの工夫が必要に感じる。
  • 「4.2.4 徒弟制度」
    • 新しく雇った人を職人の元で育て上げる。
    • 【感想】メンター制度と同じ、託児所のパターンと組合わると職人の負担が減って良い。
  • 「4.2.7 顧客の代理」
    • 顧客と一緒に考えを出し合ったり課題を明確化するのは重要だが顧客に会えないかもしれない。そのためプロジェクト内に顧客の代理ロールを作り、顧客のように考えようとする人を設け、システムの機能的な要件をユースケースとして表現する。
    • 【感想】今でいうPdM（プロダクトマネージャー）がこのロールに近いと思われる。
  • 「4.2.12 目的の統一」
    • プロジェクトの立ち上げ期に数々の障害に突き当たり、人々が協力して仕事をしようとすると苦労するため、チーム全員に共通のビジョンと目的を教え込む。
      • 様々な目的に向けて作業せず、協力して作業するようになる。またチームの士気にも影響を与える。
    • 【感想】PJを始める際に重要視する好きなパターン。目的が統一されていないと一体感が生まれるかを、個人のスキルや運の要素に任せてしまうことになると思う。またチーム内での議論が発散されがちになると思われる。
  • 「4.2.24 トラックナンバーはほどほどに」
    • プロジェクトが少数の個人に依存しすぎないようにする必要がある。そのために属人性を下げるために知識を共有する文化を構築し、知識が広がるようにする。
    • ただし、専門知識を冗長化することは費用面や時間面で非効率にコストを払いすぎるため属人性の完全排除もよくない。別の手段でリスクを減らすほうが良い。
    • 【感想】属人性を排除することが目的になってしまわないように注意する必要がある。よくある手段の目的化に囚われないように。
  • 「6.2 漸進的成長」
    • パターンをすべて一度に適用しようとせず、最初に手をつけるパターンを選んで一度に１つづつ適用していく。
    • 【感想】組織は予測が難しい人間の集まりであり、劇的に変わることは期待しないほうが良い。継続的にフェーズに応じた手を打っていくしかないと思う。