品質劣化「デグレ」について考えてみた。
デグレ※1とは何らかの原因で以前は正常に動いていた機能にバクや不具合が生じて、品質が悪くなってしまうことを表します。
※1, ここで述べるデグレはプログラムを修正したことで起きるデグレを想定します
現在、私が働いている現場では、デプロイする度にデグレを起こすケースが多いです。
そこで、個人でデグレが起きる理由と解決方法について調べてまとめました。
俺（私）の現場もデグレがやばい！という人はぜひ参考にしてください！
■ 対象読書
- 現場の若手エンジニア
- 非エンジニアPM
- 駆け出しエンジニア
デグレをすると、なぜダメなのか
そもそも、デグレが起きるのはなぜダメなのでしょうか？
デグレを起こす最大のデメリットはサービスの信頼度が落ちる点だと思います。
それも、少し下がるのではなく急激に信頼度が落ちます。
ユーザー目線で考えれば当たり前なのですが、バージョンアップする度に不具合を起こすサービスを信頼して利用し続けると思うでしょうか？
デグレを頻繁に起こしてしまうと、ユーザーからの評価は急激に落ち、結果サービスを利用してもらえなくなる可能性が高いです。
継続的に利益をあげるサービスにするためには、デグレは絶対に避けなければならない現象になります。
デグレが起きる理由
そもそも論ですが。なぜデグレが起きるのでしょうか？
デグレが起きる理由その１、「人的ミス」
デグレの起きる原因の多くは人的ミス（ヒューマンエラー）です。
■ 人的ミスの例
- 影響調査を見誤った
- テストを書き忘れた
- 仕様の把握を見誤った
影響調査を見誤った
自分の実装したコードが既存のコードにどのような影響を及ぼすかを把握せずに実装するとデグレにつながります。
テストを書き忘れた
これは人為的ミスというより、怠慢に近いのかもしれませんが。挙動を確認するためのテストコードを書いてないとデグレに気づかないままデプロイしてしまうケースが多いです。
仕様の把握を見誤った
仕様を把握せずに実装すると、想定と違う挙動のままデプロイしてデグレにつながります。
実装前にPMやビジネスサイド側の人間と認識合わせをしないとデグレになります。
デグレが起きる理由その2、「情報共有不足」
スーパーつよつよエンジニアでない限り、開発はチーム別に複数人で開発します。
チーム別で開発した結果、情報共有が上手く行かずにデグレが発生するケースが多いです。
例えば、Aチームの佐藤さんがログイン機能の修正を行ったと仮定します。
しかし、Bチームはそのことを知らずに開発を進めます。
同時タイミングでデプロイした結果,ログイン機能周りにデグレが起きます。
デグレが起きた原因はBチームがログイン周りの追加機能実装を同時並行で進めていたからです。
本来はBチームはAチームの佐藤さんがログイン周りの修正を行なっていることを知っておくべきです。
そうすることで、それを考慮した上で開発を行う事が出来た筈だからです。
要は、こういったチーム間の情報共有不足や、コミュケーション不足が原因でデグレが起きます。
自分のチームだけを理解するだけではなく、他のチームがどういった開発やデバックをしているかを理解していれば防げるデグレが多いです。
デグレが起きる理由その3、「テスト不足」
テスト不足により、デグレを起こしてしまうケースも多いです。
例えば、ログイン認証周りの実装を行った時には以下のようなテストを書くべきだと個人的には思います。
1. セッション、クッキーの状態確認テスト
2. ログイン認証の成功パターン確認テスト
3. ログイン認証の失敗パターン確認テスト
4. 認証後の画面遷移確認テスト
5. 認証後のユーザー登録確認テスト（DBに正常に保存されるとか、パスワードが暗号化されてるとか）
この辺は絶対にデグレを起こしてはいけない箇所です。
しかし、多くの現場が開発スピードを重視するあまりテストを軽視しテストを書かない現場が多いです。
その結果、コード修正などを行った時にテストでデグレが起きなように担保されているべき箇所が担保されておらずデグレにつながります。
デグレが起きる理由その４、「経験不足」
個人的にはデグレを起きないようにするには経験が重要になってくると思ってます。
なぜなら、バグが起きそうな箇所は経験則によって予測がつくからです。
サービス開発の経験が増えると、実装している中でここはバグが出やすいだろうな、以前に同じような実装をしてバグを起こしたから気をつけようなど経験則に則って実装することができます。
しかし、経験が少ないジュニア層のエンジニアはそこまで細やかな点まで気がつかないのでデグレを起こしてしまうことが多々あります。
デグレを少なくする方法
はい、ではどうすればデグレを起こさないようにすることが出来るのでしょうか？
デグレを少なくする方法その１ 「影響範囲の調査を怠らない」
修正作業が終わった後に、必ずその作業によってどのような影響が起きる可能性があるのかを慎重に調査を行う事が大事です。
自分の実装周りの動きの確認だけではなく、その実装によって他のどのような箇所に影響があるのかをリスト化してプルリクを出すのも良いかもしれません。
この時に大事なのは思い込みを捨てる事です。
疑いの目をかけながら実装コードと挙動を確認する事で、デグレに気付きやすくなります。
もし、あなたがプルリクをレビューする人であればレビューイが気づいてないようなデグレを起こしそうな可能性がある場合は教えてあげましょう。
人為的ミスの多くは「多分大丈夫だろう」という思い込みが原因です。
.....そうはいっても、人間はミスを起こす生物です。
ですので、エラーが起きてしまった場合はいち早く気付くような環境を事前に作っている事が大事です。
オススメはエラー監視ツールSentry導入です。
Sentryはエラー監視ツールで本番環境でエラーが起きた場合はSentryが検知して、エラー内容をSlack通知してくれるような仕組みになっています。
デグレを少なくする方法その２ 「情報共有ツールの導入」
情報不足でデグレを起こす場合は情報共通ツールの導入を行いましょう。
ちなみに僕の会社ではzenhubという情報共有ツールをいれています。
情報共有ツールを導入する事で、周りのメンバーや他のチームの動きを可視化する事ができます。
可視化する事で客観的に開発業務を見る事が出来るので、情報共有が円滑に行われデグレを起こしづらい環境にすることが出来ます。
あと、個人的に情報共有を行う上で大事だと思うのは人間関係です。
人間関係が悪く、気軽にお互いの開発状況を伝え合うような関係を保てないと情報共有不足につながります。結果、デグレになります。
以前読んだTeam Geekにも書いてあったのですが、「開発はチームスポーツ」だと思うので人間関係は超大事だと思います。
デグレを少なくする方法その３ 「信頼度の高いテストを書く」
現場によってはテストを書かない現場もあります。
その理由は開発スピードが落ちるからです。
しかし、開発スピードを重視するあまりデグレが起きまくるサービスを作ったとしてもそんなサービスは長期的には利用してくれません。
信頼度（網羅性）の高いテストを書いてデグレを起こさないようにすることの方が長期的に見ればかなり価値は高いと個人的には思います。
また、テスト方針はまとめておいた方が良いと思います。
テスト方針をまとめることで、テストの書き方ばらつきが最小化し、バク発生率が下がるからです。
テスト方針を決め、それに従ったテストを書くことでサービス品質を高めデグレを起きにくい環境にすることができます。
デグレを少なくする方法その４ 「経験のあるエンジニアに頼る」
現場に一人、経験のあるエンジニアがいると強いです。
とはいえ、そんなエンジニアいないよという現場が多いと思います。
そういった現場はエンジニア同士でペアプロなどで協力し合いながら開発業務を行うことでバグやデグレを防ぐ事が出来ると思います。
まとめ
人間なので、バグを完全になくした完璧なコードを書くことは不可能です。
ですが、デグレを起こさないために対応策を練ることは可能です。
品質の高いサービスを開発できるように、僕も精進していきます。
あと、他にもデグレに関してのアドバイスあればコメント頂けたら嬉しいです。