こんにちは。 Opt Tachnologies の @atsfour です。
Qiitaには初めての投稿になりますが、今回はとあるプロダクトでスクラムを始めてみたことと今後について、ポエムっぽいのを書いてみようと思います。
きっかけは？
Opt Technologies は4月に発足し、自社でプロダクト開発を進めるべく、エンジニアを集めたり制度を整えたりして来ました。もともと作りたいプロダクトは多数あり、それを企画するビジネス側の部署はすでに機能している状態でした。
2016年7月を目標にリリースしようとしているプロダクトがあり、 Opt Technologies に在籍しているエンジニアの半分ぐらいがそのプロダクトに関わっている状態で、なんやかんやありつつもリリース（ちょっと延びた）しました。
発足後まもないタイミングでの開発ということもあり、割と時間をかけて振り返り会をやったところ、開発者と企画者のコミュニケーション不足が課題であるという意見が多数出ました。
- 工数の見積もりが甘くリスケが発生した
- 動作確認のやり方が確立されてなく、後になって要改修となることが多々あった
- ビジネス側がそれほど重視していない機能の実装難度が高いなど、うまくすれば時間を節約できる部分があった
- 仕様の共有がうまくできてなかった
などなど。
開発者、ビジネス担当者ともにスクラムの経験がない中で SCRUM BOOT CAMP THE BOOK などを読みつつ、とりあえずコミュニケーション不足は解消できるだろう、と始めた感じです
どんな体制？
リリース後に追加開発したい機能もたくさんあり、既存機能の改修やパフォーマンス改善といった要請がありつつ...ということで、以下のような体制に落ち着きました。
- 機能改善とバグFIXを担当する
Kaizenチーム (PO + SM + 4名)- POはビジネス担当者から
- スプリント期間は1週間
- ストーリーポイントの見積もりはブロダクトバックログ単位
- 追加機能を担当する
Nextチーム (PO + SM + 4名)- POはビジネス担当者から
- スプリント期間は2週間
- ストーリーポイントは スプリントバックログ単位
- インフラ整備を担当する
Infraチーム (PO + SM + 3名)- POは開発担当者から
- スプリント期間は2週間
- ストーリーポイントは スプリントバックログ単位
「ユーザーストーリー」の意図を考えると、スプリントバックログ単位での見積もりは邪道か？とも思いましたが、大きな追加機能だとスプリント期間内に開発が完了しないものもあり、かと言って初期からスプリント期間を伸ばすと重要な 振り返り の頻度が下がることも考えてこんな感じに。
やってみてどうよ？
- もともとフラットな組織ではあったが、開発メンバーのオーナーシップが向上して自主性が高まった実感
- 機能実現のためにタスクブレイクする作業にビジネスメンバーも関わることになり、 進捗状況への合意感 か向上した
- コミュニケーションのためのコスト増加し 手を動かせないと感じる時間 は増えた
- 開発段階での仕様変更の相談が 開発者側から 発生しやすくなり、工数の削減や手戻りの減少がみられた
- 現場主導でスクラム本読書会などの活動も活性化
- 開発とそれ以外の社内で必要な活動とで時間配分を可視化する動き
ベロシティ計測をそこまで重視していないこともあって、「本当に開発が速くなったか」は未知数な部分がありますが、全体としては やってよかった です！
今後は？
全員が手探りな中で「本当のスクラム」から乖離しているんじゃないか？という感じはずっと感じながら進めています。
年末の課題図書として スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本- を読み、スクラム導入そのものに対する振り返りをしていき、よりよいチームをつくるべく邁進していきます。