非ソフトウェア事業にスクラム方式をためしに導入してみた（実験結果・考察）
いきなりマニアックなタイトルで、すみません。。
某飲食系の事業で、スクラムを導入してみた結果について考察するエントリーです。
ソフトウェア界隈ではアジャイル型開発の「スクラム」という方式がよく採用されており、昨年(2021年)秋に実験的に事業オーナーさんと話して「試しにスクラムを導入してみようか」ということでやってみました。
このエントリーで触れること
スクラムを適用する上で説明時に用いた資料・話したこと
適用時に留意したこと
適用後の良かった点・反省点
特に触れないこと
スクラムとは何であるか／どうやったらいいか
→スクラム公式ガイドをご覧ください（https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf）数値的な効果・効用（KPIがどう改善したかなど）
第１部. スクラムって何じゃろう？
ソフトウェア界隈にいない人たちからすると「スクラム？なにそれ？」という状況なので、まずは何なのかを説明するところからスタートしました。
スライドを作成して、大まかにスクラムについてを勉強。
（スクラムをご存知の方は飛ばしてお読みください🙏）
スプリントとは「計画・実行・振り返り」の１まとまり
スプリント中、小まめに成果を世に出します
ただひたすらにスプリントを繰り返します
いままでの方式との違いは
全てを計画し切らないで、重要なものから順に計画をする。そして計画がしっかり決まったものから徐々に進めていってしまおう、という雑な説明をしました。
スクラム方式（アジャイル型）とこれまでの方式（ウォーターフォール型）とで、途中の仕様変更による不良在庫化の影響がどう違うかを図示しました。
1スプリント内での具体的なイベントとは
リファインメント（起票されたチケットが実行可能なサイズになっているか、受入条件はどうあるべきか定義する）
スプリントプランニング（スプリントに積むチケットを選定して１スプリントを計画）
デイリースクラム（スプリントの進捗状況を検査）
スプリントレビュー（スプリントを通じて得た成果を確認）
レトロスペクティブ（スプリントの進め方に問題がなかったかを検査）
これらについて説明をしました。
時間で見積もるのではなく相対工数で見積もる
慣れない方が多いですが、相対的に見積もるんだよという話をしています。
＊＊＊
説明全般は「ふむふむ」「いいんじゃない？」という感触で進んで行きました。
第２部. さて、どう適用しようか？
与件整理
以下のことを鑑みなきゃいけないよね、となりました。
フィジカルワークなので１日の進展量がソフトウェアほどないかも
MTGで時間を割いてる間はピッキング業務などができない→MTGばかりにはできない
共同で作業することが少なく分業・分担している
もともと別事業で昔からRedmineを使ったことがあるし使える
→となると、デイリースクラム（毎日実施）を減らさざるを得なそう。そしてMTGを分散させずにスクラムイベントをぎゅっとまとめた方が良さそう。
それにしても、Redmineを使える時点ですでにポテンシャルがありました。
具体的に1スプリントを定義する
朝会を週５ではなく週２にし、その他のスクラムイベントを１日にまとめてみました。
役割を分担する
やってみる
ものは試し。とりあえずやってみる。
やりながら都合合わない日がでたりしたら都度調整をする感じで。
第３部. 結果どうだったか
miroにざっとGKPTを書き出してみました。
全部をnoteに書くと長くなるのでポイントだけ抜粋します。
Good（良かった点）🎉
スクラムでやるとなると細かに受入条件を書きますが、このムーブのおかげか「進みにくいタスクis受入条件が不明瞭」というのが伝わったのが大きいかも
単なるバックログと異なり、スプリントに積んでるタスクのみを眺めるので精神衛生が少し良くなったように感じました
Keep（続けること）🚀
受入条件を明細化するムーブは、ずっと続けていくべきだと確信。
Problem（問題点）😓
大きな問題点の１つめ「チケットのサイズがまだまだ大きすぎた」
エピックサイズのままチケットが起票されている
未リファのままのチケットが存在した
２つめ「スクラムで進める文化の浸透が発展途上だった」
各イベントの目的とやることが不明瞭だった
単なる進捗共有と相談会になりがちだった
バーンダウンへの執念が伝わりきらなかった
３つめ「うまくワークしてる状態を計画しきれてなかった」
プラ2を設け損ねてしまった
エピック/ストーリー/タスクの基準を設けてなかった
起票や担当者スイッチのお作法なども設けてなかった
Try（カイゼンすること）💪
進める上での基準や各種イベントの時期やToDoを見直すのがよさそう
あわせて起票したPOと別途リファをして「なぜ起票したか」「どうなったら完了か」を事前にもむのがよさそう
全体でのリファでは「これって実行できそう？」「やるとしたら誰がどのくらいの工数？」というポイントだしとアサインに当てるのがよさそう
まとめ
非ソフトウェア事業でもスクラムは導入できそうです。しかしスクラムを理解したスクラムマスターの存在や、バックログ管理する何らかのツールは必要になるかなと。
事前に諸々を計画するウォーターフォール型と比べて、現実的かつ健康的にすすめられるのは良い点でした👍
VUCA時代にかなりマッチした事業の進め方かもしれません。
おわり
サポートいただけたら、嬉しくて本屋に行くと思います・・・笑