![見出し画像](https://assets.st-note.com/production/uploads/images/124664331/rectangle_large_type_2_cc2c455439ea0b661de34c867bc5218f.png?width=1200)
結局スクラムは我々に何をもたらしてくれたのか。
スクラムマスター Advend Calender 2023の16日目の記事です!
スクラムマスター Advent Calendar 2023 - Adventar
フリーランスとして数々の案件に関わり、エンジニアとして、スクラムやLeSS案件に関わったことや、専業スクラムマスターとして、幾つかの開発チームのスクラム導入などをやらせてもらって、スクラムとかスクラムマスターに関する自分なりの考えを書いていこうと思います。これは僕の経験からくる解釈であり、なので世の中のスクラムマスターとの解釈とは全然別かもしれない点はご承知おきください。
スクラムはプロジェクト状況を明確にする
スクラムやってて良かったと感じたのはチームでプロジェクトの見通しを立てる時に非常に便利なフレームワークだということですね。プロダクトオーナーと開発チームとで、プロダクトゴールに向けて、どのプロダクトバックログアイテムを消化していくか、その完了条件は何か、ベロシティを元にどれくらいの時期にリリースできそうか、そこを目指すためのリスクは何か、と定期的にセレモニーを通じで議論を重ねて話すので、プロジェクトの状況を把握しやすい点が非常に有用だといつも感じています。そういうプロジェクトの状況や見立てがわからない状態だと、根拠のない〆切駆動で進めざるを得ないので炎上しやすかったなぁと経験上思います。スクラムやっていると絶対に炎上しないかと言われれば、決してそんなことはないですが、少なくともプロジェクトマネジメントが苦手なチームは、その仕組みに乗っかるだけである程度、プロジェクトの見通しが立てられるのではないかと思います。
ただし、難しいポイントもあると思っていて、上記の見立てはそこまで精度が高くないです。ベロシティも普通はきっちり安定することは稀なので、特定の期日までにリリースが間に合うかどうかの観点でベロシティを使うとその精度の悪さに非常に苦労します。精度の悪い指標を使っているにも関わらず、正確な完了予定日を算出しようとするチームをいくつも見てきました。もう一点はチーム内できちんと論点整理して議論できないと、セレモニーの議論で長時間溶かすことが多し、開発時間がかなり圧迫されやすいと思います。
スクラムはチームの可用性を上げる
開発チームのメンバー同士である程度同じスキルセットを持てるようスキルの平準化にスクラムを採用するのはありだと思いました。チームメンバーがプロダクトバックログアイテム(以下、PBI)をどのように完了させるかをプランニングの段階で設計交えて話すことはメンバー間の認識が早期に合い、レビューの手戻りリスクも減らせますし、メンバーのスキルシェアにもなります。
ここも難しいポイントがあると思っていて、エースエンジニアが一人でチームを引っ張るようなケースでは、エースが決めた方針に大体は事が進むので、若手の発言機会がどんどん奪われがちです。若手はエースの考え方を知ることができますが、若手自身が考えて、他人に設計を理解してもらう経験を常に奪われるので、もったいないです。ここは失敗込みで設計などを考えるタスクを若手にどんどん任せるなど、プランニングでのタスクのアサインを工夫すると良いかもしれません。
以上、スクラムは我々に何をもたらしてくれたのかを自分の経験ベースで書きました。
もっとドロドロした事書こうかと思ったんですが、それはスクラムマスター闇アドベントカレンダーで葬ろうかと思います。
それではまた!
この記事が気に入ったらサポートをしてみませんか?