はじめに

本記事は「アジャイルスクラム開発を行う前に知っておくべき事①」の続きです。
前はアジャイル開発の内容中心に記載しましたので、ここからはスクラム開発を中心にお話しをしたいと思います。

スクラム開発とは？

スクラム開発とは、簡単に言えばチーム一丸となってプロジェクトを進めていく開発手法です。
ラグビーでスクラムを組んで相手にぶつかっていくのと同じようなイメージです。

スクラム開発では、役割別に以下のように呼びます。

プロダクトオーナー(PO)
→開発プロダクトのオーナー。顧客。
スクラムマスター(SM)
→スクラムチーム全体のコーチ
開発メンバー
→プロダクトオーナーとスクラムマスターを除いた、チームメンバー全員

スクラム開発で重要なのは、POもチームの一員であるという事と、全員がフラットな関係性であるという所です。
なのでスクラム開発以外でよくある、顧客→PM→PL→開発メンバーみたいな上下関係はありません。
(実際はアリアリの場合が多いですが。。。)

スクラム開発でのタスクの作り方

スクラム開発では、ユーザーストーリー単位でタスクを作成するのは前項でお話ししましたが、
もう少し具体的にお話ししようと思います。

スクラム開発では、タスクを以下のように分割します。

Epic
→一番大きな括り。大きな目標をEpicとして定義する。
Future
→Epicをもう少し分割した単位。正直ここらへんの分け方はプロジェクトによると思われる。
Product Backlog Item
→実際の作業単位。もう少し細かく言うと、POが確認を行えるタスク単位。(画面の機能等)
Sprint Backlog Item
→開発者が作業を行う単位。開発、設計、テスト等もこの部分で分割される。

プロダクトオーナー(PO)の役割

POの役割は、プロダクトの機能や要件などを纏めてプロダクトバックログを作成し、
何を優先して進めていくのか等の全体的な調整を行う事です。

POがエンドユーザでない場合は、エンドユーザとの要件調整なども役割の一部となってきます。

スクラムマスター(SM)の役割

一言で言うと、プロダクトを進めていく上でチームの障害を取り除く事が役割となります。
基本的には開発等には参加せず、スクラムについてのコーチングや、雑用までなんでもやります。

私が参加しているチームの実例では、

HDMIケーブルが欲しいんだけど。
〇〇さんとの打ち合わせ調整お願い。
こういう場合に、スクラム的にはどういう考え方をすべきなのか

等々、チームに起こるプロダクトを遂行するにあたって障害となりえる問題を解決するのも仕事の一部となっています。

上記の事から、スクラムマスターはチーム内で誰よりもスクラムを熟知している必要があると言われています。
(プロダクトオーナーよりも熟知している必要がある)

終わりに

いかがでしたでしょうか。

今回の記事は、特にアジャイルスクラム開発をやったことがなく、イメージが湧きにくい方向けの説明でした。
正直まだまだ書くべき事はたくさんあるのですが、全てを説明していると恐らく１０ページ以上になってしまうので。。。

私が今回のスクラムアジャイル開発で感じたのは、やはりどちらの開発も一長一短があり、
「どっちの開発手法が優れている！」ではなく、プロジェクトの状況に応じて「今回はこの開発手法で行こう！」「基本はウォーターフォールだが、アジャイルスクラムのここは良いので取り入れよう」といった臨機応変に対応することが大切だと思いました。

最初は新しい事で抵抗があるかもしれませんが、
より良い開発ライフを楽しむためにも、一度は経験してみると良いと思います。