none
フォーラムへの回答方針について RRS feed

すべての返信

  • フォーラム オペレータの権限でスレッドを分割するのであれば、過去の経緯が分かるように体裁を整えるのも、フォーラム オペレータの責務では?
    それとも私に、過去の経緯の説明責任があると?
    (いまさらそんなめんどーなこをしたくないし、過去から経緯を考えれば、まともな回答が得られるとも思えないし、参加者を余りにも馬鹿にしている。。。。もっとも指摘されるまでもなく、私は「お馬鹿」ですけど。)
    2017年11月15日 8:25
  • お馬鹿 様

    いつもお世話になっております、立花です。
    掲題の件につきまして、貴重なご意見をいただき誠にありがとうございます。
    また、不快な思いをさせてしまいましたこと、大変申し訳ございませんでした。

    本件の経緯といたしまして、お馬鹿様より以下のご意見を頂戴いたしました。

    > 回答でもない返信を回答候補にしたり、回答として明らかに間違ったものを回答としてマークしたり、はたからみてやりたい放題のようにみえます。
    > 少なくとも、私はこのスレッドで「回答候補」になるような投稿はしていません。

    それに関しまして、私より以下の返信を行っております。

    > 回答者からお寄せいただいた回答について、オペレーターの回答の候補に設定する基準としましては以下となります。
    > ①. 資料等の参考となる情報があり、質問者の問題解決に繋がると考えれるもの
    > ②. 回答者が実際に検証し、質問者の問題を解決した結果および方法
    > ③. ①、②以外で問題の解決に向かうための調査アドバイスで原因解明の切り分けになるもの

    上記について、お馬鹿様より改めて以下のご意見を頂戴しておりました。

    > ① 問題解決に繋がると考えれる、資料等の参考となる情報は提示していない
    > ② 本件に対して私は実際に検証していないので、質問者さんの問題を解決した結果も提示してない
    > ③ 私の知り得る知識でアドバイスはしたが、それが「原因解明の切り分けになるもの」であるかどうかは、現状では不明 (ただし私は「原因解明の切り分けになるもの」と思っている)

    あくまでも私共の見解ではございますが、メモリアクセス違反に関して、お馬鹿様の以下の投稿は質問者様の “MSVBVM60.DLLの最新バージョンの適応で解決できる可能性があるのでしょうか?” というご質問の回答に十分なり得るものと判断しております。
    技術的にはお馬鹿様が一通り記載されておりますため、大変恐縮ではございますが特に追加して申し上げることはございません。
    メモリアクセス違反について、ダンプファイルから調査を行った場合の見解として、妥当かつ有用なものと判断しております。

    > msvbvm60.dll モジュールの問題とお考えのようですが、多分違うと思います。
    > "STATUS_ACCESS_VIOLATION" のエラーが発生したときに処理していたのが、たまたま "msvbvm60!IID_IVbaHost+2c021" だっただけで、問題は別のところにあると思います。
    > どーいうことかというと、メモリ上のコードあるいはデータを破壊するモジュールが別に存在していて、そいつが壊したメモリ領域にアクセスしたのが、たまたま "msvbvm60!IID_IVbaHost+2c021" の処理だった、ということだと思います。
    > (そもそも msvbvm60.dll の問題であるなら、障害事例が多数報告されているはずだし、既に修正モジュールが公開されているはず。)

    また、以下の Application Verifier のご紹介につきましても、メモリアクセス違反ではよく利用されるツールですので、問題解決につながる可能性がある資料と判断しております。

    > Verifier (AppVerif.exe) で "xx_10.exe" プロセスを検証すれば、メモリ破壊が発生した瞬間をキャッチできると思います。
    > ---------------------------------------------
    > Windows SDK ツール:Application Verifier のご紹介
    > https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2011/05/29/windows-sdk-application-verifier/
    > ---------------------------------------------

    これまでの投稿からもお馬鹿様は非常に高い技術力をお持ちであるように見受けられ、質問者様および閲覧者様の参考になるものと判断して回答候補および回答としてマークをつけさせていただいておりました。
    本件以外にも多々気になった点があったかと存じますが、頂いたご意見を基に、弊社オペレーターにて改めて回答候補および回答の基準を検討することで改善を測って参ります。

    以上、今後とも何卒よろしくお願いいたします。


    MSDN/TechNet Community Support 立花楓

    2017年11月16日 0:13
    モデレータ
  • チャブーンです。

    ありていにいうと、お馬鹿さんがオペレーター全般に不信感を持たれていると理解しています。なぜそんなことになっているのか、についても(この件とは関係なく)他のコミュニティを含めた過去の経緯はなんとなくですが、理解しているつもりです。

    「参加者を余りにも馬鹿にしている」の具体的な内容が、私には思いつかないのですが、回答の候補の評価の違いをいっているのでしょうか?

    このコミュニティでは、はStackOverflowやteratailといった純技術サイトとは違い、閲覧者(スレッドに注視している人)が評価するしくみはほぼ機能していません。それを代替するため、オペレーターが回答候補をつけているわけです。

    回答候補は回答マークとは違い、(すくなくともこのサイトでは)かなり軽い概念だと思っています。ありていに言えば「第三者から見たら、正しい方向に向かっているように見える」すべての応答が回答の候補、というところかと思います。その中で、終着点になったものや最も「落としどころ」に近づいたものが、回答になる、ように見えます。

    技術者はすべての技術に網羅しているのではないため、技術の理解度に濃淡があります。それをふまえ、私の場合ですが、文章の論理構成や進行状況から、正答が完全に判断できない状況でも「落としどころ」に向かっているかを判断して、回答の候補をつけることがあります。

    ここで注意することは「落としどころ」であり、正答でないことは留意いただきたいです。質問者と回答者の技術的バックグラウンドの違いや、解決のゴールの認識がそもそも違うことで、互いの「正答」がそもそも共有できないからです。この状況では、残念ながらある種の妥協を行い、情報伝達を優先する必要があります。

    質問者さんに「回答者の考える正答」を理解してもらい、そこに導く...のは、満足度の高い仕事かと思いますが、そのためには質問者と回答者が「がっちりスクラムを組んで」テーマを共有し続ける前提が必要で、たくさんの質問者に対応し続けることと両立はできません。私個人はそんな状況をふまえ、この方法では回答していません。

    お馬鹿さんが後者の方法(正答に導く)で対応したいということであれば、それは尊重されますし、元ネタのスレッドもその流れで「静観」されたのではないでしょうか?他人は気にせず、ご自身の思うところで回答すればよいと思いますので、気にしすぎることはないように思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2017年11月16日 2:45
  • > あくまでも私共の見解ではございますが、メモリアクセス違反に関して、
    > お馬鹿様の以下の投稿は質問者様の
    > “MSVBVM60.DLLの最新バージョンの適応で解決できる可能性があるのでしょうか?”
    > というご質問の回答に十分なり得るものと判断しております。

    現在までに "ぴーまん" さんから提示して頂いたアプリケーション ログ等の情報から、提示されている私の投稿は「回答に値しない」可能性の方が高いことが判明しています。
    2017年11月8日 5:52 に、"ぴーまん" さんから頂いた情報によれば、「複数回発生している機械のアプリケーションログ内には4つ発生していて例外コードオフセットは同一です。」とあります。
    つまり「"STATUS_ACCESS_VIOLATION" のエラーが発生したときに処理していたのが、たまたま "msvbvm60!IID_IVbaHost+2c021" だっただけ」ではなく、常に "msvbvm60!IID_IVbaHost+2c021" 近辺の処理をトリガとして "STATUS_ACCESS_VIOLATION" のエラーが発生していると考えた方が妥当です。
    さらに複数の AppCrash ログが同じである点を考慮すれば、本件はメモリ破壊ではなく、特定のタイミングで不正なパラメータ設定が行われた可能性の方が高いと、私は考えています。
    この場合、Application Verifier でのチェックはあまり意味がなく、それよりはダンプ解析とライブ デバッグを組み合わせた調査を行った方が、より効率的であると思っています。
    ですが現状においてそれらは全て推測であり、なんの確証もありません。
    そもそも "ぴーまん" さんの問題は、解決のための原因究明にすら至っていないのですから、私の返信は回答候補になどなり得ません。

    私は回答のマークは質問者さん自身が行うべきであり、かつできるだけ絞って行うべきだと思っています。
    現状では、フォーラム オペレータさんやモデレータさん達がそれを「代理」で行っているようですが、ちょっとでもそれらしい「雰囲気のある」返信であれば、迷わず「回答候補」あるいは「回答」としてマークされてしまっているように見受けられます。
    回答内容の主旨が同じであるなら、それも許容されるかと思いますが、明らかに異なる主旨の内容が、同時にマークされているケースも多々あるように思います。
    (以前にもそのような理由で、私は自身の投稿にマークされた「回答候補」を、フォーラム オペレータさんに外していただいたことがあります。)
    ですが、これでは後から参照される方は、たまったものではありません。
    どれが正しく、どれが違うのか、まったくわからないスレッドが量産され、フォーラムの意義がカオス状態に陥っているように見えます。
    (さらにひどいスレッドでは、明らかに間違った返信が回答してマークされ、正しい返信がノーマークとなっています。)

    何が言いたいのかというと。。。
    マイクロソフトさんが自分のお金を使って、正しくない。。。つまり間違った情報を垂れ流しにして、いったい誰の徳になるのか、ということです。
    例えば、マイクロソフトのエンジニアさん達は、マイクロソフト コミュニティのあの悲惨な状況を見て、何も疑問を感じないのでしょうか?
    私から見れば、自分たちの評判を落とすためのフォーラムやコミュニティを自分たちで運営している、つまり自分で自分の首を絞める「自殺行為」にしか見えません。
    マイクロソフトさん自身がそれで構わないなら、私が口を挟むことではありませんが、一部参加者からの『あなたの回答は有害無益だからこれ以上返信するな』だの、『「趣味の回答」しかできないのであればスタックオーバーフローにでも投稿していてください。』などの暴言を削除するだけで、本質的な問題が全く解決されない状況には、ただただ残念に思うのであります。
    (だからあまり見ないようにしているのですが、自分の仕事で事例等を検索しているときにここにヒットしてしまうと、ついつい覗いてしまうのです。)
    2017年11月16日 3:28
  • oooohです。

    傍から失礼しますが、

    > 回答でもない返信を回答候補にしたり、回答として明らかに間違ったものを回答としてマークしたり、はたからみてやりたい放題のようにみえます。

    こちらのような振る舞いは私も感じます。

    モデレーターさんにもよるかと思いますが、

    栗下 望氏に特にそういう傾向を強く感じます。

    「回答候補にマーク」をすることで質問者の意図しないところで

    「落としどころ」を決めつけられてしまうのでは誰得ですし、

    そもそも「回答候補」は必要ですか?

    「投票」でいいんじゃないですかね。

    2017年11月16日 5:45
  • フォーラム オペレーターの立花楓です。

    貴重なご意見をいただきありがとうございます。

    いただいた内容を基にオペレーター間で対応を検討させていただいております。

    よろしくお願いいたします。


    MSDN/TechNet Community Support 立花楓

    2017年11月17日 8:49
    モデレータ
  • お馬鹿さん、こんにちは。
    フォーラム オペレーターの立花です。

    いただいたご意見をもとにオペレーター間で検討いたしました。

    お馬鹿さんがおっしゃる通り、[回答としてマーク] の設定につきましては、
    質問した方がご自身で参考となった回答に行っていただくことが望ましいと考えております。
    そこで、オペレーターの対応といたしましては、有用な回答が行われたと判断した際には、
    積極的に [回答としてマーク] の設定をお願いしていきます。
    また、投稿した方の目につくように、例えば私共の署名などでもお願いしていきます。

    もし今後も気になることなどございましたら、お気軽にご意見をくださいますようお願いいたします。



    MSDN/TechNet Community Support 立花楓


    2018年1月24日 7:24
    モデレータ