 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| リソースヒストグラム
|
組織計画プロセスでは、「必要要員の予測」により「配員計画書」を作成する作業も重要です。通常、この作業は第4回に説明したコスト管理の作業と一緒に行います。コスト見積プロセスの中で開発対象の機能を洗い出し、必要な開発工数を見積りました。その必要工数を要員単位に展開し、役割分担と投入時期まで考慮したものが「リソースヒストグラム」です。
図2は、PYRAMIDの「リソースヒストグラム」のテンプレートです。これは、俗に"山積みチャート"とも言われているもので、どういう要員が何時から何時まで参加し、メンバーはピークで何人になるかなどを表したものです。縦に要員を並べ、どの工程からプロジェクトに参加するかを表します。他のプロジェクトと兼務して参加する場合もあるので、プロジェクト参加度合いは小数での入力も可能としており、50%の参加なら0.5と記入します。月の半ばからプロジェクトに参加する場合もあるので、ここでは10日を横軸の単位として管理する書式にしています。
|
図2：「リソースヒストグラム」のテンプレート
（画像をクリックするとEXCELファイルをダウンロードできます。/29KB）
|
この例では、トータルで55.8人月かかることになっていますが、この総工数はもちろん見積コストと整合性を持っていなければなりません。リソースヒストグラムを作成することは、要員計画という本来の目的だけでなく、見積の妥当性チェックにもなります。ある規模以上のプロジェクトでは必ず作成するようにしてください。
|
 「プロジェクトの規模に反比例する成功率」
一般に大きなシステム開発プロジェクトを受注した方が、小さなプロジェクトを数多くやるよりも経営効率がいいように思われます。どんなプロジェクトでも、プロジェクトリーダーを立ててそれなりの管理を行う必要があるので、どうせやるなら大きい方が稼ぎになると思われるからです。しかし、実際はそう簡単には行きません。ある程度のプロジェクトの規模になると、プロジェクトの成功率が急に低くなり、下手をすると大赤字になってしまうのです。
|
面白いのは、プロジェクトが失敗しやすくなる金額が会社により異なるという点です。A社は1000万円を越えると急に失敗プロジェクトが多くなるのに対し、B社はその境が8000万円という具合です（図3）。これは決して技術力や独創的発想などの力量の差ではありません。このような差が生まれるのが"プロジェクト管理力"の優劣なのです。
連載第1回目に「日本の武器とすべきはプロジェクト管理力だ」とお話したポイントも、そこにあります。技術力偏重の姿勢を改め、"プロジェクト管理力"＝「企業力」 という意識をより強くもって、本連載を役立てて頂けたらと思います。
|
図3：プロジェクト規模と成功率の関係
|
|
|
| 要員の調達／確保
|
要員の調達／確保は、俗人的な要素が強いプロセスです。社内および社外からプロジェクト遂行に必要な人材をタイムリーに集めるためには、常日頃から社内外のパイプ育成努力を怠っていてはできません。優秀なPMは、必ずなんらかのツテを持っているものです。
プロジェクトがスタートしてから「要員がいない」とただわめいているのは、典型的な泥縄PMだと言えます。しかし、そういうプロジェクトマネージャの個人的能力に依存するだけでは、企業力アップにはなりません。もう少し組織管理として制度や仕組みを考えてみましょう。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
