『第23回すくすくスクラム 〜Scrum の概要〜』に参加してきた


(写真はワークショップ終了後の会場内)

『DevLOVE HangarFlight - Spring Bomb -』でのアジャイルネタ、要求開発アライアンス5月定例会でのスクラム基礎講習と立て続けにアジャイルスクラム関連のイベント・勉強会に参加していた今日この頃ですが、今日はスクラムど真ん中、『すくすくスクラム』に初参加してきました。

過去開催された『すくすくスクラム』勉強会はこちら。


第23回目となる今回のイベントは本来3月末に開催される予定でしたが震災の影響で3月は開催取り止めとなり、今回の日程で新たに実施との運びになりました。

会場は株式会社ECナビ。最寄り駅となる神泉駅から徒歩で向かったのですが少し迷いました…(^_^;)

下記の写真はフロア入り口。会場となったフロアも結構な広さでしたが、会場に行くまでの道のりの部屋風景が何ともオッシャレ〜な感じで…。こういうところで仕事出来たら楽しそうだな〜と思いますね(笑)バーらしき一角もあったような気が。

会場は予めグループが出来るような席構成となっており(テーブルを併せた島が計7つ)、空いてる席に着席。開始までの時間を自己紹介(&名刺交換)なぞして過ごします。程なくして本編開始。

Scrumの概要

Scrum の概要について講師をして頂く方は海江田さんです。
海江田さんが12 月に行われました Jim Coplien 氏による認定スクラム
マスター研修で得た知識・考えかたをワークを通じて共有したいと思います。

今回のScrum の概要では、初学者の方を対象に行います。
そもそも Scrum って?
スクラムマスターの役割って?
プラクティスの意味って?
などをゲームやディスカッションを通して考えていきます。

基礎の基礎・単語の説明からスクラム実践の大きな流れについてのご説明。

まず冒頭に、『今回が初参加の人〜』と海江田さんが質問を投げ掛けたところ、6〜7割(もっと?)の方が挙手。予め告知していた内容もあり、これだけの割合となった模様。かくいう私も同じ位置付けで参加していたので、同じような境遇の人が多かったのは安心出来ましたね。同じ座席島(グループ)に着席された方々も同じような雰囲気だったと思います。

ちなみに私が座ったグループの島(=Eグループ)には、アジャイルコーチ/スクラムマスターの西村直人(TwitterID:@nawoto)さんも同席されていました。いやぁ〜生スクラムマスターが目の前に!と若干緊張してしまいました。(^-^;)

スクラムの概要については以下にざっくりと。後日スライド資料もUPされるとのことなので、記すのはホントざっくりなポイントのみで。

役割
  • プロダクトオーナー
    • ビジョン・方向性を確立
    • 費用対効果を管理
    • リリース可能かどうか判断するのはこの役割の人
  • 開発チーム
    • 機能横断的なチーム
    • メンバーを長期的に安定
    • もっとも重要なものから着手
    • スプリントを回すのはこの人達(だいたい2〜4週間)
  • スクラムマスター
    • サーバント(召使い的な)リーダーシップをとる役割の人。
    • チームを守り、問題を解消する役目を持つ
    • プロダクトオーナーは問題を隠したがる…
    • 実権は持って無い。
  • (顧客)
    • Scrumでは定義されていない役割。
    • 必ず存在している
流れを確認
  • 全体の流れ
  • 検査ポイントの多さ
  • 普段行っている開発手法との違い
流れ
  • プロダクトオーナーがVisionを決める:キックオフミーティング
    • プロダクトバックログの作成(キックオフ実施前に出来ている事が理想)
    • プロダクトオーナーがチームに熱い言葉を投げ掛け、ビジョンを伝える。ビジョンは最初の数イテレーション分(2〜8週間分)用意。
    • チームは話を聞く。
  • プロダクトバックログ
    • 機能・技術・課題のリスト
    • 優先順位が付いている
    • 誰でも見れる
    • POが優先順位を付ける
    • 価値について記載する
    • チームによって見積もられている
    • 見積もりは相対的に行う
      • 例:プランニングポーカーによる見積もり
  • スプリント計画を立てる
    • 誰のために何が出来たらよいか?の項目(PBI)
  • スプリント計画ミーティング
  • 完了の定義を決めておこう
    • POが出荷可能と認めるレベルについてのチームの合意
    • 知りうる限りの残作業が残っていないこと
    • ※粒度は?
      • インベスト(INVEST)という見積もりの単位がある
      • チーム毎に決めた方がよい
      • POが求める品質による
      • 統一的な定義があるわけではない
      • 「出荷可能」=厳しいイメージ?
      • チームとプロダクトオーナーで決めるべき。

※インベスト(INVEST)の意味について、Ryuzeeさんからコメントを頂きましたので修正。

これって見積もりの単位ではなくて、良いユーザーストーリーの特徴を示す物のはずです。
Independent, Negotiable, Valuable, Estimable, Sized right, Testable
の頭文字ですね。詳しくはすくすくで@kdmsnrさんが話されたユーザーストーリービギンズナイトの資料をご覧になると良いかと思います。

指摘のあった資料はこちら。Ryuzeeさん、ありがとうございます!

  • チェック判定の根拠
  • 完了をサポートするためのツール
    • 「残作業が無い」のは重要!
      • バージョン管理
      • 自動ビルド
      • 自動テスト
      • QA環境
  • PBL(プロダクトバックログ)の見積もり
    • キックオフで作ったモノを見積もる
    • 相対的に見積もる
    • プランニングポーカーとか
    • 大事:各個人の意見の差異をチェックにして話し合う事、合意する事が大事(技術等諸々の差を埋める)
      • 「すくすく」で300円で売っている。
      • 数0〜無限大まである
      • あるPBLの項目のレベルに対して、個々人が思うタスクを出していく(出した裏には個々人の思いがあるはず。その思いを共有し、認識を合わせていく事が大事)
  • スプリント計画2
    • スプリントバックログを作成
    • 仕様確認は必要ならする
  • スプリントバックログ
    • PBLをタスクに分割
    • チームメンバーが作成
    • 理想時間で決める
    • スプリント内で終わらせる
    • 1〜8時間の間で見積もる
  • デイリースクラム
    • 問題がないか確認
    • きのうなにやった
    • 今日なにやる
    • 何か障害になっていることはない?
    • あからさまに話す
    • 隠し事はダメ
    • ※毎朝行う
  • 障害リストのアップデート
    • チームから上がってきた問題点を障害リストに追加
  • 障害リスト
  • (開発!開発!開発!)
  • スプリントレビュー
    • チーム→顧客、オーナー
    • Demo or Die(注:失敗しても別に死ぬ訳ではない)
    • プロセス改善を行う
    • 開発orテスト環境で行うのが普通

  • 振り返り
    • 改善を行う
    • チームとSMが中心、スプリントミーティングのはじめからスプリントレビューまでを振り返る
    • ※スプリントレビューとは、参加しているメンバーが違う
    • 問題があれば障害リストを更新
  • これまでの流れを、イテレーティブに。
  • (各種質疑応答・・・)
  • [Q]:スクラムをするための最適な人数は?
  • [A]:6〜8人。多かった場合はこの人数単位に分ける
  • 各チームにスクラムマスター・プロダクトオーナーが存在
  • 通常のチームとは別にスクラムマスター・プロダクトオーナー達がそれぞれ集まり会議
  • 定期的に会議を行う(行う際、スプリントの期間等は統一した方がよい。3週間など)

ワークショップ×2:紙飛行機を飛ばす/自己組織化を体感するワークショップ

冒頭、お題が出されます。お題は『紙飛行機を出来るだけ多く飛ばすこと』。

『紙飛行機を飛ばすこと』について、まず幾つかルールが設けられます。

  • (用意された紙を)4分の1に切る事
  • 紙飛行機を折る際、1人が折ることが出来るのは1回である(連続して折るの禁止)
  • (用意された)ハサミで必ず紙飛行機の先端を切ること
  • 一定のライン(3m)を越えたもののみカウント

等々、これらの様々なルールが課せられた上で、計3回のイテレーション(計画→実行→レビュー→振り返り)を実施。

こうしたら効率化出来るんじゃないか、早いんじゃないか、良く飛ぶ飛行機が量産できるんじゃないか。

そういった話を交えながら、試すところは試して、良いところはレビューで振り返って次(のイテレーション)にて取り入れる。

実行した結果(=ちゃんと飛んだ/飛ばなかった飛行機、その過程など)を振り返り、次の見積もり(次は何機ちゃんと飛ばせそうか)に反映させていく。


諸々のタスクは数分程度、1回のイテレーションでも5〜6分といった程度。それが計3回なので20分ちょいといったところでしょうか(説明など含めても30分位?)。
なかなか言葉で説明するのは難しいですが、この短時間の中でも『スクラム』的な要素満載で、物事が計画・評価・改善されていく様が体感出来ました。

グループに参加している意識がものすごく高くなり、物事に真摯に取り組んで、課題に立ち向かい、良いものにしていっている…色々な実感を得ることが出来ましたね。最近あんま慣れない作業(紙飛行機折り)したもんだから最後の方は正確に折れなくなってしまってましたが…(笑)

  • アジャイルは開発の核
  • 自己組織化
  • あらゆる予測は不可能
  • 現実に向き合う
  • フィードバックを利用
  • フィードバックにはチェックが必要

といったスクラムの重要要素を踏まえた、中身の濃い、それでいて純粋に楽しめたワークショップでした。

上記ワークショップ終了後にはもうひとつのワークショップ『自己組織化を体感するワークショップ』も行われました。

内容的には(これも説明がなかなか難しいのですが…)、超ざっくり言うと『1人では到底こなしきれないタスクも、みんなで力を合わせればすぐ終わるよ!みんなの力が集まる事が大事』でしょうか。(ん〜この説明も多分違うなぁ…)『自己組織化は「一人の人が細かく命令するよりも、各人が考えて動くほうが良い」』というポイントを、実践を通じて体感するというものでした。(※講師の@Qooh0さん直々にコメントを頂き修正致しました。)

  • 参加者全員で円陣を組む
  • 代表者が円陣の中から2人を選出し、ある法則に基づいてその2人の立ち位置を移動させる
  • そのなかの人がまた別の2人を選び…『Q.最後までつづけたらどれくらいかかると思いますか?』→『A.正直わからん』
  • じゃあみんなで各自動いてみましょう。
  • 皆が一斉に動く→ものの数十秒で完了!


最後には、スクラムを学ぶ上でこれは!という書籍・資料が幾つか紹介されていました。

  • 書籍

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

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

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

闘うプログラマー[新装版]

闘うプログラマー[新装版]

セムラーイズム 全員参加の経営革命 (ソフトバンク文庫)

セムラーイズム 全員参加の経営革命 (ソフトバンク文庫)

これらの中でも、どれから着手すれば良いですか?という問いがあったのですが、答えとしては『上記に挙げてないPDF資料』というものに。どれだろう?有名どころだと以下のやつなのかな?ここについては憶測であり、情報が不確かなので、もしご存知の方がいたら教えてください。(※講師の@Qooh0さんにこの資料である、とコメント頂きました。)

また、併せて西村直人(TwitterID:@nawoto)さんの方から『スクラム道 バースト』についての告知も。『すくすくスクラム』同様、震災の影響で開催が延期されていたものが、日程調整により開催の運びとなりました。(開催日:2011/06/24(金))

こちらのイベントも非常に楽しみです。

ここ最近の間で『スクラム』については触りをちょっと体験した、という程度でしたが、それだけの踏み込み方だけでも大いに刺激となり、学びたい部分・興味関心を引く部分も数多く出て来ました。『スクラムマスター』という資格自体にも興味があるところですが、まずは書籍などで知識を蓄え、こういった実戦形式の空気が感じられる場に少しでも足を運んで行きたいところですね。


…という訳で追記的に、今回のイベントを踏まえて個人的に気になった点を。『スクラム』力をUPさせるためには、以下のような感じで方法・手段があると思うんですが、

  • 1.書籍・WEB等で情報入手、座学で教養経験値UP
  • 2.社外の勉強会・イベントでスクラムの実践空気に触れて実践経験値UP
  • 3.(???)
  • 4.職場でスクラムの流儀を(部分的に or 全体的に)取り入れる
  • 5.有料のスクラム講習を受ける

2.のようなイベントもそう数多くある訳ではないし、規模・頻度から言っても興味のある人が全て参加出来る訳ではない。
また、4.のように今居る現場でスクラム手法を取り入れて改善していく、という場合も、現場の環境次第な部分(現場の理解など)に大きく左右される。

となると、3番の部分、個人レベルで出来る事をやる・自主トレのようなもの…敷いて言えば、『1人スクラム』的なイメージ。そういう方法論というか実践方法って何かあったりするんでしょうか?今現在は[2→いっきに4もしくは5]のステップが一般的?

スクラムを学ぶにあたっては個人的には上記の内容がふと疑問に浮かびました。機会があればスクラムマスターな方々にご意見をお伺いしてみようと思います。