【実話】レビュー指摘の修正後に限ってミスが増える３つの理由
以下は実話です。
こんなことありませんか？
レビュー指摘の修正後に限ってミスが増えてしまった経験ってありませんか？
たいした修正でないのに、その修正がトリガーになって複数の不具合を出してしまったみたいな。
それって、個人の能力んじゃなくて構造と体制に問題がある可能性大です。
今悩んでいる人は以下を読んでみて参考してみてください。
ある日の出来事
私: 「よし、完璧！ レビューお願いします！」
上司: 「....ここって一応disable属性いれとかなくて大丈夫？ あと、この辺のバリデーションは大丈夫？」
私: 「(まあ動作的には問題ないけど対応した方がより好ましいかな。) 了解しました！修正します」
：
：
：
(再レビュー後)
私: 「よし、完璧！ レビューお願いします！」
上司: 「不具合がめっちゃでてるよ....ちゃんと動作確認したの？」
何が起こったの？
かなり綿密に確認したけど、まさかそっちで不具合でるなんて。。。
・ プログラムが複雑で影響範囲を把握しきれていなかった？
・ テストシナリオが足りてない？
・ 怠慢か？自身の能力の話か？
でも、プログラムなんて会社の成長とともに複雑になるもんだし、それにともなってテストシナリオは増えていき全部をカバーできるほど工数は与えられてない。
個人の能力のせいにするのは簡単だけど、明日にでもまた同じミスをしてしまいそうだ・・・
いったいどうしたらいいのだろうか。
【本題】３つの原因
さて、ここからが本題。
原因は、色々あるが結局以下の3つに集約されるのと結論づけました。
- 開発のバッジサイズを大きすぎる。
- 完璧なものを求めすぎる。
- ミスを悪とする。
1. 開発のバッジサイズを大きすぎる。
まずミスが増える一番の要因は、これ。
開発バッジサイズが大きすぎること。
例えば、ある条件を満たしたユーザにメールを送るプログラム作る際に、
送信拒否設定・送信履歴・その他送信設定等・・・・など機能盛りだくさんの状態でリリースをしようとすると、
レビューでのちょっとした指摘や、不具合が出た時の修正の工数が爆上がりします。
またそういった開発スタイルはスパゲッティコードを生みやすいです。
なぜなら、大きなものを作ってしまい、後に戻れず妥協してしまうからです。
参考: https://tech.uzabase.com/entry/2021/05/20/141950
経験上、結果として「１の修正が10のバグを生み出す」みたいな状況に陥ります。
よって、ポイントは「いかに小さい機能で課題を解決するか」だと思います。
レビュワーの負担が減るので早いスピードでリリースまで進めることができますし、
低コストで高い効果を得ることができます。
2. 完璧なものを求めすぎる
1にかなり近いことですが、完璧なものを求めてはいけません。
・ まずは雑に作ってテストする。
・ その後に作り込んでテストする
：
この辺の詳細は以下の記事を見ていただくといいかもしれないです。
3. ミスを悪とする。
「ミス = 怒られる」 ・「ミス = 無能」 といった考えは大間違いです。
ミスした時は、個人だけのせいにしないで、その本質をとにかく考え続けることですが大事だと思いました。
個人のせいにしてしまうと、優秀な人でないと回らない組織になってしまいます。
ぜひミスしたときこそ、組織改革のチャンスと思って、前向きに原因を探してみてください
まとめ
全ての人が上記が原因というわけではないかと思いますが、なにかしらのヒントになればいいなと思います。
Discussion