みなさん、バグ（不具合）、出してますか？
こんにちは。ソフトウェアエンジニアのたかにぃです。
これまで開発を通じて数多くのバグと遭遇してきました。
自身が実装者として出してしまったものもあればプロジェクトとして出してしまったものもありますが、いずれも「なんとか防げなかったものか…」と、いつも考えてしまいます。
バグを出してしまうと、すごく辛い気持ちになりますよね。
申し訳なさやら恥ずかしさやら情けなさで夜も眠れなくなったりします。
今回はシステム開発において、切っても切れない、でもお目にかかりたくない、そんなバグについて、普段考えていることをつらつらと言語化していきたいと思います。
ちなみに「バグを発生させない為の設計とは？」みたいな話は１ミリも出てきません。
期待していた方、ごめんなさい。
プロジェクトでのバグに対する取り組み
現在、私が所属しているプロジェクトでは、実際にリリースしてしまったバグや、テストなどで防げたもののヒヤリとしたバグなどを、スプレッドシートに蓄積していっています。
その上で、それぞれのバグに対して
- 不具合と対処した内容
- 検出タイミング
- 影響範囲
- 直接的/根本的な原因
- 本来検出したかった工程
- 予防/再発防止策
といった観点でまとめて、スプリントごとにエンジニア全員で振り返りを行なっています。
もちろん責任追及や犯人探しといった要素は排除し（※）、あくまでプロジェクト全体の責任と捉えて、今後のプロダクト品質向上やプロジェクトとしての開発品質向上に繋げるための取り組みになります。
（※）余談になりますが、これすごく大事なことなので、定期的＆メンバーが加入するたびに啓蒙しています。
そうして蓄積されたバグたちを見ていくと、メンバーの意識啓発はもちろんのこと、実際に設計の見直しや運用フローの改善といった形で再発防止策を講じることができたものもありますが、現実的、かつ再現性のある形での再発防止が難しいものも少なくありません。
「システムが人の手で作り上げられる限り、絶対にバグが発生しないシステムは存在しない」とは言いますが、改めてバグを完全に防ぎ切ることは困難だと痛感させられます。
バグが及ぼす悪影響について
さて、そんな防ぐことが難しいバグではあるのですが、とはいえやっぱり出したくはないですよね。
この文章を読んでる方の中にバグなんて別に出してもいいや、と思ってる方は少ないと思いますが、なぜ出したくないのか？
整理のために、改めてバグが及ぼす悪影響について列挙していきましょう。
- ユーザー体験の悪化、顧客離れ
- ブランドイメージの損失
- 法的/訴訟リスク
- システム、企業、プロジェクト、エンジニア当人それぞれの信頼性の低下
- 修正/補填対応のためのコスト増加、それによる納期の遅延
- 品質管理コストの増大
- プロジェクトメンバーのモチベーションダウン、パフォーマンスの低下
パッと思いつくだけでもこれだけの悪影響があります。
ゾッとしますね！
企業として、システム開発者として、いちエンジニアとして「バグは出してはならぬ」と思わされます。
でも無くすことは難しい…
無くす/減らすための努力をし続けるのは当然として、その上でバグとどう向き合っていくか？が非常に大事だと考えています。
バグと向き合う上で大事にしていきたい考え
最初に予防線を張るようで恐縮なのですが、あくまで現時点での私個人としての考えであり、これが正解だというつもりはありません。異論反論あるかと思いますし、なんなら数年後に見たら自分自身で「何を言ってるんだコイツ」となるかもしれません。
その上で大事にしていきたい思いを綴らせていただきます。
エンジニアはバグを防ぐためだけに存在するわけではない
当たり前じゃんと思うかもしれませんが、バグの恐怖に負けそうになる度に意識している考えになります。
エンジニアは「テクノロジーの力を使って、社会や企業、ユーザーの課題や問題を解決し、生活や企業活動の質を向上させ、成長と発展を加速させる」そういった価値を生み出すことが役割だと思います。
その価値を生み出す為の一環としてバグを防ぐことが必要だと考えています。
何も生み出さなければバグが出ることは無いかもしれません。でもそれじゃダメですよね。
上記は極端な例ですが、目的の優先順位を間違えてはいけないと思います。
もちろんバグのリスクに目を瞑ってなんでもかんでもやれ、というつもりはありません。
そうなったら負けというか、本来はそうならないように設計、運用、開発体制を整えるべきではあるのですが、実際には「工数的に品質を担保できないため、断念する」ということはままあるとは思いますし、プロジェクトの現状を見据えた上でその判断をすることも非常に大切だと考えています。
その上で大事なのはリスクと天秤にかけつつ、勇気を持って価値を生み出すことだと思います。
ユーザーのためにバグを出さないという考えも当然大事です。
ですが、本来届けるべき価値の提供ができなかったり、遅れたりすることも、同様にユーザーに不利益を被らせていると考えるべきだと思います。
それら両面を考え抜くことが真のユーザーファーストに繋がるのではないでしょうか？
サービス品質水準の概念
これまで書いてきた通り、バグなんて出したくはありませんし出してはいけないと考えています。
ですが、あなたの手がけるサービスで、あるいは担当する１機能において、そのバグを防ぐこと（実際は防ぐ為の手段を講じ、実行すること）は何よりも優先すべきことでしょうか？
SLA（Service Level Agreement）とも通ずるものがありますが、どんなサービスにも適切な品質というものが存在すると思います。例えばですが、直接的に人命に関わるものやインフラなど影響範囲の極めて大きいシステムなんかは非常に要求される品質は高いと言えます。そうでないサービスが上記と同様の品質を追い求めてしまっては、それは過剰な品質保証になってしまい、本来生み出すべき価値を生み出せていないといえるかもしれません。
我々クイックが手がけるサービスは間接的にとはいえ、ユーザーの人生に影響を大きく及ぼし得るものばかりです。
超大事ですね！そのためサービスの品質が低くてもいいなんてことを思ってはいませんし、口が裂けても言えないと思っています。
ただし、だからこそユーザーの人生をより良くするために様々な価値を届けたいと考えていますし、また多くのユーザーに届けるためにも事業的にも成功していきたいとも考えています。
- 自分たちの扱うサービスは最低限どのぐらいの品質を担保しないといけないか？
- 過剰にバグを恐れていないか？
- 限られたリソースの中で取りうる品質と価値のバランスの落とし所はどこか？
どちらがユーザにとってより重要なのか？を考えつつ、日々のエンジニアリングに向き合うことが重要だと思います。
バランス、大事ですね。
最後に
バグについて日頃考えていることを言語化してみました。
余談となりますが、そもそも開発（実装）をせずに課題を解決することも立派なエンジニアリングですし、むしろ日々の業務でそういった判断をすることは重要だと考えています。ただ、本稿で伝えたいこととはズレるため、開発前提での内容とさせていただきました。
私自身品質やバグを軽視しているわけではありませんし、そう取られないよう注意したつもりではありますが、不快な感情を覚えた方もいるかもしれません。
ただ、賛成であっても反対であっても、バグに対する向き合い方を改めて考えるきっかけとしていただき、読んでくれた皆様の今後のエンジニアライフの一助となれば幸いです。
＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／
