Scrum Boot Camp 東京 ( #scrumbc ) に参加したよ

投稿日:

7/30(土) に開催された Scrum Boot Camp 東京に参加してきました。
主催のスクラム道のみなさま、どうもありがとうございました。朝から夕方まで丸一日のイベント、しかもあの内容で無償とか、ホント素晴らしいと思いました。

また、素敵な会場を提供いただきました日本マイクロソフト株式会社様、どうもありがとうございました。
(「IE爆発しろ!」とか毎日言っててホントすいません。。。)

Table of contents

  1. Scrum Boot Camp に参加しようと思ったきっかけ
  2. 当日の Boot Camp の内容振り返り
  3. 自分が気づいたこと、実際に持ち帰ったもの
  4. まとめ、その他思ったことなど

Scrum Boot Camp に参加しようと思ったきっかけ

仕事で今開発しているのはスマートフォン向けのゲームアプリなんだけど、開発の当初からアジャイル開発で進めています。プロジェクト開始の時に Henrik Kniberg の「塹壕より スクラム と XP」をみんなで読んで、プロダクトバックログを作り、各イテレーションの計画を立てながら今まで進めてきました。他にも「アジャイルな見積りと計画づくり」を読んだりと、勉強しながら現場で実践を進めていたけど、一方で「一度基礎をちゃんと勉強した方がいいのかな」、と思っていました。
今回はたまたまtwitter見た時にイベント開催のtweetが流れてきたので、これはいいチャンスと思って参加することにしました。独学で実践を積み重ねていくのも悪くはないと思うけど、基礎をちゃんと学んだ方が良いだろうし。


当日の Boot Camp の内容振り返り

以下、座学中に取ったメモを中心に当日の振り返り。
冒頭に流れたのはドラマ スクールウォーズのOP曲。スクラム = ラグビー からのメタファ。会場の雰囲気が少しばかりスベッたように感じたのはきっと気のせい。

  • コースの狙い
  • 概要を学ぶ基本コース
  • Scrumとは → 基本セット
  • 技術プラクティスは抜いているが、共通言語として機能するの
  • 製品に関わる人達の共通言語として機能する(用語に名前つけるの重要)
  • Scrumの歴史 by 川口さん (@kawaguti)
    • 竹内弘高、野中郁次郎が1986年に発表した「The New New Product Development Game」がルーツ
    • 1993年 開発手法として登場
    • 3つの柱
  1. 経験主義 Empirical
    • そのために Scrum では「繰り返す」
  2. 自己組織化
    • チームとしてできることをする
    • 自らを律する
    • Servant Leadership サーヴァントは「執事」
  3. 信頼 Transparency
    • 相手の言うことを怖がらない

信頼の話で川口さんが説明した「タバコ買ってきて!」の例え話がとても興味深かった。(川口さんはタバコ吸わないけど)
例えば僕がチームの誰かに「タバコ買ってきてよ」とお願いした場合、その相手が信頼できなかったとすると本当にタバコ買いに行ったかどうか、後をついていくとか、お釣りをちょろまかしていないかどうかのチェックまでしなくちゃいけない。これでは「タバコが手に入ればいい」という本来の要求に対してかかるコストが高すぎる。チームで一緒に仕事をするわけだから、お互いに信頼があるべき、というお話。


  • タイムボックス 川口さん (@kawaguti)
  • 完了判断 = Potentialy Shipable Increments
    • (訳しにくいね。出荷することができる増分、とか言っちゃうより英語のままの方がしっくりくる)
  • スプリントの期間でどれだけ Potentialy Shipable Increments を出せるか
  • スプリントの期間を3週間にしている事例がある
    • 3 weeks = 1/4 Quarter Year、つまり4回スプリントを回すと四半期が終わる
  •  スプリント3〜4回でベロシティが安定する
  • スプリント中の会議体 by 川口さん (@kawaguti)
  • 前半
    • スプリント計画
      • チームの到達範囲を予測
    • タスク計画
      • 期間内のタスクを計画
  • 後半
    • スプリントレビュー
      • アウトプットを説明 / デモンストレーション
      • 問題が起こる → そういう情報が出てくるのは良いこと (That's A information!)
    • 振り返り
      • 試合後のロッカールーム。ちゃんと反省して次に活かす
  • Daily Scrum
    • 顔を合わせるのが重要。「今日、元気?」
    • 以下3つを聞く
      1. 昨日なにやった?
      2. 今日なにやる?
      3. 困ったことある?

タイムボックスの説明で一点気になったので、「スプリントとイテレーションは何が違うのか?」と質問してみた。
回答は「スプリントは Scrum の用語で、指しているものは(アジャイルな見積もりと計画づくり)に出てくる"イテレーション (Iteration)"と同じ」「Scrum の人でもスプリントのことをイテレーションと呼んでいる人もいる」とのこと。


(ネタバレしてもいいのかな。問題ないなら後日追記)
紙飛行機を飛ばしたりとか。


タスクに集中することがどれだけ重要か、というのを体感するワークショップ。(これもネタバレしても問題なさそうなら後で詳細追記)
2種類の作業をそれぞれ1分間づつ集中して実施した時と、2種類をいったりきたりしながら2分間かけて実施した場合にどれだけパフォーマンスが落ちるか、というもの。
実際の仕事の現場ではマルチタスクで作業していることが多いので、いかにそれが無駄かを身を持って知るにはいい機会でした。
逆に集中しないほうがパフォーマンスが上がるような人も若干いたようですが。普通落ちますよね。


  • 「鶏と豚」
  • 鶏はステークホルダーなんだけど、身を削る訳ではない。
  • 自分の会社とか組織にもいるんじゃないだろうか? 口は出すけど、金は出さない、責任も取らない人
  • 鶏の言うことはとりあえず参考に聞く程度でOK
  • スクラムの登場人物
  1. プロダクトオーナー
    • ビジョンを持つ (vision)
    • 成功に責任を持つ (passion)
    • プロダクトに関するマーケットの知識を持つ (market)
  2. 開発チーム
    • Product backlog の項目を動くソフトウェアとして実現する
    • Cross functional
    • Product backlog に記載された「やること」を Ready → Done にする
    • 最適な人数は 6 ± 3 人 (以前は 7 ± 2人だったのが、最新の Scrum Guide で改訂された、らしい)
      • 3人未満だとチームによるシナジーが生まれにくい
  3. スクラムマスター
    • サーバントリーダーとして振る舞う
    • プロダクトオーナーを支援
    • 開発チームを支援(進捗の妨げを排除する)
    • 組織を支援(Scrumの採用、導入、推進の支援)
  • 兼任について
    • スクラムマスターとプロダクトオーナーの兼任 → ダメ
      • 利害関係があるので
    • プロダクトオーナーとチーム → △
    • スクラムマスターとチーム → △
    • 兼任はしないほうが無難

  • ワークショップ#3 by @ryuzee さん
仮想のシステムを構築するというお題で、チームで実際に手を動かしてプロダクトバックログを作成。
チームでプランニングポーカーをやって、Product backlogに書きだした項目の相対見積もりするところまで実施。

  • プランニングポーカー (その時の)ルール
    • カードを出しあう前に Product backlog の項目名を読み上げる
    • 3種類数字が出たら、一番大きい数字を出した人と一番小さい数字を出した人がそれぞれ「何故そう考えたか」を説明
    • 隣り合う2種類の数値が出た場合は大きい方を採用
  • プランニングポーカーで数値がバラバラなのは、むしろ良い事
    • メンバーがそれぞれ頭の中で思っていることの認識をあわせるいい機会
    • 例えば「3」で全会一致したような場合も「たまたま3で一致しただけ」で、考えていることは全然違ったりする
    • なので数字が揃ったとしても「こういうことだから3なんだよね」という確認をたまにすると良い

  • アーティファクト by @ryuzee さん
  • Done の定義
    • 自分たちのタスクが終わったことを共有するためのもの
    • 出荷可能の条件。要件によってはリストがあったりする
      • ex. Unit test をパスしていること、Release Note が更新されていること
    • Done の定義なくして Scrum はあり得ない
  • Product backlog (機能一覧)
    • 優先順位が付いていること。「優先度」ではなく「順位」
    • 順番は後で変更してもOK
    • Product backlog を自然言語で記述するのは、プロダクトオーナーに理解してもらうため
    • ストーリーを技術レイヤーで分解しない
      • 技術レイヤーで分けてしまうと、リリースできなくなる可能性がある
    • Product backlog の INVEST
      • Independent 互いに独立していること
      • Negotiable 会話のための道具であり、それが絶対であってはダメ
      • Valuable 説明できないもの = ムダ
      • Estimable
      • Sized Right
      • Testable
    • 優先順位のつけ方 → 価値の高い順
      • (確か アジャイルな見積もりと計画づくり の10章あたりに価値の算出方法が書いてあったはず・・・)
  • Burndown chart
    • あと何時間あれば終わるか、をプロット
    • 某E和さんのバーンダウンには色々と情報が書いてあった
      • 横軸の日付部分に「XP祭り」とかw
      • これだw ↓
        burndown-chart

  • 妨害事項リスト
    • 開発用PCが遅いので何とかしてくれ! など
    • あまりにこのリストの項目が多いのはそれはそれで問題

自分が気づいたこと、実際に持ち帰ったもの

Scrum の勉強会なのでワークショップは全てチームで作業だったんですが、「昼ごはんもチームで一緒に食べに行ってください」というのがありました。これは他の勉強会ではあまりやったことがないので、非常によかったです。マイクロソフトさんは品川にあるので、ランチを食べられるお店がたくさんあるのも便利で良いですね。(さりげなく会場提供者をヨイショ)

内容について言うと一番印象に残ったのは紙飛行機のワークショップの後にコーチの誰かが(すいません、誰だったか忘れました)が言っていた
「品質が品質が、と言うけど、何をもって品質が良かったとか悪かったと言っているのか? (今回のワークだと)飛ばさないと品質は全く分からないのだから、飛ばせなかったものについて品質どうのこうの言うのは全く意味がない」
という一言。これは結構グサッと来ましたね。いるよな〜、二言目には必ず「品質が」っていう人。それがプロダクトを受け入れる顧客が求めている品質と本当にイコールなのか。勝手に品質品質と言っているだけで、もしかしたらズレてるんじゃないのか。意識し直さないといけないなと思いました。

アナログで管理する方が(ITの)ツールを使った管理よりも最初はベターだ、というのはとても同意出来る所です。いきなりツールを導入しても実践が大変なので、ストーリーをカードに手書きするとか、チャートを模造紙に描くとかから始めるべきだと感じました。「アナログでできないことはデジタルでもできない」は名言なんじゃないでしょうか。

そして今の開発現場。

僕はスクラムマスター的な立ち位置でありながら、コードも書いている。「しないほうが無難」と言われた「開発チーム」と「スクラムマスター」の兼任になっているのが実情。これをどうにかするのはなかなか難しいかもしれないけど、タスク切り替えがパフォーマンスを落としているのを身を持って体験したので、いつかなんとかしてみようと思います。(誤解して欲しくないですが、コードを書きたくないわけじゃぁないです)

また、「Doneの定義」が非常に難しいなとも痛感。今開発しているプロダクトがゲームなので「プレイヤーとしてXXをプレイして面白いこと」みたいなユーザーストーリーがあって然るべきだと思う。(ユーザーストーリとしては無茶苦茶なんだろうけど)とはいえ一方で「面白い」なんて価値観は人によって異なるんだから、関係者で「ここまでできたら面白いよね?」なんてことを事前に握っておくのも簡単なことではない気もします。

Product backlog を見てみたら、ちゃんと優先順位付けられてないなぁ。。同じ数値のものがあって、これじゃぁ「優先度」になってしまっている。改善出来るタイミングで改善しようと思います。

最後に参加者(ほぼ)全員参加のじゃんけん大会があり、プランニングポーカーを勝ち取りました! 川口さん、ありがとうございます!
Version One 社製 プランニングポーカー


まとめ、その他思ったことなど

一緒にチームを組んでワークショップをやったメンバー、森さん、三浦さん、高木さん、中村さん、どうもありがとうございました。総じて非常に満足度の高いイベントで、それも同じチームのメンバーと色々と意見交換することができたからだと思います。

イベントの最後にみんなで出したKPT (Keep, Problem, Try)
Scrum Boot Camp 東京 ふりかえりのKPT

「家に帰ってからblogに書くまでが勉強会です」とは良く言ったもんで、やっぱり勉強したことの復習って大事ですよね。予習・復習。
今回の Scrum Boot Camp では事前に参加者に送られたメールに

  お時間に余裕のある方は事前準備として以下の無料リソースをご一読頂くことをオススメします。

  Scrum Guide
   http://www.scrum.org/scrumguides/  (中段に日本語版があります)
  塹壕よりScrumとXP
   http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

というのがあったので、慌てて未読だった Scrum Guide にざっと目を通してから参加しましたが、予習した上で参加するのとそうじゃないのとではかなり違いがあると思います。復習もしかり。復習の一つの手段として、 blog に書くってのは有効な方法なんだなぁ、と改めて感じました。


関係者の皆様、参加者の皆様、どうもありがとうございました。
懇親会も行きたかったですが、他に予定があったので残念。。