初めての不具合報告 その1

こんにちは、Gaji-Labo イチのバグ製造担当 @neotag です。
この記事は Gaji-Labo Advent Calendar 2015 13日目の記事です。
今回は社内で「バグ報告がいい加減すぎる！」という声が出たので、その辺のことを書こうと思います。長くなってしまったので二回に分けます。

え？ Qiita Team でやれ？ Advent Calendar のネタ探し必死なんですよ。

不具合報告は淡々と

今回は「初めての不具合報告」と題しているので初心で身につけておきた心構えを書いていこうかと思います。

不具合は憎むべきものですが、不具合ゼロでプロジェクトを進行するのは不可能であり、それを目指すこと自体が非効率です。（80%のものを100%にするのが大変だったという経験は誰もがしているかと思います。）
不具合の量を抑制しつつ、発生した不具合を効率的に対処するのが正しいプロジェクトの姿勢と言えるでしょう。

感情交えるべからず

ものごとを効率的かつ安定的に進めるためには感情によるゆらぎは不要です。
不具合報告は淡々と処理されるべきなので、無駄な対立や過剰な配慮は不要と考えられます。

なぜ感情を交えてはいけないか

不具合報告というのは基本的にプロジェクトにとってネガティブな情報と捉えられやすいです。（実際にはされるべき不具合報告がされなくなることが一番危険な状況なのですが。）
そのような状況下ではネガティブな感情が積み重なりプロジェクトが進行するにつれて負のオーラが増えていくでしょう。

また、感情を交えてしまうと以降の不具合解消のフェーズでも感情への配慮が過剰に必要になり官僚的なプロセスに陥りやすいです。
「不具合解消の報告」だけで良かったはずが、相手の感情に配慮して「謝罪」、「経緯の説明」、「再発防止のための決意表明」などが必要になれば不具合の処理速度は遅れ、メンバーのモチベーションは下がり、プロジェクトの進行はどんどん遅れていくでしょう。

そして、進行の遅れたプロジェクトは作業の品質が低下しさらに不具合が増えていくという負のサイクルへ落ちていくのです。

事実だけを書く

難しいプロジェクトの終盤では「この不具合この前もでてた！（怒」みたいな状況に良く遭遇すると思います。
その時も不具合報告は極力事実だけを書き、感情を込めないように抑制しましょう。

事実だけを書くというのは「この前も出ていた」ということを書くなという意味ではありません。
「再発している不具合である」というのも事実なので、その事実は大切にしましょう。
「いついつの○○で報告した不具合の再発である」というように関連する不具合報告の履歴を参照することで不具合解消が効率化されるでしょう。

行間を読ませるような文体を避ける

「◯◯◯するべきだと思うのですが・・・」のような文体は後半の省略された部分に、批判や内省を促すような文脈が発生します。
この場合「○○○すべきだ」もしくは「○○○すべきと思う」のように断定し、余計な文脈が発生するのを防ぎましょう。

行間を読めてしまう文体は「提示されている事実以外にも目を向けさせる」というような圧力が発生してしまいます。
そのような言葉に現れないコミュニケーションは阿吽の呼吸としてチームの一体感を高めるのですが、同時に無駄なプロセスを生む危険性が高まります。

優れた不具合報告は、作業者がその報告を見た段階で「不具合の再現確認」→「原因の考慮」→「不具合の解消」に移れます。
しかし行間を読ませる文体では「不具合の再現」の前に「行間を読む」→「そこから考慮できる次の対応方法を検討する」など実際の不具合解消に辿り着くまでに余計な労力をかけてしまいます。

感情を省き事実だけを指摘した不具合報告が作業効率をあげる

不具合報告はプロジェクトの終盤、メンバーが疲弊し始め、山のように積み重なったタスクを必死に進めているときにより多く参照されるものです。
その不具合報告をチューニングすることでプロジェクト進行を安定させることも破綻させることもできる重要な物だと考えています。

不具合報告から感情を省くことで対立を避け、事実だけを可視化することで不具合解消のステップを省力化できます。不具合報告の作法を侮ってはいけません。

次回予告

今回は不具合報告をする前に理解しておくと良い心構えを書きました。
不具合報告で何を書くべきかなどの実践よりの話を書こうと思います。

関連リンク