🤷blog.takuyasuemura.dev

バグが出たときに一番やってはいけないことは、犯人を吊るし上げることだ。その犯人は開発者かもしれないし、設計者かもしれないし、運用担当者かもしれない。あるいは、バグを事前に見抜けなかったテスターやQAかもしれない。社内にいるかもしれないし、社外にいるかもしれない。とにかく、問題の原因を特定の個人にして吊るし上げたり、首をすげ替えてしまうと、組織自体は何も成長しない。

かといって、じゃあ単にバグを憎んで、バグを徹底的に洗い出して直せばそれでおしまい、というのは何か違う気がする。それは単に、誰か個人を責めるかわりに、誰かの仕事を責めているだけだ。実際には、そのバグの背景にはいろいろなことが起きている。複雑なロジックやレガシーコードかもしれないし、納期が切羽詰まっていたことかもしれない。あるいは、短い時間で機能を出すことによるインセンティブが、不具合によるロスを上回るのかもしれない。

パグは悪くない

https://unsplash.com/photos/2Ts5HnA67k8

おれ個人の話で言うと、おれはバグが大好きで、バグを探すのも直すのも大好きな人種だ。バグを見つけた時、どうしてそんなことが起こったのか、突き詰めて調べていくことに喜びを感じる。もちろん、プロのエンジニアとして、バグを出したら反省するし、それが深刻なバグであればあるほど深く反省する。そして、そのバグを二度と出さないように最大限努力する（これが、おれがいま自動テストに情熱を傾けている理由でもある）。しかし、本音ではバグを見つける度にワクワクする。再現条件が不明瞭なバグを、挙動と実装の両面から推理していき、複雑なロジックやコードに立ち向かって原因を見つけた時には最高の気分になる。そして、そのバグを二度と出さないようなクールな手段を実装できた次の瞬間には、一刻も早くそのことを誰かに伝えたい気持ちになっている。それは、バグに立ち向かい、バグから学ぶことで、プロダクトがまた一つ良くなった、という実感が得られるからである。

だから、一開発者としての姿勢として、おれはバグを憎む気にはなれない。かといって、バグの原因を（自分も含めた）誰かのせいにしたいとも思わない。じゃあ、何のせいだと思うのかというと、そのバグが出ることに思い至らなかった、おれたちの無知のせいだと思う。おれたちはスキルが低いわけじゃない。常に自分にできる一番いい仕事をしているつもりだ。でも、そのバグを防ぐには、自分たちのプロダクトの使われ方について何か大事なことを知らなかっただけだ。

知らないことは学べばいい。学び続ければ状況は必ず好転することをおれたちは良く知っている。だから、本当にやるべきことは、 バグを憎む のではなく バグを愛し、バグから学ぶ ことだ。

バグ修正は、時にエンジニアの心を蝕む。新機能開発にフォーカスしたいのに、後から後から寄せられるバグ報告に遮られて、一向にタスクが進まない。しかし、過去にそのバグを仕込んだのもまた自分自身だ。まるで、過去の自分の仕事が、ずっと自分の足かせになっているような気持ちだ。

しかし、こうも考えられるだろう。後からバグが見つかるということは、その機能にはまだ改良の余地がある、と。

少なくとも、その機能をリリースした時点で、その機能は完成していた（完成の定義を満たしていた）はずなのだ。にもかかわらず、追加でバグが見つかったということは、その機能について、知らなかったことがあったということだ。それが深刻なものであろうと何であろうと、知らなかったし、気づかなかったのだから、それは出るべくして出るバグだったのだ、と考えることも出来る。

知らなかったものを知れたのだから、それで良いではないか。大事なのは、そこから学び、改善に繋げていくことである。例えば、その箇所に対する自動テストを書いたり、開発者同士でそのバグに関する振り返りを行うことだろう。そして、次は絶対にそのバグを出さないと心に誓う。

こうした繰り返しで、プロダクトは少しずつより強いものになっていく。

バグは、ソフトウェアの弱い部分を表してくれる。逆に、バグを起点にせずに、弱い所を見つけるのは難しい。バグが見つかったら、弱い部分を強くするためのチャンスなのだ。これは機能レベルの不具合だけでなく、インフラストラクチャの障害などにも同じことが言える。

バグから学ぶという姿勢を明確にすると、「小さなバグを放置する」ということは無くなるだろう。なぜなら、これまでに書いている通り、バグはソフトウェアの品質を向上するチャンスなのだ。品質には内部品質も外部品質も含まれる。バグが出たという事実は、その箇所が弱いということである。軽微なバグを直していく過程で、コードをきれいにしたり、仕様を整理したりしていくことで、より深刻なバグを防ぐことも出来る。

ハインリッヒの法則というものがある。1件の深刻なインシデントの裏には、29件の軽微なヒヤリハット（すんでのところで気がついて、事故に至らなかった事象）がある。あるいは、バグというぐらいだから、ゴk……日本の住宅に現れる、黒い大きめの平べったい虫を想像したほうがいいかもしれない。あの忌々しい虫は、1匹見つかったら、既に30匹は部屋の隅に潜んでいると言われる。小さな出来事は、その後に起こるもっと大きな出来事の前兆だと捉えることも出来る。占いは、タロットカードや亀の甲羅のひび割れ、猫の仕草、雲の動きなどから、その後に起こる大きな出来事を予測する。

深刻なバグを防ぐために、小さなバグから学んで、継続的に品質を向上させていく。こういうアプローチが自分は好きだ。バグを足かせだと思わず、バグの声を聞き、バグから想像力を働かせよう。「ここにこういうバグが出るなら、もしかしたらこういう可能性もあるかもしれない」と想像しよう。そして、そこに手を加えて、改善していこう。

一方、バグから学ばない場合に何が起きるかを想像してみよう。

深刻な不具合を連発したチームがよく陥るミスがある。それは、形式的なQAプロセスを編成し、あらゆるリスクを事前に見つけることに注力しすぎてしまうことだ。別の言い方をすれば、QAだけで100点の品質を実現しようとしてしまう、ということだ。

QAがしてくれる仕事は「バグを見つける」ことではない。バグが出やすい所も教えてくれるかもしれないし、エッジケースを上手く叩いて、様々な「4年に1度しか起きないバグ」を見つけてくれるかも知れない。オリンピックがパンデミックで延期されたときだけ起きるバグも見つけてくれるかもしれない。

だが、バグの潰し方を教えてくれることは恐らくないだろうし、次からそのバグが起きないようにする方法も教えてくれない（相談には乗ってくれるかもしれない）。気をつけないといけないのは、「バグを見つけて、潰す」だけでは品質は上がらない、ということだ。

ここで、ソフトウェアの品質を100点満点で表すとして、仮にその内訳を次のようにするとしよう。

• 内部品質: 50点満点
• 外部品質: 50点満点

もし、今の品質がトータルで30点だとしよう。そして、その内訳が「内部品質10点、外部品質20点」だったとする。バグを見つけて潰し続けると、外部品質は50点満点になるかもしれない。しかし、内部品質が10点のままなら、総合点は60点である。

そして、大抵の場合、低い内部品質は外部品質の足を引っ張る。内部品質と外部品質のバランスが悪いと、50点の外部品質を崩さないように内部品質を向上させる、ということになる。これは非常に難しいことである。

プロとして、我々がやらなければいけないことは、「見かけ上高品質のプロダクトを提供する」ことではなく、「高品質のプロダクトを提供し続ける」ことである。同じ60点なら、10+50よりも、30+30のほうが持続可能である。見せかけの高品質を提供するための一時的なカンフル剤としてQAを利用すると、それは持続可能なものではなくなる。どこかに過負荷がかかる。その場所はQAかもしれないし、開発者かもしれない。

ユーザーにとって必要なのは50点の外部品質だ、という考え方もあるかもしれないが、内部品質が一切ユーザーに影響を与えないという考え方には賛同できない。長期的に提供可能であるのは間違いなくユーザーにとっての品質であるし、新しい機能を頻繁に受け取れることも同様だ。だから、見かけ上バグが無いだけのソフトウェアの品質が100点だと自分には言えない。

「ヤバい障害が連発した、この状況をなんとかしないと、ビジネスが立ち行かなくなる」という事態に陥った時、我々は「たくさんテストをして、完璧なものを提供するように努力しよう」という結論に至りがちだ。

でも、それって本当に可能なんだろうか？100%のものを提供するにしろ、まぬけなバグを防ぐ程度のものにしろ、それは「今まで出来てなかったことを、明日から完璧にこなす」という表明だ。そんなことが出来る人間が本当にいるんだろうか？

品質に懸念があるのなら、やるべきことはやみくもにテストをしたり、それによって見かけを良くすることではない。まずは今までに出てきたバグを見返したり、それらを直したり、それを通じてコードをきれいにしたりすることだ。なぜなら、バグとは自分たちが知らなかった何かの表れであり、それにきちんと立ち向かわない限り品質は上がらない。

品質は、保証するものではなく、インクリメンタルに改善し続けるもの、という考え方が自分は好きだ。いま30点のものしか提供出来ていないなら、明日は31点、その次の日は32点になるように努力するという考え方が好きだ。そうやって持続的にプロダクトを向上させていくという考え方が好きだ。

30点のものを、突然100点にすることは出来ない。自分たちがいままでベストを尽くしてきた結果、それが30点の品質のものだったという事実だけがここにある。事実は覆すことが出来ないが、次に繋げることは出来る。重要なのは、いままで自分たちが30点のものを提供していた、ということを認識して、改善することだ。バグだらけのコードを憎んだり、バグだらけのソフトをテストするのは今すぐやめて、まずはきちんとそれらのバグに向き合って、直して、改善していこう。そうやってプロダクトを鍛え続けた先に、高品質なプロダクトがあるのだと思う。