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

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

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

産業技術大学院大学のプロジェクトマネジメント履修証明プログラムのユニット2が開講されました。
先日、「受注プロジェクトの管理」という講義を受けたので学んだことをまとめたいと思います。

www.kato-eng.info

「受注プロジェクトの管理」概要

プロジェクトマネジメントのプロセスは標準化されているが、PMBOKのようなグローバルな標準は日本の情報システム構築プロジェクトには馴染まなかったりすることが起きている。それは日本独自のプロジェクト構造やチームでの活動を重視する文化が影響していると考えられる。
また、日本のIT業界ではシステム開発を行う業者が請負契約で受注するなどの特徴がある。日本型の受注プロジェクトのプロジェクトマネジメント要素を学ぶ必要がある。

受注企業側のプロジェクトマネージャは発注者側で発行されたRFP(Request For Proposal)に対して提案書を作成するところから始まる。つまり受注企業のプロジェクトマネージャはプロジェクトの獲得活動から参加することになる。
提案の結果プロジェクトを獲得できたら契約書を取り交わしプロジェクトが開始されるが、このような受注プロジェクトでは発注者である顧客対応も重要な仕事となる。
プロジェクトが終了すると成果物を納め、契約を終了する活動と受注企業としての収支に関する評価作業が行われる。
このように受注プロジェクトでは社内プロジェクトや発注者側のプロジェクトマネジメントとは異なった視点の作業が多く発生する。

プロジェクトの受注

受注プロジェクトはプロジェクトを受注するところから始まる。この時に、顧客からRFPが出るのを待つのではなく受注のための戦略を立てて、より良いプロジェクトのオファーが来るような体制をとらなければならない。
RFPが出たらそのプロジェクトを獲得するべく最善を尽くす。この作業は営業の仕事といえるが、提案内容を考えるのはプロジェクトマネージャであり、この段階からプロジェクトマネージャが活動することはよくある。

今回はベンダー企業(受注者側)においてプロジェクトを獲得して開始されるまでの作業について学ぶ。

ベンダー企業のプロジェクト受注戦略

業界分析と戦略策定

プロジェクトが実行される本来の戦略や目的は発注者側である顧客の戦略によるものだが、そのプロジェクトを請け負って実行する企業にも戦略がある。
受注企業のプロジェクト戦略の第1歩は業界分析にある。業界の状況を分析し、これから先にどのようなプロジェクトの需要があるかを見極める。この分析でプロジェクト体制を考え、重要な分野への人材のシフトや要員の確保などを行いプロジェクトの準備を整える。

オポテュニティマネジメント

企業がどのプロジェクトを実行するかを検討することをポートフォリオマネジメントと呼んでいる。プロジェクトの受注側はオポテュニティマネジメントと呼ばれる。
これはまず、営業担当者等を通じて各顧客企業のプロジェクト予定の情報を集め、発生確率と規模(収入)を検討材料として受注プロジェクトを探していく。

プロジェクト提案活動

顧客からRFPが出されて、そのプロジェクトが受注企業の戦略に合致したら、プロジェクト受注を獲得するため提案活動に入る。本来この提案活動は営業部門の仕事ではあるが、プロジェクトの進め方や必要なコストの見積もりなどはプロジェクトマネージャが決めるのが相応しいため、この段階からプロジェクトマネージャも参加している。

  • 営業の役割
    • 顧客戦略の把握
    • プロジェクト背景の調査
    • 顧客の予算の調査
    • 競合企業の状況把握
  • プロジェクト実施部門の役割
    • 部門戦略との整合をとる
    • 要員のアベイラビリティの調査
    • 提案要員の選定
  • プロジェクト提案PMの役割
    • 顧客要求に合った提案作成
    • 受注側としてのフィージビリティ確認
  • プロジェクト実行PMの役割
    • 提案内容の確認と承認

プロジェクトの提案を行うプロジェクトマネージャとプロジェクトの実行を行うプロジェクトマネージャは出来れば同じ人物が良い。

RFP受領と内容確認

顧客からRFPを受領したら提案チームを作り提案活動に入る。まずはRFPを精査し、チーム内でブレーンストーミングや専門家のインタビューを通して顧客の要求・制約・前提条件・リスクなどを分析する。

ステークホルダー分析

この段階のステークホルダー分析は契約取得に関連する部分のみが対象となる。プロジェクト受注後、プロジェクトが開始されるときには再度ステークホルダー分析が必要になる。

顧客についてよく知っている担当営業や以前その会社のプロジェクトを担当したプロジェクトマネージャなどにヒアリングを行い、顧客の関係者や社内での力関係やそのプロジェクトへの関与度合いを調べる。

顧客以外にも自社内でこのプロジェクトへの強い影響力を持つマネジメント、顧客とのパイプの強いマネジメント、協力関係を持つベンダー企業の関与度合いを調査する。

これらの情報は一覧表にしてプロジェクトチームに引き渡されるものだが、プロジェクトマネージャが提案活動に参画していれば、このような情報の理解が確実になる。

ラフなプロジェクト計画作成

スケジュールは提案書の最も重要な要素である。RFPや営業担当を通じた情報や顧客ヒアリングで得た情報を基に、考えられる範囲でスケジュールを作成する。有効な資料となるものは、過去のプロジェクトの経験や自社内で共有している標準的なスケジュールチャートである。この時制約事項や前提事項に注意する必要がある。
また、この段階でリスクを検討しておく。

提案検討時のリスクマネジメント

f:id:masayuki_kato:20171010231842j:plain

リスクマネジメントの基本は「リスクの識別 -> リスク分析 -> リスク対応計画」である。リスクは変化するものなのでプロジェクト開始後もリスクマネジメントサイクルを回し続ける必要がある。提案作成段階では最初のリスクマネジメントといえる。この段階のリスクマネジメントはベンダー企業としてプラスのリスク・マイナスのリスクを検討し、受注しても大丈夫かを考える。

見積りと価格設定

プロジェクトの提案価格を決めるために、プロジェクトコストを正しく見積る必要がある。提案段階では見積りのための資料が十分でない場合が多いが、できるだけ多く見積り資料を集め、確定していないところは前提条件を明確にして見積る。
また、見積りコストに対してプロジェクト全体のリスクを考慮してコンティンジェンシー予備費を準備する。このコンティンジェンシー予備費までがプロジェクトコストであり、コストが決定したらそれに企業の利益を加えて提案価格を決定する。

f:id:masayuki_kato:20171010233034j:plain

営業的な判断で提案価格を先に決めておいて、そこからプロジェクトコストや提案内容を調整する場合もある。

提案書作成

提案書の記述ポイントは下記の通り。

  • RFPに対応していること
  • わかりやすく記述すること
    • パワーポイント等を利用
    • スコープ・スケジュール・コストを明確にする
  • 提案のポイント明示する(自社のアピール点)
    • 企業イメージ
    • この提案の優れているところ
    • 自社のアイデア
    • あえてRFPに逆らう逆提案
  • 企業戦略に基づくこと
    • 譲れないところの提示
    • 前提事項の明示
    • 顧客に対する要求の明示
  • 実行チームと営業チームを明確に示す

提案書と見積書の提出の場合もあるが、通常はプレゼンテーションの機会が設けられる。上記の記述ポイントを参考に提案書を作成する。特にRFPに対応していることと、自社の優れているところがアピールできていることが重要。

プロジェクト受注活動

提案が採用されて受注が確定したら顧客との間で契約書を取り交わす。提案通りで変更が無いプロジェクトであれば営業担当者が既定の契約書を作成するだけで済むが、顧客側から要望が出されたりなど、プロジェクトによってはいくつかの作業が発生することがある。
このような契約締結作業はプロジェクト活動に含めない場合もあるが、現実的にはプロジェクトマネージャが中心となって行う作業である。

提案内容についての調整

提案に対して不足部分や変更をしてほしいなどの要望があった場合、提案書に記述された範囲であれば営業担当とプロジェクトの実行プロジェクトマネージャで提案内容の変更を行い、契約書の作成に取り掛かる。
しかし、顧客の要望が提案書の内容から大きく逸脱するようなものであれば、顧客との交渉が必要になる。この作業期間は十分でない場合が多く、営業やプロジェクトマネージャの顧客との交渉力が問われる。

プロジェクト立ち上げの準備

提案が認められても契約が正式に締結されるまでに調整が必要になる場合があるが、この時点では契約は確定しているので、正式契約が締結されたら直ちにプロジェクトが開始されるように準備する。

第一に要員の確保がある。提案時点である程度の要員は確保しているはずだが、実際にいつから要員を投入できるかを個々に確認する。具体的な人物が確定していない場合にはあらためて要員を探すことになる。

その他に勘定科目用のコードを登録したり、プロジェクトチームの活動場所や必要な機器の手配も行う。

SOW(Statement of Work)の作成

SOW(作業範囲記述書)は本来発注側が作成するものだが、プロジェクトによっては作成されなかったり、受注側が作成し発注側の承認を得るということが行われている。

SOWは下記のように作成される。

  • 合意した提案書を基本に記述する
  • 受注側として作業内容を過不足なく記述する
  • 契約作業の範囲を明確にする
  • 契約書の補完書類として利用する

提案書や契約書がSOWとして利用されることもある。

契約書の作成・確認

契約書は営業部門で作成する。取引の多い顧客との間は「基本契約書」という契約書が存在していることがある。これは両者のすべての取引に共通している分についての取引内容について法務部門などの承認を得て作成されている契約書で、基本的に変更することができない。
個々のプロジェクト独自の契約内容は「個別契約書」とか「契約書別紙」と呼ばれ、プロジェクト毎に作成する。

日本国内における契約の種類は下記表の通り。

契約タイプ 成果物責任 発注者側の
指揮命令権
派遣法の制約 成果物の帰属 瑕疵担保責任
請負 有り 無し 無し 受注者 有り
準委任 無し 無し 無し 受注者 無し
派遣 無し 有り 有り 発注者 無し

契約作業

契約締結作業は営業部門の仕事であり、プロジェクトマネージャが直接関与することはない。しかし契約書の中身を精査して確認しておく必要はある。プロジェクトが開始されたら、契約書の内容を遵守する必要がある。

プロジェクト憲章の作成

本来はプロジェクト憲章はプロジェクトのオーナーが発行するものだが、プロジェクトマネージャが作成してプロジェクトオーナーが承認を得るように変わってきた。
受注プロジェクトの場合、発注側にすでにプロジェクト憲章がある場合はその憲章に従ってプロジェクトを進めればいいが、発注者側で作成していない場合や独立したプロジェクトとして実行する場合にはこの段階でプロジェクト憲章を準備することになる。

  • プロジェクト憲章とは
    • プロジェクトの正式な認可証書
    • このドキュメントの発行によってプロジェクトが正式に発足する