「先を読む」の連載、続編です。
「リスク回避のための考え方」（再掲）
①決めるべきものとして何があるかを事前に整理しておく
②上記のうち企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく
③後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処（影響局所化検討等を含め）を行う
今回は②について考え方をお知らせします。
②企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく
品質確保の観点で、リスクの大きさや、決めるべき期限をどう判断するかがテーマとなります。
ここでは、「リスク判断」と「期限」のそれぞれについて分けて話を進めます。
まず、リスク判断について。
平たく言えば、「その課題をそのままにしておくと、後になって、どれだけ大変なことがおこるか」です。「大変なこと」には、例えば以下のようなものがあります。
- 結合テストで部品間の連携ができないことが判明する
- システム開発が進み、最終テストで負荷要件や性能を満たさないことがわかる
- システム稼働後、特定のデータ投入や異常操作により、システムが停止する
- 作成したプログラムや、内部で利用している部品の脆弱性により、データ漏えいなどが発生する
システム開発(上記の1.〜4.)が進むにつれて、大きな問題につながり、大変な対応が必要となることがわかると思います。
想定される「大変なこと」が、どのような影響を及ぼすのかを考えることが、リスクの抽出となります。
非機能として、何を決めておかないと、どのような「大変なこと」に繋がるのかは、各所に文献やガイドラインが公開されていますので一読いただければと思います。
次に「期限」です。
当然ながら「問題が発生する前までに、きちんと対処すること」が原則です。
しかし、問題によっては、その対処に多大な時間と工数が必要となったり、場合によっては「作ってきたものの、作り直し」が必要となることがあります。
たとえば、部品abcと部品xyzを繋げる場合、部品abcでは負荷要件を満たさないことが最終テストで判明すると、abcだけでなく、xyzとの接続も再作成となります。
再作成となれば、その周りのテストもやり直しとなり、多大な時間とコストが発生します。このあたりも、事例などが各所に紹介されているので参考となるでしょう。
このような想定をしながら、期限を決めていくことになります。なお、最終的な期限を迎える前に、段階的にチェックポイントを設けて、きちんと期限に向けて進捗出来ているかを確認することも合わせて定めておくことが重要となります。
今回は「企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく」について考え方をご紹介しました。
次回は本連載の最終回である、以下について考え方をご紹介します。
③後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処（影響局所化検討等を含め）を行う
Maja KochanowskaによるPixabayからの画像