（４）　妙な名前で引落し

筆者は、毎日、インターネットで銀行口座の明細をチェックし、経理や販売管理の入出金の入力を行う。

本日、見覚えのない引落しがあった。摘要に「 SMBC（キョウサイカケキン」とあり、52,180円の出金である。直ぐにはピンとこない。昨年と同月の経理の明細を見るがそんな名前は見当たらない。でもかろうじて自動車保険は農協で、掛け金を毎年7月に年一括自動引落しするようにしている事を思い出す。それにしても「SMBCナンチャラ」とは？

念のために農協に電話してみる。筆者は、こう質問した。いつも7月に農協の任意の自動車保険の掛け金を年一括払いで自動引落しするようにしているが、今日、銀行の明細に「 SMBC（キョウサイカケキン」とした自動引き落としがあった。これは、農協のクルマスターとかいう自動車保険の共済金の引き落としで間違いないかと。窓口の女の子は筆者の質問の後、お調べしますと言い保留にし、しばらくして、「それは農協とは関係がありません。」と答えたのだ。

そこで、引き落としされた金額52,180円を説明に加えたうえで再度調べるよう促したところ、また保留ののち、今度は、「農協の自動車共済の自動引き落としです」との説明にがらりと変化した。これを、にわかに信じられるわけもなく、先ほどとは全く異なる答えになったが間違いないか尋ねると、今度は、筆者のフルネームを聞かれ一度電話を切り、後刻電話をくれるとのことだった。十数分後にかかってきた別と思われる女性の説明は、「農協の自動車共済の自動引き落としを代理の業者が行っている」とのことだった。

くしくも、そのやり取りの直後、E-Mailにプロバイダからウィルス（トロイの木馬系）に感染したメールを駆除、無害化した旨のメールが届き、しかもそのウィルス駆除済みのメールの文面に「SMBC」という言葉が使われ、件名には、【三井住友銀行】振込受付完了のお知らせとあったのだ。これで、心配しないわけがない。

今のところ半信半疑というところ。あとは共済の証書が届くか、心配ならもう一度電話するかだが、あの農協の応対ではその気が失せる。人の名前、しかもフルネームを聞いて、こちらから尋ねるまで名乗りもしない職員の教育ではどうせ高が知れている。

 

追伸

7月23日に郵便で、無事、自動車保険の証書が送られてきた。自動引落しから17日も経っている。原付バイクに乗る家内から、保険証書の家族原付特約の写しを毎年この時期、会社に提出しなければならないからと、まだかまだかと催促され、言い争いまでなった。これほど時間がかからなければ不安にならなかったはずだ。

 

（３）　有償修理の承諾書をFAX返信したのに

また、B社で不快な思いをさせられた。

NAS製品の不具合で、6月23日に修理依頼しマシンを指定の手続きで送付したら、7月1日にFAXで見積金額が記載された有償修理可否確認書が送られてきた。即時、FAXにて有償修理を承諾する旨の返信をした。もうそろそろ修理が終わって手許に届くころかなと思い、B社のサイトを探すと修理状況の確認ができるサイトに行きついた。

7月5日にB社の修理状況の確認のサイトを開いて、シリアル番号と修理受付NO.を入力したが、「有償修理のお見積りを発行致しました。ご回答をお待ちしております。」というステータスで止まった状態であった。そこで、もう一度有償修理可否確認書を引っ張り出し、FAX送信した。

7月6日のAM9時半ごろ再度B社の修理状況の確認のサイトを開いて、シリアル番号と修理受付NO.を入力したが、状況は変わらず、「有償修理のお見積りを発行致しました。ご回答をお待ちしております。」というステータスで止まったままの状態であった。

そこで、電話で直接問い合わせると、とにかくこの電話（口頭）で修理方法B案で受付させていただきますとのこと。7月1日のFAX返信が受理されていたかどうかは不明だが、7月5日の修理状況の確認のステータスが「ご回答待ち」になっていたことは何らかの手違いかもしれません。また、7月5日のFAX再送していただいた後間もないので、修理状況の確認のステータスに反映されていないものと思われますとのこと。つまり反映には、1日程度の時間がかかるのが通常であるとの説明だった。それでも、にわかに信じられないのでいつ、どの運送業者で配送されるか回答が欲しいと念を押したら、後ほど担当部署からFAXでお知らせしますとのことだった。

7月6日のPM4時を過ぎた時点で、まだFAXは来ないし、修理状況の確認のステータスには、相変わらず何も反映されていない状況だった。

このように、何の確証を得ないままユーザーに納得させようとする電話窓口の担当者の対応に、端から信用しているわけではないが、誰かの手抜かりを尻拭いして筆者に怒られていることに憤慨している程度の係員だったのであろうと勝手に想像してしまう。それで電話対応の係りが務まるのか。そんな社内の対応体制に何の気配りもしない会社のトップの姿勢にあきれるばかりである。と勝手に見下したい思いだ。修理状況の確認のサイトのステータスがリアルに正確に更新されてさえいれば、ユーザーの心情が揺れることはないし、2度も3度も電話をかけることもなかったはずである。何のための確認サイトなのか。誰のための確認サイトなのか。今の世にあってこの手のステータスを示す類のサイトを出す趣旨をはき違えて欲しくないだけである。

 それと、今思い出したのだが、本件でB社のサイト上で6月23日に修理依頼をする際に、シリアルナンバーか、住所が制限文字数を超えている旨のエラーが表示され、どうしても入力内容の最終確認画面に移らず、ブラウザを変えても同じで、仕方なく、住所を県と市までにして、その後の町名番地は故障状況を記入するところに記入し、故障状況の詳細を別紙にて、製品と同梱する旨入力してやっと受付完了した経緯があった。

そのことが気がかりで翌日、確認の電話までして、入力にイレギュラが発生したことを説明し、電話口の担当者に改めて住所を伝えたにもかかわらず、案の定、修理依頼するマシーンを受け取りに来る予定日になると、運送業者から直接電話があり、こちらの住所を教えなければならない面倒が起きた。おそらく、運送業者は、こちらが入力漏れをしたと思っただろうし、手間をかけさせるなと思っただろう。

筆者が指摘したB社のサイトの問題点に対し、その不備の存在を検証したのかは、こちらには分からない。窓口の担当者は、そんなことがあるわけないと聞き流したのかもしれない。事実、問題が起きているのに、それをわざわざ通報しているのに、検証すらしていないとすれば・・・・。

できるなら、今後はB社以外の製品を求めていきたいところだ。しかし、他社の体制がどうかはわからないので悩ましい。B社は、それを認識したうえで強気なのかもしれない。

ついでに、思い出したから書かせてもらうと、パソコンメーカーのD社のサイトはモタモタ感どころかいつもパンク状態でサイトとしての体をなしてない。サポートに出てくる中国語なまりの女性がかわいそうになったのは、もう数年前になる。ハッキリ言って、D社で購入したいと思わない。

（２）　パソコンメーカーの対応は、究極はどこも似たり寄ったり

筆者は、パソコンを販売したりサポートする仕事に携わり何年になるだろうか。Windowsが出る前に、AX機とか、DOS/V機とか、もっと古くは、よく覚えていないがメーカー独自のOS（CP/M）搭載機も扱っていたころからである。

職歴からすると1988年頃からである。三菱、NEC、東芝、富士通、EPSON、HP（Compaq）、Dell、Mac、マウスコンピュータなど時代とともに変化した。今はサイトでカスタマイズしやすいメーカーを扱うようになった。

大きな問題として過去には、ある日突然内蔵ハードディスクが認識されなくなるという問題を抱えたこともあった。最近は、メインボードのリコールでユーザーに5日ほど業務を停止してもらう事態も経験した。この数年、解決しない問題を引きずったままでメーカーの回答待ちの状態が続いている案件もある。大小、枚挙にいとまがない。

これらの問題は、ハズレを引いたと諦めざるを得ない。サポートが長引いてもそのコストをメーカーは見てくれない。また、何年分のデータが蓄えられていようと、完全にメーカーに非があったとしても、メーカーは絶対に内蔵のデータを保証はしてくれない。

ちなみに、昨年の秋口来、Windows10のアップデートについても多数のユーザーで何らかの問題が発生した。中には、正常にアップデートした最後にモニタに何も表示されないという不具合が判明した機種もあった。また、アップデートの途中で何も反応しなくなり、リカバリ領域からの工場出荷段階まで戻すこともできなくなったマシンもあった。

一言で言えば、Microsoftの罠にかかった。というのが筆者の見解だ。Microsoftの戦略に付き合わされその不手際の為に、どれだけのWindowsユーザーが迷惑を被ったか計り知れない。この問題についてのニュースは、6月のある日、夜9時のNHKのニュース番組で見ただけだったが、その時の記者からの厳しい質問に、Microsoftの女性広報スタッフの取り繕った答えにならない答えを返す表情を、今も忘れない。

Windows、iOS、Android、UNIXと、世にスタンダードがいくつもあるのは販売やサポートする側としては学ばなければならないことが多くなるわけで考え物である。しかも、各社のユーザーの囲い込み戦略から派生した中途半端な新技術に付き合わされ、その尻拭いをさせられる側の身になってみて欲しい。この手の問題には特別に電話窓口を用意しているというが、つながったためしがない。

と愚痴を言っても始まらない。すべて人間のいい加減さがなせる業である。だから、旧態依然、どこも似たり寄ったりなのである。

（１）　B社法人向けNAS製品の電源ボタンの陥没癖と、バックアップ失敗の原因の曖昧さ

まず、B社法人向けNAS製品の電源ボタンの陥没癖について

2015年4月時点でのB社の法人向けNAS製品のラインナップの中で、ラックマウント型を除くデスクトップ型すべてにおいて、電源ボタンの仕様構造が同じであるということをメーカーのサポート窓口の方から説明を受けた。

なぜその説明を受けることになったのかというと、簡単に言うと、同じ構造の電源ボタンでは、怖いから異なる電源ボタンを採用した製品はないかを尋ねたかったからである。

なぜその電源ボタンが怖いかというと、類似した不可解な異常現象がその１、2年前から複数の納品先で発生していた状況で、たまたまあるユーザーで何もオペレーションしていないのに電源が勝手に落ちるという現象があり、その現象を確認するうえで手動によるシャットダウンをするときに（通常は、電源ボタンを長押し）、軽くタッチしただけでシャットダウンが始まったことから、電源ボタンが原因で色々な異常現象が起きているのではと直感し、ユーザーの業務を止めるわけにはいかないので、ユーザーにその事情を説明し費用折半で新品の同型機を購入し、データや環境を運用移行し終えた後、その異常の起きていたNASを引き上げ、思い切って電源ボタンの個所を分解（非常に簡単だった）したところ、電源ボタンが陥没して元の位置に戻らずそれが癖になり、内部のスイッチが半押し状態になってしまうことがわかった。手で触れる部分の電源ボタンは、内部で正面に向かって左側から伸びる透明なプラスチックのバネ状のもので支えられ元の位置に戻る構造になっていた。このプラスチックのバネが右側にはないのでボタンが戻る時のボタンそのものとボタンを取り巻く外側との物理的な摩擦や干渉が起きやすいバランスの悪い構造であることがわかった。誰でも判断できる単純な理屈であるから、思わず「仰るとおりですね」と答えた正直な電話窓口の女性もいた。

これらのことをB社サポートに投げかけたところ、他のユーザーからの同じようなサポートや修理の履歴はないとのことだった。しかし、この手の製品は、普通一般的なユーザーは、1台導入していることがほとんどであり、複数台で似たような異常現象を比較できるような環境ではないのだと思う。従って、一般のユーザーから電源ボタンの陥没癖について限定したサポートや修理の依頼があるわけがないのではと思うのである。

また、電源ボタンの内部構造上の欠陥ではないかという指摘に対しては、製品開発段階で第三者機関において基準の品質テストをクリアしている物理的構造であるとの説明で突っぱねられた。

それはそうであろう。大企業が、このようなことについて易々と個人に対し、非を認めるわけがないのである。

直接人命にかかわることではないが、よくよく考えるとNASに蓄えられるファイルは、その企業の働く人たちにとり、ある意味、命にも代えがたい大事なものであるといっても過言ではないのではなかろうか。もしある日突然、過去数年分の全社の提案書、見積書、発注書など基幹業務にかかわる情報が見られなくなったら管理者のストレスは計り知れない。つまり間違いなく人の心労、いわんや命にかかわる問題なのである。その理由を付けて、NITEに通告したが、丁寧にお断りされた上で弁護士に相談するように促されたので、これも経験と弁護士に無料の範囲内で相談をしたが、個人が訴訟することになるらしく、そこまですることもなかろうと諦めた。この時点でやっと、バカバカしさを感じた。

ところで、電源ボタンの陥没癖がついて、こちらで引き取り分解したマシンは、ボタンの陥没癖（内側の摩擦や干渉）がないように削り、ボタンが正常な位置に戻るようにした。その後、自社のファイルの保存をしているが、以来、以前発生していた問題はまったく発生していない。他の複数のユーザーにもこの問題を説明し、電源ボタンでのシャットダウンはしないよう運用を変更していただいたり、あまり必要性のないユーザにも、毎日業務終了時に電源を落とさないようにB社指定のバッテリーとバックアップ用にUSBHDDを導入していただいた。その結果、すべてのユーザーでまったく異常現象が発生しなくなったのである。

 

次に、バックアップ失敗の原因についての曖昧さである。

これも複数のユーザーで、度々経験してきたことで「I54」の対応方法については、B社がサイトで公開している。それによるとバックアップに失敗する原因は例えば、ひとつのファイルの容量制限だったり、使用してはいけない文字だったりとしている。しかし、筆者がそれを試してみて分かったことだが、実際探し出すには膨大な時間がかかり、例えそれを探し当て適正に処置したとしても、結果的にその処置によって解決に至ることはなかった。

B社の対応策は、そのどれも正解なのだろうが、実際、筆者は全く異なることで問題を回避してきた。それは、バックアップ元を小分けにするとか、逆にまとめるとかで回避できたのである。

この問題についてのB社の対応方法は、それが原因になっているかもしれないし、原因になっていないかもしれないという曖昧な対応方法であることを明確に説明していないことに問題がある。サポートの窓口の係りの口調からもこの問題に対する説明はとても歯切れが悪いと感じる。おそらく人類のこの分野（ファイルシステム）に対する未解決の難しい問題なのだろう。