これを読めば、明日から上司の「それ、ちょっと違うな」と言う差し戻しがなくなります。

こんにちは、まままです。
僕が仕事をする上で大切にしていることをシェアしたくて記事書きました。

では、早速…

はじめに

僕は、新人の頃は、仮説を持つなんてこと一才していませんでした。
仮説を持つ意識をするようになったのは、僕が勝手に師匠認定している人からの一言がきっかけになりました。
「このテスト設計でどんな仮説持ってるの？どこがバグりそうか、どこでバグが起きたらヤバいかを考えないと。」
この一言がきっかけになり、テスト設計以外の仕事に対しても「自分なりの仮説」を持つようになりました。
エンジニア(特にQAエンジニア)は、仮説を持つということが仕事をする上でかなり重要な要素のひとつになります。
仮説を持っていないと、的外れなテストをしてしまったり、改善結果が得られなかったり、、、と結局コストをかけただけ、プロセスを重くしただけと、成果に結び付かずに終わってしまうことになります。

仮説って？

その作業に対する目的、目指したい部分、最終的にどうしたいか、というような内容を明確に持つことが仮説を持つということになります。
と、ちょっとややこしいことを言いましたが、
簡単に言えば、作業のゴールを明確にすること、何のための作業なのかをはっきりと理解することです。
これは、こうだろう。と考えれればOKです。

では、実際に仮説を持つとはどうゆうことなのか？をテスト設計とプロセス改善の場合で見てみます。

テスト設計での仮説
そのテストで何を確認したいのか、なんの担保をしたいのかを明確にすること、テスト結果で得たいことと言ったことが仮説になります。

イメージが付きやすいかと思いますが、
A機能のテストが目的なのに、B機能、C機能のテストケースを設計／実施していた
ブラウザ毎の挙動確認が目的なのに、レイアウトしか確認していなかった
性能テストで画面レスポンスを測定したはいいが非機能要件がなかったり、基準がなく、正誤が付けられない
といったように、仮説を持っていないとテストの目的からズレてしまったり、結局何を確認したいテストなんだっけ？、となってしまいます。

プロセス改善での仮説
プロセス改善をする場合は、何かしらの課題があり、それを是正したいが前提にあります。
プロセス改善の工程の中で、課題の見える化→ボトルネックの特定→改善施策立案→改善施策実施と進みます。

改善施策を実施する前に、その効果を予測するための仮説を立てる必要があります。
仮説を持つことで、その改善施策で何をどうしたいのか？、どこを目指したいのかを明確にすることができます。

例えば、
課題:デプロイの度の人力でのテストに工数がかかり過ぎている、デプロイの度に作業が発生するので繰り返し作業になっている。
改善施策:自動化ツールの導入。
仮説:自動化ツールの導入によりテスト時間が30%短縮されるはず。
とプロセス改善をする場合、

ゴール(仮説)を持っていることで、実際にツールを導入後の効果を測定できます。
もし、仮説が正しければ、その結果をもとに他の部分にも自動化を適用し全体のテスト効率をさらに高める等、他への展開も検討しやすいです。

仮説の大切さ

ここまで読み進めていただきありがとうございます。
今、仮説を持つこととは？に対して、フワッとでとイメージを持って貰えてたら嬉しいです。
ここからは、仮説を持つことの重要性やメリットに関してです。

前述した内容と重なる部分ありますが、
仮説を持って作業を進めることの重要性と、その具体的なメリットについて詳しく見ていきます。

1. 明確な目標設定(ゴール)と方向性を定める
仮説を立てることで、作業の目標が具体的になります。
これにより、明確な目標が設定ができます。
結果として、目標に向けた具体的な戦略や施策を立案しやすくなり、チーム全体が同じ方向を目指して協力する基盤にするとこもできます。

2. 効率的なリソース配分に繋がる
仮説を持つことで、限られたリソース（時間、予算、人材）を最適に配分できます。例えば、複数のテスト実施をする際に、仮説に基づいて品質リスクが高いと予測される機能に重点的にリソースを投入することで、最大のテスト効果を引き出すことができます。このアプローチにより、無駄なリソースの浪費を防ぎ、効率的なテスト運営が可能になります。

3. データに基づく意思決定ができる
仮説を立てて作業を進めることで、結果をデータに基づいて評価できます。予測された結果と実際の結果を比較することで、仮説の妥当性を検証し、次のステップに向けた貴重な洞察を得ることができます。
データドリブンな意思決定は、直感や経験に依存するよりも、より客観的で信頼性の高い結果になります。

簡単に言うと、
・ゴールを明確にできる
・無駄なコストを使わずにすむ
・数字やデータで判断できる
ってことです。

仮説を作ろう

ここまで読んでみていかがでしょうか？
最後は仮説ってどうやって作るの？を見ていきます。

1. 現状分析
現在の状況を正確に把握し、問題点や改善点、目指すべき姿(ゴール)を特定します。
問題点を洗い出したり、最終的な目的を固めます。
重要な点は、細部までを確実に理解した上で進めることです。
テストする機能、テストで確認したい項目、なんでテスト作業が発生したのか、どこの品質担保が必要なのか、等、作業に関連するとこを全部洗い出してみてください。
また、プロセス改善の場合は、課題は何なのか？、その課題の根本な部分は何か？、なんでその課題の解消が必要なのか、等、なぜなぜとかでどんどん深掘りしてみてください。
大枠での理解のまま分析をしても、必要としている詳細な分析はできません。
現状分析をすることで仮説を持つ上でのネタ集めに繋がります。

2. 仮説設定
現状分析で集めたネタを元に明確で検証可能な仮説を立てます。
現状分析ができていれば、目指すべき姿(ゴール)、根本的な課題のイメージができているはずです。
以下を意識して仮説を立てます。
具体化: 仮説は具体的かつ測定可能な形にします。SMART（Specific, Measurable, Achievable, Relevant, Time-bound）な仮説が理想です。
前提条件の確認: 仮説が依存する前提条件を明確にし、その妥当性を確認します。

・この部分の品質を担保するから、このテストが必要
・今回の品質目標に合わせて、このテスト戦略が必要
・この課題は、こんな改善施策が必要で、結果としてこの改善結果を得られそう
とかを考えれていたらバッチリです。

現状分析→仮説設定と当たり前のように見えますが、他の人から依頼された仕事やたまたま自分が担当になったテスト設計とかだと、意外と仮説を意識できていなかったり、自分の中の仮説をしっかりと持てていない場合があったりしませんか？最初はどうしても難しい部分があるかもですが、意識する、作業する前にまずは仮説を考えることをすると自ずと作業品質も作業に対する齟齬もなくなるはずです。　
仮説を持つということを常にできるようにクセを付けられればバッチリかなと思っています。

また、IT業界の特性上、SESや派遣でお客様の現場に入るということもあると思います。
その場合も、作業の依頼主と、「作業のゴール」、「なんのための作業なのか」を明確にできるとgoodです。
(ブラックでそんなこと言ってられない等、ちょっと話がそれちゃうツッコミパターンもあると思いますがこの記事ではノーコメントとさせてください(そんな現場、会社がなくなることを願ってます))

おわりに

僕のマインドの一つでもある「仮説を持つ」と言うことに関して記載しました。
先輩方からのここは違くない？、とか、仮説思考の理論と少し違ったり、とかあると思いますが、そこはご了承ください。
この記事が、QAエンジニアとしての仮説を持つことに関して何かの気づきや、仕事や人生に少しでも役に立てば幸いです。では。