バグって言うな問題は構造の問題なんじゃないか

先日から友人のエンジニア達と、はてな界隈でバズっていた記事について話している。

提案：エンジニアに気軽に「バグ」というのはやめませんか？ - worker experienceの日記

バズっていた記事とは上記のもので、簡単に言うと「エンジニアに"バグ"と気軽に言わないでほしい」という提案を投げかける内容だ。

ある友人は上記記事を「エンジニアのエゴだ」と断じ、ある友人は「バグって言われるとウッとなるから共感出来る」と言う。僕はどちらの気持ちもわかる。

たしかに、ユーザーや顧客からすれば正しくないデータを表示したり望んでいない挙動をするプログラムにはバグがあると思って当然である。それが仕様だとしても、そんなことはユーザーにとっては知らないし関係のないことだ。

要求の履き違えであったりビジネス要件認識のズレであったり仕様通りであったり仕様漏れであったり普通にバグであったり、システムがユーザーの思った通りに動かない原因は色々ある。でも、原因なんてことはユーザーには関係のないことなのだ。思った通りのものが得られない。それが何より重要なことなのだ。思った通りのものが得られないシステムに対し、それをバグや不具合と呼んでしまうことに罪はない。ほかに相応しい言葉を知らないのだし、それこそシステム面か仕様に踏み込める人間でないとそれがバグなのかどうかなんて分からないのだ。システムをわからない人に仕様を調べて指摘しろというのはエンジニアのエゴであるし、単に"バグ"という言葉を嫌うのならばそれこそ"ドラゴン"と呼ばせてみればいい。結局ドラゴン=バグなのだから、呼び方を変えたところで根本的な問題は解決などしないと思う。

しかし一方で、バグという言葉がいかにエンジニアを傷つけるかということも僕はよく分かる。痛いほど分かる。

バグを起こしたエンジニアのリアルな感情の流れ - ここはクソみたいなインターネッツですね

バグじゃないものをバグだと呼ばれることで、エンジニアは不要なストレスを感じる。またバグという言葉が横行することで本当に直すべきバグが隠れてしまうという話も納得がいく。どちらの気持ちもわかるエンジニアとしては、この問題の根本的な構造を改めて解きほぐしていきたい。

友人達との結論

面白いのは、何度か違う場所で違うエンジニアとこの話をしたけれど、出てきた結論が同じであったという点だ。

結局「エンジニアとその他」という認識か、あるいはそう認識させてしまう構造の問題じゃない？

僕らはいつもこの結論に至った。

例えばシステムとドメイン領域両方の理解をしたディレクター、あるいはプロダクトオーナーのような人間が居れば、エンジニアに"バグ"という言葉が伝わる前に一度咀嚼してもらえるはずだ。更に言えば、例えそういった役職がなくともビジネスサイドの人間とシステムサイドの人間にしっかりとしたチーム意識があれば、エンジニアではない人間もプロダクトに対してプライドや"自分ごと"意識が生まれているはずである。その場合「バグでないものをバグと呼ばれてムッとする」のはエンジニアだけではないのが自然だ。ビジネスサイドの人間とシステムサイドの人間がしっかりとパートナーシップを結べていないからこそ、此岸と彼岸というようにエンジニアとそれ以外を断ずることが出来てしまう。一つのプロダクトに対し、ビジネスとシステム双方を織り交ぜた強いチームが存在していれば、そもそも「エンジニアにバグと言うのをやめてほしい」というような話は出てこないはずなのだ。ネガティブに言っても「プロダクトのことをよく分かっていないのにバグと言わないでほしい」となるか、普通ならば「このプロダクトにはバグだと思われてしまう問題があるんだな」というポジティブな受け取り方になるはずなのだ。

こうした論理から、僕と友人のエンジニア達は、結局この問題は認識か構造の問題であると結論した。

僕の感想

けれども実際問題、そんなに強いチームが出来ていることなど稀だし、バグだー不具合だーと直接エンジニアに言ってくる人は少なくない。でもやはり僕は、それはその人のリテラシーや気遣いの不足が悪いというわけではなくて、そう思わせてしまうシステムに原因がある場合がほとんどだと思う。そしてシステムのことはシステムの人間にしか分からないこともあるのだから、柔らかく「どんなバグですかー？」とこちらから歩み寄る姿勢こそが必要なんだと思う。

殆どの人はエンジニアを傷付けるつもりでバグという言葉を使っているわけではないのだし、エンジニアがバグという言葉で傷付くかどうかを想像しろなんて酷だ。逆にわからないものをバグと呼んでいるんだという想像は容易なのだから、まずは余裕を持てる方が歩み寄り、最終的には互いの歩み寄りが行える構造を目指すべきだ。