こんにちは、こんばんは、kubotak(@kubotak_public)です。
昨年末より弊社では「真のスクラム」という名のスクラム開発を実施しています。
今までは「なんちゃってスクラム」というわけではないんですが、スクラム開発のエッセンスを多少取り入れたような今にして思えば全くスクラム開発ではないなにかをやっていました。
私はスクラムマスターではなく「真のスクラム」を熱く語れるわけではないのでメンバー視点で「真のスクラム」になった結果何が変わったのかを紹介したいと思います。
スプリントが2週間から1週間に
以前は1スプリントを2週間として実行していました。
これを1週間と短くし、月曜日にスプリント計画、金曜日にスプリントレビューとレトロスペクティブを行うように変わりました。
私個人としては短くなったことで単純に忙しないな！と思うのと、開発時間の多くは火・水・木曜日になり余計に短いと感じます。
また、短くなったことで以前に比べるとスプリント全体で完了する成果物の大きさが小さく・細かくなりました。
小さいサイクルを回してすぐに出すことでよりアジャイルな開発になったのかなと思います。
スプリント計画をメンバー全員で実施
以前はPO及び一部のメンバーでスプリント計画を実施し、タスクのポイントなどをつけていました。
これを全員で実施するように変更しました。
プランニングポーカーを用いてデザイナー含めたスクラムメンバー全員でタスクに対するポイントを出し合い、合議により見積もりを行っています。
これによりメンバー全員が個別のタスクの詳細を理解することができ、誰がタスクにアサインされても問題ない状態になりました。
もちろんタスク毎に向き不向き、得意不得意があるかもしれませんが全員で見積もり行うことで平均化されますし、そのタスクに必要な情報の詳細を持っている人が明確になるので聞きに行くということも可能になります。
今までは一部のメンバーしか情報を共有できていなかった部分も、透明性が上がったといえると思います。
タスクにユーザーストーリーとACを追加
タスクにはユーザーストーリーが追加され、なぜ、誰のためにその実装が必要なのかを明文化しました。
また、ユーザーストーリーとともにAC（acceptance criteria）も追加し、そのタスクはどういう状態であればユーザーストーリーが完了になるかも明文化されました。
この2つは作業者としては非常に重要で、「なぜわたしたちはこのプロダクトを作っているのか」が明確化されて納得感を持ってタスクに取り組めます。
また、何を持ってこれは完成と言えるのかも記載されているので品質の担保ができます。
そしてこれは自動テストのストーリーとしても役立っています。
※DoD（完了の定義）はタスク毎ではなく全体の完了の定義としているため、ここではACを取り上げています。（完了と受け入れ基準の定義 Definition of Done vs Acceptance Criteria）
スプリントレビューを実施
PO以外にも、タスクにおけるユーザーストーリーから影響がある人を呼んでそのスプリントで完成したプロダクトを見たり触ったりしてもらうような時間を作りました。
このとき、「顧客が本当に欲しかったもの」やその顧客に近いCSの声などをフィードバックとしてもらうことができるようになりました。
これにより、「私達が作っていたものは間違っていなかったんだ」という自信を持った上でリリースに挑むことができます。
もちろん実際にはデータを元にその追加機能の優劣は後から判明することとは思いますが、少なくとも「この機能使われないのでは？ほんとに喜ばれるのか？」という不安を払拭し、モチベーション高く開発に挑める良い施策だと思っています。
まとめ
細かい話などはおそらくスクラムマスターから今後紹介されることと思いますが、現在スクラムメンバーとしてスクラム開発を実施して良いなと思った点をあげてみました。
正直最初は新しい用語や取り組みによってやや混乱を覚え「これホントに良い開発できるのか？」と思いましたが初回のスプリントレビューで払拭された感じがします。
スクラム開発によって顧客に向き合った開発ができるようになったんだと実感しています。
さいごに
まだまだスクラム開発駆け出しの弊社ですが、もっと改善したい、一緒にスクラム開発したい、と思った方はぜひ応募ください。
ちなみに、データエンジニアや機械学習エンジニアも積極採用中ですのでお声がけください。
