こんな方に読んでもらいたい
- 以下のような課題を抱える責任者・マネージャー・リーダーの方に読んでもらえると嬉しいです
- チームメンバーがいつどんな仕事を何のためにしているかわからない
- 進捗どう？と聞いてしまいがち
- 目標のためにあれもこれもと仕事が増え、残業が当たり前の組織になってしまっている
- 目的や目標に対して、全員のベクトルが揃っているかが不安
- 確認や報告のMTGが多い
- 以下のような課題を抱えるメンバーにも読んでもらえると嬉しいです
- 自分の仕事量や成果を上司が把握してくれているかわからない
- このタスクは何のためにやっているかわからなくなるときがある
- 目的や目標に対して、どう向かっていくのか解像度高く見えてこない
なぜスクラムを導入したのか
- SCQAで記載します
状況提示(Situation)
- 以前より僕たちは毎日朝会を実施していました
- 今日やることを発表し、確認し合っていました
複雑化(Complication)
- 「今日やること」は今日終わったのか、引き続いて明日もやることになったのかが、コミュニケーションを取らない限りはわかりませんでした
- 「今日やること」は何のためにやっているのか他のメンバーにとってはわからないこともありました
- 何のためにやっているかを確認すれば、無駄に時間を費やしてしまうことになります
- 「今日やること」は、本当にチームとして優先順位が高いことなのか、なぜ今日それに着手しているのかが見えづらいことが多くありました
問い(Question)
- 今取り掛かっているタスクは、誰から見ても以下が明確になっているべきではないかと考えました
- 何のためにやっているのか
- どれくらい時間がかかるものなのか
- いつ終える予定なのか
- 実際いつ終わったのか
- いつ取り掛かったのか
- また以下2点も、このチームの問題だと捉えました
- チーム全体として、今優先的に取り組む事象はなにかをはっきりさせるべきではないか
- さらに、個々はもちろん、チーム全体として仕事のスピード感や一定期間で取り組める量を把握すべきではないか
主張・提案(Answer)
- 偶然エンジニアの朝会に出る機会がありました
- タスクについて話し合い、最後には「せーの」と言って全員で指で数字を作っています
- なにやってるんだろう？
- 聞くと、「スクラム」の「プランニングポーカー」というタスクの規模を見積もる手法を実施していました
- 興味を持って調べていると、エンジニアの人たちがより詳しく「スクラム」について教えてくれたり、共有してくれました
- スクラムを適用することで、今の状況が解決出来るかも…？
- 誰からみても、誰が何のタスクをやっているのかが明確にわかる
- チーム全体として、今何に向かって取り組んでいるか優先事項がわかる
- チームの行動生産性がわかる
- 何度かエンジニアの朝会や「スクラム」で実施するいくつかのMTGに参加させてもらい、これを非エンジニアの僕たちも実施しようと決めました
実際どんなことをしているのか
- エンジニアのサポートのもと、エンジニアが実際にやっているスクラムを見よう見まねで実施してみました
- スクラムとは
- チームとして実施している内容は以下です
- Sprint Planningを実施する
- 今回のSprintに何をするかを決定します
- できるだけタスク（＝Issue）の粒度を細かくし、Issue1つ1つにEstimate（見積もり）をつけます
- 1時間程度で実施しています
- デイリースクラム（＝朝会）を毎日実施する
- 朝会では、共有事項と相談事項、それぞれのメンバーがどのIssueを着手するか、困っていることを話します
- 早ければ15分ほど、共有事項が多いと30分ほど毎日実施しています
- 振り返り（レトロスペクティブ）を実施する
- ベロシティ（1Sprintにチームが消化したポイントの合計）を振り返り、過去と比較します
- Estimateとストーリーポイント（作業時間）の乖離があるIssueがないか振り返ります
- KPTにて、このSprintで起きたことを書き出します
- 最終日に30分～1時間ほど実施します
- Sprint Planningを実施する
どんなツールを使っているのか
エンジニアが利用しているツールをそのまま使っています。具体的には、GitHubとZenHubを利用しています。
自分たちで新たなツールを探して導入から運用を進めるよりも、すでにノウハウがあり、使い方がわからなければ周りに質問できることの方がメリットは大きいと考えました。
具体的な運用の話
ストーリーポイントの定義
Estimateをつける際のストーリーポイントですが、以下と定義しています。
| ポイント | いつ使う？ | 備考 |
|---|---|---|
| 0 | すぐ終わる、1人で完結する | サポートの対応（内容による） |
| 0.5 | すぐ終わるけど、複数人が関わる | サポートの対応（内容による） |
| 1 | 普通のタスク（小） | 1時間程度 |
| 2 | 普段のタスク（小〜中） | 2時間程度 |
| 3 | 普段のタスク（中） | 4時間程度 |
| 5 | 普段のタスク（大） | 1日程度 |
| 8 | 普段より大きいタスク | わからない / ここまで大きくなったら複数のタスクに分けるのを検討する |
ベロシティ
僕たちのチームのベロシティ（1Sprintにチームが消化したポイントの合計）です。スクラムを実践して3ヶ月目の画像をここに貼ります。
初めてのSprintは1週間弱（GWも被っていた？）だったので比較対象にはなりません。
その他の週も祝日等もあり実働時間差はあるものの、少しずつベロシティが上がっていきました。
チームとして生産性が高まっている様子が可視化され、勢いづいた記憶があります。
レトロスペクティブでこの飛躍の要因を振り返るKPTがあるのも、スクラムの良さです。
Issueのテンプレート
ぼくたちは以下のテンプレートを利用しています。
## What
<!-- どんな状況でどんなアクションを取るのかを書く -->
### Goals
<!-- 何を達成したらこのissueはcloseできるのかを書く -->
### Non-Goals
<!-- このissueではやらないことを書く -->
## Why
<!-- なぜこれをするのかを書く -->
## References
<!-- 関連する issue、発端となった Slack メッセージ、議論の参考になるページなどの URL を貼る -->
導入してみて
僕だけでなく、チーム全体に聞いてみました。
結論良いこと多めだよね！やって良かった！とは思いつつも、もっとよりよく出来るという意見は出ていて、常に改善しています。
Keep
- みんなの仕事が見えるようになった
- 誰がどんな業務をどれくらい持っているかが客観的にわかるようになった
- なぜそのIssueを実施しているのかがわかるようになった
- いつそのIssueは対応していて、いつ終わったのかがわかるようになった
- GitHubに作業進捗をメモすることによって、進捗確認のMTGなどがほぼなくなった
- 1Sprint＝2週間という単位での業務量の全体把握できるようになった
- 事業目標のために、なにをこの2週間で優先し、どのような状態にするのかが明確になった
- 目的や目標に対して優先すべきIssueがあれば、この2週間で対応するIssueを入れ替えることも実施
- 気合と根性でやり切ることも大事だが、やれる業務量は限られている
- 時には冷静に、なにを優先としてこのSprintに入れて、なにを後回しにするかも決めるようになった
- IssueにGoalが設定されており、Estimateも設定されているのでIssue終了の定義が明確化された
- Issueをサグラダファミリア化しない
- 開発との連携がしやすくなった
- Epicを作成し、開発・デザイナー・ビジネスサイドのIssueを紐づけることでそのEpicを実施するのにどんなIssueがあり、全体はどんな進捗なのか、話さなくてもわかるようになった
Problem
- Issueの粒度がばらばら
- メンバーが増えるとすべてのMTGが長くなる
- Issueつくることそのものが面倒
Try
- EpicとIssueの見本をつくって、この粒度でつくる、という基準を策定
- 都度MTGのアジェンダを見直す
- Issue作成を効率化するあれこれを準備した
まとめ
- やってよかった
- 常になんでもオープンにするって大事
- 振り返る習慣がチームに根付いた
- スクラムの体系は常にチームに合わせて変化する
- チームの状況やメンバーに合わせて改善していく
- 1年やるとやり方がかなり変わっている