"自分が見ないと安心できない"のはなんでだろう？
＼オカウチワニが1人でやっている okauchiwani-hitori Advent Calendar 2025 24日目の記事です!!!／
QAの仕事をしていると、こんな感覚に覚えがある人は多いと思います。
"一応、自分で見ておきたい"
"他の人が確認したと言っているけど、最後は自分の目で確認したい"
これは決して悪い感覚ではありません。
むしろ、品質に責任を持とうとしているからこそ生まれる自然な感情です。
ただ、この感覚を個人の頑張りに任せ続けると、どこかで限界が来ます。
今回は、なぜこの状態になるのかと、どうやって仕組みに変えていくかを整理してみます。
責任を引き受ける立場にいるからこそ生まれる感覚
QAエンジニアは、不具合が起きたときに説明を求められやすい立場です。
その経験が積み重なると、
- 自分で見ていないと説明できない
- 自分で見ていれば納得できる
- 少なくとも後悔は減る
という判断になりがちです。
責任を持つ人ほど、不確実な情報よりも自分の確認を信じたくなる。
"自分が見ないと安心できない"の正体の一つは、責任を引き受けているがゆえの健全な緊張感です。
その安心はどこで破綻するのか
"自分が見れば安心"は、短期的には強いです。けれど、前提が崩れる瞬間があります。
1つ目は規模です。確認対象が増えると、目が追いつきません。
確認しきれない現実に直面した瞬間、意識でも無意識でも、悪い効率性に走る恐れがあります。
2つ目は速度です。リリース頻度が上がるほど、休む余裕がとれなくなります。
スイッチングコストも下がらず、誤解が起こりやすくなります。
3つ目は体調や集中力。"自分の目"は品質が一定ではありません。
疲れている日、忙しい日、気が散っている日で精度は揺らぎます。
このような点が自分のペースではなく、重なって訪れることがあります。
それを意識だけで、自分だけでは厳しいことは出てきますね。
諦めるわけじゃない、それを広げる
そのプロダクトの品質を一手に担った立場であれば、
2人目、3人目のQAエンジニアが入ったり、スクラムチームでテストをしてもらうようになると、
負荷が減る一方で仕事が奪われるような感覚にとらわれることもあります。
また自分が品質を守ってきたことも乗っかり、
自分がやってないテストの結果に過剰に心配になってしまうことも。
ただそこは成長の機会かも知れません。
個人の安心をチームに広げる過程で必ず通るステップとして、
変化を受け入れて自分も変わっていくことが大事です。
過去の自分が"自分で見る=安全"というルールを作っている
過去に、
- 自分が見なかったところで不具合が出た
- 他人の確認を信じて失敗した
- "見ておけば防げた"と後悔した
こうした体験があると、無意識のうちに
"見ない = 不安"
"見る = 安全"
というルールが頭の中にできます。
これは人間として自然な学習ですが、
チームの体制やプロセスが変わっても、このルールだけが残り続けることがあります。
結果として、必要以上に自分で抱え込んでしまいがちです。
果たして、今のチームやプロセスもそれを望んでいるのでしょうか？
"安心の正体"を分解して仕組みに落とす
この感覚をどう仕組みに変えていけばいいのでしょうか。
ポイントは、安心の正体を分解することです。
自分は何を見て、何が分かると安心しているのか。
- どの条件が満たされていればOKなのか
- どの変更が入ると不安になるのか
- 何が分からないと判断できないのか
これを言語化して外に出します。
- 受け入れ基準を整備する
- ダッシュボードで品質状況を可視化する
- ログやメトリクスで異常を拾えるようにする
- 定性的な基準を少しでも文章として残す
こうしていくことで、自分の判断を外に出していき、
"自分が見なくても判断できる状態"が少しずつ仕組み化することができます。
まずは"毎回同じ理由で見ている部分"を外に出すだけで十分です。
そこを面倒くさがっていないか、ちょっとだけ考えてみましょう。
まとめ
"自分が見ないと安心できない"という感覚は、QAエンジニアとしてとても自然なものです。
- 責任を引き受けてきた経験
- 過去の失敗から学んだ防衛反応
- 安心の拠り所が自分に集中している状態
これらが重なって生まれています。
大切なのは、この感覚を否定することではありません。
安心の正体を分解し、外に出していくことです。
自分の目で守ってきた品質を、次は仕組みで守れるようにする。
それができたとき、QAエンジニアが"1人でテストを頑張り続ける役割"から一段進めるはずです。
Discussion