「オープンデータ・ベリーとちぎ」のデータをExploratoryで見てみる
このニュースを見て、せっかくのオープンデータが不発だなんてもったいない、と思って、ちょっとだけ触ってみました。
このなかの2016年8月26日の新規登録データから、グラフにしやすそうなものという基準で「トラフィックカウンター日光市_湯元」を選びました。
このあたりかな。
CSVファイル（約1MB）をダウンロードして、Exploratoryから文字コードにShift_JISを指定して読み込みました。「年月日」と「時分」が別の列になっていて扱いづらかったので、
time = ymd_hms(str_c(年月日, ' ', 時分))
として「年月日」と「時分」をつなげてから日時のオブジェクトに変換しています。
横軸を時間(日)で、縦軸を総交通量にして、車線（上り、下り）で色分けして折れ線グラフにしました。
一週間でグラフの形が繰り返していますね（日曜日じゃなくて月曜日が交通量が少ないように見えるのですが、もしかしてわたしがデータとExploratoryのタイムゾーンをうまく合わせられていないのかも）。2015年の9月にデータが無いのは、なにかの測定失敗なんですかね。
えっと、それ以上に不思議なのは、上りのほうが下りより多い！！本当？？そういうものなの？？
栃木県と群馬県の境目のような地点で、地図を見てもどちら向きが上りでどちら向きが下りかわからないけど、上りと下りの交通量が毎日偏っていたら、どちらかの県に車が多くなっちゃうという心配が、、、
もうちょっと調べてみると大型貨物・小型貨物と乗用車で上り下りの交通量の差が逆転しているようですが、まだよくわかりません。車種と車線で色分けしてみてみようと思ったのですが、それは次にします。
心理的安全は流行語候補！ XP祭り2016：国際会議 Agile 2016の風 – とある参加報告 - #xpjug
今年のXP祭り2016はムスメとの散歩がてら参加するという計画だったので講演はちょっとだけ見られたら良いやというつもりでしたが、昼過ぎからムスメを奥さんに預かってもらったので自由に動けるようになったので、エンタープライズアジャイルの後に国際会議 Agile 2016の風 – とある参加報告 -を聞いてきました。
で、講演者の伊藤さんと竹葉さんのパートで紹介されていたのがモダンアジャイルです。（昨日ググった時に英語だけだと思い込んでいたのだけど、なんと実は翻訳されていました。）
- 人々を尊重する
- 安全な状態を前提とする
- 素早い実験と学習
- 価値を継続的に届ける
この４つのうちの1つの、安全な状態を前提とする（Make safety a prerequisite）の更に中に含まれている、心理的安全(psychological safety)がとても興味深いです。
心理的安全、は言葉通りの意味で、「安心」と言ってもいいだろうし、「くだらない質問しても、自分が思っていることをブログに書いても、攻撃されない」という環境だと思っても良さそうです。そりゃあ、そういう状態のほうが良いに決まっていますよね。牛尾さんの講演で言っていた西洋文化の心地よさもこれに近いと思います。「思ったことを言わない」ではなくて「思ったことを言っても大丈夫」ということですね。
牛尾さんは西洋文化と表現していましたが、モダンアジャイルの基本理念（の一部）としてわざわざ挙げるということは、西洋の文化でも空気のように当たり前というわけではなくて、みんなで意識して心理的安全を守って文化にしているのでしょうね。
それにしてもこういう当たり前のことを明言してしまうのってすごいですね。ローコンテクスト文化の強みというのか。。。当たり前すぎて反論できないし、モダンアジャイルを避けて開発なんてできないですよね（心理的安全を守っただけでモダンアジャイルに入っちゃうと思うと。4つの基本理念が全部そうですが）。アジャイルは宗教だという人もいますが、こういう宗教ならソフトウェア開発者はみんなベースとしてこの宗教を信じちゃえばいいじゃんって思ったりします。
ところで、心理的安全に戻りますが、「自分が思っていることをブログに書いても炎上しない」という状態はどうやって作るのかなと少し考えました。「反論禁止」というわけではないんですよ。反論も自由にできるのが心理的安全でしょうし。たぶん、プロジェクトファシリテーションで言うところの問題 対 私たち(Problem vs. Us)がその答えかなと思いました。
反論したいようなブログエントリーを見つけた時に、反論するのは良いけど、書いた人を叩くような事はしないで、その横にある問題（Problem）に対して意見を言うというのが必要ですよね。第一印象として書いた人を叩きたくなっちゃうのは人間としてしょうがないとしても、ちょっと冷静になって問題に目を向けて、みんなで心理的安全の文化を守っていきたいと思います。
XP祭り2016：吉原さんのエンタープライズアジャイル開発の導入事例
XP祭り2016では吉原さんのエンタープライズへのアジャイル開発の導入事例も目当ての一つだったので、1回家に帰ってから午後にもう一度会場に来ました。
エンタープライズという環境の中でアジャイル開発をしたいという要望があり、そのためにアジャイルコーチとして参加した、というお話ですね。
チームのメンバーはアジャイル開発をしたことがなくて半信半疑であるので、アジャイルのプラクティスを厳選してコアプラクティスとして、その段階での成功を体験してもらって、アジャイルに慣れてもらうという方針で進めていたようです。
多くのプラクティスをいきなり導入しないというのは、半信半疑とか不慣れとかでなくても、チームビルディングとしてはとても重要なことだと思います。どんなに優れたメンバーをそろえても、最初は（チームのルールのようなものである）プラクティスは少なく始めて、ふりかえりを繰り返しながらチームを変えていくという作業が良いやり方だと思います。そういう意味では"ふりかえり"と、そのタイミングを制御する"イテレーション"が、最初にやりたいプラクティスだなと改めて思いました。
吉原さんの講演を聞いていて、タイムボックスをうまく使っているのが印象的でした。終わりが読めない全体設計的な作業に関しては、最初にタイムボックスを決めてしまってその範囲で終わらせる、と。2:8の法則を未来の自分たちに適用する良い作戦だと思いました。
【気になったこと】
・そもそも、エンタープライズってなんでしょうか？
なんとなくわかるけど、いまいち明確ではなくて、エンタープライズの制約だというふうに言われてもそうかなーと思う場面が何度かありました。アジャイルプロセス協議会のエンタープライズアジャイルWGでじっくり聞いてみます。
・プロダクトオーナーの不在問題。
エンタープライズだからプロダクトオーナーをできる人なんてほとんどいない、というのは、私も実感として納得しているところでもあり、一方でそれを解決しないとなにをやってもうまく行かないと思っていることでもあり。プロダクトオーナーって、そのシステムを欲しい人、というプロジェクトのモチベーションであるはずなので、それが明確でないということはそのプロジェクトは不要なんじゃないかなと思ってしまいます。
・アジャイルコーチの必要性
アジャイルコーチは最初からの契約でが3ヶ月間だったようです。でも吉原さんがアジャイルコーチとして参加することでチームはアジャイルチームとしての振る舞いをすることができているようだったので、ずっといるように交渉したほうが良かったのではないかなーと思いました。そもそものプロジェクトが、システムが必要というよりはアジャイルを組織に導入したいという事じゃないかと感じたので、だったらなおさらアジャイルコーチをもっと長期間使ったら良いのじゃないかなと。
おまけ。なぜか会場では最初からエンタープライズ＝アヤシイとなっていて面白かったです。終わったあと、小井土さんが「あやしくなかったね」って言ってたり。
XP祭り2016の牛尾さんの基調講演
XP祭り2016をムスメとの散歩がてら見てきました。というか、まだ終わってなくて、午後にもう一個見に行くつもりではいます。うちから近いので家と往復しながらつまみ食いしています。
牛尾さんの基調講演を聞いてきたのですが、講演の途中から入ってムスメが飽きはじめたので一旦出て、その後ちょっと見て、出てきました。Be Lazyですわ。ちがうか。たぶん、60分のうち25分くらい聞いたかなと。2:8の法則で言えば十分ですね！
基調講演の内容は、すでに公開されている（！）エントリーが大変参考になります。
simplearchitect.hatenablog.com
講演を聞いていた時に2:8の法則(パレートの法則 - Wikipedia *1 )について言っていたので、その時にメモとしてツイートしました。
2:8の法則。を2だけ2回やると4で16の価値を出せる #xpjug
— Akiya Mizukoshi (@Akiyah) 2016年9月24日
なんだけど、牛尾さんのブログエントリーには2:8の法則という言葉は出てないですね。もしかして講演資料にも出てないのかも。口頭のみだったかな。2:8の法則の2の部分だけをやって8の部分をやらなければ、2の時間で8の価値を出し続けて生産性が10倍以上になる！ということでした。
2:8の法則、私も好きで、いろんなところに潜んでいると思っています。たとえばフォトリーディングのような速読で1時間で本を読んだとして、じっくり読んだ場合の8割は吸収できているとか、無圧縮の音楽データと比べて2割のサイズに非可逆圧縮したMP3の音を聞いても8割分はオーケーとか（MP3の場合はそもそも気が付かない程度だと思うけど）。もちろん、仕事でも。
さてさて、ぼくはこの点に関しては違う意見を持っていて*2、2:8の法則をもう一度適用して、20%のうちの20%に注目したら4%の時間で64%の価値を作り出せて、4:64=1:16の法則になるのだなと。*3
重要な20%と重要でない80%の区別の仕方が気になる人がいるかもしれませんが、それはそれぞれの人が判断していいということだと思っています。それが認められているのが牛尾さんの講演で言っていた西洋文化なのかなと。
全員にとって絶対に重要でないことを探したらそれは0%になっちゃって、誰かにとっては重要なことが100%になって、それをやっていたら生産性は上がらないですね。
*1:牛尾さんも私もパレートの論旨とは違う形で使っているようですね。wikipediaみて気が付きました。
*2:平鍋さんのエントリーの言葉をマネしたかっただけです。。。 https://anagileway.wordpress.com/2016/09/24/xp-festival-2016/
*3:なんども書くけど平鍋さんのエントリーの言葉をマネしたかっただけで、あんまり意味無いです
『ハイビーム使用を…横断死亡９６％が「下向き」』 の件は『警察は統計がわかってない』で済ませてはいけないよね
↑この読売新聞の記事（の転載）を読んで、死亡事故の96%の車がロービームだと書いてあるけど、そもそもロービームの車ばかりだから死亡事故の車もロービームが多いんじゃないかなと私も思いました。
でも『同県警の検証では、このうち２６件でハイビームを使っていれば、ドライバーも歩行者も互いに早く気付き、命が助かった可能性が高いという。』と書いてあったので、この記事に書いてある数字以外にもデータはたくさんあって、そのデータがハイビームの有効性を示しているのかなとも思いました。
で、あんのじょう、『警察は統計がわかっていない』という意見が流れてきたんだけど、さすがに統計をわかっていない訳はないはずなので、ワザとか、途中で数字が独り歩きしちゃっているとか、そういうことかなと感じて少し検索してみました。そしたらいいエントリーが見つかりましたよ。
このエントリーを読んで、そのリンク先であるFNNニュースの動画を見て、私の疑問はだいぶ晴れました。もともとは2016年9月15日の警察庁の記者会見で、それを読売新聞とFNNニュースで記事にしたのですね。FNNニュースのほうはロービームの割合については言及されていないので、読売新聞がつけたタイトルが誤解を与えているのかなと。
ここで読売新聞は統計をわかっていない、と判断しても良いのかもですが、私はわざと統計的に曖昧な表現を使って注目を集めた、と感じました。交通事故を減らすための啓蒙活動の一環でもあるので、注目を集めるのは悪いことではないと思います。でも、そのやり方が甘くて、かえって数字に強い人にとっては信用できない情報になっちゃったのでしょう。
ここまでで、私なりに改善点を書いておくと、下のようになります。
- 警察庁はニュースからリンクを貼れる形でデータを出しておいてほしい。（今回のような検証がやりやすいように）
- 読売新聞（や他のニュース媒体）は数字に強い人が見た時に『わかってない』ように思われるようには書かないでほしい。必要な補足情報は載せてほしい。
- ニュースを読む人は、『わかってない』で済まさないで、上記のエントリーのように冷静に判断してほしい。
さて、警察庁は本当にデータを出していなかったのかな？と思ってもうちょっと探してみました。警察庁から交通事故統計（平成28年8月末）に行って、さらにe-Statの該当のページに飛んで、そこでExcelとPDFのデータを見てみました。ハイビームとロービームの話はここにはなさそうだったのでちょっとあては外れたのですが、これはこれで見応えのあるデータでした。
例えばPDFに載っていたこのグラフ。（3Dグラフであることは置いておいて）
年齢別で見ると、65歳以上が多すぎる！！！ なんか、納得。ネットのニュースを見て書き込んだりしている人たちは実は当事者じゃなくて、おじいちゃんおばあちゃんが気をつけるべき当事者なのね。。。
↓こういうポスターを見て、誰がターゲットなのかイマイチわかっていなかったのですが、やっぱりおじいちゃんおばあちゃんに向けてのメッセージだったのですね。
【交通総務課】このポスターの、可愛い女の子の名前をご存知ですか？「おじいちゃん、おばあちゃん、あぶないよ」と高齢者の方に、交通事故防止を訴えていますね。名前はまた明日、ツイッターで！ pic.twitter.com/MNvrNouMBU
— 警視庁広報課 (@MPD_koho) 2013年6月3日
データにはこれ以外にも（県別の件数とか）見るとためになる分析がたくさん載っていました。やはり警察庁は統計がわかっていないわけがなくて、価値ある分析をしているようですね。でも、この状態では使いにくいデータなので、サンフランシスコのデータのように事故の1件1件をバラして、見る人が自在に分析できるデータとして公開してほしいものです。そうしたらMakeover Monday Challengeのような感じで更に意味ある分析をする人が出てくるかもしれないし！
サンフランシスコのオープンデータをダウンロードしてTableauやExplorateryで表示してみる
この記事を読んで、サンフランシスコはいろいろなデータを公開していることを知りました。そういうデータをダウンロードして表示してみたので、メモしておきます。
まず、サンフランシスコのオープンデータを公開してるSF OpenDataにアクセスします。
今回はPublic Safetyを選んでみましょう。
例えば一番上のMap: Crime Incidents - from 1 Jan 2003を選択してみます。
このデータは最初から地図に表示されていますね。表にすることもできます。
たぶんフィルタリングしたりグラフにしたり、いろいろ見方を変えられるのですが、そんなには使いやすそうではないので、丸ごとダウンロードしてしまいましょう。Exportというボタンを押します。
で、形式を選んでクリックするだけです。無難にCSVにしました。ダウンロードしてみると、なんと400MBほどありました。こんなに大きいファイルだとは、、、
まずはTableauで表示してみます。都合によりTableau Desktopのライセンスを失ってしまったので、Tableau Publicで見てみます。ダウンロードしたCSVファイルを読み込ませてみるとわかるのですが、日付のDate列がTableauでは日付と認識できようです。ついでに言うと、時刻はTime列に入ってるので、それと混ぜて日時の列を作りたいです。
DateTime
DATEPARSE('MM/dd/yyyy HH:mm', LEFT([Date], 10) + ' ' + STR([Time]))
こういう計算式を作って、無事に日時を扱えるようになりました。ここまでくれば簡単で、どんな風にでもグラフを見ることができますね。
次はExplorateryです。こちらもDateとTimeをなんとかするために、下記のコマンドを実行してDateTimeという日時を扱える列を作りました。
mutate(DateTime=mdy_hm(str_c(str_sub(Date, 1, 10), Time, sep=' ')))
こうしてしまえば、あとはいろいろできますね。
ちなみに、サンフランシスコのデータを公開しているのは、socrataというサービスのようです。
サンフランシスコ以外にもこのsocrataでデータを公開している自治体はたくさんあるようです。データ公開しているのは素晴らしいですね。
18歳以下の自殺者をExploratoryで表示してみた。
内閣府の調査の、過去約40年間の18歳以下の自殺者というデータがあったので、Exploratoryで見てみました。
Exploratoryを触って慣れたいというモチベーションだったのですが、これに関してはごく簡単でした。csvファイルの日付フォーマットを変更（1月1日→2016/1/1）したのと、ヘッダーフッターをそれっぽく修正しただけで、Exploratoryに関しては読み込んで折れ線グラフを選択して、x軸(日付)とy軸(人数)を設定したくらい。
↑横長に表示されているとしたら印象が違うかもなので、Exploratoryのページで見た方がいいかも。
元のデータが日別だったのだけど、月別にもしてみました。これもすっごく簡単。Round to Day を Round to Month にかえるだけ。
以下、ちょっと思ったこと。
- 自殺者数の9/1のピークは夏休みがあけたタイミング。でも月別でみると４月の方が多い。
- Exploratory便利。Mac/Windowsを持っていないので夏休みに触れなかったけど、会社のMacで触っていい感じだと思いました。
- Exploratory、明示的な保存という概念はないのかな？？？操作は全部保存されるのかもしれない。
- Exploratoryを起動するときにID/PASSを聞かれるのが面倒。
- 公開してるExploratoryの中のRスクリプトに、ローカルフォルダのパスが残っているのがちょっと気になる。
- 1月1日→2016/1/1と変更したけど、もしかしたら変更しなくてもなんとかなるのかも。
- 年月日(Date)じゃなくて、年を無視した月日という概念はなんと呼ぶのだろう。
