.
.
H氏からの手紙
January 1998 MACお宝鑑定団 
counter

claris

NIFTYで小川氏が公開した、クラリス社とのサポートに関するディスカッションの内容です。新たなオリジナル投稿として、御本人から送っていただきました。


ファイルメーカpro3.0を仕事で使っています.フィールド定義でStatus関数を使った場合その動作がおかしくなることに気が付かず使ってしまったためにトラブルを起こしてしまいました.

ファイルメーカのマニュアルC−18では
  》ステータス関数はスクリプト定義内でデ−タベ−スの
  》ステータス(状態)を調べるために使用します.

ヘルプでは
  》ステータス関数は、 スクリプト 内の制御ステップと
  》組み合わせて使用するのが一般的です

となっていて,フィールド定義で使用してはいけないことやその注意点は記載されていませんでした.フィールド定義の計算式の設定ではStatus関数が出てきますので,私のように気にせずに使ってしまうケースがあるはずです.

これに関してクラリスと以下のようなやり取りを行いました.その様子をできるだけ客観的にやり取りの流れを記するために詳しく述べます.
登場人物は3人います.

クラリスAさん・・・FM2.1の不具合の交渉で,ユーザに必要な
          情報やアップデータを通信を使って配布
          しろと要求したとき,すぐにはできないが
          待って欲しいと回答した人.元サポート

    Bさん・・・クラリスコールセンターのサポート

    Cさん・・・クラリスコールセンターのサポート
          
===========やり取りの記録=============

■4月23日  クラリスAさん宛FAX  小川発信
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 いつぞやはたいへんお世話になりました.A様がお話になったように,WWWでのサービスなど,サポートの改善が見られ喜ばしく思っています.

 さて,ファイルメーカpro3.0についての質問なのですが,計算式でStatus(対象レコード数)としてフィールド定義し検索したとき,その数に異常が見られました.Status(対象レコード数)というのは検索しているデ−タ数をカウントするものですが,それが検索結果件数とはあわずに,前のままの数字になります.ファイルメーカpro3.0v1,V2,V3で同じようになります.ちなみに,計算式の索引で値を非保存にすると正常に表示されました.
 これはStatus(対象レコード数)が,検索がおこったら計算しなければならないというトリガーをうまくとらえていないことが原因と推測されます.非保存にすると,それが表示の際に計算されるのでうまくいくのではないでしょうか.

 英語版V3のReadmeには
The following summarizes the fixes and feature enhancements
made to the FileMaker Pro 3.0v3 program:
・ Problems with calculations have been corrected, including:
- Incorrect results with the Extend, IsEmpty, and some Status
functions
と書かれていますが,このことを示しているように見受けられます.

 同じ現象がStatus(レコード番号)にも見られますが,これらはバグですか?
 
  ------------------------------------------
  

4月25日になっても返答がないのでAさん宛に電話.「会議中なので技術的な話ならクラリスコールセンターに電話しろ」とのことだったのでラリスコールセンターに電話,Bさんが対応しました.それによると,


1.ステータス関数はスクリプト定義内で使うものである
2.フィールド定義で使うとフィールド定義直後の値になる
3.フィールド定義で使ってはいけないとはマニュアルには書かれていない
4.今後マニュアル・ヘルプ等で注意を喚起したい
5.当分の間現ユーザについては何も知らせない
とすらすらと答えてくれました.かなり苦情があったみたいです.

このくらいで簡単に引き下がる私ではないので,インターネット上で注意喚起などを行ってはどうかと提案しましたが,「私ではなんとも言えない」とあっさり言われてしまいました.1サポートがそんなこと確約できないのは百も承知なので,米ClarisのWWWやメーリングリストの話や会長さんの発言などを並べ立て,まくしたてておきました.サポートの方に電話でいくら建設的な話をしても,会社の体質が変わるともおもえませんので,適当なところで切り上げてきました.


■5月6日  クラリスAさん宛FAX  小川発信
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 4/23日にFAXをお送りした上記の件について,確認の電話をA様宛に4/25日にしたところ,会議中とのことで,「技術的な話ならクラリスコールセンターの方へしてくれ」とのことでした.
 そこで,クラリスコールセンターに電話したところ,Bさんに対応していただき,技術的なことは確認できましたので,より上位な質問として再度FAXをお送りします.

  それによると
1.Status(対象レコード数)などのStatus関数をフィールド定義中で使用すると値がフィールド定義時にしか変更されない.
2.ヘルプやマニュアルにはStatus関数をフィールド定義中に使うことの禁止やその場合の注意については書かれていない.
3.次期バージョンでこれについての記載の変更を検討する
4.現時点でのユーザへの注意喚起はとくに行わないということでした.

 私が,こういうことに関してユーザの注意を喚起しないと,ユーザが損害を被る(事実私はトラブルを抱えました).変更したヘルプのインターネットや雑誌での配布,Q&A集配布,インターネットホームページ上での注意喚起などコストと時間をかけないで,ユーザに注意を喚起する方法を講じてよいのではないか.と提案したところ,「1サポートでは返答しかねる」とのことなので,A様にそうしたことをクラリスはしていくつもりがあるのかどうかうかがいたいのです.

 ついでに米ClarisのWWWでStatus関数を調べると,
  http://www2.claris.com/forms/techinfo-search.htmlに
  》Status Functions in Calculations Do Not Update
  》TechInfo ID: ALSMI95355
 ときちんと情報が公開されています.

また,米クラリスのCEOの発言で,日本のクラリスの販売数がアメリカを瞬時的に越えたので,日本の市場を大切にするという趣旨の発言があったと聞いております.そこで,繰り返してお願いしますが,Status関数のようなユーザが誤操作しやすいものに関しては,インターネット等を通じて情報提供をしてください.
 前向きのご返答をお待ちしています.

  ------------------------------------------

■5月6日  クラリスAさんよりFAX
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
【要約】
1.Aさんの仕事内容が変わった
2.クラリスコールセンターから電話を入れたが,小川が不在で行き違いがあった
3.さて,拝受いたしましたFAXの内容につきましては,弊社への貴重
なご意見として今後の参考とさせていただきます.

  ------------------------------------------

このFAXで初めてAさんの仕事内容が変わったことを知りました.しばらく別の回答がくるかと待ったがこないので,再びFAXを送りました.


■5月11日  クラリスAさん宛FAX  小川発信
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 5/6日にFAXをお送りした上記の件について,FAXをいただきありがとうございました.部署をかわられたとのこと,たいへん失礼しました.新たな部署でよりよいクラリスになるようがんばってください.

 さて,5/6日のFAXでお尋ねした内容については,以前からお願いしていますことなので,「1サポートでは返答しかねる」とか「ご意見をうかがっておきます」とかいったご返答ではなく,きちんとしたご回答をしていただきたいと考えております.そこで,対処できる部署にFAXを転送するか,必要なら私が再度その責任者にFAX致しますので,FAX番号や責任者のかたのお名前をお教えください.

 お忙しいとは存じますが,よろしくお願いいたします.

  -----------------------------------------


■5月14日  クラリスCさんよりFAX
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
【全文】
拝啓平素はクラリス製品をご愛顧いただき,また今回はご意見いただきありがとうございました.今後検討していく上で,お客様のご意見として参考にさせていただきます.今後ともなにとぞよろしくお願いいたします.

  -----------------------------------------

上記FAXを受けクラリスCさんに電話,以下内容要約.

小 川:きちんとした回答が欲しい
C  :ご意見はうけたまわっておきます

小 川:今回の件は前々からお願いしていることなのでなにか
    やっているのでは
C  :言えない

小 川:ではサポート法の改善として今までなにを検討してきたのか
C  :言えない

小 川:あなたの上の方に変わって欲しい
C  :私がこの件の責任者である

小 川:サポート全体のコーディネートもあなたがまとめているのか
C  :そうです

小 川:サポートのやり方を検討するチームは何人くらいいるのか
C  :言えない

小 川:米国のWWWサポートと日本のサポートの違いはなぜ?
C  :日本と米国では組織が違う

小 川:今後米国のWWWサポートのようなことをやる意志は?
C  :もろもろのことを検討している段階で明言はできない

小 川:今回のようなユーザにしらせるべき情報はどのようにして伝え

    るつもりか
C  :次バージョンのマニュアルで記載したい

小 川:現バージョンのユーザには?
C  :具体的には無い
小 川:WWWで技術情報を載せることは最も簡単でコストも時間
    もかからないが,なぜ実現しないのか?
C  :それほど簡単なことではない
    現在ユーザからもろもろの要望があがってきている.そ
    れを優先順位をつけて処理している.
小 川:そのなかで具体的に実現したことは
C  :回線数を増やすこと
小 川:回線数を増やすことはお金も時間もかかること.できる
    ことをやるのが良いのでは
C  :できるだけたくさんの人に伝わる方法を検討している
小 川:いろいろな方法で伝えるべき.いつまでたっても検討し
    ているではダメ.こちらのアクションに対して,きちん
    と実績を示して欲しい
C  :....

小 川:それでは,この件に関して,これからどう検討して,いつ
    ころご回答いただけるのか
C  :状況は変わるので,言えない

小 川:(らちがあかないので)この件に関して再び検討してFAX
    で回答してくれ
C  :内容は同じだがそれでもよいか?
小 川:検討した上での回答ならそれでも仕方がない

以上ようなことを私はじっくり話しました.


■5月14日  クラリスCさんよりFAX
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
【全文】
拝啓 お電話いただきありがとうございました.小川様のご意見は今後検討していく上で参考にさせていただきます.今後ともなにとぞよろしくお願いいたします.

  -----------------------------------------

マニュアルの制限付き保証と放棄の中に下記のような下りがあります.

》どのような状況においても,ソフトウェアと付随する文献
》の使用により生じた結果として,または故意に,あるいは
》間接的なダメージをうけたとしても(利益の損失,業務の
》中断,業務情報の紛失などを含む),Claris,または,そ
》の開発者,管理者,事務員,その他関係者は一切の責任を
》負いません.
使用許諾にも同様のものがあったと記憶しますが,これにより,メーカは守られています.

別に私はサポートをいじめて楽しんでいるのではなく,ちょっとヘルプファイルに記述を加えたものを配布するとか,AppleのようにQ&A集を配布するとか,アップデータのお読みくださいに注意書きを添えるとか,そうしたコストをかけずに,ユーザの誤操作をよりすくなくする方法があるのだから実施すべきだよと言っているだけです.

ユーザの権利を守るためにはきちんと声を上げていくことが必要だと思っています.

 1997/5/17        小川 誠


.
.
Copyright (C) 1998 Mac Treasure Tracing Club. All rights reserved.
Site design by BRESTO, Inc.