スクラム開発手法を用いたプロダクト開発事例について

こんにちは。プロアクシアコンサルティングでオープンソリューション事業部に所属しています N.S です。
今日は、アジャイル開発におけるスクラムの実践事例について紹介していきたいと思います。

プロアクシアでの役割とこれまでの経験を教えてください

社会人になった際は別の会社で勤務しておりましたが、プロアクシアコンサルティングの前身の会社に転職して以降は、プロアクシアコンサルティング創立の段階から勤務しています。

コンピューターに携わり始めた当初から Web システムでのプログラム開発を中心に担当しています。
特に、製造系企業の社内業務システムを中心に担当しており、PM 兼プログラマーとして顧客折衝や設計の段階から開発まで一貫して対応しております。

最近は Web 系の開発だけでなく、スマートフォン向けの開発にも携わっており、企業向け以外に一般ユーザー向けのアプリケーション開発も担当しています。

アジャイル開発手法とは

アジャイル開発手法は最近主流になってきている開発手法の一つで、イテレーションと呼ばれる短いサイクルで｢計画→設計→実装→テスト｣といった開発工程を機能単位の小さなサイクルで繰り返し実施しながら、開発を進めていく手法です。

ビジネス IT や新しい技術を利用した不確実性があるような開発については、トライ＆エラーでの開発が必要になってきます。
このような開発については、短いサイクルで柔軟に要望の変化に対応できるアジャイル開発手法を利用することが適しており、リスクを最小化しながら開発を進めることができます。

実際のプロジェジェクトではアジャイル開発手法をどのように活用していますか

私が参画しているプロジェクトでは、アジャイル開発手法の中でもスクラム開発手法を用いた開発を進めており、スプリントを1週間に設定して毎週確実に機能リリースを行うように運用しております。

毎週安定してリリースできるようにするために、デイリースクラムやスプリントレビューなどの取り組みはスクラム開発手法のルールに準拠するようにし、日々の取り組みを陳腐化させないように注意を行いながら取り組んでいます。

このプロジェクトでは、スクラム開発手法のルールに準拠するだけでなく、特徴的な2点の取り組みを行っています。

1点目は、週初めと週中にリファインメントの時間を設けております。

週中のリファインメントでは、次週の週初めに行うリファインメントで決める方針について事前に確認を行なうようにしております。
これは、参画しているプロジェクトがリモートでの開発のため、プロダクトオーナーを含めチーム全体での自由な会話が対面と比べて減少しがちです。このため、スプリントを円滑に進めれるために、週中に時間を確保するすることでコミュニケーションを機会を増やす取り組みをしております。

2点目は、週末に行うスプリントレトロスペクティブの時間を120分と長めに設定しており、その週のふりかえりをじっくりと行うようにしています。

ふりかえりでは、その週の活動での問題点だけを確認するのではなく、よかった点や継続して実施すべき内容についてもディスカッションを行います。
ふりかえりの中で即時対応できない課題については、アクションに設定して次週1週間かけて対応を実施するようにしております。アクションに設定する課題については、技術的な問題ではなくソフトスキルに関する問題を設定するようにし、自己学習や自己組織化を進めるための取り組みとして活動を行っています。

スクラム開発手法を成功させるために必要になる取り組み

スクラム開発手法を用いた開発では、短期のスプリントで開発を繰り返し行い、顧客の反応やニーズを確認しながらプロダクトを価値を高めるための開発を行います。

プロダクトオーナーはさまざまな顧客の反応やニーズをもとに、プロダクトゴールとプロダクトバックログアイテムを作成し、スクラムチームに正しく正確に伝える必要があります。
この際、プロダクトオーナーは短期のスプリントでの開発であることを十分に理解したうえで、実施する内容を分割したり取捨選択することがとても重要になります。

スクラム開発手法を行う際の注意点

スクラムで開発を行う場合、スプリント毎にリリースできるプロダクトを作り上げることが重要になってきます。
このためには、ベロシティ(チームが作業を進める速度)を把握し、各スプリントで開発する内容の見積もりの精度を上げていく必要があります。

開発工数の見積もりは、プロダクトバックログアイテムの作業内容を元に、プランニングポーカーの手法を利用してチーム全員で作業工数の見積もり算定します。プランニングポーカーでは、全員のポイントが一致するまで繰り返すのではなく、極端に上下でポイントに開きがない場合は、全員のポイントの平均を計算して利用するようにしています。

見積を実施する際の注意点としては、見積もりをしたポイントが 20Pt を超えるような場合は、変更の規模が大きすぎて上手く実行できない可能性が高くなるため、できるだけタスクを細分化してプロダクトバックログアイテムに落とすようにする必要があります。

スプリントプランニングでは、プロダクトバックログアイテムに設定したポイントと優先度を元に、スプリント内に開発するプロダクトバックログアイテムを選定します。
私たちのプロジェクトでは、スプリントで開発できるポイントの上限を 50Pt に設定し、プロダクトバックログアイテムを積み上げて 40Pt ぐらいの開発を割り当てるようにしてます。残りの 10Pt については、工数見積もりの誤差に対応するためのバッファとして利用していました。