本記事では、これまでウォーターフォール開発しか経験してこなかった私が、スクラム開発を実際にやってみて感じたことをまとめています。
所感
実際にやってみてどうだったかというと、多少の苦労はあったものの、想像していたより苦労せずこなすことができたと思いました。
チーム内にスクラム開発を経験したことがあるメンバが誰もいないという中で取り組んだものの、なんとかプロジェクトを無事成功させることができたため、手探りでもやることができる開発手法だと感じました。
はじめはスクラム開発のルールを覚えたり、ルール通りにミーティングをこなすのは大変そうと感じましたし、メンバにスクラム開発のルール通りに行動してもらうのには多少苦労しました。
しかし何度かスプリントを繰り返すことでスクラムのイベントが習慣となり、開発を無事軌道に乗せることができました。
以下、具体的に良かった点と苦労した点についてまとめました。
良かった点
良かった点は主に2つあります。
稼働調整のしやすさ
スクラム開発で最も有効だと感じたのは、スプリントプランニングを定期的に実行するという点です。
スプリントプランニングを定期的に行うことによって、稼働が高いメンバのタスクを他のメンバに振ってメンバの稼働バランス調整をしたり、短納期案件の担当を急遽選抜して選んだりといった作業を、確実に行うことができました。これはプランニングの度にメンバにヒアリングを行い、正直に忙しさ・大変さを申告してもらったからことできたことだと思います。
そして、プランニングは定期的に必ず実行するイベントのため、忙しいメンバのフォローをその場で確実に行うことができます。
メンバ全員でタスクの相談しながら進めることができるため、メンバが不公平さを感じにくく、納得してタスクの決定をすることができた点が、スクラム開発を導入してよかったところの一つです。
要件変更に柔軟に対応できる体制
これはアジャイル開発のメリットになりますが、次々と来る要件変更にすぐ対応できるような開発方法・体制は非常に有効でした。
これまで経験してきたウォーターフォール開発の場合は、要件変更のたびにそれまでの開発をすべて見直したり、それに伴いリリースが大幅に遅れてしまうという点がありました。
要件変更が頻発することが予想できる案件においては、柔軟に対応できるという点でスクラム開発は有効だと感じました。
難しかった・苦労した点
難しかった・苦労した点は主に3つあります。苦労したことも多かったため、良かったことよりこちらの方が多くなってしまいました。
バックログの設定
私が所属したプロジェクトでは1スプリントを2週間としていました。
2週間という設定は問題なかったのですが、1スプリント内、つまり2週間で完了するスプリントバックログの設定が難しく、設定したスプリントバックログの完了が2週間をオーバーしてしまうということが度々発生しました。
スプリントバックログは1スプリントで必ず終わるものを設定するというのがスクラム開発のルールですが、先方の対応待ちや、他に優先すべきタスクの発生などの様々な理由で終わらず、次スプリントに跨いでしまうというケースが何度もありました。
2週間で終わるスプリントバックログを設定するためには、やるべきタスクを細かく洗い出す必要があります。
洗い出したタスクのそれぞれの作業がどれくらい時間がかかるかという見込みが明確になっていない開発初期の時点では、スプリントバックログの設定はなかなか難しいと感じました。
スクラムイベントの形骸化
特に形骸化を感じたのは開発末期のスプリントプランニング、開発後期のスプリントレトロスペクティブです。
やるべきバックログが積みあがっている状態でのスプリントプランニングは非常に有意義でしたが、もうやるべきことが各メンバに割り振られており、あとは手を動かすだけという状態になった開発末期においては、スプリントプランニングの時間を作らなくてもプロジェクトが進行する状態になりました。
同様に、プロジェクトがまだ軌道に乗っていない状態でのスプリントレトロスペクティブは、様々な意見が出たため、より良いチーム作りのための有意義な時間となっていました。しかし開発後半になりそれも落ち着いてくると、プロジェクト内で見直すべき点もかなり少なくなり、コメントもほとんど出てこなくなってしまいました。
これらに関してはある程度は仕方のないことかと思いますし、逆に考えると、反省や改善点が特に出ないほど、日々チーム内でコミュニケーションをとって問題解決できていたという見方もできると思います。
長期的なスケジュール管理の難しさ
スプリントプランニングで各スプリントにてこなすタスクを計画、および管理することは難しくありませんでしたが、長期的な、全体俯瞰をしたプロジェクト計画を立てていくことが難しかったです。
私が所属したプロジェクトでは「1年以内に〇個の環境を用意する」とう形の案件だったため、確実に1年以内にそれらを終わらせるために帳尻を合わせる必要がありました。
そのため、各スプリント計画だけでなく、長期的なWBSも用意する必要があり、このスプリントで何を終わらせる必要があるかの逆算など、スケジュール進捗のコントロールが非常に難しかったです。
おわりに
難しかった点の方が長くなってしまいましたが、スクラム開発はやってよかったと思いますし、より良いチーム作りに生かせる要素がたくさんある開発手法であると感じています。
最もそれを感じたのは、この開発手法はとにかくコミュニケーションを重視しているところです。
私が参加したプロジェクトは全員フルリモートでの勤務だったため、はじめはなかなかコミュニケーションをとるのが難しいという状況でした。しかし日々のデイリースクラム等によって毎日全員の声を聞くことによって、その場で相談や稼働調整ができたりと、リモートワークでも全員が声を上げやすい環境が整っていきました。
開発手法通りに開発を進めていくことで、全員でゴールに向かって進んでいく環境を作りやすいと感じました。
スクラム開発は有効な開発手法の一つですが、すでに公開されている他の記事にも書いた通り、メリット・デメリットも存在します。それを把握したうえで、適切な開発手法は何なのかを慎重に見極めていく必要があると思います。
