スコープ定義だけでなく、用途の確認をすることで、万が一の際に後続影響を減らすアクションを取りやすい。
例えば、顧客が事前に意図しない用途での使用をすることが考えられる。
意図したものとは異なる用途への転用する場合で、転用先の用途での品質保証もユーザーが望むようであれば、その分のテスト工数を積んで対応することが重要。
このようなことを防ぐためにも、事前の検討と異なる用途で使う場合の責任は負えないことは日頃から伝達する。
テスト報告書の提出で完了とするが、要件定義など入口の段階で大まかなテスト観点を提供できると良い。
後続影響が大きい場合に、実装が無いが顧客に対してお金を請求する事例がある。
見積りの前提として、対応しないことの宣言を明記することが重要。
体制を組むことは、何かあったときの責任を取れるかということの裏返しであるため、何かあったときに責任は取れない点を強調すると顧客に文句を言われることはあまりない。もちろん、有事の際は責任の履行が求められる。
初期費用(Initial Cost)と保守費用(Operation Cost)の見積もりを提示する。
見積りで体制を検討する際には、スキルセットや担当者の忙しさ、タスクの依存関係を考慮して算出する必要がある。
ただ、細かすぎる見積は、顧客に読んでもらえないので、内部での見積算出用と提出用に分けるのが望ましい。
不確実性のバッファは現実的にはIT, ST, UATで積む。
リリース審査は主に事務コストを積む。
超概算見積はコンペにおける事前検討で使用されることも想定される。
プロジェクトマネージャーに必要なのは、進捗率よりも特に残工数を正しく工数を管理することが求められる。
「90%症候群」に気を付ける。
「90%症候群」とは、プロジェクトの進捗報告で、タスクが順調に90%まで進んだ後、最終的な完了（100%）になかなか到達しない状況。
手戻りや最終チェックの甘さ、報告者の心理的要因が原因で、深刻な納期遅延を引き起こす典型的なトラブルパターン
ここのタスクの予定工数を買えないまま、かかった工数を実績に積むと90%症候群にかかる。
予定工数を訂正しやすい雰囲気作りはこの点において重要。
イナズマ線を引いたりしたガントチャートで担当者個人に依存することが分かりやすいものは心理的安全性の観点においてはあまり良くないこともある。
タスクの依存関係があって、依存タスク待ちがあって、他のタスクに着手ができないような状況になった場合には、要員の稼働率低下が起きる。
顧客要因でプロジェクトの期間が延伸する場合の負担はユーザーに負担させる。
ベンダー要因での延伸で稼働率が悪化する場合はもちろんベンダーで負担する。
この際にプロジェクト全体だけではなく、マイルストーン毎の残工数管理も重要となる。
ターゲットとコミットを混同しない。
ターゲットはユーザーの要望としての期日や予算。
コミットはベンダーの実現可能性として提示する期日や予算。
「人月の暗黙知を解き明かす」にも記載あり。
不確実性のコーン
受動的にぼんやりとしても、グラフの右側に進まない(見積りの精緻化が進まない。)。能動的に働きかけたり、情報を増やして見積りの精緻化させる必要がある。
