3. パッケージデザイン ✔ プロジェクトに対する関心を高め る ✔ 受託案件には不向き。自社サービ スならやってもいいかも 4. やらないことリスト ✔ プロジェクトでやること・やらな いことをはっきりさせる ✔ 開発チームが判断に迷ったとき、 ここで認識を合わせたやらないこ とが判断基準になる 5. 「ご近所さん」を探せ ✔ プロジェクトの関係者を洗い出 し、関係者調整の抜け漏れ(品質 審査が必要だった!など)を防ぐ 6. 解決案を描く ✔ システム構成や採用技術にリスク がないかを話し合う(経験者が少 ない、お客様の制約で採用できな いなど) 7. 夜も眠れない問題 ✔ お客様とリスクについて話し合 い、不確実性を収束させる 8. 期間を見極める ✔ プロジェクトの完了に要する期間 をざっくりと検討する ✔ お客様のプロジェクトを始めるか 否かの判断を手助けする 9. 何を諦めるのか ✔ QCD+Scope(開発範囲)について 話し合い、開発範囲を柔軟にして おくことに了承してもらう 10. 何がどれだけ必要化 ✔ 必要な費用・期間・人材を明らか にし、お客様がプロジェクトの開 始をジャッジできるようにする 以下のような10の質問事項のテンプレートがよく使われるが、 目的(お客様との対 話、共通認識を持つ) を達成できるのであれば質問事項を減らしたり聞き方を変え たりすることは自由である。