![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
作成が並列実行される。
※ 参考
↓ ↓ ↓（計画書）
↓ ↓ ↓（プロジェクト・スコープ記述書）
↓ ↓ ↓（スコープ・ベースライン）
↓ ↓ ↓（計画書）
↓ ↓ ↓（アクティビティ・リストなど）
↓ ↓ ↓（プロジェクト・スケジュール・ネットワーク図）
↓ ↓ ↓（アクティビティ所要期間見積）
↓ ↓ ↓（スケジュール・ベースラインなど）
↓ ↓ ↓（計画書）
↓ ↓ ↓（コスト見積、見積根拠）
↓ ↓ ↓（コスト・ベースラインなど）
↓ ↓ ↓（リスク態度：リスク選好、リスク許容度、リスク閾値）
↓ ↓ ↓（計画書、RBS、スコープ・ベースライン）
↓ ↓ ↓（リスク登録簿と報告書）
↓ ↓ ↓（リスク登録簿と報告書）
↓ ↓ ↓（リスク報告書）
↓ ↓ ↓（リスク登録簿と報告書、各種計画書・文書の更新）
キーワード
※ グローバルでは、議事録・念書ではなく、リスク対応計画。
（根本的に、契約がシッカリしているので、ジャパン・トラディショナル企業的に揉めない。）
情報伝達の責任は「発信した側」にある。
を使用して決定する。
アクティビティと言う用語が出てくるのは、時間と資源と原価。
※ 其々の優先度は同じ（ Q ≒ C ≒ D ）。
成果物を第１レベル～第ｎレベルに分解してWBSを生成する。
※ ワーク・パッケージは更にアクティビティに分割される。
以下の違い。
要件定義のインプットは以下になる。
プロジェクト・スケジュール・ネットワーク図作成
スケジュール・ネットワーク分析によるスケジュール作成
ネットワーク図とは異なる。
フロート（= スラック）は、最早開始日の最早終了日の差を示す。
違いを理解する。
| # | 名称 | 対応 | デメリット |
| 1 | クラッシング | リソースの追加投入 | コスト・リスク増 |
| 2 | ファスト・トラッキング | アクティビティの並行処理 | 品質低下（手直し増） |
※ 資源平準化には、コストカット的な意味合いもある。
※ 日本語が謎いが、円滑化という緩い印象のワリに、
ファスト・トラッキングや強制残業もあり、
CPを変更させないハードさがある。
※ トップダウン見積（類推見積）＝ 概算見積
= 発生確率 * 影響度
色々あるので理解しておく。
※ 「転嫁 ⇔ 共有」は第三者を活用するケースを言う。
| # | 脅威 | 好機 |
| 1 | 回避 | 活用 |
| 2 | 転嫁 | 共有 |
| 3 | 軽減 | 強化 |
※ 転嫁
※ 代表例は保険（コレはOK）
※ 保険加入は損失・保険コスト計算ではなく、損失の許容・非許容で決める。
※ 脅威の回避と軽減の見分けが付き難い。
明確に何かを避けているか否かで判断するしかない？
入札文書（調達文書）は、入札であって応札じゃないのでRFXから構成される。
一括か？準委任か？みたいな。
あとは、インセンティブの扱い。
※ リスクは不確定要素なので、
能力次第の不確実なインセンティブ≒納入者から見た場合のリスクとなる。※ 受注者側か？発注者側か？で、答えが真逆になるので注意する。
スポンサーがスケジュール・コスト見積の妥当性を評価できていない場合、
