ぐー…なんで
あっちこっちで火の手が上がりますかorz
バトンの怖さ〜ストーキングの道具やソーシャルのネタに使われる？〜
複数のアカウントの保有を禁止してるSNSは多いけど、実態としてどの程度一人1アカウントを徹底できてるかはわからない。要は「一人複数アカウント」なんてのもありうる。
で、「どこから来てるかわからないバトン」ってのはさらに気持ち悪い。
変な話だけど、バトンの内容やシークレットバトンの設問を見てると、正直気持ち悪くなる。
「一人複数アカウント」と「バトン」があわさると、実はこれストーキングの道具になるんじゃないか？と思ったりする。周辺状況探ったり、交友関係のさらに深いところを探ったり、変な話、かなりの機微に分類される情報もそこから取れたりするんじゃないか？と思ったりする。
おーざっぱに考えられるシナリオの1つは…
- マイミク（mixiの場合のfriendの呼び名）にあたる人に対してバトンを投げる
- マイミクから広がる（運がよければ）
- 別アカウントで適度にバトンを拾って、また広める
- 適度にぶんまく
- ターゲットが引っかかるのを待つ
わりと気長だけど、もしターゲットがバトンを拾う人であれば、バトンを投げるところさえ間違えなければひっかかる可能性は高い。
もちろん、あからさまに「気持ち悪い」選択肢が並んでたり、「目的が見え見えな」選択肢が並んでたりするととまるわけだが、これについても実は回避方法があったりする、というのが持論。
バトンによるストーキング〜本当に聞きたいことを分割したり、シークレットにしたり〜
正直、単刀直入にストーキング系の質問を並べても、おそらくスルーされるとは思う。
じゃあ、
- その質問をばらして、何の変哲もない選択肢の中にまぎれさせたらどうなるか？
- そして、それがシークレットバトンだったらどうなるか？
- 本当に聞き出したい内容の質問が、100個の中に2〜3個だけ混じってたら、それをどうはじくか？
…たぶん、変な質問ばかりだったら、それがバトンによるストーキングとはばれないんじゃないか？というところが危惧する点。
さらに、バトン自体はあちこちでバンバン飛んでるので、ターゲットが答えたバトンがあったとしたら、その中からほしい情報だけ抜き出して、あと足りない情報を自分で作って適当にまわせばよろしい。
こんなバトンを気長に何個も投げられて、そしてそのバトンすべてに「聞き出したい」内容がちびっとずつ入ってたとしたら、たぶん気づかない。
心理学とか統計学に長けた人だったら、シークレットバトンの回答を分析することで、ある程度の趣味や嗜好をはじめとする「機微な情報」を抽出できるのではないか？とも思ったりする。
バトンにうらみがあるわけじゃないんだけど
考えすぎですかね？（汗
Targeted Batonよりは
Targeted Baton Attack（標的型バトン攻撃）のほうが、よりいいかもですね。明示的に「攻撃」とつけることで、危険性を想起させるきっかけにする、という感じですが。
問題は、「狙いをつけてバトン（棒）を投げつける攻撃」という「物理的に痛そうな攻撃」を想像するあたりですかねｗ
Spear Baton Attack（スピアバトン攻撃）も…いっしょかｗ
「バトン」という呼び名自体が日本独特なので、もすこしバトンをgenericな形で表現してみようか。
…"messages which have many of questions"とでも言うのか？
情報漏えいのダメージを最小限にする7つのポイント
うなずける内容。
ただ、実は「情報漏えい」ってのは、かなり重大な事故なわけで、事故が起きなきゃいいのか？というとそういうわけでもない。
情報漏えい自体はハインリッヒの法則（1:29:300の法則ともヒヤリハットの法則とも言われるけど）で言うところの「１」なわけで、これが起きちゃったら（記事中の）7つのポイントに留意して対応する、という話だけど、じゃあ29と300は？という話も考えなきゃいけない（いや、むしろ29とか300のほうを（１が起きる前に）なんとかする（発生したら対策を考える／それ以前に発生しないようにする）というようにするのが本質）。
経験上、この7つのポイントてのは、29と300について「発生したら」「認識したら」どうするか？というのを考えるのにも役に立つ。
- Point 1 事実を確認し、問題を封じ込めよ
- Point 2 “犯罪現場”をいじるな
- Point 3 他部門と緊密にコミュニケーションを取り、彼らを信頼せよ
- Point 4 守りの姿勢に入るな
- Point 5 役員への事実説明を怠るな
- Point 6 顧客、従業員、パートナーとのコミュニケーションに誠実であれ
- Point 7 事実を確認する前に公表するな
in case of 29 cases and 300 cases〜事実を確認し、問題を封じ込めよ〜
これは基本的には同じ。
ただ、発生した事実に直結する問題が出てきても、それに対処できない可能性があることを認識しなきゃいけない。
29の場合は「事実確認から問題の封じ込め」に、300の場合は「発生した事実」に注目して、どうやったら再発しないか？てのを検討する必要があるかな。
in case of 29 cases and 300 cases〜他部門と緊密にコミュニケーションを取り、彼らを信頼せよ
29 cases の場合も 300 cases の場合も、他部門に飛び火する前のものであることが多い。
ただ、あくまで自部門の中に閉じた話であっても、発生した事象の（ムリない範囲での）共有は必要。
コミュニケーションが意味するところは違うが、もしかしたら「他部門でも」同様のことが発生しているかもしれない。
結果として「潜在的な課題」が浮き出てきて、その対処が可能になるケースもあるのだ。
in case of 29 cases and 300 cases〜守りの姿勢に入るな
これはそのとおり。どんな事故であっても、キャリアが終わる／傷つくと思う人は相応数いる。
ただ、この部分でヘタに守りに入られちゃうと、事故やヒヤリの原因究明は行われない。
この部分は、処分しなければならない側の都合もあるとは思うが、普通の企業であれば「懲罰の規則などで定めてある以上のことはやらない（やれない）」ということを、きちんと確約しておく必要がある（普通はしてあると思うが）。
ヘタに隠し立てすると、よっぽどそっちのほうが罪が重い。
in case of 29 cases and 300 cases〜役員への事実説明を怠るな
そりゃそうなんだけどねー
役員→部門長や所属長、直属上長くらいに落としてもいいとは思う。
そこで問題意識を共有できれば、しかるべきレベルまでのエスカレーションは行われるでしょ。
つうか、現場としてやらなきゃいけないのは、どんな事故であっても（そしてどんなヒヤリであっても）直属上長に対して報告を行う、ということ。
そして直属上長は「感情的にならずに」受け入れ、対応するということ。
in case of 29 cases and 300 cases〜顧客、従業員、パートナーとのコミュニケーションに誠実であれ
これはどちらかというと、ステークホルダーとのコミュニケーションと言い換えることが出来る。
場合によっては、関係ない人とのコミュニケーションが発生する可能性だってある。
in case of 29 cases and 300 cases〜事実を確認する前に公表するな
裏返すと「確認できた事実」を報告するのが重要。
もちろん、それから推測できる問題や被害、そして対策の提言はいいんだけど、あくまで「事実とは分けて」報告するなどの配慮は必要。
その他〜ワークフローの抜けがないか？〜安全面からのチェックを〜
ワークフロー（業務手順）に抜けがある場合に、29の軽微な事故の前駆として300のヒヤリがある、という気はするので、「ヒヤリ」を感じたら、「何が抜けてるのか」を考え直す習慣がほしい。もっとも、29の軽微な事故が起こったら、たいていいろんなところの人は駆り出されるとは思うけどorz
