はじめに
こんにちは。令和最初の記事はsts-250rrからお届けします。
私ごとですが、プロジェクトが変わり5月からアジャイル開発を行うことになりました。
アジャイル開発の中でもスクラムをやるとのことだったので、GWの期間を利用して、SCRUM BOOT CAMPの本を読んでみました。
今回は自身の頭の中の整理を記事に残しておこうと思います。
実際にやってみるのはこれからになりますので、間違いもあるかと思いますがご容赦ください。
アジャイル開発とは
アジャイル開発では、「事前にすべてを正確に予測し、計画することはできない」という前提のもと以下のような進め方を行います。
- 関係者は目的達成のためにお互いに協力しあいながら進める
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。
- 一度にまとめてではなく、少しずつくくる。そして実際に出来上がったものが求めているものであるかを頻繁に確認する。
アジャイルではおおよその全体像は明らかにした上で、重要なものやリスクの高いものを優先し、重要度の低いものは後に回すことで、要求の分析や設計に対して必要以上の時間をかけないことで開発スピードを上げていく手法です。
ユーザが求めているものを素早く提供するようなサービスに向いている手法かと思います。
スクラムとは？
スクラムはアジャイル開発の中の手法の1つで、関係者の進む方向を常に調整しながら目的を達成するため、作業、会議、成果物を定めた手法です。
あくまで仕事の進め方にフォーカスをしたものであるため、細かなルール（コーディング規約やテストの方法など）は自分たちで決める必要があります。
書籍に記載のスクラムの特徴を記載します。
スクラムの特徴
- 要求を常に順番に並び替え、その順にプロダクトを作ることで成果を最大化する
- 実現されることの価値やリスク、必要性を基準にする
- 固定の短い時間に区切って作業を進める
- 現時点の進捗や問題点を常に明らかにする
- 定期的に今進めているものが正しいのか、進め方に誤りはないのかの確認を行う
- 進め方に問題があったり、もっと良い方法があった場合にはやり方を変更する
スクラムの全体像
SCRUM BOOT CAMPの著者でもある@ryuzeeさんの図を見ていただくのが良いかと思います。
この図を見て感じたことは、1スプリントでプロダクトオーナーのレビューを受ける必要があるため、どの程度の作業ができるのかをよく把握しておかなければならないという点です。
こうなってくると、1スプリントのなかでどこまでのことができるかを決めるスプリントプランニングや、今どこまでできているかを確認するデイリースクラムが重要になってくることもうなずけます。
スクラムでの開発チームの役割
私は開発チームとしてスクラムに関わることになるので、開発チームの役割を掘り下げていきます。
開発チームの役割は以下の点です。
- リリース判断ができるプロダクトを作る
- 6名（±3名）で構成する
- 全員揃えばプロダクトを作れる
- 上下関係はない
また、開発チームは要求の分析・設計・コーディング・サーバの構築・ドキュメントの作成といったシステム開発に必要なことが全てできる必要があります。
これは各作業に個人を割り当てるというものではなく、個人が複数のことができるようになるということです。
開発チームの進め方
開発チームはプロダクトの作っていくためにスプリントを進めていくわけですが、1スプリントでどこまで作業を行うのかを決めるスプリントプランニングを実施します。
スプリントプランニングは、プロダクトオーナーを含めて何が欲しいのか、開発チームではどこまでできるのかをすり合わせる第１部。
第１部で決まったことをどのように実現するのかを開発チーム内ですり合わせる第２部で構成されています。
ここで決定したことをスプリントバックログという形でタスクの一覧を用意し、スプリントの中で実施していきます。
スプリントの進め方
スプリントを行なっていく上でのポイントですが、開発チームはスプリントプランニングの中で合意した内容を達成することに全力を尽くす必要がありますが、全てを完了することを約束するものではないということです。
全てを完了することを目的に作業をしてしまうと、不測の事態が発生したり、必要な作業を飛ばしてしまったりといった問題が発生し、「本当に欲しいもの」が作れない可能性があるためです。
この場合はプロダクトオーナーと相談し、プロダクトバックログのリストを見直したりすることで計画を調整します。
リリース判断可能
スプリントが終わった後にはリリース判断可能なプロダクトができていることが求められます。
リリース判断可能というものがどのような状態を指すものであるかを示すために完了の定義を明確にしておきます。
スプリントレビュー
スプリントの最後にプロダクトオーナーがスプリントの成果物を確認する機会です。
ここで実際に動くものをプロダクトオーナーが確認し、プロダクトバックログであげていた項目通りのものであれば作業完了となります。
想定通りのものでなかった場合には、次回のスプリントに含むなどの形でプロダクトバックログに戻します。
スプリントレトロスペクティブ（振り返り）
スプリントレビューが終わると、今回のスプリントの振り返りを行います。うまくいったことやよくなかった点を洗い出して今後のスプリントに生かしていきます。
スプリントレトロスペクティブまで完了して1スプリントとなり、プロダクトの完成まで繰り返していくことになります。
終わりに
ここまで淡々とスクラムについて書いてきましたが、最後に所感を述べて終わりたいと思います。
開発チームの役割で「全員揃えばプロダクトを作れる」というものがありましたが、実際全員が揃うことは保証できないですし、 あるキーパーソンがいないと作業が進まないような状況は「属人化」の典型ですし、望ましいものではないです。 そのような状況を改善していくために個人が複数のことができるようになる必要があると言えます。
その道のプロフェッショナルであることももちろん重要なことですが、スクラムでは幅広い知識を持った上で参加する必要がありそうです。
また、今学習した部分ではスクラムの中には「運用・保守」といった観点は除かれているように感じました。
短期間でリリースをする可能性のあるアジャイル開発において「運用・保守」に与える影響は小さいものではないと考えます。
このような点を解決する考え方としてDevOpsが生まれてきているわけなので、DevOpsの視点も考慮して開発を進めていく必要がありそうです。
ただし、まだ私はスクラムを体験していませんので間違ったことも多々記載しているかと思います。 実際のスクラムはこれからやっていくことになりますので、次回は実体験から得られたものをご紹介したいと思います。
参考
- SCRUM BOOT CAMP THE BOOK
- スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com
