2016/05/28
その環境、動作保証外ですよ。
唐突なタイトルだけれども、単純な話だったりします。「動作保証していないOSで入れたアプリケーションの動作は保証されないですよ」というおはなし。
で、今回はそれについての個人的な意見についてつらつらと書いてみます。
内容だけで言えば別に印刷業界に限った話じゃないですが、まあ、うちの方向性もあるし、実際に書く内容を加味して、DTP・印刷の扱いにしておきます。
ある意味どうでもいいことや、役立つかどうかもわからないような中身を、日々脳内から適当に垂れ流しまくりつつ、今日をなんとか生き存えることを思案してます。
2016/05/28
で、今回はそれについての個人的な意見についてつらつらと書いてみます。
内容だけで言えば別に印刷業界に限った話じゃないですが、まあ、うちの方向性もあるし、実際に書く内容を加味して、DTP・印刷の扱いにしておきます。
まあ「動作保証外」なのはわかると思います。そのメーカーが保証していないわけで。
せっかくなので、その「保証」について、一応意味を把握しておきましょうか。goo辞書から引用。
ほ‐しょう【保証】ほ‐しょう【保証】 【goo辞書】[名](スル)
1 間違いがない、大丈夫であると認め、責任をもつこと。「品質を―する」「彼の人柄については―する」
2 債務者が債務を履行しない場合に、代わって債権者に債務を履行する義務を負うこと。「―責任」
今回の場合は「その組み合わせ(OSやアプリケーションの各バージョン)においていえば、メーカー側が対外的に公表できるような確認については行っていないので保証外ですよ」という点がまずありきかなと、ふたつの意味のうち、まずは1番目のおはなし。要は「品質を保証しませんよ」ということで。
まあ仕方ないところでしょう。アプリケーションだけでなく、どんなものでも、品質については永続的に保証されるわけではないので。
アプリケーションについては開発時点で想定しているプラットフォーム(OSバージョン)があるし、開発環境だってその範囲内というのは決まっているわけなので、そこから外れる組み合わせについてはどうしようもない。
外れた場合には、考えうる品質保証としてはふたつ。まずは別途動作チェックを行い、正常に動作するかどうかの確認をするかどうかという話になるかと。そしてもうひとつは、OSメーカー側が過去バージョンのOSとの互換性有無について提示するかどうか。確実性でいえば両方だけど、少なくともどちらか片方ができていれば、まあ、品質的な問題は出にくいってことになると思います。
あとはそのチェックがいつ、どこまで行われるかってことになるわけですが……これも永続的にするのは、行うだけの義務はないです。これも別にアプリケーションに限った話ではなく。どんな場合でも、たいてい、保証期間は決まってますから。
保証期間を超えた場合についてはどうなるか、という話になりますが……一般的には有償ではないかと。例外的に無償のケースはありますが、原則としては有償。お金をはらってどうするかの話。
アプリケーションということになると、その有償部分で対応されるのはふたつ。個別にお金を払ってメンテナンス等を続けてもらうか、そうでなければ新しいバージョンに乗り換えるか。個別に開発されたものについては前者しかないわけですが、一般に購入できるアプリケーションの場合は後者になるでしょう。まあ、これも、アプリケーションに限らないです。動かなくなったら買い替えてね、っていうのはある意味普通なので。
そして自己責任についてですが……多少意味は異なりますが、さっきの「保証」のふたつめにつながる話になってくるかと。
要は「なにかあったときには自分で責任を取る必要がありますよ」……と。
これについてはふたつのグループによる差が出てくるところかと。
まずひとつめは個人で趣味としてアプリケーションを使ってる人。
何かトラブルがあったときでも被害が及ぶのはおそらく自分とか家族とか関わり合いのある少数の人なので、影響する範囲は少ない可能性が高いと思います。あと被害の規模も同様。それほどのものではないかなと。いざ債務が発生しても、せいぜい「ごめんなさい」とひとこと謝ればなんとかなりそうだし、ケースによっては謝る必要もなさそう。
もうひとつは、業務としてアプリケーションを使ってる人。問題はここ。
この場合、責任の重さは、当然ながら個人の趣味利用よりも重くなってくる。問題の内容によっては金銭問題にも繋がる可能性は少なからず出てくるわけです。
DTP・印刷の場合は、わかりやすいところでいえば「印刷事故」がそのへんになると思います。実際にモノ作って、そこに問題が出ちゃって、結果として刷り直しになっちゃうケース。直接的に金銭を支払わないにしろ、刷り直しの負担は生じるわけで、結果としてその費用負担は出ることになってしまう。
まあそれだけで済めばいいんですが。
問題は、別のケースで責任を問われる場合。要は「原因は何だったのか」という点。
往々にして、何故トラブルが発生したのかを報告しなければならないのもよくある話です。まあ、これも責任に関する問題の一端になるから。
そのときに大きな問題になりうるのが「なんでそんな保証されていない環境で処理した」という点。実際の原因はほかにあったとしても(たとえば、実は支給データ自体に問題があって、それを一切手付けずの状態であっても)、その状態が混じることによって、なんにも言い訳をさせてもらえない可能性が高まることになるわけで……。
そしてちょっと立ち戻る、「じゃあその場合はどう対応すればいいのか」って話。
単純なところでいえば「保証のある環境にする」ということに。なのでもともと保証されている、組み合わせ的に問題のない範囲で使うことに。
業務でいえば、同じバージョンのアプリケーションを使い続ける場合については、OSやハードウェアを変更しないか、変更しても保証されている範囲にとどめること。これに尽きます。これ以上はないです。OSやハードウェアを変更せざるを得ない場合は、アプリケーション側を変えるしかありません。まあ、どちらかは変えざるを得ないってことに。
もうひとつ、アプリケーションを変えることが何かしらの理由でできない場合……当然、メーカー側の保証はない状態。じゃあどうするかといえば、行うとしたら下記いずれかで対応することが考えらえるところ。他にもあるかもしれないけれども。
まず一番目。要は誰が保証するかというところなので、それを自ら行うケース。しかしこれ、あらゆる動作に関する検証を行うってことになるので、それだけ手間も時間もかかることになりますし、検証報告をどのように行うのかという問題もつきまとうことに。なにより、結果をどこまで信用できるかという影響もあるので、当然ながら確実な方法ではありません。
二番目。第三者機関等にて保証認定を行わせる方法。もちろん、信頼できる先であることを前提にしなければならないです。が、どこが信頼できるのかってことと同時に、一番目と同様に時間はかかるうえ、対外的な対応となると費用もかかるわけで(一番目だって目には見えにくい可能性が高いですが、実際には費用はかかります)。あとそもそもの話、どこで受け付けているのかってこともあるので、ある意味現実的とは言い難いです。
三番目……については、要は対外的にも「うちこんな環境で結果の保証できんけどそれでもいいよね?」ということをぶちまけてしまうという手法。そんなんありか? と思われるかもしれないけれども、それを受け入れるところがあるのなら、それはそれでアリかと。変な話、アプリケーションのバージョン縛り(バージョン指定)を対外的に受けてしまうこともあるわけで、その場合はこれしか方法がないんですよね。まあ、縛りを設けるってことは否が応でもそのバージョンを使わなきゃならないわけで、その場合どうするかとなると、実質的にこれしかないわけなので。バージョン縛るなら縛り側にもいざって時には痛みは伴ってもらいますよ、という話でもあるんですが。
ともあれ、いずれにおいても勝手な判断は避けたいところです。いざ発生する問題に対処しておく第一歩としても。
ちなみに、ここにも動作保証外の記事なんぞを多数入れてますけど、それによって実害が発生しても当然ながら責任とりませんから。参考にしてもらう分にはいくらでもしてもらってもいいですが。
コメント