ブロックチェーン技術入門 感想

読了自体は1か月以上前にしていたが,
諸々の事情で感想を書くタイミングを逸して今に至る.

ブロックチェーンとは,一言で言えば
ビットコインに使われている技術のこと.
ビットコインについては,今年の始めにコインチェック社が
セキュリティ問題をやらかしたこともあり,
一般の関心もかなり高まったんじゃないかな.

実際にスマートコントラクト(≒プログラム)を
作成できるようになることを目的としていることもあり,
本書の内容はかなり本格的.
暗号技術の基本にはじまり,トランザクションの内容から
各種通信のデータ構造に至るまで,
かなり実装寄りの説明がなされている.

俺自身がブロックチェーンについてほぼ無知だったこともあり,
読み切るのに相当な時間を要した.
かつ,正直「なんかわかったような気がするが……」の状態.

「作り」のレベルまで理解する上で
かなり意義のある書籍だと思うが,
入門書としては,あまりお勧めできない.

というわけで,本当はもっと初心者向けの本を読んでから
改めてこれを読んで感想を……と思っていたんだが,
前述の状況のまま時間が過ぎてしまったため,とりあえず執筆.

製造品質について勉強する4

これでラスト.
残る2つの特性である保守性と移植性について見ていく.

しつこく貼っておくが,参照元はこちら.
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

■保守性
定義は以下のとおり.

意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い。

「直しやすさ」ということになる.
「保守者」とあるが,インクリメンタルな開発プロセスの場合,
開発者にとっても決して無視できない特性となる.
副特性はちょっと多くて,以下の5つ.

(1) モジュール性
定義は以下のとおり.

一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように,システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。

いわゆる「結合度」などで表現される品質特性だ.
モジュール性が低いと,修正時の影響範囲が広くなり,
回帰テストの必要量も多くなってしまう.

(2) 再利用性
定義は以下のとおり.

一つ以上のシステムに,又は他の資産作りに,資産を使用することができる度合い。

今のご時世,完全スクラッチの開発なんてのはレアケースであって,
多くの開発においては,過去資産の流用が行われる.
なので,再利用性というのは長い目で見ると割と重要なのだが,
多くの開発では,この特性は無視される.
ぶっちゃけ,未来のプロジェクトに向けた先行投資なんて余裕はない.

(3) 解析性
定義は以下のとおり.

製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること,欠陥若しくは故障の原因を診断すること,又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。

解析のしやすさというのは,大きく2つの要素があると思う.
まずは,どこを解析すれば良いか自明であること.
構成要素毎の責務が明確なシステムであれば,解析の効率がぐっと上がる.
そして次が読みやすさだ.
ソースコードなら,いわゆる「リーダブル」であることが望ましい.
システム全体に目を向ければ,ログの読みやすさも重要な要素となる.

(4) 修正性
定義は以下のとおり.

欠陥の取込みも既存の製品品質の低下もなく,有効的に,かつ,効率的に製品又はシステムを修正することができる度合い。

……これ,ほぼ「保守性」のところで述べていることと同義では?
わざわざ改めて書いている理由が,よく分からない.

(5) 試験性
定義は以下のとおり.

システム,製品又は構成要素について試験基準を確立することができ,その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。

名前通り,テストのしやすさを表す特性だ.
テストを考慮できていないソフトウェアアーキテクチャの場合,
自動化の導入が困難であったり,
あるいはかなり大きな単位まで結合しないとテストできなかったりする.
前者に関しては,たとえばSeleniumを導入したものの
スクリプトが安定して動いてくれず,スクリプトのメンテに
かえって膨大なパワーを要した……なんて経験がある人もいるのでは?

■移植性
定義は以下のとおり.

一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い。

システムの移転だけでなく,
内部構成の入れ替え(バージョンアップ)なども含めた,
包括的な「移植」への対応能力を意味する特性となる.
副特性は以下の3つ.

(1) 適応性
定義は以下のとおり.

異なる又は進化していくハードウェア,ソフトウェア又は他の運用環境若しくは利用環境に,製品又はシステムが適応できる有効性及び効率性の度合い。

移植を行うことで,
有効性や効率性がどの程度損なわれるか,という指標となる.
機能の制約が発生したり,性能劣化をもたらす場合は,
そのシステムは「適応性が低い」という扱いになる.

(2) 設置性
定義は以下のとおり.

明示された環境において,製品又はシステムをうまく設置及び/又は削除できる有効性及び効率性の度合い。

物理的な置きやすさ(コンパクトさや配線の簡便さ)だけでなく,
ソフトウェアならばインストールの容易性も影響する指標となる.
「削除」が含まれているという点も重要だ.

(3) 置換性
定義は以下のとおり.

同じ環境において,製品が同じ目的の別の明示された製品と置き換えることができる度合い。

適応性と被っている気がするが,
こちらはよりソフトウェアのバージョンアップを意識した特性.
こんなの,バージョンアップの仕様次第な気もするが.


以上,これで製品品質の理解は終わり.
それぞれの特性間には依存性があったり,
また,ぶっちゃけ定義が曖昧だったりもするので,
「俺達はこう理解する」「その上でこのレベルを目指す」という合意を
プロジェクトの計画段階で取っておくことが大事だと思う.

製造品質について勉強する3

記事としては2つに分けるけれど,
たぶん今日で終わりかなぁ.

リファレンスはいつもどおり,これ.
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

■信頼性
定義は以下のとおり.

明示された時間帯で,明示された条件下に,システム,製品又は構成要素が明示された機能を実行する度合い。

「実行する度合い」という表現がとてもわかりづらいが,
まあ,「(指定された条件下で)いつでも実行できること」と
理解して良いと思う.
詳細は4つの副特性で説明されている.

(1) 成熟性
定義は以下のとおり.

通常の運用操作の下で,システム,製品又は構成要素が信頼性に対するニーズに合致している度合い。

他の3つの副特性が,
ユーザの期待値にどれくらい合致しているか,という話.
機能適合性の副特性に「機能適切性」というものがあったが,
あれの信頼性バージョン,という理解で良いと思う.

(2) 可用性
定義は以下のとおり.

使用することを要求されたとき,システム,製品又は構成要素が運用操作可能及びアクセス可能な度合い。

一般には稼働率などで表現される品質.
個人的には,これ,要らない特性だと思う.
というのも,可用性を満たすためには
「壊れにくいこと」「壊れてもすぐ直ること」が必要で,
それがまさにこの後の2つの副特性なんだよね.

(3) 障害許容性(耐故障性)
定義は以下のとおり.

ハードウェア又はソフトウェア障害にもかかわらず,システム,製品又は構成要素が意図したように運用操作できる度合い。

前述の(2)の「壊れにくいこと」に相当する.
世の中に壊れないものなんて存在しないので,
「もし部分的に壊れたとしても」に対する二重・三重の備えが必要となる.
航空機などの命に関わるシステムにおいては
何よりも優先される品質特性と言ってよい.

(4) 回復性
定義は以下のとおり.

中断時又は故障時に,製品又はシステムが直接的に影響を受けたデータを回復し,システムを希望する状態に復元することができる度合い。

前述の(2)の「壊れてもすぐ直ること」に相当する.
どれだけ備えていても,止まるときには止まる,それがシステムだ.
というか,万物においてそうであるはずなのに,
システムだけ異常に「止まること」が許されない……
そんな理不尽に対して,どれだけ備えているかを示す特性となる.

■セキュリティ
定義は以下のとおり.

人間又は他の製品若しくはシステムが,認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように,製品又はシステムが情報及びデータを保護する度合い。

一言で言ってしまえば「防御力」に相当する.
副特性は以下の5つなのだが,
最初に言い訳しておくと,解釈にすごく自信が無い.

(1) 機密性
定義は以下のとおり.

製品又はシステムが,アクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。

この特性は2つの観点を意識する必要がある.
すなわち,
「アクセスしちゃダメな人はアクセスできないこと」
だけではなく
「アクセスして良い人はちゃんとアクセスできること」
が求められる.
前者だけ意識するならば,それこそ通信ケーブルを引っこ抜いて
隔離しちゃえば良いだけの話なのである.

(2) インテグリティ
定義は以下のとおり.

コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを,システム,製品又は構成要素が防止する度合い。

機密性との違いがイマイチ良くわかないのだが,
どうやらこちらは,より「攻撃」を意識した特性,らしい.
不正アクセスに対する防御力の度合いを示すもの,かな?

(3) 否認防止性
定義は以下のとおり.

事象又は行為が後になって否認されることがないように,行為又は事象が引き起こされたことを証明することができる度合い。

銀行の通帳を見てみると,
いつ誰がどこでお金を引き落としたという事実が明確に記録されている.
システムにとっての「通帳」とは,DBのトランザクションデータであったり,
システム基盤上のログデータに相当する.
雑なシステム開発では,これらの証跡が滅茶苦茶に実装されていたりする.
そうすると否認防止性が低いと判定されるわけだ.

(4) 責任追跡性
定義は以下のとおり.

実体の行為がその実体に一意的に追跡可能である度合い。

否認防止性と似通っているところがあるが,
こちらは主語,すなわち
「じゃあ,誰がその事実を引き起こしたか」
に着目した特性と言える.

(5) 真正性
定義は以下のとおり.

ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。

例えば今まさに,はてなブログのシステムは
俺を「NK5」本人と見なして,記事の執筆権限を与えている.
これは
・このユーザがNK5のパスワードを知っていること
・またそのパスワードはNK5以外の者は知らない(はずである)こと
という論理に基づいている.
さらに真正性の高いシステムだと,ワンタイムパスワードを用いたり
あるいは指紋認証などを用いる場合もあるだろう.
ただし,そうしたシステムは得てして使用性を損ねるので
実装者のバランス感覚が求められるという点に注意が必要だ.

以上,次の記事も今日中に書く予定.

製造品質について勉強する2

懲りずに続けているシリーズ.
眠いので,今回は短く使用性のみ.

リファレンスもしつこく掲載しているがこれ.
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

■使用性
ユーザビリティ」と呼ばれるやつですね.定義は以下.

明示された利用状況において,有効性,効率性及び満足性をもって明示された目標を達成するために,明示された利用者が製品又はシステムを利用することができる度合い。

要するに,「利用時の品質」を満たすために
開発者が行うべき努力の観点,ということになる.
副特性は6つ.それぞれ以下のとおり.

(1) 適切度認識性
定義は以下のとおり.

製品又はシステムが利用者のニーズに適切であるかどうか(4.2.1.3)を利用者が認識できる度合い。

この「4.2.1.3」というのは,前回説明した「機能適切性」のこと.
機能そのものというより,そのアピール能力ということだろう.
雑に言えば,利用者に
「そうそう,これが欲しかったんだよ」
と言わせれば,その製品の適切度認識性は高いことになる.

(2) 習得性
定義は以下のとおり.

明示された利用状況において,有効性,効率性,リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために,明示された利用者が製品又はシステムを利用できる度合い。

……何か,定義の日本語が変じゃなかろうか?
「〇〇ために」が連続していて,シンプルに気持ち悪い.
まあ,特性の意味自体は深く考える必要もないだろう.
すなわち,
「マニュアルが簡潔であるか」
「そもそもマニュアルがなくても直感で操作できるか」
といったところが評価ポイントかと.

(3) 運用操作性
そのまんま.定義は以下.

製品又はシステムが,それらを運用操作しやすく,制御しやすくする属性をもっている度合い。

運用業者も立派なユーザであり,そこへの配慮は地味に大切.

(4) ユーザエラー防止性
これもそのまんま.定義は以下のとおり.

利用者が間違いを起こすことをシステムが防止する度合い。

いわゆるミッションクリティカル系のシステムにおいては
信頼性に匹敵するレベルで重要な特性だと思う.
ジェイコム株の事件とかは有名ですね.

(5) ユーザインタフェース快美性
定義は以下のとおり.

ユーザインタフェースが,利用者にとって楽しく,満足のいく対話を可能にする度合い。

一言で言ってしまえば「おしゃれさ」といったところだろうか.
特にBtoC系のシステムで強く求められる特性かと.

(6) アクセシビリティ
定義は以下のとおり.

製品又はシステムが,明示された利用状況において,明示された目標を達成するために,幅広い範囲の心身特性及び能力の人々によって使用できる度合い。

これは近年になって注目されている認識.
言葉を選んだ定義ではあるが,
要するに障がい者や外国人への配慮が出来ているか,という話だ.


どれを重視するかは,製品のユースケースとアクタ次第,かな.

製品品質について勉強する1

前回の記事では利用時の品質について一通り見たので,
今回からは製品品質について勉強してみる.
たぶん全4回くらいになるかなぁと.

教科書は相変わらずこれ.対象は4.2となる.
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

製品品質とは,いつぞやにも述べた通り,
開発者の視点からプロダクトを評価するときの観点となる.

したがって,客が望まない品質であろうと
(すなわち,利用時品質が最低であろうと)
製造品質が完璧である,ということもあり得る.

もちろん,開発者は両者が合致するように努めるわけだが,
イコールではないという事実を,常に留意しておく必要がある.

さて,製造品質の大きな品質特性は以下の8つ.
・機能適合性
・信頼性
・性能効率性
・使用性
・セキュリティ
・互換性
・保守性
・移植性

さらに細かい副特性が出てきたりする.
とりあえず1つずつ見ていく.

■機能適合性
品質を語るときに一番出番が多いのが,これ.定義は以下.

明示された状況下で使用するとき,明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い。

利用時品質の「有効性」と混合しそうになる.
というか,ぶっちゃけ同じと思って良い.
評価者が開発者が利用者かの違いだけだろう.
実際,副特性も似たようなものが並んでいる.

(1) 機能完全性
定義は以下のとおり.

機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。

これは有効性の定義における「完全さ」と一緒だ.

(2) 機能正確性
定義は以下のとおり.

正確さの必要な程度での正しい結果を,製品又はシステムが提供する度合い。

これも有効性の定義における「正確さ」という文言に該当する.

(3) 機能適切性
定義は以下のとおり.

明示された作業及び目的の達成を,機能が促進する度合い。

……これがどうしてもわからない.
「適切」という単語もさることながら,
「促進」という単語も,これまた抽象的だ.

色々考えてみたが,これを
「利用時品質の有効性に対する,
 機能完全性および機能正確性の適合率」
と定義すれば,幾分か納得できる気がする.

製品品質はあくまで開発者目線の評価であるが,
利用者の期待とのギャップについて,
それは何かしらのバロメータで評価されないといけない.
機能適切性は,そのために敢えて存在する特性なのだと思う.

■性能効率性
定義は以下のとおり.

明記された状態(条件)で使用する資源の量に関係する性能の度合い

これも利用時品質の「効率性」と似通っている.
あちらは「資源」とひとくくりにされていたが,
後述のとおり,時間が別出しされている.
測定しやすいから,だろうか?理由はよく分からない.

(1) 時間効率性
そのまんまなので定義だけ述べる.

製品又はシステムの機能を実行するとき,製品又はシステムの応答時間及び処理時間,並びにスループット速度が要求事項を満足する度合い。

(2) 資源効率性
こちらもそのまんま.定義は以下のとおり.

製品又はシステムの機能を実行するとき,製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。

(3) 容量満足性
定義は以下のとおり.

製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。

これは利用状況網羅性に近いかな.
キャパシティは「性能」という単語に紐づけられやすいこともあり,
こちらの枠組みに納められているのだと思う.

■互換性
定義は以下のとおり.

同じハードウェア環境又はソフトウェア環境を共有する間,製品,システム又は構成要素が他の製品,システム又は構成要素の情報を交換することができる度合い,及び/又はその要求された機能を実行することができる度合い。

これ,結構勘違いされやすい特性だ.
というか,勉強するまで素で勘違いしていた.
要は,ライブラリとかで使われる互換性とは違うということだ.
(それは移植性の「置換性」に該当する)
この互換性は,「共存」「共有」という点にフォーカスしている.
後述の副特性を見ると,もう少し理解が進むと思う.

(1) 共存性
定義は以下のとおり.

その他の製品に有害な影響を与えずに,他の製品と共通の環境及び資源を共有する間,製品が要求された機能を効率的に実行することができる度合い。

これは主に性能効率性と関係してくる特性だ.
たとえば,性能効率性が抜群だったとしても,
その結果として同じ基盤上で動く他システムや他ソフトウェアの
性能を殺してしまうようなら,「共存性は最低」という評価となる.

(2) 相互運用性
定義は以下のとおり.

二つ以上のシステム,製品又は構成要素が情報を交換し,既に交換された情報を使用することができる度合い。

一言で言えば,インターフェースの充実度ということになる.
Web APICSV出力機能なんかが該当するかな.
データウェアハウスなどのシステムにおいては,
割と馬鹿にできない特性だと思う.


とりあえず今日はここまで.

利用時の品質を表計算ソフト(Excel)に例えてみる3

これの続き.
利用時の品質を表計算ソフト(Excel)に例えてみる2 - NK5のノート

「有効性」「効率性」そして「満足性」について勉強したので,
最後の2つをここで整理してみる.

■リスク回避性
定義は以下のとおり.

製品又はシステムが,経済状況,人間の生活又は環境に対する潜在的なリスクを緩和する度合い。
注記 リスクは,所与の脅威の発生確率と,その脅威の発生によって起きる悪影響の可能性との関数である。

「リスク」という言葉は,時と場合と相手によって意味が変わるので
結構危険な単語だと個人的に思っているなけど,
ここでは,発生確率によって重みづけされた悪影響の度合いとされている.
満足性と同様,これも3つの副特性から成る.

(1) 経済リスク緩和性
定義は以下のとおり.

意図した利用状況において,財政状況,効率的運用操作,商業資産,評判又は他の資源に対する潜在的なリスクを,製品又はシステムが緩和する度合い。

経済的なダメージ全般のリスクをターゲットにしているので,
セキュリティ関連は基本的にここに入ることになると思う.
Excelでは正直立てづらいけど,例えば,異常終了時のデータ復元機能が,
ここで言う「効率的運用操作に対する潜在的なリスク」に該当する,かな.

(2) 健康・安全リスク緩和性
定義は以下のとおり.

意図した利用状況において,製品又はシステムが人々に対する潜在的なリスクを緩和する度合い。

いわゆるミッションクリティカルなシステムにおいて
この特性が担うものは大きい.
自動車を一種のシステムと捉えるのなら,ATSなんかもこれに該当するはず.
Excelでは……うーん,ちょっと思いつかない.

(3) 環境リスク緩和性
定義は以下のとおり.

意図した利用状況において,環境に対する潜在的なリスクを製品又はシステムが軽減する度合い。

資源の無駄遣いや無暗な汚染を回避する度合い……ということかな.
スマホの省エネモードなんかは,これの一種になると思う.
やはりExcelではちょっと例えづらいところがある.

■利用状況網羅性
定義は以下のとおり.

明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において,有効性,効率性,リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

これまでに述べてきた4つの品質特性が,
あらゆる状況下においても十分に発揮されるか,という特性になる.
たぶん,定義内のとんでもない文言に目が奪われたはずだけど,
敢えてここでは触れずに,2つの副特性の話に入る.

(1) 利用状況完全性
定義は以下のとおり.

明示された全ての利用状況において,有効性,効率性,リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

これは理解できる.
要は「動作保証環境」における利用時の品質の保証状態を指しているわけだ.
Excelの正確な動作保証環境に関する情報はよく知らないが,
例えば,Windows7とWindows10の間で利用時品質に大きな欠落が生じなければ
利用状況完全性が高い,と言える.
問題は次だ.

(2) 柔軟性
定義は以下のとおり.

要求事項の中で初めに明示された状況を逸脱した状況において,有効性,効率性,リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

冒頭でも敢えてスルーしたけれど,
要するに,想定外の状況における利用時品質を語っている.
「いや,そんなの知らんよ」
と言いたくなるが,まあ例えばそういうときに
「これこれこういう風にすれば,使えるようになりますよ」
というメッセージを出してくれるか,
それとも問答無用で異常終了するかでは
満足性にそこそこ差が出るんじゃないかな.
そういうシステムは,柔軟性が高い,ということになる.

以上.
間違いがあったら申し訳ないけれど,
まあ,そこまで大外しはしていないんじゃないかな.


今更ながらExcelは題材としてあまり適切ではなかった気がする.

利用時の品質を表計算ソフト(Excel)に例えてみる2

前回のこれの続き.
利用時の品質を表計算ソフト(Excel)に例えてみる1 - NK5のノート

利用時の品質には5種類の品質特性があり,
目標達成に向けてシステムが役立ってくれるか否かの特性が「有効性」,
有効性と照らし合したときの消費資源の妥当性の特性が「効率性」
という話だった.
今日は残り3つを勉強する……予定だったけど,
満足性が凄く長くなったので,この記事ではそれだけピックアップ.

■満足性
定義は以下のとおり.

製品又はシステムが明示された利用状況において使用されるとき,利用者ニーズが満足される度合い。

利用時の品質を語るときは,大体この満足性にフォーカスしているイメージ.
定義が一見するとそのまんまなので,4つある副特性に着目して行く.

(1) 実用性
定義は以下のとおり.

利用の結果及び利用の影響を含め,利用者が把握した目標の達成状況によって得られる利用者の満足の度合い。

注目すべき点は「結果」「影響」というキーワードかな.
あくまでシステムを使った結果系に対して,ユーザが得られた満足度を
評価する特性となる.
有効性との違いは,正直俺にはよく分からないんだけど,
こちらの方がより感性・感情に訴えるもので判定するんじゃないかな.

中々Excelに例えるのは難しいというか,
Excelに限らず,「ああ,このツールを使って良かった」と言えるかどうかで
決まる品質特性,だと思う.

(2) 信用性
定義は以下のとおり.

利用者又は他の利害関係者がもつ,製品又はシステムが意図したとおりに動作するという確信の度合い。

実用性が結果にフォーカスしている品質特性とするなら,
こちらは過程にフォーカスした品質特性,だと思う.

特定の操作に対してユーザが期待する結果を確実にもたらさないといけない.
例えば「Ctrl + S」という操作でセーブが出来ないのであれば
そのシステムやソフトウェアの信用性は低いということになる.

また,これは製品特性で言うところの「信頼性」などにも関わると思う.
故障や緊急停止を繰り返せば,どんどん信用性は損なわれることになる.

Excel自体が表計算ソフトのデファクトスタンダードなところがあるけれど,
一方で信用性が十分かというと,微妙なところだと思う.
例えばオートコンプリート機能.
こちらが望んでいない文字列補完を促し,かつ意図せず実行しちゃう辺りは
信用性の低さの一因と言えるんじゃないかな.

(3) 快感性
定義は以下のとおり.

個人的なニーズを満たすことから利用者が感じる喜びの度合い。

……ごめん,これ,わかんない.
ただ,あくまでイメージなんだけど,
「満足」と「快感」で言うと,後者の方が強いイメージ.
ただし,「個人的なニーズ」を狙って満たすことは難しいので,
たまたまクリティカルヒットした場合に,この特性が強いと
言えるんじゃないかな,たぶん.

(4) 快適性
定義は以下のとおり.

利用者が(システム又はソフトウェアを利用する時の)快適さに満足する度合い。

これも他の特性と似通っているところがあるけれど,
裏返しで考えると,多少はピンと来る気がする.
つまり,快適性というのは
「ユーザを不快にさせない度合い」
と考えれば,良いんじゃないかと.

「Ctrl + S」でちゃんとセーブが出来たとしても,
そのたびに1分以上待たされるのであれば,
そのシステムは「信用性は高い」けど「快適性は低い」ことになる.

Excelで言うと,1個のファイルが異常終了するたびに
全ファイルが連鎖的に死亡するのは,個人的に
快適性の低さの1つかなぁと思っている.


残り2つの品質特性も,この後,別記事で書きます.