第9回 ソフトウェアの利用時品質モデル
前回までは“製品そのもの”の品質、つまり機能適合性や信頼性、性能効率性といった観点についてお話してきましたが、今回は「SQuaRE」と呼ばれる利用時品質モデルについて、それがどういうものなのか、また注意すべきポイントを解説していきたいと思います。
まず利用時品質の定義を見てみましょう。
「特定の利用者が特定の利用状況において、有効性、効率性、リスク回避性及び満足性に関して特定の目標を達成するためのニーズを満たすために、製品又はシステムを利用できる度合いのことである」
特定の条件下で利用した場合の度合い・・と言われても、なかなかピンときませんよね。
この利用時品質については、「想定された人」が「想定した環境」で使った場合「表示されている期待値」が実現できることだと解釈してよいでしょう。
品質特性は、①有効性 ②効率性 ③満足性 ④リスク回避 ⑤利用状況網羅性 の5つに分類され、その下にいくつかの品質副特性が定義されています。
少し例をあげてみましょう。
「誰でも」は本当に「誰でも」？
今では知らない方もいらっしゃるかもしれませんが、昔の年賀状作成ソフトウェアのカタログで「誰でも簡単にサクサク年賀状が作成できる！」なんていう表記を見たことはないでしょうか。これを利用時品質の側面から考えてみましょう。
この表記だけですと、以下のような誤解が発生してしまう可能性があります。
- 「誰でも」ということは、これまでPCを触ったことのない子どもや高齢者でも問題なく使えるということだよね？
- 「簡単」ということは、初めて使うPCでもすぐに使えるということだよね？
- 「サクサク」だから、どんなスペックのPCでもストレスフリーに短時間でできるんだよね？
- 印刷するためのプリンターは、どのメーカーのどんな機種でもOKだよね？
・・と、「ただの揚げ足取りじゃないか！」と思われるかもしれませんが、利用時品質を考える第一歩は、キャッチコピーにつられて購入した結果利用できないという事態を回避することなのです。
利用者像を決める必要性
それではどうすればいいのか、1つずつ考えていきましょう。
まず、目に見えないシステムを販売する場合は、想定する利用者像を定義する必要があります。たとえば業務用ソフトであれば「経理事務の方向け」「普段からExcelをよくご利用される方」といったように、利用者のレベル感が分かるように記載する必要があります。
別の例だと、たとえば自動車の製品カタログに「運転免許証を取得している方なら誰でも」と書かれていたらびっくりしますよね。高性能スポーツカー、通勤用のエコカー、家族向けのワンボックスカー、それぞれで利用者像は分かれているはずです。カタログを見た顧客が自分の用途に合った車を選ぶ、その判断を容易にできるようにカタログでは表現されています。前出のような「誰でも」といった表現にはなりません。
環境を想定する
次に考えなければいけないのは、利用環境の特定です。
- 大規模対応システムor中小企業や個人を対象としたシステム？
- ネットワークorクラウド？
- 出力環境はどのようなプリンターなのか？
等々、重要事項を明示することが必要です。
ここまで記載することでようやく「想定された範囲」を明示することができ、その範囲内で利用した場合であれば、提供側も相応の満足性を提供することが可能となり、利用時品質は担保されたことになります。
リスク回避とは？
そして次の課題はリスク回避です。リスクには3つの副特性があります。
- 経済リスク緩和性
- 健康・安全リスク緩和性
- 環境リスク緩和性
先ほど想定した利用状況で、上記３つのリスクに対してどれだけ対策がされているかということになります。
「経済リスクの緩和」とは、財務状況や商業資産、評判または潜在的なリスクを緩和する度合いとされています。たとえば、請求書発行システムの場合だと、発行された金額に間違いがあると、財務面や評判においても悪影響が予想されますが、そのリスクに対しいったいどこまで対処するのか、といったような解釈になります。
社会的影響が大きなシステムほど損害賠償請求に対する準備も必要となってくるということですが、金額的な保証は一般的にしません。保証書などへの書き方としては「システム的にはこのような修正が可能です」と言った内容になってくるでしょう。
想定できないものを示す？
最後に、利用状況網羅性についてです。こちらには2つの副特性があります。
- 利用状況完全性
- 柔軟性
これは提供側の頭を悩ませる非常に難しい項目です。これまでは特定の利用者や環境を想定した上でのお話でしたが、網羅性はその想定した枠を超えた場合、どの程度まで使用できるかの度合いを示せというものになっています。“想定できないものの度合いを示す”というのは無理難題のように聞こえますよね。
「柔軟性」項目においても、明示された状況を逸脱した状況でどこまで対応可能なのかを示さなければなりません。もうお手上げだとおもわれるかもしれませんが、ここでギブアップしてしまうのではなく、少し見方を変えてみましょう。
たとえば、あるデータが破壊された場合における回復性として考えると、これは検証可能ですよね。製品品質特性の障害許容性や修正性、移植性のところをしっかり明示することで対処できるはずです。今回、冒頭からお話してきた利用時品質は、要求事項だけを見ると提供側に非常に厳しい要求を課しているように感じてしまうかもしれません。
ですが、冷静に読み解いて対処すべき品質事項を浮かび上がらせることができれば、そのための準備を行うことができます。そしてそれができれば、製品を市場に送り出すにあたっての根拠ある自信となってくれます。品質＝コスト増としてとらえるのではなく、市場における信用や商品力を高めるものとして取り組んでいただければいいのかなと思います。
改定作業のゆくえはいかに？
さて、前回のコラムでもお伝えした通り、この利用時品質モデルも現在、改訂作業が行われていますが、今回はかなり大幅な改訂となるようです（ISO9241-11で定義されているユーザビリティとの整合性を考慮し、これらの上位概念として利用時品質モデルを位置付けることが検討されているほか、利用状況網羅性に関しても変更が予定されるなど・・）。
詳細については、リリース後に改めてお話できればと思いますので、またお読みいただけると幸いです。
