みなさんこんにちは。HC村谷です。
ちょっと刺激的なタイトルにしてみたのですが、
今回は、QAが「失敗してしまう」ケースを自分なりに考えてみて、それを「やらかさない」ためには、何をどのように考え、アプローチするのが良さそうか?
また、どうすれば相手の方にQAの存在意義を示すことができ、信頼を得て継続的な改善業務を進めていけそうか?
を考えてみたいと思います。
(今回は失敗ケースの例までを書いてみたいと思います)
——–
起:QAが信頼を失ったら相手は何を信じたらよいのか分からない
承:QAが「失敗してしまう」ケース
転:「やらかさない」ためのアプローチ(次回)
結:まとめ(次回)
——————————————————————-
◆QAが信頼を失ったら相手は何を信じたらよいのか分からない
まず、今回のテーマ設定の理由ですが、私がたまたま、主にお客様のプロダクトやサービスに対し、QAとして現場に立つことが殆どであることが主な理由です。
やはりお客様のものを暫くでも預かりチェックしていく以上、お客様側の担当者の方も「QAはあそことやりとりしながら任せれば、最後はうまく着地させてくれる!」と思いたいでしょうし、私もそう思って欲しいという気持ちでQAに臨んでいます。
ちなみに、この記事を読まれている方は、私のような第三者の品質企業ではなく、自社で開発したプロダクトやサービスを持ち、それらに対してそれぞれの立場(社内における品質保証部の立場、開発者としてのデバックを行う立場 etc)でQAに関わっている、あるいは関わろうとしている方のほうが多いかもしれません。
仮にそうだったとしても、立場の違いこそあれ、やるための目的は似ています、というか同じです。
似ています、と書いてしまったのは、お客様から仕事を引き受けて納品していく我々のような専門会社の立場の場合は、お客様が我々を安心への担保として近くに位置づけて頂けるように、「信頼」を勝ち取っていくという営業的なミッションも別にあるわけで、そういう意味で自社のサービスをQAする方々に比べ仕事的なミッションが1つ多いということで、似ている、と書きました。
(あからさまで嫌らしい話に聞こえたかもしれません。お詫びします)
同じだと書いたのは、利用者の方たちがプロダクトやサービスを必要だと感じることができて、その上使いやすいと思ってもらえることを目指していく点は、全く同じであると考えるからです。そのためには、業務の中で同じ企業だろうと別の企業から関わる場合であろうと、一緒に業務をする相手に信頼してもらうことが結構大きいのではないかと思っています。
おそらくQAとしては、発注されたお客様、または開発グループからの信頼がベースで、そのうえでしっかりとした実務、という骨組みがないと、本来無くても良い余計なオーバヘッドが発生してしまいます(コミュニケーションがうまくいかず無駄な時間を費やす/ほんとにこの内容で大丈夫かと心配される等)。
——————————————————————-
◆QAが「失敗してしまう」ケース
タイトルにも挙げた信頼を失うということは、いつかどこかでQAのやり方を失敗していたり、QAを回していくにあたって相手の機嫌を損ねているような行為をしていたりするので、それが最後までカバーできずにダメになってしまうということだと思います。
QAを回すには、立ち上がりから終わりまで、テストに関するセオリーは勿論、相手あってのQAなので、プロジェクトマネジメント(QA1人プロジェクトの場合、セルフマネジメントも含む)に関する取り回しも要求されるかと思います。
では、やり方を失敗する、機嫌を損ねる行為って何か?ということをこれから並べてみようと思います。ちなみに挙げる内容は、私が自身への自戒も含めてそうではないだろうかと感じたことであり、全ての方に当てはまる内容とは限りませんので、どうぞご了承下さい。
その前にまず、ひとえにQAとかテストに関わる人と言っても、立場などを考えると一括りではないだろうと思いました。例えば、先にも挙げましたが、それぞれの立場の違いがあるからです。
- お客様のサービスを第三者目線で品質改善・向上支援する「専門企業」
- ユーザ企業内で自社サービスの出荷可否の判断を下す「品質保証部」
- 自社サービスの開発グループの中で、他の担当者が実装した内容をクロスチェックしていく開発グループ内の担当者
それぞれに立場や、目的、責任・作業範囲、与えられた期間などがあり、要求される程度も異なってはいますが、いずれの場合も依頼した相手からの「ありがとう。これからもお願いします」、また、サービスを利用する利用者からの「利用のしやすいシステムだ」などの信頼や感謝に繋がる成果を1つのゴールとして考える点は全く同じだと思います。
そして、ここでいうゴールに到達できないパターンを考えることができれば、それが途中で「失敗してしまう」可能性のあるケースではないかと思いました。
(余談ですが、仮にここで何らかの問題が発生したとしても、問題が世の中にリリースされる前にカバーできたり、問題の芽を摘んでしまうことができれば、損害は最小限に食い止めることができ、逆にヒヤリハット事例として拾い上げることで、体制の強化につなげることもできると思います)
やり方を失敗する、機嫌を損ねる行為って何か?
◇コミュニケーション
—————————————-
- 関係者との情報伝達や意思疎通が取れていない (※1)
これが取れていない場合、最悪はテストのプロジェクトはリリース遅延を起こすかテスト漏れのままリリースされる - 要求を決めていたり、権限を持っているキーマンが誰かを把握していない(ステークホルダ特定失敗)
- ヒヤリングすべき情報を誰が持っているのか(又はどの資料に記載されているのか)を把握していない(※2)
これを掴んでいなければ、現場の一意見に振り回されていつまでもコミットできない状況が続き、QAはどうなっているんですかと言われそう
◇スコープ
—————————————-
- 相手の要求を理解していない、または浅い(※2)
この状況になった場合、気づくのが遅くなればなるほど手戻りが大きくなりテストやり直しに繋がる - QAの為にまず把握しておかなければならない事柄の全体を考えていない(※2)
QAとして何をやって、現場でどう動かしていくのかをイメージ立てできない場合、相手からQAをどのように考えているのか、と言われかねない - 相手に訊くべきことと、QAで考えるべきことが整理できていない(※2)
◇タイム
—————————————-
- 当初予定値(見積もり値)から実績値に至る推移を情報として取っていない
これは求められないこともありますが、細かな工数調整を行う場合などで、どのように推移しているかを必要とされていた場合に、これがないと今後の調整に向けたネタがないという文句が出る場合がある - 日々の実施予定や見込み値を明らかにしていない
開発とテストが並行で進行していくような場合、開発とQAが情報共有しておかなければ、開発が未実装の箇所をQAが実施予定に組み込んでいるケースに遭遇し、軒並みテストが無駄に止まる事態を招く
◇コスト
—————————————-
- キツキツの工数見積もりを出していて、生産性が思うように上がっていかないとき
無事に終わることが厳しくなってきた場合、なぜそのような見積もりを出したのか問われる
◇品質
—————————————-
- テスト計画書の中身・運用に関して諸々の問題がある(※3,4)
(例:更新もなく、実務で活用されない形式だけの計画書)
◇リスクの監視・コントロール
—————————————-
- 着地(テスト完了)見込みが当初より後にずれ込む(または早く終わる)ことの報告・共有が遅れる
日々の報告を行っているにも関わらず、この報告が上がって来なかった場合には問題となる可能性がある - 相手側での中間成果物(初版のテスト計画書、テスト仕様書・項目書など)に対する関係者レビューがない
テスト全体についての方針の共有、また納品物になる可能性も高く、事前に目を通してもらっていない場合は、能動的にアクションを起こさなかったQAの原因である場合がある
ここに挙げた事例は、やや具体的に書いてみたのですが、まだまだほんの一部だと思いますし、他にも沢山の事例があると思います。
次回はこれらのケースに対して、「やらかさない」ためのアプローチを考えてみたいと思います。
————
※1 「【テストを”段取”る!】 「コミュニケーションがうまくいかなければ、テストはうまくいくはずありません、なぜなら満足なテスト計画が立てられないからです」という話」(◆取っ掛かりからコミュニケーションが重要)
※2 同上(◆コミュニケーションを取らなかったらどうなるか)
※3 同上(◆最後に)
※4 以下の書籍の鈴木三紀夫さんの記事が、大変分かりやすくイメージもしやすいと思います。
・ソフトウェア・テスト PRESS Vol.10「テスト計画書のアンチパターン─テストを失敗させる9つの「悪癖」─ 鈴木 三紀夫」
・上記を取り上げているブログ記事:ソフトウェアテストはじめての二歩目 業務をスムーズにするためのテスト計画
2件のコメント
ただいまコメントは受け付けていません。