株式会社スマレジのエンジニア、yushiです。
ブログ3本目です。
SCRUM勉強会の第2回が実施されたのですが、今回は前回以上に有意義な会となりました！
勉強会について
株式会社スマレジでは、現在スクラム勉強会を週１開催しています。
勉強会の内容は、「SCRUM BOOT CAMP THE BOOK【増補改訂版】」という書籍の読書会です。
勉強会について、詳しくは6/14の記事で紹介しています。
第2回「実践編①」の感想
今回は実践編のScene No.00〜No.05 が対象でした。
ざっと内容を列挙すると、こんな感じです。
また、スマレジにあるいくつかの開発チームのうち一つではすでに半年ほどスクラムを導入しており、そのチームから興味深い話を色々聞くことができました。
今回も、特に気になったことや勉強会で話題になったことなどを紹介します。
※ スクラム自体の具体的な内容は書籍や公式サイト（https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf）などを参照ください
自社サービスにおけるスクラム
スクラムでは、「決まった期間・工数の中でより良いものを作る」ということを一つの目標としており、スケジュールに関する話題が多くいように思います。一方スマレジのような会社で扱う自社サービスにおいては、決まった期間で開発するというよりは、長期にわたって改善を継続する、という性質の開発を行います。そのため、我々の開発においてはスクラムは適さないのでは？ という疑問を抱きました。
勉強会内で上記の質問をしてみたところ、下記のようなことを聞けたり、気づくことができました。
- スクラムでは、全員で課題や情報を共有したり振り返り・改善を行えるなど様々な利点があり、スケジュール管理だけが目的ではない
- 自社サービスと言えど、経営や営業などの立場ではスケジュールが重要になる
- とは言え、プロジェクトでの開発に比べると大雑把な見積もりやスケジュールを大雑把に扱ってもいいかもしれない？
- むしろ、スクラムでの見積もり...ストーリーポイントは、ある程度大雑把に見積もりれることが利点である。
こうやって色々な意見を聞けたり、話し合いながら新たな発見ができるのは勉強会の醍醐味だなと感じます。
プロダクトバックログを通した情報共有
スクラムでは、プロダクトバックログの洗い出しや見積もりを全メンバーで行なっていきます。
プロダクトオーナーや経験値の高い人で行えばいいようにも思いますが、スクラムの中でもかなり重要なルールかもしれません。
普段の開発を思い返してみると、レビュー時点で他のメンバーが検討漏れに気づいたり、一部のメンバーしか修正が入れられない機能ができたり、他のメンバーの作業と重複や衝突したり、といったことが起きがちですが、それを事前に回避できます。
また、システムの全体像や向かっている方法が見えていない経験値の少ないメンバーほど、心理的にも不安を感じたり連携しづらくなってしまったりするんですよね。
開発チームでの、スクラム導入
今回の勉強会を通じて、僕の開発チームでもスクラムを取り入れていくことが決まりました！
といっても、できることから少しずつ導入する予定ですし、うまくいかずにすぐ頓挫ということもありうると思いますが...。フランクに色々試せるのはうちのチームの良いところです。
今後のブログで導入の様子を紹介できたらと思っています。
総括
今回の勉強会は、気づきや学びも多く、実際の開発にも繋がることになり、とても有意義なものになりました。
それをもっと上手にブログで伝えることができればいいんですが...。
しかし、ブログの題材を考えながら生活することで、気づきや積極性が増しているように思います。
何はともあれ先ずは継続。
