読者です 読者をやめる 読者になる 読者になる

HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

冬の四国旅行(高松~松山)

年末に四国旅行に行ってきました。
四国といっても瀬戸大橋~高松~松山~しまなみ海道と瀬戸内海側だけの旅行です。

瀬戸大橋を渡る

子供の頃以来の瀬戸大橋です。
f:id:sugiim:20141229115106j:plain

香川といえばうどん

「なかむら」という有名らしい店に行きました。つるつると美味いうどん。
f:id:sugiim:20141229122822j:plain
f:id:sugiim:20150101231315j:plain

金刀比羅宮にお参り

こんぴらさん」にお参りです。
785段の階段を2歳児連れていくのはちょっとキツいです。だっこ紐とかあればもうちょっと楽だったかなぁ。
f:id:sugiim:20141229135750j:plain
f:id:sugiim:20141229143345j:plain

鬼ヶ島(女木島)

高松港からフェリーで20分くらい。桃太郎伝説の鬼ヶ島に上陸です!
f:id:sugiim:20141230101908j:plain
鬼ヶ島の全容。けっこう大きな島です。
f:id:sugiim:20141230100647j:plain
フェリー乗り場の建物。きれいです。
f:id:sugiim:20141230101931j:plain

自転車で洞窟まで行けます。電動自転車もあります。普通の自転車でチャレンジしたのですがまったくお勧めできません(笑)
坂が異常にキツいので素直にバスに乗りましょう。
f:id:sugiim:20141230103055j:plain
山の上の洞窟付近からの眺め。高松港が見えます。絶景。
f:id:sugiim:20141230103600j:plain

洞窟の入り口。チケット売り場のオジサンが丁寧に解説してくれます。写真も撮ってもらった(笑)
f:id:sugiim:20141230110014j:plain
洞窟の中には鬼瓦が。けっこう迫力あります。
f:id:sugiim:20141230105537j:plain
あれ…!?まさかの笑顔のツーショットです。なんて絵でしょうか…(笑)
f:id:sugiim:20141230105800j:plain


松山城

早めに松山についたので急きょ松山城を見学。
日本で12か所しか残っていない、江戸時代以前に建造された天守を有する城郭の一つということで非常に格好いい城。
f:id:sugiim:20141230151332j:plain
f:id:sugiim:20141230145028j:plain
中に入ります。急な階段で幼児連れはちょっとキツい。
f:id:sugiim:20141230152716j:plain

f:id:sugiim:20141230153522j:plain
f:id:sugiim:20141230153733j:plain
f:id:sugiim:20141230153124j:plain
f:id:sugiim:20141230155225j:plain

道後温泉

観光地ということで行ってきました。
歴史がある温泉ってことでありがたい感じですが、中は普通の銭湯です。外観は素敵ですね。
f:id:sugiim:20150102004307j:plain

しまなみ海道でサイクリング

いい天気だったのでしまなみ海道を自転車で渡ってみました。
と言ってもほんの一部だけ。今治から大島を渡って伯方島までの約20キロを走りました。

f:id:sugiim:20141231110214j:plain
子供用の自転車も借りられます。次男(7歳)は糸山~大島の7キロを走破しました。橋を自転車で渡るのは気持ちいい!
f:id:sugiim:20141231125313j:plain
f:id:sugiim:20141231130021j:plain

登ったり走ったり

振り返れば登ったり走ったりばっかりした旅行でした。年末で太った体にはちょうどよかった!?

2015年の目標的なもの

f:id:sugiim:20150101095914j:plain
2015年があけました。
このBlogも2歳になります。無理のないペースで続けます。

2014年の振り返りと2015年の目標を考えてみます。

2014年の振り返り

・社内勉強会を継続する
 →ちょっと思うところもありペースを一時期落としましたがなんとか継続できています。
・個人振り返りをやる
 →これは結局できてません。なんとかやる習慣をつけないと…。
・チームの成長を記録する
 →これも途中でうまくいかなくてやめてしまいました。今年はうまくやりたいなぁ。
・フロントエンドのプログラム技術に触れる
 →これはやりました。AngularJSを仕事で採用し、ガリガリコーディングはしなかったですが2〜3画面を作ることができました。
・UX力を上げる
 →これはどうだろ…。いくつかの勉強会の参加や書籍での学習はしました。ただ現場で使うってところまではまだ到達できてません。
・「成長の機会が得られる現場」を作る。
 →ある程度達成できたかと思います。4月から自分のチームを持つことができ、数名の仲間といい現場が作れてきています。
インセプションデッキをとにかく作る
 →自分のチーム、現場のインセプションデッキを作りました。もっと色々できたような。
・サッカーの戦術/戦略に詳しくなりたい。
 →なんとなくですがわかるようになってきました。流行の「ボランチ脇」とかドヤ顔で語れます(笑)
・月2回はサッカー/フットサルする
 →29回。なんとか月2回はできました。
・週1回はジョギングしようかな
 →サッカーやった週はやってません…。
・次男のサッカーに根気よく付き合う
 →4月から少年サッカーの役員になりほぼ毎週ある試合に付き添いました。練習と試合を通して成長する姿はいいもんです。

2015年の目標的なもの

  • 社内勉強会を継続する。定期的に開催するのはちょっとキツくなってきました。不定期でも続けようかと。
  • 個人振り返りをやる。去年はうまくやれなかったのでやる仕組みから考えよう。
  • モバイルアプリの開発をやる。個人的にも勉強しよう。仕事でもやりたい。
  • え、英語の勉強…! そろそろやろうかな…。
  • サッカー/フットサルを月2回。これは継続してやりたい。ケガしないようにしよう。
  • サッカー戦術にもっとくわしくなる。サポートしているFC東京はイタリア人監督ってこともあり面白いと思うんですよね。スタジアムでよく観てみようかと。
  • 筋肉つける。30後半になって体力が落ちつつあります。キープするためにも筋トレやろう。

Fearlessな越境

このエントリは、DevLOVE Advent Calendar 2014「越境」の34日目(12/11)の記事です。

自己紹介

すぎいです。SIerで働くエンジニアです。アジャイル好き。サッカー好きです。少年サッカー(息子の応援)、Jリーグ観戦が主な守備範囲です。
2013年のDevLove現場甲子園で話をしまして、
その縁あって、今年のプレイバックDevLOVE現場甲子園でも話をさせて頂く機会がありました。

DevLOVE Advent Calendar 2014は「越境」をテーマに、ということなのでプレイバックDevLOVE現場甲子園で話をした内容について書きたいと思います。

自分のチームをどう作る?

こんな発表をしました。

書籍「Fearless Change」を読んで参考になったことを実践してみた内容となっています。

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

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

管理職になりそう→どうせなら自分の好きなことやりたい→アジャイルを軸にしたチームを作りたい、というアイデアがあり、それを社内で認めてもらうために、勉強会やったり、偉い人にフルボッコにされたり、そこから偉い人と仲良くなったり、やらしい根回しをしたりして、なんとか自分のチームを立ち上げたという内容です。

チームを作るために

 - 偉い人たちにチームを認めてもらう
 - チームメンバーに僕のやりたいことを理解してもらう
ということをやったわけですが、やりながら何やらモヤモヤとした思いがありました。
「同じ組織(会社)にいるのに、お互いの考えていることを知らないなんて!」と。

普段は偉い人たちとは距離があります。我々開発チームは顧客の近くで作業することが多く接点はあまりありません。
逆に開発チームとは普段一緒にいるのですが、作業に追われていることが多く、チームの狙いとか戦略といった話をする機会がありませんでした。

ズレを認め、超える

僕のチーム作りは意識のズレを認めることから始まりました。
ズレを見つけて摺り合わせる。その繰り返しです。

偉い人たちとは繰り返し議論をし、会社の狙いや彼らの立場を改めて理解した上でこちらの熱意を伝えました。
開発メンバーとは、インセプションデッキ、SWOT分析、ビジネスモデルキャンバスなどを用いて各人の思いを共有しました。

まだまだ議論が十分ではないものも多いですし、メンバーが途中から増えたりもしたので今後も継続して議論する場を作りたいと思います。

Fearlessな越境

わからないことに向かっていくのは怖いものです。それでも進みたいのであれば向かっていくしかありません。
向かっていって少々ダメージをくらっても「ズレ」が見つかれば調整ができます。

僕は一連の取組みで、このような「わからないことに向かっていく」という価値を改めて感じました。プレイバックDevLOVE現場甲子園で話をした内容というのは、そのような前提から何でもやれることをやってみた越境(ズレとの戦い)の軌跡なのでした。

似た境遇の人や一歩を踏み出すのが怖い人にとって少しでも励みになればと思います。
Fearless. 恐れは無用!

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

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

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

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

PowerView

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

使い方

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


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

PowerMap

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

使い方

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

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


地図のプロット方法

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

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

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

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

Power MapがMicrosoft Bingマッピングサービスに接続しているときにエラーが発生しました。機能が制限される場合があります(状態コード:407)
DirectXが初期化できません

ローカルプロキシで対応

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

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

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

f:id:sugiim:20140824004826j:plain

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 東京都港区芝公園4丁目4−2−8 東京タワー
緯度 : 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 

 
 

他にも

逆に緯度経度から住所を取得するAPIGoogleYahoo)もあります。
試してないけど。

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

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

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

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

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

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

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

対策

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

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

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

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

対策

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

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

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

対策

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

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

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

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

対策

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

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

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

対策

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

バッファは必要か!?

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

対策

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

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

まとめ

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