Office2013(Excel2013)の「PowerView」と「PowerMap」で地図にデータを表示する

地図系のツールを色々と試しています。
Excelのアドオンである「PowerView」と「PowerMap」の両方で地図にデータを表示する方法です。

Jリーグ2013年平均入場者数を地図にプロットしてみる

使ったデータは2013年のJリーグのスタジアム単位での平均入場者数です。
http://www.jsgoal.jp/11mpark/ranking/visitors.php?year=2013
こちらの画面に出ている数字を以下のような表に加工しました。（地味な手作業で…）

PowerView

Excelのアドオンとしてインストールすることができます。
Officeのバージョンによっては使えないようですのでご注意を。
（今回はOffice 2013 Professional Plusで試しています）
インストールすると下のように「挿入」タブに「パワービュー」というアイコンがでてきます。

使い方

エクセルに使いたいデータを入力します。
使用したいデータの範囲を選択した状態で「挿入」→「パワービュー」を選択すると、別シートに以下のようなPowerViewシートが表示されます。

「デザイン」タブの「マップ」を選択すると地図が出てきます。
次に右側の「PowerViewフィールド」で「スタジアム」を下部の「場所」に設定します。「Σサイズ」には「平均入場者数」を設定します。
後はマップの背景やらデータラベルなど設定すると以下のようなバブルマップが完成です。
入場者数が多いスタジアムはバブルが大きくなります。

PowerMap

次はPowerMap。
こちらもExcelのアドオンとしてインストールすることができます。
適用できるOfficeのバージョンもPowerViewと同じものです。
インストールすると下のように「挿入」タブに「マップ」というアイコンがでてきます。

使い方

こちらもPowerViewと同様にエクセルに使いたいデータを入力します。
使用したいデータの範囲を選択した状態で「挿入」→「マップ」→「Power Mapの起動」を行います。
すると以下のようなブランクのマップ別ウィンドウでが表示され、右側のレイヤーウインドウに選択したデータの項目が出てきます。

今回の場合は「スタジアム」にチェックをし、下の「地理およびマップレベル」を「その他」にしました。
スタジアム名をBingMapで検索し地点を自動的にプロットしてくれます。
表示設定をいじると以下のような感じにできます。見た目はPowerMapのほうが綺麗ですね。

地図のプロット方法

今回はスタジアム名から地点をプロットしましたが「味の素スタジアム」などいくつかのスタジアムがプロットされないという問題がありました。
基本的にはBingMapでスタジアム名を検索した結果の地点となるようですので、スタジアム名であればほぼ問題ないですが店舗名など正しく検索されない可能性のあるものは避けたほうがいいでしょう。

プロットに使用できるデータとしては緯度経度、住所、データソースをSQLServerとするならgeographyデータ型も使用できます。
業務などで使う場合このような確実なデータにすべきですね。

PowerMapは認証プロキシ環境で動作してくれない…

社内LANなど認証プロキシが必要な環境だとPowerMapが起動しません…。
以下のようなエラーが出てしまいます。

Power MapがMicrosoft Bingマッピングサービスに接続しているときにエラーが発生しました。機能が制限される場合があります（状態コード：407）

DirectXが初期化できません

ローカルプロキシで対応

yappaなどのローカルプロキシツールを使い、直接認証しないような設定（IEのインターネットオプション）をしました。
ひとまずはこれで動いています。

Office2013は認証プロキシ環境で使うには厳しい…。

熱闘！「DevLOVE現場甲子園2014 東日本大会」 #devlove

http://devlove.doorkeeper.jp/events/11792
「DevLOVE現場甲子園2014 東日本大会」に参加してきました。
スタッフとしてお手伝いしつつ、いくつかの良い話を聞き刺激をもらいました。

「創トラック：サービス企画(UXデザイン/サービス開発/要求開発/スタートアップ)」をメインに楽しい一日を過ごしました。
自分の仕事でサービスっぽいことをやっているのもあり、顧客開発やサービスデザインとか気になったんです。

圧倒的すぎる黒田さんの話

「社内スタートアップでの組織の成長に伴い発生する痛みとその解決策（スクラム＆顧客開発＆リーンスタートアップ導入）について」
@i2keyさんの話です。
いきなりすごい話に圧倒されました。
スマホアプリサービス最前線で、様々なレイヤーの課題に立ち向かうお話でした。
何が凄かったかって、課題解決へのアプローチがいちいち凄い。
「開発の課題→アジャイル（スクラム）の導入」ってのはよくある話でもあり、それはそれで素晴らしいのですが、黒田さんはそこに留まりません。
プロダクトの課題をリーンスタートアップの考えを使ってやっつけていっているようです。
（Bulid-Measure-Learnサイクルを実践してる）
しかもそれぞれの課題に対し、しっかりとしたプロセスを構築しています。使ってるツールも何かいい感じだし。

個人的にはダントツナンバーワンのプレゼンでした。
大きな刺激を貰えました。ありがたや。

熱闘続々

他のトラックもすごく充実したものでした。
川瀬浩也さんの「アジャイル開発の外側としての顧客開発。僕はプロダクトオーナーなんて出来ない」もすごく良かった。
「アジャイルの外側」は顧客開発ってことなんですが、もうエンジニアって開発だけ語っててもダメでビジネス価値を高めること本質だよね、というテーマは黒田さんと同じテーマだったのではないでしょうか。

和田あずみさんの「失敗上等！世にも奇妙な「旅行会社でのUXデザイン 裏話」」も参考になる話ばっかりでした。
ユーザテストやログなど、ちゃんとした根拠からアプローチしているのは言われてみれば当たり前なんですが、現場でしっかり実践するのは凄いです。

作ってるだけじゃダメ

今回の収穫というか、刺激をもらったのは「エンジニアは作ってるだけじゃダメ」ということを再認識できたことです。
なんていうか、その考えは重々承知してるつもりなんですが、自分の現場は顧客開発のプロセスが全然できてないし、我々エンジニア側からも提案できてません。
皆さんの話から様々なヒントをもらいました。明日からの現場をどう変えてやろうか楽しみです。

ああ、こういう場は本当に貴重です。
企画したスタッフの皆様、ありがとう。

Google Maps API(V3)とYahoo!ジオコーダAPIで住所から緯度経度を取得するサンプル

地図とか位置情報を扱うため、GoogleとYahooのそれっぽいAPIに触ってみました。
使い方、サンプルコードなどをメモ。
※2014.8.14に記載した内容です。APIの最新仕様をご確認ください。

Google Maps API(V3)で住所から緯度経度を取得

google.maps.Geocoderを使って取得できます。
公式なドキュメントはこちら。
https://developers.google.com/maps/documentation/javascript/geocoding?hl=ja

サンプルコード

jsファイルの設定は以下

<script type="text/javascript"
  src="http://maps.googleapis.com/maps/api/js?key=yourkey"></script>

"東京タワー"というワードを渡して、その緯度経度をconsoleに出力するサンプルです。もちろん"東京都町田市"のような住所から緯度経度を求めることもできます。

var geocoder = new google.maps.Geocoder();
var word = "東京タワー";

geocoder.geocode({'address': word,'region': 'jp'}, function(results, status){
  if(status==google.maps.GeocoderStatus.OK){
    if(results.length > 0){
      var latlng = results[0].geometry.location;
      
      console.log("名称 : "+ results[0].formatted_address);
      console.log("緯度 : "+ latlng.lat());
      console.log("経度 : "+ latlng.lng());
    }
  }
}

検索結果は複数返ってくることがあります。このサンプルでは1番目を取り出しています。

出力結果

名称 : 日本, 〒105-0011 東京都港区芝公園４丁目４−２−８ 東京タワー
緯度 : 35.6585805
経度 : 139.74543289999997 

Yahoo!ジオコーダAPIで住所から緯度経度を取得

同様にY.GeoCoderを使います。
http://developer.yahoo.co.jp/webapi/map/openlocalplatform/v1/geocoder.html

jsファイルの設定は以下。

<script type="text/javascript" charset="utf-8"
  src="http://js.api.olp.yahooapis.jp/OpenLocalPlatform/V1/jsapi?appid=yourkey"></script>

サンプルコード

こちらは"東京タワー"のようなランドマークの名称では検索できません。住所のみに対応しているようです。

var geocoder = new Y.GeoCoder();
var word = "東京都町田市"; 
var request = { query : word };

geocoder.execute( request , function( ydf_data ) {
  if ( ydf_data.features.length > 0 ) {
    var latlng = ydf_data.features[0].latlng;

    console.log("名称 : "+ ydf_data.features[0].name);
    console.log("緯度 : "+ latlng.lat());
    console.log("経度 : "+ latlng.lng());
  }
} );

出力結果

名称 : 東京都町田市
緯度 : 35.54663039
経度 : 139.43861819 

他にも

逆に緯度経度から住所を取得するAPI（Google、 Yahoo）もあります。
試してないけど。

アジャイル開発のタスク見積もりでやりがちなミス

アジャイル開発、主にスクラムをやっている人にとってタスクの見積りは悩ましいところかと思います。

個人的な備忘録も兼ねてよくあるミスをまとめてみます。
ここでのタスクの見積もりとはスクラムガイドにあるスプリント計画ミーティング第２部のことです。念のため。

①見積りポーカーで時間がかかりすぎる

見積りポーカーを用いて見積りをするのはよい方法なんですが、いかんせん時間がかかりすぎる場合が多いと感じています。

• みんな様子を伺っていてこれといった決め手がないままダラダラと議論してしまう
• 逆に好き勝手に話をしてもよいと思うメンバーがいて、決め手がないまま話が長くなってしまう。

見積りポーカーをやる理由は「タスク量の認識ズレをなくすこと」です。
認識ズレがないようなら見積りポーカーは必要ないはずです。そもそも別の方法でもよいかもしれません。

対策

• 認識ズレがありそうなタスクに対してのみ見積もりポーカーをやる
• そもそも見積りポーカーを用いずにタスク量の意識合わせを行う。

という感じでしょうか。我々のチームでは見積りポーカーにこだわらないようになりました。
とは言え、メンバー間で違和感が残ったまま見積りを終わらせるのだけは避けたいところですので、みんなの意識が合っているかどうかは確認します。

②技術調査や検証のタスクが正確に見積もれない

我々のチームでは「Feasibility Check」と呼んでいる種類のタスクです。
技術的な検証をしないと出来るかどうかわからない、採用してよいか判断できないといったことは開発の途中でもよく遭遇します。
この検証はどの程度で終わるのかなんて誰にもわかりません。さあ見積りとしてはどうすればよいのでしょうか。

対策

このような場合、ある程度時間を区切っての見積もりとします。
我々のチームでは８時間を上限としてタスク化していました。８時間（約一日）やってみてどうだったかをデイリースクラムで共有します。
出来そうなのか無理そうなのかを判断し、必要であれば検証を続けますし、出来そうなら別のタスクとして追加します。

③タスクをやる上での注意点を忘れてしまう

見積り時に、「ここは性能問題を注意する必要があるよね」とか「セキュリティについてｘｘのことを注意すべき」などの議論になります。
このようによい議論があるのに何もしないのはもったいない。
テストの時や受入時に「あー、見積もりの時に注意しようって言ってたのに～」とならないようにしたいです。

対策

• チケットの備考欄にメモしておく

我々はRedmineやJIRAを使うことが多いので、当該チケットのどこかにその場でメモをしておきます。
または付箋に書いてカンバンに張っておくのも効果的です。

決まったタスクを忘れがち

リリース作業や報告書作成など、スプリント毎に同じような作業を繰り返し行うことがあります。
このようなタスクが見積りから漏れてしまい、結果としてキャパシティオーバーでスプリントのタスクが完了せず、という状況になりました。

対策

このような必要な作業がある場合は、忘れずに作業量を見積もっておきましょう。（当たり前のことです…）

UI変更を伴うタスクは思ったより時間がかかる

WEB系のシステムをやっていると大抵この問題が起こります。
特にチームにUIを得意としている人がいない場合、画面のレイアウトを少し変えるだけでも思ったより時間がかかります。
デザインが苦手なプログラマにとってJavaScriptやCSSなどの修正は手間がかかったり、慎重に作業をしてしまうものなんだと思います。

対策

２割増くらいの感覚で見積りをしましょう。もちろん過去のスプリントを参考にしつつ。

バッファは必要か！？

キャパシティに比べ見積もり時間が100%近くになっていることがあります。
理論上はそうなのかもしれませんが、現実だとこうはいかないことが多かったです。
見積りは実質の作業時間をイメージするのですが、現実は作業を開始する前にアレコレ考えることから始まります。
「影響するのはどのコードだっけ？」「似たようなコードあったっけ？」などなど…。
アレコレ考えることも見積りに含める必要があります。とは言え、どの程度なのかわかりません…？

対策

• バッファとしてしてしまう

アレコレ考えたり、ちょっとした課題で議論したり、と開発中はコーディングや設計書執筆以外のこともやっています。
これをいちいち作業として考え出すと細かくなってしまい大変です。（そもそもこのような作業を正確に見積もるは無理です）
そこで、バッファとしてそのあたりことを行う時間としてしまいます。
目安はキャパシティの20%くらいでしょうか。

まとめ

ダラダラと書いただけなので、まとめも何もないんですが、アジャイル開発時の備忘録でした。
スプリントレビューや振り返りの時も同じような失敗集ができそうです。

個人のせいにする前にプロセスやシステムを疑え

最近いくつかのプロジェクトで同じことが起きてます。
「何か問題があると個人の問題にする」という現象です。

「個人の問題」

例えば品質問題。
ある個人のコードの質が悪かったんです。たまたま結合試験で気づきました。試験担当者がたまたまコードを見ながら試験したから気がついたんです。
「あいつの書くコードはちょっとなぁ…」という意見が複数出ました。

例えば生産性。（生産性って言葉はあまり好きじゃないのですが、プロジェクトではこの言葉を使っていました。技術力と同じような意味なんですが）
ある個人のスキルがあまり高くなく、コードを書くのに時間が掛かります。システム開発の経験も少ないのでプログラム言語、業務仕様の理解も他のメンバーより時間が掛かります。
チームとしても顧客の求める計画を達成できていませんでした。
「あいつがチームの生産性を落としてるから計画通り進んでないんだ」とマネージャーは言いました。

本当に悪いのは何か？

個人が本当に悪いのでしょうか。
確かにスキル不足は否めませんが、チーム全員がプロフェッショナルであれば問題は出なかったのでしょうか。

1つ目の問題（結合試験でコードの不備が見つかる）では以下のような問題がチームにあったのではなかったでしょうか。

• なぜコードレビューで見つからなかったのか
• なぜ単体テストで見つからなかったのか
• スキルが低いとわかってるはずなのになぜ放置しているのか

２つ目の問題（生産性の低い個人）ではそもそも個人の問題でありませんでした。

• スキル不足の本人はドキュメンテーションや試験などの作業でプロジェクトに貢献していた
• ちゃんと計測してみると、そもそもチーム全体としての生産性は悪くなかった
• 技術的課題、手戻りなどのリスクを無視した計画となっていた

サッカーに例えると

このような状況をサッカーに例えてみると、

• あるディフェンダーはフォワードに抜かれて点を取られるシーンが多い
• あるフォワードはボールを取られるシーンが多い

という目立ちやすい問題をみて、
「あのディフェンダーは簡単に抜かれるからダメ」とか「簡単にボールを取られるフォワードは役に立たない」というのと同じです。

表面的な問題から安易な答えを出さないこと

「フォワードに抜かれて点を取られる」という状況を考えるのが大事です。
そもそもフォワードと1対1になっているのは守備戦略の上ではあってはならないことでしょうし、フォワードが簡単にボールを取られるのは味方から孤立していて何もできない状態なのかもしれません。

表面的な好ましくない現象から安易な原因を求めるのは危険です。
「質の悪いなぜなぜ分析」の分析結果が個人攻撃になってしまうことが多くあるように、「なんとなく」で原因を考えると個人のせいになってしまいます。

僕がみたいくつかのプロジェクトでも本当の原因は個人ではなかったように思えます。

プロセス、システムは機能してるか

じゃあ何なのか、というとプロセスやシステムがうまくいっていませんでした。
個人のイマイチなコードが気づかれずに残っているのは、明らかにコードレビューが機能していないんです。
「コードレビューを必ずする」という（当たり前の）開発プロセスのもと、Gerritというツールでコードレビューを運用していたんですが、これがちゃんと機能してなかった。
"レビューツール（Gerrit）に慣れていない"、とか"忙しくて細かくレビューしていない"のような他の問題/原因がありました。

また生産性の話も、チーム全体の生産性は当初計画を上回るものでした。ただ計画に余裕がなくリスクが顕在化した時にリカバリーする動きが管理層でとれませんでした。
"リスクはなく開発を予定している機能は計画した生産性で完了する"というプロジェクト計画となっていました。
個人の生産性問題はわかりやすい形で表面化していただけで問題の本質ではありませんでした。

組織やチーム全体の問題としてとらえる

サッカーチームが負けるのはディフェンダー一人の問題でしょうか。点が取れないのはフォワードのせいでしょうか。
その前にチームのリスク管理や点を取る戦略が欠けてないでしょうか。

と、昨日の「今日は本当に申し訳ない。僕は、その一言しか言うことがない。次で取り返したい。自分の判断ミス、普通にクリアしていれば…」というFC東京の森重選手の言葉を聞いてこんなことを考えたのでした。

個人のミスはしゃーない。その個人のミスをチームとしてどうマネージメントしているかが大事なんじゃないでしょうか。

組織をアジャイルに変える方法 〜FEARLESS CHANGE〜

『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』を読みました。

組織を変えるアイデア、ヒントが48のパターンに

僕の仕事はSIな現場にアジャイル開発を普及させる、というものです。
組織に新しいことを適用するのは想像してたよりも大変でして…。とりあえず突っ込んでみては玉砕したり、地道な活動が実を結ばず心が折れかかったり…。

そんな悩みを抱えていた時、この本に出会いました。
めっちゃいい本です。日本語訳が出たタイミングも含めてこれはもう僕のための本じゃないかと。

自分が取り組んできたこと、これからどうやって取り組んでいくのか、のヒントがこの本に書いてありました。
48のパターンから、忘れちゃいけないこと、これからの活動のヒントになりそうなことをメモします。

グループのアイデンティティ Group Identity(13)

活動を特徴づける名前を掲げ、人々がその存在を認識できるようにしよう。

チームの目的や取り組むことを決め、わかりやすい名前をつけることで存在意義を明確にします。
まだまだ小さなアジャイルチーム。良い名前をつけ存在感を組織内で出せるようにしたいですね。

次のアクション Next Steps(19)

研修の終わりごろに、受講者が得た新しい情報をどのように活用すべきか、プレインストーミングと議論の時間を取る。

研修や勉強会で得たものはあっても消化せずに忘れてしまう問題への対処方法です。
例えば議論をして、自分が考えたことを付箋に書く、というのは記憶に残るかもしれません。今度試してみようと思います。

アーリーマジョリティ Early Majority(30)

組織において、新しいアイデアに注力する方針を確立するには、マジョリティ（大多数）を納得させなければならない。

少人数（イノベーター、アーリーアダプター）だけで成功しても大多数に受け入れられるわけではない。
この違いを意識できるかどうかは大きいです。
アーリーマジョリティに受け入れられることが成功となるので、段階に沿った取り組みが必要となりそうです。

• 新しい取り組み（例えばアジャイル開発が）リスクが低いことを示す。また需要が大きいことも示す
• アーリーマジョリティがそれに気づくことが大事
• 積極的な売り込みも大事だが、こちらの取り組みや成果を常にオープンにしておく

体験談の共有 Hometown Story(32)

新しいアイデアの有用性をわかりやすく示すためにに、うまくいった人には経験の共有を促そう。

アーリーマジョリティにわかってもらうために、はじめてアジャイル開発をやった人に有用性を発表してもらうのはいいアイデアです。
社内勉強会などで新しいことの良さを定期的に示し、常にオープンにしておく。少しずつでもアーリーマジョリティに響いていきそうです。

相談できる同志 Shoulder to Cry On（39）

めっちゃ大事です。心折れないように。

成功の匂い Smell of Success(40)

あなたの取組みがなんらかの目に見える結果を残した時、あなたと話したがる人がぞろぞろと現れるだろう。

目に見える結果は大事です。
外から見える成果（プロジェクトの成功、売上や利益の増加）、内側で実感できる成果（チーム・個人の成長）をうまくアピールすることで「成功の匂い」が強まり、より賛同者が増えそうです。
自分のチームでどうするか。ちょっと考えてみたいと思います。

懐疑派代表 Champion Skeptic(44)

あなたのアイデアに懐疑的なオピニオンリーダーに「公的な懐疑派」の役割を演じてもらうよう、協力をお願いしよう。
彼らの懐疑的な姿勢を変えられないとしても、あなたの取組みを改善するためにその意見を活かそう。

懐疑的な意見を得られる環境が大事です。
時には意図的に反対意見を出してもらうことでアイデアを深めることができます。
どれだけタフクエスチョンに耐えられるか。

恐れは無用 Fear Less(46)

抵抗勢力を新しいアイデアの強みに変えよう。

いわゆる「抵抗勢力」を単純に拒絶せずに、協力をしてもらうことで自分のアイデアをより強固にしよう、ということです。
これはもうその通りでして、反対されてもイライラせずに謙虚に聴き、あわよくば味方にできれば怖いものないですね。
精神修行が必要なパターンです（笑）

そして、これからのアクション

「次のアクション(19)」にならってやってみることリストをば。

• チームの目的を明確に：インセプションデッキを作ってみる。
• 常にオープンに：社内でアジャイル開発セミナー（勉強会）を定期的に開催する。
• ついでに新人研修でもアジャイルの話をしたい。
• 体験談の共有：チームの成長を何かで計測する。先日教えてもらった「スターマップ」を作ろう。
• 「アジャイルチームだと成長できる」と内外にアピールできれば。

本当に良い本に出会いました。成果が出ると信じて進むのみです。
恐れは無用！ Fearless Change！

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

東日本大震災 当時の記録

3.11　東日本大震災から3年が経ちました。

当時のメモを転記します。
長男は9歳（3年生）、次男は3歳（保育園）でした。三男はまだ産まれてない。

東北の比ではないですが、大変な一日でした。

『3.11 大地震』

『3.11 大地震』
忘れないように地震の時の状況、考えたことなどを記しておきます。

◆３月１１日 １５時前。地震発生。
茅場町のオフィスにいました。

大きな揺れだということはすぐにわかりました。
阪神大震災を経験している（大阪の端なので神戸からは遠いですが）僕は、その時の恐怖が頭をよぎります。
阪神大震災では、ゆらゆらっと小さな揺れの後、ガツン！と暴力的な揺れがきました。

あのような揺れが来た時、ビルなんて簡単に崩れてしまう。
早く逃げなければ、と思いますが怖くて足が動きません。
揺れが収まって、非常階段でビルの外に出ました。
そのまま近くの公園へ職場の仲間と避難。
携帯電話は繋がらず、メールも遅延している模様。大活躍だったのはTwitter。
意外だったのはPHS。問題なく繋がり、嫁と連絡が簡単に取れました。非常にラッキー。

職場に戻り、早く帰ろうと思えど、電車が動いていない。
歩くにも家まで４３km（！）。
歩きだす勇気がでず、職場に留まります。

２０時を過ぎ、いつまでも帰らないわけにもいかず、職場を出発。
とりあえず東京駅方面へ、そして新宿駅を目指します。

外に出ると寒い！
この寒さで朝まで歩くのは困難に思えます。
周りには歩く人でいっぱい。みんな寒そう。
歩いて帰る人の中に、飲み屋を探す人の群も・・・。
それはそれで楽しそうだけど、余震なんかのことを考えると酔っ払っちゃうとマズいんじゃない？

茅場町～新宿は過去何度か（運動不足解消のため）歩いてたので、道に迷うことはなし。

途中、市ヶ谷あたりのコンビニでパスタ買って食べました。
何件か寄ったコンビニには食糧はほとんどなかったです。
カロリーオフのダイエット用のゼリーしかない・・・。

携帯でTwitterを定期的にチェックします。電車の運行情報を探しつつ歩きます。
霞が関を通る頃、地下鉄がちらほら動き始めていて、京王線の復活に望みが出てきました。

歩く中、多摩ナンバーの車を見つけたのでヒッチハイクしてやろうかな、なんて考えたのですが、
道は大混雑していて歩いているほうが早かったので断念。

新宿に着く頃、Twitterで京王線復旧の情報が。
ラッキー。非常に混雑してましたが新宿から最寄駅まで電車で帰宅できました。

◆嫁は、電車が止まってると見るや、家まで３０kmの職場にも関わらず、
歩いて帰る決断を早々にし、３時間くらい歩いたところで友人の車で拾ってもらったようです。
迎えにきてくれた友人に感謝！
とは言え、渋滞していたので帰宅したのは２３時を過ぎていたとのこと。

◆長男は小学校にいました。授業が終わる頃に地震が発生したようです。
親の引き取りで下校することになったのですが、僕も嫁も帰宅の目途は立たないため
同じマンションに住んでいるクラスメイトの親御さんが一緒に帰ってくれたようです。
帰宅し、家に１人でいると危険と考えた長男は必要なもの（オモチャや漫画、お菓子・・・）をかばんに詰め、自宅前の広い公園に自転車で行ったそうです。
近くにある公園なのに、なんで自転車？と思ったのですが、
自転車には取り外し可能な電池式のライトがついていたので、夜になったら使える、と判断したそうです。
普段はぼけーっとして、忘れ物が多い長男。やる時はやります。
その後、公園にいるところを友人に見つけてもらい、友人宅に避難です。
ちなみにウチの周りは全戸で停電していたようです。

◆次男は保育園でした。
僕も嫁も迎えにはいけず、長男を拾ってくれた友人が迎えに行ってくれました。
次男は同系列の別の保育園へ避難していました。長男が事前に次男の保育園に行き、別の場所に避難しているという情報を得ていたので、混乱なく次男を拾うことができたそうです。
（長男は次男が心配で保育園まで行ってみたそうです）
長男と次男が停電で暗い友人宅で身を寄せます。
次男はずっと泣いていたようです。長男はずっと声を掛けていたと友人が後で教えてくれました。
ちゃんと次男の着替えやオムツを持ち出していた長男。かっこいいです。やる時はやります。

嫁が帰宅後、息子達をピックアップし帰宅。
帰宅した３０分後に自宅電気も復旧し、そのまた３０分後に僕が帰宅しました。
夜中１時前にようやく全員揃いました。

とにかく全員無事でよかった。
長い１日でした。

◆以下、思ったこと。
・勤務地から家まで（43km）を歩くのは困難に思えました。途中で足を痛める可能性も高く危険ですね。実際新宿からウチまで（35km）歩いた友人がいるのですが、足のダメージがひどく３日たってもまともに歩けないそうです。
・勤務地が遠いことは災害時のリスクだと感じました。共働きで夫婦のいずれも家から遠い場合、子供と会えなくなる可能性が高いです。
・地域コミュニティの大事さ。「地域」ってほど大げさなものではないですが、近所の友達が多いこと、自治会（マンションの管理組合）の人と連携することで最悪の事態は防げます。普段からの近所付き合いは大事ですね。僕は２年前にマンションの理事長をやっていたこともありマンション内では顔が知られているため、息子のことを気遣ってくれる人が沢山いました。ありがたいことです。
・嫁のネットワーク（ママ仲間）も素晴らしい動きでした。子供の迎えや世話などをできる人がやる、という感じで見事なチームワークで子供達を守っていました。
・電話やメールが不通だったので、Twitter、facebookは安否確認に有効でした。でもまあPHSが最強です。通話が特に不自由なくできました。
・都心の土地勘は重要でした。何度か趣味で新宿まで歩いたことは良い経験でした。他の人は地図を片手に歩いたり、警察官に道を尋ねたりしていました。普段地下鉄しか乗らないと方向・距離感はわからないですよね。僕は新宿までなら楽勝で歩ける、ということは分かっていたので安心して歩を進めることができました。
・マンションの低層階は地震に強い。高層階では大きな物が倒れたり、皿が割れたりとそれなりの被害が出た模様です。３階のウチは特に何事もなく、軽く物が散らばってる程度で済みました。

◆その後
・嫁にTwitterのアカウントを取らせました。何の保証にもなりませんが繋がる手段は多いほうがいいでしょう。
・次男が情緒不安定です。些細なことで泣いたり、怒ったり。普段から素直なほうじゃないので地震と因果関係があるかわかりませんが、たぶん関係あるのでしょう。親と離れて揺れを経験し停電の夜を過ごしたのですから。
・長男は落ち着いているように見えます。でもまだ９歳。途中まで１人でした。心配です。
・食料の買いだめ、ガソリンの補充などをなるべく控えています。普段の生活で必要のないものは無理やり確保しません。必要な分だけ買っています。車も普段は使わないので。

家の近くで崩れた大型スーパーの駐車場のスロープ。