 |
|
|
| 前のページ 1 2 3 次のページ
|
|
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
|
|
| 外部調達のコツ
|
外部調達をうまくやるためのコツは、できるだけ早い段階から手を打つことです。例えばプログラミング以降の下流工程を外注するとしても、直前の詳細設計工程が完了した時点で、プログラマ集めようとしても優秀な技術者は集められません。第6回「組織管理」において、PYRAMIDの「リソースヒストグラム」を説明しました。リソースヒストグラムを作成すれば、いつ頃どういうレベル（SEかPGかなど）の人を、何人ぐらい外部調達しなければならないかがはっきりします。プロジェクトの計画段階でリソースヒストグラムを作成し、早めに外部と交渉すればそれだけ優秀な人を集めやすくなります。
一般に発注側は、発注先の事情には無頓着なケースが多く、依頼すればすぐに優秀な人を出してもらえると思いがちです。しかし、発注先もいろいろな仕事に自社技術者をアサインしているので、来月からと言われてすぐに必要な人数を集められるものではありません。ましてや優秀な人ほど抜きにくいので、すぐに出してもらえるようなメンバーでは、技術レベルに不安が付きまといます。
もちろん、参入時期と必要人数がはっきりしないという事情から、ぎりぎりの段階になってから引合を出すこともあるでしょう。「9月からJavaのできる人を5名」とお願いしておきながら、設計が遅れて11月にずれ込んでしまう場合もあるからです。それでも、時期がぶれる恐れがあるという前提で、事前に打診しておくことは大切です。発注先は、それをプロスペクトとして管理し、スタッフのやり繰りをしてくれるはずです。
場合によっては、プロジェクトがスタートしてからでは遅いくらいで、プロジェクトが発足する前から、「こういう案件があるけれど」と打診する必要があります。さらに、目先のプロジェクトがない段階でも、協力会社の開拓やパイプ維持とった努力をしなければなりません。プロジェクトの成功率が高い企業は、そのような体制がきちんとできているものです。
|
| RFPなどで内容をきちんと伝える
|
調達管理の計画プロセスは、ユーザー企業とシステムインテグレータの立場、もっと正確に言えば請負ベースか派遣ベースかによって少し内容が変わります。請負ベースの場合は、目的や要件をまとめた提案依頼書（RFP：Request For Proposal）を作成し、複数の引合先に提示してプレゼンテーションを行ってもらうのが正規の手続きと言えます。RFPを作成する段階で引合先の候補を選ぶのですが、開発リソース（人）だけでなく、目的達成のためのノウハウや技術力などの提供も期待します。引合先が決まっていて、ベンダー選択プロセスが不要だったとしても、RFPもしくは「発注仕様書」をきちんと作成して、プロジェクトの要件や目的をきちんと伝えておくことは重要です（P1）。
一方、派遣ベースの場合はRFPを作りません。必要なスキルを伝えて、相手から「職務経歴書」などを提出してもらい、必要に応じて面接を行ってから決定することになります。この場合に大切なことは、いかに優秀な人を出してもらえるかということです。もちろん、単金の高さや仕事のボリューム、作業内容も重要ですが、日頃からの相互信頼がポイントとなるケースが多いと思います。メンバーに参加してからは社内スタッフと同様の扱いとなり、通常のプロジェクト管理が適用されることになります。
PMBOKの調達計画のアウトプットは「調達マネジメント計画書」と「役務記述書」、引合計画プロセスのアウトプットは「調達書類」と「プロポーザル評価基準」です。主に請負ベースで仕事を依頼する場合を想定して、管理項目がまとめられています。調達書類の代表はRFPとなります。RFPの内容はプロジェクトにより異なりますが、基本的な項目は標準化できますので、できればきちんとしたRFPのテンプレートを作成しておきましょう。
|
| 協力会社のプロジェクト管理を管理する
|
「引合」「発注先選定」「契約管理」という3つの実行プロセスと「契約完了」の終了プロセスから構成されているように、PMBOKの調達管理は引合から契約までを管理対象としています。つまり、契約した後の委託先の進捗管理や品質管理、コミュニケーション管理などは調達管理ではなく、それぞれの管理エリアの範疇に含めていると思われます。確かに欧米的なドライな考え方なら、契約したからには納期や品質は相手側の管理問題であり、それをこちら側で管理する必要はないということになるでしょう。しかし、実際のプロジェクトでは委託先の進捗管理や品質管理をどうするかという問題は重要で、丸投げでまかせていると大きな痛手を被る場合があります。
ユーザーに対する責任はこちらにあるので、協力会社におけるプロジェクト管理についてもチェックしましょう。スタート時点でどのようなプロジェクト管理を行っているかを確認させていただき、不足と思われる点は遠慮なく注文を付けて協議します（P2）。
また、週一回は進捗報告を行ったり、できた部分だけ先行納品させてテストをしたり、体制図を提出してもらったりして、協力会社の状況をきちんと管理することが大切です（P3）。プロジェクト管理の原則は現場・現物ですので、進捗報告を鵜呑みにせずに、時にはこちらから出向いて現場を見たりして、現物を見せてもらうなどのチェックも必要です（P5）。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
