KATOエンジニヤリング開発日誌

「アウトプット無きエンジニアにインプットもチャンスも無い」の精神で書いています

受注プロジェクトの管理を学ぶ - プロジェクト計画 -

前回に引き続き、履修証明プログラムの「受注プロジェクトの管理」の内容をまとめます。

www.kato-eng.info

前回はプロジェクトを受注するまでの流れでしたが、今回はプロジェクト計画を確定させるまでです。

プロジェクト計画

発注者と受注者の間で契約が締結され、プロジェクトが正式に立ち上がった後はプロジェクトの計画を確定させる。
これまでの提案活動や受注活動で大部分の計画が作成されているので、この段階では作成されたプロジェクト計画を見直し、より実現可能なプロジェクト計画書を作成することになる。

提案書や契約書の確認

RFP、提案書、SOW、契約書、社内で作成したプロジェクト憲章等の記述をもとに、顧客の意向を確認しプロジェクト計画を作成する方針を決める。
場合によっては顧客が持っているプロジェクト資料や制約条件、前提条件などを提示してもらう。

ステークホルダーの特定と分析

f:id:masayuki_kato:20171011171103j:plain

提案段階ではプロジェクトを獲得するために関連するステークホルダーを分析し対応計画を立案した。プロジェクト計画を作成する段階では、プロジェクト実行に関連するステークホルダーを特定し、分析・対応計画を考える。

ステークホルダーの分析は、プロジェクト推進の賛成者なのか、反対者、または中立的立場なのかを見極めるところから始まる。また、プロジェクトに対する影響力がどれだけ強いかも重要である。
プロジェクトに対し強い影響力を持ち、ネガティブ(反対者側)なステークホルダーには十分なケアが必要。中立的立場のステークホルダーにはできるだけ賛同者側に回ってもらうよう対応に注意する。

顧客要求の確認

プロジェクトが開始されたら目的・目標が狂わないように、顧客の企業戦略やプロジェクトの開始の背景などを確認しておく。そのためには顧客側の発注責任者であるプロジェクトオーナーにインタビューするということも重要だが、顧客側の様々な立場のマネジメント層の方針や考え方を確認することも重要。

このとき注意することとして、ユーザーからの要件の収集ではなく、マネジメントの考え方を理解するためのインタビューであることを念頭に置く。顧客側マネージャがシステムに対する要求を伝えたと思われないように配慮しておく。

プロジェクト計画書の作成

この段階でプロジェクト計画書を完成させる。受注側のプロジェクトマネージャの管理項目として大きな特徴はプロジェクトの利益に対しても気を使わなければならないという点である。PMBOKは社内のプロジェクトを想定しているので、プロジェクトがもたらす利益はすぐには現れないものが殆どだが、受注側ではプロジェクトの終了と同時に収入が入りプロジェクトの採算が評価できる。このため、プロジェクトの採算もプロジェクトマネージャの大きな管理項目となる。

プロジェクト管理標準の確認

ここでの重要な作業は、どのような開発技術・手順を採用するかである。このようなことを「成果物指向プロセス」と呼ぶが、これを確定させないことにはプロジェクトマネジメント計画書も作成できない。
通常は受注側が開発手順を提案書に記載しているので、その方法で進めることを発注側に確認する。場合によっては発注者側の開発手法を使うことや、提案とは違う進め方を顧客から要求されることもある。

変更管理基準の作成

f:id:masayuki_kato:20171011195334j:plain

請負契約の受注型のプロジェクトの場合、変更管理に関する手順を明確に定義し、顧客側と十分に理解しあうことが重要。
変更管理の基本はプロジェクトのすべてのステークホルダーが要求する変更である。これは当初のベースラインを変更する本来の変更要求だけでなく、是正や予防処置も含まれている。変更要求は変更管理委員会(CCB)において、その変更を承認して実施するという手順を決めておき、それに従い対応する。

顧客が出してくる変更要求は成果物スコープの変更要求が主であるが、これは顧客との契約に関係してくる。このような顧客からの変更要求についても、開始時期や運用方法などを営業と交えて顧客と受注者側で合意しておくことが重要である。

要求事項の定義とスコープ記述書作成

  • 成果物スコープの確定
    • RFP、提案書、契約書、SOWなどから成果物スコープの概要を確認する。
  • プロジェクトスコープの確定
    • プロジェクトスコープは開発技法などに依存している
    • 概要WBSの作成
  • 前提条件と制約条件の確認

WBSの作成

f:id:masayuki_kato:20171011204137j:plain

WBSはプロジェクトの作業を管理できる作業レベルまで階層的に分解したものである。WBSの各作業要素をタスクといい、最上位のタスク(レベル0)はプロジェクトそのものである。

WBSはこのプロジェクトスコープをさらに管理できるレベルまで分解したもので、この段階で分解できない場合は、計画を立てるのに支障のないレベルで止めても構わない。これは計画パッケージとして扱う。このように最初から詳細の作業に展開せず、段々と詳細化していくことを「段階的詳細化」といい、プロジェクト活動の大きな特徴といえる。

WBSの最下位タスクは「ワーク・パッケージ」とよび、個々の作業の定義や見積りなどはこのワーク・パッケージについていく。
すべてのワーク・パッケージには成果物あるいは作業完了基準が定められている。WBSの作成ルールとして、「手順を表してはいけない」というものがある。手順を表すためにはワーク・パッケージを「アクティビティ」に分解し、アクティビティ自体に順序関係を持たせる。

スケジュールとコスト計画

スケジュールが確定したらそれをガントチャートに落とす。こうすることで各月や週別の投入工数やコストが計算できる。ガントチャートの個々のタスクに必要な工数を要員の単価や能力別に期間単位で集計する。この期間は月別や日別で作成しても構わないが、数ヶ月単位のプロジェクトであれば週単位くらいにしておくのが適切である。

請負型のプロジェクトでは契約段階でスケジュールやコストが決まっていたりする。その後、詳細の計画を作る中でスケジュールが入りきらなかったりコストがオーバーしてしまうことがある。このような事態には調整作業が必要になってくる。
スケジュールの調整には一般に「クラッシング」や「ファストトラッキング」という手法が使用される。クラッシングはスケジュール上のクリティカルパスに要員を投入し作業期間を短くすること。ファストトラッキングは作業の順序関係を外せるような工夫をして期間を短縮する方法である。

コストを下げるにはスコープを削ることが最も簡単な方法であるが、他の方法としては安いコストの要員に変えたり、外部委託(特にオフショア)の利用などが一般的である。
受注企業の利益に余裕があるうちは、契約金額を変えずに受注企業側の利益を少なくしてコストを確保することもある。

要員の平準化

f:id:masayuki_kato:20171011212513j:plain

プロジェクトに投入する要員はプロジェクト期間を通じて一定であることが望ましい。要員の増減が頻繁に行われるとプロジェクト内のコミュニケーション負荷が高まったり、要員の習熟度が落ちて効率が悪くなる可能性がある。
平準化するには時間に余裕があるタスクの開始時期をずらしたりリソースに余裕がある場合、あるタスクにリソースの追加投入をして期間を短縮するなどの調整を行う。

体制図作成

WBSや要員の投入計画ができたらプロジェクト体制図を作成し、それぞれの役割を明確にする。受注企業の体制図は自社内チームと顧客側チームの体制に分けて考える必要がある。さらに、受注側と顧客側との間に両者のマネジメントからなる「ステアリングコミッティ」を置くのもプロジェクトを円滑に進めるための手法である。

プロジェクトの正式レビューの計画

プロジェクト活動にはマネジメントレビュー、進捗レビュー、品質レビューといったプロジェクト外部からのレビューが多くある。受注プロジェクトになると自社内のマネジメントプロセスに基づくレビューと顧客側のマネジメントプロセスに基づくレビューに分けることができる。これらのレビューは同じような時期に行われるレビューでもレビューの目的が異なるのでプロジェクトマネージャは両方の要望に答える必要がある。

品質管理基準の作成

品質管理計画は受注側の基準で実施するのか顧客側の基準を使用するのかを明確にする。顧客のRFPや提案書などに取り決めが無い場合はプロジェクトマネージャがプロジェクトに適した品質尺度を選定し基準値を決定します。

プロジェクト計画作成時のリスクマネジメント

プロジェクトの提案時にリスク分析を行っているが、プロジェクト計画を作成する段階ではプロジェクトを実行するにあたってどのようなリスクがあるか、必要な対応計画はなにかを考えなければならない。

調達マネジメント

受注プロジェクトにおいて、自社の要員が不足していたり技術レベルが低いようなプロジェクトを受注する場合、協力会社の要員や技術を前提として提案をすることがある。このような場合、発注側へ提案を進めていくなかで協力会社にRFPを出して実現可能性や協力会社のコストなどを確認する。顧客との価格折衝などが長引く場合は、協力会社との契約も同時に検討しなおす必要がある場合もある。

プロジェクト計画書の合意

  • プロジェクト計画書社内承認
    • プロジェクトが実行可能であるか
    • コスト計画が適正か
    • プロジェクトリスク対応はなされているか
    • プロジェクトの利益が確保できるか
  • プロジェクト計画書の顧客合意
    • プロジェクト計画が提案どおりになっているか
    • 成果物が期待できるか
    • プロジェクトチームの体制は十分か
    • 顧客側としての対応はどうすべきか
    • プロジェクトリスク対応はなされているか

キックオフミーティング

キックオフミーティングの目的はプロジェクトの関係者に支援を求めることである。プロジェクト計画書が完成した時点でステークホルダーを集めてプロジェクトキックオフミーティングを行う。このミーティングはこの後プロジェクトを円滑に進めていくのに重要なものである。できるだけ上位のマネジメントを招待し、プロジェクトに対する思いを語ってもらう。そして参加者の紹介を行い、今後のコミュニケーションを円滑に行えるようにする。