2012/9/25(火) 「初心者Scala in F@N 第一回」に参加してきました。
こくちーず（告知サイト）
http://kokucheese.com/event/index/52806/ Haskellを勉強し始めてから、Scalaにもすごく興味あったんですよねー。同じ関数型言語だし。
でもScalaを始める良いキッカケが無かったんで、初心者向けの勉強会とかないかなーと思ったりしてました。
んで、ちょうどこの勉強会が運良く見つかったんで、今回参加することにした次第なのです。
会場は渋谷のファンコミュニケーションズです。参加者は10名くらいでしょうか。
ちなみに以前、ファンコミュニケーションズさんはアジャイルサムライ読書会も主催してました。
んで、私も何回か行ったことがあります。
今日は初回ということで、「ScalaのインストールからREPLとビルドツールの使い方、HelloWorldまで」がテーマだそうです。
Scala処理系のインストール 最初はWindows7にScalaの処理系をインストールするトコからです。
まず、Typesafe Stackインストーラを以下のサイトからダウンロードします。
http://typesafe.com/stack/download んで、インストーラのEXEをダブルクリックすると、
なんと！ウイルスバスターに阻まれてしまうではありませんか。。。
しょうがないので、ウイルスバスターを一時的にOFFにしてインストールしました。
またLinux（Ubuntu）も仮想環境で使えるようにしてるので、こちらにもScalaをインストールしておきました。
これでコマンドプロンプトから scala と入力すると、REPL（対話型評価環境）が起動するようになります。
文字列を表示するには、println関数を使います。セミコロンは必要ないようです。
あと、Eclipseのpluginもインストールしてみました。使い物になるかどうかは、これから評価～。
pasteモード :paste と入力するとpasteモードに移行し、プログラムをプロンプトに貼り付けて実行することができます。
Fizzbuzzのプログラムを書いたあと、pasteモードのプロンプトに貼り付け、「Ctrl - d」で実行してみました。
Scalaの文法わからんかったですが、Javaの文法で書いてみたらほぼ一発で動作しました！
Scalaの文法ってJavaと似てるんですねー、Javaでそのまま書いただけで動作した感じです。
これは普段Java使ってる私にとって、Scalaは習得しやすそうです。
他にも以下を内容を学びました。
■再代入できない変数宣言の方法
■型指定と型推論
■カリー化
■Listに関する関数（map, foreach, filter, zip, partition, foldLeft, foldRight）
---
カリー化やListに関する関数は、「スタートHaskell」の勉強会でHaskellやってたおかげで理解できましたね。
でも、同じ関数型とはいえ、HaskellとScalaの流儀はだいぶ違うように感じます。
Scalaはどっちかというと、HaskellよりもJavaの方に似ている感じです。
休憩時間にはお菓子が振舞われました。
またScalaに関する書籍が何冊か置いてあったので、主催者さん方にどれがオススメか聞いたりしました。
そんなこんなで、基本的な内容を学んでお開きになりました。
かなり初歩的な内容から入りましたが、私のようなScalaのインストールさえしてなかった参加者にとっては
ちょうどよかったかも。
逆に、Scalaの経験者にとっては、すこし物足りない内容だったのかもしれません。
もう少し踏み込んだ内容は第二回以降で扱われるようなので、経験者さんは2回目からの参加でも大丈夫そうです。
これを機に、Scalaも勉強してみたいと思っています。
ただ、第二回の開催日である10/9、別件が入ってしまっていて参加できそうにないのが残念です。。。
第三回に期待！
Scalaの一歩を踏み出す機会を提供くださったファンコミュニケーションズさん、ありがとうございました。
2012/9/8(土) ＆ 2012/9/23(日)
「アジャイルサムライDevLOVE道場二周目 第一回 インセプションデッキ」に参加してきました。
Zusaar（告知サイト）
http://www.zusaar.com/event/368007 会場はJR有楽町駅から数分の「ぐるなび」さんで、参加者さんは25人前後でしょうか。
今回のDevLOVE道場の位置づけは、「全力で剣を振って、失敗できる場」です。
「実践の場、失敗できる場」ってのは、いいですね～。やっぱ本読むだけでなく、実践が大事です。
今回は以下の書籍をターゲットとして、３～５章のテーマ「インセプションデッキ」の作成を実際に行いました。
ちなみに9/8と9/23の二日間を、以下のように割っています。
■9/08(土) :
プロジェクトにまつわる「なぜ」を明確にするためのインセプションデッキを作成する。
（主にアジャイルサムライ第４章『全体像を捉える』の内容）
■9/23(日) :
プロジェクトを「どうやって」実現するかを明確にするためのインセプションデッキを作成する。
（主にアジャイルサムライ第５章『具現化させる』）
1日目（9/8） システム開発の背景 今回は題材として、以下のテーマが与えられました。
我々（PO）は、中堅旅行会社の企画部門に所属している。昨今、同業他社による価格競争の波にさらされ、収益が低下。そこで、所得が相対的に高い中高年にターゲットをしぼった商品の販売を展開していく方針が経営として決まった。経営者から、企画部に対して、最近、利用者を爆発的に増やしているスマートフォン向けの試作サイトを企画、構築するように司令が下った。企画部担当者は、開発者の皆さんに相談を持ちかけたのだった。
（
@ryu22e さんのブログ から抜粋）
なお、プロダクトオーナー(PO)はスタッフさん方々が担当してくださいました。
スタッフさんが各チームに１名ずつPOとして入り、各チーム6人前後でインセプションデッキを作ります。
ちなみにスタッフさん方々、今回の勉強会のためにスタッフミーティングでPOの役割をかなり煮詰めてくださったようです。素晴らしい！
チーム名称の決定 最初の課題は、チーム名称の決定です。
チームでいろいろ案を出し合った結果、ウチのチーム名は
特攻野郎Aチーム になりました。
チーム名自体は某有名な作品のパクリですが、今回は以下の意味をその名前に込めています。
・Aチームの「A」は、
Agileの「A」 を表す。
・「A」はアルファベットの「先頭」ということもあり、今回の勉強会でも
先頭に立って特攻する気持ち を出す。
あと、実際に「特攻野郎Aチーム」って単語は5章のP.92にも出てくるんですよねー
我々はなぜここにいるのか？ このフェーズでは、プロジェクトで作ろうとしているものの背景にある
「なぜ」 を明らかにします。
このフェーズでは、以下の観点を元にチームで「WHY」を徹底的に考えます。
・この案件で実現したいことを徹底的にPOにヒヤリングする
・なぜそれが必要なのか、チームの中で繰り返し問いかける
上の模造紙を見てもわかりますが、かなりの付箋が書き出され貼られています。
やっぱ二日間あるとゆーことで、徹底的に議論する時間が確保されている点は良いですねー
ここで「HOW」から入らず、チーム徹底的に「WHY」を考えたことがこの後のフェーズでも活きました。
エレベータピッチを作る 次に、ごく短い時間でアイデアの本質を伝えるための「エレベーターピッチ」をチームで作りました。
短いフレーズで本質や核心を伝えるのって、難しいですよねー。。。
なんどもチームで読み上げて、全体のニュアンスを確認したり、試行錯誤しました。
あと、前のフェーズで徹底的にWHYを議論していたか否かで、ココはずいぶん変わってくると思います。
エレベータピッチのテンプレートを使って作成した、ウチのチームのピッチは以下のとおり。
「今までの旅行では分からなかった新しい発見や経験したことのない旅を」 「旅慣れた50歳以降のお金に余裕がある夫婦」 「F2F(仮)」 「旅行企画アシスタントサービス」 「いつでもどこでもFace to Faceに近い形でお客様にとって最適なプランを提供することで成約率を上げる」 「既存の旅行サイト」 「行きたい場所、やりたいことを柔軟に提案できる機能」
プロダクト名だけ決まってなかったので、(仮)と付いてます。
そういや、最後までプロダクト名って仮のまま、決定せず終わっちゃったなぁ。。。
あ、でも、なんかシュタインズゲートの「電話レンジ（仮）」みたいでちょとカコイイ。。かも？
やらないことリストを作る プロジェクトのスコープへの期待をマネジメントするために、やることやらないことリストを作成しました。
特に「やらないこと」を洗い出すのはスコープを決める上で大事だと思います。
特攻野郎Aチームでは、やること、やらないこと、あとで決めること、として以下を挙げました。
やる やらない ・Face to Face Interface ・２４時間対応 あとで決める ・タブレットの貸し出し
特に、「やらないこと」を明確にしておくのは重要ですね。
お客さんに過度の期待を抱かせてあとでガッカリさせるよりかは、最初から「やらない」としておいたほうが
お互いにとってよいことだと思います。
KPT 1日目（9/8）の最後に、振り返りとしてKPTを作成しました。
Keep １．自分ごとで思いを持って考えられた Problem １．暑い Try １．会社でやってみたい
■Keep １．と２．ですが、これは私も凄く感じました。
仮想のテーマを元に議論をしているわけなんですが、チーム全員、本気で考えて本気で議論するんですよね。
これはとても良かったことだと思います。
３．ですが、Whyを徹底的に考えると指針がブレず、本質を押さえた議論を進めることができます。
最初に「なぜ」を突き詰めることは非常に重要ですねー。今後も意識しようと思います。
４．ですが、ウチのPOさんは非常に積極的に自分の思いを伝えようとし、ファシリテートし、
チームを導いてくれました。 なので最初から最後まで、POとチームが一体となって議論できました。
POがこれほどチームに溶け込むと、こんなにも一体感を持って議論し突き進むことができるのかー、と驚きでしたね。これが「チーム全員が同じ方向を向く」という威力なのか。。。
POをチームに巻き込むことの重要性をマジ実感しました。
ちなみにウチのチームのPOは @jun116 さんでした。感謝！
５．ですが、チームの一体感は非常に良く、次回もこのメンバーでやりたい、という意見です。
かなり良いチームでしたねー
他にProblemとTryもいろいろ挙がりました。
---
ここまでが一日目（9/8)でした。
この後の懇親会にも参加して、いろんな意見交換もできました。
2日目（9/23） こっからは２日目（9/23）です。１日目（9/8）のWhyに関する議論を踏まえ、Howに迫りました。
マスターストーリーリストを作る １日目（9/8）の議論を思い出すことを兼ね、以下の観点を元にマスターストーリーリストを作成しました。
・足らないものは無いか
・要らないものは無いか
そこで @iwaoRd さんが紹介してくださった
「共感マップ（Empathy Map）」 という手法を使って整理してみました。
んで、「如何にユーザにボタンを押してもらうか」の突き詰めが弱いのでは？という意見が出ました。
なので、そこをまず考えることにしました。
ちなみに、共感マップをテーマにした勉強会が先日クラスメソッドさんであったようです。
ググってみるとこれらしいですね。
「BMG（ビジネスモデルジェネレーション）」で何かやる
https://www.facebook.com/events/452405461466434/ BMGや共感マップって、私、始めて知りました。こーゆう手法もあるんですね。勉強になります。
解決案を描く 次に、マスターストーリーリストを実現するためのアーキテクチャを概要レベルで考えました。以下が目的です。
・ツールや技術に抱く期待をマネジメントする
・スコープを可視化する
・リスクをPOに伝える
今回は「Face to Face」を実現するためのリアルタイム応対システム（チャットやTV電話）をどーゆう技術で実現するかが鍵なので、そこを中心に検討しました。
例えば、HTML5のWeb Socketを使うだとか、Cookieでアクセス履歴を取れるようにするとか、プログラミング言語やフレームワークはどーする、だとか、等など。
クライアント ■PC or スマフォ サービス（サーバ） ■Webサービス オペレータ ■顧客情報（個人の検索履歴や会員情報）を表示するPage その他 ■釣れそうな人を引っ掛けるにはどうする！？
このへんは今までのデッキとは少し趣が異なり、エンジニアのテクニカル要素が深く関わってくるトコですね。
トレードオフ・スライダー 何を諦めるのかをはっきりさせるため、トレードオフ・スライダーを作成しました。
まず、スコープ・予算・時間・品質の四天王に優先度を付けます。
ウチのチームは、
「時間 ＞ 予算 ＞ 品質 ＞ スコープ」 の順序で優先度付けを行いました。
次に、この４要素に「捉えどころのないもの」として以下の要素を追加しました。
■シンプルさ 上記４要素を追加した順序付けは以下のようになりました。
時間 ＞ 予算 ＞ シンプルさ ＞ 品質 ＞ もてなし ＞ スコープ ＞ セキュリティ ＞ スケーラビリティ 特に
「もてなし」 がミソです。
今回のサービスはFace to Faceで接客することでお客様を「もてなす」んですが、こーゆう単語を
優先度付けの対象として抜き出すことは非常に難しかったです。
表現したいニュアンスを表す単語を見つけるのが、とても難しい。
ひとまず「もてなし」という単語を抜き出しましたが、これがベストだとは思っていません。
でも、微妙なニュアンスを名前付けして議論対象に乗せる、ということは非常に重要です。
何がどれだけ必要なのか ～「Aチーム」を編成する～ このミッションをやり遂げるためのチーム編成について考えました。
最初に、開発期間を約２ヶ月と決め、スコープから工数を人月ベースで算出し、６人月としました。
なので、エンジニアが３人必要になります。
またそれとは別にPM＆PO的な立場を１名追加して、計４名としました。
また３名のエンジニアの強みや期待することについても洗い出しました。
人数 役割 強みや期待すること 1 PM ・ステークホルダーとの折衝 3 PG PG1 ・クライアントサイドの技術 PG2 ・サーバサイドの技術 PG3 ・インフラまわり（テスター）
3名のPGは、役割を固定するのではなく、互いが強みを活かしてカバーし合う感じです。
KPT ここまでの検討でインセプションデッキの作成自体は終わりになり、最後にKPTで振り返りを実施しました。
Keep ・雨にも耐えて参加した Problem ・各フェーズの落とし込みに時間がかかる Try ・コア技術は、調査してから先に進む
最後に各チームのKPTを共有してたときに、「インセプションデッキはWhoの要素が弱い」 という意見が出ました。
★まとめ：
2012/9/21(金) 「LeanStartupNight - Eternal Rotation! -」に参加してきました。
Doorkeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1687?auth_token=KtzNwSR5xptmQrC6sMfR togetter（ツイートまとめ）
http://togetter.com/li/377362 DevLOVE LeanStartupNight -Eternal Rotation!- まとめ
http://matome.naver.jp/odai/2134822157181001701 会場は株式会社エムティーアイで、主催はDevloveです。
参加者は８０人くらいでしょうか。
このイベントも申し込みから満員まで一瞬でしたね。
アジャイルの勉強会は最近良く見かけるようになりましたが、リーンスタートアップをテーマにした
勉強会はほとんどないので、アジャイルやってる人からしたら今日の勉強会は願ったりだったのでしょう。
そんな私もリーンスタートアップは概要レベルしか知らなかったので、今日のイベントは非常に興味ありました。
講師はLean Startup Japanの和波俊久さんです。
以下は講演中の一幕。
以下、自分への覚書としてのメモ。
19:40 - 20:40 Startup! Lean Startup ■マーク・アンドリーセン（Marc Andreessen）
・Mosaicというブラウザを作成し、２０代前半で億万長者になったエンジニア
・「ソフトウェアが世界を飲み込んでいる（Sotfware is eating the world.）」
■スマートフォンが世界中にソフトウェアのチカラを届け始める。
５年以内に５０億の人がスマフォというコンピュータを毎日使うようになる。
■これまでは産業の中に根ざしたビジネスのルールの枠にいる競争者との戦いだった。
今はルールが全く変わっている。
■いつの間にか産業がなくなっている。
・手紙や図書券のような、紙媒体
・紙広告
・紙幣
→ デジタルへ移行した。誰が乗っ取ったかというと、ソフトウェア。
例：コダックの倒産。
・フィルムへの固執が命取りとなった。
・逆に富士フィルムは、フィルムに固執しなかったため、生き残っている。
・一度飲み込まれると、気づいてからでは遅すぎる。
・リーンスタートアップの先行事例として取り上げられていたコダックさえ倒産する時代。
■決めた計画の実行力より、想定外の変化への対応力が必要。
複数の人間がオセロをやっているような感じ。いきなり誰かが隅っこに石を置くような時代。
■昔は事業を立ち上げるのに、最低でも1000万円かかった。
今はOSSとかクラウドとかを利用すれば、0円でサービスが立ち上がる。
今の時代、ライバルは企業ではなく、親から貰ったお古のコンピュータを使いこなす幼い子供かもしれない。
■アンゾフの成長マトリクス
【参考】
http://www.tam-tam.co.jp/tam_marketing/Ansoff_matrix.html 「製品開発」の象限↓
・何もノウハウが無い。未知の領域。
・既存領域はソフトウェアが飲み込んでいる。そこに挑んでもダメ。「新規開発」へ向かうしかない。
・社内で承認プロセスを経ようとしているようでは、「新規開発」のライバルは先に行ってしまう。
■Lean Startupは、大きな戦略の話。戦略論。
■Lean Startupを企業が手に入れると、「柔軟性＋走りながら考えるチーム」ができる。
→ 状況が見えるようになり、新規事業のリスクが劇的に軽減される。
■Lean Startupを一言でいうと。。。
変化に対応できるチームを作るための、現存している唯一のバイブル ■生き残る企業と死んでいく企業がある。生き残る企業には理由がある。
→ 誰に向けたサービスをどう作っていったのか、フォーカスできていると生き残れる。
→ 「誰が探してくれるの？」を意識するところが残る。コンセプトを持っていることが重要。
■最初から全員が欲しいものが出来なくても、その中の一人の、彼のためだけなら幸せにできる、
というものを少しずつ作っていくのがリーンスタートアップ。すばやく素早く。
■リーンスタートアップではPivotを繰り返しながら、マーケットが「Wow！スゲー！今すぐ欲しい！」と
言ってくれるまでビジネスモデルを探していく。
→ Wow！と強い反応が返ってこないとダメ。
■Pivot（方向転換）のコツ
・とにかく素早くやる
・とにかく何回でも試す
・小さなものからやる
・特定のマーケットからやる
・改良をする
■ビジネスをスタートした瞬間から、以下は凄いスピートで減る。
・お金
・外部から得られるサポート
・モチベーション
前者２つはあとから注入可能。
モチベーションはそうはいかないので、尽きる前に何回ビジネスを試せるかが重要。
■リーンスタートアップを加速させるための４つのポイント
１．小さく始める
２．繰り返す （繰り返し繰り返し試す）
３．仮説から始める （仮説を立ててから全ての行動を始める）
４．常識を変える
■１．小さく始める
・MVP（実用最小限の製品：Minimum Viable Product）
・完璧はいらない。すべて完璧が必要なのは、圧倒的なスケーリングが求められるタイミング。
（例えば1000万人の人にサービスを提供するとか）
・Simple is Best。後は走りながら考える
・人に頼るのはダメ。自分がまず変わること。自分が走り始めないと何も変わらない。
■２．繰り返す
・新規事業は何回失敗してもOK。法律さえ犯さなければ、ルール何にもなし。
・繰り返さないほうが損。３ヶ月もかけて１回しかリリースしないのは圧倒的な損。
・走り出さないからウォーターフォールになる。走り出せばウォーターフォールされようがない。
ウォーターフォールから抜けれない人は、走り出さない人。
■３．仮説から始める
・失敗の元凶１
- 一発勝負に出る。
- 先送りにする。
・失敗の元凶２
- ガントチャート
- チェックリスト
チェックボックスにチェックが増えると自己満足感は得られるが、何も終わってない。
もっと言えば、ビジネスは一つもも始まってない。
・タスクから始めてはいけない。仮説から始める。
■４．常識を変える
・経営者は「新規事業を立ち上げろ！」と言うが、以下にハマっている経営者が多い。
- 新しすぎて理解できない。
- 今までどおりの報告書を要求している。
- リスクを回避すると賞賛する。
→ これでは新規事業は生まれない。
斬新な考えを提供する秘密兵器が投入されても、経営者が理解できないので、秘密兵器が腐っていく。
こんなんでは、どんなに頑張っても竹弁当しか出てこない。無難の塊になる。
・経営者でも、新規事業はノウハウがゼロ。ゼロから書き直していかないと、無難の塊（竹弁当）になる。
・新規事業開発 ＝ 新しい「ものさし」を作ること。
新しい「ものさし」は、以下に適用していく。
- 進捗
- 将来性
- 貢献 ・・・ 貢献度をちゃんと図る仕組み作らないと、タスク(ToDo）を埋める作業に戻っていく。
- 新規性 ・・・ 新規性を理解できるようになるにはどう測ったら良いのか。
- チームワーク
- スピード
・まずタスク管理をやめる。仮説をとにかく書き出し、どのくらいその仮説が証明されていくかが目安。
・自分たちがどういう状態にあるのか、間違った方法で計らないこと。
（例えば月に１回しかログインしない人をアクティブユーザとしてカウントするような測定は愚行）
■数年前に言われていたStartupのフレームワークから、現在言われているStartupのフレームワークへの変化を表した図
（@fullvirtue さんのTweetから写真引用）
如何にして私はリーンスタートアップにたどり着いたか ■下流から上流へ
・下流のプログラマをやっていて、恐ろしいデスマーチを経験した。
・一度、上流工程の人が集まる参謀会議に出席してみた。
→ 参加者がまるで解を出そうとしない状況を目の当たりにした。ダメだコイツ、早く何とかしないと。。。
→ 俺が上流へ行くしかない。
■上流に登ってみて、源流で見たもの（プロジェクトを生み出す立場から見たもの）
・矛盾の源流は、請負契約。
・請負契約では、発注者と受注者は当然のごとく、相反する。
- 発注者側のPM： とにかくたくさん、やすく、いいものを作りたい。思いついたものはすべて作ろう。
- 受注者側のPM： とにかく安く。仕様変更は追加料金を求める。粗利重視。
・受発注者の相反には高い壁があり、相容れることは今後ありえない。
■どうやら、ウォーターフォールやアジャイルといったメソドロジーの問題では無い、と気づいた。
・請負契約の問題を解決するには、発注者と受注者が同じ世界にいるしかない。同一化する。
・ただ、内製だけではダメ。情報システム部門と業務部門は、一般的に仲が良くない。
■スタートアップは、困難度は上がるが矛盾が少ない。
■Agile vs Lean
Agile Lean 価値 サービスイン ローンチ後 満たすのは 要求事項 マーケットのニーズ Driven by ユーザーストリー／テスト 仮説（課題・ソリューション他） アプローチ インクリメンタル or イテレーティブ MVP ゴール 満足度 ROI
■ウォーターフォール vs アジャイル
・いいアイデアもってるけどＷＦやってる人
・いいアイデアはあんまないけど日々アジャイルやってる人
→ 後者のほうが事業が成功する可能性は圧倒的に高い。
20:40 - 21:40 No-Bull Know-How LeanStartup ■Q1.
Q.
リーンスタートアップを社内教育にどう導入するか？
A.
Lean Startup Japanで講師を担当することも可能。5分バージョンから8時間バージョンまである。
■Q2.
Q.
リーンスタートアップをハードウェアベンチャーでハードを対象にどうやるか？
（ハードは、モノ作るのにそれなりの設備とか必要）
A.
ハードとソフトの対比は関係ないと思っている。
リーンが検証するのは、提供するバリューがマーケットに受け入れられるかどうか。
iPhoneは、iPodを作ってる段階でだいぶApple内で検証が進められていたハズ。
ハードの設計よりもUXが先。まず仮説を立てること。
あんまりマテリアルに縛られないほうがよい。
■Q3.
Q.
現在の抜けてる視点として、使う人に対する視点が置き去りになっている。そうじゃなく、UXが大事。
UXの大事さをうまく伝えていくには、どう伝えていくべきか？
A.
「今のコンセプトではダメだから、UXで変えましょう」と言って、会社を変える
権限 を持っているだけの
UXデザイナに、今まで会ったことがない。つまり、UXデザイナが会社の中で
権限 を持っていないのが問題。
海外では、UX担当者が執行役レベルで担当している。
日本の会社でも、UXを執行役員レベルで推進しないと、本当の価値は出せない。
■Q4.
Q.
日本でスタートアップを継続して価値出している企業はあるか？
A.
成功の定義が各社で違うので一概には言えない、というのが根本にはある。
ただ、サイクルを回しながら徐々に改善を目指していく仕組みがインストールされた段階で、いったん一つの成功と見て良いと考えている。
なぜなら、そこで学びを得て、必ず次へステップすることで成功に近づけるから。
その観点で言うと、いくつかの会社はやっている。（会社名は出していいのわからないので、控えます）
アジャイルは、サービス開始後を意識する人はチームにあんまいない。
「ある一定のサービスインに向かってリーンスタートアップやっていこうぜ」というのは、その時点でリーンスタートアップではない。
事業が成功する日に向かって、その日までやるのがリーンスタートアップ。
■Q5.
Q.
事業と開発を分けて考える時点で負けかな、と思ってる。
事業が言われたものを作る、という構図を実現するために効率的な方法として、
リーンな方法としてアジャイルを使う、という構図が生まれている。
この辺を打破しない限りリーンスタートアップは熟成するような組織は生まれないという危機感がある。
どうすれば良いと思うか？
A.
事業と開発が分離されていること自体が、最大の超えないといけない壁。
経営者の理解を勝ち取る必要がある。
理解を勝ち取る、というのがどういう状態になるのか。
「リーンやってもいいよ」と言われるだけでは、理解を勝ち取ったことにはならない。
まず、新規事業を開発する、というのを「プロジェクト化」してはいけない。
プロジェクト化した段階で、リーンじゃなくなる。
プロジェクト化すると、ゴールはプロジェクトを終えること。どうしても、終えようとする。
事業が成功することが目的ではなくなり、リーンじゃなくなる。
ビジネスは勝ちに与えられるパイは決まっており、相対評価できまる。
それに対して柔軟に対応できるかが、リーンに問われているところ。
リーンスタートアップを理解している、ということは、環境が何か変わったら手を打たなければいけない、ということ。
■Q6.
Q.
サービスの価値を提供する先のユーザと、収益の源泉（お金を出してくれる人）が結びつかないことがよくある。
例えば、facebook。価値を届ける先は、ユーザ。でもお金を払ってくれるのは企業。
新規事業を立ち上げる時に、どちらに集中していくべきなのか、という葛藤がある。どうすればよいか？
A.
ビジネスモデルの仮説に対して、真摯に普通にチャレンジする以外に何もないのでは。
無料なんだから、とか、お金を払ってくれる人が別なんだから、というのは関係ない。
ビジネスを成功させる仮説に基づいて、そこに向かってチャレンジしていくだけ。
■Q7.
Q.
英語の学習ソフトを作ろうと、リーンに基づいて、その辺にいる人にインタビューを敢行してみた。
・1回目のインタビューは、ランダムに聞いて回った
・2回目のインタビューは、MVPを作って話しかける対象をビジネスパーソンに絞った。
・3回名は、チームリーダの意向から、女性に絞った。
最初の仮説として、ビジネスパーソンに絞る、というのを決めるのは他のスタートアップだと難しかったと思うが、どうやって仮説を立てるのが良いのか。
A.
まず、事業のターゲットを絞るのに「ビジネスマン」という括りではターゲットがデカすぎる。
どういうような「ビジネスマン」なのか？を掘り下げる必要がある。
・何をしているシーンを想定するか
・どんなことに不満を持っているのか
今にでもお金を払ってくれるようなユーザに絞る必要があるので、課題をベースにセグメントを切っていくべき。
インタビューのクオリティは以下の公式で決まる。
インタビューのクオリティ
＝ インタビューする側のシナリオのクオリティ × インタビューされる人が適切なターゲットか
ターゲットをきっちり絞って、その条件に該当する人にインタビューしないと、インタビューの質は一向に上がらない。
ペルソナの有効性は、目的次第で変わる。
■Q8.
Q.
レベニューシェアでやるのは難しいと考えているか？
A.
レベニューシェアが銀の弾丸になるとは思わない。あれはただの請負契約の形の１つなので。
請負契約である以上、納品したら終わり。
請負だと、ローンチ後も要員を投入し続けるベンダなんてない。
■Q9.
Q.
仮説を立てるのは私たちはヘタ。
講師として、今回の勉強会にどういう仮説を立ててどういうフィードバックを期待して望んだか？
A.
今回の勉強会は事業だと考えていないので仮説立てない。
出席した人の満足度があがればいいなぁ、というところまで。
今回はどちらかというと、システム開発寄りの方をターゲットとした。
★感想： 和波さんの語りは非常に明快で、引き込まれました。
あと、どちらかというとアジャイルは手法寄り、リーンはビジネス寄りな感じですかねー
これはアジャイル、これはリーンと明確に区分けするよりも、両方の良いトコ取りする感じが良いのでは、
と思いました。（非ウォーターフォールみたいな）
パレートの法則（80:20の法則）というものがよく言われますが、早く市場に投入した2割の機能が8割の価値を生み出すのなら、それは非常に意義があることだと思います。
WordやExcelの機能だって、一般ユーザが普段使ってる機能なんて、全体の10%～20%くらいなのでは。
そーゆー意味で言うと、ほとんど使われない（≒価値を生まない）機能まで作りこんで、完成させてから市場に投入してるようでは、他社に市場を奪われてしまうでしょう。
また、早く失敗がわかる、という点も見逃せないと思います。
今日得たリーンスタートアップの知識を体系建てるためにも、今日の勉強会のターゲットにもなってた本を1冊読んでみようかなぁ、と思います。
あと、仮説から始める、という点。これは私できてなかったので、反省。意識してみようと思います。
今日の勉強会も非常に有意義でした。運営者様、登壇者様、会場提供者様、ありがとうございました。
2012/9/20(木) 「アジャイルサムライ読書会 横浜道場 "当てずっぽうの奥義"」に参加してきました。
kokucheese（告知サイト）
http://kokucheese.com/event/index/52905/ ツイートまとめ（togetter）
http://togetter.com/li/376992 「アジャイルサムライ横浜道場」は以下の書籍をターゲットとした読書会です。
今回は第７章「当てずっぽうの奥義」から読書しディスカッションを行いました。
ちなみにウチのチームは５人で、模造紙はこんなカンジでした。
↑見てもわかるとおり、最後の纏めの時間で、議論の内容を以下４種類に分類しました。
１．見積
２．サイズ
３．その他
４．チームの人数（見積の派生）
以下、チーム内ディスカッションとチーム毎の発表で出た意見のメモです。
---
■プランニングポーカーやっても、見積もりはあてずっぽう。
「見積もりの精度」よりも、「最大と最小のカードを出した人で話し合う過程が生じる」ことに意義がある。
■見積もりするには「完了（Done）の定義」が重要。
■プランニングポーカーで全員が同じ数字を出しても、必ずメンバの誰かにその数字の根拠を聞くことが重要。
・周りの空気を読んでなんとなく数字を出す人がいるかもしれない。
・数字が一致することが重要なのではなく、数字を出した根拠を議論することに意義がある。
■プランニングポーカーで「大・中・小」の３種類のカードのみ使用する。
・曖昧なストーリーはどうしても「大」に寄りがちになる。
→ 「大」が多い場合、「中」や「小」に分割することを検討すべし。
■「大・中・小」の反対として、フィボナッチ数列に沿ったストーリーポイントを使って見積もる方法がある。
■プランニングポーカーで「20」という大きな数字をあえて使うことがある。
・ゴールまでには片付けねばならない大きなストーリーがいくつかある、ということを認識できる。
・「20」のストーリは、それをやる直前まで分割しない。（必要になるときまで先延ばしにしておく）
■スプリントの開始時までには、ストーリーを「5」以下にしておく。
■見積もりに数ヶ月の期間と多大なお金をかけるようなプロジェクトがあった。
→ 時間をかけて見積もった割には、見積もりが正確だったということは無かった気がする、とのこと。
→ 見積もりに時間をかけても、正確になるとは限らない。
■ストーリーポイントが「13」のストーリは、どうやっても１イテレーションで終わらない。
「8」でも終わるかどうか危うい、という臭いが徐々にわかるようになってきた。
→ チームが成熟すると「不吉な臭い」に敏感になる。
■チームの人数のベストは、「基準６人±３人」が良い、という通説がある。
■チームの人数は「奇数が良い」という話がある。
ペアで作業してもフリーになる人がいる、ということが重要とのこと。
■チームの人数が二桁になったら、チームを２つに割ることも検討する。
■割り当てたタスクが１週間たっても終わらないタスクは、最悪、別の人を割り当ててやり直すことも考慮する。
■タスクボードを壁に張り出していると、ISMSの監査で引っかかることがある。
（顧客情報とかプロジェクト情報とかが張り出されていることになるので、監査にひっかかるらしい）
---
あと、チームでRedmineとかTracとかツールの話が出たときに、JIRAとGreenHopperというツールを耳にしました。
アジャイルのプロジェクト管理とかに使えるツールらしく、調べてみるとどうやら以下らしいです。
★JIRA
http://www.atlassian.com/ja/software/jira/overview ★GreenHopper
http://www.atlassian.com/ja/software/greenhopper/overview ---
ディスカッションと各チーム発表、KPTといういつもの流れの後、懇親会にもいつもどおり参加。
横浜道場のTシャツがお披露目されてました。
コチラ ちょと欲しい。。。
今日のテーマでもある見積、やっぱ難しいです。私も四苦八苦してます。。。
今日の道場で得られた知識をちょっとでも活かしたい。
運営者様、参加者様、いつもありがとうございます＆おつかれさまでした～
2012/9/15(土) 「XP祭り2012 〜 ソーシャルチェンジ！ 〜」に参加してきました。
■「XP祭り2012 〜 ソーシャルチェンジ！ 〜」公式サイト
http://xpjug.com/xp2012/ ■togetter
2012/09/15 XP祭り2012 ～ ソーシャルチェンジ！ ～ Vol.1（前日まで～本編午前） #xpjug
http://togetter.com/li/360397 2012/09/15 XP祭り2012 ～ ソーシャルチェンジ！ ～ Vol.2（本編午後：コンテンツ祭り） #xpjug
http://togetter.com/li/372845 2012/09/15 XP祭り2012 ～ ソーシャルチェンジ！ ～ Vol.3（本編午後：基調LT以降） #xpjug
http://togetter.com/li/372846 会場は早稲田大学の理工学部です。参加者は200人↑でしょうか。大イベントですね。
ちなみに私、XP祭りは今年が初参加です。
今年になってアジャイル関係の勉強会とかよく参加するようになって、興味があったのです。
でも「eXtreme Programming」って、明確な定義とかよくわかってないや。。。
開始は10：00からでしたが、私は10分くらい遅れて到着しました。
なんか、漫才らしきトークが繰り広げられてる。。。
A-1 オープニング【トークライブ】 時間 – 10:00〜10:20 http://xpjug.com/xp2012-contents-a1/ 公式サイトを見ると、どうやら「XP仙人であり、XP祭り主席実行委員でもある、小井土さん、福井さんによる毎年恒例のトークライブ(まんざい)」だったようです。
すみません、遅れてきたし、外がすげー暑かったモンで少し涼んでたりして、あんまり聞けませんでした。。。
A-2 アジャイルコーチ・ラウンドテーブル 時間 – 10:20〜12:00 http://xpjug.com/xp2012-contents-a2/ アジャイルコーチ8賢人によるパネルディスカッションです。
私が取ったメモをベースに、気になり事項を覚書として書いてみます。
---
■お堅い大企業は、中より外から動かすほうが早い。コミュニティとか外の力が、SI業界には大事。
■チームで能力を高める活動していけば、半年でチームはデキるようになる。天才の存在は必須ではない。
■まず、アジャイルでTRYする場を用意するのが大事。
■いきなり本番でアジャイルやって失敗すると、上司から「やっぱりアジャイルはダメ」という烙印を押される。
■失敗しても力技でなんとかできるプロジェクトからやる。まず成功体験を作る。
お客さんのシステムでアジャイルを始めて試すのはおかしい。
■とあるエピソードを３つ紹介
１．アジャイルやるぞ、という人がいて大事なプロジェクトで１０人くらいで始めてるところがある。
→ 開発メンバーのスキルが足らなくて混乱し、倒れそうになった。
→ やっぱ大規模ＰＪからやるのはダメである。
２．優秀な人がいるチームでアジャイルをやってみた。
→ 若手はアジャイルに馴染んでやりだしたが、その優秀な人は、アジャイルが合わなくて去った。
→ 優秀な人がアジャイルに合うとは限らない。
３．人によってアジャイルで遣り方が変わる。「優秀の在り方」のも変わる。
■相手（上司）を説得してアジャイル（ペアプロ）を始める方法
・相手の価値観を聞く。
・相手とラポールを形成する。（※１）
・相手の瞬き（まばたき）に合わせる。
・ムードを作ってから価値観を聞く。
・～さんにとって最も重要なものは何か？と聞く。
・相手の価値に響くトークをする。
（※１）ラポールとは：
互いに信頼し合い、安心して感情の交流を行うことができる関係が成立している、心的融和状態を表す。
■相手（上司）は不安だから反発してくる。
→ 不安に対して解決をアピールすることが重要。不安を取り除くにはどうすればいいのかを考える。
■ペアプロは、確かに実装する時間は増えるが、２倍にはならない。
しかし、作り終わった後のバグがでる数が圧倒的に少なくなる。
→ トータルとして保守コストが減る分、長い目で見ればお得です。
■偉い人を説得するときは、世の中データがどうなってるかを示すのが有効なときがある。
どこかの機関が毎年出してる統計とか、集計された客観的なデータを使った方がいい。
■結果責任は上司が取るべき、実行責任はチームにあるべき。
→ 正面から「お前は黙ってろ。オレを信頼しろ」と上司を説得する。
→ チームがみんなやりたいんだったら、上司は見守るべきで、チームに権限委譲すべき。
ここを突破しないとダメ。あと、PJがアジャイルで成功したら、手柄を上司にも渡すこと重要。
■アジャイルを会社で始める方法
一人でも、それおもしろそうですね、という人がいると、そこから攻めれる。
そういう人が二人以上ほしい。一人だと、まわりに助けてくれる人がいなすぎて、折れる。
味方がいたほうがいい。
■ペアプロを会社でやる方法
・ペアプロを見込んだアサインをする。
・最初計画のときに、「他の人を手伝ってもいいよ」というルールにしておく。
・バッファをもって見積もっていく
■アジャイルはお互いの協力が前提。
現在は、評価制度に問題があることが多い。メンバを手伝ったら評価が上がる評価制度が良い。
■社内の品質基準と、顧客にとっての品質基準は関係ない。
過剰なテストは無駄。きちんとそう契約しておくのが大事。
■設計力に関心がないチームやメンバへのアプローチ方法
・「オレでもできるわ」と思ってもらえると、その人はすごく変わる。
・ 今の実力じゃなくて「オレでもできる」と思ってもらうかが重要。
・オブジェクトゲーム（※２）とかでオブジェクト指向のコツを体感してもらう。
（※２）オブジェクトゲームとは、↓のようなモノらしい。
http://objectclub.jp/download/files/event/2006summer/sessionE.pdf ■テストを書く文化を入れるのが効果的。
テストをかけるようにする、効率的にテストできるようにする。
テストを上手にできるようにする。
■まずアジャイルコーチがテスト書いてみせる。
Jenkinsの設定をやってみせる。
きっかけが遠すぎる場合に、最初にコーチが材料を見せるのは、コーチのテクニックのひとつ。
■アジャイルをやるとチームで暗黙知がたまるので、チームは解散しない。
→ スクラムマスターがチームから離れて元に戻っちゃうなら、アジャイルが身についていない証拠。
→ スクラムマスターが離れるタイミングを見越して、チームメンバに権限委譲とかしないとだめ。
→ 弟子を育てること重要。
→ 朝会とか振り返りのファシリテーションを他のメンバにやらせる。やらせないとできるようにならない。
■失敗を恐れてアジャイルをやりたがらない上司にどう対応するか？
・まず上司に話を聞く。
・失敗が怖いということは、不安を持ってるはず。それをトークで聞き出す。大概、きちんと説明すれば大丈夫。
・ちゃんと聞いて、ちゃんと説明すること。ちゃんと話を聞いてるか？
■上（上司）にしても下（部下）に対しても、どれだけ誠実であるかが重要。
・誠実でない態度は一瞬で見破られる。
・上に対しては、多少合わなくても、全力で支える。
・下に来た人には、来て良かったと少しでも思ってもらえるように頑張る。
---
★感想：
非常に実践的なトークが繰り広げられ、大変ためになりました。
あと、聴講者からの質問とかパネラーの話を聞いてると、やっぱ悩むポイントは誰も同じなんだなー、と思います。
自分でできてないところは、実践していきたいと思います。
A-3 いま東北が熱い！【講演】 時間 – 13:00〜13:20 発表者： 小泉 勝志郎さん http://xpjug.com/xp2012-contents-a3/ 登壇者の小泉さん、東日本大震災で被災されたとのこと。。。
でも、震災をきっかけとして、コミュニティから東北でイベント開催という支援を行っているとのこと。
最初は東京などのコミュニティが地元協力イベントを開催してくれたのががきっかけだったそうですが、
自分たちでもやりたいという思いから、今は東北デベロッパーズコミュニティ運営委員とかもされているそうな。
震災に負けず、積極的に行動を起こすその姿勢が素晴らしいですね。
直近では、9/17にメイド喫茶で「WebUI勉強会」を、10/20に「ICT ERA+ABC2012東北」を行うそうです。
・・・メイド喫茶！
また「東北IT新聞」というものを立ち上げるとのこと。以下のテーマとかを取り上げるそうです。
・東北のITイベントレポート
・東北のITイベントの告知
・東北産のスマホアプリの紹介
専用のドメイン（
http://tohokuitnews.info ）とTwitter ID（
@tohokuitnews ）も取得したとのこと。
★感想：
XPとは直接関係ないセッションですが、こーゆう頑張ってるエンジニアさんを見ると、身が引き締まる思いです。
オレも頑張らなきゃ、と思います。こーゆう刺激が大事。
小泉さんも震災に負けず、引き続き頑張って欲しいし、応援してます。
A-4 適切なイテレーション期間の設定に向けて 時間 – 13:20〜14:20 講師： 塩浜 龍志さん、鷲崎 弘宜先生 http://xpjug.com/xp2012-contents-a4/ 早稲田大学の鷲崎研究室では、イテレーションの適切な期間設定のシミュレーションを研究しているそうです。
ミニワークショップでは、適切なイテレーション期間を決定するためのゲームを4～5人のチームに分かれてやりました。
私はワークショップのゲーム参加に申し込んでなかったんですが、人数によゆーがあったので、せっかくなので参加してみました。
2回目のゲームで、"LinkedHashMap"というJavaのクラス名を1文字ずつバラバラにしたカードを揃えるゲームをやったんですが、カードがバラバラで机に並べられた瞬間、「HashMap」が含まれてそうだと気付いたので、そうコメントしました。
んで、それを元にチームでカード並べて文字列組み立ててみたら、一瞬でLINKEDHASHMAPを組み立てることができました。
ちょびっとだけ、活躍できた！
イテレーション期間を適切にしないと、様々な弊害があるとのこと。
■長すぎるイテレーション
→ 顧客からの要求変更をうける回数が減る。
→ MissCommunicationとMissUnderstandingが生じる
■ある文献では、アジャイルの失敗原因に「イテレーションの期間設定」が深くかかわっている、と論じている。
---
★感想：
たしかにイテレーションの期間設定は難しいトコがあります。
私もイテレーションの期間を2週間から3週間に変更した苦い経験があります。
鷲崎さんと塩崎さんの研究の今後に期待！
A-5 一歩＝∞ ～Agile2012参加報告～【講演】 時間 – 14:20〜14:45 発表者： 伊藤 宏幸さん http://xpjug.com/xp2012-contents-a5/ 「Agile 2012 Conference」に参加した伊藤さんの現地レポートです。
うーむ、有名人ともいっぱい話したり、楽しそうだ。
伊藤さんからのメッセージ「一歩を踏み出す勇気」は、非常に説得力がありますね。
言葉の壁を恐れずに「Agile 2012 Conference」に飛び込むには、まず一歩を踏み出すこと。
でも、やっぱ英語は大事だなぁ。。。
会社からもしきりに「グローバル化、グローバル化！英語！」と言われますが、こーゆうセッション聞くと、なおさら英語の必要性を実感しますね。
例えば来年のAgile Conferenceに参加しよう、みたいな明確な目標があれば、英語の勉強も頑張れるのかも。
学ぶことの多いセッションでした。
A-6 クラスメソッドのAWS×HTML5×アジャイル事例【講演】 時間 – 15:00〜16:00 発表者： 横田 聡さん、嵩原 將志さん http://xpjug.com/xp2012-contents-a6/ クラスメソッドの事例紹介をベースにしたセッションです。
■社長方針： やりたい仕事は自分で情報発信する。年間に数百本の記事を書いたり。
■
クラスメソッド では、究極のインバウンドを目指す。
インバウンド（※３）でお客さんの方から話がくるようにするには、情報発信して興味を持ってもらうのが大事。
（※３）インバウンドとは：
Wikipediaによると、企業側が顧客からの電話や来訪などを受け付ける形態の業務、だそうです。
■何かを始めるとき必ずやること：
・どんな問題が存在しているのかを話し合う。
・課題を設定して、課題を解決するためにITの知識を活かす。
・新しいIT技術は、問題を解決するのに有効かどうかを評価してから始める。
■Webページで、表示が１秒早くなると売上が１０％上がった。
→ Webページの描画速度が売上に大きな影響を与えることって、なにげに日本人って知らないんじゃ？
■スピード＝価値＝勝ち。速いは正義。
■Webで表示が遅いページがあったとき、競合他社に流れる。
■日本のトップ企業のWebページはどこも重い。情報システム部門とかが足枷になってることが多い。
■TOP20以内に入るためには1.5秒までにWebを表示できること重要。モバイルは７秒以内。
■Amazonのindex.htmlは5000行以上あるのにサクサク動く。
→ エンジニアが課題を解決している。
■例えば、都道府県情報をJSONでとってくるのは愚の骨頂。リクエストが２回走ってしまう。
■Webの表示を早くする方法
・HTMLで、CSSは上、JSは下に持ってくる。
・HTMLで、ソーシャルブックマークボタンは一番下に持っていき、非同期で読み込ませる。
・ファーストバイトダウンロード： 画像はAmazon CloudFrontから読み込ませるようにする。
---
★感想：
Webの表示速度って、確かに少し軽視される方向にありますよね。
見栄えをよくするために画像とかをちりばめると、当然HTML表示時に重くなるわけで。。。
Web表示速度の統計とか見せていただいて、速度の重要性を実感。
いろいろなノウハウが詰まったセッションで、大変ためになりました。
A-7 How to change our world 時間 – 16:10〜16:55 http://xpjug.com/xp2012-contents-a7/ アジャイルサムライ横浜道場で以前、藤原さんと及部さんの発表を聞いて、大変感銘を受けました。
そんときのブログは
こちら 。
なので、今回はどのくらいソコから変化あるのか興味ありました。
■
サムライエピソード の１章を執筆した。
■
How to change the world という本で、「身の回りからどうやって変化をおこすか」がテーマにある。
・我慢するか
・辞めるか
・
変えるか → 今日伝えたいこと：「変えたいなら変えればいいじゃん」
■テーマ：「アジャイル1周年を迎えた新米アジャイラーが、開発現場からアジャイルと変化について本気で考えてみた」
■1年前、楽天で抱えていた課題
・レガシーコード
・ヘビーな運用
・エンジニア急増
→ 藤原さん（@daipresents）とアジャイルやることになった。
■アジャイルやって良かった事 for Team
・スピード感
・楽しかった
・問題解決意識
■Henrik Knibergさんの一言： 「人は変化を嫌う。だからまずは自分を変えることから始めよう」
■見える化は相手が見に来ないと伝わらない。
→ 「見える化 ＋ 見せる化」が重要。
■楽しいは正義。
■Agileカンファレンスで聞かれる質問「What are you doing using agile?」
→ 「アジャイルやってるか」じゃなくて「アジャイルで何やってるか」と聞かれる。
（アジャイルやってることはあたりまえ、アジャイルで何を変えたかが重要）
■XP祭り2012までの30日間で、どこまで変えれるかやってみた。
→ 詳細は発表スライド参照。すげー良い取り組みが満載です。しかも、楽しそう。。。
■質疑応答：
Q1. もっと人を巻き込んだほうがいいとあったが、もっと具体的に。
A1. 最初、チーム外の人を巻き込めなかった。ので、こちらから見せに行くようにした。
--
Q2. 変化のスピードで気をつけることあるか？
A2. 最初に失敗したのは、チームに途中から入ってきた人に、これまでのアジャイルの方法をやってしまった。
→ その人にとっては超ギャップに感じてしまう。ここがダメだった。
・変化を拒絶した人を組み込んだら、その人が進んでやるようになった。
・やってみて思ったのは、変化を拒絶した人は「寂しかった」のかな、孤独だったのかな、ということ。
→ マネージャ（最初拒絶した人）もチームに巻き込んだら上手くいった。これ重要。
--
Q3. 技術での工夫なにかあるか？
A3. アジャイルでチームに余裕ができた。
→ そのとき、余裕を作ってやりたいことやらせてあげると、技術面でよくなった。
--
Q4. 失敗を立て直す決め手はなんだったか？
A4.
・自分が変わったところで大きく変わった
・アジャイルを拒絶する人に対して反発心しかなかったが、自分が変わると、そういう気持ちがなくなった。
---
★感想：
及部さんがスゲー楽しそうにしゃべっている姿見るだけで、今が上手くいっていることがよくわかります。
あと、凄く前向きな姿と、積極性が凄いです。これで入社4年目か。。。楽天恐るべし。
Jenkinsから飛んでくるメール文面を工夫するの、とてもイイですね。是非やってみようと思いました。
他の施策も凄く参考になりました。
藤原さんの良い後継者として、エンジニアとして成長してる姿が眩しい～
A-8 基調LT【基調講演】 時間 – 17:10〜17:30 http://xpjug.com/xp2012-contents-a8/ 歴代のXPJUG委員長による基調LTだそうです。
■平鍋 健児さん VIDEO 【参考】アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html ■倉貫 義人さん
VIDEO ■渋川 よしきさん
VIDEO ---
★感想
いやー、皆さんトークが熱い！信念が熱い！
特に倉貫さんのトークが私は心に響きました。
お名前は聞く機会多かったんですが具体的にどんな会社でどんな活動されている方なのか知りませんでした。
今日のビデオメッセージで伝えようとされていた想い、私まったく同感です。
プログラマを一生の仕事にする、素晴らしいメッセージ性ありますね。
A-9 LT祭り【LT】 時間 – 17:30〜18:30 http://xpjug.com/xp2012-contents-a9/ (1) @JibrielShibataさん
『学習するチーム』
http://www.slideshare.net/JibrielShibata/ss-14299104 (2) 瀬宮 新さん
『ITドカタがスマフォ向けWebサービスを作ってみた』
https://speakerdeck.com/u/semiyashin/p/xpjug (3) 中込 大祐さん
『初めてのアジャイル開発プロジェクトを終えて』
(4) ながせ みほさん
『チェンジ・エージェントになる方法』
http://www.slideshare.net/MihoNagase/xp2012 (5) @HIROCASTERさん
『26人のサムライ達による電子書籍「サムライ・エピソード」』
https://speakerdeck.com/u/hirocaster/p/lt-agile-episodes (6) @mnagakuさん
『種まく人』
http://www.slideshare.net/mnagaku/xp20120915 (7) 水越 明哉さん
『デザイナーとエンジニアが織りなすもの』
http://photozou.jp/photo/photo_only/237876/153493674 (8) yana_3さん
『リーンスタートアップやってみてわかったいくつかのこと』
http://www.slideshare.net/yanamura/xp2012-lt-leanstartup (9) 川口 恭伸さん
『Agile Conference の廊下の雰囲気を再現したい』
https://speakerdeck.com/u/kawaguti/p/xpji-ri2012lt-kawaguti (10) 松浦 洋介(@ayaya1024)さん
『アジャイルなチームビルディング』
http://www.slideshare.net/yosukem2/xp2012-lt-ayaya (11) たのっちさん
『相棒が欲しい！ ～たったひとりの2周目アジャイル～』
http://www.slideshare.net/Tanoguchi/2-14303542 (12) 森崎 修司（@smorisaki）さん
『ソフトウェア品質シンポジウム2012のオープニングセッション15分を5分でしゃべる試行』
→ 飛び込みLT！
---
★感想：
どのLTも内容が凝縮され、熱い内容でした。
あと瀬宮さんのLTで、以下の文章がありました。
命綱（テストコード）とセーブデータ（git）がある →チャレンジが出来る この表現いいですねー。うまく表現できてると思います。
他にもいっぱい、皆様のLTは非常に得るものが多かったです。
最後に、XP祭り2012の協賛各社さんから提供された書籍各種が貰えるとの事で、じゃんけん大会になりました。
相当の書籍数が提供されていまして、ありがたいですねー
私は、というと、最初のじゃんけんに勝って、以下の書籍を頂きました。
ありがたいこってす。名著として紹介されることが多い本ですので、是非読もうと思います。
でも、欲を言えば、Martin Fowlerの「リファクタリング ― プログラムの体質改善テクニック」が欲しか(ry
いやー、今日のXP祭り2012は大変有意義でした。
良い話もいっぱい聞けたし、本も貰えたし。あとは、得た情報をアウトプットすること、実践あるのみです。
来年もぜひ参加したいと思います。
運営者様、発表者様、会場提供様をはじめ、皆様ありがとうございました！
9/12(水) 「学び方を学ぶ 〜オブジェクト指向の設計と実装を学ぶ〜」に参加してきました。
■Doorkeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1605?auth_token=JExVxcAvaUdwiSgrdvjU ■イベント纏め
http://matome.naver.jp/odai/2134746812716134601 ■togetter
http://togetter.com/li/371959 会場は「KDDIウェブコミュニケーションズ」で、主催は
DevLove です。
参加者さんは50名くらいでしょうか。
周りを見渡してみると、アジャイルやDevLove関係で顔見知りの方がかなりの人数いらっしゃいました。
あと、このイベント、告知されてから一瞬で定員に達するほどの凄い人気ぶりでしたね。
私は確かメールかTwitterで告知を検知してすぐ申し込んだので、なんとか参加できました。
今回の勉強会は
「オブジェクト指向設計と実装を題材にして、学び方を学ぶための場」 だそうです。
実に興味深いテーマだ。
会場の入り口で、冊子2冊が配られました。あと、セッション終了後に論文っぽいシートをいただきました。
この冊子は、最初のセッションのテーマ「学習パターン」の成果物だそうです。無料配布とはありがたいですねー
セッション１：「学習パターンをエンジニアの学びに適用するためには」 さまざまなコンテキストでどのようなパターンが利用出来るかディスカッションを行う。
[形式]
・ディスカッション
[登壇]
・井庭先生（
@takashiiba ）
・増田亨さん（
@masuda220 ）
・市谷さん(モデレータ：
@papanda )
[テーマ]
・学習パターンの適用方法/新しいスキルを得るための学び方 等
（この日の発表でこの資料が直接使用されたわけではありません）
---
ちなみに「Learning Patterns」のサイトは
コチラ 。戴いた冊子版とかもPDFでダウンロードできます。
自分への覚書として、TwitterのTLと自分が取ったメモを元に、心に響いたフレーズを挙げてみます。
---
■「学び方」を学ぶ
■学習パターン ＝ 学びのコツ
■言語化しないと体験は認識できないし、他人に伝達することができない。
■「概念」があって、初めて「外界から切り取る」ことが可能になる（そこで、「名前（付け）」が重要になる）
■パターン名、状況、問題、解決。この組み合わせで「パターンランゲージ」と呼ぶ。
■他の人が持っている経験をもらうことができないが、それをパターンの形にすることでこんな経験している人がいるんだ、といったようなことが可能。
■自分達が大切にしている事をトコトンまで突き詰める。
■パターンとは、問題発見・解決のコツである。
■ライターズワークショップ ＝ 「論文を他者が議論する。著者は決して発言してはいけない。他者の読み方を延々聞く。著者はコメントから学ぶ。このように誤解されるのかというのを知る。」
■「学びのチャンス」は、与えられるものでも探すものでもなく、自らつくりだすものである。
■名前があれば認識ができ、共有できるようになる。
■Learning Patternsの40個は、ヒント。（押し付けではない。）ヒントとして、自分で工夫すればよい。
■「学びの対話ワークショップ」
１．取り入れたいパターンを、すでに体験している人を探す。見つけたら体験談を聞く。
２．逆に、自分の体験したパターンを取り入れたい人がいたら、その人に、体験談を話す。
※普段話さない人と話して下さい。
■組織文化を理解し、可視化するための方法
・制度やルール、慣習、習慣が、どんな問題を解決しようとしているのかを書き出す。
・可視化することで、これらの制度やルール等が、すでに古くなっている／使えない等の判断ができ、制度設計や再設定のヒントになる。
■ルールオブスリー ： 3つくらいの事例が無いと共感は得られない。
---
★感想： 各人のノウハウや学び方を「パターン」として纏めた点が斬新ですねー
ノウハウって、抽象的すぎてなかなか人に伝えたり学ぶことは難しいのですが、「パターンとして名前を付けた」点が素晴らしいと思います。
名付けられる事で認識され、命が吹き込まれる。名前すごく大事。
戴いた「Learning Patters」の冊子を一通り読みましたが、非常に有意義なパターンが網羅されてるカンジです。
個人的に特に心に響いたパターンは以下です。
・No.7 まずはつかる 私、定期開催されてる興味ある勉強会に参加して、PythonとかHaskellとかTaPLとか勉強しています。
ですが、「仕事で使わないから」といった甘えが心のどこかにあります。。。
本気でマスターしようとしてるか、といったら、Yesとは言い切れない自分がいます。
「始めるからには、しっかりと取り組む」ができてない、これ反省！
・No.39 突き抜ける 上記のNo.7にも絡みますが、学びに中途半端感があって、マスターには到底至っていません。
そうかといって、普段仕事で使っているJavaの知識や技術が飛びぬけているか、というとこれもダメです。
もっと貪欲に、突き詰める姿勢が自分には必要だと感じました。今日のお話を聞いて、反省。
あと、No.13の「アウトプットから始まる学び」も、まさしく私がブログ始めた動機を見事言い表してます。
このセッションの内容、非常に同感です。ITに関係なく、すべての人が意識すべき思想だと思います。
セッション２： 本を読みながらコードを書き、コードを書きながら本を読もう。@masuda220 ） ---
告知のタイトル見た瞬間、申し込みを即決しちゃうようなタイトルです。
プログラマなら、誰でもそう思うのではないでしょうか。
自分への覚書として、TwitterのTLと自分が取ったメモを元に、心に響いたフレーズを挙げてみます。
---
■オブジェクトを上手に設計・実装すると？（増田さん流の解釈）
・上手く設計・実装できると、バグが激減。
・修正・変更が簡単。
・早くコードが安定する
■人の役に立つソフトウェアを書く
「書き上げた（動いた）」は道半ば。
自分がわかる（動かす）ために書き、他の人がわかる(使える）ように書き直す。
■設計の学び ３つのステージ
1st Stage ： 修行する ９つの簡単なコーディングルールでオブジェクト指向の基本を体に叩き込む
2nd Stage ： 一人前になる Become a Software Developer
６つの役割ステレオタイプで設計する
Final Stage ： 突き抜ける Become a Leading Software Designer
Become a Thoughtful Software Developer
（３つのステージの詳細は発表資料参照）
■オブジェクトの設計と実装の学び方 まとめ
(1) 設計の学びの鉄則：「考えてコードを書く」
(2) オブジェクトの設計と実装の基本：「小さくする」
(3) 設計スタイル：
・役割ステレオタイプ
・小数の隣人と協力
(4) オブジェクトの設計・実装で突き抜けたかったら：「ドメイン駆動設計」
---
★感想： 発表資料が非常に良く纏まっていて、この日の参加者でなくても最初から最初まで一読する価値ありです。
何をすべきか、が明確に書かれていますし、随所にアドバイスや書籍紹介があるのがいいですね。
オブジェクト指向設計に関する指針やノウハウがいっぱい詰まってます。
あと、伊庭さんの最初のセッション「Design Patterns」から適切なパターンを抜き出して、ご自分の発表資料に随所にマップして説明しているところが素晴らしいです。
すごくスムーズに実感として腑に落ちてきますね。
でも、「メソッドは3行以内」は、俺はちょっと無理そう。。。
俺がオブジェクト指向の本質を理解できていないからなのか。。。
これは今後、やるべきか否か、ちょっと注意深く意識してみよう。
★最後に： 今日のイベント、非常に内容が濃く有意義でした。
ブログ書くために再度togetterとか発表スライドとか読み返したりしてたんですが、すごくノウハウやコツが詰まってるのを再実感。
学ぶだけでなく、実践し、アウトプットしてみようと思います。
特に「Lerning Patterns」の40個のコツを意識して行動したい。
発表者様、運営者様、会場提供者様、非常に有意義なお時間を提供いただき、ありがとうございました。
2012/9/9(日) 「第4回 スタートHaskell2」に参加してきました。
RARTAKE（告知サイト）
http://partake.in/events/996a8407-ad27-4d02-ab25-f5c3fe31e97f 以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
今日の会場は、いつものIIJ（御茶ノ水）ではなくニフティ（新宿）でした。
JR御茶ノ水駅もJR新宿駅も、ウチから総武線一本で行けるのがいいですね。行きも帰りも電車座れましたし。
参加者は60名くらいでしょうか。
今日の8章で、Haskellの重要要素、IOに入ります。
予習する時間あんま取れませんでしたが、可能な限りコード写経してから参加しました。
8章. 入出力 @igrep さん
↑クリックすると発表資料に飛びます↑
8章の発表は @igrep さんです。前回はLTをしてくださいました。
今日はLTでなく、章の発表です。2回連続で発表とは、積極性が素晴らしいですね！
他のプログラミング言語の書籍だと、"Hello world"の表示は1章の最初にあるのがフツーですが、
この書籍は8章にしてようやくお出ましです。Haskellの奥深さを感じる一瞬です。
んで、IOを更に深く説明したのが、次の9章です。
9章. もっと入力、もっと出力 @mizu_tama さん
↑クリックすると発表資料に飛びます↑
9章の発表は @mizu_tama さんです。
@mizu_tama さんも発表は2回目で、前々回に3章の発表を担当してくださいました。
変わらず、積極性が素晴らしいですね。
きちんの写経もしてるようで、実際にプロンプト上でプログラムを動かしながら説明してくださったんですが、
プロンプトに♥が表示されてて、参加者さんたちのRT「♥が女子力高い！」がたくさんTLに。。。
ByteStringんとこは、私も予習する時間があんまりなかったんで、あんまり理解してないや。復習しないとなぁ。
演習タイム 今回も2時間くらい、タップリと演習時間が取られました。
演習問題と、参加者さんがその場で解いてくださった回答は以下のとおりです。
■8章問題
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8 (8-1) 何もしない
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#何もしない (8-2) I/Oアクションを実行する
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#ioアクションを実行する (8-3) プログラムの終了
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#プログラムの終了 (8-4) 数の統計情報を表示する
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#数の統計情報を表示する (8-5) エコー
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#エコー ・回答１ @shokos さん ：
https://gist.github.com/3683328 (8-6) 素敵な名前
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#素敵な名前 (8-7) 九九の表
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#九九の表 ・回答１ @igrep さん ：
https://gist.github.com/3683344 (8-8) フィボナッチ数列を表示する
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise8#フィボナッチ数列を表示する ■9章問題
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9 (9-1) 電卓コマンド
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9#電卓コマンド ・回答１ @aomoriringo さん ：
https://gist.github.com/3683299 (9-2) 数当てゲーム
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9#数当てゲーム ・回答１ @apstndb さん ：
https://gist.github.com/3683362 (9-3) echoコマンド
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9#echoコマンド (9-4) Haskell版 UNIXコマンド集
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9#haskell版-unixコマンド集 (9-5) Project Euler problem 8
http://wiki.haskell.jp/Workshop/StartHaskell2/exercise9#project-euler-problem-8 ・回答１ @notogawa さん ：
https://gist.github.com/3683300 ・回答２ @aomoriringo さん ：
https://gist.github.com/3683301 正攻法もあれば斬新な切り口もあったり、実に様々な解き方がありますね。
私はというと、ぜんぜんスラスラ解けませんでした。復習しとこう。。。
でも、やっぱ自分で手を動かして頭を使って演習を解く時間があるのはいいですね。この勉強会のイイとこだと思います。
LT「Haskell Golf へのおさそい」 @notogawa さん
今日のLTは @notogawa さんの、その名も「Haskell Golf へのおさそい」です。
私、恥ずかしながらこのタイトルを最初に見たとき、「あ、Haskellでゴルフのゲームでも作ったんかな～」と
おバカなこと考えてました。。。ホントお恥ずかしいぜ。
正しくは「コードゴルフ」のHaskell版で、「より少ないバイト数で所与の課題をプログラミングする遊び。より少ない打(鍵)数を競うところがゴルフに似ているところからの命名。」だそうです。（はてなブックマークより）
この遊び、日経ソフトウェアでも連載記事ありましたねー。
私も同じ１エンジニアとして、このネタは凄くワクワク感を感じますね。今日の発表内容、スゲー惹かれました。
ちなみに、コードゴルフと言えば、「Anarchy Golf」が有名だそうです。
http://golf.shinh.org/ やっぱプログラマは、こーゆう技術ネタ大好きだと思います。今日の参加者も、きっとそうなんじゃないかなぁ。
今日も非常に有意義で楽しい時間を過ごす事ができました。
運営者さま、いつもありがとうございます。次回も楽しみにしてます。
以下、ツイート一覧です。
http://togetter.com/li/370277
2012/9/6(木) 「アジャイルサムライ横浜道場 特別編 パネルディスカッション」に参加してきました。
Zusaar（告知）
http://www.zusaar.com/event/355105 ツイートまとめ（ゆかりんノート）
https://yukar.in/note/ckFkBf 「アジャイルサムライ横浜道場」は以下の書籍をターゲットとした読書会です。
今回は書籍を読むのではなく、特別編としてパネルディスカッションが繰り広げられました。
メインテーマ： 貴方のアジャイルとの関わり方 上記のテーマについて、以下6名のパネラーを中心に、スタッフと参加者を交えてディスカッションが繰り広げられました。
@tsuyok @LascasM @dproject21 @joker1007 @shin_semiya @terahide27 以下、パネルディスカッションでの議論内容について、自分向けの覚書メモです。
１．方向付けをどうしていますか？ 方向付けをどうやってますか？例えば、インセプションデッキとかチーム作りとか。
---
■まず、あなたはなぜここにいるのか？という話をする。
→ チームが進むべき道筋が合ってくる。
■ウォーターフォールでもアジャイルでも方向付けは必要。
■今何をやってて、何を目指していくかは、どんどん変わっていく。
なので、基本的に「振り返り」が大事。
「振り返り」で、何をしていかないといけないか、目指すことを決める。
■方向付けに失敗した。客が現状維持的な思想で、客の方向に流されざるを得なかった。
ただ、インセプションデッキでもいいけど、共有は大事。
■「やることリスト」と「やらないことリスト」を作る。
→ チームの方向付けで盛り上がった。（特に「やらないことリスト」で）
■まず、アジャイルを始めるときの約束を２つする。
・上司は、チームに対して口を出さない。
・上司からチームに、「こういう風になって欲しい」と伝える。
■最初の課題として、「チケット駆動ができない」というのがある。
→ チームに「守ってください」と言う。
■一人ひとりヒヤリングする。
・どういう風になりたいのか
・どういう風になってほしいのか
→ 明確にしておく。
■市場調査（顧客がやりたいことの調査）に手を抜くと、自分たちの考え（間違った思い込みもありえる）に倒れてしまう。
■方向付けは、システム部門がしてしまった。
→ ユーザからクレームが来た。
→ やはり、何のために作るのか、の目的が大事。
■押し付けられた目的に、100%の力を出すことはできない。
■同じ方向に向ける、というのには２つの観点がある。
・どこに向かせるのか
・どうやって向けるのか
■みんなが同じ方向を向いていない時、どうするか。
■土台がハッキリしてないから議論ができない。議論ができないから、バラバラになる
■関係者がお互いを知ることが重要である。
■エンドユーザを明確にしてからアプローチする。
→ 上司に対して協力を働きかける。少しずつ関係性を作る。
→ チームが、客が何を欲しがっているのかを自分たちで考え始める。
→ これが重要な点で、こうなったら勝ち。
■方向性を向ける対象（≒チームメンバ）のことを知らな過ぎ。
・各チームメンバーの年齢とか家族構成とか趣味とか。いつも何を考えて仕事しているのか、とか。
（ある人にとっては、早く帰りたい、というのが最重要と考えていたりするかもしれなかったり）
・同じ方法では、チームメンバ全員は同じ方向を向かない。
・メンバによって、向け方を変える必要がある。それには、相手のことをわかってないと、できない。
・チームメンバのことを知るために、何かやってますか？相手のこと、ちゃんと知ってますか？
・無理やり同じ方向を向かせようとしても、向かない。なぜなら、人は変えられることを嫌がるから。
・同じ方向を向くように、まずヒヤリングして、そこから方法を探す。
ヒヤリングして、相手のことを知っておく必要がある。
・同じ方向を向くためには、信頼関係を築いておくことが大事。
（例えば、手が空いたらチームメンバの仕事を手伝ったり、困ってる人がいたら助けてあげたりとか）
・信頼関係があると、同じ方向を向きやすくなる。
■インセプションデッキはいつ作っても良い。必要なときに作ればよい。
２．問題は早く見つかるのか？ 「アジャイルをやると問題は早く見つかるのか？本当に？」というのが、スタッフミーティングで盛り上がった議題だったそうです。
---
■問題が早く見つからないことがあった。
・そんときは、エンドユーザが距離的に遠くて、直接ヒヤリングとかでずコミュニケーション取れてなかった。
・思い込みによる所、対話できていない所で失敗した。（エンドユーザの要望と乖離した）
・デモがPOレベルにしかできておらず、エンドユーザにデモできなかったのが問題だった。
■反復開発で増改築を繰り返し、徐々にアーキテクチャが破綻した。
・小さく小さくリファクタリングしていれば、傷は浅くなる。
・反復開発といっても、データモデルとはかきちんと決めておくことが大事。
■問題が出たとき、「チームに問題があるのでは？」とまず考える。
・答えは１つではない。なぜそうなったかを考えて、チームで答えを出すことが大事。
・プロセスの問題ではなく、チームの問題だと認識することが大事。
・完全なチームというものは無い。
・アジャイルは「振り返り」があって、そこで同じ問題を繰り返さないようにできる。
■ウォーターフォールだと、問題が見つかると隠蔽する。アジャイルだと、隠蔽がしにくい。
・アジャイルだと、常に情報がオープンになってるので、隠蔽できない。
・アジャイルは信頼関係が前提にある（ハズ）なので、そもそも隠蔽しようとしない。
・アジャイルは反復開発なので早く問題が見つかる。傷口が浅くて済む。
■最近はアーキテクチャを、必要なところから先に薄く作るようにしている。
（⇔ ウォーターフォールだと、厚くアーキテクチャを作り込む。）
アーキテクチャを作るチームとアプリを作るチームの、横の繋がりを強くしている。
３．最初の問題は何でしたか？ アジャイルをやってみて最初に遭遇した問題について。
これからアジャイル初めてみようと思ってる人にとって、最初にぶつかる課題というのは身近なテーマです。
---
■スプリントの期間を１週間にして開始したら、1週間では何も成果が出ず、ベロシティが０になった。
→ ストーリーの抽出単位がデカすぎたのが原因。修正したら成果が出始めた。
■誰にも興味を持ってもらえない。
・解決案１：
アジャイルやると「得する」と思ってもらえるよう頑張る。（成果を出して納得させる）
・解決案２：
腕を見せて、言うことを聞かせる。
（これは「腕（＝腕力）で従わせる」と「腕｛≒能力）を示して従わせる」の2種類の意味があると感じた）
■アジャイル用語（例えば「朝会」）を出すと拒絶された。
・「朝会」＝ 長いイメージ
・「朝会」「昼会」「夕礼」のような進捗管理三昧なイメージを連想
■朝会が長くなった。
・朝会が長くなると、進捗会議を毎日やってるのと同じ。
・朝会の話が長くなる人がいる場合、空気を読んで話を切る人がいないとダメ。
■朝会に人が集まらない。
・特定の人がいないと始まらない。
■問題をメンバに名指ししてしまう。
・○○のせいだ。
・犯人探し
■ＫＰＴが溜まり過ぎる。
・問題には新鮮さが必要。期限を決めて、期限が切れたＰは捨てる。
・Ｐに対して具体的なアクションを決めないと、いつまでも残る。
・Doneの定義が重要。
■チームでアクションが取れない問題がある。
→ マネージャがアクションを取らないとダメ。（例えば、経営層や顧客のエラい人に話をつけるとか）
ただ、チームでアクションが取れない問題が頻発するようなら、それは組織に問題がある。
■顧客不在
・忙しくて時間を割いてもらえない
・POが業務知識を持っていない
■デキる人がいない
→ ペアプロとかで教えてあげて、デキる人を作る
■チームの意識を一定に保たないと、ダレる
・規律を守らなくなると、緩やかにチームがダメになっていく。
・規律を保つ専任のスクラムマスターが欲しい。。。
・モチベーションの維持が難しい。当然、気が乗らない日もある。
逆に、アジャイルをやってみて改善された問題はあるか？ ■見積もりの精度が上がった。
・見積もりがブレることが無くなり、残業が無くなった。
■ユニットテストとCI（継続的インテグレーション）をメンバーが明確に意識してくれるようになった。
■「それはできない」と顧客に言っても、納得してくれるようになった。
・それまでに成果を出し続けて、顧客の信頼を得ていた。
・信頼しているチームが「できない」と言うのだから、妥当な理由なんだな、と納得してくれるようになった。
■メンバーが明るくなった。
・手が空いていたら、他の人を手伝ってくれるようになった。
■良いこととをやるのに、抵抗が無くなった。
・やってみたことに対し、メンバから「スゲー」とか、反応が返ってくる。
・以前は、良いことをやろうにしても、上司の許可とか、工数の捻出先とかばっかり気にする必要があった。
以上でパネルディスカッションのメインは終了し、いつものKPTの時間になりました。
その後の懇親会にも参加してきましたが、ここでも有意義なお話ができました。
懇親会でKPTの話をしたんですが、前回のKPTに今回のKPTを上書きで貼る、という話がありました。
自分の職場ではイテレーション最後のKPTで毎回新しい模造紙使ってて、前回のKPTを貼ったままの紙に
上書きで貼るってのはやってませんでした。これも有効そうなので、やらないといけないなぁ、とか思ったり。
いくつか気付きが得られて良かったです。
あとパネルディスカッションで「方向性を向ける対象（≒チームメンバ）のことを知らな過ぎ」という議題が
出てましたが、この一言は私にとって結構強烈な一言でした。
確かに、メンバとは普段フツーに会話してますが、相手のことをよく理解できているかというと、ぜんぜんダメです。
これは反省点として、もう少し相手のことを知る努力をしていきたいと思います。
今回も有意義な時間を過ごす事ができました。スタッフの皆様、いつもありがとうございます。
こーゆうイベント的なの、良い企画だと思います。これからも続けて欲しいです。
次回も楽しみにしてます。
2012/9/1(土) 「函数プログラミングの集い 2012 in Tokyo」に参加してきました。
■PARTAKE（告知サイト）
http://partake.in/events/9a5f18bf-ca0c-48cd-a050-8a564c1ab0d9 ■発表資料まとめ
https://sites.google.com/site/fpmjp2012/home ■togetter
その１：
http://togetter.com/li/366053 その２：
http://togetter.com/li/366046 ちなみに私、関数プログラミングは、大学3年生（もう10年位前ですが。。。）の講義で受講した
ML と
OCaml 、あと去年から参加している
「スタートHaskell」という勉強会 で出会った
Haskell ぐらいしか経験ありません。
ただ、やっぱ関数プログラミングに触れてみた感覚は強烈で、現在学んでいるHaskellにも刺激されっぱなしです。なので、初心者ながら今日のイベントに参加してみることにした次第なのです。
会場はお茶の水女子大学の理学部３号館です。
かなりの大規模イベントで、参加者は200人くらいでしょうか。
しかも参加者はほぼ男性なんですが、会場は女子大という。。。
あと、名古屋でも関数型プログラミングの勉強会がいくつか開催されているのですが、それに関係ある出席者もかなりいらっしゃったようです。主催者さんや発表者さんの半分くらい？も名古屋出身かな。
実は、私も大学と大学院は名古屋なので、親近感がありますねー。
以下、各発表のメモと感想です。発表スライドに無い内容も含め、自分への覚書です。
関数型言語初心者と仕事でF#使ってみた(仮) @bleis さん
■F#なら、.NET Framework 2.0でも開発できる。（3.5や4.0でなくてもOK）
■とある開発でF#を使ってみた。
① 今までやっていた作業を自動化するWebアプリ
② 納期が厳しい
③ .NET Framework 2.0の環境
→ 開発メンバの一人は、F#の経験なし。
→ 「実践F#」という書籍を読んでもらった。（↓かな？）
→ ペアプログラミングで教え、レビュー時間が取れないときは「直しといたから見といて」とコード渡した。
■教えたこと
① 自分でループを書かない方法
② リストの先頭や最後にデータを追加すべきではないのはなぜか
③ nullとNoneの違い
→ 結果、範囲外アクセスや、ぬるぽバグはほとんど出なかった。
→ 関数型初心者がいても、サポートできればなんとかなる。
■F#初心者さんの感想
① 制限が厳しくて、慣れるのが大変
② バグがあんまり出なかった
③ C#とF#だったら、（今の時点では）C#の方が気が楽。
■ある案件では、C#で8000行のものがF#で1600行で済んだ。
■F#は.NET Frameworkが使えるところが良い。Haskellとかだと実際の現場で使うのは厳しいかも。
■F#で性能問題になったことが無い。Visual Studioには性能を調べるツールがある。
■少しでも関数型言語にシフトできるように、手続き型言語のプログラマをもっていきたい。
関数型プログラミングの今昔(仮) @ksknac さん
■関数の数学的定義
AからBへの関数は、以下の性質を満たすA×Bの部分集合Fである。
すべての a∈Aに対し、(a, b)∈Fなるb∈Bが
１つだけ 存在する
→ プログラムでいう関数とは異なる。
■関数か否かは集合次第
・入力の集合を絞れば、入力に対し出力が１つにすることも可能。
■そもそも、「関数型言語」の定義自体が難しい。
（どの言語でも通じる言葉で説明できない）
■では、「関数型」とは？
・プログラミングスタイルへの形容
・言語に関係なく実現可能
■「関数型言語」という単語を、関数型プログラミングがしやすいという意味以外で使ってはいけない
■実は、Red Bullという飲料は、Functional！！ だって、公式Webに書いてあるし。
（エンジニアさんがRed Bull飲んでる姿よく見かけますが、そーだったのですね。。。）
■関数化による効果
・プログラみの見通しの改善
・プログラムの分割・結合が容易
■独自の関数型言語が乱立 → 多くの言語を統一するため、Haskellが開発される
■まとめ
・数学的な意味で関数か否かが重要
・関数型とは、言語でなく記述に対する形容詞
継続開発のススメ Erlang/OTP 編 @voluntas さん
■資料：
https://gist.github.com/9ee65f0dfa9b7dd78fde ■仕事でErlangを使っている。
（すみません、ちなみにErlangの読み方、今日初めて知りました。。。アーラン、って発音するみたい）
■エディタ（Emacs or Vim）
エディタはEmacsを使うべき。Erlang/OTP ではソースコードに erlang.el が同梱されている。
■コーディング規約
コーディング基本的には erlang.el に倣う。ただ個性の話になるので、そのたび開発者間で意見をぶつけ合う。
（じゃんけん、という話も。。。）
■開発環境
Macで開発するメリットがほとんど無い。のでLinuxにすべし。
■ビルド
Erlang の開発環境は rebar というビルドツールが出てきたことで激変した。（今まではMakefile）
■バージョニング
ソースコードのバージョンの付け方が大事。バージョニングというのは一番「決めておくべき」事。
・参考：Semantic Versioning 2.0.0-rc.1 日本語版
http://samidarehetima.blog9.fc2.com/blog-entry-182.html ■単体テスト
単体テストはコード書き換えたときの保険で、テストとすら見なされていない。ある意味、自己満足の範囲。
仕様がわかってないとそもそも意味ないので。仕様ミスってたらおわり。
■受け入れテスト
単体テストよりも受入テストを重視し、ブラックボックステストを実施する。
■キャパシティテスト
リリースするソフトウェアは、必ずキャパシティテストする。
■定期アップデート
Erlang VM や依存しているライブラリは、１ヶ月に１回、定期アップデートしてる。やらないと破綻が始まる。
古いままで使い続けて幸せなことはない。後でまとめてアップデートしようとするとコストもかかる。
■ドキュメント環境
・ドキュメントがないと運用に響く。顧客からは確実にドキュメントを求められる。Wordは辛い。。。
・ドキュメントはバージョン管理されてナンボ。
→ Sphinxつかってる。
・見栄えがよいドキュメントが重要。フォントも商用のものを検討。
■自動化
Jenkinsを使って自動化してる。ボタン一発ですべての品質が保証される、ということが重要。
■継続開発
・継続開発は負債になってる。
・継続的デリバリーは、継続的に固定費が発生 → 仕事がとりにくくなる。
・成功すれば成功するほど負債が増える。
・やりすぎはよくないが、やりすぎないと継続開発はできない。
・大事なのは政治力。継続開発するための予算とること。
■レビュー
・仕様を理解してレビューする専任の人がいる。
・レビューとは、「メンテナンスができるようになっているかを確認すること」である。
・知らない状態が生まれるのは許されない。
■CM1
「Learn You Some Erlang for Great Good!」という、「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")のElrang版が出版予定。
---
★感想：
いやー、非常に実践的な発表でした。Erlangを知らない人にも、かなり役立つ内容です。
私も最近は会社でアジャイル開発とかやり始めて、継続開発とか自動化とか意識することが多くなったので、
一つ一つの話が非常に腑に落ちました。是非参考にさせていただきたいです。
「すごいHaskell」を支える技術 @tanakh さん
↑クリックすると発表資料に飛びます↑
■「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")の翻訳をした。
（私が参加してる読書会「スタートHaskell2」のテキストでもあり、良書です）
■Haskellで詰まったところ（当社調べ）
・1位： モナド 85%くらい
・2位： Cabal 10%くらい
・3位； 特になし 5%くらい
（半分はジョークかと思いますが。。。大体こんなイメージ）
■モナドの謎を解き明かす、のは永遠のテーマ
（ちなみに、ゼノブレイドというゲームにモナドが出てくるらしい。。。）
■「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")は、モナドを理解するためにある、といっても過言ではない。（らしい。。。）
■Typeclassopedia
・日本語訳:
http://snak.tdiary.net/20091020.html ・Haskellの型クラスを解説した記事
・
Functor -> Applicative Functor -> Monad の階層に従って書かれたもので、わかりやすいと評判。
■モナドを理解するポイント
「Applicative Functor」 and 「Typeclassopedia」
---
★感想：
「スタートHaskell2」でもFunctorやIOが登場する章に突入し始めたので、モナドの謎を解き明かせるか、期待！
HaskellでWebアプリ ～Yesodを使って面白かったこと～ @seizans さん
■Haskellを学べば上手にプログラミングできるようになる、と教えられHaskellを始める。
■Yesodとは
・HaskellによるWebアプリケーションフレームワーク
・Haskellのメリットを活かせるように作られている
■Yesodを使うことの利点
・型システムの恩恵が受けられる
・セキュリティが充実。（SQLインジェクションとかクロスサイトスクリプティングとか防ぐ）
・その他、いろいろあるが、発表資料参照。
■YesodによるWebアプリ開発の詳細
・詳細は↑の資料参照。ハンドラとかも出てくるし、聞く限りどうやらMVCモデルのようです。
---
★感想：
@seizansさん、今日もあいかわらずイケメンでした。
ちなみに私が参加してる「スタートHaskell2」と「TaPL読書会」の主催者さんです。
私はWebアプリケーションフレームワークとしてStrutsを長いこと使ってますが、その経験があれば
比較的楽にYesodの仕組みに馴染めそうな印象でした。
ただ、やっぱHaskellでスラスラとコードが書けないので、そこがネックになりそう。。。
あと、問題はやっぱり保守でしょうね。
アプリケーションは長い間保守しなければならないわけで、現実問題として、Haskellに習熟している
エンジニアはごく一握りなわけで。。。
開発時にHaskellエンジニアを確保できたとしても、保守フェーズに入ると。。。難しい問題です。
F#を学んで感じた関数プログラミング習熟度レベル @pocketberserker さん
■関数プログラミングにも習熟度レベルがある？
・再帰が書けるレベル
・再帰を使わずに高階関数を使って書けるレベル
・モナドを使えるレベル
・モナドを自作できるレベル
・etc
■力関係
・再帰 ＞ fold系 ＞ 目的に特化した高階関数
・力の弱いものを使ったほうがコードがわかりやすいので、そっちから使っていくべし
■高階関数
・高階関数に慣れるには訓練あるのみ。
・上達しないのは、手を動かすのが足りないから。
・リファクタリングするにはテストコードが必須。
■モナド
・モナドは、使って慣れるところからはじめる。
・慣れてきたらモナド自作。（まだ見ぬ高み）
■習熟度レベルのまとめ
・FPには習熟度レベルがあるっぽい。
・次に挑戦する段差が何か知ることができれば学びやすいのかも。
・一歩一歩進めばそのうち上達する。
■発表後半：FSharpxのIteratee
・自分の知識が足りず、ついていけなかった部分が大半でした。。。F#のコード読めないし。
・詳細は↑の発表資料参照。
---
★感想：
高階関数や再帰の力関係については、先日の「スタートHaskell」でもちょうどネタになったところでした。
あと、「次に挑戦する段差が何か知ること」というのは、確かに大事ですね。
F#、いつかちゃんと勉強したいな。。。
テストにおける静的型付け函数型 @kyon_mm さん
↑クリックすると発表資料に飛びます↑
■@kyon_mmさんの、ソフトウェアテストの定義：
→ 誰が確認しても一意に定まるもの
■ソフトウェアテストの分類
・テストレベル
・テストタイプ
・テスト観点
・テスト手法
（詳細は発表資料参照）
■まとめ
・静的型付け関数型プログラミングによってテストコードは減らせる
・現状で減らせるのはコンポーネントテストレベル
・結合テストやシステムテストの工数を如何に減らせるかが、ソフトウェア開発でその言語が
使われるようになるための鍵ではないか。
---
★感想：
・発表者さん： 「この中で、テストエンジニアっていらっしゃいますか？」
・会場の皆様： 「（シーン・・・）」
・発表者さん： 「そうですよね～。。。分かってたさ！」
あと、うさみみバンドを付けてプレゼンを行う発表者さん、初めて見たよ。。。
「書いたコードがコンパイルタイムに（IDEなら書いているそばから）エラーを強力に検知する。」という文言がありましが、これ、私もEclipse使ってますがかなりの恩恵ですよね。
テキストエディタとIDEでは、「コーディングのしやすさ」ももちろんですが、「リアルタイムテスト」という観点も見逃せないと再認識しました。
イベントドリブンプログラムの関数型的書き方 @osiire さん
↑クリックすると発表資料に飛びます↑
■イベントドリブンプログラミングは、多くの状態や複雑な条件分岐が登場する、やっかいな状態遷移プログラミング
■代数的データ型とパターンマッチをうまく使うと、管理すべき状態が減り、網羅性もチェックできる。
■第一級のイベントとコンビネーターを使うと、生のイベントを意味イベントに翻訳することができる。
意味イベントと「やりたい処理」を結びつければ、イベントドリブンプログラムはわかりやすくなる。
---
★感想：
自分のキャパ不足もあり、状態遷移の変換について、聴講中に理解しきれない部分がありました。。。
思いつくまま状態遷移をコーディングするより工夫することで改善できることがある、との発表ですが、思いつくままコーディングしちゃった時点で満足して思考を停止しちゃいそうな自分がいて、反省。。。
予定通り、17時半くらいに全セッションが終了しました。
午後は7Fの応用セッションと、2Fのトピックセッションの２会場に分かれましたが、私はずっと7Fでした。
なので、2Fの発表は聞けなかったのがちょと残念です。
しかし、「関数型プログラミング」という同じ方向性を持った人が全国から集まるイベントということで、とても熱気がありました。
なによりも、発表者や聴講者の目が輝いていた、というか、「関数型プログラミング」という夢中になれるものを持っているエンジニアや研究者をたくさん見て、羨ましく感じました。
自分はまだとてもその域に達していないので、勉強あるのみです。
有意義なお時間を提供してくださった運営者様、発表者様、会場提供者様、ありがとうございました。
-->
