PMBOKの概要とA-Signの実装

・顧客、スポンサー、ステークホルダー等の要求事項
・プロジェクトの概要、目的、妥当性
・任命されたPMと権限レベル
・ステークホルダーの影響
・機能型組織の関与
・制約条件と前提条件
・要約したスケジュールと予算

各フェーズの立ち上げ時に、本プロセスでプロジェクト憲章の検証・更新を行います。

◆A-Sign◆
■プロジェクト憲章の管理
プロジェクト発行者がプロジェクト憲章として任意の形式のファイル・文書を作成します。任命されたPMはWeb情報共有システム上にプロジェクト憲章を転記入力します。その際、Web上のプロジェクト憲章の参照権限・更新権限を定めます。例えば、プロジェクト憲章の一部を特定のステークホルダーのみが参照または更新できるようにしたりします。

■プロジェクト憲章の変更
プロジェクト憲章はイニシエーターやスポンサーからのPMに対する「タスク（作業指示）」と捉えることができます。「タスク（作業指示）」はビジネス状況に応じて変更する場合があります。プロジェクト憲章も、ビジネス状況の変化があった場合は可視化された様々なプロジェクト情報を分析した上で大胆に変更する場合もあります。その場合、ステークホルダーに対する承認プロセスを経る必要があります。

各フェーズの立ち上げ時に、本プロセスでスコープの検証・更新を行います。

◆A-Sign◆
PMはプロジェクト憲章をもとにスコープ記述所暫定版を作成し、プロジェクト憲章と同様にWeb情報共有システム上に入力します。

各マネジメントの計画書を束ね参照します。
・資源カレンダー
・スケジュールベースライン
・コストベースライン
・品質ベースライン
※プロジェクト・マネジメント計画書は統合変更管理プロセスを通じて更新します。

◆A-Sign◆
フェーズ単位、タスク単位で各ファクター間の関連性を確認し統合的に計画します。各ファクターは一元化されているので各画面で時間・金額・進捗などを連動表示できます。

品質保証、プロジェクト・チーム編成、プロジェクト・チーム育成、納入者回答依頼、納入者選定、情報配布

承認済みの変更要求・是正処置・予防処置・欠陥修正の実行、資源の調達、納入者管理、教訓の収集と文書化

◆A-Sign◆
■変更処理
フェーズ単位・タスク単位で各ファクター間の関連性を確認し、スコープ・スケジュール・コストを変更します。

■作業パフォーマンス収集
メンバーは、WEB情報共有システムでタスク状態更新・進捗入力・勤怠画面でのコスト入力を行います。

スコープ検証、スコープコントロール、スケジュールコントロール、コストコントロール、品質管理など

◆A-Sign◆
フェーズ単位・タスク単位で各ファクター間の関連性を確認し、計画・実績を比較します。

【変更要求】　スコープの拡大・縮小、方針、プロセス、計画、手順、コスト及び予算等の修正やスケジュールの改訂
【是正措置】　プロジェクト・マネジメント計画書と実績の差異解消
【予防措置】　リスク低減措置
【欠陥修正】　品質検査や監視プロセスで発見された欠陥修正

提案済み、要求済み、承認済み、却下済み、実施済み

◆A-Sign◆
フェーズ単位・タスク単位で各ファクター間の関連性を確認し、各ファクターの変更を承認します。A-Signでは、特にフェーズ管理画面での分析を重要視しています。フェーズは、バリュー・受注契約・発注契約・予算・リソースコスト（月次・日次）を完全に関連付けることのできる唯一の単位です。フェーズ管理画面で、これらファクターを関連付け全体を俯瞰し、各ファクターの変更を承認します。

目標のためにどのような成果物を作成すべきかを分析します。

ステークホルダーのニーズ・利害を分析し、プロジェクトへの影響を分析します。

成果物を作成するための全てのタスクを定義します。また、成果物スコープ記述書において成果物を定義します。
成果物の定義は段階的に詳細化しますが、後工程のタスクのためには十分詳細な定義をします。

◆A-Sign◆
要件とタスクの定義はプロジェクトの目的を具体的に定義することであり、最も重要なプロセスです。よって、高度なスキル（主に洞察力）をもったメンバーが時間を費やして対応します。

■シンプル
要件（タスク）はプロジェクトの土台となるファクターです。この土台を基に、他のファクターは級数的に増加します。よって、要件（タスク）は冗長性をなくし可能な限りシンプルに表現する必要があります。また、要件（タスク）間の関連性を分析し、粒度の統一と適切なソートにより要件全体の構造もシンプルに表現します。
A-Signでは、要件（タスク）に対して、部門・分類・小分類・目的・優先度・タスク名などの属性（文字列）を任意に設定できます。また、属性を任意に組み合わしてソートすることができます。これら機能を活用し、要件（タスク）全体の構造をシンプルにしていきます。

■メタニーズ（ニーズの本質）
PMは要件定義書（文書化されたニーズ）がニーズの一側面のみを可視化しているのに過ぎないことを自覚します。膨大な業務や未知への多様な可能性のすべてを文書化することは現実的には不可能だからです。よくある間違いとして、要件定義書を全ての源泉とし、演繹的にあるべき業務・システムを構築してしまうことがあります。また、ニーズを網羅的に可視化できていない原因を顧客の表現不足だけとしてしまう場合があります。さらに、膨大な業務知識を、詳細かつ正しい分析をしないで、短絡的に本質的（TO　BE）ではなく無駄な業務として否定的に捉える場合もあります。
要件定義のプロセスでは、もちろん顧客のスキル不足の問題もありえます。ここで述べたい大切な観点は、要件定義とは情報を持つ者と情報を持たざる者の間での情報伝達であるという側面です。情報伝達を効果的に行うためには、情報を持たざる者の情報に対する敬意ある姿勢が重要だということです。つまり、PMを初めとするプロジェクトメンバーは顧客の膨大な情報に対して敬意を払うことが重要です。膨大な業務知識や未知への多様な可能性を、顧客と同じレベルまで理解しようとする姿勢があって初めて、顧客との共感や一体感が生まれ、顧客のメタニーズ（ニーズの本質）に迫ることが出来ます。 ここでは、メンバーの顧客に対する姿勢については言及していません。メンバーと顧客とのコミニュケーションスタイルについては状況に依存し様々な形態がありえていいからです。 しかし、情報に対する謙虚な姿勢については、状況に関わらず必要です。

■流動性
PMは要件定義書が基本的にその時点のニーズを可視化しているのに過ぎないことを自覚します。プロジェクトの進行過程で、ニーズの変化は起こりえることです。変化に対しては、「可視化する」という姿勢が重要です。「計画ありきで変化を認めない」、または「変化を分析なしに受け入れる」という行為はいずれも問題があります。ニーズの変化に対して、その他のファクター（バリュー、コスト、スケジュール、リスク、品質）などを可視化し、全体最適の判断をすることが重要です。A-Signでは、各データを統合管理し全体最適の判断を迅速に行います。

■「自由と統制」のメカニズム
A-Signでは「タスク（作業指示）」を発信者から受信者へのトップダウンの情報伝達だけではなく、受信者から発信者へのボトムアップの情報伝達としても捉えています。実際、Web情報共有システム上で自由な情報更新と必要十分な統制管理を行います。

成果物をワークパッケージまで階層的に分解したもの。

【WBS全要素に関する情報】　
ＷＢＳコード識別子、作業範囲記述書、担当組織、スケジュール・マイルストーン一覧表
契約情報、品質要求事項、作業の遂行を促進する技術的参考文献
【コントロールアカウント要素に関する情報】　請求番号
【ワークパッケージに関する情報】　関連アクティビティの一覧（親子関係、順序関係）、必要な資源、コストの見積り

プロジェクト・スコープ記述書とWBSとWBS辞書がプロジェクト（ベースラインとは承認された計画のこと）

◆A-Sign◆
PMはタスクに対してタスク内容・担当者などの各タスク項目を入力します。タスク（ワークパッケージ）に対して、FP法などを利用し機能量を設定します。さらに、機能量と係数（フェーズに設定されたFP係数）を乗じてタスクコストを算出します。タスク内容は仕様書として詳細化していくため、タスク一覧から参照されるファイルとして、仕様書をタスクNOなどで関連づけて管理します。

【類推見積り】　過去の類似アクティビティを参考にして見積ります。プロジェクトの初期段階で可能です
【係数見積り】　基準値（総工数、総所用期間）÷期間あたり投入量で算出します。なお、基準値＝機能量×生産性です。 (例：ＦＰ法、ソース行数見積など)。
【３点見積り】　最頻値、楽観値、悲観値の３つの見積り値から所要期間を求めます。

リスクを考慮しアクティビティに予備量を組み入れます。コンティンジェンシー予備、時間予備、バッファーと呼ばれます。

◆A-Sign◆
理論的には、タスク期間＝タスク工数÷アサインリソース数として算出しますが、アサインリソース数は他のタスクアサインの影響を受けるので、１つのタスクに関する局所的な計算ではタスク期間を算出することはできません。他のタスクアサイン、リソース負荷などを統合的に把握するために、後工程のスケジュール作成において、GUI操作によるアサイメントを反復的に行い、最適なアサイメントの結果としてタスク期間が定まります。コンティンジェンシー予備を組み入れる場合には、架空のサブタスクを用意するか、タスク期間に対して一定の率を加味します。

スケジュール・ネットワーク図に基づく、アクティビティの理論的な最早開始日・最早終了日、最遅開始日・最遅終了日を計算します。

【クラッシング】　コストとスケジュールのトレードオフを分析し資源追加をします。
【ファスト・トラッキング】　順番に行うべきアクティビティを並行して実行します。

資源の使用を一定レベルに保ち負荷を平準化します。資源平準化に伴いクリティカル・パスが変わる場合があります。

◆A-Sign◆
スケジュール作成のためには、クリティカル・パス、資源平準化、タスク順序など考慮すべき点が多く、演繹的にスケジュールを決定することは困難です。A-Signではタスク工数・タスク順序・リソーススケジュールを前提にGUI操作によるアサイメントを反復的に行い、最適なスケジュールを定めます。

・スケジュール・マネジメント計画書上のリソース時間
・要員マネジメント計画書上の特性・リソース単価
・リスク登録簿上のリソース

【類推見積り】　過去の類似プロジェクトを参考にして見積ります。プロジェクトの初期段階で可能です
【係数見積り】　計測した何等かの量と過去の実績に基づく係数とを利用して見積ります。

コンティンジェンシー予備をアクティビティに組み入れます。コスト・ベースラインに含みます。ＰＭ裁量で定める予測可能な予備量です。

品質コスト＝予防コスト＋評価コスト＋不適合コスト

◆A-Sign◆
WBS作成の際にFP法などを利用しタスクコストを算出し、さらにスケジュール作成の際にタスクアサイメントを行っているので、ここではサブタスクに対してアサイメントされたリソースの期間と単価を乗じてより正確なコストを算出します。コンティンジェンシー予備を組み入れる場合は単価に対してリソースに設定された予想係数を乗じます。

アクティビティでの見積コストをワークパッケージ、コントロールアカウント、プロジェクトごとに期間集計します。

マネジメント予備を織り込みます。特定のアクティビティに配分しないのでコスト・ベースラインに含みません。ＰＭ裁量ではない予測不可能な予備量です。

時間軸に展開した予算のことで、コスト・パフォーマンスの測定、監視、コントロールの基準です。

◆A-Sign◆
■ROI分析
PMBOKでは、財務効率評価は一般にプロジェクト管理外で行うとしています。つまり、コストや成果物（目的）は管理ファクターとしていますが、成果物が生み出すビジネス的バリューは管理ファクターとはしていません。
バリューが管理困難な理由は下記のとおりです。
・バリューを完全に定量化するのは困難です。例えば、内部統制対応など定性的に表現せざるをえない場合があります。
・バリューをタスク・コストと関連させることは困難です。例えば、１つのバリューは複数のタスク・フェーズに関連する場合があります。

A-Signでは、コストとバリューの対比はプロジェクト管理において可能な限り実施すべき作業であるとしています。なぜなら、バリューは最終的な目的であるからです。メンバーが自身の作業を最終的な目的と関連付けて認識することにより、モチベーションが向上し創造性と生産性を高めることができます。そして、母体組織としての全体最適をプロジェクト内で目指すことができます。

A-Signではコストとバリューの対比のために下記を行います。
【タスクにおける損益分析】　コストをタスクで集計し、バリューとコストを対比します。
【フェーズにおける損益分析】　コストをフェーズで集計し、バリュー、受注金額、発注金額、見積コストを対比します。
【ソート・コスト集約】　タスクにおいてバリュー項目（目的・BV明細など）を設定しソート・コスト集約などを行います。
【配賦処理】　タスク間での配賦処理（単純平均配賦・加重平均配賦）を行います。

■予算化
フェーズ予算は通常、タスクコストの集計値にマネジメント予備を加算し丸め処理を行った上でPMは決済責任者に承認申請をします。

プロジェクトの品質規格を定める際、多くの場合、母体組織の品質規格を踏襲します。しかし、場合によりプロジェクト独自で品質規格を定める場合もあります。

【スコープ受入基準】　品質管理も含まれますが、別工程とする場合もあります。
【スコープ検証】　成果物の受け入れ可能かを確認
【品質管理】　成果物が品質規定を満たしているかを確認
【スコープ限界値】　コスト、時間、資源の上限などです。限界値を監視し、超えた場合、何らかの対応をします。

品質管理、品質保証、継続的改善の方法を定めます。品質管理の方法として、成果物作成者と成果物レビュー者を分けることが有効です。

品質目標を定めます。品質報告の基準となります。

◆A-Sign◆
品質計画では、品質管理を下記のとおり分類して品質管理の方法を計画します。

■成果物の品質管理の非定型作業
ニーズに対しては、シンプルかつ本質的に可視化をします。（仕様書作成やテスト計画書作成など）
リスクに対しては、影響範囲を網羅的に可視化します。（他成果物との関連、他部門との関連など）

■成果物の品質管理の定型作業
ニーズに基づいた成果物の性能の定型的測定（仕様書に基づいたシステムテストなど）

■プロセスの品質管理の非定型作業
ベースラインとの乖離限界値を設定します。
ベースラインの変更の承認プロセスを規定します。

■プロセスの品質管理の定型作業
タスク、スケジュール、コストがベースラインとどの程度乖離しているかを監視します。
ベースラインの変更が規定どおりの承認プロセスを経ているかを監視します。

母体組織内の品質保証部・監査員などが、プロジェクトが母体組織の品質規格に従っているかどうかを監査します。
例えば、プロジェクトの品質規格において非効率な部分を識別します。

各作業において、問題点、制約、非効率などを分析し、根本原因を確定します。

◆A-Sign◆
母体組織の品質規格をプロジェクトで適用する部分を識別し、母体組織による品質保証を行います。

■母体組織の品質規格の適用が困難な品質管理
【成果物の品質管理の非定型作業】　プロジェクト依存が強いです。

■母体組織の品質規格の適用が可能な品質管理
【成果物の品質管理の定型作業】　不具合の個数測定基準など
【プロセスの品質管理の非定型作業】　乖離限界値や承認プロセスなど
【プロセスの品質管理の定型作業】　ベースラインの監視方法など

【OBS（組織階層）】　既存の組織の階層を表現し各組織にWBSの要素を割り当てます。
【RBS（資源階層）】　資源（人・物）の階層を表現し各組織にWBSの要素、OBSの要素を割り当てます。

プロジェクト内外での様々な交流、方法論として実証されている組織論などを活用し、組織を計画します。

必要な要員の役割、コストなどを計画します。その他調達方法、離任基準、育成方法、評価方法などを計画します。

◆A-Sign◆
■全コストの管理
A-Sign ではRBSに相当するリソース管理を行い、コストの源泉すべてを管理します。リソースには、社員、派遣、物品、賃貸などの種類があります。また、母体組織から配賦されるプロジェクト外のコストについてもリソースとして管理し、母体組織の財務部門とプロジェクトにおいてコスト情報を共有します。

■RBSとWBS
リソース設定画面において、仮のリソースを追加し、役割、コスト、契約タイプ（社員、派遣、物品など）を仮設定します。また、月次スケジュール画面において仮リソースとフェーズをアサインします。必要に応じて日次スケジュール画面において仮リソースとタスクをアサインします。

各部門、各プロジェクト、外部組織などと交渉の上、要員を調達（アサイン）します。各計画文書にアサインしたメンバー情報を記入します。

メンバーの休暇予定などの可用性を十分に理解します。

アサインされた要員の役割、コストなどを更新します。

◆A-Sign◆
リソース設定画面において、リソース情報をアサインされた実際のリソースの情報に更新します。また、リソースの可用性やその他備考的情報も更新します。月次スケジュールや日次スケジュールも、実際のリソースの可用性に基づき更新します。

共感、創造性

教室、OJTなどを利用する

打合せ、非公式交流など様々な方法でチーム形成をします。バーチャルの場合は特に必要です。

誤解が解消され生産性が向上します。

同じ場所で作業をすることにより、生産性が向上します。

自身の計画ミスによる残業は評価するできではありません。相対評価（ゼロサム評価）ではない絶対評価が効果的です。

◆A-Sign◆
チーム育成のためには、情報共有によりチーム形成を促進し、主観評価や相対評価ではなく、客観的な絶対評価を行い「ものづくり」に集中できるような環境を用意することが重要です。

■情報共有
Web上で任意の情報を共有します。各情報には申請者、更新者、閲覧者が自動設定され、チーム内でスムーズに情報共有できます。知識、目的、課題を共有でき、チーム形成が促進されます。

■定量的評価
一般に定量的評価は局所的になるため期待する目的とは異なった効果を招く場合があります。例えば、特定の指標（売上など）でのみ評価してしまうと、評価対象外の要素（利益、協調性、部下の育成など）に対するインセンティブがなくなります。このような局所性の回避に対しては、本質的には高度なスキルをもった管理者が時間を費やして対応するしかありません。
また、成果を定量化すること自体が困難な場合もあります。特にシステム開発の場合は、メンバーの成果以前に開発している「もの」自体の定量的価値の把握が困難です。A-SignではIFPUGが策定したＦＰ法を実際に利用可能な手法に改良した定量化手法によってFP量を算出します。そして各メンバーが費やしたコストを除算することにより生産性を算出し定量的評価を行います。

■定性的評価
定量的評価（成果主義）の失敗、いわゆる「成果主義の失敗」の反動で最近は定性的評価への揺り戻しが起こっています。しかし定性的評価には主観的になってしまうという欠点があるのは現在も変わりありません。これを回避するためには、PMBOKが示唆するように360度評価などの手法もありますが、本質的には高度なスキルをもった管理者が時間を費やして対応するしかありません。

進捗、達成業績、人間関係などを監視します。

定性的評価を多角的（360度評価など）に行います。

ルール、規定、マネジメントによってコンフリクトは軽減できます。逆に意見の相違をコンフリクトではなく生産性向上につなげることができます。

意見の相違、要調査状況、予想外の責任などを管理します。

◆A-Sign◆
チームマネジメントにおいては「自由と統制」のバランスが重要です。実際、メンバーには自分の仕事を自分で提案できるような自由を与え、提案はWeb上の承認フローでチェックがされるという必要十分な統制管理を行います。異なる意見をブレーンストーミング的に自由に発言し、その中から最適解を見出すことは創造的かつ生産的なことです。

ステークホルダーにニーズに応じた必要十分な情報伝達を定めます。

・必要十分な情報
情報の情報の不足はよくないですが情報の過剰も避けるべきです。

・必要十分なチャネル
ステークホルダーがn人いれば、論理的にはn人から2人を選択する組み合わせの数のチャネルがあり、無駄なチャネルを可能な限りなくします。

コミュニケーション技術には、打合せ・会議・ツールなど多様です。緊急度（定期的な文書報告か緊急の伝達か）やステークホルダーがツールを利用できるスキルがあるかなどの分析に応じて、必要なコミュニケーション技術を選定します。

◆A-Sign◆
A-SignのWeb情報共有システムで下記のコミュニケーションができます。
【情報・チャネル】　情報の参照項目、参照者を自由に制限でき、情報・チャネルを必要十分な量にできます。
【集合知】　１つの情報を複数人数で更新できるので、集合知を醸成できます。
【情報発信】　誰が参照したかがわかるので、発信者は情報がうまく伝達されているかどうかがわかります。
【情報受信】　アラート機能のように未参照の情報だけを抽出できるので、受信者は必要な情報だけを参照できます。

作業パフォーマンス情報,パフォーマンス測定結果,完成時予測値,品質管理測定結果,成果物

◆A-Sign◆
スケジュールやコストの進捗状況をEVM形式で報告します。
EVMの報告書式として下記があります。
・１つのフェーズやタスクに対して時系列のEV指標の変化を表現するグラフ
・複数のフェーズやタスクに対して任意の時点でのEV指標を表現する表

対面打合せやメールで課題解決を行います。

課題がアクティビティ（タスク）になるほど重要性を高めることは通常ありませんが、課題の管理は必要です。
実際、課題責任者や解決予定日などを管理します。

◆A-Sign◆
A-SignのWeb情報共有システムで課題をタスクとして登録・管理します。しかし、PMBOKが示唆するように、通常、課題は作業にはならないので、作業時間の割り当ては行いません。タスク名の先頭に＊をつけることにより、日報管理画面で作業を報告する対象のタスクにしないようにできます。

・リスクに対する方法論、スケジュール、コスト、役割と責任

・リスク区分（RBSなど）：母体組織のリスク区分をプロジェクトで活用することによりリスク識別の網羅性が向上します。
・発生確率と影響度の定義
・発生確率・影響度のマトリックスと等級付け
・ステークホルダーの許容度の改定：プロジェクト固有の情報を反映します。

【報告書式】　リスク登録簿の内容と形式など
【追跡調査】　教訓のためにリスク管理のプロセスを記録する方法

◆A-Sign◆
リスク管理においては、網羅的に分類することが重要です。実際、発生確率・影響度が一定基準以上のあらゆるリスクを可視化・分類します。

■母体組織のノウハウ活用
プロジェクトにおけるリスクを網羅的に分類するためには、まず母体組織の既存RBSなどを基にし、プロジェクトに関連する可能性のあるリスクを網羅的に分類し、暫定版RBSを作成します。

網羅的・構造的なリスク一覧を下記の手法などで作成します。
・RBS、ブレーンストーミング、デルファイ法、インタビュー
・継続的なリスク識別（想定外のリスクを見出すことに注意を払います。）

◆A-Sign◆
暫定版RBSを基にし、より具体的にリスクを洗い出し、RBSを作成します。

■RBSにおける分類として、下記が考えられます。
【ファクターによる分類】　品質リスク、スケジュールリスク、コストリスク
【フェーズ等による分類】　プロジェクト、フェーズ、スコープ

リスク等級、リスク緊急度など

リスクの発生確率を査定します。

リスクのマイナス効果とプラス効果の両方の影響度を査定します。
スケジュール、コスト、スコープ、品質などへの影響度を査定します。

発生確率・影響度マトリックスに基づいてリスクに等級をつけます。多くの場合、母体組織の規則をプロジェクトに適用します。

リスクの緊急度も重要な査定対象です。

リスクに関するデータの正確性、品質、信頼性、整合性等を検査します。

リスクをRBS上で分類するだけでなく、プロジェクト、フェーズ、スコープにより分類することにより効果的なリスク対応ができます。

◆A-Sign◆
■網羅性とリスク等級
PMBOKでは、全てのプロジェクト関係者がリスク識別に参加し、ブレーンストーミングや外部の専門化へのインタビューを積極的に行い、未知のリスクに対して可能な限り可視化することを推奨しています。これらはリスク管理において最も重要な網羅性という観点から有効な考え方です。
しかし、リスク識別ではリスク等級を念頭におくこともまた重要です。論理的にはプロジェクトに関する全ての行為にリスクがあります。よって全てのリスクを洗い出すことは現実的には不可能であり杞憂なことです。重要なことは、リスク等級（発生確率・影響度でおおよそ定まる）が一定基準以上のリスクを網羅的に可視化することです。これは定型的な単純な作業ではなく、鋭い洞察力が要求される高度な作業です。

様々な確率分布（ベータ分布、三角分布、一様分布、正規分布など）によって、発生確率を分析します。

感度分析によって、リスクの他のファクター（コストやスケジュール）への影響度を分析します。

デシジョン・ツリーによって、不確実な状況下で最善の意思決定を行います。実際、デシジョン・ツリー上でEMV（期待金額価値）を算出し、定量的な意思決定を行います。

モンテカルロ・シミュレーションでは、WBSやPDM上の各要素の確率分布関数の結果を、演繹的に繰返し集計し、総コストや最終完了日などを算出します。

◆A-Sign◆
A-Signでは数学的分析ツールとして相関分析や主成分分析のためのテンプレートがあります。複数のベクトル型のデータ間の関係性や法則を分析することができます。

【回避】　ニーズを明確化します。また計画変更により目標を緩和します。
【転嫁】　定額契約・保険などによるリスク転嫁。一般にリスク転嫁のためにはコストをかけます。
【軽減】　簡潔なプロセス・テスト実施などによる発生確率の軽減。機能を冗長させ機能欠陥による影響度を軽減します。

【活用】　有能なメンバーのアサイメントなどにより、スケジュール、品質、コストなどを計画以上とします。
【共有】　好機を第3者（パートナー、特定目的会社など）と共有します。
【強化】　好機の原因を強化し、発生確率・影響度を高めます。

【受容】　何も対応しないか、コンティンジェンシー予備を設けるかです。

対象のファクターを監視し、特定のイベントが発生次第、対応します。

◆A-Sign◆
■トレードオフ的対応策と本質的対応策
PMBOKでは、対応策の例として計画変更・要員追加・外注の利用などの各ファクターのマクロなトレードオフ的処理を挙げています。実際、トレードオフ的対応策は各ファクターを可視化することにより可能になる有効な対策です。しかし、最近のシステム開発のプロジェクトの場合は、対応と効果は単純比例せず非線形な関係になっています。そのようなプロジェクトでは各ファクターの関係は複雑であり、単純なトレードオフ的処理が有効でない場合もあります。
A-Signでは、トレードオフ的対応策だけでなく、マネジメントチームがミクロな深い洞察を行うことにより効果が純増するような本質的対応策も重要としています。

■マネジメントとアクティビティ実行の分業
PMBOKでは、マネジメントとアクティビティ実行とを明確に分類しています。プロジェクト全体の工程を明確にするためにこれ自体は有意義なことです。しかし、この分類を誤認し、マネジメントチームがミクロな深い洞察をする必要がないと解釈してしまうケースがあります。結果、マネジメントチームは短絡的なトレードオフ的対応策のみを繰返し、ゼロサムゲームのような状態になることがあります。A-Signでは、マネジメントチームがミクロな深い洞察を行うことにより本質的改善を目指すことも重要なリスク対応策であるとしています。

■マイナスのリスクとプラスのリスクへの対応策
リスクとは、将来発生しうる計画と実績の差異と定義できます。差異はプラス・マイナス両方あるので、リスクにもプラス・マイナス両方があります。リスク対応計画では発生確率・影響度について、プラスのリスクは高め、マイナスのリスクは低くするように対応策を定めます。

【マイナスのリスクへの対応策】
スケジュール・コスト・品質が計画よりも悪くなる可能性があります。発生確率と影響度を低くするためには、要員追加なども考えられますが、マネジメントチームも問題の本質を洞察し、実行アクティビティなどの質的改善を行うことも重要です。

【プラスのリスクへの対応策】
スケジュール・コスト・品質が計画よりも良好になる可能性があります。発生確率と影響度を高めるためには、要員追加なども考えられますが、良好な計画差異を積極的に可視化しモチベーション向上などを行うことも重要です。

リスクの重要度、対応策を繰返し見直します。

EV指標を利用してベースラインとの乖離を分析します。

マイルストーンなどで技術的成果の計画との乖離を分析します。

コンティンジェンシー予備残量とリスク残量を比較します。

頻繁に実施することにより、議論が容易になりミーティング時間が短縮されます。

◆A-Sign◆
■EVM
A-Signでは計画と実績を迅速に対比することができるので、PMAは日常的にベースラインとの乖離を監視することができます。

■コンティンジェンシー予備
その時点のリスクを見直し、過不足のないコンティンジェンシー予備に調整します。実際、下記のコンティンジェンシー予備を更新します。
・タスク予備期間
・コンティンジェンシー予備用タスク
・コスト算出のためのリソース単価予測係数
・予算算出の際のマネジメント予備費

■未知へのケア
リスクも要件と同様にプロジェクト進行過程における変動要因です。リスクは顕在化して初めて実感できる特性があるため、プロジェクトが進行し各ファクターが級数的に増加すると、相対的にリスクに対してケアしなくなる傾向があります。特にプロジェクトが逼迫した場合は、リスクを極端に過小評価する場合があります。「危機のときにこそ注意深くなる」という姿勢は意義深い示唆を含んでいます。特にPMは常に未知のリスクに対してケアすることが重要であり、そのような姿勢は、強いリーダーシップにも繋がります。

外製か内製かを判断します。外製の場合、購入、レンタル、リースかを判断し、直接費と間接費（購入手続き費など）の両方を考慮します。外製か内製かを判断する際に、母体組織の資産としての観点で配賦コストとして処理できることも考慮します。

どのような契約によって取得すべきかを検討します。
【定額契約・請負契約】　明確に定義された成果物を一括固定価格で定めます。
【実費償還契約】　実コスト（直接費と間接費）に納入者利益を加えた金額の契約です。
【タイムアンドマテリアル契約】　単価×作業時間＝費用で契約します。上記契約の中間的な契約です。

母体組織の契約部門・購買部門とプロジェクトチームとの作業分担を定めます。

◆A-Sign◆
PMは月次リソーススケジュール上の各リソースについてどのように調達するかを計画します。外注するリソースについては、発注契約管理において契約状態が未定の仮発注契約を作成し、リソーススケジュールと関連付けます。関連付けた後、リソース設定画面で、リソース単価（各月ごとに保持）を関連付けた発注契約の単価に反映します。

納入候補者から提案・入札を得るために使います。
入札招請書、提案依頼書、見積依頼書、入札公告、交渉招請書、第一次コントラクター提案依頼書ともいいます。

納入候補者からの提案書を基に評価・採点します。評価基準には、納入候補者の属性（技術力、資金力）、提案価格、所有権などがあります。

◆A-Sign◆
発注契約管理において、仮発注契約に対して求める要件・評価基準などを入力します。

価格、スケジュール、品質など

リスク軽減と数量割引の不適用のメリット・デメリットを考慮します。

◆A-Sign◆
■定量的評価
納入候補者からの回答を比較・評価する場合は、納入候補者間の比較だけではなく、これまでのリソースの生産性（機能量÷実績コスト）の比較も行い、可能なかぎり公正かつ定量的な評価を行います。

コスト、スケジュール、品質が契約内容と照合して問題ないか評価をします。

母体組織もしくはプロジェクトの支払システムによって支払われます。何れにしてもPM承認に基づいて支払われます。

システム化された契約管理（契約文書管理、支払管理、実績管理）を行います。

◆A-Sign◆
■発注契約とプロジェクトの関連
発注契約とプロジェクトは多対多の関係でライフサイクルも異なっており複雑な関係にあります。A-Signではこの関連を確実にマネジメントすることを重要視しています。PMBOKのWBSの説明において、発注契約をWBS上のタスクと関連づけて管理するとしています。しかし１つの発注契約は複数のタスクと関連づくことがあるので、A-Signではリソースと関連づけています。そして、リソースとタスクの多対多の関連付け（アサイメント）により、発注契約を複数のタスクと関連づけています。

■発注契約のタイプ
発注契約の契約内容が期間・人的リソースに関わる場合には、発注者・受注者間でサービス内容を明確に定義することは容易ではありません。A-Signでは、特に委託契約と派遣契約の管理についての管理手法を明確に定めています。委託契約の場合、受注会社の担当者が作業者の管理（スケジュール管理・日報管理・勤怠管理）を行う必要があります。しかし、プロジェクト全体の情報一元管理のためには、作業管理をPMが集中コントロールすることが望ましいです。A-Signでは作業者と管理者を多対多で関連づけて管理し、さらにPMは全体の作業状況を把握することができます。これにより、現在の複雑な組織構造でのプロジェクトにおいても発注契約の主旨どおりの契約履行を行うことが出来ます。

■支払管理
支払管理はプロジェクトのコストと関連づけます。また可能であれば支払金額をA-Sign内で計算します。支払金額は、母体組織で計算する場合とプロジェクで計算する場合があるので、A-Signの支払計算機能を母体組織またはプロジェクト内で必要に応じて活用します。支払計算は、例えば時間給で契約している場合は、勤務時間×時間単価＋残業手当+深夜手当＋各種経費などと算出します。支払計算は母体組織によって実装が多様であったり、母体組織の計算システムを利用しなければならなかったりし、A-Sign内での計算が困難な場合もあります。

購入計画から契約管理までの体系的なレビューを行い、他のプロジェクトの教訓とします。

正式な書面で納入者に完了を通知します。

◆A-Sign◆
発注契約管理画面で契約状態を完了または中止にします。