コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想part2
和智さん翻訳・コプリエン著のアジャイルソフトウェア開発の「組織パターン」を読んでいると、気づくことが多い。
ラフなメモ書き。
【参考】
生成的開発プロセス・パターンランゲージ
コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想: プログラマの思索
【1】コプリエンは、モデルとして安定しないプロセスよりも、モデルとして安定しているロールに着目して、組織パターンを書いた。
何故、ロールに着目したのか?
7.3節「ロールとコミュニケーション」で、組織におけるロールの重要性について述べている。
【1-1】組織の中で何が行われているか、をロールが定義する
組織の中のプロセスは誰かが担当していて、それはロールによって抽象化されて定義される。
担当する作業を組織内の誰にでも実施できるように、アサインできるようにするならば、ロールの定義が作業内容になる。
【1-2】人はロールによってアイデンティティを得て行動できる
開発者、テスター、プロジェクトマネージャなどのロールを与えられて、初めて、その組織内でそのロールを使って振る舞える。
人にふさわしいロールを与えることで、生き生きと見違えるように、能力を伸ばす人もいる。
僕の経験では、若手にはロールを意識的に付与させると、仕事していくうちにそのロールに必要な能力を身につける。
特に、管理職や経営層のように、組織内で権力が大きくなるほど、ロールの影響力は大きくなる。
ロールを付与されることで、ノブレス・オブリージュのように、その社会的地位にふさわしい能力を自然に身に付けるパターンが多いと思う。
それらロールは、プロジェクトや組織を離れても、その人について回る時がある。
その人の能力や性格に見合ったロールはある。
プロセスよりもロールの方が安定している。
【1-3】組織の情報はロールの間を流れる
コミュニケーションは、ロールの間を流れる。
情報の流れは組織の成功・失敗の起因の一つ。
コプリエンによると、調査した組織では、あるロールが存在すること、あるいは、存在しないことに気づいたと言う。
ロールが足りない組織は、そのロールを組織が必要としていないことを意味しているわけだ。
例えば、組織の中で、顧客をロールに組み込んでいない場合、その組織は顧客の問題に対してどれくらい認識しているか、疑問に思える。
これは、顧客の代理人パターンを指すのだろう。
あるいは、アーキテクトというロールがない組織がある。その組織は、ソフトウェアアーキテクチャを軽視している組織なのだろう。
これは、アーキテクトが製品を統制する、アーキテクトもまた実装する、アーキテクチャチームのパターンに相当するだろう。
【1-4】ロールを取り巻くコミュニケーションパスも重要
開発者ロールを中心に組織のコミュニケーションが回っていることが大事。
もし、マネージャのロールを中心に結びついていたら、その組織はマネージャが管理者として干渉しすぎていることを示唆している。
品質管理者のロールが他のロールと結びついていなかったら、きちんとしたシステムテストが行われていないだろう。
その場合、開発組織がシステムテストに価値を見出していない可能性がある。
そうだとすれば、かなりの問題だ。
【2】組織パターンのほとんどは、ロールの性質を説明している。
防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)、パトロン、アーキテクト、品質管理者というロールがない組織があったとしたら、そのロールに付随するパターンの効果が実現されていないことになる。
つまり、そのロールが果たすべき作業を、開発組織は軽視しているか、その作業の工程そのものの品質が悪いことを意味しているのだろう。
個人的には、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というパターン名は、ネットワーク機器を連想させる。
それらのパターンの意味は、まさにネットワーク機器の特徴と同じ。
ファイアウォールは、外部からの不要なアクセスを防ぐ。
防火壁(FireWall)は、ニワトリとブタというScrumの格言の通り、スクラムチーム外の利害関係者からの割り込みや干渉を防ぐ。
ゲートウェイは、通信媒体やプロトコルが異なるデータ(情報)を相互に変換して通信する。
門番(Gateway)は、スクラムチーム外の利害関係者と、適切なプロトコル(外部インターフェイス)を通して、対話できるパイプラインを作る。
門番(Gateway)は、プロジェクトの情報やシステムに関係する用語を、利害関係者とチームの間で翻訳する。
プロキシサーバーは、ネットワークに出入りするアクセスを一元管理し、内部から特定の種類の接続のみを許可したり、外部からの不正なアクセスを遮断する。
顧客の代理(Proxy)は、チームが顧客と頻繁に会えない場合、プロジェクト内に顧客の代理人というロールを作り、課題を明確化したり、解決策のアイデアを出し合う。
このように、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というロールは、コミュニケーションを遮断したり、促進するために用いられる。
それらロールがあるからこそ、開発者は自分たちの仕事に集中できる。
そうでなければ、外部からの利害関係者やマネージャが常に開発者へ干渉して、開発の生産性や製品の品質に悪い影響をもたらしているだろう。
他にも気づいた点があれば書いてみる。
【追記】
コプリエンさんのつぶやきを見つけた。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
「パターン言語」カテゴリの記事
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- 「ハリウッドリライティングバイブル」のマインドマップ(2022.01.23)
コメント