これまで色々な開発場面に関わってきました。失敗が多く延伸を繰り返すケース、大きな問題なく予定通り進むケース、各種理由により方針変更を繰り返すケースなど、多岐に渡ります。
スケジュールや予算に余裕があれば、多少のトラブルは吸収出来ますが、限られたスケジュール/予算で行うときには、一つ一つの判断の精度が、プロジェクトの成否を大きく左右する事になります。そして、判断の精度は、判断時の情報量やリスク察知力が、大変重要なキーファクターになります。
では、システムにおけるリスクとは何でしょう？要件に関するもの、スケジュールに関するもの、システム規模に関するものなど多彩です。
例えば要件に関する不安要素として、要件の一部が未確定、途中で要件が変わる、実現が難しい要件などがあります。要件の具体的な内容としては、機能、使い勝手、負荷量、性能、トラブル時の調査のしやすさ、セキュリティバグなどの改修のしやすさ（パッチのあてやすさ）など。まだまだあります。
これらをすべて明確にすることはとても重要です。しかし、企画段階では、以下のような理由から簡単には明確にできないのです。
- 明確にしづらいものもある
例えば、使い勝手の評価は人の感覚により異なります。
明確にすること自体が難しいかもしれません。 - 開発を進める上で変わるものもある
上記の使い勝手もその一つ。作成した画面を見て「イメージと違う」となるケースです。
更に後工程で決まっていくことが多い運用に関する事項（トラブル時の調査のしやすさ、パッチのあてやすさ）なども、より運用負担を減らす施策が必要となるかもしれません。
上記の対応を、スムーズに進めることがとても重要となります。例えば以下のようなプロセスを進めます。
- 決めるべきものとして何があるかを事前に整理しておく
- 上記のうち企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく
- 後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処（影響局所化検討等を含め）を行う
上記の繰り返しが、とても重要となります。
次回は具体的な考え方について、ご紹介していこうと思います。