こんにちは、 @yizknn です。
2018年1月にLSMスクラムマスター認定を受けまして、スクラムの手法で強いチームを作ろうと日々もがき続けています。
今回はこれまで3つのチームでスクラムした中で出来上がってきたスクラム観について語りたいと思います。
あくまで1人のスクラムマスターとしての意見であり、団体としての総意ではないことをここにご了承ください。
アジャイルやスクラムの用語は流行り廃りやチーム内の造語で置き換えがよく発生します。
この記事では意味がズレないように、スクラムガイドの用語を使用します。
スクラムガイドは日本語訳のpdfも配布されています。
https://www.scrumguides.org/index.html
スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.comより
スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価
値の高いプロダクトを生産的かつ創造的に届けるためのものである。
表現が少し濃いですが、私は「共通のゴールに到達するため、開発チームが一体となって働くこと」がスクラムだと考えています。
1人よりもチームで強くなることで生産性が上がり、楽しく仕事が進められるようになるという理想の職場環境です。
仕事が順調に進むとモチベーションを高く維持できるので、会社で働くことが楽しくなってくるでしょう。
なぜスクラムを取り入れたいのか
不確定要素の多い開発の場合、「素早く価値を提供する」ことが求められます。
その価値が目論見通りの価値になるか分からないので、素早く提供して反応を見ながら訂正していくのです。
スクラムはフレームワークの定義が整っていて、すぐに手法を実践できるため、試しながら効果を実感できます。
共通言語として用語へのイメージも固定されるので、学習コストも低くなります。
気になったら試しに始めて、組織的に取り組むとなったらスケールを広げられるのも魅力です。
スクラムは明確な改善意識を育てる手段でもあるので、指摘を受けて襟を正すのではなく、自立して問題に立ち向かえるようになります。
プロダクトバックログは開発の外を意識する
「顧客にどんな価値を提供できるか」を主題にすると上手く機能しました。
1つの製品または機能に対する要求をユーザーストーリーに分割して、優先順位を付ける方法がシンプルで運用しやすいと感じました。
例えば、「庭で気軽に遊びたいので家の木を使った遊具で遊べる」のようなタイトルです。
顧客は何が得られるのか、実装されると何が嬉しいのか、実装の目的を明確にすると実現方法を想像しやすくなります。
タイトルに全て詰め込むと長くなってしまうので、補足事項として背景や何が目的なのかは別に文章化しておきましょう。
例えば、気軽に遊ぶというのは安いものでいいのか、運用するのが楽なものがいいのか、などの設計で重要なことを明確にします。
ここでは実装方法は問わずに価値を主題にすることで、プロダクトオーナーとチームメンバーで話が通しやすくします。
プロダクトバックログを管理して完了を宣言するプロダクトオーナーが、ビジネスサイドとして価値があるか判断しやすくなれば齟齬も生まれにくくなります。
有名な画像にもあるように、顧客の要望とその要望に対応する価値は一致しないことが多いです。
本当に必要なものを考えるためには、なぜそれが必要なのかを知る必要があるのです
Project Cartoon: Japanese
スプリントバックログは開発の作業を意識する
「価値を生むために何をするのか」を主題にすると上手く機能しました。
ユーザーストーリーを実際の作業に落とし込んで、1日で終わるようなサイズに分割します。
この1日の匙加減は適当でよく、MTGが特に多くなければ長くても3~5時間程度で終わる量を想定するとタスクが終わりやすかったです。
それ以上の大きさになるようであれば、レビューの難易度やタスクの属人化を考慮してペアプログラミングやモブプログラミングで片付けたいです。
タスクはなるべく翌日に持ち込まないようにして、タスクの属人化とモチベーションの低下を防ぎましょう。
意味のあるコードとして無理にまとめようとすると、リファクタリングなど修正範囲が膨らむ事になり、時間が掛かると中途半端にマージして別のリファクタリングを挟む事になります。
そうなると、1つのタスクに縛られ過ぎて仕事が進んだ心地になりません。
同じような結果になるのであれば、どこまで進んで何が障害になるのか分かるような区切りにして、着実に進んでいる実感を得られた方が良いと感じました。
スプリントプランニングでゴールを決める
次に何が完成したら目的達成となるかを主題にすると上手く進むと感じました。
プロダクトバックログを上から眺めて、完了させたいユーザーストーリーをスプリントバックログに移します。
そのユーザーストーリーたちの完了条件を決めて、全て終わらせたらゴールすることを確認しましょう。
可能であれば作業期間となるスプリントの日数も決めない方が良いかもしれません。
目指すゴールに辿り着いた時がスプリントの終わりとなった方が、次々と加速して前進していくように感じれます。
ゴールを追い抜いた後はボーナスステージではあるのですが、明確な目的が消えてしまうので実の所モチベーションが上がらないことが多いです。
見積もりの手順が抜けていますが、見積もりはしない方が良いと考えています。
見積もりは作業の目安にしてやり過ぎない
まず、ソフトウェア開発は不確定要素が多く、作業時間を予測して管理することに向いていません。
再現性が低く、異なる状況に対応する必要があるからです。
見積もりの精度は作業が進行するにつれて上がるため、最初からスケジュールを定めて引こうとしてもうまくいきません。
もし見積もりが正しく働いていると感じているなら、それは見積もりを正しく見せるために動いていて危険な状態かもしれません。
パーキンソンの法則である「仕事の量は完成のために与えられた時間をすべて満たすまで膨張する」になっていたり、ベロシティが人事評価に繋がるようになって実際以上の成果を作るようになってしまうことがあるのです。
何より見積もりには膨大な時間が掛かります。
不確定要素が多い時に抜けが無いように時間を掛けても、いずれ何かしら忘れていたことが発見されて再見積もり、スケジュールとズレてくると再見積もり、と際限がありません。
それだけの時間を消費して敏捷さを損なっている状態でアジャイル開発だと言えるでしょうか。
www.industriallogic.com
2012年の古い記事ですが、既にモダンアジャイルの提唱者も見積もりを辞めるべきと書いています。
Regional Scrum Gathering Tokyo 2019では、Chris Lucian氏が何年も見積もりの無い状態「No Estimate」で仕事をしていて、とても良くチームが機能していると話してくれました。
何年も前からアジャイル開発者の中には見積もりは必ずしも良い手法ではないと気付いて実施していない人たちがいました。
ビジネスサイドからすればリリースのスケジュールが引けないので頭の痛い問題ではありますが、より良いものを早く提供していれば約束が無くても顧客の信頼を勝ち得ることは成功者が証明しています。
個人的には見積もりは作業の大きさが分かる目安にして、個人でやれるか協力してやるのかを決めるくらいにした方が効率も上がるので好みです。
ただし、お互いに信頼があり技術力も高まっている「強いチーム」でなくても実践できるかはまだ試せていませんので、実戦経験などある方がいましたら教えてください。
デイリースクラムをチームの成長に繋げる
デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。
スクラム会議の目的は、進捗の障害と解決策をチームで話し合い共有することです。
自分のタスクの進捗を報告するのではなく、なぜ遅れているのか、早く進んでいるなら何を前倒しにできそうかを話し合う場になると、チーム全体の進捗が良くなるので成長に繋がると感じました。
スクラムでは輪になって順番に報告していくスタイルを提案していますが、話すのが苦手な人にも順番が必ず回るという利点もありつつ、自分の番以外には興味を失って黙り込む欠点もあります。
かんばんスタイルでタスクを管理している場合は、人ではなくステータスを順に見てタスクを移動させられるか話し合う方が活気付いて良かったです。
特に物理的なかんばんボードがあるなら、止まっているタスクがあるとみんなが注目してタスクをどうするか話し合いやすいのです。
順番に話していくと人に注目しがちなので、ともすれば個人に責任や問題が転嫁しない工夫が必要です。
スクラムの定義では15分とされていますが、30分程度まで伸ばして振り返りの要素を入れてあると良いように感じています。
スプリントレトロスペクティブまで待つのではなく、改善できることは早く見つけて忘れずに対応するためです。
スプリントレビュー
スクラムでは、チームが一丸になってスプリント毎に設定したゴールを目指します。
そのゴールに辿り着いたかを関係者にお披露目するのがこのレビューです。
スプリントレビューを開催しないスクラムチームの多くは、タスクを消化することがモチベーションに繋がってしまい、個々人のタスク消化に執着することが多いように感じています。
チームが提供できた価値を正しく評価されることが、モチベーションやチームの一体感を育てる最も良い方法だと考えています。
そのため、場合によっては他部門や別チームの人も呼んで盛大にお祝いした方が良いでしょう。
お互いにリラックスした状態で仕事が出来れば、より良い発想や協力関係になっていくからです。
良い議論をするためには、遠慮なく意見を言い合える関係性が不可欠です。
ドーナツとコーヒーを用意して集まるだけでも雰囲気が良くなるかもしれません。
スプリントレトロスペクティブは小まめかつやり過ぎない
スプリントレトロスペクティブは用語が長いので、以下から「振り返り」と呼びます。
短い時間でも1日に1回振り返りをする方が、もっと長い間隔で開催するより効果的だと感じました。
1週間に1回の振り返りでは直近または個々の記憶に残る出来事に引っ張られてしまいます。
チームに関わる問題を意識的に思い出すことは難しく、記憶に残るきっかけも異なるので大事な改善要素が消えていきます。
毎日KPTを書き溜めてチームの振り返りで発表する方法は、気に掛かる点を忘れないという点では有効でしたが、週末に大量のTRYが出ても実践できずに捨ててしまう結果になりました。
中には実施しなくて良いこともあるので、TRYがあれば良いというものでもないですが、無かったことにはせずにTRYの駐車場を作る方が良かったですね。
あとから見回して必要なくなったら取り除けば良いのです。
振り返りはチームが成長する時間です。小まめに丁寧な手入れを続ければ、チームは強くなっていくでしょう。
ただし後から話した方がいいことは後回しにして、話し合いに疲れないくらいの適度な量に調整しておきましょう。
もう疲れたよと誰かが言ったら笑って止められるくらいが丁度いいです。
最後に
スクラムは初めてアジャイル開発する時に強力な助けとなります。
しかし、全員がスクラムしたいという意識が揃わないと上手く回らず、スクラムは合わないとなってしまうことも多いです。
結局のところ、スクラムは開発運用の助けであってチームの関係性を変えるものではないので、コミュニケーションは別枠で考えて大事にしていく必要があります。
そうした問題を乗り越えたチームで働いてみたくて今日もスクラムしています。
クラウドワークスではチームと共に成長したいエンジニアを募集しています。
www.wantedly.com
