はじめに
QAの仕事でよく行われる不具合報告。その中で気を付けなければならないことのひとつが「問題の切り分け」です。
例えばざっくりと「〇〇がおかしい」とだけ言われるとどう修正をして良いかが分かりにくいため、まずは以下のような問題の切り分けを行います。
- サーバー側の不具合なのかクライアント側の不具合なのか
- 特定のOSバージョンや端末、画面サイズ、環境に依存していないか
- 再現する条件は何か、手順は何か
これらの情報をQAの中で可能な限り切り分け不具合報告として詳細に記載しますが、言い方を変えればこのようになります。
- 例えばサーバー側の不具合であればクライアント側は問題がない
- 特定の環境に依存する不具合であれば、該当しない環境は問題がない
- 再現手順を踏まなければ問題がない
問題を切り分けるということは、原因を特定し具体的に言語化するのと同時に「それ以外は問題がない」ということを特定させることになります。これが、僕がコミュニケーションの中で大きく役に立ち、QAの仕事を通して学べて良かったと思うポイントのひとつです。
なお、ここにおけるコミュニケーションは、自分と自分以外の存在の間で行われるコミュニケーションに加え、自分の中で壁打ちをしたり心と向き合ったりするような個人内コミュニケーションのどちらも指しています。
「問題を切り分ける」コミュニケーション
生きている中でぶつかるあらゆる問題に対して、誰しも一度はこうコミュニケーションしたことがあるのではないでしょうか。
- だめだった
- なんか上手くいかなかった
- やっちゃった
- ミスった
これらは最初の不具合報告の例では「〇〇がおかしい」といった、ふわっとして、何から手をつけて良いかわかりにくい捉え方です。これの良くない点は「必要以上に大きく、ネガティブに見える」ということです。
例えば 10回の選択によってクリアできるものがあり、それがクリアできなかったとします。じっくり考えれば実は問題だったのは 10回の選択のうちの最後の A か B かの選択を誤った、程度のものであり、非常に惜しい状況だったかもしれません。むしろ 9回は正解できていたのにも関わらず、ふわっと「だめだった」とコミュニケーションしてしまったことで 10回全体が問題だったかのように捉えてしまうのは非常に勿体無いと思いませんか。ここで問題を切り分けていくのですが、「選択を誤ったのは最後だけ、今回も90％は正解」とすることができれば、少し気持ちが楽になるのではないでしょうか。
よく、根本的な問題解決のアプローチとして「なぜなぜ分析」を行いますが、時に、なぜなぜを繰り返すことは「これだけは自分が向き合わなければならない、どうしても避けられないこと」が見つかっていくしんどさを感じることもあります。そこで僕は、コミュニケーションにおいては何が問題だったのかを切り分けながらも、切り分けた結果除外された「ここは大丈夫、ここは正しかったかもしれない」ということにもフォーカスすることを忘れないようにすることで安心感を与え、ポジティブな感情を保てるようにしています。
問題を切り分け小さくしていくテクニックに加えて、「切り分けられていった部分も大きい」と捉えるテクニックは自分に対するコミュニケーションでも、他者に対するコミュニケーションでも有効です。
QAで培った「問題を切り分ける」ことが、安心を与えることに繋がるかもれないと思ったのが僕の気付きでした。
(問題によっては切り分けること自体の負担が大きく、あえてふわっとさせておくことで問題を限定させずに置いておくこともあるかもしれません。全体としては切り分けた方が良いことの方が多い気がするので括弧で括っておきますが、切り分けるテクニックを知った上で「切り分けない」と選択することもコミュニケーションのひとつでしょう)
最後に
QAの話に戻ります。QA活動において「これが問題だ」「これが解決しないとリリースできない」というコミュニケーションもできれば「ここは最高だ」「これさえ満たせればリリースできる」というコミュニケーションもできます。どちらも柔軟に使い分けられるようなQAでいたいですね。
以上、何かの参考になれば幸いです。