スクラムに「うーん、、、」て感じた時なんか役にたつ"かもしれない"3行アドバイス

この投稿は ミライトデザイン Advent Calendar 2021 の 25日目最終日の投稿です。

本稿の内容

スクラム開発を取り入れてみたけどいまいち機能してない。いまいちメリットを感じない。
失敗はしていないけど成功もしていない。みたいな経験ががありませんか？

本稿ではそんなときに改めてさっと見返して役に立つことを目的とした「3行くらいのアドバイス」を書きたいと思います。（あくまで"くらい"なのでたまに超えるかも）
また、個人的意見も多分に入ってますのでそこはご了承ください。

前提

まずはスクラムチームの意識を合わせましょう。
スクラム開発ではスプリントごとに「プロダクトに対してインクリメントを積み重ねていく」事を目的とします。
この大前提を見失ってはスクラム開発のどんなプロセスを踏んでも価値を得る事は難しいでしょう。

インクリメントとは、プロダクトに出荷可能な形の価値を積み重ねる事です。

大事な事なのでもう一度言えば、スプリントは「計画したインクリメントを積み上げる事をゴール」とします。スプリントで計画したポイント総量を消化することや、各種イベントをこなす事は本質的な目的ではありません。

そして、より良いインクリメントを柔軟に積み上げるためにスクラムにはいくつかのルールやイベントが存在します。
そういったスクラムの各用語にこれから3行ほどの説明を書いていきたいと思います。

導入系

やっぱ時代はアジャイルじゃん

時代で決めない方が良い。
なぜアジャイルやスクラムを導入したいか文書化してみるのおすすめ。

スクラム（アジャイル）未経験者しかいないけどなんとかなるかな

たいがいなんとかならない。
半年でも良いから経験と知見ある人アサインできないか上とかけあいましょ。

スクラムやれば開発効率あがるよね

あなた次第。
上がる可能性はあるけどグダグダになる可能性もあるよ。
あまり考えずイベントこなすだけでは多分上がらない、というか下がるかも。

スクラムやれば個人毎のタスク消化数が測れるよね

側面として見える事もあるけど、それが目的で導入はおすすめしない。
スクラム組んで押してるとき誰が一番力入ってるかわかりにくいでしょ？
スクラム開発も文字通りチームで一丸となるものなので。

イベント系

スプリントプランニング

優先順位は必ずプロダクトオーナーが決める事。開発チームは決断に必要な情報を提供する。
ストーリーポイントは必ず開発チームでふる。その時何をすればいいかの理解が全員がバラバラでは良い感じのポイントふれないよ。

デイリースクラム

昨日何して今日何やるかの報告しかしないならやる意味ない。カンバン見ればわかる。
スプリントゴールにチームが到達する為に日々何をコミットしなくてはいけないかを話し合おう。
その手法として1行目のテンプレを使うだけ。目的忘れないで。

スプリントレトロスペクティブ

特に何もなし、みたいな事が続いてたらあなたのチームはパーフェクトスクラムチーム。
多分異世界から転生してきた可能性がある。
タスクではなくスクラムチームにフォーカスを当てた大切な検査の機会を無駄にしないように。

スプリントレビュー

開発チームがデモをしてはダメ。
プロダクトオーナーの気ままな操作を伴うレビューに耐えられないものはそもそも出荷可能とは呼べないよ。

バックログリファインメント

プロダクトバックログアイテムを全て見積もり可能な状態にする事は不可能。
直近の分だけでもしっかりと見積もり可能な状態に変えていきましょう。

用語系

スプリントゴール

プランニングで定めたインクリメントを積み上げる事がゴール。
ポイントは消化できてるのにプロダクトが成長している感じがしないって事はありませんか？
それはおそらくゴール設定が間違っています。
「ベロシティは上がってるけどこのスプリントではレビューするものはありません」みたいな会話が出ていたら黄色信号の合図です。

インクリメント

スプリントによって生み出されたプロダクトの価値。
一番よくある誤解は、インクリメントとはリリースの単位なのではと考えてしまう事。
インクリメントをどういう計画でリリースするかはまた別のお話しです。

SHIPPABLE

SHIPPABLE PRODUCT INCREMENTと、インクリメントの頭に付くあれ。
出荷可能なプロダクトの価値。
技術的に完成した状態。リリースの計画に影響を受ける事はない。

velocity と estimate

estimateは難易度。velocity は速度。
慣れてるから、初めてだから、ベテランだから。そういったもので難易度は変らないよ？
変わるのは速度だけ。

東京-浅草間を移動する距離は誰が歩いても同じ。つまり同じ難易度。これがestimate。
ただし道を知ってる人や歩いたことある人は初めての人より早く着ける。これがvelocity。
estimateふる時にメンバーそれぞれが自分の経験値を元に難易度決めちゃったら適切なestimateが降られることはなく、当然velocityも信用できなくなる。

その他（QA形式）

スケジュールの管理がうまく行かないっす

スクラム開発で一番陥りがちなのが、スプリントばかり強調されるので、細切れでしか開発を認識できない事があります。
もちろんそれでは良いプロダクトを作るのは難しいでしょう。
ユーザーストーリーマッピングなどを行い、必ず全体像を見据えた上でバックログを作成しましょ。
インクリメンタル & イテレーティブ

ドキュメント書かなくていいって聞きました

うん。忘れよ。
どんな手法だろうが必要があればどんなドキュメントだって書く。
カンバンしかドキュメントがないプロダクトなんて地獄よ。

バーンダウンしてんのに炎上してんすけど

その消化しているポイントは本当にインクリメントを生み出せていますか？
ポイント消化が目的となるような計画を立てていませんか？
そもそもリソースに対して計画がずれていませんか？
MVPを切り出して、ストーリーごとにインクリメントを積み上げる意識をプランニングに持ち込みましょう。

POが忙しくてイベントに参加できません

プロダクトオーナーが不在のスプリントレビューは不可能です。
もし定期的に時間を取ることができないのであれば、無理にスクラムしない方が良いかと。
プロダクトオーナーで進めたとしても結局リリースの直前に一気に検査が行われ、大リジェクト祭りが発生して今いますよ。

スクラムマスターって持ち回ってもいいんですか

事情があり複数人のスクラムマスターが入る事があっても不可能ではないです。
ただし、その場合そのスクラムマスター同士がしっかりとコンセンサスが取れているというのが前提となります。

おしまい

今回は思いついた事を雑多にならべて書きましたが、他にもこれについてはどう？という話題があれば教えてください。
そのうちなんか知らの方法でお答えさせて頂く"かも"しれません。

ミライトデザインアドベントカレンダーは本日の投稿で以上となります。
ミライトメンバーや協力してくれた仲間の方々みんなのおかげで無事最終日を迎える事ができて凄く嬉しいです。
本当にありがとうございました。

ミライトデザインでは、一緒に働いてくれる仲間を絶賛募集しています。
アドカレの記事の内容が興味があった方、設計やDDDが好きな方、ミライトデザインが気になった方、
どんなきっかけでもかまいませんので、もし少しでも興味を持っていただけましたらお気軽にお茶でもしませんか？
そんな方はぜひtwitterのDMまでお気軽にメッセージください！

一か月間ありがとうございました！