Scrum Gathering Tokyo 2011:Day2 に参加してきた #sgt2011

勉強会 Scrum Agile


(写真：Day 2最後のセッション『WRAP UP!』、フィナーレの一幕。)


2011/10/19(水)に行われた有料イベント『Day1』に引き続き、Day2も参加してきました!! Day1及びScrum Gathering Tokyo 2011全体の内容についてはDay1のブログレポート及び派生リンク等をご参照下さい。


開催場所は早稲田大学理工学部55号館。XP祭りX以来の早大訪問となりました。


会場内に入ると、sgt2011の看板などが幾つか立てられており雰囲気を盛り上げておりました。

また、今回は以下の様に『Job Board』なるものもお目見え。(内容が内容なので一応ボカシ入れました)


今回Day2で個人的に参加したのは以下の赤枠線内のセッションです。参加したものについて順次メモ＆レポートして行こうと思います。(※この他のセッション・ワークショップに参戦された皆さんも是非どのような内容だったかブログ等でレポートして頂けると嬉しいです。)

オープニング [9:40-10:00]

  • 230名申込に対してこの時点での参加者は100名未満。
  • ワークショップ多め、会場には早く来てね。（参加したいのあれば）
  • 会場説明
  • ハッシュタグとか説明
  • スクラムのおさらい
    • (Day 1と同内容のスクラムに関する説明・海外でのScrum Gatheringの展開についての説明あり。)
  • セッションアピールタイム
    • チームたぬき
      • 講演3本立て/Day1行けなかった方もご安心の内容。
      • ラズロさんを筆頭に強力な講師陣。
    • チームこっしー
      • スクラムを始める人達を対象としたもの。
      • 林さん：スクラムの心/角さん：ユーザーストーリー/安井さん：逆計画ゲーム
    • チームメイド
      • スクラム実践者対象。色んなカベを乗り越える方法をみんなと一緒に探求。
      • お悩み相談会/現場を変えた方達のパネルディスカッション/タスクボード/バトルロワイヤル
    • チームにゃんちゅう
      • Jeff Patton氏に喋ってもらいます。4本立て。
      • 情熱を持ったプロダクトオーナー、とてもお得なセッションです。人間中心設計。
      • 3,2,1 Passion!! Passion!!
    • Scrum Boot Camp
      • 丸一日掛けてやります。他のセッションには行けないよ。本だけだと不安なところをお勉強。
  • Scrum Gathering Tokyo 2011 ワークショップデイ 始まります！

Agile Transformation Strategy (大企業のアジャイル化戦略) [English] [10:00-10:45]

英語セッションで会話も英語、なのにスライドは日本語という若干変わった構成でのセッション。個人的には英語に自信が無かったので日本語スライドの情報を必死に追っておりました。(^_^;)

以下メモ。

  • 自己紹介
  • アナリストから
    • アプリケーション開発者へのインタビューで、アジリティの拡大は共通の問題であることが明らかになりました…
    • 特にチームが多くの場所に分散して複数のプロジェクトで仕事をしている場合に当てはまります。
  • 顧客から
    • 異なるソフトウェア開発アプローチ：作業時間の50%以上を開発インフラの管理に費やす
    • プラットフォーム全体にグローバルに拡大：設計チームのリーダーは丸一日、10時間以上をコミュニケーションをよくするために費やしていた
  • 私たちのビジョン

CollabNetのプロセス変革へのアプローチ

  • 企業変革
    • Choosing is losing("選べば失敗する" - すべてを同時に実行せよ。)
    • Begin with the end in mind("目的を持って始めよ" - 完成図を描いてから取り組め。)

  • 企業変革のパターン
    • 自然発生的変革
    • 計画的変革
    • 偶発的改革
  • Agile Enterprise Transformation - アジャイル企業変革
    • 確立
    • 展開
      • シニアマネージメント参加
      • プロジェクトの選択基準
      • 組織内認識の文書化
      • アジャイル布教
      • 内部外部へのコーチングモデル確立
      • ALMプラットフォーム
      • フォーラム設置
    • 拡大
      • 社内コミュニケーション促進
      • 変更/リリース管理
      • 管理の統合
      • ガバナンス設立
  • アジャイル変革モデル
    • 非アジャイルプロジェクトチーム
      • ↓[調査]
      • ↓[調整]
      • ↓[プロセス定義]
      • ↓[計画的適用]
      • ↓[変革]
    • アジャイルプロジェクトチームに！
    • 単一チーム→複数チームへ展開
  • 注意：企業はただの大きなワークグループではない
  • Agile Readiness Assessment - アジャイル適応準備アセスメント
    • 現状環境を評価
    • データを使った計画
  • Managing the Transformation - 変革の管理
    • スコープを定義
      • 資産の目録
      • 現状環境を評価
  • タイミングを定義
    • ヴィンテージチャート
  • お客様の声
  • Some Ads(宣伝)
    • 私の Global agile transformation Strategy についての記事をご期待ください。
    • Agile Journalに来月掲載予定

アジャイルとクラウドでビジネスが加速する [10:45-11:30]

お二方によるトークセッションの形式を取った講演。


……とセッション開始冒頭、当日sgt2011スタッフとして動いておられたMiho Nagase(TwitterID:@miholovesq)さんがお二方の前で豪快にコケるというハプニングがww それを受けて玉川さんが『今豪快なアトラクションが...』とコメントされる和む一幕も。

  • 倉貫さん：自己紹介
    • 社内に広めるも賛同者ゼロ
    • 勉強会などに参加
    • 自分の脳のブレーキを壊す人との出会い
    • エンジニアからマネージャーへ
      • 直属の先輩でありリーダーの退職
      • マネジメント経験ゼロ
      • ケントベックを参考にマネージメント
      • アジャイル開発が教科書
      • 逆転の発想で乗り切る
    • ガラパゴスなキャリア戦略
      • 自分を取り巻く環境そのものも自分の価値
    • 社会人としての転機
      • マネージャ挫折、転職を決意
      • 好きな事だけやってから辞めよう
    • ディフェンシブな開発
      • ディフェンシブな開発がもたらす問題
    • 第2の契機
    • ディフェンシブな開発から脱却を
      • 納品をしない受託開発。
    • サービス型の受託開発
      • クラウドで使えるソフトウェアの開発及び運用を
    • Point of Useで大事な事
    • 継続性
    • 保守性

ここで玉川さんにバトンタッチ。

  • 玉川さん：自己紹介
    • もともとは研究開発部門に居た。
    • IBM：ラショナル
    • Agileエバンジェリスト
    • 背中に悪寒(これはやばい、業界を大きく変えるものだ...)
      • 帰国、日本amazon日本法人立ち上げに参加
      • 日本にきちっとした形でクラウドを広めたい
      • Amazon EC2 立ち上げた人？（やっぱり居ない）
      • ＜悪寒が走ったデモ実演＞
        • 自己紹介中にサーバを立てる！時間にして数分でサーバ構築完了。


      • ※これは大きな力になる。日本が打って出るための。

    • エバンジェリスト良い事ばかりではないよ
      • 最近はかなり多くの講演をこなしている。(※ちなみに今月で20回らしい)
      • 息子さんとのやりとり。どうやら分かってくれていないらしい…(笑)
息子：『いつもパパ何しに行ってるの？』
玉川さん：『こうえんに行っているよ。』


この後はテーマに基づいて2人のセッショントークが最後まで続きます。


    • 新規事業の事業計画を書く上で
      • 以前は何億も掛かっていた...
      • Amazonだと全然余裕。安く行ける。ローコストで始められる。

    • 最近のIT企業動向。
      • クラウド：Sierはどうしてるか
        • 今までは『プライベートクラウドを作ろう』
        • 今年はアマゾンさん使おうか、という話も出てきている。
        • 結構去年とか人が移動した。
          • その旨をブログに書いてたり
          • 新しい時代の幕開け？

    • キャパシティプランニングが無くなった。
      • 見積もり
      • 上乗せして買う
      • 結果、全然使われてないサーバが出来る事に･･･

    • もともとサーバ費用安いのに、高い金をかけて買うのはぼったくりだ！
      • スモールスタートなんだけどスケールアウトも出来る。クラウドは。
    • お客さんのサービス
      • 最初はスモールで
      • ボタン１つでスケールアウトできますよ。

    • 仕切りなんてものはないよ。
      • 付加価値は自分でつけてください。
      • 代理店モデルの破壊。

    • 受託の階層構造モデル
      • 代理店モデル:日本はまだまだそこが求められている部分がある。
    • 納品の無い受託開発
      • 原因：一括で発注、請負がダメ。
        • →納品しなければ見積もりしなくていい･･･？
        • クラウド上にアプリケーションを載せる
        • クラウド上のものを見てください。それが僕らの商品提供です。
        • ↓
        • 客：『ポカーン』
        • いつまでにやってくれるの？→定額ですよ。約束しません。信頼してください。
    • 一括請負でクラウドが使えたか：難しい部分がある。
      • ビジネスモデルとして難しい？To 一括請負
      • これまで:
        • 物理的なデータサーバ
        • クラウドに移行、コストは下がってるので利益率はあがっている
        • （運用ビジネス）

        • （受託開発）
          • お客側にクラウドと直接契約してもらう
          • 受託の範囲を狭める
          • ハード・ソフト→ハードはAmazonで契約してくれ。そっちはユーザで勝手に。
      • 倉貫さん『起業を勧めます。』

    • やってないと競争に打ち勝てない。
      • Agile/Scrumでないと
    • リーンスタートアップ
      • スタートアップ業界で話題。
      • 今まで：お金が入ったうえで事業が出来る。
        • 途中で引き下がれない。
        • 変えやすくするためにリーン（無駄なく）進めて行く。
      • Agile/Scrumでも主流に。
    • グローバル展開しやすい環境が整っている。
      • クラウドが整ったことで、遠隔地からスタート
      • 『テクニカリーには、日本に持ってくるのは数時間で出来る』（byネットフリックス）
  • アジャイル×クラウド×エンジニアのキャリア
    • 2011年位で転職ブームが。
      • キャリアとして、どういう事を目指すのが大事なのか。
      • クラウド＝アジャイルなインフラ
        • もう、ソフトウェアの一部です。
        • デプロイ/障害検知/バージョンアップ
        • 運用周りもプログラミングしちゃう。
      • 数百代のサーバを1人で管理出来る時代。
      • 新しい技術に対して怖い/凄いという感情。後者の考え方になって欲しい。
      • 過去のスキルを捨てるマインドセットが重要。
      • 今は『幕末』に近い。
        • 閉塞的/外圧/グローバル
      • 坂本竜馬的な生き方がしたい。


      • 新しいのが良いなと思える＝以前の考えを捨てられる人。
        • 過去の栄光にとらわれると、変われない。

      • インフラの人がアマゾンを目の前にして
        • 『どのくらいのスペック？わからないと出来ないよ...』：先に進めない
        • 深く理解『瞬時に調達できる・・こんなことが出来るのか！』先に進める
      • 作る→使うの変化。
        • 大事なのは来たものを上手く利用して乗っかること。
        • Amazonと同じことやっても勝てない。乗ったうえで新しいサービスを
        • 車輪の再発明を考え出すと戦えない･･･？
    • アジャイルサムライ、流行ってますね
      • サムライって言葉好きじゃない。
      • 頭固い感じが･･･
        • 一回でも失敗すれば切腹か！
      • これからの時代は商人のつもりで。
  • 締め：これからのエンジニアは。
    • エンジニアの未来は明るいと思っている。

    • スクラムで組織変革、大事。
      • もし、本当にエンジニアで目指す部分があるのであれば
      • エンジニア、プログラミング突き詰めるのも良い。
      • 組織を変えてどうしたいかがあればいいけども...
      • エンジニアで行くなら起業、転職を。

    • 玉川『スクラムって最高ですよね』
      • 選択肢が増えている
      • 自分たちが一番輝ける場所を探して行こう。

実践知リーダーによる組織活性化とアジャイル開発 [11:30-12:00]


  • 浜屋 敏 氏
    • 自己紹介
    • 実践知研究センターの長は野中さん。
  • 実践知リーダーとは

  • Fujitsu Scrumで目指す事
    • 会社全体をもっと明るく元気にagileにする
    • 社員一人ひとりが実践知リーダーになる
    • 講師の話から得た気付きを『自分ごと』として自分の現場で実践する
    • みんなの思いを共有できる場を作る
    • 大局観と現場感覚の両立・スパイラルアップ
    • 固定的な役割＜みんなでスクラム
    • 組織の仕組み・制度＜個人の思い、行動
    • how どうやるか＜what 何をやるか
    • 成果（モノ）の共有＜物語（プロセス）の共有
  • こんなことやってきました
    • テーマと講師の紹介。
    • 様々なテーマで実践。
  • こんな事に気づきました
    • 動きながら考える事の重要性
    • 人を動かすためには、思いを持ってまず自分が動く
    • 現場でのヒトとのつながりが新しいことを生む
    • scrumが必要なのはソフトウェア開発、エンジニアだけじゃない！
    • 何よりも大事なのは動き続けてつないでいくこと

  • 神部 知明 氏
    • 自己紹介
    • 新市場開拓プロジェクト
    • ミッション
      • 従来富士通で取り組んでこなかった分野の開拓
      • クラウドの活用
      • システム開発チームの役割
        • 現場で必要とされるアプリケーションの開発
        • アプリケーション開発を支える基盤の整備


    • どうぶつ医療クラウドと震災対応
      • ペットの家族化傾向
        • 63%が『家族と思っている』
        • 15歳未満よりもペットの方が多い
  • 動物病院の現状とニーズ
  • 被災地支援：現場での経験
  • 被災どうぶつ情報をクラウドで管理
  • 動物救護センターへの支援内容
  • 現地の状況
    • 全てボランティア運用
    • 次々に人が入れ替わる
    • ツールの適用には作業プロセスの設計から運用まで定着させるまで支援が必要
    • 電源は自家発電、ネットワークはキャリアのデータ通信データ頼み
    • クラウドシステムの導入が必要
  • 現場の状況から判断：
    • モバイルアプリの開発が必要と判断
      • 健康管理アプリ（android）
      • 提供実績

  • 厳しいフィードバック
    • 2か月間での進化
      • アプリケーションの機能改善、管理項目の精査
      • 対象とする利用者の拡大
      • 目指すコンセプト
  • 物資管理の導入は整理整頓から
  • 運用マニュアル
    • 紙カンバン。
  • 開発チームの取り組み
    • 新市場開拓の現場が直面する課題
      • 情報シス、it担当者がいない
      • 富士通にノウハウが不足
      • すごいスピード感で業務が成長
  • XPをベースにカスタマイズ
    • 平常に
  • 突発的な開発への対応
    • チーム横断でメンバー召集
    • 頻繁にバージョンアップ＆自ら提供しに行く
    • カウボーイに変身
    • 腕の見せどころ
  • 開発メンバーヒアリング
    • 行って良かった。
    • 要求は非常にシビア。
    • 現場をみてみないとわからない部分多い。
  • バックエンドを汎用化し開発スピード向上
  • 最後に
    • 現場の信頼を得ることが第一ステップ
    • モバイル・クラウドサービスを最大活用

また、締めの言葉として野中さんのコメントが紹介されておりました。内容は以下。


ユーザーストーリー：ファーストジェネレーション [13:20-15:20]


プロフェッサーXのようなテレパスではない我々は、コミュニケーションを通じてクライアントの要求を獲得していかなければなりません。

本セッションでは、スクラム開発の中心的な存在である「ユーザーストーリー」の
基礎的な内容・記述方法・背景にあるパターンやリーンの考え方を、グループワークショップ形式で一緒に学んでいきます。

スクラムの基本知識を前提としますので、午前中のセッションを受講されることをオススメします。

昼食後はB教室に移動、初心者向けで展開されている角さんの『ユーザーストーリー』のワークショップに参戦。

  • 『ファーストジェネレーション』…元ネタ：Xmen。

X-MEN：ファースト・ジェネレーション　2枚組ブルーレイ＆DVD＆デジタルコピー（ブルーレイケース）〔初回生産限定〕 [Blu-ray]

X-MEN：ファースト・ジェネレーション　2枚組ブルーレイ＆DVD＆デジタルコピー（ブルーレイケース）〔初回生産限定〕 [Blu-ray]

    • 超能力で読まれないように仮面を被る。
    • ファーストジェネレーション
      • 仲良くしようという第一世代。
      • ここから頑張っていこうよ。
  • 本日の想定する参加者
    • ソフトウェア開発者
    • スクラムの基礎知識がある
    • USを使ったことが無い、上手く使えない
      • Q：対象外の人はいますか？→A.いないようです。
  • 自己紹介
    • 書籍：翻訳等の紹介
    • 告知『The Clean Coder』鋭意翻訳中！年明け以降。

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

  • アジェンダ
    • 第1部：ユーザーストーリーの物語
    • 第2部：実例による使用
    • 第3部：パターン、リーン、ユーザーストーリー
    • 目標：ユーザーストーリーの思考方法を身に付ける
第1部：ユーザーストーリーの物語
  • 石のスープのお話
    • 『せかいいちおいしいスープ』　マーシャ・ブラウン：ユーザーストーリーと似ている。

せかいいち おいしいスープ (大型絵本)

せかいいち おいしいスープ (大型絵本)

      • 書籍のあらすじ
はらぺこの三人の兵隊が、ある村で食べものをわけてほしいとたのみました。
けれども、村人たちは首を横にふるばかり。兵隊たちは、しかたがないので、石のスープをつくるといい出しました。
えっ、石からスープをつくるだって?! いったい、どんな味がするのでしょう? 民話をもとにしたマーシャ・ブラウンの楽しい絵本。
→最後には石のスープがおいしいスープになってめでたし、というお話。

  • ユーザーストーリーのスープ
    • それ自体はたいしたことない
      • 要求を網羅した仕様書ではない
    • 会話のきっかけとなるもの
      • みんなで情報や一時成果物を集める
    • 最初から最終成果物はわからない
  • XPのストーリーカード
    • ケントベック白本 1999年が最初

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

  • 開発者が要求を記述していてはうまくいかない。。
  • 要求の自由と責任をビジネスと分担するのが良いと思う。
  • ビジネスが積極的にかかわってくれるような『形』が必要。
  • ユーザーストーリの手法化
    • User Stories Applied / 2004年、マイクコーン

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)

  • ユーザーストーリーって何？＊
    • ユーザーや顧客のシステム要求がわかるように関係者全員がわかる言葉で理解していくもの。
      • 1.システム要求が
        • ビジネスとソフトウェアの間（海面）
      • 2.完了できるように
        • 終わりが見えなければならない
      • 3.理解していくためのもの
        • 記述ではなく、段階的に共通理解する
  • 【ワークショップ】これユーザーストーリー？理由も一緒に話し合ってください。
    • 幾つか出された例題について、チームでユーザストーリーの是非、及びその理由を議論。
  • 三幕構成
    • 1.＜役割＞として
    • 2.＜対象＞を（に）＜行為＞したい。
    • 3.それは＜価値＞のためだ。
    • 参考：『アジャイルな見積りと計画づくり』

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

    • 三幕構成は『物語の形式』
      • 物語を書くようにUSを書く
        • 設定：誰がどんな状況なのか
        • 葛藤：何ができないのか
        • 結末：何が欠かせないのか

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術

    • 例)映画『ロッキー』
      • 2番目と3番目の関連性が無い。
        • 勝とうが負けようが関係ない(現に負けているし)。
      • 解消されたので満足している。
  • 【ワークショップ】sgt2011に来ているのはどんな人？まずは自分の設定を書いてみよう。
  • 設定を作るヒント
    • 既知の事実（自分や知人から）
    • 観察やインタビュー
      • contextual inquiey
      • 師匠と弟子モデル
    • 葛藤から仮説→調査
    • 勝手な想像でペルソナを作るくらいなら、実在の人物を設定する
  • 【ワークショップ】sgt2011に行った結末は？まずは自分の結末をカードに書いてみよう。続いてグループで自分以外のストーリを書いてみよう。
  • 良いストーリー（物語）とは？
    • 続きが気になるもの
  • ここまでのまとめ
    • ユーザーストーリーは
      • 石である
      • 物語のように三幕構成で書く
      • 続きが気になったら質問する
第2部：実例による使用
  • 三幕で良いの？楽勝www問題
    • 良いときもあれば悪い時もある
      • 『記述』が最終目標じゃないよ！
      • 横が決まったら次は縦
      • 【石】はあくまでも範囲。
  • INVESTの『T』：テスト可能である事
    • 完了や受け入れが可能である事
  • テストって言葉が微妙すぎ
  • 実例による仕様
    • MF's Bliki
    • 年次有給休暇の例
      • 表にすると分かり易い！
      • テストケースを書くのでなくて、実例を書く

    • 実例が思い浮かぶこと。
      • ストーリーカードの裏側にメモる。
      • 書きすぎて契約みたいになると困る。
  • 『受け入れ可能なのに書きすぎない、ってなんだよ！
    • 対応策
      • 1.チームで一緒に作る/Wikiでチーム萌え
      • 2.実例（例えば･･･）から開始
    • テストは段階的に整理していく
      • 実例：テストになる
      • テスト：検証が要求される
      • 実例：検証を創発する
  • テストツールの記法
    • 表形式
    • テキスト形式
      • exactor, texttest
    • gherkin(gwt)形式
      • cucumberなど
  • GWTの日本語化
    • Given
    • When
    • Then
  • 晴れの日と雨の日のシナリオ
    • 晴れの日（正常系）を中心に
    • 雨の日（異常系）を追加的に/降水確率はかなり高め！
    • 例）ATM利用の晴れの日
  • チームで一緒に実例を使いながら、ツールの記法を参考に晴れと雨を意識する。

【ワークショップ】ATM利用の雨の日のシナリオを考える。

  • ここまでのまとめ
    • 最初からテストを目指さない
    • 実例を使う（例：10万）
    • チームで一緒に考える
    • 自動化ツールの記法で考える（ここだけは詳細に書いても良いかも）
    • とりあえず晴れの日を考える
  • GWTも三幕構成である
    • 前提(Given)：状況や設定
    • もし(When)：葛藤や行動
    • ならば(Then)：理由や結末
第3部：パターン、リーン、ユーザーストーリー
  • 『物語はありません』問題
  • 物語の無い2つのむずかしさ
    • Complicated（入り組んだ）
      • 全体＝合計（部分）
      • 例：機械の部品
    • Complex（複雑な）
      • 全体≠合計（部分）
      • 例：生命的なもの

例)

  • 【ワークショップ】身近にあるcomplexとcomplicatedなものについてグループで話し合ってください。※これ自体が難しいワークショップですが
  • complecatedの対応指針
    • 『わからない』と認識している
    • 把握→分析→対応
    • 因果関係を探せば見つかる
    • 意思決定に時間が掛かる
  • complexの対応指針
    • 何が分からないかわからない
    • 探索→把握→対応
    • 環境を整えて実験を繰り返す
    • 相互交流とコミュニケーション
    • パターンを創発
    • 探しても見つからない

意志決定はじっくりコンセンサスを得ながら、あらゆる選択肢を十分に検討するが、実行は素早く行う（根回し）
  • 書籍参考：パターン、Wiki、XP

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

    • 都市はツリーではない
      • インドの村の分析を1つにまとめたダイアグラム
      • 都市はcomplex！なのに・・
    • 都市はセミラティス
    • ストーリーはツリーではない！
      • 簡単なのはいいけど...
  • アレグザンダーの6つの原則
    • 1.有機的秩序の原則
    • 2.参加の原則
    • 3.漸進的成長の原則
    • 4.パターンの原則
    • 5.診断の原則
    • 6.調整の原則
  • 17章：episodes
    • 製品始動計画パターン
    • 市場のおさらいパターン
    • 暗黙の要求事項パターン(ユーザーストーリー)
    • 作業待ち行列パターン(backlog)

プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集

プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集

  • （難しい）ユーザーストーリーはパターンである。
  • パターンであればパターンのように生成できるはず。
  • パターンの構造
    • 文脈は問題を持つ
    • 文脈は制約を決定する
    • ソリューションは問題を解決する
    • ソリューションは制約を解消する
  • パターンのように生成する
    • 1.うまくいっている事例から(ソリューション起点)
    • 2.うまくいっていない事例から(問題起点)
    • 3.理論的な側面から(文脈・制約起点)
  • 問題と制約の違い
    • 切るなら『問題』
    • 残すなら『制約』
    • ※建物を立てるのだが、木が邪魔している場合。
  • 【ワークショップ】在宅勤務を導入したい
    • 文脈/問題/制約から、3枚1組の組み合わせを幾つか作ってみてください。


  • リーンの概念
    • 自働化 - 品質の作り込み
    • JIT- 無駄、ムラ、ムリの排除
      • PBI, PO,スプリント
      • プルベース・作業の平準化
  • complicatedなら分割出来る
    • 5つのなぜで発掘（トップダウン）
      • (↓)ゴール
      • (↓)テーマ
      • (↓)ユーザーストーリー
      • (↓)ユーザーストーリー（分割後）
  • ストーリータイプで分割

  • 『やわらかい』パターン
    • コミュニケーション・実験・創発
    • UI,コミュニケーション

  • 使い方を間違えてはいけない

自動車絶望工場 (講談社文庫)

自動車絶望工場 (講談社文庫)

  • 物語がないなら2つのむずかしさがある
    • ストーリーの源流はパターンだ
      • パターンの構造を参考にして...
    • アジャイルはリーンでもある
  • 今日のまとめ：
    • ビギンズナイト・スクラムガイド
    • 石・三幕構成・続きは質問
    • 条件はみんなで実例とツールを
    • ２つのむずかしさ・パターン・リーン
  • ふりかえり：
    • 今日のWSを受けてみて、現場に戻ってやってみたいことを三幕構成で書いてみてください。
  • ふりかえり：チーム（KPT）


…というわけで計2時間のワークショップ終了。初心者向けと銘打っていましたが、ところがどっこい奥深く、世界が広がる要素が散りばめられた非常に有意義なワークショップでした。新しい要素、フレーズ、参考書籍等の存在を知る事が出来たので、今後はその辺りの情報にもリーチしていって、見識を広めて行きたいと思います。

DevLOVE道場で行っているワークショップの成果物に関しても再度これらの視点で見直しを掛けて見ても良いかも、と思いました。

アナログツールで現場が変わる、チームが分かる [15:40-16:40]


あなたの現場では、タスクボード、カンバンなどのアナログツールをどのように活用していますか？なにか悩みはありませんか？
このセッションでは、タスクボード、スクラムボード、カンバンなどのアナログツールを上手に活用して、
プロジェクトの透明性や、コミュニケーションの向上、問題の発見などに繋げる方法を学びます。

ここからはC会場に移動。まずは多くのタスクボード・カンバンを見てこられた天野さんのワークショップから。

  • 自己紹介
    • 天野勝/@amapyon
    • コンサルティングをしています
    • ファシリテーションとか好き
    • 自分は何もしない。今日の件についても最終的には『勝手にやって帰ってください』の体で(笑)
    • Kent BeckからTDDを直接教わっています（参加者からは『おお〜』とどよめきが...）
  • 訳書・著書多数。
  • コミュニティにも多数関わっておられる。
  • 実は･･･I love XPです♪(と、ここでTシャツのロゴ『I Love XP♪』をおもむろに見せる天野さん(笑))
  • 会社紹介：
    • 永和システムマネジメント
    • ESM Hiring Rubyists!Rubyな人を募集しています
  • はじめに
    • 大前提
      • 仕事はチームで行われる
      • 組織やプロジェクトはチームで構成される
      • ※『チームでする仕事』が大前提

  • TFの最小セットの構成
    • 実践
      • 週計画会
      • 朝会
      • ふりかえり会
      • タスクボード
    • 原則
    • スクラムっぽい用語に置き換え可能
  • タスクボードとは
    • 基本レイアウトはtodo/Doing/Doneの3レーン
    • タスクを、作業状況に応じたレーンに貼る
    • ※チーム作業の見える化ツール
  • 見える化とは
    • 異常を見えるようにし、行動を誘発する仕組み、及び活動のこと
      • メンバー間で共有する
      • 観たくなくても目に飛び込んでくる
        • 五感に訴えかける
      • 自発的な行動を促す
        • アイデアを出す、相互に確認しあう

    • ※異常が見える事で行動につながる
    • ※世の中のツールはちゃんと理解しないと見えなかったりする。
  • 見える化によるカイゼンの促進
    • ↓可視化で現場が見える
    • ↓チームで問題に気付く
    • ↓チームで改善策を練る
    • ↓チームで改善策を実施する
    • ※現場の人の知恵と工夫を最大限に活かす（衆知を集める）
  • 例）朝会との連動（todo欄の追加）
  • 例）見積もりと実績の差異の確認（Done欄の工夫）

  • タスクボードの応用形
    • done欄を狭くして同時着手タスク数を制限する
    • バグ数を制限した例（バグレゴ）
    • 週の時間を制限した例
    • 作業手順との連動
    • バリューストリームマッピングによるムダ分析
  • この後は演習。皆さんが主役です。

…という感じで天野さんによる講演はここでお仕舞い。この後はワークショップを通じて即席作成チーム・及び参加者全員でディスカッションを行いました。


内容としては、予め用意されていたタスクボードやカンバンなどのとある一面を切り取った状況について、各人で気になったところ、改善すべき所を洗い出していくというもの。付箋を使って指摘・まとめ等を行っていくのですが、ものによってはポイントが被っていたり、または人によって全く別の視点で指摘がなされたりと、チームならではの新しい発見が幾つも出て来ました。

また、ディスカッションを行っていく上で見えてくるもの、提示された状況を見つめていることで見えてくる状況というものもバンバン出て来ます。『この人頑張り過ぎじゃなかろうか…』『こういう状況にあるって事は○○がおかしいのではないか？』等々。

逆に、『こういう点は見づらい、分かりづらいから△△すべきでは』という点も各所から出てくることでツール自体の改善・改良についてもチームで話し合う事が出来、改めてディスカッションの重要さ、多様な意見を出す事を許容する事で新しい発見が出来るのだなぁ〜と言うことを実感。

こういうのって大概が上からor一人から提示されてそれに従いがちな部分は有ると思うので、アナログ・デジタルツールどちらにしても『使い勝手』『ツールの状況から見えてくるもの』についてはチームで話し合う場を持ってみるのはアリなのかな〜と思いました。

スクラムバトルロワイヤル in 西早稲田 〜スクラムの悟りを開く一時間〜 [16:40-17:40]


君は生き残り、免許を受けることが出来るか！？
死ぬも地獄、生き残るも地獄
あなたは本当にスクラムを実践していると云えますか？
これは、真に実力を持つスクラム実践者への登竜門です。
スクラムで競い、スクラムで共に高め合う場。
待ち受ける幾多の試練により貴方の実力を極限まで高めます。
免許皆伝への道は平易ではありませんが、我々は門戸を大きく開いております。
我こそはと思う実力者は、ぜひ門を叩いて下さい。
※一部表現に誇張があります。ご注意ください。

今回のScrum Gathering Tokyo 2011:Day 2に於いて、『一番興味をそそられた』＆『一番内容が読めない』セッションだったのがこの牛尾さん＆前川さんの『スクラムバトルロワイヤル』。

上の概要文見るだけでも『何じゃこりゃ』感は満載ですが(笑)、このお二方によるセッションとあっては参加しない訳には行きません。私自身、スクラムやアジャイルは実戦経験が無く、力量には多いに不安があったのですが(『超実践的道場』を謳うアジャイルサムライDevLOVE道場に参加し、雰囲気だけは何とな〜く感じ取っている程度)、牛尾さんの

という上記のツイートを見て、思い切って参加を決意。

会場は前述の天野さんセッションと同じでしたので、そのまま部屋で待機。

すると会場内にスタッフと思しき方々が続々と集結。


…あれ？どこかで見たメイドさんが。しかも完全フル装備。

そして参加者の誰もが頭に『？』を浮かべたであろう、この御方。SP？ボディーガード？門番？

この時点では、テイストが全く読めてません...(笑)



時間になり、いよいよ『バトルロワイヤル』スタート。なぜか牛尾さんの声色がデーモン小暮閣下調で進められていました(笑)

  • 『このセッションは、Jeff Pattonの裏番組だ』
  • 『世界で一番ハードな内容』
  • 『括りとしては中級SM向けとあったが、あれは嘘だ。恐らく最上級者レベルであろう』

等々、恐怖感を煽るコメントが続き、セッションのルール説明。『覚悟のススメ』と称して、下記写真にあるようなルール(掟？)の説明があったのですが、

その過程でちょっとした小芝居・茶番劇が繰り広げられていたのでここでBlog上再現に挑戦。

  • 牛尾さん『一旦入塾したものの途中退出は許さない』

  • メイドさん、おもむろに入り口のドアに向かって突進、脱出を試みる。それを阻止する謎の黒人男性。
  • メイドさんと謎の黒人男性との取っ組み合いの攻防開始。結構本気(笑) (※ここの写真を撮る事が出来なかったのが本当に残念!! 恐らく個人的には唯一にして最大の後悔すべき点。実写＆アニメ風のイメージで御容赦頂ければ…)


そして小芝居はそこそこに(笑)、本編となるワークショップ開始。予め同じ卓に座ったもの同士でチームを組んで行いました。

  • 自分がスクラムマスタと仮定する
  • チームを次に改善するとしたらどんな課題？
  • チームに対して具体的にどう行動する？
    • 1.上記の課題とカイゼン行動をチームメンバーで共有せよ
    • 2.相手のスクラムマスタに質問を行い、相手のスクラムマスタとしての振る舞いの課題を発見せよ
    • 3.（発見しても、口にするべからず)倒すべきスクラムマスタの課題を見つける
      • 殺しあう相手の欠点が見えてくる。課題が見えてくる
      • 相手に課題を教える事無く、気付きを与えよ！(先行、後攻で実践)

尚、ここで例として『相手の鼻毛が出ていた場合』のやりとりが成されていたのですが、最後に『ボーボー!!』とか言ってしまってました。あまり参考例になってないという...(笑)


個人個人が状況を想像し、またはチームでの実際の状況をふりかえり、問題点(とその解決策)を思い思いに出していきます。

そしてバトル開始。私の相手はあのアジャイルサムライ読書会渋谷道場道場主でもあるHIROCASTER(TwitterID:@HIROCAST)さんでした。本来ならば先攻後攻・攻守交代だったのですが、やはり力量の差は歴然としており(笑)気付いたら攻められっぱなしで時間が過ぎてしまっていました…(^_^;)

『相手に課題を直接口にすることなく』『相手に気付きを与える』…これはまさにスクラムマスターの真骨頂。皆さんやはりこの点には苦労されていた模様です。


ワークショップ終了後には、

  • スクラムマスタの行動として結果と学びを共有し、チームでの主席スクラムマスタを選定せよ

というチームワークショップ作業が提示され、各チーム議論を経て選出。

この過程を見て、牛尾さんが

  • 『なんやお前ら、苦行のくせに楽しそうじゃないか』

というというコメントを。

これは想定外だったのでしょうか？それともしてやったりのコメントだったのでしょうか。確かに中々やるような事では無い試みではあったので、『楽しかった』部分があったのは確かですね。


各チーム主席を選出し終わった後には

牛尾さん『主席には更なる地獄を味わってもらう』

と称し、以下の課題を提示。

  • 鉄人に課題とスクラムマスターとしての行動とその理由を説明しスクラムマスタとしてどうあるべきかディスカッションせよ
  • そして串刺しにされてこい！


時間の都合上、選出したうちの2人のみがこの苦行(？)に挑むに留まりましたが、鉄人(＝スクラムマスター)を目の前にしてのガチの質疑応答は手に汗握り、聴き応えのあるものでした。


尚、一発目のやり取りの過程で主席に対し趣旨説明が不十分であったとして不手際さをスクラムマスターから指摘される一幕があり、牛尾さんを(スクラムマスターの手から)守るために庇う謎の黒人男性…という小芝居的一幕も(笑)

更には、HARADA Kiro(TwitterID:@haradakiro)さんから『スクラムマスタの順位を決める事に何の意味がある？』とツッコミを入れられ、牛尾さん自身がメッタ切りにされてしまうというオチ付きでした(笑)



最後は、無事地獄を生き延びた(？)参加者全員に認定証が授与されました。

代表として、今回のワークショップであのRyutaro YOSHIBA(TwitterID:@ryuzee)さんとバトルをやりあったやまこ(TwitterID:@ywindish)さんが認定証授与を受けました。

その際の授与コメントなのですが、

貴殿はスクラムバトルロワイヤルの苦行に耐えぬき、スクラムのスタートラインに立てた事をここに証明します。
(中略)
素苦羅鵡(スクラム)塾  塾長　　永瀬  美穂

と、この件に関して全く何も聞かされていなかった(らしい)永瀬さんの名前が勝手に利用されているというオチでした。(^_^;)

これが授与された認定証。この凝り様は素晴らしすぎる…(笑)

『家に帰ってご飯を食べて寝るところまでがスクラムだ』という牛尾さんの締めの言葉でセッション終了。

いやぁ、最初はどんな恐ろしい内容なのかと怯えておりましたが、終わってみればスクラムマスターとしての力をつける上での格好の修行の場、鍛錬の機会を得ることが出来、とても満足の行くものでした。普段からこういった点を念頭に置いて物事に取り組むことで、より『スクラムマスター力』の様なものが養われていくのでは、と強烈に実感した次第であります。


本来であればもっとカリキュラムが用意されていたとの事ですが、時間の都合により最初の1つをこなすに留まってしまったらしいです。(牛尾さん談)残る課題がどのようなものであったのかは非常に気になる所ではあります。またいずれ『続編』が実施される日は来るのでしょうか。更なる『地獄』に興味津々です(笑)


(追記)当セッション『バトルロワイヤル』で謎の黒人SP役を担当されていた方は、どうやら牛尾さんの弟さんだったようです。(某情報筋から入手)恐らく参加された方々全員が疑問だったであろう点がこれで1つ、氷解しました(笑)

ラップアップ 18:00-


最後は参加者全員が集まっての締めセッション。

まず冒頭は2011年07月に行われていたScrum Gathering 上海について関係者の方からのコメント。

そして、Qooh0(TwitterID:@Qooh0)さんによるふりかえり。

  • Sgt2011の始まり
    • 最初のミーティング
      • 1/22 18:00 odd-eオフィスにて
    • 大地震も起きていなかった
    • 結構変わった
    • 色々な事が起きた
    • Day 1
        • 参加者：149名
    • Day2
      • 参加者：151名


更には、来場者のみが体験した(＆写真・動画も禁止)、ある作業を今回参加した方同志で実施。ギャザる(Scrum Gathering)イベントならではの、ちょっと照れる、でもとても印象に残るひとときでした。


そしてsgt2011もいよいよフィナーレへ。Kaz Takahashi(TwitterID:@kappa4)さんの

来年のScrum Gathering Tokyo 2012までが今年のsgt2011です！

というコメントで会場拍手喝采。※ちなみにこしばさんの以下のツイートにインスパイアされたものだそうです。^^


最後に、今回の『Scrum Gathering Tokyo 2011』開催スタッフの皆さんが壇上に上がり...

中でも今回のsgt2011のみならず、関連するであろう各種イベントに関して尽力して頂いたYasunobu Kawaguchi(TwitterID:@kawaguti)さんに改めて感謝の意を表す一幕も。

スタッフの皆さん、また川口さんが居なければここまで素晴らしいイベントが開催されず、また数多くの方々が得がたい・貴重なスクラム体験を出来なかった事を考えると感謝してもしたりないくらいです。皆様、本当にありがとうございました！

懇親会

イベント終了後は非公式に行われた『焼肉懇親会』に参加。高田馬場近辺で美味しいお肉、興味深いお話を幾つも聞くことが出来ました。
[:280]

Scrum Gathering Tokyo 2011に関する一連のイベントも無事終了し、個人的にもハードな今週一週間を乗り切ってホッと一息、ようやくついたところです。今回のsgt2011ではまた新たに興味を惹く要素、勉強したくなる分野、疑問に上がってきたポイントなどが明らかになってきました。今後は既存の『やりたい事・こなしたい事』と調整して、それら新しい要素も出来る限り進めて行きたいと思います。


改めましてScrum Gathering Tokyo 2011に於ける主催者・スタッフの皆様。また参加された皆様、ありがとうございました！

Scrum Gathering Tokyo 2011 Day:2 関連URL