開発をしていると、バグ報告をもらう。もらうのだが、何を問題としているのか、全くわからないものがある。ITに疎い部署の人であればまだしも、情シスの人間だったり、テスト担当の人間だったりした時には、本当に呆れる。
バグ報告の話を本で読んだのは、学生時代。だから、もう何十年も前の話だ。そこで書かれていたのは、「起きた現象を正確に具体的に伝えること」が重要だということだった。なのに、未だにそれは徹底されていない。それどころか、日本語として意味が取れないレベルだったりする。コミュニケーションができないのだ。「コミュニケーション能力」と言われると、面と向かって話せる能力と思いがちだ。だが、そう言ったことではなく、日本語として成立する文章を書いて、用件を誤解なく伝えられる能力なのだ。だから、ITに疎いかどうかは関係ない。ただ、疎いと適切な用語を使えなくて、コミュニケーションコストが若干上がるだけだ。
視点を変えて「問題を伝えて解決を依頼する」という点から見ると、「問題点」「あるべき姿(希望する動き)」を明確にして伝えることができていないのだ。そう考えると、ITに疎い人だからしょうがないと諦めるのは、おかしな話になる。単に、コミュニケーション能力が低いだけなのだ。
話を戻して、バグ報告。
よく5W1Hと言われるのだが、意味不明なバグ報告にはそれが入っていない。
・いつ起きたのかがわからないから、ログを全部調べなければならない。もしかしたら、ログがもう消されているかもしれない。
・どこで起きたのかがわからない。本番環境なのか、テスト環境なのか。
・誰が操作したのかがわからない。ログインしたユーザによって使える機能が変わるので、単に権限のないユーザでログインしているだけなのかもしれない。
・何を操作したのかがわからない。
・どうしたのかがわからない。ウィザードに従って順番に進めていったのか、途中でキャンセルしたのか？
・どうやったのかがわからない。パソコンでマウスをクリックしたのか、スマホでボタンをタップ(押した)のか？
これらに加えて
・どうなることを期待しているのか？「適切に動く」といっても、何を持って「適切」というのか？
・実際どうなったのかわからない。現象をちゃんと説明できるほど、文才あるの？
これらを明らかにしないと、バグ修正は行えない。だから、欠けている情報を問い合わせるのだ。問い合わせの手間が生じるのだが、対応時間数で金額が決まるなら、まぁ許せる。請負の開発作業で、受け入れ試験で見つかった問題の報告がこんな感じだと、次は請けたくないし、請けることになったとしても、手間(コミュニケーションコスト)を上乗せすることになる。
専門学校とか、新人教育とか、プログラミング教育なんてやる前に、バグレポートの書き方を徹底的に叩き込んでほしい。適切なバグレポート→コミュニケーションコストの削減→プロジェクトのコスト削減となっていくのだ。新しく来た人に、とりあえず「テストお願い」というパターンは多い。仕様がよくわからない中でのテストはどうなんだろうと思っていたが、コミュニケーションスキルを見るという点では、案外、いい方法なのかもしれない。
