どうやればプロダクトをアンラーンできるか？

＼オカウチワニが1人でやっている okauchiwani-hitori Advent Calendar 2025 17日目の記事です!!!／

プロダクトに長く関わっていると、いつの間にか"当たり前"が増えていきます。
この画面はこう使うもの、この操作はこの順番、この挙動は仕様。
最初は一つひとつ確認していたことも、気づけば無意識に前提として扱うようになります。

この状態は効率的ではありますが、一方でリスクも孕んでいます。
それが、プロダクトを"理解しているつもり"になることです。
今回は、QAや開発に関わる人ほど意識しておきたい、プロダクトのアンラーン（学び直し）について考えてみます。

なぜアンラーンが必要になるのか

プロダクトは常に変化しています。
仕様が追加され、ユーザー層が広がり、使われ方も少しずつ変わっていく。
それにも関わらず、人の理解は過去の成功体験に引っ張られがちです。

例えば、

• 昔はこの導線で問題なかった
• この設定は誰も触らない前提だった
• このエラーは実運用では起きないはず

こうした前提は、ある時点では正しかったかもしれません。
ただし、時間が経つと前提はトリガーもなくズレていきます。
ズレに気づかないまま判断を続けると、ユーザー視点や新しい利用シーンを見落としやすくなります。

アンラーンが必要になるのは、知識が古くなるからではありません。
"知っている"という感覚が、疑問を持つ力を弱めてしまうからです。

プロダクトをアンラーンするための視点のずらし方

アンラーンは、知識を捨てることではありません。
視点を意識的にずらす行為に近いです。

まず効果的なのは、初期状態から触り直すことです。

• 新規ユーザーでログインする
• 初期設定を一つずつ進める
• なんとなくで理解していたの前提条件を1つずつ理解する
• エラーや制限に意図的にぶつかってみる
• 表示されるメッセージを言葉通りに動作させてみる

慣れたアカウントや完成されたデータを使うと、途中の違和感に気づきにくくなります。
あえて不便な状態から触ることで、"なぜこの手順が必要なのか"が見えてきます。

次に有効なのは、言語化です。
無意識に操作している部分を、あえて言葉にしてみる。

• 今、何を期待してこのボタンを押したのか
• 画面遷移後、何が起きると思っていたか
• 期待と違った場合、どこで迷うか

頭の中で完結していた理解を外に出すことで、前提のズレが表面化します。
アンラーンは、違和感を言葉にした瞬間から始まります。

機会によってアンラーンするきっかけが出来ることも

この記事を投稿しようとしたきっかけも、今まで実施する機会が少なかったある条件からでした。

• 大量のユーザーを作成する必要がある
• それらのユーザーに機能を利用できるように前提条件を設定する
• これらを手順書にまとめる

1つ、2つのアカウントであれば少し手を動かして設定完了としていたところですが、
大量のユーザーとなるので、クエリでデータ作成を試みた方が効率的。
では、機能を利用する為の前提条件ってなんだろう？意外にしっかり説明できなかった。

そこで、丁寧に学び直しをしてみたところ、2つぐらいの前提条件かと思っていたのが、
合計4つの条件を含むことがわかりました。

QAエンジニアだからこそできるアンラーンの作り方

QAエンジニアは、プロダクトを最も長く、最も多角的に見続ける立場にいます。
だからこそ、アンラーンしにくくもあり、同時に最も必要とされる役割でもあります。

QAエンジニアが意識したいのは、答えを出すことより問いを持ち続けることです。

• 本当に今のユーザーも同じ前提で使っているか
• この仕様は誰のために存在しているのか
• 過去の判断が今も最適と言えるか

こうした問いは、過去の自分の理解すら疑う姿勢から生まれます。
一度決めたことを守るのではなく、必要なら壊してもいいというスタンスが、アンラーンを支えます。

また、チームの中で"初見の視点"を守ることも大切です。
新しく入ったメンバーの素朴な疑問や、違和感を軽視しない。
それはプロダクトが変化しているサインかもしれません。

まとめ

プロダクトのアンラーンは、知識の前提を疑い、視点を更新し続ける行為です。

• 長く関わるほど"当たり前"は増える
• 当たり前は気づかないうちにズレていく
• アンラーンは違和感を拾い直すことから始まる

QAも開発も、理解が深まるほどアンラーンが難しくなります。
だからこそ意識的に、もう一度初めて触るつもりでプロダクトを見る。
その姿勢が、品質を次の段階に引き上げてくれます。