リリース内容を小さくしたらいろんなメリットがあった話

こんにちは。Nonです。今回はリリースする内容を小さくしたら色々なメリットがあった話をしようと思います。

とは言っても、すでにdevsOpsやマイクロサービスが浸透してきているので、リリース内容が小さい方が良いというのは知っているかもしれません。

ここでは、やっぱりやってよかったよねという話にしていきたいと思っています。

1. リリースを小さくしたらバグが減った

リリースを小さくするということは実装する機能の数が減るということです。ということは、制限時間内に（納期までに）開発者が向けるべき関心事が減るということですね。

正直、この内容をシェアしたくてこの記事を書いたまであります。

リリースが小さくなったので、リリースまでの納期は短くなります。しかし、自分が注力すべき内容が小さいので、その全てに全力を注ぐ事ができます。そのおかげで、明らかに今までのコードより品質が高くなりました。QAチームからのフィードバックも減り、実装コストだけではなくて全体のコストも減りました。

やはりバグ原因での手戻りが少ないとストレスも減って進捗がいい方向に向いていくことを実感することができました。

2. リリースを小さくしたらマネジメントしやすくなった

１と同様に、関心事が減るので、把握すべき進捗の内容が減りました。おかげで今までおざなりになっていたプロジェクトの進捗の把握もかなりしっかりできて、ほぼ計画どおりのプロセスを踏むことができました。

（この案件では私が実装兼PMみたいな感じ）

こうなると、マネジメントする側にもかなりのメリットがアルのではないでしょうか？進捗管理という事務作業が一気に減ることになりますんので、本来PMがすべき真の意味のプロジェクトマネジメントを遂行することができます。

追記するとPMはプロジェクトの進捗管理をするだけの役職ではないと個人的に思っています。

このことに関しては賛否あるかもしれません。
私もPMについてしっかりと勉強できているわけではないので、おかしな点があるかもしれません。簡単に書くとPMは

• POから欲しいと言われた機能を吟味し、取捨選択する
• 機能についてメンバーに割り当てる
  • 機能から更に分割されるであろうタスクはメンバーが決めるもの
• 機能について終了日のあたりをつけ、QAとの連携をとる
• リリースにあたって他のプロダクトとの影響について調査する

この辺ではないかと思っています。

何やら一般的にはスケジュールばかりに目が行っていますが、どう考えてもそれは副産物で、メンバーとの折衝、他のチームとの折衝こそがPMの本来の仕事のはずです。（だからコミュ力が求められるのだと思います。）

上述した内容を遂行した結果、たまたま進捗管理をしていたというだけだと思います。

逆に言えば、他の影響範囲との摩擦がなければリリース日なんて「完成した日」になると思ってます。

3. リリースを小さくしたらスピードが上がった（たくさんのピリオドを打てる）

マラソンを走るスタイルで、ダラダラと開発をしていたのが、パッと開発してストップ、パッと開発してストップ、の連続になりました。メリハリが効いてピリオドも明確に打てる。何かあったときのトラブルにも強い印象になりました。

ピリオドを打てるというのはとても大きくて、終わったら前回の反省をすることができます。対して、長ーいスパンで開発すると、その途中で反省会をしてもあまり意味がないように思えます（経験）。

長ーいこと開発を続けるよりも、キチンとピリオドを打って、終わったよということを表明できるのはメンタル的にも優しい気がしました。

最後に

リリース内容が大砲の弾のように大きくて必死こいて弾を運んで、外したらOUT。みたいなのより、リリース内容は小さくして気軽にパパパパっと打てるサブマシンガン的な手法の方が手軽でいいです。

小さい分、何回も繰り返してリリースすればいいですし。

この取り組みは今後も続けていきたいです。

今回は私の主観が多めでした。

次回は何書こうかまだ決めてないです。でも記事にはします。

その時はよしなに。

.