利用時の品質（最終･まとめ）

この規格はシステム／ソフトウェア利用時の品質を計測・評価するために作られたものだと思っています。

とはいえ、突然計測指標や評価方法を解説すると核となる"そもそも何を意図しているのか”がわからなくなる可能性もあるため、今回は「用語の意味」を中心に解説しました。

これらの意図や意味を確実に捉えることがこの規格の使いこなしの基盤となり、必要な計測指標や評価方法も導出しやすくなると思います。

では最後にまとめを。

■この規格の意味

あくまでも私の主観ですが、この規格は、利用者（人間）が、システム／ソフトウェアの利用を通じて、どのような要素で満足する（不満と感じる）のかをモデル化したものの一つであり、提供するシステム／ソフトウェアを利用者の立場に立ってつくることの重要性を伝えていると捉えています。

「想定する利用者」が存在していること、そしてシステム／ソフトウェアの外側にいる利用者の立場で「どう（満足を）感じるか」を捉えていることを忘れないようにしましょう。

（立ち位置）　利用者（★ココです！）←→システム／ソフトウェア

■個別要素は関係している

これまで見てきた通り、個々の要素がすべて並列・横並び、バラバラに存在しているわけではなく、それぞれが関係して構造を持っています。

機能が提供する「有効性」を核として、それがどのくらい効率的かを示す「効率性」、有効性の背後で実利用に伴うリスクをどの程度回避するのかを示す「リスク回避性」、想定内外の利用者の状況をどの程度カバーするのかを示す「コンテキストカバレッジ」が存在し、これらの結果、最終的にどの程度満足するのかを示す「満足性」がある。

このような関係（構造）が存在していることを理解して活用（参考に）したいものです。

■活用時の注意事項

この規格は決して「これらを考慮すれば完璧！」とか「これ以外の要素はない」ということを主張しているわけではないことに注意しましょう。

その内容は絶対視するべきものではなく、対象をよりよく理解し、システム／ソフトウェアを作り上げる・提供するための参考情報として活用する、というのが適切な距離感と取り扱い方になると思います。

もちろん「そんなの理解しなくても売れるシステム／ソフトウェアを提供できるから大丈夫さ！」という方は使わなければよいだけです。

モデルとは、「さまざまな領域で共通的に活用できるように代表的な要素で構成したもの」ですから、ある特定のドメインで活用する場合には過不足が存在する可能性が（大いに）あります。

「地図と実際が異なっている場合は目の前の景色（事実・実際）を信用せよ」ですので、実活用時は

・規格の用語、内容が実務にうまく合わないところがあれば適宜読み替える

・規格には存在するが、実務には存在しない要素があれば適用しない

・実務において規格に存在しない必要な要素があれば適宜追加する

・現実とはあまりにかけ離れている場合や使いこなせない場合は、無理に規格を活用しない

などの適切な（現実的な）取扱いが望まれます。

■使いこなせるようになるまで

最初からうまく使いこなせる人はまれです。

運転技術のように何度も実践しながら理解を深め、徐々に使いこなせるようになっていくのが通常ですので、３回程度は「トライ→フィードバック・改善」を重ねてください。

当初のトライアルの対象として規模の大きな対象や難易度の高い領域はお勧めしません。

小さな対象や難易度が低い領域から始めて徐々に規模と難易度を上げていくと、程よいチャレンジ感を得つつ、許容範囲の失敗リスクテイクになると思います。

何度も使っていくうちに利用者の立場からモノを見る、そして感じることの重要性を理解できるようになっていくと思いますのでお試しください。

■私が伝えたかったこととお礼

私がこのしがない連載を思い立ったのは「相手の立場に立ってモノゴトを捉え、考え、行動することの重要性を伝える素材になりそうだなぁ」と思ったからでした。

そもそも自分自身がちゃんと理解できているのかを確認するすべもなく、執筆時間を捻出できずに主に昼休み時間を活用したため不備もたくさんありましたね。その辺は大目に見てやってください。（笑）

お読みいただいたみなさんからのフィードバックをいただきつつ、さまざまなやり取りができたのはとても楽しかっただけでなく、自分の理解不足を解消したり、より深い理解を獲得することにつながりました。

この場を借りてみなさんにお礼申し上げます。ありがとうございました。

この情報が多少なりともみなさんの実務の参考になればうれしいです。

以上で「利用時の品質」の解説（もどきｗｗ）はおしまいです。