あしたのチーム Tech Blog

はたらくすべての人に「ワクワク」を届けるべく、日々奮闘するエンジニアの日常をお伝えします。

すくすくスクラム 〜新卒が西部開拓期のようなチームにスクラムを導入してなんとか回したお話〜 R

書いた人: tomo  描いた人: tomo  自炊をサボりがちになった人: tomo


おいす〜スクラムマスターのtomoだよ〜
前回思っていた以上の人に見てもらってたので今回はもっと真面目なお話をしていこうかと思います。

・・・・・・・・・
・・・・・・
・・・
ま、嘘なんですけどね。

はい、ってなわけでタイトルコール!!
『すくすくスクラム 〜新卒が西部開拓期のようなチームにスクラムを導入してなんとか回したお話〜 R』(リターンズあるいはR指定じゃん?)
始まるよー!

f:id:ashita_tsuzuki:20190212142558j:plain

1. 必殺!スクラム三種の神器

・プロダクトボード(ここではアナログとTrelloの話をする)

まーこれがないと始まんないわな、
言わずもがな、チームのメンバーがどのぐらいの見積もりで何をしているのかが一目できるつよつよボードである。
(というかこれをやっていないところはプロジェクトの進捗をどうやって測ってるんだろう?)
基本的な使い方はウチらも例に漏れず・・・

Product Backlog:追加されたタスク。基本的にスクラムマスターが管理をするが、バグや社内業務などのタスクは開発者も追加したりする。
Sprint Backlog:スプリント単位で着手するタスク。スプリントごとに実施するプランニングで決定する。
Doing:名前の通り、デイリースクラムではここにあるタスクについての報告を行う。
Waiting for Review:プルリクエストを作成したタスク、1タスク1プルリクとは限らない。
Done:レビューが通りマージされたタスク

開発業務ならば大体このような形になるのではないかと思ってます。

f:id:ashita_tsuzuki:20190213135607j:plain

スクラムを進める内で最も重要といってもいい要素はデイリースクラムおよび振り返りである。
スクラムとは言ってしまえばPDCAを高速で回す事と同意義であるため定期的な情報共有の場を儲けるこれらの要素は切っても切れない関係にあるというわけなのです。
デイリースクラムではボードにあるタスクを完了させるためにやったことを共有して、問題があるのならばその場で軽い要件定義やタスクの分解を行うことでプロジェクトメンバー全員が十全に稼働する体裁が整うのだ!やったね!!
振り返りでは次のスプリントで着手するタスクを、プロダクトバックログから移動させて見積もりも一緒に行います。

世のスクラムマスターたちはスクラムが上手く回らなくて形骸化してしまっているなんてこともあるのではないでしょうか?
では、そこで私が若輩ながらあなたを謎の頭痛から救うアドバイスをして差し上げよう。それは ”やさしさ” である!(何言ってんだコイツ?)
スクラムと言うのは手段のことであり目的ではない、この一言につきます。その故、無理にスクラム化を推進しようとするとチームがへたります。あなた自身もへたります。
・・・・・・そんなの嫌ですよね?
ここでアジャイルソフトウェア開発宣言を振り返ってみましょう!

f:id:ashita_tsuzuki:20190206141749p:plain
URL:https://agilemanifesto.org/iso/ja/manifesto.html

ほら見てよこれ(私のブラウザフォントじゃないよ)、詰まるところスクラム、リーン開発、XPなどアジャイル開発はこの宣言を実現するための手段に過ぎないのです!私はこの中でも”包括的なドキュメントよりも動くソフトウェアを”と言うのが一番好きです(笑)
Done is better than perfect! たぶん動くと思うから(ry..... あ、頭の中から幻聴が・・・・
元より形式張ったものではなく柔軟に対応することができるのが、スクラムをはじめとするアジャイルソフトウェア開発なのです!!
おそらくスタートアッププロジェクトでスクラムマスターになった同志諸君の中にはスクラムの本、あるいはスクラムの体験談で書かれていたことをそのままプロジェクトに押し込んでしまうと、本を読んだ同志は問題ないだろうが開発者たちは大きな環境の変化に耐えることができなくて、チームを良くする為に導入した数々の制約が最も恐るべき”形骸化”を引き起こすことになりかねない。
なので精一杯の ”やさしさ” を持って小さい単位での革新的革命を長い時間をかけて少しずつやっていこう!

2. 真にできるスクラムマスターとは他力本願ができるヤツのことを言う

私の失敗談の話をしよう。(唐突の自分語り)
スクラムマスターは言ってしまえば”現場の現場による現場のための運営”をする役割なのだが・・・

現場以外のタスクを全て引き受けてしまうと死にます。と言うか死んだ。
スクラムマスターは色々と並走するため忙しくなってしまうのは必然なのですが、現場以外の現場の人になってしまっては本末転倒ですね!クソがっ!

そうだよ!ベンチャー企業なんかは仕事を探そうと思えばいくらでも見つかるYO⭐️。自由な働き方の裏側にはこんなものが隠れていたんだね!(悟り)
だからと言って管轄外などのワードを出すのも絶対NG。困っている人がいるんだからそのお仕事も転がっていると言うことも忘れずに。
・・・なんだか矛盾しちゃったけど要はバランスですよ、バランス。
でもそれらをうまい事できるようになるのは結局のところ経験がものを言うんじゃないかな?後、当事者意識。

さてさて、前置きがだいぶ長くなってしまったけど要は何を言いたいのかと言いますと・・・

ケースバイケースで触れそうな仕事があったらプランニングの場で開発現場の人にも振れ!(勿論全く筋の通っていない仕事は受けないことを前提としている)
身は一つしかないんだから何でもかんでも引き受けてしまうと   爆発    します。

なんだか例を上げておかないと伝わりづらいところかもしれないな。
というわけで、実際に私たちのチームでやったこととして・・・

~~しんどかった時~~

  1. POから新規追加機能の実装案件が降ってくる(絶対やんなきゃいけないやつ)
  2. 要件仕様をまとめてPM、POと相談しながら要件定義を進めていく
  3. プランニング or デイリースクラムで初めて案件の話をしてプランニングを行う(要件定義不足があったら2に戻る)

~~しんどくなくなったとき~~

  1. POから(ry)  → ユーザストーリに追加ドーン!!
  2. プランニングで自分が持っている情報だけを話してから担当を決める
  3. じゃ!あとは任せた!

正直1億万倍は楽になった!

お前サボってんじゃねーよ? はて、なんのことかな?

ま、これには悪いことだけではなくてですね・・・開発者がUI/UXにもある程度携わっていただくことでプロダクトの仕様に詳しくなってチームとしての開発力の底上げにもなるんじゃないかなって思います。いやほんとマジで

今回のケースで言うと回らなくなりそうだからそうしたら結果的によくなった!って言う話でした。めでたし!!(オチなし)

3. まとめ

前回よりもまとまりがないなぁ・・・
とにかく今回の内容をまとめると

  • デイリースクラムや振り返りなど共有体裁が整っているとプロジェクト管理が捗る
  • スクラムマスターはスーパーマンではない。しんどくなったら人を頼れ!

こんだけ書いて二つしかないのかよ・・・

4. 次回予告

さらば、スクラムマスター。
我々のスクラムはさらに上の次元に到達する。

5. 次のスクラムマスターは

この記事を見ている君だ!
一緒にスクラムをしよう!!