ITユーザの為のシステム開発リスクチェック集　(要件定義編)

はじめに

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

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

要件定義書(仕様書)といえばシステム開発の出発点です。しかし、その中身を見てみると、間違ってはいないけど、今後思わぬトラブルを引き起こしかねないような記述があるものです。無論、これは要件定義書のレビューシートではありませんので、何か思うところがあっても、修正せよ！というわけでもありませんが、心の中では、なんかヤバいかも、もしもの時のためにあらかじめ対策考えておこうかな。。。と色々想像を巡らせることが大切です。

<<要件全般について>>

□ 要件記述の抽象度が高い(玉虫色)
　→ ユーザー、プロマネ、開発者間などで具体化された要件に齟齬が発生する可能性

□ 要件について最終利用者へのヒアリングが不足している → 結果として業務改善しない、あるいは使用されないシステムとなる可能性
　  → ユーザビリティ等が不全で、業務生産性が改善しない(悪化させる)システムとな
　　　る可能性

□ 現在のメンバーには理解できるが第三者に理解できない記述である → メンバー交代時などに要件を正しく理解されない可能性

□ 要件等が「現行踏襲」と表記されいている
→「現行」が正しく理解されておらず、誤った要件となる可能性
    →現行の要件定義書が誤っている可能性