前回、システムにおける品質リスクを出来るだけ回避するために、どのようなプロセスで進めればよいかについて、私の考え方をお知らせしました。
「リスク回避のための考え方」（再掲）
- 決めるべきものとして何があるかを事前に整理しておく
- 上記のうち企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく
- 後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処（影響局所化検討等を含め）を行う
それぞれのポイントについて具体的な考え方をご紹介していこうと思います。
①決めるべきものとして何があるかを事前に整理しておく
システムに必要な要件には、目に見えるものと、そうでないものがあります。身近な事例として、「年賀状の宛先を入力すると、ハガキに印刷してくれるソフトウエア」の場合、以下となります。
- 目に見えるもの（例）
- 宛先を入力する画面がある
- 宛名には複数の名前が入力できる
- 宛先の検索ができる
- 印刷位置は任意に変更できる
- 複数の宛先を選択し一括印刷ができる
- 目に見えづらいもの（例）
- 宛先を入力する画面の使いやすさ
- 宛先を保存する処理の性能
- 宛先を保存する事ができる件数
- 多くの宛先を保存した場合の検索性能
- 一括印刷が出来る件数
思ったよりも「目に見えづらいもの」があります。
宛名印刷ソフトを購入するに当たり、「目に見えるもの」だけをカタログなどで確認して購入してしまうと、以下のような不満が出て後悔をするかもしれません。
- 宛先を入力する画面が使いづらい
- 宛先保存が50件までしかできない
- 宛先の検索が遅い
- 一括印刷が5件しかできず足りない
以上は簡単なソフトウエアの例ですが、これが大きなシステム開発となると、より話は複雑であり、「目に見えづらいもの」も膨大にあるはずです。
もしも「目に見えづらいもの」を含めた、「ソフトウエアに必要な観点」のカテゴリが定義されていて、事前に洗い出し出来れば、と思いませんか？
ソフトウエアの世界に有効なカテゴリとして、「ソフトウエア品質特性」という物を指針にすると、これが可能になります。
「ソフトウエア品質特性」については、広くインターネットに公開されていますので、ぜひ一読いただければと思います。
今回は「決めるべきものとして何があるかを事前に整理しておく」についてご紹介しました。
次回は「②企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく」について、ご紹介しようと思います。