ITユーザの為のシステム開発リスクチェック集　　　　（プロジェクト計画編）

はじめに

このリストはＩＴユーザーがシステム開発プロジェクトの状況からリスクを抽出する際に持ちたい観点を集めたものです。システム開発は非常に失敗の確率の高い仕事で、頼んで作って貰ったのに、うまく動かない、想定していた機能が違う、とにかく使いにくい、費用が予定の２倍以上かかった。当初の予定を半年過ぎてもまだできあがらない。そんなことが日常茶飯事でまたそうしたことがあると、会社は数千万から時には数百億円の損害を被るし、担当者達も疲れ果てて病気になってしまうなんてことにもなりかねません。
そんなことを防ぐためには、システム開発で起きる様々な問題を、ことが起きる前に予測して、あらかじめ対策を立てておくことが大切です。このチェック観点集では、システム開発の要件定義ができたとき、プロジェクト計画ができたとき、そしてプロジェクト実施中に、ユーザが気づくべきこと、考えるべきことを集めています。こんなことがあったら、もしかしたらこんな目に遭うかもしれない、そんな書き方をしていますので、皆さんもこうしたことが起きていないかをよくよくチェックしてみてください。ただし、これらは"観点"であってチェックリストではありません。これらを起点に発想を広げ、また会話などをしながら各プロジェクト独自のリスクを抽出することが大切です。
実際、プロジェクトのリスクは各プロジェクトの特性や状況により無限に広がるものであり、画一的なチェックリストでこれを抽出することは不可能と考えます。従って、これまでのプロジェクト経験や各種の知見から観点を絞り込み、これを元に様々に思いを馳せることがリスクの抽出には必要となります。

尚、ここに挙げるリスク観点はデジタル庁の「デジタル社会MBOK、CMMIその他一般的な知見を参考に作成されていますが、これらはいずれも今後継続的に改善されていくものであり、特許庁内での知見も今後さ更に蓄積されていくことから、この観点集も継続的に追加・修正等を行いながら利用することが必要です。

「準備7割」という言葉のある通り、システム開発の成否もその準備状況によって大きく左右されます。ことにプロジェクト計画書の出来不出来は、無理なスケジュールやメンバーのスキル不足など多くの問題がその中に含まれているものであり、逆に言えばプロジェクト計画書をツブサに見ていくことで、そうしたリスクをあらかじめ織り込んでプロジェクトに入ることができます。

<<プロジェクト特性について>>

□ 複数プロジェクトが関連している
　　→ 双方の依存関係管理が不十分で、進捗が遅延する可能性
　　→ 双方の責任と役割の分界点が不明確で、作業漏れや重複が発生する可能性

□ 他システム連携がある
　　→ 双方の依存関係管理が不十分で、進捗が遅延する可能性
　　→ 双方の責任と役割の分界点が不明確で、作業漏れや重複が発生する可能性
　　→ 性能要件を満たさない可能性

□ 外部調達のあるプロジェクトである
　　→ 調達契約の遅延や不成立によりプロジェクト見直しを余儀なくされる可能性
　　→ 納品等の遅延や不実施によりプロジェクト見直しを余儀なくされる可能性
　　→ 調達品のサポートが十分に受けられずに、設計や開発に支障が出る可能性

□ マイグレーションである
　　→マイグレーションであることを理由にテスト観点を一部割愛し網羅性が不足する
　　　可能性
　　→潜在バグによりプロジェクトが混乱する可能性

□ 経営者等有力者からの依頼で始まったプロジェクトである
→ 合理的でないスケジュールや要件、その他制約事項を受け入れざるを得ず成果物
　　　の品質が低下する可能性、プロジェクトの健全性が損なわれる可能性