読者です 読者をやめる 読者になる 読者になる

Scrum Boot Camp 東京に参加しました

6月16日 Scrum Boot Camp 東京(東京都)

アジャイルサムライ横浜道場で紹介されていて、参加しようと思っていたのですが、募集開始日のことを忘れていて、気付いた時には埋まっててしょぼーん。。。
運よくキャンセルが出たのを見つけて滑り込めてよかったです。

今回の会場は日本マイクロソフトさん。品川駅直結で雨でしたが濡れずに行けました。
中も非常に綺麗で、こんな会場を使わせて頂いて感謝です。

なお、当日は他にも2つのイベントが開催されていました。

オープニング

ほぼ出席者が集まったところで、会場の中の人かつ『アジャイルソフトウェアエンジニアリング』監訳者の @tomohn さんによる会場説明等の後、横浜道場でお馴染みの方法で席替え。
横浜道場などでお会いしたことがある方が、ちらほらいらっしゃいました。

アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)

アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)

同テーブルになったのは、@shin_semiya さん、@nonumberless さん、@libaty さん、@pilgrim_reds さん、私の5人。
それぞれバックグラウンドがかなり違うメンバーということから、ごちゃまぜ、色んなものが混ざってるという連想で、チーム名は「チームもんじゃ」となりました。*1

アジャイルとは

@ryuzee さんによるアジャイルな開発に関するセッションとワークショップ。

横浜道場特別編でも即買ってくださいと言われていたこの本、今回も紹介されました。
ごめんなさい、まだ買ってません。いい加減買わなきゃ…

トヨタ生産方式―脱規模の経営をめざして

トヨタ生産方式―脱規模の経営をめざして

ワークショップは、紙飛行機を使ったもので、全部で4スプリント実施しました。
スプリントの内訳は、計画1分、実施4分、振り返り2分です。*2
チームもんじゃは、第2スプリントまで苦戦しましたが、第3スプリントでブレイクスルーがあり、第4スプリントでベロシティがぐっとアップしました。

  • ゴールの共有重要
    • 手を動かす前に話し合う
    • 言葉だけでなく図や絵も使う
  • 役割分担重要
    • ただし、ゴールが共有できた上で
  • 暗黙の制約
    • 本当は制約ではないものを勝手に制約と思いこんでしまう
    • 制約はプロジェクトが進むにつれて制約ではなくなるものもある
    • 暗黙の制約を取り払わなければイノベーションは起こせない
  • タイムボックス
    • 短いので最低限の要求達成を考えないと間に合わない
    • 色々やろうとすると全部未達成に
    • 先の見えないデスマーチ状態よりもはるかに健全
  • 見積もり通りでよい
    • 1と見積もったなら、まずは1をやる

Scrum とは

昼食のあとは、引き続き @ryuzee さんによる Scrum についてのセッションとワークショップ。

ワークショップのお題は「社内飲み会管理システム」。
横浜道場主 @tw_takubon さんによる説明を聞いた上で、このシステムについてプロダクトオーナー視点でプロダクトバックログを作成し、チーム視点でストーリーポイントとスプリントバックログを作成するというもので、各作業時間は20分。
なお、日本マイクロソフトさんのご厚意で、ストーリーポイント作成に使用するプランニングポーカーが提供されました。

  • プロダクトバックログ
    • バックログとして要求を出すのが意外と大変
    • チームの能力が高い場合を想像するとより大変さがわかる
    • 顧客のビジネスをよく知っていないとできない
    • プログラマとしての知識があることが妨げになる場合も
    • 優先度の低いバックログは曖昧になりがちだが、そこに時間をかけず後で見直せばよい
  • ストーリーポイント
    • 基準を2つ設けて相対的に見積もるのは分かりやすい
    • もし基準が違っていたら後で見直す
    • ポイントが大きいものばかりの場合、基準が小さいかバックログの粒度が大きい
    • 自明と思っていたことが違った場合は、ここで判明する
    • 仮に一回でストーリーポイントが一致しても、根拠を話した方がいいかも
  • スプリントバックログ
    • ストーリーポイントから時間への変換が難しい
    • スプリント実施毎に精度が上がっていくはず
    • 正直、ワークショップだけだと見積もりの妥当性はわからなかった
    • 慣れが必要

質疑応答と振り返り

ワークショップの後は質疑応答と全体の振り返り。

  • 周囲を巻き込むアイデア
    • 小さい成功体験
    • 覚悟を決めて推進する
    • チームトレーニングの継続必須
  • 予測と実績の乖離をどう測る?
    • デイリースクラムしていれば遅れていることは分かるはず
  • アナログが良い理由は?
    • スクラムに慣れてないチームがツールの使い方まで覚えるのは負担
      • 慣れていて、かつ、巨大プロジェクトの場合ツールが必要になる可能性も
    • 常に見ることができるというのは意外と重要
    • 記録を残したければ写真を撮って保存
  • ダメなスクラムマスターの場合
    • チームはスクラムマスターをクビにすればいい

その後、プランニングポーカーと『アジャイルソフトウェアエンジニアリング』2冊の争奪戦、後片付けなどをして全日程終了でした。
残念ながら、私はどれも奪取できませんでした…

感想

早起きして参加した甲斐はありました。得たものは大きかったです。
やはり、ワークショップ形式は楽しく、気づきが多いと感じました。

ワークショップ中にスタッフの方から言われましたが、「Scrum は理解するのはそんなに難しくないけど、実践は難しい」という言葉が印象的かつ納得でした。

実践に向けて何が難しいのかをよく考えないといけませんが、少なくとも思ったことはテクニカルスキルの不足だけではないということです。
今回のワークショップの内容は、特別なスキルが必要という訳ではありませんでしたが、それでも各チームの進め方に大きな差がありました。

また、顧客というかプロダクトオーナーの役割が非常に大きいということがよくわかりました。
要求を出す立場の人物に、Scrum を導入することで、こんなに価値を提供できますよというのを提示することが必要と理解しました

今後は、できる範囲のプラクティスの実践及び継続学習をしつつ、社内の人間を巻き込むような動きをしていきます。

会場提供頂いた日本マイクロソフトさん、@tomohn さん、講師の @ryuzee さん及びスタッフのみなさん、参加者のみなさん、ありがとうございました!

*1:他には会場がマイクロソフトさんにも関わらず「一○郎」や「i○S8」とかありました

*2:記憶が曖昧です…