パスワードを忘れた? アカウント作成
792820 journal
日記

tamoの日記: しつこく続ける、「ではない」の話 4

日記 by tamo

本筋と関係ない例で盛り上がってしまったので仕切り直して、
「××ではなく○○」の話。

というのも、「××ではなく」を付けるだけで説明が劇的に変わるというのは、
文面だけで直感的に分かるものではないから。

たぶん実際に使ってみると理解できると思うけど、
パンダを説明しようとするときに「焼きそばではなく」からスタートする人はいない。
むしろ「ヒグマではなく」から近付けていくはず。

だから「××ではなく」を使おうとした途端に自然と、
「似て非なるもの」を探しはじめるってこと。
これが一点。

別の実例。

「えー、味噌ラーメン知らないのー? 味噌が入ってるラーメンだよ。名前でわかるじゃん」

これだと、説明する側はじゅうぶん教えた気になってるけど、
聞いてるほうは、自分の知ってるラーメン (たとえばカレーヌードルかも!)
にそのまま味噌を足したものを想像しているだろう。
それがたまたま塩ラーメンだったらいいんだろうけど。

「じゃあ塩ラーメンは知ってる? それも知らないのかぁ。
なに、カレーヌードルしか食べたことないの? 麺はそれと同じ感じだけどさ。
カレーは入ってなくて、ていうか豚汁のほうが近いかな。
でもダシと味噌だけじゃなくて以下略

だから「××ではなく」の××を探すにあたって、
相手のバックグラウンドを自然と考慮に入れるということ。
これが二点目。

つまり説明しようと思ったときの視点が既に違ってくる。

……!!

ということは、バグ報告のようにエスパーが必要になりがちな場面では、
「できるだけ詳しく症状を書いて」というよりも
「『××ではなく○○』と書いて」と求めたほうが良いのかもしれないな。

戻るボタンがしいたけに見えるんです [ネタかと思われる]
↓(できるだけ詳しく)
ブラウザの左上にある、一つ前のページに戻るためのボタンが、岩手産の干ししいたけのように見えて困るんです [食欲が湧くことが問題だと思われる]
↓(ではなく!)
矢印ではなくしいたけに見えて困るんです [非直感的な UI の問題だと理解してもらえる]

もちろん報告フォームのテンプレにも
「いつも再現しますか」とか「設定リセットしてもなりますか」とかいう
絞り込みの質問を付けておくべきなんだけど。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 例:
     「今までのM2のようにModerationを評価するのではなく、新しいM2 ではコメントそのものを評価するのです」

    この説明は「今までのM2」に対するイメージがあるからこそ、それではない、という指摘に価値が出ます。
    しかし「今までのM2がどうであったのか」が判らない人にとって、これは良くても無駄な文字列で、悪いと混乱のもとにしかならない。

    ようするに、読む相手の背景知識が予測できない(複数の読者を想定しなくてはいけない場合も、この条件に合致する) のに「not A but B」的な説明をすると、むしろ混乱を招くからやめろ、という「明瞭な文章を書く上での技法」があるのだが、それに反するべき理由は何? ということなのだが…

     

    逆の例として「味噌ラーメン」の例:

    「えー、味噌ラーメン知らないのー? 味噌が入ってるラーメンだよ。名前でわかるじゃん」

    例えば料理人相手の場合、これで十分だったりする。

    1. 「まずいものをわざわざ作って、それがヒットするわけはない」という大前提を理解していて、
    2. なおかつ、「味のベースを味噌味にする」ならどのようなラーメンがあり得るか?という想像から入れる人

    にとっては、むしろ「not A, not B, not C…」というのは、理解の上でも、新しい何かを思いつく上でも、邪魔でしか無い。

    基本的に「not X」で範囲を狭めて理解を助けるのは、対話型の環境で、なおかつ相手が「それって X みたいな感じ?」と自分が知っている範囲を提示してきた場合に限定するべき。文章のように非対話型の環境では、「not X」は、本当に X を期待できる状況に限り、その X がなかったことを述べる場合に記述するのに限定したほうが良い。

     

    これは障害発生時のレポートの大半について、同じことが言える。

    障害を解析する時に、ほんとうの意味で信頼できるのは、ログだけだ。だからログは「勝手に絞りこまずに」全部持って来い、と命令する。ここだけはまじで命令する。勝手に範囲を限定するな、と。
    勝手に「範囲を限定できる」ぐらいモノを知っているというなら、その場で問題を解いてこい、判りもしないのに勝手に「これはいらないだろう」とか判断するな、と。
    その勝手に捨てた情報の有無で、判断が 180度ひっくり返ることだってあるのだから。

    このような「情報の絞り込み」は一種の not A で、実は『問題が解けない』人たちの多くは、この「勝手な not A という思い込み」のせいで、見るべき場所を間違っているから、問題が解けない…ということが多いのだ。

    --
    fjの教祖様
    • 「戻るボタンがしいたけに見えるんです」のくだりがどこまで行ってもネタにしか見えないのは、報告を受ける側(を想定した自分)に「しいたけに見えるのは戻るボタンではなく中止ボタン」という「勝手な not A という思い込み」があるせい。

    • 例:
       「今までのM2のようにModerationを評価するのではなく、新しいM2 ではコメントそのものを評価するのです」

      この説明は「今までのM2」に対するイメージがあるからこそ、それではない、という指摘に価値が出ます。
      しかし「今までのM2がどうであったのか」が判らない人にとって、これは良くても無駄な文字列で、悪いと混乱のもとにしかならない。

      ようするに、読む相手の背景知識が予測できない(複数の読者を想定しなくてはいけない場合も、この条件に合致する) のに「not A but B」的な説明をすると、むしろ混乱を招くからやめろ、という「明瞭な文章を書く上での技法」があるのだが、それに反するべき理由は何? ということなのだが…

      そうですね。そこは両者を天秤にかけるしかないかも。
      そっかー、そうすると、なんでもかんでも「××ではなく」で書け、とは言えませんね。
      でも、その方式で書けないかな、と考えることで、
      (ふだん説明が苦手な人でも自然と) 相手の理解状況を想定して
      それなりに説明できるようになるのではないかと思います。

      つまり、教祖様のように
      「旧 M2 を知ってる人にも知らない人にもわかるように説明したい」
      と考えることができちゃう人には私の提案なんぞ無用ということです。
      説明するにあたって相手の知識範囲を想定すべきだということが
      身についてない (私のような) 人には役に立つんじゃないかと。
      それでも常に害のほうが大きい、という主張では、ないですよね?

      で、M2 の話で言うと、複数のバックグラウンドを想定するとやはり最初には
      「コメントをダブルチェックしてもらいます」みたいに「○○である」で書いて、
      そのあとに「注意: 以前の M2 とは違い、モデの可否を直接判定しなくなりました。
      M1 とあなたの判断が合致しているかどうかで自動判定されるようになってます」
      みたいなことを付け加えるしかないのですかね。長いなぁ。ショボーン。

      逆の例として「味噌ラーメン」の例:

      「えー、味噌ラーメン知らないのー? 味噌が入ってるラーメンだよ。名前でわかるじゃん」

      例えば料理人相手の場合、これで十分だったりする。

      1. 「まずいものをわざわざ作って、それがヒットするわけはない」という大前提を理解していて、
      2. なおかつ、「味のベースを味噌味にする」ならどのようなラーメンがあり得るか?という想像から入れる人

      にとっては、むしろ「not A, not B, not C…」というのは、理解の上でも、新しい何かを思いつく上でも、邪魔でしか無い。

      おっしゃるとおり、知識と理解力のあるかたにはそういう説明は邪魔ですね。
      でも私 (および、この日記から受益しそうな読者 if any) が
      そういう賢者に何事かを説明することはまずないと思って気にしてませんでした。

      基本的に「not X」で範囲を狭めて理解を助けるのは、対話型の環境で、なおかつ相手が「それって X みたいな感じ?」と自分が知っている範囲を提示してきた場合に限定するべき。文章のように非対話型の環境では、「not X」は、本当に X を期待できる状況に限り、その X がなかったことを述べる場合に記述するのに限定したほうが良い。

      そこまで限定しちゃいますかぁ。
      でもまあ、誰でも知ってる「似て非なるもの」から削っていくのは大切なことですね。
      うーむ、最初に思ってたよりも、使える条件が厳しいな。

      これは障害発生時のレポートの大半について、同じことが言える。

      障害を解析する時に、ほんとうの意味で信頼できるのは、ログだけだ。だからログは「勝手に絞りこまずに」全部持って来い、と命令する。ここだけはまじで命令する。勝手に範囲を限定するな、と。
      勝手に「範囲を限定できる」ぐらいモノを知っているというなら、その場で問題を解いてこい、判りもしないのに勝手に「これはいらないだろう」とか判断するな、と。
      その勝手に捨てた情報の有無で、判断が 180度ひっくり返ることだってあるのだから。

      このような「情報の絞り込み」は一種の not A で、実は『問題が解けない』人たちの多くは、この「勝手な not A という思い込み」のせいで、見るべき場所を間違っているから、問題が解けない…ということが多いのだ。

      ほんとですね。
      情報を加えるどころか減らす方向での not A は
      (障害レポートにおける) 諸悪の根源と言っても過言ではないかも。

      だから単に「not A but B 方式でお願いします」ではうまくいかないでしょうね。
      結局は上手に誘導しなきゃだめか。

      いやー色々とご指摘ありがとうございます。こうやって、私の
      「『××ではなく○○』で何でもうまく説明できるぜ俺天才!」
      という思い上がった「○○である」に対して教祖様の
      「相手の背景知識を予測できない場合にではなく、また
      相手がじゅうぶんに知識や読解力がある場合にではなく」
      を付けることで、ずいぶん明瞭になった気がします。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...