回答。

歴史的に、作業量の評価は専門家の評価や過去のプロジェクトとの類似性に基づいています。限られた時間と情報の中で、システムアナリストは高レベルであいまいな要件を扱う必要があり、不完全さや過度の期待に直面することがよくあります。

問題: 不確実性は、評価が低く見積もられるリスク、顧客や技術チームとの対立、予算超過を引き起こします。契約締結後の前提条件の変更により、評価は非常に困難です。

解決策:

• 要件の分解技術や迅速な抽選手法（プランニングポーカー、Tシャツサイズ）を使用する。
• すべての前提条件と制約を特定および文書化する。
• 質問と未知の領域のプロトコルを維持する。
• リスクを考慮して余裕を持たせる（不確実性係数/バッファ）。
• 最も重要なことは、完了の基準（Done）と境界条件を明確にすることです。

主な特徴:

• 簡潔なアーティファクト: ハイレベルのシナリオ、ユーザーストーリー、C4ダイアグラム
• 価値の主要な流れを視覚化する。
• 合意を得やすくするためにプロトタイプやワイヤーフレームに重点を置く。

素朴な質問。

要件がまだ完全に明確でない場合、品質を損なうことなく評価を行うことは可能ですか？

いいえ、この段階での評価はすべてリスクと予備を明記して仮のものとして扱う必要があります。さもなくば、予算超過の責任が実行者にかかります。

評価には、顧客によって明示的に定義されたオブジェクトのみを含めるべきですか？

いいえ。明確に定義されていないものは、「不確実性のバッファ」または将来の明確化に対する特別なストーリーポイントを通じて評価されます; 「その他の要件は評価の範囲外」と明記することが重要です。

システムアナリストはTCO（総所有コスト）の準備に参加する必要がありますか？

はい、アナリストは要件リスト、シナリオのリスト、リスク領域、制約を形成し、TCOの正確な計算に必要です。

一般的な過ちとアンチパターン

• 不明な領域を考慮せずにプロジェクトを「直球」で評価する。
• 実施開始後の変更の可能性を無視する。
• 前提条件と制約を文書化しない。

実生活の例

ネガティブケース: システムアナリストはマネージャーからの要件を「そのまま」受け入れ、詳細を理解せずに迅速に評価しました。

利点:

• 迅速で、顧客にとって便利。

欠点:

• 予算超過、顧客とチームの不満。
• 解決策のリファクタリングおよび期限が最初から「燃えて」います。

ポジティブケース: アナリストは主要なステークホルダーとの作業セッションを実施し、一般的な要件も検討し、不確実性の領域マップを作成し、仮定を示し、余裕を設けました。

利点:

• すべてに対して透明な状況。
• 今後の段階での対立の最小化。

欠点:

• ファシリテーションスキルを必要とします。
• 事前セールのサイクルが少し長くなる。