スクラムって難しいですよね。
なんで難しいのかっていうとスクラムガイドが薄すぎるからだと思うんですよね。
なんで薄いのかっていうとチームによってやり方が全然変わるので抽象的に書かざるを得ないからなんじゃないかなと思います。

スクラムガイドとかスクラムに関する本とか読んだ後に、いざ導入してみようととりあえずタイムボックスとか意識して全イベント導入してみるけど「使ってる時間と効果が釣り合わねー」と思ってるチームってありませんか？（そうです。私です。）

色々と試行錯誤する中でカロリー低く導入してみたらいいんじゃないかと思って記事にしてみました。

※ あくまで僕のチームでの経験を元にしています

対象読者

とりあえずスクラムを導入したけど効果を感じてない人
過去にスクラムやってなんか失敗したことある人
これからスクラムを導入しようと考えている人

簡単に経験談

かく言う僕もスクラムをとりあえず導入してみた結果、スクラムイベントに時間だけ取られてる感があって悩んでました。

試行錯誤の末、最終的に「3~4人 x 4チーム」くらい見てましたが、各チームごとにスクラムイベントの数とか内容とか全然違くなりました。同じ会社で同じプロダクト作ってるのにこんなに変わるので、他のチームの事例をそのまま導入って結構きついよなーなんて思ってます。

ただ、「最低限これだけはやってみたらいいんじゃない？」というものがあるのでそちらをご紹介します。

大前提

大前提として チームやメンバーが変わると最適なスクラムは変わる と思っています。
あるチームでデイリーミーティングがうまくいっていても、他のチームでデイリーミーティングをやったら必ずうまくいくとは限りません。チームのメンバーが1人変わるだけでも変わると思います。

チームによってやり方が違ってもいい、という意識を持つことがまずは大事かなと思います。
全部を汎化しようとせずに、チームの意見を尊重して柔軟に対応していきましょう。

スクラムの目的

その前にまず「なんでスクラムをするのか？」なのですが、 「自己組織化」すること が最大の目的かなと思っています。

いろんな本にも書かれてることですが、これが1番大事な気がします。
スクラムの失敗の1つに上長の提案でスクラムを導入して各チームにやらせるって言うのがあるのですが、全然自己組織化できてないですよね。
ある程度は上長が引っ張るのは大事ですが、ふんわりレールを引いたらあとは各チームに任せましょう。

「じゃあどう自己組織化するの？」ということなのですが、必要なことは 「振り返り」を行うこと だと思います。振り返りを自分達で出来るようになれば上長は別のタスクにリソースを割けますし、部下は当事者意識や自己成長を感じるので楽しくなってきます。

最低限、チームで「振り返り」を出来る環境を作れることを目指しましょう。

振り返りに必要なこと

振り返りをするためには 「予想(目標)」と「現実」のズレ を比較することが1番簡単です。

予想(目標)と現実のズレとは具体的に...

ストーリーポイントのズレ
Tryと効果のズレ

が計測しやすいのでオススメです。

ストーリーポイントのズレとは？

スクラムをやっているのであれば、各チケットにフィボナッチ数列とかでストーリーポイントを振っている人も多いかなと思います。

例えば、2ptのタスクがいつも大体1〜1.5日くらいで終わるのに5日経っても終わってなかったらなにか変ですよね。
逆に7ptのタスクがいつも大体5日もかかるのに、1日で終わってたらなにか変ですよね。

このズレがなぜ起きたのかをチームで話し合ってみましょう。僕の見ていたチームでは

予想よりも遅く終わった場合

スプリント・バックログに積んだタスクが終わらなかった
他チームのリリースとコンフリクトしてた
他部署へのやりとりが想定よりも多かった
コード見てみたら思ってたよりも複雑だけどだった
PR出したけどレビューに時間がかかってしまった
など

予想よりも早く終わった場合

コード見たら使いまわせそうなものがすでに実装されてた
見積もり時の仕様とは異なるアプローチで解決できた
仕様が変わって工数が大幅に減った
など

とかがあったりしました。
あとはこれを元に「じゃあ何をすればストーリーポイントを正確に見積もれるようになる？」「なんで見積もりの時にこれらに気付けなかったの？」というのをみんなで話し合ってみましょう。

話し合った結果

事前に関連するコードを見ていたら気付けたかも
この辺りの開発することを他チームに共有できていなかった
PRがデカ過ぎてレビューに時間がかかった
他部署とのやり取りが発生すると思ったより時間がかかる
など

などなど、何かしらのProblemが出てくるはずです。そうしたらそれに対するTryを洗い出し、次スプリントで実践するTryを選んでみましょう。

Tryと効果のズレとは？

Tryを実践したらその効果も必ず振り返りましょう。Tryをする前には 「こう言う効果があったらいいな」という理想があるはず なので、そのズレがあるのかないのか話し合ってみましょう。

次スプリントで試してみることの認識をみんなで揃えられればなんでもいいと思いますが、僕はKPTを使っていました。振り返りで出た課題がProblemです。逆にこれが良かったみたいなのがあればKeepに入れておきます。Problemを改善するために実行すること、Keepを抽象化して他に応用できそうなことをTryに置きます。

Tryは必ず実行可能な具体的なものにしてください。

⭕️ 作業前に実作業をチェックリストにしてみる, PRを最小に分割する
❌ タスクを早く終わらせる, 気合を入れて取り組む※

※ もし気合いが入ってなかったら大事です

このようにTryをみんなで話し合ってみてください。

ここで「技術的に困っていたが調査に没頭しており相談するのが遅れた」みたいなProblemが挙がってきたら「デイリーミーティングとかやってみます？」というのをみんなが合意の上で導入してみるのが良いと思います。
「もしうまくいかなかったら無くすので、1ヶ月間だけとりあえずやってみましょう」、的な感じで「この決定が未来永劫続くのでは…」という不安を取り除くのも大事です。

手軽に試して、手軽に辞めれる という環境を作ることが大事です。

最初のゴール

こんな感じで振り返りを繰り返しながら「自己組織化」を目指しましょう。

チームメンバーが自立的に振り返りを行いProblemを出す
Problemに対するTryを自立的に出し、実践し、振り返る

まずは自分たちで振り返る習慣が出来ると良いと思います。その中で「チームでやってみよう。」となったら徐々にスクラムイベントを足して行けると納得感もあって良いと思います。

上からスクラムイベントを押し付けるのではなく、ボトムアップで必要なものは何かを話し合いましょう。

最低限これは欲しいもの

スクラムにはロール・スクラムイベント・成果物など色々ありますが、最低限これは入れておいたほうがいいのでは？と言うものをご紹介します。

タスク管理ツール
スプリントごとのミーティングを1回はやる
KPTのような振り返り用ボード

タスク管理ツール

既に使っているタスク管理ツールで、タスク毎に以下のステータスを管理できればそれを使いましょう。

Product Backlog
Sprint Backlog
In Progress
Done

カンバンボードのように全体がパッと見れればなお良いと思います。特にまだ何も使ってないということであればGitHub Projectsがオススメです。

流れ

とりあえずタスクが発生したら Product Backlog にガンガン積む
スプリント毎のミーティングでタスクの見積もりをし、次スプリントで終わらせるものを Sprint Backlog に積む
着手する時にタスクを In Progress に移動させる（担当者が誰かもパッと分かるように）
タスクが終わったら Done に移動させる

この4つのステータスが分かれば振り返りに使えると思います。ちなみにチケットを見て「パッと作業内容が分からない」とか「予想と現実がズレてるのは分かるが理由が分からない」とかであれば、もう少しチケットに細かく記載してみよう、というのもナイスTryになると思うので、改善していきましょう。

スプリントごとのミーティングを1回はやる

スクラムイベントでいう「スプリント・レビュー」「スプリント・プランニング」「スプリント・レトロスペクティブ」に当たるかなと思います。

流れ

スプリントでやったことをみんなで称賛しつつ※、予想とズレてるものがあれば軽くピックしておく（スプリント・レビュー）
Product Backlogを見積もってSprint Backlogに移動させる（スプリント・プランニング）
1でピックした各チケットのズレの原因を振り返ってProblemを洗い出し、次スプリントでのTryを整理する（スプリント・レトロスペクティブ）

※ 僕らは成果物の評価とかは都度スポットでPdMや営業にお披露目していたのでエンジニアだけでやってました

こんな感じのミーティングをスプリントで1回はやりましょう。僕のチームでは1週間スプリントだったのでとりあえず毎週1時間このミーティングの時間を取ってました。「1時間じゃ終わんなくね？」と思いますが、1時間で終わらせるために「ここの時間を削ろう」とか「事前に軽く準備しよう」とか「振り返りはもう少し深掘りしたいから別ミーティングにしよう」とか、色々意見が出てから変えていくのが良いと思います。とりあえずヘルシーに気軽にスクラムを導入してみることが大事だと思います。

KPTのような振り返り用ボード

決めたTryはいつでも簡単に見れるようにしておくと良いと思います。また、ProblemやKeepを思いついてもミーティングまでに忘れてしまうことも多いです。
忘れてしまってもすぐに目に入るように、また 思いついたらすぐにProblemやKeepを挙げられるように 振り返りのボードは準備しておくと良いと思います。

そして、Tryしたことは必ず振り返りましょう。「Tryに入れてみた結果どうだった？」と必ず話し合いましょう。

中には「全然意識できてなかった」みたいなこともあると思います。そしたら「じゃあ意識するためにはどうすればいい？」とか「なんで意識しなかったの？」とか話し合いましょう。「前回のミーティングでは良さげに聞こえたけどいざやってみると全然意味なかった。」とか意見が出れば別のTryが生まれるチャンスです。

あくまで少人数のチームを改善するための施策なのでそんなに無理してやらなくてもいいと思います。みんなが良さそう！と思ったものを積極的に取り入れていきましょう。

まとめ

スクラムの目的

振り返りを実施して「自己組織化」を促す。

最低限必要なもの

Product Backlog, Sprint Backlog, In Progress, Done の状態が分かるタスク管理ツール
スプリント毎に1回のミーティングで「タスクの見積もり」「振り返り」を行なって予想と現実のズレを話し合う
KPTのような振り返りボードでTryを確認できるようにし、手軽にKeep, Problemを挙げられるようにしておく

長くなってしまいましたが、スクラムってめっちゃむずいので、もっと気楽に導入してみようぜ、と思っています。
新設してばかりのチームであればコミュニケーションのために対話の時間をもっと増やしたほうがいいかもしれませんし、シニアエンジニアが多いのであればドキュメントがメインのコミュニケーションでいいかもしれません。

僕はジュニアが多いチームだったのでシニアエンジニアの考えを共有する会を開いてみたり、見積もり時に細かく作業内容を洗い出すようにしてみたり、個人の学習に対して多めに時間を割くようにしていました。

チームのスキルによって、また個人の価値観によっても最適なやり方があるはずなので、対話をしながらぜひベストな運用を見つけていただければと思います。

繰り返しになりますが、「チームによってやり方が違ってもいい」という柔軟な意識と、「ダメだったらすぐ辞めるからとりあえずやってみよう」という気軽さで試していただけると良いかなと思います。

何か気になることがあれば質問とかしていただければ嬉しいです。

FAQ的な

Q. チーム間のコミュニケーションとかはどうする？

各チームにリーダーを任命して、毎週リーダーミーティングで以下のようなことを話していました。

今何をしているのか（コンフリクトとかリリース日の調整などの共有）
KPTの共有（他チームでも転用できる可能性があるため共有）

Q. ProblemやKeepが出ないけどどうする？

まずは心理的安全性を大事にしましょう。的を射た意見でもまず否定から入る人がいたら注意するなど、チームが前向きになるようにしましょう。
僕のいたチームでは「すみません」が口癖の人が何人かいたので「すみませんを言わない」というTryをしたこともあります。

また、意見が出ないというProblemがあり、「ミーティング中に5分間GoogleDocsに書き込む時間を作る」というTryをしたところ意見が出るようになったと言うこともあります。技術的な部分だけでなく、こういった改善でも良いので柔軟に色々な角度から気軽にTryを出していきましょう。

Q Tryが出ないけどどうする

「なぜなぜ分析」とかをやってみるといいと思います。1つのProblemに対してなぜを5回繰り返すというやつです。2回くらいで頭打ちになることが多いのですが、頭打ちになってから あえてもう1回なぜを考えて みてください。

あとは光の当て方を変てみたり柔軟に考えることも大事です。
例えばレビューに時間がかかっている場合に、レビューのやり方を改善するのも良いのですが、そもそもPRやIssueの粒度を細かくしてみることも検討できます。 「レビュワーの改善だけではなく、レビュイーの方も改善点ないか？」 と言うように対局にあるものに焦点を当ててみるのも良いと思います。

Q. 上長はどこまで意見する？

チームや上長のスキルによると思いますが、あくまで自己組織化を促すことが目的なので基本的には口出ししない方が良いと思います。

僕の場合は

これ以上ProblemやTryが出なさそうな時
他のチームや別会社の事例が当てはまりそうな時
会話が発散して着地点が定まっていない時

には意見を出すようにしてました。

ただこの時も、「こんな事例もありますよ」とか「一般的には朝会はこういうアジェンダが多いみたいですよ」という風に紹介するだけに留め、あくまで施策の採用・不採用はメンバーに任せていました。

Q. PdMなど他部署とのコミュニケーションは？

他部署が気になることの合意を取っておくのが重要かなと思います。
僕の場合は「リリース日」と「誰のどんな課題を解決するのか」を事前に知りたいという合意をとっていたので、全社朝会でリリース日の共有をしたり、新機能のデモ会を開いたりしてました。

Q. スクラムを評価とかに使ったことはある？

ありません。
ストーリーポイントの基準はチームによって違いますし、評価にするとメンバーにその気はなくても水増ししてしまったりして、チームの状態を正しく測れなくなってしまいます。

ただ、チームの成長や個人の成長のために使うのはとても良いと思います。
スプリントのベロシティが20ptだったところ、半年後に25ptになっていたらチームが成長したと言っても良いと思います。また、見積もったものが、正確に見積もり通りに終わるのも精度が上がっているので成長していると言って良いと思います。

Q. 見積もりはどうやってやる？

チームのスキルに寄ると思いますが、ざっくりどんなタスクが必要かをさっと洗い出してました。
例えば何かの修正をしたいと言う場合に以下のように修正箇所とやることをなんとなく出してました。

View
- 修正が2,3ページありそう
- コンポーネントがないものが少しあるので新規で必要っぽい
Model
- カラムの追加がありそう
- default値を入れればいいので既存データはそんなに考えなくてよさそう
その他
- 他部署との連携はなさそう

「このくらいのタスクだったら以前に似たタスクが5ptだったので、5ptくらい？」と言う感じでざっくりやってました。もちろんModel周りなど、「もう少し揉んだ方が良さそう」と言うところは時間をとって話し合ってました。

見積もりはやろうと思えば無限に時間を使ってしまうので、チームによって最適な時間で見積もれるように試行錯誤すべき部分だと思います。