代休。楽しみにしていた「オブジェクト倶楽部2010夏イベント」に参加してきた。オブラブのイベントは、初参加。
以下、印象に残っている箇所と、メモに残っている箇所を、簡単に書き残しておく。自分の感想と区別するために、セッションの内容を引用のように記載している。ただし、内容はあくまでも自分のメモであり、講演者の言葉や主張と異なる可能性があることだけ、ことわっておく。
しかし、代休がたまっていると、色々なイベントに顔を出せてよい。これは継続したい（代休をためる方ではなく）。
開始前
梅雨も（たぶん）あけ、まさに夏な天候。『当日は、カジュアルな服装での参加をオススメします』と書いてあったので、カットソーにノースリーブのロングカーディをはおり、デニムのパンツでお出かけ♪平日に開催されるイベントは、（スーツではないまでも）ネクタイしめていくので、ちょっとした違和感。でも、ネクタイしめていかなくてよかった。
アイスブレーク
。。。
あの空気を作れるのは、才能だと思う。
招待講演『ファッションと実践』（関 将俊氏）
「ファッションリーダーを目指してみるも、やはりなれない」という話の流れにのせて、「方法論、モデルを説明し、売り込む」体で、関氏のこれまでの実践（の発表）をまとめたセッション。マニアじゃない人向けの話だと思う。
ツイートの状況がスクリーンに表示されていたが、意外にもあまりツイートされていなかった*1。
モデルとは、ある視点における本質。模型でしかない。「ある視点でモデル化→モデルを用いた説明を繰り返す→このモデルで成功できる」になりがち。ファッションリーダーを目指し、方法論を説明し、売り込む。是非、みなさんにもインストールしてほしい。なお、小さく分けられた要求単位、機能単位を「ストーリー」と呼ぶ。
忍者式テスト
最初からテストドリブンで開発する。V字モデルでは、忍者式テストは上の方（要件定義⇒システムテスト、基本設計⇒結合テスト）、TDDは下の方（詳細設計⇒単体テスト、実装）。要求とプログラムをインプットとしてプロセスを実行する。テストスイートの見直しをかける。
計画ゲーム
イテレーション、ウォーターフォールを複数回やると考える。256日のプロジェクトであれば、128日を2回をやると考える。64日を4回…。ストーリーベース、反復ベース。ストーリーがいつ手に入るか。まず、たくさんの要求をストーリーに分け、優先順位をつける。その後、バグもストーリーとして扱う。変更もストーリーの追加とする。そして、ストーリーの優先順位をつけ続ける。これで、ある日突然失敗しない。
テストのレート
ストーリーの数が増えると1日でまわらなくなる。iTunesにならって、好きなテストに、おすすめやレートをつける。今日のおすすめテストスイートを自動生成するツールを作成。RWikiで。
テストのたびにレートを見直す。一度に見直すのは無理（iTunesでも、レートを一度につけると大変）。リスクベースドテストという手法があるが、これのカジュアルな実装。
プロセスのプロセス
大規模な開発の場合、規模と向き合おう。規模の大きさを味方につける、量を利用する。
バッチ処理システムに例える。大きな集合を扱う方法に、MapReduceがある。みんな1次論文も読まずに使っているが、分散うんぬんは後から。SQLとMapReduceは、集合の扱い方に対する戦略が違う。SQLは集合の演算。MapReduceは集合の走査。キーで並んでいる集合を走査する。コントロールブレイク。巨大な集合を一度に扱わない、集合を演算しない。結局、順次処理すると楽。最後、要素を順にたどるという操作においては、線形になる。ストリーム。どんなに大きくても、ちょっとずつ仕事をするしかない。似ていない？
小さなストーリーによる大きな集合を扱う。ポイントは4つ。全てを一度に処理しない、今日のテストストーリーに集中する、身軽な計画、絶えず見直すための見直せる量。ここで、プロセスを調整するメタなプロセスが登場する。要求（ストーリー）と前バージョンのソフトウェアをインプットとして、プロセスを実行する。バッチ処理のプロセスは変わらないが、チームは変わることができる。メタなプロセスによるフィードバック。
ここで、繰り返しがないとフィードバックができない。繰り返しが多くなるとフィードバックが多くなってよい。1年のプロジェクトの統計をとるには、100年かかる。
つまるところ、、PDCAといっしょw
ロールプレイング
「よい出力（製品）か？」「自分たちは正常か？」を問う。「自分たちが正常か？」とは？理想の開発者を演じる。価値観は、場（無数の状況と判断の組み合わせ）から学ぶ。判断へのフィードバックをする。プロセスを見直す。
仕事は仕事なので。理想の違いによるコンフリクトも仕事。（プライベートでは言わないが）仕事だから言う。
（話の流れ上の）結論
どこでも使えるモデルはメタすぎる。PDCAとか。商品化は難しそう（儲からなさそう）。やはり実践。
実際には、随所に「簡単」とあったが、省略。メモの偏り方にびっくり。予習なし（ごめんなさい）。正直、内容はあまり理解できなかった*2が、、一貫した主張で、ウィットに富んでいて、皮肉もたっぷりで、刺激的な話だった。自分の仕事のスタンスを見直す、たいへんよいきっかけになった。
すくすくスクラム『スクラム入門〜やさしいスクラムの組み方〜』
すくすくスクラムによる、ワークショップ。
1. アイスブレーク（林 栄一氏）
体を動かす。
アイスブレークでは、ドラムサークルのセッションを行います。
http://d.hatena.ne.jp/objectclub/20100708/1278582590
リズム楽器を使ったチームビルディング体験から始まって、思いっきり楽しみながら実際にスクラムを回してみる体験ワークです。みなさんにもシェーカーを使ってリズムを体感していただきたいと思っています。
これ読んだ時は、何するのかと思ったが、本当にそのままだった。体がほぐれ、心もほぐれるからすごい。
参加の目的などからチーム名を決め*3、チームを表現するパフォーマンスを考えたことで、「ただ同じテーブルにすわった人」から「チーム」へと変わった。これいいな。
2. 講義（今村 哲也氏）
一般的な話なのだが、今村氏の言葉で語られ、書籍で学習するのとは全然違うなぁと感じた。大変にわかりやすかった。一生懸命聞いておかないと、ワークショップにかなり支障をきたす（むろん、ひっしで聞いた）。
歴史
1986年：野中氏、竹内氏による、成功したチームの管理手法を研究した論文。1990年：ADM社のケン・シュウェイバー（Ken Schwaber）氏。1993年：ジェフ・サザーランド（Jeff Sutherland）氏が問い合わせ。1994年：ジェフ氏による初期のスクラム。1996年：Individual社にケン、ジェフの両氏。スクラム導入コンサルを通じて、形式知化。
大切な要素
まず「リズム」、そして「フィードバックループ」「継続的な改善」。ループでよくなっていく。これは、2つの結果をもたらす。1つは、人間的な側面として「自律的で自己組織的なチーム」。自分たちで自分たちの力が発揮できるようにする。これには「信頼」と「コミットメント」が必要。もう1つは、仕組み的な側面として「経験的、適用的なプロセス」。
概要
実測駆動の制御プロセス。PDCAサイクルの実装の一種。
全体の（1回の）流れは、(1) スプリント計画 Part.1：成果物「プロダクトバックログ」、(2) スプリント計画 Part.2：成果物「プロダクトバックログ」、(3) スプリント（＋デイリースクラム）：成果物「プロダクトインクリメント（製品）」、(4) スプリントレビュー（お披露目）、(5)スプリントレトロスペクティブ（振り返り）。
「スプリント」とは、1くぎり。一度期間を決定すると固定。チームを取り巻く環境が変化するサイクルよりも短くする。「プロダクトバックログ」により何を作るかが決まり、「プロダクト」が出荷できるように働く。
役割
プロダクトオーナー：収益性（ROI）に対し責任を持つ。スクラムチームの作業結果を許可または却下する。スクラムマスター：内向きには、チームの機能と効率を支援、保証する。リズムを作る会議体を設定。外向きには、関与と支援を促進しつつ、干渉からチームを守る。スクラムチーム：1チーム7人（5〜9人）。あまりチームメンバーが少ないと、意見の是正がされにくい（変な方向に行きやすい）。プロダクトバックログの優先順位をもとに、スプリントの目標を設定する。決定と管理する権限と責任を、チーム自身が持つ。ステークホルダ：まんま。
成果物
プロダクトバックログ：プロダクトの要件の一覧。誰でも追加可能。優先順位はプロダクトオーナーがつける。スプリントバックログ：チームの作業を定義したタスク一覧。スプリント計画 Part.2で作成。スプリント中、チーム全員が追加、変更、削除可能。プロダクトインクリメント：出荷可能な製品。
活動
デイリースクラム（朝会）：日々のリズムを生みだす。夕会、朝会＋夕会でもよい。スプリント計画 Part.1：プロダクトバックログを明確に。スプリントで扱う項目を仮選別。スプリント計画 Part.2：仮選別した項目をタスクに分割。スプリントで扱う項目を選別。プランニングポーカーなどの見積もり手法がある。スプリントレビュー：プロダクトインクリメントを見せる。チームが今どこにいるか、今後どこに進むかを共有することが目的。ここでは何もコミットメントしない。フィードバック→ブレストのみ。スプリントレトロスペクティブ：スクラムマスターとスクラムチームで、スプリントをさらに楽しく、生産的にするにはどうするかを議論。KPT（Keep、Problem、Try）法などを用いる。
最後に
次のようなモデルとの対応を考えると、面白い。
- PDCAサイクル（デミングサイクル）
- SECI（セキ）モデル（知的創造プロセス）：スプリントの中で各人が得た知識を共有、表出、形式知化
3. ワークショップ（たくさんのスタッフの方）
何をやるのか、大変興味深かった。チーム内で、プロダクトオーナー（1人）、スクラムマスター（1人）、スクラムチーム（2人）を決め、なんと幼児向けの「モービル」を作成した。与えられたのは、（初期の）プロダクトバックログのみ。会場には、竹ひご、折り紙、はさみ、のり、セロテープ、麻紐などのツールが用意されていた。
スプリント0は、正直、何をやってよいかよくわからなかった。ここで色々悩んで、スプリント1からはチームが軌道にのった。ちなみに、うちのプロダクトオーナーの第一優先は「強度」。
スプリント1だけで、かなりノウハウが蓄積された。それをすぐにスプリント2で取り込めるのが素晴らしい。これは、けっこう感動。
例えば、次のようなことがわかった。計画面では「一段目と二段目を取りつけるには、一段目と二段目を持つ人、取り付ける人の2人が必要である」「飾りを切るのに予想(2〜3分)以上に時間がかかる」など。実装面では「つり合いは最後に調整する方が効率的である」「飾りが重いと、結び目を“絶妙なポイントで固定”しないとつり合いを保てない（マラカスを使ったから）」「結び目をテープだけでは固定しきれない」など。運営面では「どんどん作業をするメンバーと、全体を見ながら作業をするメンバーがいること」など。
1回のスプリントが10分だったが、残りの3分はものすごくあわただしくなる。やっぱりそんなものだ。あと、スクラムマスターとスクラムチームの役割分担が難しかった。これは実際にも混乱しそうだ。。
最終成果物は、、なんてことだ（他のチームの成果物は、すごくゴージャスだった）。。仕方がない。
本当にちょっとしたスクラム体験ができた。期待以上、すごい。それと、みんなで盛り上がっていこうという雰囲気がすばらしい。
ライトニングトークス
全般的に、言いたいこと詰め込み過ぎな感が。たくさん発信したいことがあるのだなぁと。みんなすごい。。
終了後
大きな（体験型）イベントだったが、スムーズに進行され、すばらしかった。参加者への配慮にも富んでおり、頭が下がった。右も左もわからず参加したが、楽しむことができた。
この運営ノウハウを「モデル」にすれば「ファッションリーダー」になれるのではないか。
