仮説を立てて検証する

学習の目的

この単元を完了すると、次のことができるようになります。

• 解決策の仮説を検証するメリットを理解する。
• テスト手順をすべて記録することの価値を理解する。

根拠を基に推測してテストする

あなたの調査と再現によってユーザーの問題に対する解決案の方向性が示されました (多分…)。次は、収集した知識と経験に基づいて、リストの中から最も可能性が高い解決策を選択してテストします。最初に選んだ解決策がうまくいくとは限りません。けれども、うまくいかなかった解決策から有益な情報が示され、根拠に基づく後続の推測に役立つことがあります。 

繰り返しますが、本番組織でテストしないことを強くお勧めします。Sandbox 組織は、この場合のように、隔離された環境でのテストや開発を目的に構築されています。Sandbox 組織で実行されたアクションが本番組織に影響することはありません。また、Sandbox 組織は複数作成できるため、さまざまな段階のテストを実行できます。

テスト手順を記録する

ユーザーの問題に対して最も可能性が高い解決策を選択してテストするときは、実行している手順を記録します。トラブルシューティングでよくある間違いは、解決策の最後の手順のみを記録することです。場合によっては、あなたが試したさまざまなことが積み重なって解決に至ることがあります。そのため、実際の解決策に至るために必要なすべての手順を必ず記録します。 

各テストのそれぞれのステップを記録した場合の主なメリットとして、このテストドキュメントを次の 3 通りの方法で活用できます。

• 問題をどのように修正したかよく覚えていない場合に参照できる。
• テストを何度も繰り返すときに、作業の重複を回避できる。
• 解決策が実際に機能した場合に記録に残すことができる。

テストの操作は必ず記録します。 

推測を繰り返す

最初の推測が当たらなかったかもしれません。そんなこともあります。むしろ、想定内です。トラブルシューティングは容易なことではありません。トラブルシューティングの主な秘訣の 1 つは粘り強さです。解決案をテストし続けます。解決案のリストに戻り、次の候補をテストします。うまくいくまで繰り返します。根拠に基づく次の推測がうまくいくかもしれません。

徹底的にテストする

うまくいきましたか? おめでとうございます! [紙吹雪を用意してください!] お祝いする前に、その解決策があなたと影響を受けるユーザーの両方で機能することを確認します。ユーザーのシナリオに示されているすべての変数 (操作、時間、場所、ブラウザーなど) を可能な限り再現します。このユーザーとしてテストしたら、別のユーザーとしてテストし、この条件下でテストしたら、別の条件下でテストし、念のためにもう一度テストします!

このすべてをテストするために、新しい Sandbox のまっさらな状態から始め、解決策として記録した全手順を実行する必要のある場合があります。実際には修正されていないものを修正されたとみなして、自分自身や他の人々にストレスをもたらすのは望ましいことではありません。解決策がすべてのテストに合格したら、お祝いしましょう! 

完了、ですよね?

仮説を立て、操作を記録し、複数の解決案を試して、最終的に適切な解決策を見つけました。すべてが終わったところでログオフし、デスクを片づけて、くつろぐことにして...、もいいですよね? 残念ながら、そういうわけにはいきません。次のステップでは解決策を実施して、解決した問題の再発防止に取り組みます。