
日付:2005/07/14
====================================================
CCプロジェクト管理講座(17)
リソースはどうやって定義する
====================================================
こんにちは西原です。CCプロジェクト管理講座第17回を始め
ましょう。疑問点や質問ご意見あれば弊社メーリングリストや私
宛に質問下さい。
先週は、プロジェクトの完成イメージの定義(ODSC)、ネットワ
ークの構築について書きました。このフェーズで、プロジェクト
のゴール達成に最低限必要なタスクが洗い出され前後関係が定義
されます。
このフェーズでのポイントはゴールからロールバックでタスクを
洗い出すという点です是非一度やってみてください。
さて、次ぎにおこなうのはリソースの定義です。
クリティカルチェーン法では、一人の人が同時に2つ以上の作業
を掛け持ちで行う「マルチタスク」は禁止されています。また、
プロジェクトの期間を決めるもっとも長い経路を探すとき、リソ
ースの依存関係を山崩しした後に計算をおこなわなければなりま
せん。このリソースを山崩しおこなったネットワークの中でもっ
とも長い経路になっているものをクリティカルチェーンとよびま
す。
リソースの定義のフェーズの手順は以下のようになります。
1,各タスクに必要な能力を定義してリソース要件を決める。
2,企業全体の保有するリソースをリソースプールとよばれる一
覧にまとめて確認する
ここでの分類は「プログラマー」「シニアプログラマー」といっ
た職種別での分類になり職種ごとに保有する人数を確認しておき
ます。
3、タスクごとにリソースプールで定義した職種をアサインして
いきます。誤解のない名前にしておくことが重要です。
4,タスクに必要な重要なリソースは特に重点的に定義します。
5,リソース管理者にネットワークをレビューしてもらう
ここで重要なのは、まだこの段階では個人名レベルのリソースを
アサインしない事です。企業によって異なりますが、プロジェク
ト計画前に個人名レベルでリソースが決めていまっている事があ
ります。しかしこれでは組織の保有する能力を最大限いかしてプ
ロジェクトのゴールを達成できる保証はなくなってしまいます。
クリティカルチェーン法では、プロジェクトに人をアサインする
のではなく、タスクに人をアサインします。つまり計画段階では
タスクに人をアサインせず、進捗段階に入ってからアサインして
いき進捗度合い等にあわせて能力の高い人をアサインしたりする
などプロジェクトに柔軟性を持たせて運営していきます。
このようなやり方を取っていない企業でクリティカルチェーン法
を実施する場合、マネジメントレベルの方針を変える必要性がで
てきます。プロジェクトマネージャーが人をアサインする権限を
もっているならばそれが果たして企業の保有する能力を最大限い
かす事になるのかマネジメントレベルで考える必要があります。
私は様々な企業にいっていますが、この件は企業・業界によって
様々なやり方をしています。例えば建設業界では、過去プロジェ
クトマネージャーにリソースをアサインする権限を与えられてい
た事が多かったのですが、こうしていると企業ではなくプロジェ
クトマネージャーごとに協力会社が階層構造になるような歪な組
織構造が出来上がり、協力会社とプロジェクトマネージャーの癒
着による不正行為などの原因になってしまっていました。よって
現在では一般的にはプロジェクトマネージャーがリソースをアサ
インする権限を持たず、企業全体をみながら協力会社をアサイン
する権限をもった人を置いているのが一般的になっています。(
工事部長等)
あるソフトウェアー開発企業では、プロジェクトマネージャーに
ほとんどの権限を与えていました。進捗が遅れたときに
協力会社にムリをしてもらい追加の作業をお願いしないといけな
い場合がありますが、この時に予算をみると追加で支払うことが
できない事があります。そうなるとトラブルになるわけですが「
次回のプロジェクトで借りを返すのでお願い」といった貸し借り
をやって解決するという事が多発します。こんな事を繰り返して
いてプロジェクト成功のためのリソース選択といった事は出来ま
せん。なぜこんな協力会社が???といった事が起こりますし、
プロジェクトマネージャーにあまりに責任と権限を集中させられ
ると精神的に参ってしまうマネージャーもでてきてしまいます。
このようにリソースのアサインのやり方は様々な問題を引き起こ
す重要な問題です。マネジメントレベルの問題であり非常に重要
な方針です。自社のやり方が今のままで良いのか是非一度議論し
てみて下さい。
CCプロジェクト管理講座
[2005/10/26]
30.「最終号」TOC/CCPMから組織の変革へ
[2005/10/19]
29.プロジェクト・マネジメント・オフィス
[2005/10/15]
28.複数のプロジェクトを如何にマネジメントするか
[2005/10/15]
27.リレー走者の原理とチームプレイ
[2005/10/15]
26.進捗管理の方法「ファシリテーション3
[2005/09/23]
25.進捗管理の方法「ファシリテーション2」
[2005/09/23]
24.進捗管理の方法「ファシリテーション」
[2005/09/08]
進捗管理の方法「バッファマネジメント」
[2005/09/08]
進捗管理の方法「どうやって遅れを管理するか?」
[2005/09/08]
クリティカルチェーン・スケジューリング(2)
[2005/08/08]
21,クリティカルチェーン・スケジューリング
[2005/08/08]
遅れること前提の時間見積もり(2)
[2005/07/25]
18.遅れること前提の時間見積もり
[2005/07/14]
17.リソースはどうやって定義する
[2005/07/06]
16.ODSCからネットワークを構築
[2005/07/06]
15.完成のイメージから逆算して計画を作る
[2005/06/26]
14. プロジェクト管理の中核問題
[2005/06/15]
13. プロジェクトマネージャーの方針制約
[2005/06/13]
12. プロジェクトのリードタイムのほとんどは待ち時間
[2005/06/05]
11.完璧な計画の作成方法
[2005/05/23]
10.計画するとは
[2005/05/23]
9.プロジェクトに関わる『人』の現実
[2005/05/11]
8早く始めれば早く終わる・・・・ことはない。
[2005/04/20]
7.なるべく早くが地獄への道・・・
[2005/04/20]
6,プロジェクトマネジメントの目的は何か?
[2005/04/20]
5,プロジェクトマネジメントソフトウェアー(PMソフト)
[2005/04/20]
4,クリティカルパスは早く家に帰る道??
[2005/04/20]
3,最小自由度の原則 (こまねずみはダメ???)
[2005/04/20]
2,従来型プロジェクトマネジメントの実践
[2005/04/20]
1.まずはプロジェクトとは何か考えてみよう「恐ろしい話・・」
TOCはどうなるのかin2005
[2005/04/20]
導入が進むが失敗例も増える!?TOCクリティカルチェーンの2005年