他者の不具合をみつけること、それをうまく伝えること

ソフトウェアに関わらないが、他者の成果物の不具合や矛盾を見つけ出すこととそれをうまく伝えることとは別だと思っている。私が開発を担当していたプログラムに対してQA（品質保証）の方からバグの指摘をしていただいたときに感じたのがきっかけだ。

QAの方からのバグ指摘はメールで送られてきた。遠隔地で勤務時間帯が必ずしも一致していなかったこともあり、バグの症状は必ず文章になって届いていた。QAの方は皆さん敏腕でよくぞそんな不具合を。。というようなものが多く勉強になることが多かった。

ただし、その不具合の概要や再現方法を説明する文章には個人差があり、指摘がとてもうまい方とそうでない方にわかれていたように思う。うまい人の指摘には「起こる頻度にもよるが」という前提や「このナビゲーションでユーザが誤って～すると…まで戻る必要がある。現状では…まで戻ると入力した内容が消えてしまう」というような文脈やユーザが困ることが具体的に書かれていたように思う。それに対して「先週の指摘ID xxxxの"・・・"と同様にここも、本来～なっているべき部分ができていない」というような「前の指摘」「本来～なっているべき」「常識」というような書き方が目立つものもあった。文章からでは「一緒にいいものを作ろう」という熱意が伝わってこなかった。

担当いただいたQAの方は不具合をみつけるスキルは全員すごかった。QAとして重要なのは不具合をみつけるスキルだと思う。しかし、みつけるスキル、伝えるスキルの両方が揃っているメンバはよりよいソフトウェアを生み出しやすい環境を提供しているといえるのではないか。指摘のタイミングはレビュー、テスト、各種承認と頻度はそこそこ高いと思う。

当たり前の話ではあるが（といっても私自身もできていないことがあるが）、不具合や矛盾を作り出した人に対する指摘ではなく、一緒にいいものを作ろうとしていることに気づいてもらうことが重要だと思う。極端な例ではあるが「前と同じミスをここでしていますね」という指摘や「まだわかりませんか」という指摘はおそらく解決のスピードを遅らせている可能性があるのではないだろうか。もちろん奮起してもらいたいという意図もあるだろうが、文章でそれを伝えるのは難しいように思う。