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

勉強会 Scrum Agile


(写真：参加お土産で頂いた『塹壕とXP』の書籍版と参加証として利用したカード。)

2011年1月、野中郁次郎氏とジェフサザーランド氏の歴史的な邂逅を実現した「イノベーションスプリント2011」は
エグゼクティブ、マネージャ、デベロッパに大きな反響を呼びました。

あれから10ヶ月ーー日本のスクラム実践のパイオニアが参集し、いままさに話を聞くべきと考える２人の人気講師を
東京に呼び寄せ、渾身のコンテンツを準備しました。

「最強講演 x 大企業事例 x 懇親会」-- 最強カードで皆様をお待ちしております。

世界各地で実施されているScrumのイベント『Scrum Gathering』。その待望の日本版イベントがこの日(と22日)に開催される事となり、参加してきました!!


関連するイベントをざっくり調べてみても、これだけの地域(国)で開催されているようです。


そして東京。国内の様々な方々によるイベント開催前の告知エントリも多数アップされておりました。


公式サイトによる関連サイトはこちら。座談会形式で事前に記事が発表されており、盛り上がりに華を添えておりますね。


なお、2日間あるうちの初日(Day1)に関しては有料(￥20,000/通常申込)となっておりました。当初は迷ったのですが、これだけの充実した内容の講演を聞けることもそうそう無いだろうと思い、思い切って自腹で申込。


開催場所は野村コンファレンスプラザ日本橋。写真は対面にそびえ立つ『日本橋三井タワー』。

(今回のイベントは『ビル内における写真・動画撮影は禁止』というアナウンスがあったため、関連する写真UPはございません。今回は上記の"外写真"と、帰ってから撮ったグッズ等の写真数点のみで。会場内は設備が非常に充実しており、とても綺麗でした。)


早速以下メモ。今回はセッション毎にTogetterのまとめも成されておりますので、併せてそちらの方も御覧頂けるとイベントの内容・雰囲気を感じ取って頂けるかと思います。

今回は英語ヒアリング(by日本語同時通訳)のセッションも幾つかあり、内容的には不確かな部分もあるかも知れません。その際には御指摘など頂けると助かります。また、内容の削除・変更等指摘もありましたらこちらも宜しくお願い致します。

オープニング[日本語] 10:00 - 10:30

  • 司会：高橋一貴さん
  • スクラムに関する簡単な説明
    • 1990年代半ばにジェフ・サザーランド、ケン・シュエイバー氏によって考案
    • 思想のルーツに野中郁次郎氏、竹内弘高氏の日本企業に関する論文。
    • スクラムガイド
  • スクラムに対する考え方
    • 検査
    • 適応
    • 透明性
    • 自己組織化
    • クロスファンクショナルチーム
    • ※一枚絵をスムーズに回す考え方。
  • Scrum Gathering Tokyoの参加者
    • Day1:180名
    • Day2:230名
  • タイムスケジュールの紹介
  • 『Scrum to Go!』について
    • スクラムに関する悩みを相談。
    • ロビーにあるホワイトボードに先生の空き時間が記載されているので時間予約を。
    • 予約できる時間は15〜30分。延長戦不可。
    • 先生はエプロンをつけています。
  • スポンサーとして支えてくださった方々のご紹介。
  • 後押しして頂いた方々のご紹介。
  • 実行委員の方々のご紹介（8名）
  • コンテンツ委員のご紹介（計13名）
  • 今日一日がスクラムへの取り組みへのきっかけ、あるいはさらに良い実践のヒントになれば。
  • 『知っている』から『行っている』へ

キーノートセッション: 「Change 〜 組織の特性に合わせた、アジャイル導入の勘所」[日本語][英語] 10:30 - 12:00

誰もが変化の必要性を感じています。しかし「変えられたい」と望む人はいません。
ありったけの熱意でアジャイルを布教しても、思わぬ抵抗にあうことがあります。
本講演では、組織の特性にあわせ、メリットを確認しながら、スムーズにアジャイル導入を行うための手法や勘所を、
世界中で引っ張りだこの凄腕アジャイルコーチがこっそりお教えします。
  • おはよう。げんきですか？(日本語)
  • 目的：
    • 組織の変化を引き起こすために何が皆さん出来るか。
    • 人を変えることは難しい。
  • 最初はウォームアップから。机の上の何かを変えてください。
    • 簡単ですよね？
    • じゃあ、自分以外の他の人を変えてみよう。
    • 今回は難しいんじゃないですか？恥ずかしいと思ったりで...
    • 誰か私を変えているのって嫌ですよね
    • どうしたら上司を説得できるか？
      • 説得受けるのは好きじゃない。
      • 自分から変わってみるのはどうだろうか。
      • 自分自身を変えられない人がどうやって他人を変えられるのか。
    • 例：6歳の男の子の部屋を片付けるには･･･
      • 悪い戦略：
        • 今すぐ部屋を片付けろ！
        • アイスクリーム上げるよ！(←長期間は続かない。)
      • 何をしたかったのか？
        • 部屋をきれいに？
        • 部屋自体がゴールではない。
        • 子供に対して自分の責任を取らせることが大事。
        • 子供に人生の価値を教える事が出来る。
        • お父さんモード→コーチモードへ。
    • 本当にきれいなへやだったらどう思う？
      • 部屋がきれいな状況を想像してもらう
      • ゴール（目的）を作る
      • パスを作る（これ本当に必要？）
      • ペンは必要だ、どこに置く？→引き出しに
      • これは必要？と繰り返す
      • 同じ質問をした後、綺麗に。
        • →そうすると場所が出来た。進捗。
        • 実際繰り返すことでアルゴリズムを覚える。
        • 床を綺麗にすることが出来る。
        • 実際片付けた後、きちんと自信を持てる。
        • 覚えたことを教える事が出来る。自発的に行うようになる。
  • 変化に関してはゴールを付ける。
  • アジャイルソフトウェア開発宣言/スクラムガイド
    • どうしてゴールに行きたいのか。
    • 次の具体的なステップは何なのか。
    • 変更・変化には勇気が必要。
      • 他の人を変えるときもそうでしたね？
    • 常に『抵抗』という要因がある。
      • 多くの人は変化を好まない。
    • まちがった方向で解決しないように気を付ける。
    • なぜ今やるんだ？と抵抗しているのかも
    • 抵抗の原因を知る必要がある。
    • この変化により誰が影響を受けるのかを考える。
    • この変化のプロセスはどこから来たかで変わる。
      • アジャイルになりたい
      • リーンに行きたい
      • 小さな会社で5人しかいない・メインプロセスが無い
    • どのように変化をもたらしたらいいのか？
      • ビッグバンで変えていく
      • 斬新な方法で少しずつ変えていく
      • 1つのチームで試験的に導入してそこから学んで行く
    • 共通の問題。
    • チームが出来ました→改善ミーティングを実施
      • 改善のバックログを作成(色んなアイデアは出てくる)
      • どれだけ実行に移せましたか？→時間が無いのでやってません・・・
      • →他の人を変えようとしているので難しい。
    • ワイルドライフメソッド
      • 現場で燃えそうな人を見つけて火をつけ、ガソリンを注ぐ
      • 小さな火をまとめるように仕向ける『楽しそうにしてるよ』
      • 大きな火へ。
        • 成功例も度々。
    • 抵抗の問題
      • Us と Them
      • 開発者に『アジャイルでやりたいですか』もちろん！→でも上司がやらせてくれないんです
      • 上司『もちろんです！』→でも顧客がやりたくなくてね
      • 顧客『是非！』→でも開発者が(ry
      • ※みんなを一つの場所にまとめて話す、という戦略。
        • とりあえず集まってみようよ。
        • その場にいる人の意図を尋ねる。
    • 正しい質問をする『やりたいですか？どうしたら出来ますか？』
      • スプリントごとにリリースなんて無理です。
      • なぜ？（これは×な聞き方）
      • もしそれが出来るならやりたいですか？（○）
      • そうするには何が出来る必要が･･･？（○）
        • ※成功する可能性が高い。
    • 現状を見える化する。(Peter senge)
      • 新しい解釈： どのレベルの人も参加し、共通の理解を得る
    • システムを皆が理解するには『見える化』が必要（例：とある警察組織のシステムでの『タスクカンバン』
      • 現状を理解し見える化することで現状を把握することが可能。
    • ベロシティも重要なツール。
      • doneになるまでにどれだけ掛かったか。
      • リリースプランに役立てる事も出来る。
      • どこがボトルネックかもわかる。
        • （バーンアップチャートを例にとって
      • これからの予測も立てることが出来る
      • リリースプランを作成するための参考にも出来る。
    • データが無くても簡単な見える化でですマーチを回避できる。
      • デスマーチを回避出来るか？指の本数で確認
        • →これだけで問題があるかどうかがわかる。
      • 数週間後、同じ確認を。
        • 指の数が多くなる。という事は…
    • 見える化の例：
      • バリューストリームマッピング(Ohno Taichi)
      • 現金になるまでのタイムラインを考えよう
      • 必要ないバリューは切り捨てよう
      • 1つのゲームを作るまでの手順を確認
        • ミーティング：開催までに時間が掛かる（待ち時間の無駄）
      • ゲームのバックログが出来た
      • ○○○バリュー ストリーム マップを作成する - Visio - Office.com http://office.microsoft.com/ja-jp/visio-help/HA010113024.aspx
      • 画を見せる事によって、会社の無駄を確認。
        • 最適化するための
        • 箱と箱の間の時間が見えてくる。改革への参考に。
  • 戦略：
    • reversible "experiments"
    • 後戻り出来る実験をする。
    • 実際の例：
      • ペアプロは考えらない、うまく行かないよ。
      • でも、1スプリントだけやってみませんか？試しに
      • やってみた。うまくいった。繰り返した。
        • いつでもやめていいんだ、というのがあるから
  • 戦略：メトリクスを使い、進捗を見える化する。
    • 多くの会社がメトリクスを上手く使えていない。
    • 勤務時間の情報とか
    • 役に立つメトリクスを使おう。
      • 1週間でどれくらいのポイントを消化したか。
    • デリバリータイムという測定が非常に簡単。
      • カード：ボードに日にちを書き入れる。
        • フィーチャーにどれくらい日にちがかかったかログを書き、グラフ化する。
        • プロセス改善にも使える。
        • マネジメントに関して非常に有用なツールとなる。
  • 戦略：
    • たくさんの文書を作成しがちな組織
    • 本当にこんな細かいレベルの文書化が必要？
      • そうです。組織で決まってるので･･･
    • 意味の無いドキュメント（監査の結果）
      • ビールおごるよ！って書いてあっても誰も見てない→必要ないってこと。
    • 本当に必要なドキュメントだけを作る。
  • if all else fails…/全部うまく行かないんです...
    • 会社で変化を起こしたい場合:2フィートの法則
      • 脚を使って新しい環境へ動くことが出来る。
      • アジャイルな会社に移ればいいじゃない。
      • 自分自身は変えられる。
  • ヘンリック氏の個人的な話。
    • 2010年12月　ジレンマを抱えていた…旅行中、楽しいんだけど子供、家族と離れるのはどうも嫌だ。
      • ひらめいた！
        • 出張中、家族で一緒に動き回ればいいんじゃないか。
        • チェンジモデル　ゴールとして適用してみよう。
        • 家族で世界一周旅行をしてみよう・・絶対無理。
          • 時間がない、子供の学校がある、家どうしようか･･たくさん仕事やらないといけない...趣味の問題...
    • ちょっとまてよ、顧客に対しても同じなんじゃないか
      • どうやったら実現出来るだろうか･･･
        • 仕事を減らす
        • 家族の同意を得る
        • a date constraint
        • 出来たら家族で旅行したいか？（はい）
          • 10月に旅行へ行くことに
        • プレゼン資料を用意するなかで、顧客に対しても同じように踏襲すれば良いのでは、と思った。
    • タスクカンバンを作った。ゴールのイメージはgoogle imageで持ってきた。
      • モチベーションを考えてみた。
    • 実際色んな事をやってくなかで難しいのが『仕事を減らす』
      • ターゲット：仕事を減らす
      • モチベーション：仕事を減らす事で家族との時間を増やすことが出来る。
        • インターネットを減らす事も出来る
      • でも現実はそうではない･･･lots of work
        • 皆さんどうですか？（たくさん挙手）じゃあバグがあるって事ですね。
    • 進捗のはかり方、どうやってはかるか？
      • 測定可能なもの
        • Emaiのやりとりにどれくらい時間が掛かったか
        • 顧客とのやりとりにどれ位かかったか
          • 測定で分かったのが1日で相当数時間が掛かっていた
    • 付箋化して、優先順位のフィルタを書けてみた
      • 私にしか出来ない責務は私がやるしかない
      • 旅行プラン、バリュー、･･･
    • そして10月1日までに終わるものはなにか、外部委託するのは何かを洗い出した
        • とっておこう/phase out/delegate or outsource/ end of pause
    • 仕事量を少しずつへらし、10月にはここまで持って行かなければならない
    • どんなプロジェクトにも障害がある
      • 奥さんの腰痛：歩くのも辛い･･･
      • 屋根に水漏れが起きた
      • 家の改修も行わなきゃだったり･･･
    • 10月の数週間前の状態･･･大変な事に（笑）
      • 日付は変えられない。
      • 沢山仕事をしなければならなくなった
      • 旅行中に出来るものも幾つかあった。
  • 最後に
    • 変化はあなたから始まります。
    • 自分が変わらなければならない、そうすると周りが変わって行く
    • 周りが変わって行くように刺激しましょう。
    • 変わるきっかけを与える、理由を提示する必要があるかも。
      • そうすれば早く解決するかも。
    • 具体的なやり方を示してあげよう。
      • チームを作る
      • デイリーミーティングをする
    • 方向に向かっていくことが大事。
    • 後で資料はブログにUPします。ご静聴ありがとうございました。


…と言うことで色々あったようなのですが、現在ヘンリックさんは家族と共に世界一周旅行の真っ最中。
訪日もそのスケジュールのなかの1つで、2週間前は中国に居たそうです。でこの後はタイへ訪れる予定。


最後にまとめ(幾つかのおススメ書籍を紹介)、質疑応答等を実施。

特別講演: 「プロダクトマネジメント情熱教室 〜 スクラムにおける「私たち」と「お客様」の関係を見直そう」[日本語][英語]

今日、スクラムの方法論は広く知られる所になりました。
しかしその一方で、「私たち(us)」と「お客様(them)」の間の溝が、静かに深まっているように感じます。
旧来のソフトウェアプロセスもそうであったように、ソフトウェアを作る「私たち」は私たちに要求をもたらす「お客様」に依存しています。
私たちにとって、なにが価値であるかを理解し、学び取るために、「お客様」の存在は不可欠なものです。
しかし、本来緊密であるはずの「私たち」と「お客様」の溝は、過去30年間埋められることなく、
今まさに悩まれている方もいらっしゃるのではないかと推測します。

この講演では、"本当の価値"の源泉を探索します。それを記述するための手法を学びます。
私たちが開発しているソフトウェアには、開発する側が思ってもみない価値があることを学びます。
「私たち＋お客様」が共同開発者として一丸となる文化と方法論について学びます。

「私たち」と「お客様」は協調し、"本当の価値"を創造する責任があるのです。
  • Us and Them：アメリカではよく使われる言葉
    • 我々のグループ：コミュニティ、共同対
    • Them：また別の〜
      • themと使う場合、『やつら』のせいだ、と若干悪く言う
      • 責任の設定をする場合
      • 何か上手く行かなかった場合、罪をなすりつける必要がある
        • →彼等、やつらが原因である、仕事してないからだ
      • 今異なるプロセスグループについて話してる
      • スクラム、プロダクトオーナー、スクラムマスター
      • 我々：何か問題が起こるとPOのところへ行く
  • 深掘りしていきましょう。
    • 1.I'm a decider （意志決定をするひと）
    • 2.I'm a maker（制作者、コードを書く人、文書作成）
    • 3.I'm a manager（管理者）
と、ここで会場内参加者全員をシャッフルし、上記1〜3の経験毎に一旦集合。
その後、1〜3のメンバーがある程度均等にチームを組めるように席替えを行いました。
  • あることをやってもらいます。
    • 今やったことのように、学ぶ事があるはず。
    • 実際、構築に関する意志決定をする人が少ない。
    • マネージャ、管理者、色々な人が混在。
  • Pstitを手元に以下の作業を実施。
    • 黄色の付箋紙に『自分がやってないけどやりたいこと』を書き出す。
    • アイデアが出た…重なっているものはまとめておく。
    • ピンクの付箋を使い、集まった付箋群にアイデアを凝縮した言葉を書く。
    • 抽出したアイデアの中で、何かやるのであればどれが一番会社・企業にとってメリットがあるか。
      • 1人2つ、『これ』と選んだものに対して投票。
      • 票が集まったものを立ち上がって叫ぶ。
  • 皆さんに伺いたい。
    • 1.ブレインストームを静かに
    • 2.さっきのをもう1回

  • 参加した前回のプロダクトでの失敗した大きな原因は？
    • （ブレインストームの際にはみんなで黙ることが重要。）
    • テーブルで自分のアイデアを読む。
    • まとめる、クラスタ書く
    • 叫ぶ。
    • さっきよりはスムーズに出来たでしょ？
  • ストーリーマップ help us build shared understanding about the future world
    • カードを使って、より大きなストーリーを書いていく。
    • バックログを書いていく
    • 優先順位づけしていく
    • 一番優先順位の高いものを使って
  • 認識を共有することの例：
    • プラグマティックペルソナ
    • ジャーニー　maps describe today's world
      • どこで人々が満足しているのか、していないのかを書き出し共有する
    • ビデオDEMO
      • ピンク（ストーリーのまとめ）
      • 最初のストーリー（緑）
      • どうやればいいのか、詳細（白）

    • ソフトウェアを作る時、自分の人生を交えて説明
      • 赤い付箋＝問題として挙げる。『面白いね。ITとして何か解決出来るかも』
      • 説明する人はITに詳しくない

    • words on cards arent …
      • 画を書いて説明
      • スケッチを描くことで議論がまとまる
      • 文書化をしなくてもきちんとした共通認識が持てる

    • globo.com does'nt stop with words
      • 紙でプロトタイプを作る。
      • 動かしながら何が良いのかを紙を切り貼りしてイメージ作る。
      • ソフトウェアを作ってない。問題点を洗い出しているのだ。

    • 協力が必要
      • 全員が問題を理解し、将来を想像し、ソリューションをどうやれば作れるのか

    • this isnt a client-customer rerationship
      • お互いに協力する立場。
  • フィーチャーの問題：作った機能の70％以上が使われない・ほとんど使われない。
  • it takes a small cross functional team
    • valuable(価値があり)
    • usable(使用可能で)
    • feasible(実現可能なものだ)
  • 3つが重なるとこが大きくなれば、正しいバックログが出来る。
  • 映像デモ：
    • アナログ紙芝居：画面遷移
    • ワークショップ：サングラスショップの映像による比較アプリ（営業ツール）？ With iPad
    • nordstorm
    • 考えてほしい
      • お客さんはチームの事なのか？
      • 誰がオーナーシップを持ってるのか？
      • 誰が要件を決めたのか？
      • 誰がストーリー、受け入れテストを書いたのか？
      • 勝つことが出来たのか？（win the outcome game）
      • チームはスクラムを間違った使い方してなかったか？
    • 現在の状況を考えてください。
      • 皆さんの今の役割分担で問題があった場合に
      • 成功、ゲームで勝つためには何をしなければならないのか
      • it's all just a game
      • これはプロセスではなくゲームだ。
      • process ≠skill
  • games have clrar objectives
  • game-winning strategies


ここのメモは正直、メタメタです…(つДT)(笑) Togetterで御覧になられた方が把握出来ると思われます。

Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み - 組織と現場から - [日本語] 14:50 - 15:35

  • ヤフー株式会社
    • 志立 正嗣 氏(R&D統括本部プラットフォーム開発本部本部長):(TwitterID:@shidachi)
    • 立木 貴洋 氏(R&D統括本部フロントエンド開発1本部開発1部開発1) : 
ヤフーでは約1年前から、アジャイル開発およびスクラムへの取組みを開始しました。
今や社員約3,800人の大企業となったヤフーにおいて、どのようにスクラムへの取組みを始めたのか。
組織としての取組みおよび、実際にスクラムで開発を行なっている現場からの事例をご紹介いたします。
  • ◆導入に至る動機、推進方法
  • 『アジャイルなどの開発手法によって、開発のスピードが上がるのであれば、導入を検討したい』
  • 2010年07月：標準化チームにて、検討開始
  • 従来のフロー(WF型)：承認・判断ポイント多し...
  • 3つのステップを組んで導入を検討
    • 実情検査
    • 導入検討
    • 具体的導入案
    • 2010年9月導入へ、
  • 推進体制
    • コアメンバーは導入の外堀を埋める社内調整役と導入決定後のチームをサポートするコーチ役の2名で分担。
  • アジャイル開発の成功：推進方針
    • 習熟・制度・環境の三位一体推進
    • マインドスキル、ルール、ツール、
  • 推進の3つのステップ
    • 興味
    • 導入
    • 習熟
      • 導入後は手厚く、徐々に自立を促す
      • 自立後も随時サポート
  • ＜興味＞
    • 幅広くセミナー・ワークショップを展開
      • アジャイル開発が大切にする考え方から説明、これから起こる変化を想像してもらう
      • セミナー参加者がより興味を持ったら、個人・部門に訪問、相談から始める
      • 同僚・部下に打診し、話を聞いてもらう
    • 調査協力伺い→導入支援
      • 既に自主的に導入しているチームに調査協力を伺い、改善のワークフローがまわるような協力関係を築く
  • ＜導入＞
    • 詳細をヒアリング・適合性を確認
      • 開発の進行状況、メンバー適正等を総合的に判断
      • 懸念点の事前解消に努め、適さないと判断すれば導入を断る事も
    • 開発中の支援を全面的に約束
      • 事前の不安感を取り除く
      • 推進当初はスクラムマスターとしてチームに直接参加することもあった
    • 任意にいつでも撤回可能
        • 導入後うまくいかなかったり継続が困難と判断される場合、いつでもスクラム採用を撤回出来る条件で始めた
  • ＜習熟＞
    • Step1：ルールや考え方を教え、守ってもらう
      • 全てのミーティングや普段の作業中に顔を出し、ルールややり方、考え方を教える
    • Step2：課題を問いかけ、考えてもらう
      • 課題への質問や課題の存在へ気付いてもらい、解決方法を自ら考えてもらう
    • Step3：自分たちでやってもらう
      • ふりかえりのみ出席とし、チーム状況を大雑把に把握しつつも自分たちで運営してもらう。適宜アドバイスを行う。
  • ＜制度＞
    • 導入期はテスト扱いでスクラムを採用
    • 目標業績評価制度への対応
      • 悩ましい問題ではある･･･。期初ではコミット出来ない。試行錯誤中。プロジェクト成功への貢献度をどうやって測るか？
    • J-SOX,内部統制対応
      • 近日中に整備予定。
    • agileワークフロー（スクラム型）
      • スクラムをベース
      • 品質、セキュリティに関する要求レベルはヤフー標準同等
  • ＜環境＞
    • 各プラクティスを適切に運用できる道具の整備
      • 社内で余っているものを集める
    • 壁にアナログ様式でタスク、進捗を可視化
      • 直観的　ツールの習熟に時間が掛からない
      • 能動的に見に行かなくても状況がわかる（嫌でも見える）
      • 社内情報セキュリティに触れる公開限定情報でないか確認
    • 開発メンバーの物理的な集合
    • これまでの成果・結果
      • プロダクトの大小・性質にとらわれず幅広く導入。
  • 品質
    • 障害件数
      • 重大な障害の発生なし
    • 主観評価
    • ポジティブな反応
    • ネガティブな反応
  • 中断事例
    • 割り込みタスクの優先順位付けが浸透しずらいチーム
    • 多数のプロダクトを抱えるチーム
    • スケジュール及びスコープが完全にfixしており、調整・相談の余地が無いプロジェクト
  • 今後の展望
    • 状況・習熟度に応じたプログラム・支援を全社展開へ。
  • おわりに
    • 開発プロセスは文化の側面がつよい。
    • 全ての開発をスクラムで行う訳ではない。プロジェクト進行手法の選択肢を増やし、適切な選択を行う。
    • 新しい手法を試みる際、空気を読み過ぎない。読ませすぎない。（成果物、目標設定、ルール･･･）
      • アクセルの人
      • ブレーキの人
    • お客様への高い価値提供がゴール。
  • ◆iPad版Yahoo Japanトップページでのスクラムの取り組み
    • 自己紹介
    • iPad版Yahoo Japanトップページを紹介。(動画デモ)
      • PC版/iPad版切り替え
      • PCと同じ使い勝手を実現（タブ切り替え）
      • タイムラインの表示
      • ニュース・映像トピックスなどの情報をフィルタリングして表示
      • 横画面レイアウトの対応
    • 導入の動機、きっかけ
      • コミュニケーションがまだ上手くとれていなかった・・・
      • 新チームで新しいものを開発
      • 隣のスクラムチームの雰囲気がすごくいい
    • スクラム開発でコミュニケーションを円滑にしたい！
      • (布教活動に乗った)
    • アジャイル開発推進チームのコーチ指導のもと、進めて行った
      • 初回講習
      • 各MTGをコーチが回す
    • チーム構成
      • 元デザイナーPO
      • 企画PO
      • 開発チーム5名（team）
  • 開発中の課題と解決策
    • タスク出し忘れが頻発･･･
    • 半年やった：完全になくすことは難しいんじゃないか
    • タスク作成チェックリストを作成し、計画作成時に確認した
      • エラー処理は必要か？などなど
    • タスクをとったけど着手出来ない。
    • また、タスクは完了したが、ストーリーが完了できなかった。
    • タスクの優先順位（横）・：ストーリーの優先順位（縦）で並べた
      • ストーリーの列
      • タスクの列
      • 完了の定義：レビューが済むこと。
        • スプリントの最後にレビューが頻発。
        • →どうやって解決しようか。
        • →タスクボードをカレンダー風に並べてみた。
          • ※計画ミーティングで作成
    • 実践して思ったこと
      • コミュニケーション
        • スクラム開発してミーティングが多くなった。そしてコミュニケーションも良くなった。
        • 議論が活発になった
    • 見える化の大事さ
      • 今プロジェクトで何が起きているか
      • どんなバグがあるかをを付箋紙に貼り出している
    • 問題ー改善策の定期ー実践ー確認のプロセスが大事。
    • ベロシティの表
      • 当初10〜進めて行くうちに80
      • 新規チームで新規開発なので
  • 今後
    • ツール：タスクボード、git、レビューボードを使用
    • 過去のデータを振り返る時に紙だと不便、デジタルデータを使えるようになりたい
      • ベロシティを挙げる為に個々人のスキルUPが必要、ペアプロやTDDなどに取り組んでみたいかも
        • チーム全員で検討して対応。

国内における最新スクラム事例集 [日本語] 15:40 - 16:55

さまざまな業種、企業規模、立場の方から、スクラムへの取り組みを語っていただきます。
あなたの現場にも適用できるヒントをお持ち帰りいただけることでしょう。
梶浦 毅一 氏：『Scrum before After』
  • スクラムを導入してみて
    • 自己組織化
    • 顧客との距離をちぢめる
    • 動くものを早く届ける
    • 絶えずコミュニケーションを取る
    • 素早いフィードバックを得る
    • 改善（PDCA）
    • 品質の作りこみ
  • 会社紹介
  • 自己紹介
  • ＜Before＞
    • 創成期
      • 少人数：ゴール・目的の共有が自然となされ、常にコミュニケーションが取れていた
    • 小型案件：1〜2名で1〜2か月以内の仕事であればこなせて当たり前。→スコープが明確だった
    • 一緒に作る：お客様にインターネットやモバイルで何が出来るか一緒に真剣に考えていた。
      • →積極的な顧客関与。
    • 混迷期
      • 人数の増加：1年辺り５〜１０名社員増加、暗黙知も増加
      • 案件規模拡大：要件定義不足、使用変更→遠くの的を正確に射抜くのは難しい
      • 環境の変化
  • 対策
    • 顧客志向：顧客志向をスローガンに。もっとお客様のそばへ
    • iSMS
    • PMBOK
    • ITIL
  • アジャイルソフトウェア開発再考
    • 2001年以来0年ぶりに再度勉強。(海外では主流)
    • 協働促進による自己組織化と自立化
    • 技術論より組織論
      • 独学できない事を会社は教育機会、学習機会として提供すべき。
    • 障壁はなかったのか？
      • 顧客に恵まれていた
        • 『やりたいんです』→『うん、やってみれば？』と即決。
      • 社員に恵まれていた
  • どのように導入したか
  • ＜After＞
  • コミュニケーション
    • 会話の量、場が増えた。
    • 全員があらゆる事柄を関心事に。
    • 伝播
      • 情報の共有、変更コストを低減するアナログルーツ
      • タスクボード：加速度的に導入
      • 素早いフィードバック：1スプリント1週間としてショーケースと振り返り。
    • 品質の作りこみ
      • ツール導入と自動化の促進
        • バージョン管理/TDD/ペアプロ/CI/Doneの定義/テスト自動化
  • 導入してみて…7つの変化は確実に起こっている。
鬼頭 雅英 氏
  • 今はそれよりもデカい版（4人/3D）のゲームを開発中。
    • ビフォーを代表する言葉『FIXって言ったじゃないですか！』
      • ※クリエイターのマインドの問題じゃない。
        • 曖昧な指示
          • 不明確な作業
        • 共有されない情報
          • 改善されない開発環境
    • アフターを代表する言葉
      • 『試しに作って、見てみましょう』
      • なぜこうなった？
      • 実際の様子をヒントに。
  • 計画：作業の明確化
    • リリース計画とpBL
    • スケジュール管理はこの2つだけ。基本、きとうさんが記入。
  • 計画ミーティング：
    • 上記表を印刷、短冊状に切ってそれを元にポイント見積もり、優先度を見直し、ミーティング実施。
  • プランニングポーカー
  • タスクボーど（スプリントバックログ）
  • 日々のゲーム開発
    • 朝会（15分）
    • くじ引きキット（朝会の司会決め）
    • バーンダウンチャート更新、朝会終了
    • ※進捗会はやめました。
  • 2週間後･･･レビュー会
    • 全員でプレイ、全員で意見。
  • ふりかえり
    • に開発環境や運営体制について。

その場で『やる/やらない』を決定→次のスプリントに反映。

  • まとめ

やるべきさぎょうが明確になり全員で共有できる
全員が製品に対して意見を出して改善していける
スプリントごとに反省会をやるので開発体制が改善されていく

  • 試しに作ってみましょう。…というアクションに。

スクラムは万能薬ではない。でも取り組む価値はある。


古賀 Alencar 和幸 氏：『SCRUMで"原石を磨く"』
  • IT・開発センターの暗黒の時代
    • 企画に対してITサービスを展開
      • 思い出したくない位･･･
        • 映画『300』の･･･w
        • 何があっても納期を守れ
        • 全てを要求通りに作れ
        • ダメじゃん！！！！
        • 『Waterfall』→『Humanfall』に…
    • 企画＝顧客
      • IT＝下請け
      • 土下座せい、土下座
    • 顧客満足度調査
      • 全部門に対して
      • IT部門最低・最悪･･･
        • →ITが悪い！
      • 大型2プロジェクト失敗
        • 2つ併せて400人月
    • 関係がどんどん悪くなる
    • 組織変更
      • 開発、企画を一緒に！
      • 組織変更。
    • 大成功!!
      • 8つの課題をクリア
        • コスト○
        • 納期○
        • 満足度◎
        • 失敗PJ◎
        • ：
  • SCRUMの全社展開
    • 現在25チーム
    • オフショアへの全面展開
  • SCRUMの効果
    • 失敗プロジェクトが無くなった
    • 企画の評価が高くなった
      • 全ての評価20％UP
      • 仲良く開発出来てます。
      • 人が育つ
        • 原石を磨く
      • コミュニケーション能力UP
        • 技術力UP
        • モチベーションUP
  • SCRUM全社展開できた理由
    • パイロットプロジェクトは高リスク・大規模
    • SCRUM採用の決定基準が明確
    • ８つの課題をクリア
    • 強力なスポンサー
    • 最高の指導者に恵まれている
  • Special Thanx to Scrum Master!!
    • @nawotoさん、@kakutaniさん等...
  • 日本最大66名のスクラムマスター関連有資格者を有しています。
小芝 敏明 氏：『フルスライダーではじめる正攻法スクラム推進活動』
  • 自己紹介
  • コンテキスト
    • Voyage Group 人を軸とした事業開発会社
    • クルー数：約280人
    • 約80人がエンジニア
    • 社内標準の縛りは少ない
    • 裁量の幅が広い
    • 社内バーAJITO
      • 社内イベント多数
  • アジャイル戦略室　室長を担当。
    • 今年の4月から。
    • CSMに同僚と2名で参加。
      • 『これ、俺等出来んじゃね？』
      • 自分たちのチームメイトと出来ればいいな〜
      • きっちり成果を上げることが出来るんじゃないか。
      • やることと遣らないことを明確にした。
    • 1.体制
      • 高く、広く
        • CSM持ちエンジニア
        • デザイナーリーダー
        • グループ会社取締役
        • 最高技術責任者
    • 2.手段
      • 狭く、深く導入。
        • 成功事例を作りたかった。
        • 失敗してしまったら信じてもらえなくなる。
        • ※社内標準などはこの時点ではまったく意識していなかった。
        • Buzzword
          • あえて使った。『最速最高のプロダクトリリースサイクル』
          • すごい盛りすぎではあった･･･ただイニシャルで切り込んで行くには悪くは無い。
    • 3.相手
      • 社内のheroes
        • 事業の責任者
        • プロデューサー等
      • 公式活動として展開。
        • 『アジャイル戦略室の･･･』とアピール度が高まる。
      • 設立趣意書（A4一枚半）
        • 現状認識
        • 狙い
        • 何をやるか
        • どうやるか
        • (1).組織結成提案＝月曜日
        • (2).役員会会議＝水曜日
      • まるっと、概ね一式導入。
      • 週に一遍参加して様子を確認。
    • どうなっったか
      • 無事リリース。
      • 新規フィーチャー等の追加なども迅速に。
  • 幾つか得られたこと、感じたこと
    • 今、判明してよかったですね（こしば）
    • デモベースで話ながら認識会わせができった
    • 期間半ばでまにあわないさそうな事が分かった
  • (最速最高と謳った)スピードは？
    • そんなに上がって無い。
    • でも『着実に出来上がっていきますね』
      • 確実性は高まっている。
  • Simple Tools + Better Process = Awesome Product
  • 仲間と事を成す。
宇畑 洋介 氏・高木 丈智 氏『はじめてのSCRUM これから大切にしていきたいこと』
  • 自己紹介
  • 事例の紹介
    • Rubyビジネスモデル　研究実証事業
    • Rubyの特徴を活かし、ユーザーニーズを素早く的確に捉え、ユーザー満足度を高めるための開発手法を明らかにする
    • ソフトウェア開発における課題
    • 詳しくは関連の成果報告書を御覧下さい。
  • 実践した内容
    • ユーザーストーリーマッピング
      • ユーザーストーリーを如何に効果的に開発チームに見せるか
      • 利用者のロール（縦）
      • 業務のフロー（横）
      • 縦軸が優先順位。
      • ※これを行う事で、利用者が困っている、希望している事･･･利用者を意識する事が出来る。
    • 工場見学
      • 計2回の見学を実施。
      • 利用者と実際にディスカッションし、気付きを得る。
      • 開発チームからの提案も出た。
    • Scrumコーチ
      • 懸田さん(@kkd)に来てもらった。
      • agile & Scrum講座
      • システム思考visual thinking
  • Scrumやってどうだったか
    • ユーザとして
    • 期待値と現実のギャップ
      • リリースバーンダウン棒グラフ
        • センター線より下に出ている＝チームのベロシティが高い
        • センター線より上に出ている＝逆。
      • システムが利用されるときになってどれくらいの期間、使われるのか・誰がメンテナンスするのか…といったもう一回り大きい部分で考える必要があるのでは。
  • 大切にしたいこと
    • 反復漸進的な成長
      • プロダクトの成長/チーム（人）の成長
      • ビジネス価値の提供/持続可能なペース
    • 開発者に問われる責任と姿勢
      • 自律的な活動
        • 変化への機敏な対応
        • 継続的な価値の提供
        • 価値の探求
        • 技術の卓越
      • passion-izmの探求
        • 情熱を持ち続ける事が大事。
      • これからも思いを共有して継続して成長させる姿を目指す。

【Day1参加者特典】講師、国内実践者へのQAセッション [日本語] 17:00 - 17:30

ご参加の皆様の疑問や質問に当日の登壇者が自らお答えします。大変豪華でインタラクティブなセッションです。

今回登壇された方々が一同に介し、参加者と質疑応答を行うセッション。時間的には20分程度の尺になってしまいましたが、皆さん思い思いの質問をされておりました。メモは取り切れていなかったのですが、記憶しているものとしては『コーチは居た方が良いか？』→『居なくても何とかなるだろうが、より効果を期待するのであれば居た方が良い。』といったものがありました。

懇親会 18:00 - 20:00

イベント本編は6Fで実施されていたのですが、懇親会は階・場所を変えて5Fで実施。

個人的にはこの後用事があり(といっても勉強会なのですが…その辺は後日別エントリにて)、開始10分か15分そこらで懇親会会場をお暇し、いそいそとタクシー＆電車を乗り継ぎ次の(勉強会)会場へと足を運んでいたのでした…(笑)

本編自体は非常に内容が濃く、満足の行くものだったのですが全編を通して思ったことは『やはり英語は十分に話せなくとも、ヒアリング・リーディングがある程度出来ていた方が良いな〜』という点でした。先頭2つのセッションが海外から講師を招いての日本語同時通訳アリと言うことで多少安心して臨む→片方の耳で英語、もう片方の耳で日本語通訳音声を聞きながら内容を理解し、メモを取る…というのが非常に体力を消耗しました。(^_^;) より内容理解を促すためには、『英語学習・英語への慣れ』というステップが必要なのでは、と痛感した一日でもありました。


(参加お土産として頂いた『塹壕』書籍版とロゴ入りカバン。カバンの方はノートPCがゆったり入る大きさです。)