この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-25です。 adventar.org
day-25は「組織パターン」です。
25！！！やっと！長かったです・・・
どんな本
原題は「Organizational Patterns of Agile Software Development」です。冒頭の記述を見ると、「組織としての学びや、病と癒やし、成長の為のパターン」というところになるでしょうか。
こうした「成長」や「癒やし」というのがアジャイルの性質と深く関わるということで、Agileの名を関して・・・という面もありつつ”「アジャイル」という単語をタイトルに選んだのは、本が売れるようにとの思いからだった。"と述べていますw
一方で、実際に「アジャイルソフトウェア開発にも影響を与えた」とも述べており、ジェフ・サザーランドやケン・シュェイバーといったスクラムの人たち、また「ペアで開発する」のパターンはXPのプラクティスに取り込まれたり、といった事柄が紹介されています。
(そういった影響の度合いを見て、「ひとりでアジャイル」のAdvent Calendarに含めたのです。)
組織パターンが生まれるにあたっての背景を説明したり本書の全貌を解説する「歴史と導入」、パターンランゲージ(カタログ)、より広い視野で組織構造そのものに備わる原則についての「基礎と歴史」、最後に「ケーススタディ」という4部構成になっています。
本書で挙げられているパターンの様子については、オブラブのサイトでコンパクトにまとめられているので雰囲気を掴めるかも知れません。
リンクしておきます。
お気に入りポイントかいつまみ
抽象的で難解だが「なるほど」も(かなり)多い
本書はボリュームもそこそこありつつ、「組織」とか「コミュニケーション」「計画」といった抽象的なテーマを扱っています。
その上、「パターンで記述する」というのは、馴染みの薄い人にとっては取っ付きさもあるのではないでしょうか。
そのために、読みながら「自分はちゃんと理解できているのだろうか・・・」とモヤモヤとする場面も少なくなかったです。
まして、自分に経験の少ないところには想像力も働きにくく、例えば「受託開発」「何十人も開発者がいる組織」「厳密にウォーターフォール方式でを用いた開発」「アナリストやテスターと言った役割と責務の分担」などなど、自分は身を持って経験をしたことがありません。そのため、それがすべてのパターンを読解する時に関係するものではないのですが、扱っている前提がピンとこない・・・というハードルがあります。
ただし、目指しているものは共感できていると感じます。
「ちゃんと働きやすい組織を作って、プロジェクトがいい感じに進むようにしようぜ！」という。そのために「厄介な課題」を特定して「こういう時どうしよう」を記述したパターン集であり、「それをクリアしたら次に・・・」とか「そこまでいったらコレもできるはず」といった、パターン同士の連なりが描かれている本です。
ということで、自分としては「変にハードルを上げすぎないで気楽に読む、それだけでも十分に学ぶものが多い！」と肩の力を抜きながら読んでいました。
(往々にして、歴史の淘汰を超えて生き残っている本は、「然るべき時に自分が読んだら嘘みたいに分かりやすい」という性質を持つものが多いので。)
とりわけ、スクラムやXPに触れたことのある人は、その「元ネタ*1
例えば
- 「¶ 4.1.3 ぐずぐずするな」と「¶4.1.7 プロトタイプを構築せよ」は、「出荷可能なインクリメント」の精神性に見て取れたり、
- 「¶4.1.13 ワークキュー(を優先度付けされた作業の一覧を作り、それをスケジュールとして扱う)」はバックログの管理を思い浮かべたり、
- 「¶4.2.7 顧客の代理」は、そのままXPの「オンサイト顧客」→ スクラムの「プロダクトオーナー」に通ずるものを感じますし、
- 「¶4.2.8 シナリオが問題を定義する」はユーザーストーリーを
- 「¶ 4.2.12 目的の統一」は、インセプションデッキの「我々はなぜここにいるのか」を想起します。
- 「¶ 4.2.19 全体論的多様性」は、クロスファンクショナルチームという概念に繋がっていきますし、
- 「¶ 5.1.2 ロールは少なく」は、まんまスクラムチームの「プロダクトオーナーと開発者しかいない」に繋がっていくと思ったり、
- 「¶ 5.2.7 スタンドアップ・ミーティング」は概念も名称もそのまま採用されることが多いプラクティスになっています
といったように、既に定式化されていてよく見知ったパターンやプラクティスとの関連性が浮かぶものが豊富に存在しています。
それ以外にも、
- ¶4.1.2 スケジュールを小分けにする
- ¶4.1.9 細かいリスケをしない
- ¶4.2.16 多様な集団
- ¶4.2.24 トラックナンバーはほどほどに
- ¶ 5.2.8 ドメインの粒度に合わせて人員を配置せよ
など、パターン名から「言わんとしていることが何となく分かる」のと課題への共感もしやすそうなものもあり散見されます。
こうした、実感の湧きやすいパターンが多く含まれており、ただ壮大な「組織パターン」というハードルにビビりながら読むよりも、1つ1つ見ていったら結構馴染みやすい印象になるのではないか〜という気がしました。
自身の環境における問題にどう適用するか？
パターンランゲージ(カタログ)の強みの1つは、「自分が何となく感じていたモヤモヤについても、コンテキスト・課題を言語化して、その対処法と注意事項も示してくれる」という点です。
この本においても、読みながら「あ、最近気になっているああいうの、もしかしたらこの観点で捉えてこういう風にしたら改善できるのかも」と感じているものが多々ありました。あるいは、自然と出来ていることに対して、しっかりと名前がついてパターン＝形式として認識できるようになったり、など。
個人的には、
- ¶4.1.14 非公式の労働計画
- ¶4.1.17 開発者がプロセスをコントロールする
- ¶4.1.18 作業が内側に流れる
- ¶4.1.22 誰か一人を犠牲にする
- ¶4.1.28 手を止めて始めた作業を中断するな
- ¶4.2.9 防火壁
- ¶5.1.4 中央の生産者
- ¶5.1.12 循環領域を作る
- ¶5.2.15 インターフェイスの背後のバリエーション*2
- ¶5.2.17 緩やかなインターフェイス
辺りについて、特に気に入ったり意識したいなと感じたりしました。
わかっているものや、分かってはいるけど意識しないと中々そうならないものや、全く出来ていないな・・・と感じるようなものが含まれます。ただ、組織パターンに導かれて「組織を今より強くする」という気持ちを持つと、非常にヒントになることが多いです。
まとめ
Team Topologiesでも「いかに組織構造を扱って問題を解決するか」「コミュニケーションパスをどう設計するか」という話題が論じられていましたが、組織パターンも非常に広い観点から「組織」を描いています。
少なくとも言えるのは、「引き出しを増やす」ことができる1冊です。 目の前で発生しているコンテキストとそこに起因する課題の見抜き方、そこにどう対処するか・・・という引き出しが増えます。すなわち、識別できる・検知出来る問題のレパートリーが増え、それに対応するための解法も増えるということになります。
先述の通り、いきなりすべてを理解する・・・というのは困難かと思いますが、「気楽にパラパラとページをめくってみる」「何か困ったときやうまく行かない時にまた手にとって、ピンときそうなところだけ読み直してみる」くらいのカジュアルさが大事に思いました。
