日系パワハラのいわゆるブクマスパム問題の正しい突っ込み方

人気急上昇中のブログ「日系パワハラ」が、アクセス数を稼ぐためにはてなブックマーク上でランキング操作行為をしているのをtemtan氏が発見しました。

通常であればこれは日系パワハラが大炎上し公式謝罪へという流れになりそうなところが、今回どうも様子が違う。
temtan氏と日系パワハラ側のやりとりがまとめて公開されているのですが、
http://togetter.com/li/541121
野次馬の感想コメントではむしろtemtan氏が粘着SPAM扱いされたりしていて、五分五分どころか、本来の正義の在処からすれば劣勢になってしまっています。

僕も実際こういうコメントを残していますね。

「考えが整理されていない」と大見得を切ってしまった以上、自分なりに整理してみせるのは義務かと思い総括させていただきます次第。

とはいえその後の流れ。

日系パワハラはその後の記事で

一部ツイッターユーザーの方から、ブログ製作者側が自分のブログをはてなブックマークすることは違法行為であると指摘されました。めんどくせーので今後、自分のブログをブックマークすることは辞めます。

http://nikkeiph.com/overtime/

とむしろ面倒なクレーマーに絡まれてしまった被害者的スタンスをとってさらに優勢に（非難するコメントも来ているものの）。

そしてtemtan氏側は、追い込むはずがむしろ釈明的なブログ記事を出す羽目になります。
http://d.hatena.ne.jp/temtan/
これはこれで、数字という証拠をきっちり集めていて労作だしはてなブックマークに対する問題提起としても重要だとは思うんですが。

とはいえこれで外野の支持は傾いたか。ブックマークコメントを見る限り微妙ですね。

どうしてこうなった

この記事でも「いわゆる」とつけていますね。「スパム」という言葉をいきなり使ってしまったところが急所となっていたと感じます。

これによって、「スパムの定義とは？」「勝手に定義したスパム認定で中傷するの？」という寝技にもつれこんでしまった。

実際、ウォッチャーの皆さんのコメントを見てもブックマークスパムの定義に関心が行ってしまっているものも多々見受けられました。

こう整理したかった

スパムとは何なのか。スパムならば悪なのか。

そういう話ではないんです。
はてなブックマークが他のブログランキングと違うところは多数のユーザーのブックマーク行為から注目度を自動でランクづけているところであって、それが魅力と信頼性の根源になっているのだから、それを損なう意図的な操作行為はユーザーとして見過ごせないのです。
そして、はてなブックマークの魅力を毀損することは、それをアクセス源にしているブログ側にだって結局損なのだからやめてもらわないといけないのです。

そこを突くべきだった。初手で「スパム」という言葉を使って事実に曖昧な名前をつけてしまったところがすでに失着だったと考えます。

正しくは

  • 「日系パワハラの記事のブックマークは不自然に操作されている形跡がある」
  • 「関係者3人で一斉にブックマークすれば新着リストのトップにいきなり入ることは理解の上で、操作行為をしていたことをお認めになるわけですね？」
  • 「他の大手サイトのことは話していません。あなたがたが操作行為を意図的に行っていたかを問うています。何の問題もないとお考えでしたか？」

この辺までの問答でtogetterでまとめる。これで世論はこっちのものだった。

ここまでやってからからなら最後にクロージングとして「スパム」という言葉を使っても良くなります。すでに定義は文脈上きっちりなされたので。

教訓として

追求側。評価よりも、それを構成する事実と考察を中心に攻撃を組み立てないと思わぬ泥仕合に引きずり込まれます。
対応側。寝技を使えるようになると予想以上に粘れます。

慣用句の解釈2題：「風上にも置けない」「気の置けない」

雑感

このネタすでに書いてるだろうか。でもチェックするのも面倒なのでこのまま書いてしまう。

置けないつながりってわけじゃないんですが、この2つの慣用句、表現に納得がいかない2巨頭なんですね、僕の中で。

「気の置けない」

まず「気の置けない」。若者が誤用しているけしからん的な例に挙げられるトップ3に入る言葉だと思うんですけど、実際仕方ないと思いますよね。だって「置けない」という不可能表現である以上悪い意味としか考えられず、そうすると語感から「気を許せない」ぐらいの意味ではないかと類推するのはわりと自然な思路。

この表現、「可能動詞はれる・られるの複数の意味のうち可能の意味だけに限定したもの」という原則の数少ない例外なんですよね。可能動詞のくせに自発の意味、「気を置こうという気が起きない」なんだ。だから「遠慮のいらない」という意味になる。

でもやっぱり可能動詞は可能の意味だけで使いたい。だってそのせいで、ら抜き言葉が便利に使えるわけでしょ？　気持ち悪いので個人的には「気の置けない」は避けてますよ。

「風上にも置けない」

タイトルの順と本文の順が逆になった。まあいいか。

「風下にも置けない」が正しいんではないか？　とずっと思ってました（ちなみにこう入力するとATOKには怒られる）。
「も」を使う以上は、許せない第一段階、第二段階があるってことじゃない。「風上には当然置きたくない。いや風下にだって置きたくない」となれば「風下にも置けない」です（また怒られた）。

まあ、これはあまり感覚レベルで受け入れられないんだけどこう考えるしかないのよね。



「風上に置けもしない」が「も」の移動で「風上にも置けない」に変化した姿であろうと。

「空も飛べるはず」は自然に受け入れられるんだけどこちらの違和感は、うーん、なんなんだろうね。

フェルミ推定を問われたらこう答えたい

雑感

その具体的な奇問については“飛行機の中にいくつゴルフボールを積み込むことができるのか？”“マンハッタンにはいくつのガソリンスタンドがあるのか？”など。しかし、グーグルが奇問で行った「選抜」について分析をおこなったところ、まったく効果がないことが分かりグーグルとしては現在、採用試験に奇問はやめたとのことです。

Google「入社試験の“奇問”は時間の無駄だった」

流行らせた当のGoogleが意味なかったと面接で聞くのやめてしまったフェルミ推定ですが、惰性とかありますしまだまだ聞かれる機会は多い気がするんですよね。

そういう場合は、こんな感じの答え方で自分の小賢しさと面倒くささを全面的にアピールできればと思います。

  1. まず時間を稼ぎつつ推定方法を2つ以上ひねり出しておく
  2. 「このような推定をするとき、実務ではなからずもう一つ条件があると思うのです。多すぎる見積もり違いと少なすぎる見積もり違いのどちらが致命的かです。ゴルフボールが積みきれない事態を考えると多すぎる間違いが致命的だと見なして概算してみたいと思います」
  3. 推定方法1で、少なくなる方向に安全値を取りつつ概算
  4. 「もしお時間を許していただけるならもう一つ別の方法で概算し、その少ない方を採用したいと思いますが」
  5. 時間が許されればその通りに、方法だけ説明を求められれば（一番楽）推定方法2の概要を説明する

これで「こんなめんどくさいやつ勘弁してくれ」と不採用決定！

ぱちんこCRはてな村

CRはてな村はこんな感じです。

記事がツイートされたりブログで言及されたり

小当たり。しかしこれがこれから来る大当たりへの序曲でもあります。

2ブクマ

リーチ！あと1ブクマで新着ブクマ入りです。
セルクマでリーチを強制成就させるくらい、みんなやってるよね！？

新着入り

確変突入！ここから小当たり連発でブクマもアクセスもぐんぐん伸び始めます。
伸び方次第で大当たりまで届きますよ！

ホッテントリ入り

大当たり！滝のようなアクセスが流れ込んできます。
アクセス解析をリロードするたびにびびる。

Gunosy推薦記事入り

連チャン！ホッテントリの大波が収まったと思ったら翌朝からまさかの第二波が来ます。正直第一波と同じくらいでかいです。

そしてCRはてな村がフィーバーするとこんな感じに。

意味のわかるオブジェクト指向(1) プログラミング言語は、巨大なシステムを開発するために進化してきた

意味のわかるオブジェクト指向

プログラムは書けるけどオブジェクト指向がどうもよくわからないという人に

オブジェクト指向の価値は多態性にある

ことを理解してもらうためにこの連載を書きます。このことが理解できたら、次はデザインパターンに触れて多態性がいかに役立つかわかるようになると、ものすごく理解が深まることでしょう（この連載の中でも、少しだけデザインパターンを紹介する予定です）。
連載では、ずっと昔のプログラミング言語の紹介から始めて、オブジェクト指向に向けて進化する中で何が変わったのかを解説していきます。この過程は（デザインパターンを学んでいくところまで含めて）まさに僕がプログラミングを学んできた過程そのものにほかなりません*1。自分では、自分はちょうどいい時代に生まれてちょうどいい段階からプログラミングを習得できたと感じているので、この過程を紹介する次第です。

プログラミングの初心者にとって、オブジェクト指向プログラミング（面倒くさいので、以下OOPと略そう）を取り入れた言語から学ぼうとすると、意味のわからない「おまじない」がとても多い。昔のマイコンのずっと原始的な言語でプログラミングを学んだ人の方が、自分が何を書いているのかよっぽどわかりやすかったはずだ。

※Java（OOP言語）で書いた、「こんにちは！」と表示するプログラム
Class Hello{
  public static void main(String[] args){
    System.out.println("こんにちは！");
  }
}

※BASIC（原始的な手続き型言語）で書いた同内容のプログラム
10 PRINT "こんにちは！"

BASICのプログラムの意味は、「各命令行の頭には行番号を付けないといけない（上の例では「10」）」というルールさえ理解していればすぐに理解できる。それに対してJavaのプログラムは括弧がたくさんあり、行が字下げされていて、Class, Hello, public, static, void, main, String, args, System, out, とたくさん単語が並んでいる。こいつら、どういう意味？
やりたいことはprintln（これも、「ln」の意味がよくわからないけど……）だけなのに。println以外は全部おまじないだと思うしかない。これでは自分が何を打ち込んだのかもよく理解できない。

これらのおまじないの意味（と意義）を理解してもらうためのOOP講座なのだが、最も簡単なプログラムからこんなにおまじないだらけでは心がくじけてしまう。だからまず、心が折れないよう、次のことを頭に置いておいてもらいたい。

１．プログラミング言語は、巨大なシステム構築のために進化してきた

仕事としてプログラムを作る人たちも、昔はBASICのような原始的な言語で実務用のシステムを開発していた。しかし実務用の（複雑で巨大な）システムを開発していると、どうしても突き当たる問題というのがあった。それを解決するために言語の方が進化してきた結果が、おまじないだらけの現代の言語なのだ。簡単なプログラムは最初から念頭にないわけで、それが簡潔に書けないのはある意味当然のこと、と。

さて、そのプログラミング言語の進化のうち2大変革とも言える「構造化・モジュール化」と「オブジェクト指向」を順を追って見ていくことにする。それを理解することで、オブジェクト指向の意味が自然に理解できるはずだ*2。

次回：「スパゲティ・プログラム」

*1:過程そのもの、といっても関数プログラミングについてはまったく割愛します。またオブジェクト指向の中でもプロトタイプ型オブジェクト指向については省きました。どちらもとても面白いのですが、あしからず

*2:最後まで読んでもらうと、上のJavaのサンプルプログラムの中で、内側の括弧がモジュール化の産物、外側の括弧がオブジェクト指向の産物であることに気がつくと思います。にやりとしてください

パソコンのエラーは、本質的に難しい

雑感

PC初心者の人からよく聞かれる質問に「パソコンの出すエラーメッセージはなんであんなに理解不能なの？」というものがあります。
そういう質問に僕はこう答えることにしています。「それは、エラーメッセージを出しているソフト自身だって、うまくいかなかった原因がよくわからないからだよ」。

実はこの質問は、質問した本人は気付いていないかもしれませんが、PCがPCである――家電や携帯やワープロ専用機とは違う――ことの本質を突いている質問です。そのことについての説明を一切省いて結論だけ言うと、冒頭の回答になります。

その本質というのが何なのかを述べましょう。まず、PCが家電と違うところ、それは使用者がプログラムを自由にインストールできることです。家電も携帯も、使用者が機械に入れられるのはデータだけ。プログラムを入れられるかどうかが違いなのです。

どんなプログラムが入っているかが決まっていないということは、機械の動作をあらかじめ予測できないことを意味します。ソフトを作るとき、他にどんなソフトが入っているかによって機械の仕様が違うのに、それは未定のままプログラムを作らないといけないのです。

他にどんなソフトがどのように入っていてPCがどのように振る舞うか、そのことをソフトは「環境」と呼びます。一部のソフトは、環境がどうであるかに応じて自分の動作を変更するため、ユーザに「環境設定」をさせます。これはもちろん、ユーザがPCのソフト状況を把握していることを前提にした要求ですね。

ソフト自身が自力で環境を解析して、それにあわせた動作をするというのは、原理的に困難です。PC内のソフトインストール状態には事実上無限通りの場合の数があるからです。*1そもそも、環境設定メニューで選択肢を提示して動作を変更すること自体も、何通りかの状態のPCに対して正しく動作するようにするだけです。ほぼ無限通りあるPCの状態すべてに対応できることは期待できません。

振る舞いの場合の数が無限通りあるPCに対して、有限通りの状態しか考慮せずに（できずに）設計したプログラムを動かした場合、期待と異なる結果が出る場合が当然あります。このようなとき、プログラムにわかるのは「想定した以外の振る舞いをPCがした」ことだけです。

このときプログラムにできること、それは「PCが、想定と違うこんな反応をした」とエラーメッセージを出すことだけです。何が原因なのか、どうすればいいのかなど表示できるわけがありません。なにしろ、想定した有限通りの状態以外だったわけですから（想定内の振る舞いだったのなら、最初からエラーメッセージなど出さず、振る舞いにあわせた動作をすればいいだけのことです）。

プログラムをインストールすることができるおかげで、PCは使用者の望む機能を持つことができ、アップデートすることができ、複数のベンダのソフトを利用することができるという便利さを持っています。それと同時にこの特徴は、状態が（ほぼ）無限通りになることで振る舞いが予測できなくなるという最大の欠点の本質でもあるのです。

このことを一言でまとめると、まさに「ソフト自身だって、わかっていない」ですね。

*1:ある程度環境設定を自動化したソフトというのもありますが、それは選択肢を非常に限定することで実現しているに過ぎません。設計時に想定しなかった状態になっていれば、環境を正しくは判定できません。