こんにちは。
レバウェル開発部アドベントカレンダー 16日目です。
はじめまして。レバウェル開発部の有銘（ありめ）です。
私の所属するチームではスクラム開発を取り入れています。
これまで実践してきた中で直面した課題、そこから得た学びを備忘録としてこちらで公開します。
この記事で学べること
この記事では、私がスクラムを実践する中で直面した課題や学び、そこから導き出した改善の方向性について共有します。
- スクラム実践して直面したリアルな課題と学び
- チームが成長し続けるために必要なアプローチ
- アジャイルな文化を組織全体に浸透させるための具体的な取り組み
チームや組織でスクラムを実践している方やこれから取り組む方にとって、少しでも参考になれば幸いです。
はじめに：そもそもスクラムとは？
※あくまで個人的な理解ですのでご容赦ください。
最もよく聞くアジャイルフレームワークのひとつなのかなと思います。
スクラムガイドには、以下のように書かれています。
「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。」
さらに、アジャイルソフトウェア開発宣言では、
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
という価値が示されています。
これまで実践してきた中での私なりの理解では、
「顧客の変化するニーズに素早く適応し、価値を届けるための仕組み」
がスクラムであり、組織全体がアジャイルになるための一つの枠組みだと考えています。
スクラムとの出会いと初期のつまずき
スクラムとの出会いは、私がリーダーとしてチームにジョインした時です。
前のチームリーダーがチームでスクラム開発を取り入れていたので、深く考えずにそのまま引き継いだ形になりました。
当時の自分はスクラムを「ただの開発手法」だと考えており、深く理解せずなんとなく始めてしまいましたが、すぐに様々な課題に直面しました。
-
見積もりが機能しない
- ベロシティが一向に安定しない
- ポイントが工数として捉えられている
-
手戻りが多発する
- 要求や要件の認識合わせが不十分で、開発が進む中でズレが生じる。
-
レトロスペクティブ（振り返り）で問題が出ない
- チームの課題がないってことは成長が止まっている？
- そもそも 何を目指して開発しているのかわからない
こうした課題に直面し、「スクラムとは何か」「なぜスクラムをするのか」を深く考えざるを得なくなりました。
スクラム実践してみて見えた課題と学び
1. スクラムの目的を忘れないこと
スクラムは単なる「開発手法」ではなく、価値を届けるためのフレームワークです。開発の仕方だけに囚われず、プロダクトの価値を中心に考え続けることが大切だと気づきました。スクラムに固執する必要はなく、チームに合った方法があれば柔軟に変えていくこともありなのかなと思います。
2. チームが向かう方向の明確化
プロダクトの方向性や目標が明確でなければ、チームとして何を達成すべきかわからなくなります。事業部と開発チームが認識を合わせ、「どこに向かっているのか」を共有することで、タスクに対する納得感やモチベーションが生まれることを学びました。
3. チームの成長を継続的にサポートする
チームの成長は一度で達成できるものではありません。Four Keysや他の指標を活用してチームの状態を可視化し、振り返りで課題を一つずつ解決していくことで継続的に成長し続けるチームを目指すことが重要だと学びました。
これから実践していくこと
1. アジャイル・スクラムの浸透
事業部や開発組織全体にアジャイルな文化を根付かせ、変化に適応しやすい組織へと進化させる。
2. プロダクトチームでインセプションデッキを行う
プロダクトの方向性や目指すべきゴールをチーム全体で明確化し、共通の認識を持つことで開発の軸を作る。さらにチーム間、事業部との連携を円滑にしていきたいと考えています。
3. チーム状態の可視化
チームの状態を把握し、課題を見える化することで、改善の取り組みを効果的に進める。Four Keysの指標を活用してチーム状態の可視化を行う。
おわりに：スクラムは形ではなく価値を生み出すためにある
スクラムは「型に従うもの」ではなく、「価値を生み出すための手段」だと思います。組織やチームが直面している課題に柔軟に対応し、成長を支える仕組みだと考えています。
今後、プロダクトチーム、そして組織全体でアジャイルな文化を浸透させ、チームと個人の成長を促進しながら競争力を高めていけたらと思います。
最後まで読んでいただき、ありがとうございました。