実装を急ぐくらいなら、MVPでリリースすべき。
実装を急ぐくらいなら、MVPでリリースすべき。という当たり前ポエムです。
大昔、開発リソース足りないのにフル実装を目指した結果、負債的コードが残ってしかもリリースできなかった様子ありけり。
— shanon (@shanonim) 2017年6月5日
MVPは、Minimum Viable Product（必要最低限の能力を兼ね備えたプロダクト）です。
つらいパターン
- リリースがやばい。
- 実装を急ぐ。
- 「とにかく動けばええねん。」
- 技術的負債みの強いコードが残る。
- 「誰やこんなコード書いたやつ！！！😡😡」→「2ヶ月前のおれや…………..」
- 「誰やこんなコード書いたやつ！！！😡😡」→「えっ……..マジで誰……..(もうすでにいない担当者のcommit)」
- enhancement issueが重くなる
- つらい😇😇
つらい実装をしてしまう背景
MVPが判断できずにフル実装してしまう
MVPを判断できるプロダクトマネージャ、もしくはリードエンジニアがいるとベストなんだろうけど、実装メインのエンジニアだけではその判断が難しい。結局、プロジェクト開始当初のフル要件をリリースまで引っ張ってしまうパターン。
調整するのが面倒になってフル実装してしまう
実際にMVPを検討することになっても、ファーストリリースでどこまで機能を削る？？→削った機能いつ実装できる？？っていう決めが必要になるので、結局「あーー調整めんどいし実装したほうが早いわ！！！！」ってなってしまうパターン。
そもそも
スキル的に実装可能だけど時間がないという状況は、ミスを生みやすい状況だと思います。それでも完璧に実装するのがプロだろ！！！って言いたいのは、わかるけど・・・状況のイレギュラーをエンジニアに押し付けるのはよくないので、解決すべき🐯
つらい実装をしない🙅🙅
短期的には、
- 時間のかかりそうな機能は一旦削除してissueを切る。
- 落ち着いて段階リリースしよう。
中長期的には、
- コードレビューを徹底する。
- MVPのわかるプロダクトマネージャをしっかり立てる。
まとめ
念のために補足すると、今やってるプロジェクトがつらい状況っていうわけではなくて、むしろこうなりそうだったから修正している（軌道修正できた）という感じです。備忘録。
いいリリースをやっていきたい。💪
