2012/10/31(水) 「関東三道場共催 "先鋒、前へ！"」へ参加してきました。
Partake（告知サイト）
http://partake.in/events/c58825a9-c0c0-4097-b853-2b15a1411fa4togetter
http://togetter.com/li/399537ゆかりんのーと
https://yukar.in/note/ckFjDwアジャイルサムライ３道場（埼玉道場、横浜道場、DevLOVE道場）の共催イベントです。
今日は西村直人氏(@nawoto)を迎えて、インセプションデッキをテーマに講義＋ワークショップです。
会場は日本オラクルです。参加者は25名前後でしょうか。
■会場案内最初に、日本オラクルの @yokatsuki さんより会場案内です。
@yokatsuki さん曰く、「オラクルなう」とツイートするのがカッコいいとされている（笑
私、データベースリファクタリングの勉強会でもOracleに２，３回きたことありますが、
その時も @yokatsuki さんが会場提供してくださいました。いつもありがとうございます。
■道場案内１．DevLove道場 （@papanda さん）
去年、アジャイルサムライの勉強会（1周目）を全5回で実施した。
また今年に入って2週目を開始した。積極的に失敗する場、がコンセプト。
年内にもう１回道場を予定していて、ワークショップでやる予定。
2.埼玉道場 （@inda_re さん）
今年の1月に開始。初回に著者のジョナサンが来た。今は見積もりまで終わって、来月から計画の章に入る。
基本的に土曜日の昼間にやっている。最近は赤羽でやっている。
3.横浜道場 （@tw_takubon さん）
横浜道場は去年の1月から始めてそろそろ1年。まだバーンダウンチャート前のP.164までしか進んでない。
終わるまであと1年くらいかかりそう。
基本、毎回輪読＋ディスカッションを4回回して、最後のまとめでチームごとに1分発表する。
アジャイルサムライを読んでなくても参加できる、初心者向けの道場。
今年の予定は以下のとおり。
・11/08 年内最後の通常会。バーンダウンチャートのトコをやる。
・11/22 特別編として、Cucumber（※１）のハンズオンをやる。
・12/06 特別編で忘年会。LT大会をやる予定。
（※１）
Cucumberとは、Rubyの受け入れテスト(Acceptance Test)を自動実行するためのツールらしい。
Head First インセプションデッキ改 @nawoto さん自己紹介お客様の現場や組織をアジャイルにするお手伝いをしている。
スクラム道というコミュニティをやっていて、去年、アジャイルサムライという書籍を出した。
CMScrum Alliance Regional Gathering Tokyo 2013http://scrumgatheringtokyo.org/2013/スクラム道も協力コミュニティになっている。
Scrum Boot Camp Premiumhttp://enterprisezine.jp/pma/special/0312/12に翔泳社さんと、スクラムってこんなんやー、ってのを１日でやる。
スクラム道で書籍化決定2013年1月出版予定としていたが、ムリです（笑
２月かな。。。
今日、編集担当に進捗を伝えたら、頭を抱えていた。
今日のアジェンダ１．デッキとは何か
２．デッキの作り方
３．現場での始め方
スライド補足P.37 「やらないことリスト」・やらないことをまず明らかにする。
・わからないことはどこか、を明らかにする。
P.38 「ご近所さんを探せ」 ・体制図を明らかにする。
・プロジェクトのコアチームの外にいる人は、たまに現れる。そんな人が多いほど、進捗は遅くなる。
またその人たちの見積もりは外れやすい。
P.43 「トレードオフ・スライダー」 QCD + Scope
P.57 「１枚目のデッキを完成させるまでの時間」インセプションデッキは、下手したら１週間くらいかかることもある。
実は、すぐに始められるものではない。
→
事前にちゃんと議論できる材料を（持ってる人に）用意してもらう集めて整理して、つくるところから始める。
P.77 「それは変だ」さっきのスライドのように偉い人が言ってても、「それは変だ」とちゃんと言えるかどうか、が重要。
アジャイルサムライでは「手ごわい質問」と行っている。
P.88 「事例」■１．
ミッションは生々しいものになる。生々しくないと疑ったほうが良い。
UIを素晴らしいものにしたい、とか、使い勝手が良い、というのをミッションに持ってくることは結構多い。
そーゆうのは疑ったほうが良い。
■２．
ちゃんとプロジェクト始める前に手ごわい質問をしたほうが良い。
P.94 「ファシリテーターがやるべきこと」回答が難しいものは、そのまま持ち帰りにするのではなく、材料を与えてからみんなで考えてみる。
材料を渡してから、先に進める。１回インセプションデッキのミーティングを止めたほうが良い。
一回持ち帰って検討したほうが良い。ただし、材料を与えること。
P.95 「事例」■１．
付箋は強い。付箋はおすすめ。
あと、自分の意見を書くのが怖いという人には、隣の人と相談して付箋に意見を書くようにすると、
みんなの前で自分の意見をいうより、障壁が和らぐことが多い。
■２．
開発者が全員中国人というPJで苦労した。
中国の方は日本の人にすごく気を使ってくれて、日本語で話そうとするが、意見が出づらかった。
→ 「日本語じゃなくて、中国語で話してください。自分たちの言葉でまとめて最後に教えてください」とした。
→ そうしたらしっかりした意見が最後にたくさん出てきた。
結論：いかに全員がしゃべれるようにしてあげれるかが大事。
P.100～P.102 「大事なポイント」・纏めたことを、エライ人が通る廊下に張り出したPJがあった。→ エライ人の目に留まるようになった。
・誰がまとめるのか、を事前に決めておくべき。
（最後はみんなヘトヘトで、誰か纏めておいてくれ、といってみんな帰っちゃう事態になってしまうので）
・できあがったものは共有フォルダに入れてはならない。誰も見なくなるので。
少なくとも印刷して貼り出しておくべき。
P.108デッキに書いてある質問をすればいいわけではない。
自分が作業をする上で、不安だな、と思うことは必ず話すこと。
それは、他の人が思っていることもあるし、他の人とズレてることもある。
P.123手ごわい質問の練習を「終わったプロジェクト」を題材に練習すべし。
P.126インセプションデッキで一番難しいのは、以下。
・「デッキを作る場」を作ること。
・PJが始まえる前に、分からないことをイメージしてきっちり話すこと。
なので、ちゃんと練習しておかないと、口先だけの話になってしまう。
終わったあとのPJを題材はすごくイメージが残ってるので練習になる。
注意するのは、当初の不安と結果について確認すること。
当初の不安は、結構当たる。そして次のプロジェクトでも当たる。
それを防ぐために、どういう手ごわい質問をしておくべきだったのか、を考えること。
ここまでは基礎の話。その先の話の、スライドにない話をちょっとします。↓
１．デッキをやれば良い、という話ではない。 デッキを作るためには情報が必要。その情報があやふやだったら意味がない。
情報が本当かどうか、もっとクリアにしていかなければならない。
そのためには、ほかの活動も必要になったりする。
２．スライドを変えない現場が多すぎる。 このスライドだけやれば良い、という話ではない。
いかに自分の現場向けにアレンジしていくか。
必要なスライドを、既存のインセプションデッキに足すこと。
例えば、「俺たちのAチーム」をスキルマップにしてるPJがあったが、とても良いと思った。
まずは、自分たちでやってみて、何が足りないかを考えて、補っていく活動となる。
ウチの班の、ワークショップの模造紙こんな感じ。
質疑応答Q1.
日曜のスクラム道で、ステルスデッキの報告が行われたそうなので、横浜道場の特別編でやってほしいなー、
ということで、いつごろになったら出来そうですか。
A1. （@papanda さん）
12月の忘年会のLTでできたら。
Q2.
インプションデッキがあれば何が嬉しいのか、というのを周りの人に上手く伝えられない。
どういうふうに伝えてあげればインセプションデッキの必要性を周りに伝えられるか？
A2.
デッキの１つ１つは在り来たりの話。
よしやろーぜ、というのは難しいので、自分からデッキ1枚を気になり事項の１つとして周りに話してみたらどうか。
で、話してみると、結構意見がバラバラになったりする。
そのときに、みんなで集まってその話を進めてみようか、となったら「じゃあ私が進め方をアレンジしてみよう」とインセプションデッキの方向に持っていけばいいのでは。
デッキありきで話すのではなく、自分の気になるテーマを話し始めて、デッキに繋げて話す方が良いのでは。
Q2'.
今日の話でも、要求を出す側が情報を準備する、という話があったが、その人を巻き込むにはどうしたらよいか。
A2'.
最初は無理。「PJでわからないことがあるので教えてください」ということで話を聞いて、それをこちらでまとめて、「この情報で合ってますか」と聞きに行くことでその人を巻き込むべき。
開発チームで集まれる人で集まって、集まった情報を元にして話し合って、「こーゆう疑問点が出たんですけど確認してください」という形でその人の元に聞きに行くことで、その人を巻き込んでいく。
Q3.
50歳を過ぎた部長さんに付箋を書かせることができるか？
A3.
無理じゃないか。
「残りのメンバーの意見はこうなっていますが、何か意見ありますか？」という話し方をすべき。
ひっくり返されないように、検討の過程も伝えたほうが良い。
例えば、その人の前でインセプションデッキを作ったりしてはどうか。
人に対するアプローチは人によって変わるので、いろんなアプローチを試すのが良い。
Q4.
大規模PJにアジャイルを適用するのは難しい。
そもそもインセプションデッキで全員の合意を取るのは、大規模PJだと難しい。
どうやっていけばいいのか？
A4.
やめたほうがよい。
インセプションデッキを大規模でやること自体は、それほど難しい問ではない。
大規模でPJを始めると、作る物自体が難しい。コミュニケーションの問題もでる。
マルチベンダーの話も出る。問題がいっぱいでる。
誰が解決するか、というと、参加している人が解決するしかない。
その解決能力を付けないと、大規模は無理。まずはその育成から。
インセプションデッキだと、複数チームの代表でまずやって、結果をチーム内に持ち帰って、検討する。
問題がでれば、また代表者が集まってデッキをやる。
そんな形で全員が合意に近い状態に持っていくことは可能では。
全員でいっぺんにやるのは難しい。
体育館で全員をあつめてやるのもあるが、難しい。準備を念入りにやっても大変。
Q5.
意見が平行線をたどって収集がつかない場合、ファシリテーターは区切ったほうが良いのか、もしくは、強制的に収めるべきなのか、どうしたらよいか。
A5.
どちらが良いと思いますか？
Q5'.
区切ったほうがいいのかな。。。と思ってる。
A5'.
それで良いです。こーした方が良い、と思ってることは大体当たってる。
ファシリテーターで大事なのは、議論を円滑にすることであり、収束させることではない。
まとまらないなぁ、と思ったら一旦切って、その原因を理解しておくこと。
1時間や1時間半ていうのは、目安ではなく制限時間として設けてもらったほうが良い。
それ以上やるとヘトヘトになって妥協してしまうので、そこで一旦区切ったほうが良い。
★感想：最後の質疑応答で、Q4.は私でした。
んで @nawoto さんから丁寧に回答をいただけて、しかも終了後にも私に話しかけてきてくださって追加コメントいただけました。
とても丁寧なご対応していただき、とても感謝です！
でも、マスターセンセイでさえも、やっぱ大規模PJでアジャイルは難しいかー。。。
最大で60名くらいのPJでアジャイルやったことはある、とはおっしゃっていましたが、やっぱ大変だったそうです。
あと、本読んだだけではピンとこない隙間とか、今日の講演を聞いてかなり気づきを得られました。
自分のPJにアレンジしてデッキを追加すべし、なんて話は、確かにそうだなぁ、と実感したり。ナドナド
自分の仕事にも活かしていきたいと思います。
@nawoto さん、3道場の主さん、会場提供者さん、有意義なお時間をありがとうございました。
2012/10/30(火) 「第3回 集合知プログラミング勉強会」に参加してきました。
Atnd（告知サイト）
http://atnd.org/events/33438以下の書籍をターゲットとした勉強会なのです。
場所は東京理科大学の神楽坂キャンパス8号館です。
参加者は20名くらいでしょうか。
私は第2回の引き続きの参加です。ちょうど2週間前ですね。その時のブログは
コチラ。
ちなみに私、PythonのコードはUbuntuのvimで書いているのですが、vimはデフォルトでPythonの予約語とか
シンタックスハイライトしてくれます。でも、インデントは自動でしてくれないんですよね。。。
なので、ちょとググって、以下のサイトを参考にvimの設定いじってみました。
Pythonを快適に編集できるようvimを設定するhttp://d.hatena.ne.jp/over80/20090305/1236264851おかげさまで、vimでPythonコードが自動インデントされるようになりました。感謝。
というわけで、可能な範囲でコードを写経し、できるだけ予習してから参加しました。
今回は3章「グループを見つけ出す」が対象です。
3章前半の発表担当は @komiya_atsushi さんです。
大変わかりやすいスライドです。
私も写経してたんですが、1個わからないとトコがあったので質問してみました。
Q.
P.34の下から4行目で if count > 1: となっているが if count > 0: ではないのか？
A.
1回しか出現しないものは、デタラメな単語ということで対象外とする、という意図である。
（2回以上出現している単語だけカウントする、という閾地を設ける）
とのことでした。なるほど。
他の質問に関するツイート。
あと、P.46のK平均法（K-means法）で、とあるブログが紹介されました。
http://tech.nitoyon.com/ja/blog/2009/04/09/kmeans-visualise/K-means法をGUIでシミュレーションできます。
あと、最後のページにPythonをEmacsで書くための設定が紹介されてました。
vimに設定したばっかですが、Emacsの方も設定して使ってみようと思います。
3章後半の発表担当は @satou30 さんです。
P.49で、Zebo（http://www.zebo.com/）というサイトからデータセットを作る、となっていますが、繋がらない。。。
こーゆうの、多いですよね。この書籍。URLが紹介されているのに、繋がらないという。。。
あと、P.42に出てくるPython Imaging Library（PIL）は、インストールが大変とのこと。
ちなみに私、インストールやってなかったので、この苦労わからなかったです。
PILよりもpillowを使うのが良いとのこと。
結論。2日では予習ムリ、ということがわかった。。。
もうちょっと早めに予習しないとキツいなぁ。ということで、もっと早く着手するようにします。
運営者さん、会場提供者さん、ありがとうございました。
2012/10/23(火) 「初心者Scala in F@N 第３回」に参加してきました。
こくちーず（告知サイト）
http://kokucheese.com/event/index/56877/togetter（ツイートまとめ）
http://togetter.com/li/394706会場は渋谷のファンコミュニケーションズです。
参加者は１２名前後でしょうか。
私、第１回に引き続きの参加です。そのときのブログは
コチラ。
ちなみに第２回は別件で参加できなかったのでした。。。
なので、第２回の発表スライドを参考にPlay Frameworkをインストールして、多少動かしてみたりして、
前回の復習をしてから今回の第３回に参加しました。
アイスブレイク最初はアイスブレークのお時間です。
TopCoderというプログラミングコンテストが話題に挙がっています。
プログラマなら、誰もが興味を持つ内容ですねー
TopCoder公式サイト
http://www.topcoder.com/あとスライドに出てた書籍は↓のようです。
Scala基礎講座次は @shitai246_ さんによるScala基礎講座です。
Case2で紹介されている、XMLを扱うScalaプログラムを作って動かしてみました。
まず、第１回のお題でもあったREPL（対話型評価環境）のpasteモードを使い、変数にXMLをベタ書き代入します。
次に、このXMLに実際にアクセスして値を取り出してみます。
Scalaだと、シンプルにXMLを操作できることがわかります。
私もJavaでXML操作のプログラム書いたことありますが、Javaの標準機能だとこう楽には操作できませんよね。
Javaに慣れているプログラマが、ちょっと使い捨てのプログラム作るときにScalaを使うという選択は有効そうです。
Play framework前回の復習と続き
（↑クリックすると発表スライドに飛びます↑ キーボードの矢印キーの←→でページめくれます）
最初のほうは、Scalaの他の勉強会などの紹介がありました。
んで、メインは以下のチュートリアルに沿って、Play2.0でWebアプリケーションを作成するお題です。
http://playdocja.appspot.com/documentation/2.0.3/ScalaTodoList私も実際にチュートリアルにそってやってみました。
ただ、UbuntuのvimでScalaのソースコードを書いてると、デフォルトではシンタックスハイライトが有効になってないんですよね。
これは使いにくいなぁ、ということで、以下のサイトを参考にVimにScalaの設定を追加しました。
■開発TIPS: vim エディタで Scala プログラムを編集する時にシンタックスハイライトを有効にする方法http://sourceforge.jp/projects/milm-search/lists/archive/public/2012-April/000174.htmlこれに沿って設定すると、スゲー簡単に設定できました。予約語とかにハイライト付きます。こんなカンジ↓
んで本題。
チュートリアル進めていくと分かるんですが、PlayはMVCモデルを明確に意識していますね。
Webアプリのappディレクトリの構成が以下のようになってますし。
/app/models
/app/views
/app/contorollers私、普段の仕事でJavaのStrutsを使っているのですが、これもMVCモデルのフレームワークです。
なので、PlayとStrutsを意識せずとも比較してしまいながらチュートリアルを進めていきました。
んで、完成。
Windows7とUbuntuの両方で進めていたんですが、起動するときポート番号が9000番で重複してしまうんですよね。
んで、@gkojax さんにポート番号を指定してアプリを起動する方法を教えていただきました。
以下は私のツイート↓
ということで、
run 9001 で実際に起動してみました。
URLんトコ見ると、9001番ポートで起動していることがわかります。
これで、同一マシンで複数のOSから起動することができるようになりました。
ちなみに、ソースコードは @gkojax さんがgithubに公開してくださっています。
https://github.com/gkojax/play-todolist2
★感想：基礎講座という形の
講義形式と、PlayでWebアプリを作るという
ハッカソン形式が両立されているのが良いですねー
プログラミングでは実際に自分で手を動かして試すことは重要ですし。
あと、スタッフさんがいつでも質問に答えてくれるサポート体制があるのも良いです。
お菓子や飲み物も振舞われるのも、空腹になるこの時間には大変ありがたいです。
次回も楽しみです。
・・・ですが、次回は別件が重複していて、参加できない可能性大です。
第２火曜日は、何かと用事が重複するんだよなぁ。第２回もそれで参加できなかったし。
ファンコミュニケーションズのスタッフの皆様、ありがとうございましたー
2012/10/19(金) 「Agile Conference Retrospective」に参加してきました。
Doorkeeper（告知サイト）
http://esminc.doorkeeper.jp/events/1771ツイートまとめ（ゆかりんノート）
https://yukar.in/note/ckFj1sAgile2012 Summary（ManasLink）
http://www.manaslink.com/articles/4796ハッシュタグ： #agile2012ja
会場は品川シーサイドの楽天タワーです。
参加者は40名くらいでしょうか。
先日10/3(水) にも「オブラブ Agile2012報告会」というイベントがあり、こちらも私、行ってきてブログにも書きました。
コチラ今回も2012年のAgile Conferenceの報告会という意味では、同じ趣旨のイベントですね。
ちなみに今年のAgile ConferenceはUSAのダラスで8月に行われました。以下は公式サイト。
http://agile2012.agilealliance.org/最初に楽天の吉岡さんより「Rakuten Technology Conference 2012」のご連絡がありました。
http://tech.rakuten.co.jp/rtc2012/ちなみにコチラは私の英語力が足りないため、参加は見送りました。無念。。。
以下は@TAKAKING22さんがツイートしてくださった当日のお写真。
以下、当日のセッションのメモ。（間違っているところあるかもしれません）
登壇者の自己紹介■大澤俊介さん・Atlassian社で働いている。
・Twitter IDは@Sean_SF。ショーン、というカッコいい外人みたいな名前でやっている。
・帰国子女とかと間違えられるが、日本生まれのショーネンです（笑
・Agile Conference 2012で、Atlassian社もスポンサーとなっていて、Nicholasも参加していた。
・今回Nicholasが来日するということで、@papandaさんに無茶振りして、今回のイベントに至った。
・今回は、ニックの通訳として参加している。
・ダバディ（元・日本サッカー代表監督のフィリップ・トルシエの通訳）のような、意訳した通訳ではなく、今回は直訳を目指して頑張りたい（笑
■Nicholas Muldoonさん（本日は皆さんからニックという愛称で呼ばれていた）
・Atlassian社で、2007年から働き始めていてGreenHopperという製品のプロダクトマネージャをやっていた。
・去年からアジャイルエバンジェリストとして活躍している。
・オーストラリア人だが、シドニーからサンフランシスコに転勤になって働いている。
・日本に来られて光栄。
■安井力さん・アジャイル自体は10年以上やっている。
・最近は、ボードゲームやカードゲームのようなものをつかってアジャイルの教育をやっている。
■上田佳典さん・NECビックローブで、新サービスの立ち上げを担当している。
・それと平行して、大規模なサービス開発をどんどんアジャイル化していこう、という試みもやっている。
■松元健さん・バンダイナムコスタジオで開発やっている。
・経営企画に近いポジションでスクラムマスターをやっている。
・スクラム道のスタッフをやっている。（スクラム道：
http://www.taoofscrum.org/contents/）
・スクラム道で今、みんなで本を書いている。来年のデブサミまでには、スクラムに関する本を出せるかな、と思っている。
■伊藤宏幸さん・スクラムマスターを社内でやっている。
・先ほどちょうど、認定スクラムプロダクトオーナーの研修を終えて、急いでココにきた。
・ManasLinkさんで、Agile2012の記事を投稿している。
http://www.manaslink.com/articles/4796■藤原大さん・楽天で、社内の開発支援の部隊でマネージャをやっている。
・最近は小さめのPJのサポートとかアジャイル導入のサポートとかやっている。
・来月11月にコミュニティでアジャイルのイベントをやる。
- AgileTourOsaka2012 in Minoh 箕面の滝からこんにちは
http://kokucheese.com/event/index/55362/ - Ultimate Agilist Tokyo - 集え、日本の活動家たちよ
http://ultimateagilist.doorkeeper.jp/events/1823 ■市谷聡啓さん・本日の司会。
・DevLoveというコミュニティを主宰している。
本日のアジェンダ■１．アナログツール vs デジタルツール
■２．日本 vs 海外
■３．Enterprise Agile
①トップダウン vs ボトムアップ
②チーム vs 会社
③現場 vs 経営 などなど
■４．アジャイル vs ウォーターフォール
■５．SI vs サービス
■１．アナログツール vs デジタルツール●アナログツールについて 安井さん・ホワイトボードと付箋とマーカーがあれば幸せ。
・簡単で、シンプルなところからスタートできる。
・チームごとに最適なツールを作れる。
- 自分たちの仕事を、ツールを媒体として改善していける。
●アナログツールについて 松元さん・Agile Conference 2012で、"ヘンリックのかんばん"がすごく人気だった。
→ 聴講者の食いつきが凄かった。
・ヘンリックのセッションが、なんでそんなに人気があるのか考えてみた。
- 過程がわかりやすく見ることができるからでは。
・デジタルツールは、何かしらの考えがあって作られている。
- 合うか合わないかでだいぶ変わる。
・アナログの利点： 試す、変える、俯瞰する
●デジタルツールのならではの良さ ニック・アナログは最高の方法。
・私はデジタルツール側のベンダー所属なので、発言にバイアスがかかってるので信用しない方が良い（笑
・デジタルは、自動で計算してくれる。
●市谷さん・アナログは簡単に始められるけど、めんどくさい。
- ベロシティとかの計算を自分でやらないといけなかったりする。
→ 何か工夫ありますか？
●安井さん・アナログだと、ベロシティ出すために計算したり、毎日やるのは大変。
→ 時間で見てるから大変になる。
・じゃあ、タスクを同じくらい時間かかる粒度に分けて、枚数で数えるようにした。
→ ボードを管理するめんどくささから、プロセスを変えて改善した。
●松元さん・仕事の仕方を変えるに慣れると、タスクの粒度が揃ってくる。
→ 揃ってくれば、数えるだけでいい。
・プロダクトバックログに載っているストーリがー終わっているかどうかが重要であるのであって、タスク自体の追跡はあまり意味がないのではないか。
●市谷さん・デジタル化のコスト（利用料金や習熟時間）や、利用しないというリスクを、どうリスクヘッジしているか？
●ニック・デジタルツールの習熟に時間がかかる、と言うが、アジャイル自体の習熟に時間がかかるので、それはデジタルツールに限った話ではない。
・アジャイルとは、journey（旅）である。常に学び続けなければならない。だから、デジタルツールを学ぶコストも当然、ずっと掛かっていく。
・デジタルツールは、スケールさせることができる
・デジタルツールに慣れてくると、タスクを完了させることに集中できるようになる。アナログのままだと、ずっとタスクを手で数えることをやらないといけない。
★結論：・ヘンリックの考えたかんばんは最強。
・アジャイルなら、デジタルツールも学ぶべき。
■３．Enterprise Agile ボトムアップ（現場から） vs トップダウン（経営層から）
チーム vs 組織 などなど ●伊藤さん・最近気になるのは、「アジャイルを売ろう」とするマネージャや営業が多いこと。
→ アジャイルって売り物ですか？というのがいつも疑問だった。
・「アジャイル開発手法」という表現に問題があるのではないか？
→ 日本だと、アジャイルは「開発の話」だと思われてしまう。
USAのアジャイルは、「テクニカルプラクティス＋マインドセット」の両方がセット。どっちか一方ではない。
・アジャイルは「開発手法」だと思われる故に、改善しないといけない本来の人たちが、「開発の話は、オレには関係ない」と無関心になっているのが問題である。
●上田さん大規模サービスも全部アジャイル化していこう、というコンセプトでやっている。
最初は未経験だったので、まず取り組みやすいといわれる新サービスからやった。
・まず新事業でアジャイルを知ろうとした。
・大規模チームも徐々にアジャイル化 ← いまここ
・エンタープライズアジャイルを実現したい。
自分にとってのアジャイルとはなんなのか、をしっかり考えることが大事。
まずはアジャイル開発とはなにか、を考えるところから始めてもいいのでは。
●松元さん・Agile 2012でMike Cottmeyerがレクチャーのセッションをやっていて、まとめっぷりが凄かった。
- 意思決定はトップダウンでやっていきましょう。
- 実際にどこから手をつけるか、といったら、開発チームから。（ボトムアップ）
・AGILEな組織をAGILEな考え方で作る。
・組織、手法、人、制度を順繰りに移行していく。
- まず、ちょっとチームを作る
- プラクティスを実験的にやってみる
- 良いとこ悪いとこをを知った上で、理解する。
これで1週。これを少しずつ範囲を広げながら続けていく。
・意思決定はトップダウンで、ボトムアップから始める。
・全体ロードマップや指標を整備してプログレスを取る。
●安井さん・アジャイルを広げていく過程で、どこかで壁にあたる。
・壁に当たる理由：アジャイルが「開発」だと思っている。
・ビジネスとかマネジメントとかになると、アジャイルは「開発」なんだから、こっちくんなという話になる。
・しかしアジャイルでは、ビジネスからフィードバックを得なきゃいけない。
でも、アジャルは「開発」の話だから、ということで、どこかで止められてしまう、という事象がおきる
・上の立場（社長と話ができるレベル）の人がアジャイルを理解してくれていると、壁を越えやすい。
・逆に開発の現場にいる人だけだと限界があるので、いろんな人を巻き込んで、いろんなアプローチで攻めるのが重要である。
-どこまで行くのか
-覚悟してるのは誰か
-アプローチはひとつじゃない
●聴講者からのコメント１ 開発者がビジネスサイドに寄り添うか、ビジネス側が開発側に寄っていかないかぎり、壁は越えられないのでは。
●聴講者からのコメント２ 「Do Agile」か「Be Agile」という話について。
↓
●伊藤さん・Do Agile
- アジャイルをする。いろんなプラクティスを使ってやる。
- あくまで「やる」だけ、そこで止まってしまう。
- 改善までは考えが及び難い。
・Be Agile
- 全体的な視点で改善を続けるのが、良いアジャイル。
- 「アジャイルであれ」
●安井さん ケントベックの本には「変化を包容せよ」と書いてあった。
●聴講者からのコメント３ 上の立場の人と意識が違うと、評価が変わってくるのでは、と思う。
アジャイルで現場が頑張っていても、上の立場の人の理解が無いと、「なに遊んでるんだ」となってしまう。
これまでに、上の立場の人に共有ができて、評価を変えれたことがあったか？
あったならば、どうやって改善したのか？
下々ががんばっても理解してもらえないと神々の評価に繋がらない。
アジャイルとしてうまくいくのか？
・藤原さん -上司とコンフリクトしたことがないのでわからない
-アジャイルは改善活動なので、上司に説明して理解を得た上でアジャイルを採用している。
-評価は全社員と同じ方法でやっている。特別なことはやっていないが問題は出ていない。
・ニック ボトムアップとトップダウンについて、2006年のオーストラリアでの経験の話をシェアしたい。
そのときは、スクラムを小さなチームで、Do Agileで始めた。
- 朝会をやる
- スプリントをやる
- etc
→ Do AgileからBe Agileになるまで、2年かかった。
別の例として、2万8000人いるような銀行でアジャイルの導入をやった。
大きな銀行でも、Be Agileになるまで何年もかかった。
●聴講者からのコメント４Be AgileとDo Agileの具体的な違いは何か？
・ニック Be Agileは、マインドセットの話である。
何のためにやるのか理解して、どうやったらもっとうまくやれるかを探して、改善し続けること。
その銀行では、CEOがアジャイルに理解を示して全社的に広げることができた。
●市谷さん開発もロクにアジャイルで出来ていないのに、組織をどうやってアジャイルにしますか？
AGILE 2012で見てきた具体的な話があれば、お願いします。
●藤原さん・Agile2012へ行ってみて、参加者の多くが「企業にどう導入するか」とか「どう組織を変えるのか」が難しいと困っていたので、日本とあまり変わりはないかな、と感じた。
・でも、海外のほうがやはりスピードが早い。
・一番初めにどうやったら良いかは、国によって解が違う。
-インドでは、まずトップを落とせ。
-自由そうな国では、ボトムアップでやらせてくれる。
→ 自社の組織文化に合わせてやるしかない。
楽天だと、ボトムアップでやらせてもらっているので、コンフリクトしていない。
逆に、トップダウンでやれ、と言われても、そこまでエンタープライズをいきなり導入するか、というと、やりかたがわからないのが本音
→ １つずつ考えて、Try and Errorでやるしかない。
・トップの理解は怖い。
- アジャイル＝早い、をどう捉えているか。
- 誤解を解くのは別で考えなければならない。
●上田さん・神々と下々の話で、意識の違いがでる原因として、アジャイルやることが目的、という風に神々に見えてしまうのがある。
・目的を実現するためにどうすればよいのかを神々の人に相談し、それで「アジャイルで解決できるかもしれないね」という風になれば、神々の理解も得られるのでは。
Agile2012で、Dean Leffingwellがエンタープライズアジャイルの説明をしていた。
http://www.manaslink.com/articles/4735（参考：市谷さんのレポート）
そこで、マインドセットの話が12個くらいでてきた。
開発のプラクティスとマインドは切り分けられない。
目をそらすのではなく、マインドセットから変えていく努力が必要だな、とそのセッションを聞いて感じた。
●市谷さんでも、マインドセットを変えるのは難しいですよね。どうすればよいか。
●安井さん・他人の考えを変えられるわけがない。自分から変わるしかない。
・自分がまず変わって周りに影響を与えると、周りも変わる。
●伊藤さん・マインドセットを変えようとするのではなく、自分から「変わりたい」と思わせることが重要。
・事例：チーム間でお互い殴り合いの喧嘩するようなチームがあった。
- 原因： お互いを批判する文化にいた。
- 対処： 批判するのをやめよう、もっとお互いしゃべっていいんだよ、とした
→ Facebookに意見を書いてお互いが見えるようにしましょう、とした。
→ 自分から意見を言うようになった。
→ お互い、あなたの言っていることがわかりました、というようになった
もっと話していいんだよ、と気付かせる環境を作ってあげるのが重要。
問題は、大抵がコミュニケーションミス、コミュニケーションロス。
お互いがもっと見えるよう、見せ合えるよう、アイデアをシェアできるようやってみれば、変わるのでは。
●聴講者からのコメント５神々の人は成果を求める。
数値化して、アジャイルやるといいことがあるんですよ、と神々に説明しなければならない。
数値をどうみせるか、いい方法ないか？有無を言わせない数字って出せるか？
ベロシティを神々に説明しようとしても、ベロシティって何？から始まってしまう。
●松元さんサービスは、小さく作って動かしちゃって数字を出している。
2年もかかるようなプロジェクトだと、成果というよりも、リスクがとても大きい。その案件が上手くいってるのかどうなのか、が一番、神々が知りたいこと。
神々にバーンダウンとか見せてあげると、対応をしてくれるようになる。
現状をきちんと見せる。嘘をつかない数字を見せる。
本当のリスクを踏んでいる人のとこに正しい情報が集まっていればいいのでは。
●上田さん工数だけ確保して、1ヶ月いくらという形で、何ヶ月か積んでおくスタイルの契約で、その範囲の中できちんとプロダクトを作って見せる、という開発をしているSIerがあった。
そこでは、KPIもチームの中で決めていた。
チーム毎にお客さんと納得した上でケースバイケースでKPIを作るのが良いと思った。
●ニックストーリーポイントを使って、マネージャを教育して、スプリントデモにマネージャを呼んで、実際どれだけストーリーを消化したか、話をするのはどうか。
●伊藤さん実際に、モノを見せるのがいいのではないか。
スプリントの最後のレビューで、作ったものをデモをする。ステークホルダーをお招きして、動くものを見せたら、それは立派な指標や成果になるのでは。
●藤原さん成果というと「開発生産性とは何か」みたいな話になってしまう。
そんなことを私が言われたら、「じゃ、今の生産性を出してみて」って言ってみる。
ベロシティというものを説明して、生産性の変わりにしていると説明する。
見せる化することが重要。
一番効果的なのは、「楽しそう、雰囲気がよい、リリース回数が多い」というのが評価される軸と思う。
一番お勧めなのは「リリース回数」。
何が良くなっているのかを焦点を絞って示す。
●伊藤さん「Legacy Mindsetからアジャイルへ」
Agile2012で、Dean Leffingwell氏のセッションが「Scaled Agile Framework」だった。
エンタープライズでアジャイルでやるための仕組みとかパターンを纏めている。
SAFでググるとヒットするのでそっちを見ると参考になる。
→
http://scaledagileframework.com/
■２．日本 vs 海外●上田さん・日本は、プロダクトオーナーの考え方が確立、浸透していない、と感じた。
・Agile2011で、LindaさんがProduct Discoveryを行うためのフレームワークを紹介してくださった。
→ 日本ではそういうのは弱いなぁ、やってないなぁ、と感じた。
・アジャイルってドキュメント作らないんでしょ、という誤解が日本にはある。
・日本だと、アジャイルの解釈が人によって大きく異なる。
●安井さん・Agile2012のような世界的なカンファレンスは日本では無いという意味で、日本はアジャイル普及してない。
・海外では、ITという枠を遥かに超えてアジャイルを普通にやっている。
・数としては日本は普及してない。
・日本だと、開発の話だと思われている
・日本だと、カンバンといったマネジメント系よりも、TDDとかCIとか技術的プラクティスは流行っている。
・日本だと、アジャイルコーチでお金を貰ってる人が少ない。
・日本の面白いところで、ソフトウェア開発と関係ない世界にアジャイルが普及してたりする。（事例：佐賀県庁のパスポート発行）
→平鍋健児さんが、「プロジェクトファシリテーション」という言葉でアジャイルをいろんなところで話していた影響もある。
●市谷さん海外だと、登壇する人とかはLLCとか自分の会社を作ってる人が多い。
●ニック海外は、日本のリーン開発とかトヨタの事例とかから学んでアジャイルに取り入れている。
海外は、日本がアジャイルの国だと思っている。
EUとかUSAとかでは、10年前からアジャイルが有効だと証明されていて、キャズムを超えている
でもEUとかUSAでも、アジャイルの普及は時間がかかっている。
日本はグラフでイノベーターの位置にいるから、普及にあと10年かかるかもしれない。
インドとかは英語が普及しているから、アーリーアダプタになるかもしれない。
中国では、まだアジャイルが始まってもいない。
●市谷さん日本も海外と同じくらい時間かけている。
なぜ10年経っても同じ位置にいるのだろうか。
XPユーザ会やケントベックの書籍は2001年くらいなので、10年は経っている。
●伊藤さん日本は、失敗してはいけない、というプレッシャーを感じすぎている。
USAのユナイテッド航空のシステムは、いつも落ちている。
それでも、いつものことだから、と気にせず運行している。
それに対して日本は失敗してはいけない、と恐れて一歩を踏み出すことを恐れている。
海外は成功事例も多いけど、失敗事例も多い。
でも彼らは失敗したことを、失敗ではなく学びと捉えてプラスにしようとみんなにシェアしている。
それに対して、日本は失敗を恥と捉えてしまう。
●聴講者からのコメント６IT技術者はどんな会社に所属しているか、という調査があった。
それによると、日本はほとんどがSIerで、USAでは半数がユーザ企業の情報部門にいる。これが日本と海外の発展の仕方を変えたのでは。
エンドユーザの近いところにいる海外では、アジャイルを適用しやすかったのでは。
日本はピラミッド構造で、よきにはからえ、で作らせる構造がこの10年間変わってきてないので、そこが原因では。
明るい兆しとして、楽天とかDeNAとかGREEとか、本業がITではなくてサービスの会社にエンジニアが移ることが加速してきているので、日本もアジャイルっぽくなっていくといいなぁ、と思っている。
●吉岡さんBe AgileかDo Agileか、という話で言うと、競争力がある会社は変化にadaptしているという意味でBe Agileだと思う。
トヨタがBe Agileというのは、圧倒的に車の生産に関して競争力を持っているから。
ある新しい車を作る時に、市場の調査からプロダクトが出てくるまでが、他の企業よりも遥かに早かった。だから変化に適応できた。
日本では、ITは受託開発がほとんどで、圧倒的に競争力がない。なのでBeingでもDoingでもない。
圧倒的に競争力を持っている会社があれば、それは結果としてBeing。
ユーザ企業かSIerという軸ではなくて、仮にGREEとかが競争力があるとしたら、手法としてより効率のよい開発をしている事例なのかな、と感じた。
同じ会社でも、Beignが上手くいってるところもあるし、ないところもある。
●川口さん海外＝英語圏。英語圏は、アイデアを持ってる人口が圧倒的に多い。
あっというまに英語でブログとかで伝わる。
日本では、一部の人がそれを見聞きして翻訳してから伝える。
その分、フィルタが入るので遅れているのでは。
●市谷さん確かにそのとおりだと思う。
Agile2012へ行くと、著名な人たちが最新の話を目の前でしてくれる。
日本だと、それが日本語に訳されて出てくるのを待っている状態。
そもそも翻訳されず入ってこないものもある。
●川口さん今日ニックと同じ時間を共有している、このような場の共有が、海外では普通に起きている。
●聴講者さんからのコメント７今、日本は高齢化社会で、部署によっては、10人いたら8人管理職だったりになる。
アジャイルを導入することによって、役割を再編成できるのでは。
マネジメントの人もコードを書けたりとか、アジャイルで再編成できるところが利点ではないかな、と思っている。
●及部さん私もAgile2012に参加したが、アジャイルとか関係なしに、上司やチームメンバとコミュニケーションやらないと、うまくいかないと感じている。
海外では、そこをすごくポジティブに考えている人が多いと思った。
難しく考えすぎずに、仲良く楽しくやっていいけばいいのでは、と思っている。
最後に「Why Agile？」と「Agile Conference」●安井さん
Why Agile？・自分が楽しく仕事がしたいと思ってたらアジャイル、XPに出会った。
・XPやりたいと思ったら、一人ではできないので、周りにも広げないといけない。
・XPと言い続けたら、徐々に回りに広がっていった。
・それやっていくと、マネージャとかお客さんとかまで広がっていく。
・ふと気づくと、「あれ？俺、何がやりたかったんだっけ？」と自問自答した。
→ 楽しく仕事したい、が原点で、それは「開発すること」だった。
・でも、今アジャイルが楽しい。もう一回再確認して、アジャイルコーチをしている。
・今でも、自問自答することがある。
Agile Conference・Agile Conferenceは大変。（体力、金銭、家庭）
・たとえ話：
おもちゃを買いに行くとき、商店街のおもちゃ屋に行くか、デパートのトイザラスに行くか、で考える。
近所のおもちゃ屋さんでも、欲しい物があることがわかれば、買うのは楽。
でも、トイザラスに行くと、思っても見なかったものに出会ったり、おもちゃがたくさんあることに刺激されたり、違った経験が得られる。
このたとえ話で言う「おもちゃ屋」とは、
・商店街のおもちゃ屋 ＝ 日本の勉強会とか
・デパートのトイザラス ＝ Agile Conference
Agile Conferenceは、世界中のアイデアの展示会であって、この中から好きなものを持って帰ってこれるすばらしい場所だと再認識した。
近場の勉強会とかイベントもすばらしいが、Agile Conferenceは、それとはレベルが違った価値が得られる。
●上田さん
Why Agile？上司から、やれといわれたから。
→ トップダウンでアジャイルが始まった。
もうひとつの理由として、ボトムアップの観点があった。
エンジニアとしてスキルを高めていかなくては、という危機感。
変化に挑戦（チャレンジ）するのは楽しい。
Agile Conference藤原さんに誘ってもらってAgile Conferenceに初参加したが、上司を熱意を伝えてわかってもらえて、会社のお金で参加できた。上司の説得もチャレンジの１つだった。
●松元さん
Why Agile？・技術をもっと磨きたい
・開発をもっとうまくやりたい
・プロジェクトをもっとよくしたい
・現場と経営を直結したい ← いまココ
・人材育成
Agile Conference・Agile Conference 2012は、まさにオアシスだった。
・運営者とか登壇者とかにギャップがなく、オープンな雰囲気をすごく感じた。
メアリー・ポッペンディークとかが受付で記録係やってたりする（笑
・色々と無茶をしても、案外なんとかなるもの。
・歩き続けることが大事。
●伊藤さん
Why Agile？・私の戦場だから。
・アーキテクトをやっていたが、プライドの高いプログラマと設計者との板ばさみになっていた。
・そこで、私がチームの交通整理役となって、人と人とを繋ぐコネクター役に価値があると信じてずっと頑張っていた。
・それでも、中途半端な奴、と言われてへこんでいた。
・後々、自分がやっていることがスクラムやアジャイルに行き着いた。
・そこが自分の居場所だと思うし、アジャイルで生きていこうと思っている。
Agile Conference 2012・最高のレジャーである。
・著名な人がどこにでもいて、話ができて友達になれる。
・心から溶け込める空気がある。
・行って、試して、おもしろい、と経験してもらいたい。
●藤原さん
Why Agile？アジャイルがやりたいから。
もともとSIerで働いて、開発生産性が～、とか言われていた。
これにどう回答していこうか悩んでいたが、マッチしたのがたまたまアジャイル開発だった。
今も試行錯誤してるが、答えはない。やって気づくしかない。
他にいい方法が思いついていないので、このまま続けて行こうと思っている。
Agile Conference 2012・最初は会社の命令で行かされるとあって、嫌だった。
・でも行ってみて凄くよかった。
・でも、その良さは言葉では伝わらない。なので、今年は市谷さんと及部さんを連れて行った。
・よし、みにいこう、って一歩を踏み出せる人がもっと増えればいいなぁ、って思っている。
●ニック
Agile Conference・私のAgile Conferenceは、2009年のシカゴから始まった。最初は学ぶほうだった。
・行くと、誰もがオープンで、半分の人が実践者で、他にも学習者がたくさんいた。
・今年2012年のAgile Conferenceはすごく素晴らしいものだった。
・来年2013年のAgile Conferenceは素晴らしいイベントになる。ビジョンを得るために行くべき。
●市谷さん
Why Agile？値打ちがあることを作りたいから。
一つの在り方がアジャイルでは。
●大澤さん・今日は通訳で失敗した。でも、これは失敗じゃなくて学び。
・無茶振り、ってのを英語に訳すのが大変だった。
●市谷さんのclosing以下のイベントをやります。
Ultimate Agilist Tokyo - 集え、日本の活動家たちよ
http://ultimateagilist.doorkeeper.jp/events/1823
感想：日本でアジャイルの先駆者とでも言える方々が、海外の本場で何を見て、何を感じ取ってきたのか、非常に興味深く聞かせていただきました。
こーゆうイベントは良いですねー。Agile Conferenceに行けなかった人に情報を共有してくださるのは、ほんとありがたいです。
あと、英語、やっぱ大事！ニックのリアル通訳、大澤さんと安井さん、カッコよかた。
英語の話はセッションの中でも出ましたが、知見を広げるためにはやっぱ必要だなあと思いました。
オレもいつか、Agile Conferenceとかで登壇できるようなエンジニアになりたい。
ただ、当然それはすぐには無理で、身近なトコから一歩を踏み出して行こうと思います。
企画者さん、運営者さん、登壇者さん、会場提供者さん、皆様ありがとうございました。
2012/10/16(火) 「集合知プログラミング勉強会 第2回」に参加してきました。
Atnd（告知サイト）
http://atnd.org/events/33080場所は東京駅の八重洲南口から出てスグの株式会社リクルートキャリアです。
参加者さんは25名くらいでしょうか。かなり出席率が高かったようです。
今回の勉強会で使用させていただいた部屋、すごかったですねー。
全席にマイクとPCが備え付けで、輪のように席が並んでいて、その真ん中にモニタが2台、
部屋の前にプロジェクタが1台、という。。。
なんか、国際会議でもするかのような部屋でした。
この勉強会は、O’Reillyより刊行されている「集合知（collective intelligence）」をテーマにした
集合知プログラミングがテーマとのこと。
というか私、この日、書籍まだ買ってませんでした。。。
というのも参加申し込みしたのが当日の昼間でして、仕事が終わってからO’Reillyのサイトから
PDFをダウンロードして、一通り読んでソース写経してから参加した次第なのです。
ちなみに、O’Reillyのサイトに2章までのPDFが無料で公開されているので、それ印刷して読みました。
■PDF ：
ftp://ftp.oreilly.co.jp/9784873113647/PCI_sample.pdf■ソースコード ：
http://examples.oreilly.com/9780596529321/この日はサッカー日本代表 vs ブラジル戦を家で観戦しよー、と思ってたのですが、この勉強会が以前からやっぱ
気になってて、当日直前に申し込んでしまったのでした。。。
なにより、Pythonを実践で学べそう、というのがデカかったです。この本、コードはPythonなのです。
先週も
エキスパートPythonプログラミング読書会に参加しましたが、Pythonを今年から学び始めたので、
ちょうどいい機会だなー、と。
■2章 「推薦を行う」今日は2章が範囲でした。2章を前半と後半に分け、二人の方が発表くださいました。
前半： @millionsmile さん ■githubに２章前半のソースとかをmillionsmile が公開している。
https://gist.github.com/3887602■Dictionary型 { } ってメモリをムダに使って非効率かも？
■P.10の、距離の計算式が間違っている。正しくは以下。
>>> from math import sqrt
>>> sqrt(pow(4.5-4,2) + pow(1-2,2))
1.118033988749895
|
■P.11の一番上の計算式も、同様に間違っている。正しくは以下。
>>> 1/(1+sqrt(pow(4.5-4,2) + pow(1-2,2)))
0.4721359549995794 |
■P.11の下の方のソースでreloadを使っているが、初回読み込みでは使えない。正しくは以下。
>>> import recommendations
>>> recommendations.sim_distance(recommendations.critics,
... 'Lisa Rose','Gene Seymour')
0.14814814814814814 |
■P.13の上から３行目や４行目に、0.4や0.75という数字が出ているが、本の最後のほうの付録P.341に
計算式が書いてあるらしい。（書籍をまだ買ってないので確かめられない。。。）
後半： @hid_tanakaさん 実際にライブコーディング形式での説明が行われました。
Pythonに関する説明と質疑応答@terapyon さんによるLT「Pythonお悩み相談その場で解決」です。
Pythonのバージョンpythonは2系列と3系列の2種類がある。
3系列は西暦3000年くらいにできたらいいよね、と言われていた。
python3を業務で使っている人はほとんどいない。
というのは、python2でできたことがpython3でできないことがあるから。
python3が、python2.7より性能が悪いこともある。
ただpython3は日本語の扱いが良くなっている。
いつpython3に移行すれば良いか、というと、python2系で使っていたモジュール類がpython3系に対応してからだと思う。
python2.4がpython2.6で動かないケースは稀なケース。
python2.7で動くように作ると、それより前のpython2.Xのバージョンで動かなくなることがある。
python2.7より前のバージョンで動いていたのが、python2.7で動かなくなる、ということはほとんどない。
python3になって、python2の古い書き方を捨てたりしているケースがある。
たとえば、print文とか、import文（相対import）とか。
PythonにはPEP8という公式のコーディングスタイルがある。
プロンプトにコード書くとき、どこで改行すべきか？→ .（ドット)の前で切る。
pythonの詰まりポイントpythonに直感的に考えたことをコードに書きにくい、というのを聞く。
pythonの詰まりポイントはどこか？
pythonは模擬コードに近い。ハマりポイントはたくさんある。
例えばpythonで正規表現を使いたい場合、そのままでは使えない。
正規表現オブジェクトを作ってコンパイルする必要がある。
pythonの利点の１つは、関数でそのままかけること。
クラス使ってオブジェクト指向で書け、とは強制されない。
標準モジュールが充実しているのも利点の１つ。
PythonのモジュールPyPI （読み方：ぱいぴーあい or ぱぴぱい or ぱいぴー）http://pypi.python.org/pypiPython Package Indexの略らしく、Pythonパッケージを登録したりダウンロードしたりできるPython版CPANのようなものらしいです。
24000パッケージくらい登録されており、良いものも悪いものも登録されている。
PyPyhttp://pypy.org/Python 開発者がPython実装のハックを行うためのPython 記述された Python 実装系らしい。(by Wikipedia)
要するに、PythonでPythonを実装するプロジェクトらしいです。
PyPyを使ったほうが普通のPythonを使うより速い時がある。
NumPyhttp://numpy.scipy.org/Pythonプログラミング言語の拡張モジュールであり、大規模な多次元配列や行列のサポート、これらを操作するための大規模な高水準の数学関数ライブラリを提供するものらしい。(by Wikipedia）
Jythonhttp://www.jython.org/Jython(旧称JPython)は、プログラミング言語PythonのJavaで書かれた実装とのこと。（by Wikipedia）
ちなみにPythonの普通の実装はC言語らしい。
Pythonのパッケージやモジュールのインストールeasy_installとかpipといったツール（コマンド？）がある。
pipでインストールできるならpipを使ったほうが良い。
Pythonは何が優れているか？Pythonは読みやすい、簡単に書きやすく、メンテナンスしやすい。
Rubyと比べて、同じような感覚で書けると考えている。
モジュールが揃っている。科学計算ライブラリとかもある。
やりたいことが手軽に出来る。
Pythonでしかできないことがあるか？基本的に、この言語しかできない、ということは無いと思う。
自分が使いたいモジュールがその言語にあるかどうか、が基準。
自分が使いたいライブラリがPythonにしかにないので、Pythonを使っている。
WindowsでPythonを使おうとしたら、何を使うのが幸せになれるか？Windows用の標準インストーラを使うのが良い。
Windowsで苦労するのは、NumPyとか。
この業界は、Mac使いとかLinux使いとかが非常に多く、Windowsは苦労するかも。
WindowsはC言語の処理系がデフォルトで入っていないので。
お勧めのWebフレームワーク３大フレームワークがある。
① Django
② Flask
③ Pyramid
① Djangohttps://www.djangoproject.com/Pythonで実装されたWebアプリケーションフレームワーク。 model-view-controller のMVCデザインパターンに緩やかに従う。(by Wikipedia)
② Flaskhttp://flask.pocoo.org/Python用の、軽量なウェブアプリケーションフレームワークの一つ。Werkzeug WSGIツールキットとJinja2テンプレートエンジンを基に作られている。(by Wikipedia)
③ Pyramid（旧：Pylons）http://docs.pylonsproject.jp/projects/pyramid-doc-ja/en/latest/index.html小さく、速く、堅実 (down-to-earth) な Pythonウェブアプリケーション開発フレームワーク。Pylonsプロジェクトの一部として開発されているらしい。
他にもTornadoとかZopeとかもある。
④ Tornadohttps://sites.google.com/site/tornadowebja/FriendFeed で使われていたスケーラブルでノンブロッキングなWebサーバとツールのオープンソース版らしい。
⑤ Zopehttp://zope.jp/オープンソース＆フリーのWebアプリケーション・サーバ。
これまではPythonのフレームワークは乱立していたが、最近は大体①と②が主流になっている。各フレームワークの欠点と利点を討論したセッションがPyCon JP 2012にあったので、参考になる。
http://2012.pycon.jp/program/panel.htmlPythonのクラウド① Google App Enginehttps://developers.google.com/appengine/?hl=ja② Herokuhttp://www.heroku.com/Amazon Web Services（AWSのIaaS上に構築されたPaaS。Ruby以外にも、Pythonとかにも対応したマルチ言語なプラットフォームになっている。
③ Windows Azurehttp://www.windowsazure.com/ja-jp/http://www.windowsazure.com/en-us/develop/python/Pythonももちろん動作する。
GAEが強すぎて、Pythonの他のクラウドサービスが出てこない。
感想：思い立って当日申込で参加したイベントでしたが、Pythonの勉強にもなるので次回以降も参加しようと思います。
集合知というものも合わせて学べそうなのも良いですね。
ということで、ようやく（中古で）本買いました。ちゃんと写経しないと。
運営者さん、発表者さん、参加者さん、ありがとうございました。
2012/10/13(土) 「第5回 スタートHaskell2」に参加してきました。
PARTAKE（告知サイト）
http://partake.in/events/c18d7583-75b8-45e9-990d-041215c1fe29#togetter
http://togetter.com/li/389173以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
場所は IIJ 大会議室 (17階)です。参加者は60人くらいでしょうか。
今回は以下の2章が対象範囲です。
・10章： 関数型問題解決法
・11章： ファンクターからアプリカティブファンクターへ
特に11章のアプリカティブファンクターは、モナドの謎を解き明かす鍵（？）になるそうです。
あまり予習時間は取れませんでしたが、一読し、可能な限り本のソースコードを写経してから参加しました。
10章： 関数型問題解決法
（↑クリックすると発表資料に飛びます↑）
発表者は @dekokun さんです。
ソースコードはgithubに公開してくださっています。親切設計ですねー。
https://github.com/dekokun/StartHaskell2-Chapter10■P.216のsolveRPN関数で、たった1行追加するごとに計算機能が1個増えるのはHaskellの威力かも。
■P.225に runhaskell コマンドが出てきてるが、初めて知った。。。便利ですねー
新しい何かを紹介する章ではなく、これまでの章の機能を使って課題を解決してみる、って位置づけの章ですね。
いつかスラスラとこんな課題をHaskellで解けるようになりたい。。。
11章： ファンクターからアプリカティブファンクターへ 発表者は @UsrNameu1 さんです。以下、メモ。
---
■Applicativeはまずこれを読んで使い方を覚えるのが良い。理屈を理解するのは、あとからで良い。
・Applicativeのススメ
http://d.hatena.ne.jp/kazu-yamamoto/20101211/1292021817 by @kazu_yamamoto さん（ツイート）
■発表資料のP.7にあるCASE3が、Applicative Functorで一番大事な本質。
line'という変数を無くせるのが良いところ。これを無くすためにFunctor則がある。
■fmapは<$>という記号を使うのが流行とのこと。以下２つは同じ意味。
①
line <- reverse <$> getLine ②
line <- reverse `fmap` getLine■Listのmap
map :: (a -> b) -> [a] -> [b] は、以下の構文糖衣である。
map :: (a -> b) -> [] a -> [] b■この章に出てくる「文脈」という単語について。
ParserとIOはくっつかない。それは文脈が違うから。
例えば、おもちゃのブロックで、レゴ社のブロックはレゴ社のブロックにしかくっつかない。
ここで「レゴ」ってトコが文脈にあたる。
・「IO」の文脈は、副作用を起こすことができる、ということ。
・「Maybe」の文脈は、失敗するかもしれない、ということ。
・「List」の文脈は、非決定的な計算ができる、ということ。
演習問題10章と11章の発表の後は、毎度恒例の演習タイムです。
・10章の演習問題：
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise10・11章の演習問題：
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise11---
11章■ファンクターを使って書き直す その１main = do
xs <- getLine
let ws = words xs
mapM_ putStrLn ws |
↓ ファンクターを使って書き直す ↓
main = do
xs <- fmap words getLine
mapM_ putStrLn xs |
■ファンクターを使って書き直す その２main = do
xs <- getLine
let n = sum $ map read $ words xs
print n |
↓ ファンクターを使って書き直す ↓
main = do
n <- fmap (sum . map read . words) getLine
print n |
■モナドをアプリカティブに書き直すmain :: IO ()
main = do
putStrLn "What's your name?"
name <- getLine
putStrLn $ "Hello, " ++ name |
↓ アプリカティブに書き直す ↓
import Control.Applicative
main = do
putStrLn "What's your name?"
putStrLn =<< (++) <$> return "Hello " <*> getLine |
■GHCIで
:set prompt > と打つと、長いプロンプト文字列が > に変更される。
importをたくさんしてるときに便利かも。
■パーサーコンビネータの演習は、私の頭脳では着いていけず。。。
LTタイム演習タイムの次はLTタイムです。
LT1 「Offline Hoogleで何処でもはすはす」 発表は @master_q さんです。
ユーモア溢れるハイテンションLT。あと、Debian、今日もやっぱ出ました～。内容も実用的です。
LT2 「Haskell と Scala」
（↑クリックすると発表資料に飛びます↑）
発表は @xuwei_k さんです。
私、Scalaは
ちょっと前の勉強会で触ったくらいです。Scalaも、もっと勉強してみたいな。
Scalaで型を扱うのは、Haskellに比べて大変そうですねー
LT3 「Haskell で AWS」発表は @seizans さんです。
・会社でHaskellの仕事を作り出したい。部署の25％くらいのエンジニアはHaskellが使える。
→ ということで、実際にHaskellの仕事を社内で作り出して、やってみた。
・HaskellからAWSのAPIを操作できるようにするライブラリを一人のエンジニアに作成してもらい、公開した。
http://hackage.haskell.org/package/aws-sdk・開発してみて、やっぱJavaよりもHaskellの方が生産性が良いとのこと。
（例： Javaだと3API/日、Haskellだと10API/日 etc）
Haskellで仕事、俺にはまだまだ、とても無理そうです。。。
でも、いつかHaskellをマスターして、はすはすできるようになりたい。
---
しかし、どのLTもとても濃い内容で充実した内容でしたねー
あと最後に @kazu_yamamoto さんからフットサルのお誘いがありました。↓ですね。
品川でゆるいフットサル(2) 品川でゆるいフットサル(3)
★感想：
アプリカティブファンクター、難しいです。。。時間無くて、11章の最後の方まで読めてないトコあるし。
これは復習しないと、以降のモナドとかで間違いなく躓きそう。
もっと早くから予習に着手しないと、ということで反省。
運営者さん、発表者さん、ありがとうございました。
2012/10/12(金) JBL 日立サンロッカーズのホームゲーム開幕戦を観戦してきました。
場所は大田区総合体育館です。
金曜日の平日だったんですが、試合開始は19:15なので18時過ぎに退社して向かいました。
この体育館、ウチの職場から30分くらいで行けるので便利ですねー。しかも新しくて設備も良く、綺麗です。
ちなみに私、ここ3年くらい、神奈川～東京～千葉近辺で行われる日立サンロッカーズのホームゲームは
かなりの割合で観戦しに行っています。
というのも、日立製作所の従業員はホームゲームを無料観戦できるのです。（全試合が無料では無いけどね）
この日の相手はアイシンシーホースでした。ここ数年は優勝か準優勝のどちらかの強豪です。
以下は選手紹介の場面。
しかし平日ということこもあり、会場は空いてました。。。
もっとお客さん入っても良いのになぁ。そのほうが盛り上がるし。
試合はというと、第3Qまで日立サンロッカーズがリードしながらも、第4Qにアイシンに逆転され、
そのまま3点差で敗れました。。。
やはりアイシンは今年も強いです。開幕3連勝。
特に、インサイドからのパスアウトによるアウトサイドシュートのフォーメーションが素晴らしいです。
外角にパスを出した後、2～3人が素早くサイドに展開してスリーポイントシュート、という流れは
なかなかディフェンス難しいです。
ちなみにパナソニックも開幕第1戦、第2戦と軽快なパスアウトからの3Pシュートの流れがすごく良く、
日立はアウェイでパナソニックに開幕2連敗でした。
そして日立はこの日もアイシンに負け、開幕3連敗。。。
でも、翌日の10/13(土)はアイシンに大差で勝ち、今シーズン初勝利！通算は1勝3敗になりました。
来週も代々木第二体育館でホームゲームがあるので、見に行く予定です。
佐藤選手と大屋選手の引退セレモニーもあることだし。
しかしPGの佐藤の引退は惜しすぎる。屈指のゲームメイクとスティールは圧巻でした。
あと、アキレス腱を断裂しながらも復帰して活躍してる佐藤選手の姿は、私をスゲー勇気付けてくれました。
というのも、私も佐藤選手とほぼ同時期に、バスケやっててアキレス腱を断裂してしまったのでした。。。
あの時はホント、日々の生活がマジ大変でしたよ。。。
佐藤選手と大屋選手、これまでお疲れ様でした。
俺もアキレス腱断裂から復帰した後、フルマラソンを2回とも完走できたし、バスケも再開したいと思います。
あと、みんなもJBLの試合を見に行って盛り上げよう！JBLの公式サイトは以下参照です。
http://www.jbl.or.jp/今年も待ちに待ったシーズンが開幕し、これから週末が楽しみです！
2012/10/11(木) 「アジャイルサムライ読書会 横浜道場 "現実と向き合う"」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/1811
「アジャイルサムライ横浜道場」は以下の書籍をターゲットとした読書会です。
今回は第８章「アジャイルな計画づくり：現実と向きあう」から読書しディスカッションを行いました。
ちなみにウチのチームは５人で、模造紙はこんなカンジでした。
以下、メモ。
---
■チームに専門性が高い人が１人しかいないのは良くない。
→ ２～３人ができるようにペアプロとか設計とかを一緒にやるのが良い。
■タスクに個人名を割り当て、それを元に遅れを個人名で責めるようでは、まずチームがダメ。
■ガントチャートの弊害
・修正履歴が残せない。
・ガントチャートを書くと、それが正確なスケジュールだと一人歩きして、誤解されることがある。
・作業が個人単位になり、チーム意識が薄れる。
■計画はコミットメントではないが、契約はコミットメントである。
■期日固定とフィーチャーセット固定で、お互いがクロスするタイミングがある。
まずフィーチャーを減らしていき、これ以上フィーチャーを減らせない、というトコまで来たら
次は期日を延期するしかなくなる。
■期日が絶対、という場合がある。
例えば、クリスマス用の商品をクリスマス後にリリースしても、それは意味を成さない。
---
大体こんな感じの話がウチのチームで出ました。
この章は、アジャイル特有の重要な概念がけっこー満載で出てきますよね。
なので、１スプリント１５分の４本では、どうしても議論する時間が足りないカンジを受けました。
もっといろいろ議論する時間が欲しかったです。
あと、この章を更に詳細に扱った書籍としては、以下がおススメだと思います。
ディスカッションの最後に纏めの時間が取られ、いつものように各チーム発表→KPTの流れとなりました。
んで、そのあとは懇親会です。参加者さんといろいろお話しながらピザとビールを戴きました。
懇親会の最後に、道場主の@tw_takubonさんから「Scrum Alliance Regional Gathering Tokyo 2013」のアナウンスがありました。
http://scrumgatheringtokyo.org/2013/2013年1月15日(火)、1月16日(水)に実施されるとのことで、10月中旬から申し込み開始とのことで、ちょうど開始されたトコですね。
あと次回は、埼玉道場＆横浜道場＆DevLove道場の3道場合同開催だそうです。
2012年10月31日(水) 19:30から日本オラクルで、タイトルは「関東三道場共催 "先鋒、前へ！" 」だそうな。
http://partake.in/events/c58825a9-c0c0-4097-b853-2b15a1411fa4こちらは既に申し込みしました。
運営者さん、参加者さん、今回もありがとうございました～
2012/10/9(火) 「エキスパートPythonプログラミング読書会 第二期 10」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/911/togetter（ツイートまとめ）
http://togetter.com/li/387248場所は目黒のバリストライドグループです。
今回は「第8章 コードの管理」が対象範囲でした。
最初に、バージョン管理システム（VCS）のお話が出てきます。
中央集中型システムはCVSやSubversion、分散型システムはGit, Mercurialあたりが有名ですかね。
んで、この本はMercurialに焦点を当ててます。
しかも今日はMercurialのコミッターである藤原克則さん（@flyingfoozy）さんも参加されてました。
私、Mercurialは使ったことなかったので、この本が初でした。
んで、実際に本に沿ってMercurialをUbuntu Linuxにインストールし、動かしてみました。
■１．Mercurialのインストールまず、UbuntuにMercurialをインストールします。
apt-get install mercurial
|
■２．リポジトリへファイルをコミットんで、本に沿って設定を進め、リポジトリを作成します。
次にファイルをリポジトリにコミットしようとすると、以下のエラーが表示されました。
「ユーザ名が未指定です」とのエラーメッセージを元にググって原因を調べると、どうやら
設定ファイルにユーザ名を記載しておく必要があったようです。
ホームディレクトリに .hgrc というファイルを作成し、以下を追記することでエラーは出なくなりました。
■３．簡易Webサーバの起動とリポジトリ閲覧以下のコマンドで、Mercurial自身が持つ簡易Webサーバが起動し、リポジトリをブラウザから閲覧できます。
■４．Webサーバ（Apache）の設定MercurialのCGIスクリプトを実行するため、Webサーバを設定します。
Apacheのインストールが必要になりましたので、以下のコマンドでインストールします。
次に /home/mercurial/atomisator/apache.confファイルを作成します。
↑の黄色い線の部分ですが、本から一部設定を変更しています。hgwebdir.cgiでなく、hgweb.cgiとしました。
hgwebdir.cgiが無かったからです。これで大丈夫みたい。
作成できたら本のとおり、 /etc/apache2/sites-enabled/の下にシンボリックリンクを設定しました。
あと、/home/mercurial/atomisator/hgweb.cgi を以下のように修正しています。configファイルのパス修正。
こうしないと怒られます。
あと、本のとおり /home/mercurial/atomisator/hgweb.config を作成します。
■５．MercurialのCGIスクリプトをApache上で実行これらを設定後、http://localhost/hg にアクセスすると、以下の画面が表示されました。
ちゃんとMercurialのCGIスクリプトがApache上で動作しているようです。
この辺までが、実際に自分で本を写経して、Mercurialを触ってみた内容でした。
以下は、読書会のメモ。
■SubversionからのVCS移行で、bzrにするかhgにするかのツイートまとめ
togetter:
svnからの切り替え先にbzrを検討するなど（最終的にはhgになった‥）■Mercurialの要望とかは、ハッシュタグ #mercurialjp へツイートするとMercurialコミッターさんが拾ってくれるらしい。
■Git vs Mercurial
・GitとMercurialは、用語が対応してないので注意が必要。
・SubversionとMercurialは、用語とかコマンドとかが似ている。
→ SubversionからMercurialへの移行は、Gitへの移行より楽かも？
・Mercurialは、コマンドで簡略なことしかできない。
→ 人にMercurialを教えるのは楽かも。基本的なことしか最初はできないので。
・GitとMercurialでの違いで大きいのは、ブランチ戦略。
・Mercurialは、「標準」と「拡張（エクステンション）」がある。
- Mercurialは「標準」のままでは使えないようになってる機能がけっこうある。
- 初心者が触らなくても良いところは、「標準」では提供してない。
- 「拡張」を有効にすることで使えるようになる機能がある。
・Mercurialは、GUI（TortoiseHg）が使いやすい。
・Gitは、Githubが使えるのが大きい。Githubが使えないと、Gitの価値は軽減する。
・Gitは学ぶのが大変。
・GitはWindowsだと使いにくい。
■Mercurialのコマンドはメッセージが100％日本語化されている。
set LANGUAGE=ja と設定すると、Mercurialのプロンプトが日本語化される。
■Mercurialのコマンド実行時に -v オプションを付けると詳細なマニュアルが出る。
（例：hg -v help add）
■8.2節で紹介されている継続的インテグレーションツールのBuildbotは使わないほうが良い。
セットアップが大変なので。ニーズが発生したときに触るくらいで良い。
普段は、継続的インテグレーションツールとしてJenkinsを使うのが良い、とのこと。
■清水川さんの「Python Developers Camp 2008」でのテスト自動化に関する発表スライド
今日の読書会でチラッと触れられていたスライドです。Buildbotとか、いろいろ出てきてますねー。
■10月にTokyoMercurialという勉強会がある。
TokyoMercurial#6 :
http://connpass.com/event/1162/■PyCon JP 2012で「分散バージョン管理システムの組織化」というセッションがあった。
http://2012.pycon.jp/program/sessions.html#session-15-1430-room230-ja （セッションの動画とスライドが置いてあります）
■継続的インテグレーションは「Travis CI」が便利らしい。
Travis CIってのを始めて知りました。
どうやらGitHubのリポジトリをビルドして結果を通知してくれるWebサービスのようです。
Travis CI：
https://travis-ci.org/
懇親会＆LT読書会終了後は、その場で懇親会です。この日はお寿司とピザでしたー。
あと、希望者のLTタイムがありました。どのLTも面白くて興味深かったです。
LT1 @Alice1017さんの「蜘蛛の巣から抜け出すには？」 LT2 @hirokikyさんの「新卒から半年で会社辞めた」
（写真は @takanory さんのツイートより）
LT3 @tfmagicianさんの「Scrapyネタ」・ScrapyはPython製のオープンソース・ソフトウェアらしく、Webサービスから必要な情報を抜き出したり、自動操作をしたりするスクレイピングと呼ばれる技術らしい。
参考：
http://www.moongift.jp/2009/10/scrapy/・Scrapyの公式サイト：
http://scrapy.org/・Rubyだと、Nokogiriとかが該当するみたい。
http://route477.net/rubyscraping/★感想：今回はPython自体というよりもバージョン管理しシステム、特にMercurialメインの会でした。
最近は自分もSubversionとかJenkinsとかを使ってるし、Gitとかにも興味あったので、Mercurialの話は
とても興味深かったです。
GitとMercurialの比較の話とかもいろいろ聞けたし、Mercurialコミッター藤原克則さん（@flyingfoozy）さんの生の話とかはとても興味深かったです。
運営や発表の皆さん、ありがとうございました。次回も楽しみにしてます。
2012/10/3(水) 「オブラブ Agile2012報告会」に参加してきました。
DoorKeep（告知サイト）
http://esminc.doorkeeper.jp/events/1708Togetter
http://togetter.com/li/383842ゆかりんのーと
https://yukar.in/note/ckFkifAgile2012公式サイト
http://agile2012.agilealliance.org/
会場は麹町のKDDIウェブコミュニケーションズです。参加者は50人くらい？でしょうか。応募は満員でした。
周りを見渡すと、見知った顔が非常に多いです。
アジャイルサムライ横浜道場とか、Devlove道場の常連さんとか。
今回、Agile2012の報告をしてくだった登壇者は、以下の3名の方です。
・西村直人さん
・安井力さん
・市谷聡啓さん
また、司会進行は 角谷信太郎さん です。
登壇者さんと司会者さんの紹介は以下のイベント告知サイトに説明があります。
DoorKeep（告知サイト）
http://esminc.doorkeeper.jp/events/1708登壇者さんも司会者さんも、みなさんアジャイル界隈では超有名人ですねー。
私も「アジャイルな見積りと計画づくり」と「アジャイルサムライ」は読みましたし、
DevLove主催の勉強会にも参加してますし。
なお「Agile2012」とは、アメリカのダラスで8/13～8/17に開催されたアジャイルの世界的なイベントです。
ちなみに参加者は1600人くらいで、日本からは27名が参加したそうです。
Agile2012公式サイト
http://agile2012.agilealliance.org/以下、メモ。
■懸田 剛さんによるAgile Conferenceの紹介
・愛媛県在住
・永和システムマネジメントで働いていたが、愛媛でカルチャーワークスという会社を起業
・Agile Conference 2008で登壇（安井さんと木下さんと発表しに行った）
・XPのカンファレンスが纏められてAgile Conferenceになった
・アジャイルやってる人が集まってワイワイ騒ぐ会
・参加者の25％くらいが登壇してしゃべる（しゃべる人の割合が非常に多い）
・1週間ぶっ通しでアジャイル漬け
■Agile Conference 2012へ行く前と行った後の気持ちの違い●西村さん
・行く前：
今回初めて参加。一回くらい行ってみたいな。
・行った後：
もう一回くらい行ってもいいな。
●安井さん
・行く前：
- 3回目の参加。
- どうせ行くんなら自分のセッション発表しないと意味無いと思った。
- 二人の引率役として参加。
・行った後：
- 風邪を引いて1ヶ月くらい直らなかった。体力ないと辛い。
- 大御所たちと会ったり話きいたりして刺激を貰った。
●市谷さん
・行く前：
英語が不得意。誰とも話をしないで行こう、と誓って行った。
・行った後：
2013年にナッシュビルであるカンファレンスで登壇してみようと思った。
●角谷さん
・自己紹介：
Rubyで書く人が好きな人を手懐けてアジャイルやる。
■やってきたこと●安井さん
・8/13～8/17の1週間くらい。引率業。
・大御所の中でも、この人の話が聞きたい
-
リンダ・ライジング（Linda Rising） -
ロバート・C・マーチン（Robert C. Martin）オーラがある人たちが向こうにはたくさんいて、空気を共有してくることが価値。元気の素になる。
リンダなんかは、年をとっても元気というイメージを植えつけたい、というカンジで、ほんと元気。
●市谷さん
・楽天の藤原さんと及部さん、オージス総研の伊藤さんと4人で行動を共にした。
・Agile Conference 2012には、日本人は27人が参加。
・アジャイル事業を進めていく立場なので、向こうでどういう課題があって、
どういう解決を編み出しているのか、を盗んで日本で活かしたいと思った。
・ManasLinkでAgile 2012の現地レポートを4人で書いた。合計30本くらいのうち、市谷さんは4本。
コチラ →
Agile2012 Summary・英語が不自由なので、誰とも話をしないでおこうと思ったが、これから1年英語勉強をするという誓いを立てた。
●西村さん
・行く前のミッション
① 腕試しをしてみたい（セッションとか）→ やってきた
② 日本と海外は違う、と言われるが、そんなことないだろ、と思ってる。
→ 本当にそうなのかの確認しに行ってきた。
③ 今、本を書いている。
→ アジャイルサムライの著者のジョナサンに、前書きを書いてもらう約束を取りに行ってきた。
どれもミッションコンプリートして帰ってきた。
---
①について。Open Jamというフリーのセッションスペースがあり、飛び入りで喋れる。
参加者1600人くらい収容の大きなホテルの、すごく広い廊下をぶち抜いて、Open Jam用スペースになってる。
希望の時間にこれやる、と書いておけば、その時間になにをやってもよい
廊下の片隅に椅子とかプロジェクタとか、ホワイトボードが置いてある。
Open Jamの写真 →
[8/13] Agile 2012 始まる Agile2012 現地レポート(6)西村さんがやったのは、30分くらいのオリジナルのワークショップ。
タイトルは「書き取り」。外国人の方に漢字の書き取りをしてもらう。
内容はすごくショボくて、黒歴史。でも、10人くらい参加してくださった。
西村さんのブログにも写真があります。
ヲトナ.backtrace 「Agile 2012 の報告会をやります #oblove」●安井さん
・Open Jamでボードゲームみたいなワークショップを作ってやってきた。
・テーマは「プロダクトバックログ」
最初に１からかいてやるのがいいのか、流動的にやるのがいいのか、を体験するワークショップ（ゲーム）
・2回やって、1回目は3人、2回目は日本人だけ6人でやった。
・向こうの人達からフィードバックをたくさん得られた。
■見聞きしてきたこと●市谷さん
・印象に残ったセッションが３つあった。
・1つ目はAlan Shalloway氏のセッション
-
[8/14] Leanがビジネス価値を駆動する Agile2012 現地レポート(15) - バリューストリームで価値を発見するフェーズとデリバリーするフェーズの２つがある。
- 「スクラムマスター」と「プロダクトオーナー」と「開発チーム」だけじゃなくて、
もっと役割を増やさないといけないね、という話。
- 「プロダクトマネージャ」を置きましょう。
・2つ目は、Henrik Kniberg氏のセッション
-
[8/14] へんりっくのかんがえたさいきょうのかんばん Agile2012 現地レポート(17) -
「塹壕より Scrum と XP」という有名な文章を書いている。
- 大規模となったとき、朝会のレイヤーを分けてうまくやっていきましょう、という話。
・3つ目は、Dean Leffingwell氏のセッション
-
[8/15] Legacy MindsetからLean-Agileへ Agile2012 現地レポート(25) -
「アジャイル開発の本質とスケールアップ」という書籍を書いている。
- 大規模開発をやるうえで、ストーリのサイズがデカすぎる。
- ユーザストーリで表現するには大きすぎるので、３つのレイヤーに分けよう。
①エピック
②フィーチャ
③ストーリ
- リーンをやる上での心構えを10個挙げている。
■思ったこと●市谷さん
・大規模開発どうしよ？というテーマが流行ってた。組織単位でどうやろうか？が日本との違い。
・大規模どうやって戦うか、ということで、多くの人が「リーン」って言ってた。
●安井さん
・大規模の補足。基調講演がそもそも「Scaling up Excellence」というタイトルだった。
- アジャイルで上手くいってるやり方があったら、全社や全世界にいかに広げていくか、というテーマ。
・ワークショップの中にいかにゲームを取り込んでワークショップを活性化するか、
というセッションを聞いてきた。
- 1つ目のセッション：
すごく複雑なルールが書いてある紙が用意されたゲームを用意したので、やってみてよ、というカンジ。
本当のプロジェクトをゲームとしてシミュレーションする。
いろんなプラクティスをPJにどう入れていくのかを試行錯誤するゲーム。
- 2つ目のセッション：
参加者がグループに分かれて、これからゲーム作ってください、というセッション。
道具はたくさん用意されている。
作り方にルールがある。
P： problem まず問題に注目する
L： learn そこから何を学ぶか
A： aspect どういう観点からアプローチするか
I： invent ゲームの発明
D： devleaf 振り返り
アジャイル現場でやってる人がメインじゃない。
アジャイルをやってる人を支援・サポートする人が使える道具を提供する、というテーマのワークショップ。
●西村さん
・興味があるやつを雑多に聞いてきた。
・1つ目は、大御所の話。
- 大事なことをあの手この手を使ってどう上手く説明するか
- このプロジェクトはおいくら万円ですか、という質問に答えるセッションがあった。おもしろかった。
・2つ目は、自分と同じ世代、ちょっと上の世代の人の話を聞いてきた。
★思ったこと
・日本だと、サポートしている仕事のノウハウが個人に依存している。
みんなで使えるようにするという発想がまだない。
海外はそういう共有があるようで、一歩先に行ってる。
・「何かを持って帰ろう」とか「自分の主張をしたい」という気持ちを持ってきてる参加者が多い。
そこが、日本とは違うと感じた。
・セッションの参加者の割合
- 開発者： 1割
- PM： 3割
- スクラムマスター： 3割
- アジャイルコーチ： 2割
- CIOとかCTOとか： 2～3人
中間管理職の人が多いかも。年齢層も高い。20代の人はあんまいなくて40代くらい。
・参加費用
- 参加費が定価で2000ドル
- ホテル1000ドル
- 飛行機代とかもあるので、日本からだと50万円くらいかかる。
- 個人参加者も多い。USAでは、個人事業主として、確定申告で税金として落とせるらしい。
- LLC（Limited Liability Company・有限責任会社）の人が多い。
■聞いてみたいこと（質疑応答）Q1.
どんなカンジのソフトウェアを作ってる参加者が多いのか？
A1.
受託開発の匂いはしない。サービス作ってる人、コンサルの人が強そう。
向こうは、コンサルは辣腕をふるってるかんじ。Henrikとか。
ただ、軍関係の開発でアジャイルが導入されている、というセッションがあった。これは受託のはず。
ただし、話すネタとか困ってることとかは、受託とかサービスとかあんま関係ないイメージ。
オフショアの人も来てたし。テーマとしてはあまり区別せずに話してたイメージ。
---
SAF（Scaled Agile Framework）の話は、みんなが使う。
エピック、フィーチャー、ストーリをそれぞれバックログで管理する。
各バックログにかなりの人数が張り付いてるかんじ。
---
A2.
日本だと、そうはいってもアジャイルは難しいよね、抵抗あるよね、という話が出てくる。
カンファレンスはそーゆう話は出てくるのか、それともアジャイルやってる前提なのか？
Q2.
アジャイルやってる、は大前提。
すでにやっていて、どうやって広めていくか。オフショアでどうやるか。という話が多い。
技術的な話はあまりなかった。
USAの開発プロセスで一番多いのはスクラムで３８％、アジャイル入れてスクラムを入れてだと６０％。
なので、アジャイルやってる人しかこない。またアジャイル前提のツールしか売れない。
日本では、そこがギャップで、そーゆうツールは売れない。
アジャイルやってることが前提、という話の補足。
・やってることは前提。ただし無理やりやらされている。
・やらされているけど、困ってる人が一定数いた。
・他の会社ではどうやってるのか、という観点でセッションに群がる人も一定数いた。（3割くらい？）
---
A3.
海外では、ビジネスの根幹に関わっている印象だったが、その辺を伺いたい。
Q3.
SAFだと、一番上はプログラムポートフォリオ。
わが社は何をやっていこうか、という話があって、それをやるにはどういうフィーチャーがあるのか、
という話をレイヤーで管理してる。ビジネス直結してるかんじ。
SAFの話題がホットで、やろうとしている状況。ただ、それがガンガン回っているか、というとそうではない。
---
A4.
アジャイルというと作ることに注目が集まってるが、運用周りでアジャイル、という話はあったか？
Q4.
運用の話は少なかった。あったのは↓
・エンジニアの話
・プロジェクトの話
・そっから先の話は、一気に組織の話
その間の、運用の話とかは無かった。運用の話とかはもっとあってもいいかな、と思った。
Agile 2012のカテゴリーはこんなカンジ。
http://agile2012.agilealliance.org/program/stages1/---
補足。
「Enterprise Agile」とは、大きいアジャイルではなくて、大企業をどうやってアジャイルにしていくか。
今回は「Enterprise Agile」がメインテーマの１つだった。
リーンは、いくつか流れがある。全部別。
①Mary Poppendieck（メアリー・ポッペンディーク）氏の「Lean Software Development」
②Eric Ries（エリック・リース）氏の「Lean Startup」
③David J. Anderson（デビッド・J・アンダーソン）氏の「Kanban」
それぞれ、トヨタのリーンの良いトコ取りをしてるカンジ。
---
Q5.
海外と違うこと、違わないとこ、似てるとこ、を聞きたい。
A5.
・西村さん
違いは、やってる人数と年数だけかな、というカンジ。
海外で聞ける話は、日本でもきける話が大半。
ただ、いろんな人がアジャイルをやれるように、何をしなければいけないのか、なんとかしてうまくやろう、
という話は、日本にはないなぁ、と思った。
・安井さん
こだわりが強い人が多い、と感じる。
このやりかたで頑張るんだ、これが俺のやり方だ、という態度が多いように感じる。
だから発表者も多い。
逆に、日本はいいとこどりしよう、という姿勢を感じる。
日本は良い感じに纏める、というのが得意な感じ。
・市谷さん
日本：チームで開発するにはどうやってうまくやっていこうかという話が多い。
海外：ビジネスの価値にフォーカスした話が多い。
---
Q6.
セッション応募をRejectされたとのことだが、AcceptとRejectの差は何か。
A6.
Rejectされたのは、PRが上手くなかったのが原因。
Acceptされた人のは、PRが上手かった。ただ、内容が酷いのもあった。
何が良いのが、をPRすることが大事。
--
Q7.
Agile 2012に参加してみて、次に取り組んでいこうと思ったことを教えて欲しい。
A7.
・安井さん
Open Jamでやってきたゲームが会心作だと思っている。
アジャイルを現場でやっている人を支援する人に、ツールを提供したいと考えている。
・市谷さん
向こうに行くと、物理的に一人ぼっち。会社とか家族とかコミュニティとかと切り離される。
なんで、いろいろ考えた結果、できるだけひとりで生きていこうと思った。
ひとりでどこまでできるか、向き合おうと思った。ひとりでできることを増やしていきたい。
・西村さん
アジャイル開発というキーワードで、みんなが自然にしゃべれるような環境になるようしたい。
アジャイル開発はさも当然、という前提で、いろんな人とできるような環境にしたいと思った。
感想：いつもは日本に閉じてますが、今回、海外のアジャイルの話が聞けたのは非常に良かったです。
しかも、日本の第一人者とも呼べる人が感じたコトも合わせて意見が聞けましたし。
こーゆう話を聞くと、非常に刺激になります。
あと、視野を広げるためにも、英語ってやっぱ大事だなぁ、と痛感しました。
いろいろサイトとかも紹介されてたので、見返してみようと思います。
登壇者の皆様、会場提供者さん、ありがとうございました。
-->
