チェックリストでリスクを見つけてプロジェクトを幸せにしよう

# リスク要因を洗い出してリスク管理！

プロジェクト管理とはリスク管理とイコールだ！と言っても過言ではありません。
**すべてのリスクを回避**すれば、プロジェクトは

*期限通りに、*

*要件通りに、*

*お客様も満足して、*

*幸せに、*

終わる**はず**なのです。

# ITプロジェクトのリスク予防への実践的アプローチ

IPAが、そんな**幸せへの最短ルート**と言うべきドキュメントを出しています。それが、

[ITプロジェクトのリスク予防への実践的アプローチ](https://www.ipa.go.jp/archive/digital/iot-en-ci/hjuojm000000m6de-att/000026834.pdf)(PDF)

です。

長いですが、一読の価値はあるというか、百読の価値あるドキュメントです。
プロジェクトの最初に、プロジェクトの途中で、プロジェクトが終わってから、それぞれ違う読み方が出来ると思います。

ただ、**長い**ので、簡潔なチェックリストにしてみました。
これをチェックするだけでも、割といい線でリスクの洗い出しが出来るはずです。

リスクが見つかったら、対応方法を考えなければいけません。基本的には**チェックに引っかからないように**すればいいのですが、どうするのがベターなのかは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)

* ユーザ側のキーマンは出てきているか？話は聞けるか？
* 関連業務は明確か？
* 関連法規・外的制約は明確か？
* 業務分析は時間を取って行ったか？

# カバーされていない範囲

**進捗が遅れる**とか、**見積もりを誤った**とか、そういうリスクに対する対応はココには入っていません。
しかし、このリストに対応をすれば、そういった事象が**発生しにくくなる**ことは間違いありません。

**ちゃんとこういう工数考えてる！？** と言ってくれているリストに、ちゃんと対応すれば、基本的に工数が足りなくなることは無いはずです。

リスクをコントロールして幸せなプロジェクトマネジメントを！