はじめに
スクラム初心者の私がスクラムを一年ほど経験して、大事にしたいなと思ったことをまとめさせていただきました。
よければいいねをよろしくお願いいたします！
アジャイル開発、スクラムとは
多くの方が様々な形でまとめていらっしゃいますので、こちらでは簡潔に紹介します。
まず、アジャイル開発とは、短い期間で実装とテストを繰り返して開発する方法です。ウォーターフォール型開発とよく比較される開発スタイルです。
スクラムとは、アジャイル開発の一つのフレームワークです。スプリントという期間の中でゴールを定めて、小さくかつ素早く開発を繰り返します。スクラムを行うチームは、この後説明する3つの役割を持つ、6〜8名程度で構成されることが一般的です。
スクラムには、具体的なプロセスや手順があるわけではありません。次のルールのみ定められています。
- 3つの役割
- 5つのイベント
- 3つの成果物
3つの役割
- プロダクトオーナー（PO）
プロダクトのゴールを明確にし、プロダクトの価値を最大化させる
プロダクトバックログの所有者 - 開発者
実際に作業を進め、価値提供をする
スプリントバックログの所有者 - スクラムマスター（SM）
スクラムの各イベントを円滑に進める
5つのイベント
- スプリント
開発期間の単位です。期間は、週単位で1週間〜4週間のいずれかです。 - スプリントプランニング
スプリントの中で何ができるかを決め、どうやって達成していくかを話し合います。決まったスプリント期間に対し、適切な時間が設けられます。例えば1週間のスプリントの場合、このイベントは1〜2時間を要します。 - デイリースクラム
作業開始時に15分ほど使って、進捗や問題の共有、その日のゴール設定を行います。「朝会」として実施することがあります。 - スプリントレビュー
インクリメント（成果物）の確認をチーム全体で行い、フィードバックを得ます。POのOKがでたら、成果物の価値が十分ということになります。 - レトロスペクティブ
チームがスプリント内の動き方を見直し、改善するためにトライすることを決めます。スプリントプランニング同様、例えば1週間のスプリントの場合、このイベントは30分〜1時間を要します。
3つの成果物
- プロダクトバックログ
これから進めていく開発（プロダクト）が優先順位で並べられたもの - スプリントバックログ
開発者がスプリントの範囲内で開発を完了させるための計画 - インクリメント（成果物）
スプリントで完了したもの、つまり開発やテストが終わり価値提供できるもの
つまりスクラムでは、3つの役割のいずれかを担う、6〜8人程度のチームで行う開発スタイルで、3つの成果物を作成・管理し、5つのイベントに沿って開発を進めていく、ということになります。
大事なこと
それでは本題です。
自分がスクラムを約1年間経験して学んだ、大切にしたいなと思っていることを紹介します。
1. 開発者は全部やる
開発者の中には、フロントが得意だけどサーバサイドはさっぱりという人や、インフラが強い人と、何かに特化しているということが多いと思います。ただ、スクラムという開発においては機能横断的になんでも考えていくことが重要になります。
短期間で開発しプロダクトを提供するためには、特定のスキルだけでなく様々な角度から物事を考え素早く実践していくことが必要です。チーム全体で、価値提供のために必要なスキルを全て持っていれば最低限良いですが、スクラムチームの一員になる際は、個人でも色々な角度から考え開発を進められるようになるとより良いと思います。
そのために、自分はまず主体的になってタスクをこなすようにしています。
2. 透明性を持たせる
チームで担当を持って開発を進めるので、他の人の作業やプロダクト全体の進捗は細かく把握していくことが大事です。
進捗が見えないと、気づかないうちにバグが発生し、遅れる原因になるかもしれません。実際自分が経験した中で、進捗が悪くずるずる開発してしまったり、黙々と開発してしまったりした際に遅れる傾向にありました。これまでに、早く共有して課題解決するように動けば良かったと後悔したことは割とあります。
3. コミュニケーション
チームで開発する上で、コミュニケーションを取ることは必須になります。作業の進捗や成果を共有する時、問題があった時に他のメンバーに助けを求める時、POにインクリメントをレビューいただく時、などコミュニケーションを取る機会は多くあります。
また、自分が何を考えて作業をしているかを共有することで、開発が効率的に進むことにつながります。これは先述の透明性を持たせることにもつながると思います。
正直、スクラム開発で大切なことを聞かれたら、私は即座に「コミュニケーション」と答えます。コミュニケーションが上手くとれないと、進捗や開発環境などで様々な障害が発生し、スクラムは機能しないと思うからです。
4. 守破離
ビジネスの現場で聞くことがある言葉です。元々は千利休の詠んだ句から来ています。
まずは『守』として、徹底してスクラムのフレームワークの言っていることを守りましょう。例えば、「POとSMの役割を兼任する」、「リリースを優先するため、振り返りは次回まとめて実施する」は、スクラムの守に反します。役割は一人ひとつにし、必要なイベントを確実に実施し、成果物を毎回のスプリントで必ず出すことが、まずは大事です。
スクラムのフレームワークに則ってチームが軌道に乗ってきたら、フレームワークの範囲内でチームがより効率的に作業できるように『破』ったり『離』れたりすることは問題ないと思います。
5. 心理的安全性
ここまで色々紹介してきましたが、これらはチームが穏やかな雰囲気でのびのびと開発ができる環境でないと難しいと思います。スクラムをやっていて自分の思いがフランクに話せないと感じる場合は、SMに相談したり他愛のない話をしたりして、話しやすい環境を作ることが良いと思います。
私はたまにプライベートの話を業務中に差し込んで、話しやすい環境を作るようにしています。
おわりに
スクラムというフレームワークは、個人的には好きです。スピーディに価値提供ができるし、どんどんでき上がっているということを継続的に実感できるからです。また、スクラムはシンプルである故に、エンジニアのチームだけでなく、営業などにも活用できます。
仕事の進め方の一つとして、ぜひスクラムというフレームワークを選択肢にしてみることはいかがでしょうか？
また、興味を持ってくださった方は、ぜひスクラムガイド（日本語版）を読んで理解を深めることをオススメいたします。
最後まで読んでいただき、ありがとうございました！！