Fearlessな越境

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

自己紹介

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

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

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

こんな発表をしました。

自分のチームをどう作る？ from Masakatsu Sugii

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

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
こちらの画面に出ている数字を以下のような表に加工しました。（地味な手作業で…）

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のパターン