みなさんこんにちは。HC村谷です。
今回は、前回、前々回の続きです。
前々回 ： QAとしての信頼の失い方（やってはいけない）
前回 ： QAとしての信頼の失い方（やってはいけない）［続き］
今回 ： QAとしての信頼の失い方（やってはいけない）［最終回］
——–
起：QAが信頼を失ったら相手は何を信じたらよいのか分からない（前々回）
承：QAが「失敗してしまう」ケース（前々回）
転：「やらかさない」ためのアプローチ ←（前回）、今回
結：まとめ ←今回
——————————————————————-
◆「やらかさない」ためのアプローチ
前回に引き続き「やり方を失敗する、機嫌を損ねる行為って何か？」で挙げたそれぞれの例について、アプローチ方法を考えます。
◇タイム
—————————————-—————————————————————————-
- 当初予定値（見積もり値）から実績値に至る推移を情報として取っていない
（これは求められないこともありますが、細かな工数調整を行う場合などで、どのように推移しているかを必要とされていた場合に、これがないと今後の調整に向けたネタがないという文句が出る場合がある）
—————————————-—————————————————————————-
業務の現場では、各タスクについての見積もり値があり、見積もり値に対する実績値を出します。
これらの値を用いて様々な判断を行いますが、そのためには、精度や各予定に対する実績の推移状況、変更となった際の理由、変更による影響と今後の見通し等が重要だと思います。
そのような提供情報の１つの例として、実施の見通し値（いつどれくらいの項目をこなせそうか）というのがありますが、この値も開発状況に応じて、刻々と変化をしていくことがあります。
決めていたことが変更になることはよくある話で、テスト側でもスケジュール変更への即時対応を求められることも多いと思います。しかも現場によっては、何回も発生することがあります。
そういった変更が発生した場合に、ステークホルダーへ分かりやすくテストの状況を伝え、QAとしての考えを提案する必要があります。
プロジェクト内での複数回の変更発生によって、各回におけるテスト見通しがどのように変化していったのか、良くなっているのか悪くなっているのか、間に合うのか間に合わないのか、間に合わないとしたら、QAとしては何を開発にしてもらったり、QAがどのようにすれば間に合わすことができるのか等を合わせてステークホルダーに的確に伝える必要があります。
もしテストの見通しの変化等、推移の情報を示さなかった場合は、ステークホルダーは、QAとしての見通しの妥当性を判断できず、今後の計画に影響を及ぼすことがあるでしょう。
—————————————-—————————————————————————-
- 日々の実施予定や見込み値を明らかにしていない
（開発とテストが並行で進行していくような場合、開発とQAが情報共有しておかなければ、開発が未実装の箇所をQAが実施予定に組み込んでいるケースに遭遇し、軒並みテストが無駄に止まる事態を招く）
—————————————-—————————————————————————-
１つ前の項と、若干似ていますが、テスト項目の実施にあたっては、「全項目をこの日までに改修確認含めてやり切る」や、「実施予定の項目数を工数で割り算した項目数が1日のノルマでそれ以上をこなす」、といったざっくりした方針だけが出ている場合もあると思います。
しかし、開発がまだ途中であるが、テストを開始しなければならない場合などは、その方針だけで実施しようとしても、テストがうまく回らないことがあります。
そのため、予めテスト実施を行う箇所や順番、または重要な機能について優先度を高くするなどのテストの進め方について、開発と現在の開発状況まで共有しながら進める必要があります。
◇コスト
—————————————-—————————————————————————-
- キツキツの工数見積もりを出していて、生産性が思うように上がっていかないとき
（無事に終わることが厳しくなってきた場合、なぜそのような見積もりを出したのか問われる）
—————————————-—————————————————————————-
これは状況としていくつか考えられると思います。
１つは「キツい」見積もりと分かっていながら出していて（出すしかなく）、テスト実施の生産性に懸けているといったケースです。
あるいは、ギリギリの見積もりであることの自覚がなく、期待する進捗が上がっていないことで初めてキツい見積もりであったことが分かるといった、後から発覚するケースです。
前者は、事前にリスクであることが分かっていながら進めており、リスクを意図的に増大させていることになりますので、理由はどうあれ、リスクな時点で、対処するためのアクションを採らないといけません。
後者は、自覚がないのは自身の感覚だけで見積もりしていたり、事前のインプット情報が少なかったり、精査しないままで生産性を考えていたりと、限定的な情報で見積もりを行っている場合が当てはまると思います。
充分な情報収集の上、各種レビューによるチェックを施すことで独りよがりではない見積もりにする必要があります。
◇品質
—————————————-—————————————————————————-
- テスト計画書の中身・運用に関して諸々の問題がある
（例：更新もなく、実務で活用されない形式だけの計画書）
—————————————-—————————————————————————-
テスト計画書に纏わる誤解のうち、QAを回すのが初めての方であれば、経験の少なさから、やはり誤解も多かったり、今までテスト実施しか行ったことがなければあまり意識できないことであったりと、誤解は色々あると思います。
計画書の目次・内容等は、専門の書籍や初めての方向けのものが詳しいため、ここでは割愛しますが、１つだけよく誤解されそうなものを挙げたいと思います。
「テスト計画書は更新をしないもの」という誤解についてです。
「一度お客様としっかり決めたものだから変更するものではない」としたら、それは誤解だと思います。
もちろん、変更が発生しないように事前に綿密に段取っておく！ことを目指すのは非常に大切なことだと思いますが、いくら計画していても、その通りに行かないことは多いです。
大事なことは
・計画はもちろんしっかり立てるが、必要に応じて変更を行う（「お飾り」にならないようにする）
・変更に至った計画書は変更の理由があるので、その理由、変更前、変更後の内容等を知見としてためる
上記のうち、2点目については、今回の場合だったから変更となったんだけれども、もし○○のような状況だったとしたら変更はなかった、というようなパターンはいくつもあると思います。
このようなパターンを想像できる場を多く経験することで、得られる知見は多くなると思います。
◇リスクの監視・コントロール
—————————————-—————————————————————————-
- 着地（テスト完了）見込みが当初より後にずれ込む（または早く終わる）ことの報告・共有が遅れる
（日々の報告を行っているにも関わらず、この報告が上がって来なかった場合には問題となる可能性がある）
—————————————-—————————————————————————-
日々の発信情報の中に○○はいつ終わる、終わらない等の着地の見込みを盛り込むことがあります。
開発者や先方の管理者はテストが最終工程としてちゃんと問題ない状態で終了でき、リリース延期等なく済むかどうかを知りたいはずです。
テストも中盤以降になると、その雰囲気は目に見えて高まることと思います。
そのため、テスト側として発信していく進捗状況には気を遣います。
どういう状況でどのように進んでいて、こちらがどのように考えているのかを関係者にうまく伝えないといけません。伝えられない、伝わらないようであればリスクです。
—————————————-—————————————————————————-
- 相手側での中間成果物（初版のテスト計画書、テスト仕様書・項目書など）に対する関係者レビューがない
（テスト全体についての方針の共有、また納品物になる可能性も高く、事前に目を通してもらっていない場合は、能動的にアクションを起こさなかったQAの原因である場合がある）
—————————————-—————————————————————————-
基本的に、納品物と成り得るような成果物（の正式版）は、自分だけで勝手に提出することはできません。
関係者での合意が伴いますが、レビューなど内容を確認・コミットする場をQAが率先して作り、能動的に進めていくことをしなければQAが出そうとしている成果物は後回しにされる、または気にされないこともあります。
開発側はリリースに向けて時間との戦いを強いられていますので、QAが品質面で全面的なバックアップをしていくためには、こちら側からの主体的なアクションが求められることが多いです。
◆まとめ
3回の長きに渡ってしまいましたが、いかがだったでしょうか。
自身の過去の経験や見聞きしたこと、教えて頂いたことなどを選びながら、いくつかの例を挙げ考えてみました。
QAの存在意義は、開発側が作ったプロダクトやサービスについて、１つ１つの動きや見え方をチェック・考察し、有益な品質情報を提供し続けることで魅力的・満足度の高いモノを世の中に送り出す手助けをすることだと思います。
これらの事例が１つのケーススタディとなって、QAに役立てば嬉しいです。
Tweet