【PMBOK対応】PM試験の知識体系まとめ（#9 調達編）
#9.0 概要
ここで触れる調達の対象は、外部の人・物（機材やシステム）となる。
必要な知識は主に、法律・契約の種類と特徴・ビジネスセオリー(定石)である。
この知識が不足していると、議論が円滑に進まなかったり、計画の根本が崩れたりしてしまう。
小難しい内容が多いかもしれないが、曖昧さを残さないように覚えてほしい。
#9.1 調達マネジメントの計画
ここでは、#9.2～9.3 調達の実行・コントロールでのマネジメント方法や進め方を定義・文書化する。
外部から調達を行うか決定し、必要ならば「いつ・何を・いくつ・どにように」調達するか検討する。
その際、入札文書や発注先選定基準を作成し、納入候補を特定する。
インプット・ツール・アウトプットは以下の通り。
■#9.1.1 契約形態
PMが最低限覚えておくべき契約形態は、要員確保における「請負契約」「委任契約(準委任契約)」「派遣契約」の3つである、
また、物やソフトウェアの契約で必要なものは、「売買契約」「リース契約」「レンタル契約」「使用許諾契約」の4つである。
・#9.1.1.1 請負契約
物やシステムの成果物を「完成」させて初めて対価を得られる契約。
※民法改正（2020/4/1施行）により、未完成の成果物でも、価値があれば一部を請求ができるようになった。
成果物が具体的で、変化しにくい（不確定要素が少ない）場合に有効な契約である。
特徴は以下の通り。
- 受注側は「完成責任」を負う
※不履行の場合、債務不履行責任も有り
- 発注側は「支払責任」を負う
- 発注側は、受注側への進捗報告義務は無く、作業場所も任意である
- 受注側の要員は自由に変更可能
- 偽装請負
2005～2007年頃、製造業で多く行われていた不正で、
請負契約にも関わらず、直接指揮監督している状態を指す。
本来であれば労働者派遣契約か雇用契約を結ぶべきである。
具体例を以下図に表す。
・#9.1.1.2 委任契約(準委任契約)
役務（事務処理や作業）を実施すれば対価を得られる契約。
完成責任は無く、成果物が変化に富む（不確定要素が多い）場合に有効な契約である。
特徴は以下の通り。
- 発注側は、受注側への進捗報告義務は無く、作業場所も任意である
しかし、「善管注意義務（善良な管理者としての注意義務）」を負う
- 受注側の要員変更は原則難しい
- システム開発フェーズ「要求分析」「要件定義」「外部設計」「システムテスト」での契約が効果的
- 「履行割合型」と「成果完成型」の違い
委任契約(準委任契約)の契約方法には、「履行割合型」と「成果完成型」の2種類がある。
上述した内容は「履行割合型」であり、「成果完成型」は、成果物を完成させると報酬が支払われる。
「請負」との違いは、「仮に完成しなかった場合でも、損害賠償請求は発生しない」という点である。「請負」の責務の重さがよくわかる。
- 委任契約と準委任契約との違い
委任契約は、「法律行為（弁護士や税理士の業務）」に対する契約である。
準委任契約は、法律行為以外に対する契約である。
システム開発においては準委任契約が正しい契約形態であるため、試験の記述時には注意してほしい。
・#9.1.1.3 派遣契約
(準)委任契約と同じく役務に対して報酬が発生する。
大きな違いは、「受注側は、発注側の指揮命令に従う」である。
- 受注側は、発注側の指揮命令に従う
- 受注側の要員変更は可能
表にまとめると以下の通りである。
・#9.1.1.4 売買契約
所有権が受注側→発注側に移動する際に契約を行う。
通常の買い物も、契約書は締結しないが同じ概念である。
- メリット
①資産が自社の所有物になる
②長期利用を考えると割安になる可能性が高い
- デメリット
①初期導入費用が高額
②陳腐化のリスクがある
・#9.1.1.5 リース契約
リース会社が所有している物品・ソフトウェアを、発注者へ貸し出す仕組みである。
レンタル契約よりも比較的長期的な契約となる。
特徴は以下の通り。
- 契約期間未満での解約は違約金が発生する
- リース期間満了後、任意で「下取り」か「再リース」が可能
- 再リース時の金額は、当初より下がる場合が多い
- メリット
①初期費用が抑えられる
②陳腐化のリスクが抑えられる
- デメリット
①違約金の発生
②支払総額が割高
・#9.1.1.6 レンタル契約
レンタル会社が所有している物品・ソフトウェアを、発注者へ貸し出す仕組みである。
リース契約よりも比較的短期的な契約となる。
- メリット
①初期費用が抑えられる
②陳腐化のリスクが大幅に抑えられる
- デメリット
①支払総額がリースよりも割高となる
・#9.1.1.7 使用許諾契約（ライセンス契約）
物品ではなくソフトウェアに対し適用されることが多い契約。
所有権と著作権は開発者側に残り、利用者は「使用料」を支払う。
■#9.1.2 支払い金額の決定方法
契約の報酬支払金額の決め方を3つ紹介する。
・#9.1.2.1 定額契約
支払総額（固定金額）を契約書に定める方式。
仮に作業が増えたとしても支払額が増えないため、受注側のリスクが高くなる。
細分化すると以下の3つになるが、筆者は「完全定額契約」しかお目にかかれなかった。
- 完全定額契約
冒頭で述べた通り、支払い金額は固定で一切変更を行わない契約。
- インセンティブ・フィー付き定額契約
支払い金額を定めるものの、受注側の努力・結果に応じてインセンティブ（報奨金） を追加支払いする契約。
- 経済価格調整付き定額契約
支払い金額を定めるものの、インフレや金利・特定の商品価格等に応じて最終的な支払い金額を増減する契約。
・#9.1.2.2 実費償還契約
受注側が成果物を作成するまでに掛けた実費に、受注者側の利益を上乗せした金額を支払う契約。
細分化すると以下の3つがあるが、筆者はいずれもお目にかかれなかった。
- コスト・プラス定額フィー契約
冒頭で述べた通り、受注者側の実費に利益を上乗せした金額を支払う契約。
- コスト・プラス・インセンティブ・フィー契約
受注者側の実費に加え、受注側の努力・結果に応じてインセンティブ（報奨金） を追加支払いする契約。
- コスト・プラス・アワード・フィー契約
受注者側の実費に加え、場合によって報奨金を追加支払いする契約。
追加支払いするかどうかは、発注者の主観による判断され、受注者は異議を申し立てることができない。
・#9.1.2.3 タイムアンドマテリアル契約
IT人材派遣では一番多く用いられる契約ではないかと思う。
計算式は以下の通りである。
固定金額※1＋単価 ✕ 数量※2
※1：固定金額は、ゼロの場合も多い
※2：数量は、稼働時間×人数
作業員が意図的に残業したり休日出社する等、支払総額が予算を上振れしないよう、契約時に上限を定めることもある。
■#9.1.3 調達の計画
調達実行の前に、以下を検討・定義しておく。
・内外製分析（内部から調達するか、難しい場合は外部調達するか）
・依頼する作業の内容
・要求するスキル
・人数
・契約形態
・#9.1.3.1 代表的な外部調達要因
内部調達できない要因は主に以下の通り。
- 要員がいない
例1）採用計画の遅れ・予定外の退職等で、一時的に要員が確保できないため
例2）社内規範による制約のため（特定のフェーズでは内製しない等）
- 技術力の不足
例1）社内のナレッジ・技術要員等に一時的な不足があるため（将来的には是正する予定）
例2）社内の技術向上は計画していないため（パッケージソフトの改修等）
- 費用削減
例1）内部調達よりも外部調達した方が安価であるため
■#9.1.4 代表的な調達手順
代表的な調達手順は以下の通りである。
①調達作業範囲記述書（調達SOW：Statement Of Work）の作成
調達範囲のスコープを定義する。
・参考にする資料
スコープベースライン、アクティビティ資源見積り、スケジュール、リスク登録簿等の、調達以外のプロジェクト計画書
・調達作業範囲記述書に含める内容
成果物名、要求（仕様・数量・実施期間・品質・作業場所）、パフォーマンスデータ（各実行プロセスで発生したデータ）等
②調達方針の決定
調達方針を決定する。具体的な例は以下の通り。
・契約形態
・成果物の納期
・調達費用（概算）
・調達先の候補（RFPの送付先）
・調達先をマネジメントする担当者
・選考方法（一次選考 or 二次選考等）
③調達先選定基準の作成
調達先の選定基準には、評価軸・評価項目・配点等を指定する。
具体的な選定基準は以下表を見て欲しい。
※PM試験H21年午後1問2を参考に作成
④提案依頼書（RFP：Request For Proposal）の作成
RFPは、発注者から調達先候補へ配布する文書である。
作成時注意すべきこととして、認識相違が発生しないよう、以下のような観点を漏れなく記載することである。
・提出期限、提出先
・提出してもらう成果物名
・成果物ごとの作成要件（機能要件・非機能要件）
・成果物の前提条件、制約条件、除外事項
・提案書に記載すべき内容
（会社概要、作業場所、作業方法、使用ツール、提案内容、見積り金額、見積りの根拠 等）
・調達先選定結果の通知方法 等
- 情報提供依頼書（RFI：Request for Information）
RFPの作成中に疑問・不明点が発生した際、調達先候補に対して質問（情報提供）を依頼するための文書。
⑤RFPの配布
発注者は、「⑥入札説明会の実施」の数週間前に、調達先候補へRFPを送付する。
⑥入札説明会の実施
RFP配布の数週間後に実施する。
ここでの目的は、調達先候補からの質問に回答し、認識合わせを行うことである。
ここでのポイントは、「情報の偏りを防ぐため、どの調達先にも対等に接する」ということである。
質問に対する回答はとりまとめ、後日調達先候補へ配布する。
⑦提案書の入手と評価
提案書を入手した後、「③調達先選定基準の作成」で定めた基準に沿って評価（採点）する。
採点後、調達先候補に対し、選定結果を通知する。
⑧契約の締結
発注者は、提案書に基づいた内容で契約を締結する。
■#9.1.4 その他の調達文書
・見積依頼書（RFQ：Request for Quotation）
調達する物品・サービスの見積書送付を依頼する文書。
・入札招請書（IFB：Invitation For Bid）
読み方は、「にゅうさつ しょうせいしょ」。
RFPと同じ意味で使われることもあるが、「入札への依頼」に限定して使用される場合もある。
■#9.1.5 海外の人材活用
・#9.1.5.1 海外人材の活用の目的
当初は、調達先人件費の格差を利用し、コスト削減を目的に行わてきた。
しかし、時間と共に一部の国では日本との差がほとんど無い状態になってしまった。
結果的に、要員不足の解消を目的として活用することが増えた。
さらに今後は、技術力の高い人材を確保する目的で、利用することになると思われる。
・#9.1.5.2 オフショア開発とオンサイト開発
- オフショア開発
システム等の開発業務を、海外の事業者や海外子会社に発注する方式である。
主に開発・テストフェーズでの発注が多く、企画・要件定義・設計・リリース・運用等の業務は日本で行われることが多い。
- オンサイト開発
発注した海外企業のエンジニアが日本に来日し、企業内に常駐して開発を行う方式である。
対面で会話できるため、品質面・スケジュール面の認識が合わせやすいメリットがある。
・#9.1.5.3 オフショア開発の課題と対処方法
国内と海外とでは、言語・文化・雇用形態・品質レベル等、多くの認識違いがある。
これらが影響し、業務で発生しやすい課題と対処方法を紹介する。
#9.2 調達の実行
「#9.1.4 代表的な調達手順」の「⑦提案書の入手と評価」「⑧契約の締結」の実施がこのプロセスにあたる。
#9.3 調達のコントロール
調達先との契約に対し、実施状況が問題ないか監視し、問題があれば是正する。
契約範囲の責務が無事完了した場合、契約の集結を行う。
謝辞
以下利用させていただきました。感謝申し上げます。
・いらすとや
この記事が気に入ったらサポートをしてみませんか？