2017年5月8日

【コンサルタント散歩】

～障害に優先順位を付けて対応していますか？～

皆さんはテスト工程で障害が発生した際にはどのように感じますか？「スケジュールの期限が迫っているのに障害が発生して最悪だ！」「早めに障害が発見できてよかった！」など人それぞれだとは思います。筆者はちょっとテンションが上がる頭がおかしいタイプです。

本題に入りますが、皆さんが障害管理者になった際に障害が発生したとします。どのように対応しますか？何も考えずに障害が発生した順に改修を行っていませんか？そんな改修スケジュールを策定していてはスケジュールが破綻するのは目に見えていると思います。では、破綻しないためにはどうすればよいのでしょうか。それにはしっかりと障害を理解し、改修の優先順位を付ける必要があります。

プロジェクトの状況により優先順位は変わってくると思いますが、基本的には以下の優先順位になるのではないでしょうか。

1 テスト対象機能の仕様調整が必要になる障害

2 テスト対象機能のテストが実施不可能になる障害

3 テスト対象機能の他のテストケースは実施可能な障害

「3 テスト対象機能の他のテストケースは実施可能な障害」については、障害が発生したとしても他のテストケースを進めることができるため、優先順位は低くなります。また、他のテストケースを実施することにより内在している障害がないか確認することができます。次に「2 テスト対象機能のテストが実施不可能になる障害」については、対象機能のテストは止まってしまいますが、他機能にテストの人員を割くことができます。最後に最も優先順位が高い「1 テスト対象機能の仕様調整が必要になる障害」については、特に他のシステムと調整が必要な場合は、仕様調整した結果対象機能の設計見直しや後続機能に影響が出る場合があります。そのため、仕様の調整が必要になる障害は時間を要することになるので1番はじめに取り組む必要があります。

前回のコラム（2017/3/6）で開発する順番について少しふれさせていただきましたが、障害も同様に、時間を要する場合は優先順位を最優先にして取り組むべきです。この優先順位を間違えるとどんどん遅延しますし、進捗報告に際に「障害を理由にスケジュールが遅延します。」などの他人行儀の報告が行われて、障害管理者が悪者にされる場合もあるでしょう。そうならないように優先順位を決めて破綻しないスケジュールを策定しましょう。そのためにも、障害の発見者から事象、原因、テストが止まるのか、スケジュールに余裕があるのかなど優先順位を決める材料を集めることが重要になります。

2017年5月