環境構築ミスやヒューマンエラーをなくすためのノウハウ

こんにちは、テスシです。
私はソフトウェア開発で、システムテストに携わっています。この工程では、これまでに開発したプログラムを一つにまとめて、想定通りのものができているかどうかや本番環境でちゃんと動作するかどうかを確認しています。

はじめに
テスト開始に向けた対策
- 環境構築前の確認6W1H
- ストーリーとは
問題が起きてしまったときの対策
おわりに

はじめに

今回のお話は、プロジェクトが進行する中で発生する、環境構築ミスや思い込み（ヒューマンエラー）によるリスケジュールの回避がテーマです。環境はWeb系のある業務アプリで使用するクライアントPCやサーバーのことをイメージしてください。

効率よくテスト活動を進めるには、特にテスト開始直後の手戻り要因となりがちな環境構築ミスやヒューマンエラーといった事前に対処可能なところを十分抑えておくことが大切です。その対策を何もしなければ、本来必要のなかったスケジュール調整に繋がってしまうと私は考えています。

もしスケジュール調整が発生してしまうと、上記マイルストーンに示したような状態になります。複数のテスト実施予定の変更だけではなく、急な要員調整が発生するなど困難な状況に陥りやすいです。

同じような悩みを持っている方に、少しでも参考になれば幸いです。

テスト開始に向けた対策

環境構築前の確認6W1H

環境構築ミスやヒューマンエラーといった事前対策には6W1Hという分析技法の活用が有効です。

6W1Hは、問題や課題を解決するために、いつ、だれが、何を、どこで、なぜ、どのように行うのかを明確にする技法です。具体的には、「When（いつ）」「Where（どこで）」「Who（誰が）」「Whom（誰に）」「What（何を）」「Why（なぜ）」「How（どのように）」の7つの質問を用いて詳細に分析します。そして、それぞれの答えをまとめることで、問題を解決するための具体的な計画を立てることができます。

この分析技法を用いて、使用するテストケースから必要な環境の洗い出しを行って、どのような環境がテストで必要かをまとめておきます。

私のやり方ですが、テスト環境構築の6W1Hを行い、その分析結果を基に環境構築の進め方を整理して、最後にはストーリーというものを作ることで理解しやすくしています。そうすることで、テスト環境に関わるステークホルダー全員と認識合わせを行う際にも「自分たちはこういうテストをするので、このような環境が必要です。」ということをはっきり示すことができます。また、環境を変更する必要性が発生してしまった際にもすばやい対応ができます。（ストーリーについては後述します。）

ここからは6W1Hで分析するポイントを示します。問題となりやすいポイントを中心に分析することで、環境構築時に発生する問題が見えやすく、事前に解決することが可能になってきます。

＜テスト環境構築の6W1H＞

・When「いつテスト環境を構築するのか」

テスト環境を構築する日程を決めます。

・Where「どこで端末を使用するのか」

どこで端末を使用するのかを決めます。他チームと共用で使用しているような場合はテスト期間中の端末を早めに抑えておきます。

・Who「だれがテスト環境を構築するのか」

環境構築する担当者が決まっているか確認します。また、担当者レベルでは端末の過不足が把握しにくいことがあるため、環境構築する担当者任せにはしないことです。テスト環境を使用する担当者と環境構築する担当者との間で十分に認識を合わせるか、環境構築する担当者と一緒にやるつもりでいることが大切です。

・Whom「だれにテスト環境を使ってもらうのか」

他チームも一緒に使用する可能性がある場合は他チームの要件も確認します。

・What「なにを使用するのか」

テストで使用する環境の組み合わせが揃っているかや端末の初期状態を確認します。

＜確認するポイントの例＞
・テスト対象製品の詳細バージョン
・OSの詳細バージョン（パッチなど）
・その他に使用するツールやアプリケーションと詳細バージョン
・使用するドライバー等
・製品・アプリ・ドライバ類の初期設定と状態
・旧製品の有無（新旧で製品比較が必要な場合など）

・Why「なぜテストするのか」

テストが必要な理由を再確認します。テストする理由と構築するテスト環境に矛盾がないことを確認します。そして、認識齟齬をなくすために、テスト担当者と必要な理由について会話することが大切です。

・How「どのようにテストするのか」

テストしやすい端末の配置を確認します。例えば、新旧製品の画面比較をするような場合には、新旧で横並びになっているかを確認します。もし向かい側に設置されてしまうと、それだけテストがやりにくくなり、進捗が大幅に悪くなってしまいます。

ストーリーとは

環境構築の6W1Hが終わった後はストーリーを作ります。ここでのストーリーとは、テスト環境に関して6W1Hの分析結果を整理したものです。ストーリーには、必ず目的やテーマがあり、環境構築の担当者とそのステークホルダー、出来事やエピソード、それらが起こる場所や時期などが含まれます。以下にその例を示しました。ストーリーは、プロジェクトごとにテンプレートを用意すると効率がよくなると思います。

💡 ＜ストーリーの例＞
目的：システムテスト開始までに期待通りのテスト環境を構築する
テーマ：期待通りのテスト環境が構築されていることを余裕をもって確認する
登場人物：αチームの環境構築の担当者A、αチームのテスト担当者B、端末を共有で使用するβチームのテスト担当者C
When：〇〇要件で、システムテストを〇月〇日から□月□日まで行うことが決まった。
Where：今度のシステムテストでは複数のシステムが連携しており、システムごとに拠点が異なっている。そのため、テストをどの拠点で行うかを確認した結果、拠点Aであった。
また、テスト端末は他チームとテスト期間が重なることが判明し、共有で使用することがわかった。
Who：システムテスト開始の三営業日前までにAさんが環境構築を行う計画を立てた。
その後、Bさんが端末の配置と要件通りにテスト環境が設定されているかをチェックする。
Whom：構築したテスト環境の端末をαチームとβチームで共有して使用するため、Cさんと打ち合わせを行い、必要な数の端末を揃えた。
What：テスト環境は、OSのバージョンはなんでもよく、Microsoft Edgeを推奨ブラウザとしてメインで使用している。
業務アプリは比較のために、新旧製品を用意した。また、テストでは印刷するため、プリンタドライバが必要であり、プリンタのデフォルト設定は顧客の指定通り、モノクロ・両面に設定した。
Why：テスト目的は移行性調査である。
移行性調査とは、非互換機能を正確に把握するために行うもので、特に操作性の観点で、旧製品と同じように動作していなければならない。
How：テストは旧製品と比較する観点があるため、旧製品と新製品を用意し、その端末を横並びになるように配置した。テスト終了後はAさんが端末を次のテストのために初期設定に戻すことになっている。

このようにストーリーを基に関係者間で十分に認識合わせを行うと、どのように環境構築を行うかが明確となり、設定ミスなどの環境構築ミスや、思い込みによるテスト端末間違いなどのヒューマンエラーを未然に防ぐことに繋がります。

上記に加え、以下にテスト実施前に確認してほしいポイントを示しました。参考になれば幸いです。

💡 テスト設計者がテスト環境を確認する
テスト環境はテスト実施する上で非常に重要です。テスト環境で失敗しないためには、テスト設計者が自らの目でテスト環境が正しく構築されていることやテスト条件が揃っているかを確認する必要があります。
これで認識齟齬などのヒューマンエラーは少なくなると思います。

問題が起きてしまったときの対策

ここからは万が一それでも問題が起きてしまったときの対策について、少しだけお話したいと思います。

前述のように考えられる対策をしても、テスト開始直後は、想定外の環境構築ミスがあったり、初めて触るモノだったり、仕様理解が不十分な場合、思い込み（ヒューマンエラー）でテストを行ってしまい、期待結果にならないことがあります。

もし、このようなミスが出てしまった場合には、その場ですぐに何か暗黙知（知らなかったこと）がなかったかをよく確認することと有識者を集めて認識合わせを行うことが大事だと思います。ミス発生直後の問題意識が高い状態で確認や認識合わせを行うことでミスの原因を効率的に特定して、取り除けると考えます。その結果、今後のスケジュール遅延予防に繋げることができます。

それでも問題が続いてしまうような場合には、「顕在化してしまった問題が解決するまでチーム内で助け合う体制を作る。」ということは効果があると考えます。チーム内で助け合う体制とは、例えば問題を抱えている人が何に困っているのかを自らが発信して、同じ問題を抱える人を集めたり、解決できそうな人に協力を求めて解決していくことを指します。

この体制を作る際に大事なことは当事者が問題をどのように捉え、それをどのように解決しようとしているかを明瞭にし、解決するための期間がどのくらい必要かを当事者自らが示すことです。当事者の「やりたいこと」が明瞭化されることによって、はじめて周囲から助けられる状態になります。