結城浩の「コミュニケーションの心がけ」2016年11月15日 Vol.242
はじめに
おはようございます。
いつも結城メルマガをご愛読ありがとうございます。
＊ ＊ ＊
新刊の話。
結城の新刊『数学ガールの秘密ノート／やさしい統計』は、 たくさんの方に応援していただいています。 先日、編集部から増刷の連絡がありました。 刊行後二週間足らずでの《重版出来》です！
また、Kindle版を初めとする電子書籍版も無事配信開始しました。 ありがたいことにKindleの数学有料本で、 数日間ランキング一位が続いていました！ 感謝！
◆『数学ガールの秘密ノート／やさしい統計』（Kindle）
https://www.amazon.co.jp/exec/obidos/ASIN/B01MSJMKMW/hyam-22/
『数学ガールの秘密ノート／やさしい統計』のKindle版は、 これまでの秘密ノートシリーズ同様に「固定レイアウト」での配信です。 必ず購入前に「無料サンプル版」で、 画面の大きさや使い勝手などを確認してくださいね。
無料サンプル版には、第一章をまるごと掲載していますので、 ぜひ試し読みも兼ねてダウンロードしてみてください！
なお、固定レイアウト型のKindle本は、 Amazon Cloud Readerを使うとPCやMacでも読むことができます。 Macで無料サンプル版を読むと、以下のような感じになります。
◆Amazon Cloud Reader（スクリーンショット）
Amazon Cloud Readerについてはこちらから。
◆Amazon Cloud Reader
https://read.amazon.co.jp
『数学ガールの秘密ノート／やさしい統計』 を引き続き応援してくださいね！
＊ ＊ ＊
書評の話。
日本数学会の会員誌『数学通信』21巻（2016年度）に、 結城の『数学文章作法 推敲編』に対する書評が掲載されていました。 評者は近畿大学理工学部の松井優さんという方です。 以下のページからだれでもPDFで読むことができます。
◆日本数学会「数学通信」書評
http://mathsoc.jp/publication/tushin/bookreview.html
この書評、たいへんていねいに結城の本を解説してくださっているのですが、 私は書評の最後「結びにかえて」を読んで驚きました。
そこには「この書評の第一稿はとても見せられたものではありませんでしたが, 本書を実践して書き直し,勇気づけられました」 と書かれていたのです。
つまり、この松井さんは、 この書評そのものを推敲した実例としてここに提示しており、 しかもそのことを書評に明記しているのです。 この謙虚さと誠実さに私は深く感動し、 襟を正す思いになりました。 書評を読んでこんな気持ちになったのは、 初めてのことかもしれません。
お時間がありましたら、あなたもぜひお読みください。
◆日本数学会「数学通信」書評
http://mathsoc.jp/publication/tushin/bookreview.html
＊ ＊ ＊
iOSアプリの話。
ニコニコチャンネルのiOSアプリ（niconico ch）ができました（無料）。 結城メルマガを「ブロマガ」で購読している方はアプリでも読めます。
niconico chアプリをインストールしてログイン後「結城浩」 を検索すれば「結城浩のコミュニケーションの心がけ」はすぐ見つかります。 よろしければどうぞ！
◆niconico ch
https://itunes.apple.com/jp/app/niconico-ch/id1148502570
＊ ＊ ＊
誤りの話。
設計ミスや施工ミスで建物が壊れたとします。 そうするとミスをした人の責任が問われることになります。 そして次の一歩として「再発防止」を考えることになりますね。
再発防止を考えるときに、
・(A) ミスをしないように人間が注意しよう
・(B) ミスを検出できる仕組みを作ろう
という二つの考え方があると思います。 この二つの考え方は排他的なものではありません （つまり、どちらか片方のみにしなければならないわけではありません）。 両方が大切になるでしょう。
設計や施工に関わる人がミスをしないように注意することはいいことですし、 ミスを検出できる仕組みを作ることも大事です。
しかしながら、(B)の考えを進めるためには、 「人間はミスをすることがありうる」 ということを前提としなければなりません。 だって、人間がミスを絶対しないなら、 ミスを検出する仕組みなんて不要ですから。
逆に(A)の考えを進めるためには、 安全装置としての(B)は存在するとした上で、 それでも人間は注意しなくてはいけないと考える必要があるでしょう。 安全装置があるから手抜きしてもいいや、では困りますから。
複数の安全装置がもっともよく機能するためには、 それぞれが適切に独立であるべきなのでしょう。
人間が注意してもしなくてもミスがあったら検出する仕組みを用意する。 ミスを検出する仕組みがあろうとなかろうと人間は注意する。 そうすれば、(A)と(B)の複数が存在する意味があることになりますね。
ただし、今度はそこにコストという要因が加わって話をややこしくします。 人間と仕組みの両方を多重に掛けるために、 コストが大きくかさむ危険性が出てくるからです。
あたりまえのことですけれど、すべては《程度問題》になります。 現実社会において、何かがゼロパーセントである場合や、 百パーセントであることはほとんどありません。 すべては《程度問題》になります。
現実社会において、 ゼロパーセントや百パーセントを要求する人がいたならば、 その要求は現実的ではないといえそうです。
「重大な問題であるからこそゼロパーセントを要求する」 と考える人もいますが、それは、 「重大な問題であるから、現実的な答えは求めない」 というナンセンスな主張になりかねません。
＊ ＊ ＊
変化の話。
先日、カルロス・ゴーン氏の短いインタビュー記事を読みました。
◆「私は変化が嫌いだ」 再建王ゴーン氏の本音
http://style.nikkei.com/article/DGXMZO0910378002112016000000
結城はふだん、こういう記事はあまり読まないのですが、 この記事を読んだ理由はもちろんこの見出し「私は変化が嫌いだ」です。 「え？」と思って読んでしまいました。
--------
驚かれるかもしれませんが、私は変化が嫌いなのです。
変えなければならないことは、最小限に抑えたいのです。
よくなると期待するから変えるのであって、
変えることが目的になってはいけません。
（記事より）
--------
「変えることが目的になってはいけません」とは、 あたりまえのことですけれど、ゴーン氏がいうと重みがありますね。 技術の世界でよく言われる警句に「壊れてないなら直すなよ」 というものがありますが、それにも通じます。
わが身を振り返ってみると、こういう誤りをしてしまいそう…… と思いました。変えることが目的になってしまったり、 そもそもよく考えずに何となく変えてしまったり。
もちろん、どう進んでいいかわからずに変えてみることはあるでしょうし、 いわゆるイノベーションのジレンマを防ぐために、 うまくいっていてもあえて変えることもあるでしょう。 大事なのは、だから「見極め」であり「判断」になりますね。
変化を起こすときに、変化を起こす前に、
「いま起こそうとしている変化に、私は何を期待しているんだろうか」
ということを見極める。判断する。 それが大切なのでしょう。
変化したからうまくいくわけではなく、 変化しないからうまくいくわけでもないのですからね。
そして変化の良し悪しを見極めるためには、 そもそも現状をよく観察しておく必要があるのでしょう。
＊ ＊ ＊
アクセス解析の話。
書籍のランディングページを結城はたくさん管理しています。
ランディングページで集客するぞ！ のように意気込んでいるわけではなくて、 ネットで自分の本を紹介するときの場所は、 きちんとしておく必要があるだろうというほどの気持ちです。
あるときふと、 「ざっくり言って毎日どのくらいのアクセスがあるんだろう」 と思いました。ずっと放置していてアクセスは見ていなかったからです。
サーバは粛々とアクセスログを保存していますので、 それを手軽に解析するツールがほしいなと思いました。 検索してみると request-log-analyzer というものが私の用途に合いそう。 サーバのアクセスログファイルを access_log としたとき、 以下の二行を実行するだけで、時間ごとのアクセス、 メソッドごとの分布、アクセスURL, リファラなどがグラフ表示されました。
◆request-log-analyzerのスクリーンキャプチャ 
実行時に --output html というオプションを付けると、 HTML形式で出力してくれるのでとても見やすくなります。
◆HTML形式での出力（１）
◆HTML形式での出力（２）
見てみると結城が作ったランディングページへのアクセスは、 一日に数百くらいのオーダーですね（そのうちbotが数割）。 結城のツイートからたどるアクセスが多いのかなと思っていましたが、 結城のトップページからのアクセスが多いのが意外でした。
アクセスログのざっくりした解析にはrequest-log-analyzer便利ですね。
◆request-log-analyzer
http://request-log-analyzer.com
＊ ＊ ＊
二つの話。
他人がまちがっているのを見て「やっぱり自分は正しかったのだ」と考える人と、 「自分もまちがっているかもしれない」と考える人がいます。
他人が成功しているのを見て「自分はやっぱりだめだ」と思う人と、 「自分にも道がありそうだ」と思う人がいます。
「●●である人と、■■である人がします」と言われると、 「どちらか一方だけが正しくて、他方は誤りである」と考える人と、 そのようには考えない人がいます。
二つの話が与えられると、 二つの選択肢しかないと思ってしまいがち。
＊ ＊ ＊
新聞紙の話。
先日ふと、
「新聞ってもう購読しなくていいんじゃないか」
と気付き、購読を停止しました。
妻は半分賛成しつつも、 「新聞紙がないと生ゴミを包んで捨てるときに困るのでは」 という意見を出してきました。
結城は「ゴミを捨てるための紙として新聞紙を購入するのは高すぎ」と、 反対意見を提示しました。 「必要ならアマゾンで古新聞紙は買えるはず」 と思って。実際、古新聞誌は買えます。
しかも、チラシなどが入ってないものもあり、 生ゴミを捨てるには都合がいいのです（チラシは水を吸わないので、 生ゴミ処理には不適切）。
紙の新聞は、ほとんど家族の誰も読んでいませんでした。 何となく継続して購読していただけ。 毎月のことですから、よく考えると高い買い物をしていたことになりますね。
＊ ＊ ＊
分割統治の話。
「複雑なものは分けて考える」というのはエンジニアリングの基本です。
大きな問題を場合分けによって解決したり、 要因を分析して、それぞれに対策を立てたりします。 そもそも工業製品やプログラムがたくさんの「部品」に分かれているのは、 まさに「複雑なものは分けて考える」という《分割統治》に根ざしています。
プログラムではグローバル変数は嫌われます。 たくさんのモジュールからいつアクセスされるかわからない変数は、 管理がしにくくてしかたがありません。 だから、影響範囲をできるだけ少なくするような工夫が考案されています。 グローバルなスコープを持つ変数を少なくし、 ローカルなスコープを持つ変数でできるだけ解決しようとします。
世界における「グローバル化」の難しさは、 グローバル変数の扱いにくさと似ているのかもしれない、 とふと思いました。
安易な類比は避けなくてはいけませんが、 社会という極めて複雑な問題に適切な解を与えるために、 エンジニアリング的な発想は必要だと思います。
問題は分割して統治するのが基本です。 問題を分割しただけではだめで、 個々に対して適切な対策を打たなければなりません。
しかしこまったことに、 問題を特定するために「分割」することそのものが、 新たな問題を引き起こすことも多いでしょう。 性別しかり、国籍しかり、収入しかり、居住地しかり……
難しいものです。
＊ ＊ ＊
書籍検索の話。
結城は「でんでんランディングページ」 を使って自著のランディングページを作っています。 そこには購入のためのリンクを貼ることができるセクションがあります（当然）。 でも、ネットショップはとてもたくさんあるので、 一つ一つURLを確認するのが大変です。
そんなことをツイートしていたら、鷹野さん（@ryou_takano） から「書籍横断検索システム」というサイトを教えてもらいました。 ここでは書籍を検索するといろんなショップをまとめて表示してくれるのです。 これは助かります！
◆書籍横断検索システム
http://book.tsuhankensaku.com/hon/isbn/9784797387124/
◆スクリーンショット
それにしても現代は「こういうサービスがほしいな」と思ったら、 たいてい誰かが作っていますよね。便利な時代です。
＊ ＊ ＊
さてそれでは、今週の結城メルマガを始めましょう。
どうぞ、ごゆっくりお読みください！
目次
- はじめに
- 再発見の発想法 - 状態
- publish or perish
- 情報の賞味期限 - 本を書く心がけ
- 質問に答える技法
- おわりに
