■ 1.システム化の目的が明確でない
- リスク事象：要件の増大、もしくは絞り込みの不全が発生し、プロジェクトが統制できなくなる
- 把握観点
- システム化の目的が文書化されているか
- 定量的な達成指標が文書化されているか
■ 2. 現行機能の調査・確認が不足している
- リスク事象：受け入れテスト時に不具合指摘が多発しプロジェクトの中断または大量の仕様変更が発生してコストが超過する
- 把握観点
- 業務要求と現行システムの関係を説明できるメンバーの有無
- 現行システムの設計書が最新化されているか
- 要件定義書に「現行どおり」という記載があるか
■ 3. 現行システムとそのドキュメントが整合していない
- リスク事象：現行システムから引き継ぐべき要件に漏れが発生する
- 把握観点
- 現行システムに関する各種ドキュメントが存在するか
- サンプルチェックによる網羅性・整合性の度合いが一定以上か
■ 4. パッケージ選定に関する検討が十分でない
- リスク事象：機能の要求を満たせないことや性能が出ないことにより、大きな手戻りが発生し稼働不能になる
- 把握観点
- 選定における機能条件、非機能条件、運用条件が明確に文書化されているか
- 検討経緯が明確か
■ 5. 性能の検討が十分でない
- リスク事象：利用に供する性能が出ないため、稼働不能や大規模改修に繋がる
- 把握観点
- 性能見積りの前提となるデータ量に関する資料の有無
- 実装過程における性能に関する進め方について、妥当性があるか
■ 6. 可用性の検討が十分でない
- リスク事象：安定稼働の保証がないため、稼働不能や大規模改修に繋がる
- 把握観点
- 目標とする稼働率、可用性確保の方式が明確か
- 稼働率の見積り方法は妥当か
■ 7. 運用要件の検討が十分でない
- リスク事象：実現できない、矛盾を含んだ要求仕様ができる（運用要件）
- 把握観点
- システム運用関連の検討が行われているか
- システム運用関連の成果物の作成が計画されているか
■ 8. 運用に向けての制約条件が明確でない
- リスク事象：期待された業務運用ができない
- 把握観点
- 運用担当者によるレビューが行われているか
- 業務視点でのウォークスルー、テストが計画されているか
■ 9. 要件を獲得すべきステークホルダーが網羅されていない
- リスク事象：要件の漏れが発生する（後になってステークホルダーから指摘される）
- 把握観点
- ステークホルダーのリストの有無
- ステークホルダー全員にヒアリングを実施しているか
■ 10. システム部門による要件とりまとめが十分でない
- リスク事象：要件がいつまでも確定しない、あるいは要件が想定以上に膨らむ
- 把握観点
- 要件の引き出しプロセスが明確になっているか
- 要件のとりまとめ様式が定義されているか
■ 11. ドキュメントの更新が管理されていない
- リスク事象：追加・改修開発時に、現行システムから引き継ぐべき要件に漏れが発生する
- 把握観点
- 変更管理手順が規定され、実践されているか
- 要件変更・ソースコード修正時にドキュメント修正およびレビューを実施しているか
■ 12. 仕様の変更管理ができていない
- リスク事象：規模の肥大化、費用に関するPJ の目標未達
- 把握観点
- 仕様変更一覧の有無
- 仕様変更に仕組み（フロー、会議体）が規定されているか
■ 13. ユーザーによる仕様の確認が十分でない
- リスク事象：要件の漏れや認識の齟齬が生じる
- 把握観点
- 現場ユーザによるドキュメントレビューが適切に行われているか
- 要件定義完了時点でステアリングコミッティが開催されたか
■ 14. 要求の優先度が曖昧になっている
- リスク事象：開発規模が膨張する
- 把握観点
- 要求に優先度付けを実施しているか
- 要求の優先度をお客様に確認しているか
■ 15. 業務要件の網羅性が検証できない
- リスク事象：画面、帳票等の形式的、定型的な情報はあるが、業務の全体にわたる要件や要望、今後の展望などがあいまいになる
- 把握観点
- 現行の画面や帳票以外から業務要件を把握するための人的な体制が準備されているか
- 業務視点でのウォークスルーがスケジュールされているか
■ 16. 設計と実業務の整合性が検証できていない
- リスク事象：業務に合わない情報システムになる（要件定義に漏れが発生する）
- 把握観点
- 業務面と情報システム面の双方から点検（ウォークスルー）し、業務に対する機能の解釈の誤りの有無について確認しているか
■ 17. 経営層によるプロジェクト運営の関与が十分でない
- リスク事象：要件定義を始めとする工程の節目や重要な意思決定場面で、優先順位やリソース配分に対する方向性が決まらないため、プロジェクトの意思決定が誤ったものとなる
- 把握観点
- プロジェクト憲章が作成されているか／承認されているか
- 経営層がプロジェクトに対し月次報告などを要求しているか
■ 18. 経営層によるスコープ決定への関与が十分でない
- リスク事象：調整の不調による費用の膨張や要件定義の誤り
- 把握観点
- 要件の変更時に、及ぼす影響に応じた責任者の承認を得るルールが存在するか
■ 19. 経営層がパッケージ導入の意図・目的を明示していない
- リスク事象：パッケージ導入でカスタマイズ仕様が膨張する
- 把握観点
- パッケージの採用方針（導入意図や、現行業務維持方針など）について、プロジェクト企画書などの公式文書に記載しているか
- カスタマイズに関する制約条件（コストや工数の上限など）について、プロジェクト企画書などの公式文書に記載しているか
■ 20. ステークホルダー間の力関係がアンバランスである
- リスク事象：全体最適が実現しないことによるQCD の乱れ
- 把握観点
- 納期折衝・スコープ調整の余地がない
- 異なる役割を持つステークホルダー間で指導・統括・評価関係がある
■ 21. 高次の調整・決定機関が機能していない
- リスク事象：重要事項の決定が遅れたり、調整できなかったりする
- 把握観点
- ステアリングコミッティにあたる機構が存在しない
- ステアリングコミッティの開催要件(定期開催サイクル、開催条件など)が定義されていない
■ 22. 十分なコミュニケーションがとれていない
- リスク事象：作業効率の悪化により工程の進捗が遅れる
- 把握観点
- 会議体が定義されているか
- 課題管理とエスカレーションに関するルールが規定されているか
■ 23. 業務用語が共有されていない
- リスク事象：要件定義・設計上の誤謬による手戻りや品質問題が発生する
- 把握観点
- （開発者向け）業務用語に関する注釈付きドキュメントの有無
- （ユーザ向け）システム用語に関する注釈付きドキュメントの有無
■ 24. 業務知識が不足している
- リスク事象：仕様変更、仕様追加の多発により、サービス開始の遅れや品質の極端な悪化を招く
- 把握観点
- ユーザ側：キーマンが明確であるか／要件定義に参画しているか
- ベンダー側：現行業務を現場レベルで調査しているか