リスク要因を洗い出してリスク管理！
プロジェクト管理とはリスク管理とイコールだ！と言っても過言ではありません。
すべてのリスクを回避すれば、プロジェクトは
期限通りに、
要件通りに、
お客様も満足して、
幸せに、
終わるはずなのです。
ITプロジェクトのリスク予防への実践的アプローチ
IPAが、そんな幸せへの最短ルートと言うべきドキュメントを出しています。それが、
です。
長いですが、一読の価値はあるというか、百読の価値あるドキュメントです。
プロジェクトの最初に、プロジェクトの途中で、プロジェクトが終わってから、それぞれ違う読み方が出来ると思います。
ただ、長いので、簡潔なチェックリストにしてみました。
これをチェックするだけでも、割といい線でリスクの洗い出しが出来るはずです。
リスクが見つかったら、対応方法を考えなければいけません。基本的にはチェックに引っかからないようにすればいいのですが、どうするのがベターなのかはPDFを見たほうがいいです。
PDFのページ番号と、項目を対応付けておくので、リスクを見つけたらサッと対応策を見つけて下さい！
一番大事なことは、プロジェクトの成功のためにはベンダの努力だけではダメで、ユーザにも協力をしてもらわなければいけないということです。「こういう協力をしてもらいましょう」という対応策がほとんどなので、ユーザを頑張って説得しましょう。お互いの幸せのために！
リスク要因チェックリスト
主プロセス
1. システム化の目的が明確でない (P.16)
- システム化の目的は文書化されているか？
- システム化の目的が複数あれば、優先度はついているか？
- システム化の目的は誰が責任をもって決めているか？上位層も見ているか？
- 仕様が膨らんだ場合は、誰がどんな基準で対応を判断するか？
2. 現行機能の調査・確認が不足している (P.19)
- 業務知識のある人がプロジェクト内にいるか？ユーザ側？ベンダ側？
- 現行システムの要件定義をやったメンバーはいる？
- 現行システムのドキュメントは最新化されている？
- 「現行どおり」という記載があるか？あればそれは危険箇所。
3. 現行システムとそのドキュメントが整合していない (P.22)
- ドキュメントは存在するか？何が存在するか？
- ドキュメントの網羅性は？最新性は？
- 作成者は在籍するか？質問は出来るか？回答の精度と速度は？
- いっそスクラップ＆ビルドという手は取れる？
4. パッケージ選定に関する検討が充分でない (P.25)
- 選定の前提条件は明文化されているか？
- 検討・レビューは十分か？
- 必要な機能要件・非機能要件は満たしているか？Fit&Gap分析の時間は取ってあるか？
5. 性能の検討が充分でない (P.28)
- 性能目標を明文化しているか？
- 性能見積もりの前提データは十分あるか？正確か？妥当なものか？
6. 可用性の検討が充分でない (P.30)
- 稼働率目標は明文化されているか？
- 稼働率見積もりの前提データは十分あるか？正確か？妥当なものか？
- 可用性検証作業（復旧テスト等）は計画に入っているか？
7. 運用要件の検討が充分でない (P.32)
- 運用関連の手順書の作成計画はあるか？
- 運用手順書の作成メンバーはシステムを理解しているか？
- 障害発生時の代替・回復方法は手順書に入っているか？
8. 運用に向けての制約条件が明確でない (P.34)
- 非機能要件は具体化されているか？
- 運用体制は明確か？
- バックアップ等の作業を想定してスケジュールが作られているか？
- 運用担当者のウォークスルーはあるか？シナリオはあるか？
9. 要件を獲得すべきステークホルダーが網羅されていない (P.37)
- ステークホルダーのリストはあるか？職位は？知識レベルは？その人の信頼感は？
- 合意の形成方法は明確か？
- キーマンは誰か？
- 経営層は？コンプラ担当は？開発責任者は？運用責任者は？社外の人も使う？
10. システム部門による要件取りまとめが充分でない (P.40)
- 要件の引き出しプロセスは明確か？
- システム部門は決定権を持っているか？
- システム部門の業務知識は十分か？
支援・管理プロセス
11. ドキュメントの更新が管理されていない (P.42)
- 変更管理はされているか？
- 要件やソースの変更時に、関係するドキュメントを修正しているか？
- ドキュメント管理の工数は考慮されているか？
12. 仕様の変更管理ができていない (P.44)
- 仕様変更は一覧化されているか？
- 仕様変更は誰が承認するか？承認の記録は残るか？
- 仕様変更の内容確認は十分か？影響範囲は？規模は？
- 工数の変更が見えているか？
13. ユーザーによる仕様の確認が充分でない (P.47)
- 要件定義確認、ドキュメントレビューなどをやってくれているか？
- 業務視点のウォークスルーは予定されているか？テストシナリオは適切？
- UIなどはプロトタイプで確認してもらっているか？
14. 要求の優先度が曖昧になっている (P.50)
- 要求の優先度は明確か？
- 要求の依存関係は明確か？
- 要求の優先度はユーザーの基準でつけられているか？
15. 業務要件の網羅性が検証できていない (P.52)
- 現物の帳票などとの比較はしているか？
- 業務システムを理解している有識者はいるか？QA出来るか？
- Fit&Gapなどやっているか？
16. 設計と実業務の整合性が検証できていない (P.55)
- エンドユーザがUIを見ているか？
- 外部システムのI/Ｆは明確？サブシステム間のI/Fは明確？
- データベースの制限や入力値の制限は明確？境界値は？
- 適切なレビュアーはいる？
組織的プロセス
17. 経営層によるプロジェクト運営の関与が充分でない (P.58)
- プロジェクトは経営層に承認をとっているか？
- 優先度に経営的視点は入っているか？
18. 経営層によるスコープ決定への関与が充分でない (P.61)
- プロジェクトの目標に対して責任者は決まっているか
- 要件の変更時に、影響度によってエスカレーションするルールは決まっているか？
19. 経営層がパッケージ導入の意図・目的を明示していない (P.64)
- パッケージの採用方針は公式文書で残されているか？
- カスタマイズとスクラッチで費用・期間の比較は実施しているか？
20. ステークホルダー間の力関係がアンバランスである (P.66)
- 要件定義を分離受注出来るか？
- プロジェクトにとっての優先度が正しく評価されているか？
- 声が大きい人や立場が強い人が不合理な決定をしていないか？止める仕組みがあるか？
21. 高次の調整・決定機関が機能していない (P.68)
- プロジェクトの意思決定機関（ステアリング・コミッティ（＝ステコミ））はあるか？
- ステコミに決定権限があるか？開催頻度は十分か？議事録はあるか？
- ステコミの参加者は各ステークホルダーの利益を網羅しているか？
- 決定事項がちゃんと共有されているか？ひっくり返されないか？
22. 十分なコミュニケーションが取れていない (P.71)
- 長く放置されている課題はないか？
- コミュニケーションはBacklogなどのツールで行われているか？
- 定例会は行われているか？
- 随時の連絡先、緊急時の連絡先は交換できているか？
23. 業務用語が共有されていない (P.73)
- 業務用語辞書は作成されているか？
- DB項目説明書はあるか？
- 謎の略語等が出てきたりしないか？逆に、システム用語は伝わっているか？
24. 業務知識が不足している (P.75)
- ユーザ側のキーマンは出てきているか？話は聞けるか？
- 関連業務は明確か？
- 関連法規・外敵制約は明確か？
- 業務分析は時間を取って行ったか？
カバーされていない範囲
進捗が遅れるとか、見積もりを誤ったとか、そういうリスクに対する対応はココには入っていません。
しかし、このリストに対応をすれば、そういった事象が発生しにくくなることは間違いありません。
ちゃんとこういう工数考えてる！？と言ってくれているリストに、ちゃんと対応すれば、基本的に工数が足りなくなることは無いはずです。
リスクをコントロールして幸せなプロジェクトマネジメントを！