【テストを”段取”る！】 「コミュニケーションがうまくいかなければ、テストはうまくいくはずありません、なぜなら満足なテスト計画が立てられないからです」という話

みなさんこんにちは。

今回は実務で重要だけれども（基本的に備えていて当たり前と思われるのと特にテスト技術でも無いのとで、）何となく陰に隠れがちな『コミュニケーション』について自分なりに思うところを自由に書いてみたいと思います。（注：答えが１つと決まっている訳ではないと思いますので、見て頂いた方によっては齟齬もあるかと思われますが、どうぞご了承下さい）

◆取っ掛かりからコミュニケーションが重要

普段からQA業務に携わっていてよく「コミュニケーションの重要性」を感じることがあります。

なぜそう感じるかと言えば、企画チームが企画し開発チームが設計して作ったプロダクトやサービスがQAの対象になるので、QAとしては当然、その企画や開発を行う関係者との密なコミュニケーションが無いと業務を進めることができないからです。
（ある程度フェーズが進むと、決定したことを基にしてテスト設計なりに入れるので、四六時中やりとりしないと全てが全く進まないということは無いのですが、やはりプロダクト・サービスあってのQAなのでこう思います）

ですので、QAの初期あるいはプロジェクトの最初から、関係者との情報伝達や意思疎通が取れていれば、まずはQAとして良いスタートが切れたと言えると思いますし、私はこれも最初の成果物みたいなものだと思います。

◆コミュニケーションを取らなかったらどうなるか

では、逆に適切なコミュニーケーションを取らず（取れず）に進めようとした場合、どのような問題が発生するのでしょうか。

簡単な例としては、開発のスケジュールをしっかりと把握しておかなかったので、テストの開始時期が適切では無かった、というのがあります。終了期限についても同じです。また、そのプロジェクトで求められているテストの目的をしっかり掴み切れていなければ、やるべきテストを抜かしたまま、必要のないテストを行ってしまったり、的外れな結果報告が出てきてしまいます。

コミュニケーションが大切だというのは誰でも知っているのですが、難しいのはコミュニケーションする際に何をどれくらい情報収集すれば良いのかが、会社、プロジェクト、時期、担当者等によってまちまちだということです。
加えて、誰がどんな情報をどこまで知っているのかもプロジェクトでの立場や役割などを踏まえて事前に認識しておかないと、ちぐはぐな質問をしてしまい変な顔をされるかもしれません。

ちぐはぐな質問を避け、欲しい情報を集めるために意識した方が良さそうな事柄として、とりあえずパッと思い浮かんだのは以下のような事でした。

• まず、QAの為に把握しておかなければならない事柄がどれだけあるかを考える
• その事柄に結びつく情報を誰が持っているのか（又はどの資料に記載されているのか）を考える
• 聞くべきことと、QAで考えるべきことが整理できているかを考える
• 収集できた情報はどの程度決定された話なのかを聞く

etc…

◆コミュニケーションした結果をどう活かすか

さて、上記で何とか情報を収集していくのですが、ではその収集した情報は次にどうするのでしょうか。

それらの情報は、品質を担保するためにどのようにQAを動かすか（例えば、目的から方針、日程、体制、範囲、設計手法、報告、会議体や各種管理方法など状況に応じて多岐に渡る）を、適切に（そのプロジェクトに合った形で）決めるためのベース情報として使用します。
例えば、「テストする必要のある機能とそうでない機能」であったり、「どのような場合にテストを中止して再開させるのか」などテスト計画として決めなければならないことの大部分に影響が及ぶものだと考えても良いと思います。

なお、前項でも挙げたQAとして決めなければいけない項目については、一から考えて書き出していっても良いのですが、すぐに考え付かない場合は、IEEE829（※）にテストプラン用のテンプレートが用意されていますので、そちらを利用するのも良いと思います。
（が、英語の為、日本語で説明されたサイトも多数見つかりますのでそちらをご参考に）
それで各項目に対して、収集した情報を基にして内容を反映していきます。

※IEEEは、Institute of Electrical and Electronic Engineersの略。
1963年に発足した電気・電子分野における世界最大の学会。技術標準を定めたりしている。IEEE829は、ソフトウェアテストのドキュメンテーションのための標準を示したもので、世界中で普及している。

◆結果を活かした後も活かしっ放しにしない

上記で作成したものについては、関係者の合意を取って確実に記録を残しておく、つまり承認を得ておくということが大切です。
そうでないと、問題が起こった場合に正式な記録・承認が無いために判断材料が無くて困ったり、過去に決定していたと思っていたことが覆ったりする可能性がありますので気を付けましょう。
（※承認があった場合でも、覆る場合は覆ります）

◆最後に

思いつくままに書かせて頂いたのですが、最後にもう一つ大事なことを忘れました。

よくやりがちなのですが、折角作った計画書なり資料やルールも、関係者の希望通りに書き過ぎてQAとして現実離れした理想ばかりになってしまったり、開発とうまく連携が取れるような内容では無かったりということがあります。

決めた計画自体が計画としてドライブできない（されない）内容［※小刻みな修正ではない］であれば、それまでに費やした時間は水の泡になりますので、コミュニケーションし情報収集する中で、一方的に聞くだけではなくQAとしての見解もしっかり示しながら双方向で決めていくことが非常に大事だと考えています。（そういった姿勢を含む）

うまくコミュニケーションする、といってもシンプルなようでなかなか捉えどころのない難しさがありますが、この記事がコミュニケーションについて考える際に僅かでも役に立てば幸いです。

Tweet