はじめに
こんにちは。
株式会社LIFULLでアプリケーションエンジニアとして不動産ポータルサイト「LIFULL HOME'S」の開発を行なっています。
yamaoです。
早速ですが、今回は半年間私のチームでスクラム開発を行なった結果、失敗したことをいくつか挙げて振り返っていこうと思います。
ぜひ反面教師にして下さい。
ちなみに筆者はサブスクラムマスターとして主にスクラムマスター（以降 SM とする）のサポートをしてましたので、その目線からの振り返りであることをご認識下さい。
チームについて
- 2022年4月から新たに組成されたチーム
- 企画・デザイナー・エンジニア合わせて 10 人
- スクラムを導入
半年間やってみての課題
モチベーション
-
チームの KPI 設定やすぐにやってしまいたい施策を優先して、メンバーに対してスクラム導入にあたっての説明やモチベーション（動機付け）部分をざっくりと済ましてしまったこと
- メンバーのモチベーションがスクラムの運用に、実際は対して影響を及ぼさないんじゃないかと軽視してしまっていた
- 結果としてスプリントの完了 MTG をやってもチームの運用を改善する様な本質的な意見を出す人が少なくなったり、何より「みんなでチームを上手く回していく」みたいな雰囲気が最後まで作れなかったのもここが尾を引いたのかなと思っている
ストーリーポイント
-
SP を企画・デザイナー・エンジニア全てのタスクに振っていたこと
- 元々は、振り返りの時にチームのどこが進捗悪いのかボトルネックを把握出来た方が良いからという理由
- 結果としては、それぞれの職種間で 1 ポイントの重みを揃えるのが大変だったり、全部の職種のタスクに SP を振るとなるとその分プランニングポーカーの時間も増える。その割にボトルネックは目に見えて開発フェーズだったので2ヶ月ほどでエンジニアのタスクのみ SP を振る運用に変更した
スクラムイベント
-
準備からファシリまで全て SM で行なっていたこと
- 朝会はかろうじてファシリを輪番で回して SM とメンバーのみの会話にならないように出来ていたが、基本的にスクラムイベントの準備や朝会以外のファシリは SM 側でやってしまっていた。完全に間違いとも言えないとは思うが、結果的にチーム改善のための全てのアクションが SM 起点になってしまった要素の一つだと考えていて、個人的には失敗したなと感じる部分でした
-
計画 MTG が作業となってしまったこと
- SM がバックログリファインメントで次スプリントで行えるであろうタスクを前 SP をもとに見積もり、計画 MTG でメンバーと擦り合わせを行なうというやり方であったが、前スプリントの SP をもとに振っているということもあり、メンバーからも特に意見は無く認識を揃えてすぐ終わり...となりがちで作業感が強かった
- これ自体は問題ではないのだが、バックログリファインメントにメンバーも参加してもらってワイワイしながらタスクを見積もっていった方がメンバーも納得感もって取り組めるし、より多くの意見を拾えるから良かったなと感じている
ファシリテーション
- スクラムイベントのところでも記載しましたが、SM だけで回しすぎてしまったこと
- MTG アジェンダの作成や準備からファシリまで、適宜振り分けた方が各々メンバー自身でどういう MTG にする必要があるかなど考えてもらうきっかけになるので、より自発的に行動してもらう一助になったのではないかなと考えている
次の機会に向けて
私の知識の拡充ももちろんなのですが、やっぱり「チームが自発的に行動しやすい」様にスクラムを運用していけなかったのが一番の反省点かなと思っており、それに紐づく
- チームの KPI 設定やすぐにやってしまいたい施策を優先して、メンバーに対してスクラム導入にあたっての説明やモチベーション（動機付け）部分をざっくりと済ましてしまったこと
- SM だけで回しすぎてしまったこと
この二つの課題は特に次回のチームでは改善出来る様に動くのが良いなと考えています。
この二つの課題に関してはそもそも行えていないものなので、まずは実践していくことから始めていきます。
さいごに
チームの成果物を見るとこのスクラム運用のせいで問題があった訳ではなかったのですが、個人的に SM に近い役割をやらせてもらって課題を感じることが多かったのと、失敗談ってあまり記事でみないのでスクラムをしている他の方に「こういうことをやって失敗しましたよ」というのが知れ渡るといいなと思い記事にしてみました。
是非反面教師にしていただけると幸いです。