アジャイルプロジェクトにおけるリソースマネジメント

作者 Vikas Hazrati , 翻訳者 笹井 崇司 投稿日 2009年6月29日

セクション

プロセス/プラクティス

トピック

Agile ,

Agileの採用 ,

Agile in the Enterprise

タグ

Best Practices

原文(投稿日：2009/6/23)へのリンク

アジャイルプロジェクトは急激な変化という問題を解決するものとして知られている。これらは市場要因やシステム要件、実装技術における変化かもしれない。こうした変化の1つに、プロジェクトに取り組む人員の頻繁な変化があるが、これはアジャイルプロジェクトとは相性がわるい。アジャイルを採用している組織において、組織が人をプロジェクトに割り当てようとしたときに、よく見られる課題だ。Roland Ceullar氏は、効果的なリソースマネジメントのやり方をいくつか解説している。

Roland氏はこう言っている。

時々、アジャイルを採用している企業で、「リソースマネジメント」のやり方について興味深い質問を受けます。「たくさんのプロジェクトが進行しているとき、1人を1つのチームにずっと100％割り当てるにはどうすればよいのでしょうか？」と言うのです。

Roland氏は、この質問には2つの根本的な問題があると述べている。

1. 人を動かしてプロジェクトに配置する必要があるという前提
2. 同時に実行しているプロジェクトの数

人を自由に動かせる部品として考えることはできないのです、と彼は言う。人がチームで仕事をしているときには、フォーミング（形成）、ストーミング（混乱）、ノーミング（統一）、パフォーミング（機能）という成熟度サイクルを経験する。これには時間が必要だ。いったんチームがうまく機能すると、成果を上げているチームを乱すのは通常よくないことである。成果を上げているチームは、できるだけ手をつけず、そのままにしておくべきだ。したがって、人をプロジェクトに割り当てるのではなく、チームの能力とスキルに基づいて、プロジェクトを成果を上げているチームに割り当てるのが望ましい。しかしながら、特殊なスキルのためにプロジェクトを横断する必要のある専門家には、これは当てはまらないだろう。

これに関連して、Joe Ocampo氏が浮き彫りにした問題に、人のマトリックス型割り当てがある。これは1人の時間をプロジェクトを横断して配分することだ。一例としては次のようなものだ。

開発者 UberBob の時間配分

• プロジェクト A に 25%
• プロジェクト B に 65%
• プロジェクト C に 10%

Joe氏によると、大規模なRUPベースのプロジェクトでこうしたマトリックスモデルで仕事をしているのを見たそうだ。しかし、これはアジャイルプロジェクトではうまくいかない。アジャイルプロジェクトでこれをやると、チームダイナミクスやコミュニケーションが乱れ、ベロシティも乱れてしまう。

リソースを特定のプロジェクトに固定して、それに完全に専念させることによって、その活動の推進力と予測可能性が得られるのです。マトリックスモデルはコミュニケーションの連続性を乱し、イテレーションベロシティを乱します。プロジェクトからプロジェクトへ、毎週リソースをうまく組み合わせようとすると、これまで記録してきたベロシティはすべて無駄になり、チームダイナミクスは乱れてしまうでしょう。単純に1対1で人員を入れ替えると、混乱なしでアウトプットを期待することはできないのです。

組織にある数多くのプロジェクトを管理するために、Roland氏はスローダウンアプローチを提案した。Roland氏によると、1つのチームに同時に複数のプロジェクトをやらせるのではなく、チームごとにプロジェクトの待ち行列を作るとよいそうだ。市場とビジネスのダイナミクスを考えると、これは実現困難かもしれないが、プロジェクトをうまく優先順位づけして、集中するのに役に立つ。こうすることで、チームは厳選されたプロジェクトにおいて、スループットと納品を実現できるだろう。複数のプロジェクトに取り組んで、どれにも集中できないということはない。

ここにある暗黙のメッセージは、人に注目するということだ。アジャイルプロジェクトは、人を最善の方法で活用したときに有益なものとなる。それゆえ、人をプロジェクト横断で管理するのではなく、プロジェクトをチームで管理するのが得策だ。

• 次へ >