スクラムチームの悩みを共有！ Scrum Developer's Night! Online #17 参加レポート

はじめに

スクラム開発者向けのイベント『Scrum Developer's Night! Online #17』に参加してきました。
この記事では、イベント内で議論したスクラムの実践者が現場で抱える悩みとその解決策について共有します。

Scrum Developer's Night! とは

Scrum Developer's Night!は、スクラム開発をデベロッパーとして実践する中で生じた疑問や悩みをタネに参加者同士で交流しながら語り合うオープン・スペース・テクノロジー（OST）形式のイベントです。
オンラインと現地で交互に開催されていますが、私が参加した回はオンラインでした。参加者は10数名ほどで、私を含めてほとんどが初参加の方々でした。

以下に私が参加した3つのトピックと所感をざっくりまとめようと思います。

#1 運用作業に追われて開発に割く時間が減っている

背景

• 開発者が減ったり運用作業にかかるコストが増えたりと、以前より開発に割く時間が大幅に減っている
• 他のチームではどのように開発と運用のバランスをとっている？

議論

• なにが問題なのか
  • 開発者が減る → やれることが減る → やりたいことがやりきれない
• どうすればいいのか
  • 優先順位の高いものから実施していく
    • 運用作業が開発と比べて優先順位が高いのであれば問題ない
  • ただし、透明性を確保した状態で優先順位をつけること
    • 正確な情報を元に判断することで精度を上げるため
    • 実際どのくらい時間がかかっているのか可視化すると良かったという声
      • 会議の時間が長いことに気づき、その後自然に短縮された
      • 潜在的な問題を発見する効果や、問題意識を揃える効果があった

所感

こちらは私が出したトピックです。
自分が変えられる範囲・変えられない範囲に切り分けて問題をブレークダウンしていくのは大事だなと感じました。漠然と抱えていた不安が「やりたいことはいつだってやれることより多い」というよくある問題由来であることに気づくことができました。

#2 効果的だった振り返りについて聞かせて

背景

• TRYを出しても実行できずに終わる。いいTRYの出し方・振り返りのやり方を知りたい
• 実行できるTRYを出すには？

議論

• 案1：TRYの出し方についてもふりかえる
  • TRYを出しても実行できずに終わってしまうこと自体をPROBLEMに挙げる
• 案2：TRYをPBIにする
  • 多くのチームで導入していたやり方
  • POへの説明が必要になるため、以下のようなメリットがある
    • 開発チームが抱える問題をPOが把握できる
    • なぜそれをする必要があるのかTRYの実施者が説明可能になる
• 案3：実施可能なくらいまでTRYのハードルを下げ、成功体験を積み重ねていく
  • メンバーにできなかった理由を聞くと、時間がなかった etc.
  • 確実に実行できるくらいTRYを小さくする
• フレームワークについて
  • KPT
    • 利用しているチームが多かった
      • KEEPがさらっと流れ、PROBLEM出しで殺伐とした雰囲気になりがち
      • 雰囲気づくりに気を遣っているチームが多かった
    • PROBLEMと同じだけKEEPを出す
    • KEEPをメンバーへの感謝の場として活用する
    • 派生：KEEPだけ出す
      • プロジェクトの問題が山積みでメンバーが苦しいとき、KEEPだけにしてモチベを保った
  • Sailboat
    • ゴールの島を目指すヨットの搭乗員と見なして振り返りを行う
• 情報収集場所について
  • vivaさんの情報発信を見る
    • Qiita：https://qiita.com/viva_tweet_x
  • ふりかえりチートシート（いろんな振り返り手法を一覧化したもの）
    • 参考：https://qiita.com/viva_tweet_x/items/b06f56ce83038fc2bb8f

所感

不安定な時期はモチベを高めるため、安定した時期はよりよい状態を目指すため、といったようにチームが置かれた状況によって、レトロスペクティブに求めることが変わる部分に気づきました。自チームの場合はどういったレトロスペクティブが求められているのか見つめ直してみようと思いました。

#3 全体的な設計どうやってる？

背景

• スクラムの理想としては、End to Endなインクリメントを継続すること
• しかし、DB設計のように、手戻りが発生したときに膨大なコストがかかるものについては、先を見越して全体的な設計を行いたくなる

議論

• どうやってる？
  • 方法1：スクラムのプロセス外でやる
    • 先を見越して進める
    • ヒアリング、要件の洗い出し、全体設計、受入基準作成などのプロセスについては明言されていないから
  • 方法2：スクラムのプロセス内でやる
    • そもそも、End to Endなインクリメントを目指す理由とは？
      • スプリントレビューでフィードバックをもらい、早めに軌道修正するため
      • →レビューできる形の成果物にすればよい！
    • ヒアリング結果をドキュメントとしてまとめる etc.
• どこまで先を見越す？
  • 一つの基準として、明日の天気予報くらい がある。「まあ当たるよね」はやる

所感

相談者は設計段階での悩みでしたが、私が実装の際に感じていた手戻りのコストを考えて先に実装しておきたい気持ちと共通する部分があるなと感じ、参加してみました。「明日の天気予報」くらいを目安とするなら、次に着手予定のPBIであれば織り込み済みで実装してもいいのかも、と思いました。

おわりに

多様なバックグラウンドを持つ参加者が集まるワークショップでしたが、共通の悩みや課題を抱えていることが分かり、共感できる部分が多くありました。また、他のチームの状況を具体的に知ることで、自チームの状況を客観的に捉え直すことができ、「検査」のよい機会になりました。

We Are Hiring!