みなさんは結婚式の準備にどのようなイメージをお持ちでしょうか？

「ウェディングプランナーさんの言う通りに準備を進めていけばいいかなー」

「オプションでどれにするか決めていくくらいかな」

となんとなく思われている方も多いかもしれません（自分はそう思っていました）。

ですが実際にやってみると、「どんな結婚式にしたいのか」「どんなふうに感謝を伝える場にするのか」から自分たちで決めていく必要があります。楽しい瞬間もたくさんありますが、議論不足や認識の違いから喧嘩に発展してしまうこともありました。

そんな難しい結婚式の準備という自分たちで「正解」を作り上げていくプロセスに、スクラムでどう向き合って乗り越えることができたのかを、このセッションでは紹介したいと思います。

スクラム未経験のチームでスクラムを始めていくと、2-3スプリント目が終わったあたりで

• こんなに多くの会議は必要ですかね？
• 手を動かしたほうが早くないでしょうか？
• スクラムイベントの時間が長くて疲労感がすごいです。

という感想やフィードバックがレトロスペクティブの際に挙がることはないでしょうか？

チームが上記のように感じることで、時にはチームのモチベーションが下がったり、スクラムをやめてしまう原因の一つになってしまうこともあると思います。

スクラムに対して「会議が多い」「会議の時間が長い」というのはよく聞く批判なので（あるあるなので）

• よく出てくる感想なので、あまり心配しないでくださいね
• 効果を感じるまで時間がかかるのは事実なので、もう少しやってみませんか？
• 慣れるまでは確かに大変だと思います。

という言葉でチームに対してコメントや問いかけをすることもあると思いますが（自分はそうしてしまうことも多かったです）、「会議が長い・多い」という感想やフィードバックがでてしまう背景には当然原因となる事象が潜んでいるはずです。

それらのフィードバックや感想の原因となる事象についての考察と、それに対してチームでどう向き合っていくのかについて、BASE株式会社のあるチームの実例を紹介しつつ発表します。

チーム構成としては以下を想定しています

• PO、スクラムマスター、開発チーム（エンジニア4-5名）
• スクラム未経験からスクラムを始めて1-2ヶ月

サービス開発をしていると、不確実性が高い様々な事象がチームを容赦なく襲います。

そんな中、不確実性への対応力を上げるために、皆さんはどんなことに取り組まれていますか？

自分のチームでは、スクラムとともにアジリティを高めるために「開発タスクのバッチサイズを小さくする」ことに日々取り組んでいます。

この発表では、受け渡し型開発（リレー形式・ウォーターフォール）がなぜ不確実性をコントロールしにくいのかや、明日からできるチームのアジリティを上げる開発タスクの切り方を紹介します。

スクラムを始めていくと

• こんなに多くの会議は必要ですかね？
• 手を動かしたほうが早くないでしょうか？
• スクラムイベントの時間が長くて疲労感がすごいです。

という感想やフィードバックがレトロスペクティブの際に挙がることはないでしょうか？

チームが上記のように感じることで、時にはチームのモチベーションが下がったり、スクラム開発をやめてしまう原因の一つになってしまうこともあると思います。

スクラムに対して「会議が多い」「会議の時間が長い」というのはよく聞く批判なので（あるあるなので）

• よく出てくる感想なので、あまり心配しないでくださいね
• 効果を感じるまで時間がかかるのは事実なので、もう少しやってみませんか？
• 慣れるまでは確かに大変だと思います。

という言葉でチームに対してコメントや問いかけをすることもあると思いますが（自分はそうしてしまうことも多かったです）、「会議が長い・多い」という感想やフィードバックがでてしまう背景には当然原因となる事象が潜んでいるはずです。

それらのフィードバックや感想の原因となる事象についての考察と、それに対してチームでどう向き合っていくのかについて、BASE株式会社のあるチームの実例を紹介しつつ発表します。