ASP、SaaS、クラウドなどが最近は多くなってきており、様々なサービスがされている。
そこでも「質」というものが問われる。
例えば。
個人情報を取り扱うような場合。どんなことを考えるだろうか?
・通信を暗号化できる方がいい。
・ローマ数字が使える方がいい。マンションやアパート名で使われているケースがあるからだ。
・第2水準以上の文字が使える方がいい。言わずもがな、氏名に使われるから。
いわば、提供されるサービスで実現したいことでもある訳だ。しかし、数年前はこれすら公開されずに「ASPサービス」などと名乗っている企業があった。結局、SSLを使っている程度で、住所や氏名は使い物にならなかった。今もそれなりにやっているようだが、事情が苦しいのは見て取れる。
そう、質というのは、こういうものにも適用できる。
その質を合意するのがSLAである。サービスレベル合意書、つまりどんなサービスをどういうレベルで提供するか、を双方合意の上で決定するものだ。パッケージソフトではなく、開発するソフトウェアについてはこれを交わしておかないと運用に入ってからトラブルの源となる。
また、SLAで合意形成を図るには、RFPで要件を定めておく必要もあるだろう。
そうなってくると「顧客が求めたもの」だけが質の基準になる、とも言える。実際、そのように定義しているものもあるが、それだけでは不足するケースがある。
例えば医療機関で電子カルテや診療報酬請求のサービスをSaaSで提供する、とした場合。現場のドクターや事務方から、医療に関する要件は出てくる。ベンダーはその通り作る、というだけで事足りるかというと、不足するのである。
大きな問題として、医療機関はカルテ等の情報が「個人情報」であるという認識が薄い傾向にあり、また個人情報として「機微な情報」であるという意識も更に薄い。となると、そこから「機微な個人情報であるので、これだけ厳重にしないと」という要件は、少なくとも医療機関側からは出てこない。しかし法的要件という制約がある。
特にカルテは改ざんできない仕組みも要求される。また、SaaSなどを運営するデータセンターはプライバシーマークの取得が必須であるとか、いろいろ制約事項がある。また、医療系のソフトではインタプリタ言語はNGとされているということを知る人は少ないかも知れない(少なくとも数年前)。
質から要件の話にちょっとそれたが、「要件を満たす」ということも「質」の一部であるのだ。
そこでも「質」というものが問われる。
例えば。
個人情報を取り扱うような場合。どんなことを考えるだろうか?
・通信を暗号化できる方がいい。
・ローマ数字が使える方がいい。マンションやアパート名で使われているケースがあるからだ。
・第2水準以上の文字が使える方がいい。言わずもがな、氏名に使われるから。
いわば、提供されるサービスで実現したいことでもある訳だ。しかし、数年前はこれすら公開されずに「ASPサービス」などと名乗っている企業があった。結局、SSLを使っている程度で、住所や氏名は使い物にならなかった。今もそれなりにやっているようだが、事情が苦しいのは見て取れる。
そう、質というのは、こういうものにも適用できる。
その質を合意するのがSLAである。サービスレベル合意書、つまりどんなサービスをどういうレベルで提供するか、を双方合意の上で決定するものだ。パッケージソフトではなく、開発するソフトウェアについてはこれを交わしておかないと運用に入ってからトラブルの源となる。
また、SLAで合意形成を図るには、RFPで要件を定めておく必要もあるだろう。
そうなってくると「顧客が求めたもの」だけが質の基準になる、とも言える。実際、そのように定義しているものもあるが、それだけでは不足するケースがある。
例えば医療機関で電子カルテや診療報酬請求のサービスをSaaSで提供する、とした場合。現場のドクターや事務方から、医療に関する要件は出てくる。ベンダーはその通り作る、というだけで事足りるかというと、不足するのである。
大きな問題として、医療機関はカルテ等の情報が「個人情報」であるという認識が薄い傾向にあり、また個人情報として「機微な情報」であるという意識も更に薄い。となると、そこから「機微な個人情報であるので、これだけ厳重にしないと」という要件は、少なくとも医療機関側からは出てこない。しかし法的要件という制約がある。
特にカルテは改ざんできない仕組みも要求される。また、SaaSなどを運営するデータセンターはプライバシーマークの取得が必須であるとか、いろいろ制約事項がある。また、医療系のソフトではインタプリタ言語はNGとされているということを知る人は少ないかも知れない(少なくとも数年前)。
質から要件の話にちょっとそれたが、「要件を満たす」ということも「質」の一部であるのだ。