マイクロコミットのススメ - プロダクト開発編

まえがき

今回は前回書いたマイクロコミットのススメ - 開発編

に続き
もう少し大きな話をしてみたいと思います。
プロダクト開発の場面でのマイクロコミットについてです。
ちょっと前まではプロダクト開発というと
ウォーターフォール開発で用件定義から始まり、
仕様をバシッと決めて
開発とテストとリリースと、といった感じに上流工程から下流に仕事が流れる仕組みの開発が主流でした。
このウォーターフォール開発自体をディスるわけではないですが
今現在、社会の仕組みや流行やサービスの移り変わりが早い中で
ウォーターフォール開発でやってしまっていると
1年前2年前の要件で今リリースしてユーザに喜んでもらえるの？？
という話になってしまいます。
対してマイクロコミットという考え方ではどのように進めていくのか？
というのを解説してみたいと思います。

アジャイル開発という名のマイクロコミット

マイクロコミットに近しい考え方の開発手法としてアジャイル開発
というのがあります。

アジャイル開発とは

リリース計画を立てて
1〜2週間でイテレーションを回して小さい単位で機能や改修をリリースしていくという開発手法です。
この中で、リリース計画とは
ざっくりな仕様、要求を決めたら細かいところは決めずに開発に取り掛かってしまい、途中で仕様変更が入ってもすぐに対応できる環境を作る作業になります。

イテレーションとは

イテレーションとは、反復という意味で
「計画」→「設計」→「実装」→「テスト」というサイクルを
1週間〜2週間で回していく事になります。

アジャイル開発とマイクロコミット

このアジャイル開発とマイクロコミットというのはとても相性が良くて
自然と出来ているケースもあるかと思います。
具体的にはどのように相性が良いのでしょうか。
アジャイル開発の場合、
サイクルが1〜2週間で実施できるサイズにタスクを分割する
というのをリリース計画の中で検討する事になります。
その際にマイクロコミットでの考え方の一つで
粒度がありますが、
極小の粒度でタスク分割をする事でアジャイル開発のサイクルを回すのが容易になります。
「この修正をするには、まずはコードのリファクタリングが必要です！」
といった場合も、このリファクタリングをするというタスクを独立させてしまいます。

メリットデメリット

メリット

この粒度を細かくするというのはメンバーにとって大きなメリットがあります。
タスクが小さいので、1サイクル内でこなすタスク数が多く積み上がっていきます。
積み上がるということはメンバーの達成感に繋がり、モチベーションが持続する事になります。
（全員がこれでモチベーションが上がる訳ではないですが）

デメリット

タスクの粒度を細かくするということで、メンバーは目の前のタスクをこなすことに集中することは出来るのですが
より大きな視点でプロダクトの方向性を見つめるという事が難しくなります。
本来、このプロダクトはどっちに向かうんだっけ？？
というのがブレてしまったりもします。

それでもマイクロコミットが良い理由

前回の記事でも書いたことと重複する内容ではあるのですが
大きな機能を一気にリリースすることはインパクトは大きく出せますが、逆にリスクになり得る事もあります。
タスクの粒度を小さくすることで細かくユーザに機能を提供でき、それによってフィードバックも細かく受け取れるので、より良い改善が続けられる仕組みとなっています。
プロダクトの方向性がブレようとも
そのブレた先に新しいプロダクトの未来が見える事もあります。
マイクロコミットのススメ - 開発編でも言及しましたが、ファットコミットによる驚きを最小にする事で開発者、ユーザともにストレスなく共に歩んでいく事が出来るのではないかと考えます。