スクラム実践者が知るべき97のこと

31稼働率管理の弊害

ダニエル・ハイネンコンスタンチン・リベル

プロダクト開発の進捗が思わしくないために、外部ベンダーからチームを追加した組織をいくつか見てきた。それがどんなひどい弊害をもたらしたかを書いてみようと思う。

ベンダーのチームは、プロダクト全体やそれがどう開発されているのかを理解する必要がある。経験豊富なチームからどれだけ手助けが必要か、どれくらい学習に時間がかかるのかは、プロダクトの複雑さ次第だ。

結果として、ブルックスの法則†1のとおりになる。

[†1] 『人月の神話』（滝沢徹 他訳、丸善出版、原著『The Mythical Man-Month』Frederick Brooks、Addison-Wesley、1995）

遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである

フィーチャーのアウトプットは減り、マネジメントの懸念はさらに大きくなる。手を打たなければいけない。いちばんわかりやすいのは、人をさらに追加することだ。社員を採用するよりも、外部スタッフを増やす（そしてあとになって減らす）ほうが簡単なので、（外部）ベンダーのチームを使う割合が急激に上がっていく。

プロダクト開発グループが大きくなるにつれて、システムに対するチーム間の理解の差も大きくなっていく。だが、全体として、チームと個人の稼働率を最大にすることが期待されている。その結果、スクラムで期待されるような顧客価値のための組織化ではなく、チームの現在の能力に合わせた仕事の細分化につながる。チーム間で仕事を分担するときの柔軟性は減り、専門性の高いチームの作業負荷が増える。仕事はさらに分断されて、プロダクト開発グループの適応力は落ちる。チームは自分たちの作業領域に特化することになり、コンポーネントチーム（ ...