バツを見て先に手が出る癖を、TDD の語彙で言い直してみた話。問題集はテストシナリオで、目的は問題を解く事じゃなく『自分をグリーンにする事』。失敗確認駆動として育児に持ち込んでみた、育児フレームワーク 第 2 回。
「またバツや」
算数のプリント、上から 3 問連続で赤ペン。子が口を尖らせている。
正直、ちょっと前の私なら「あ〜あ」と言って、次の問題のヒントをそっと出していたと思う。
前に 子どもの失敗、勝手に拾ってた というのを書いたんですが、あれを書いてからも、染み付いた癖はそんなに簡単には抜けなくて。バツが並んでるのを見ると、つい先に手が出る。
ただ、最近は、もう少しだけ黙って見ていられるようになりました。理由を言語化してみたいと思う。
これ、頭では分かってる人多いと思うんですが、いざ我が子のテストの点数を見るとそうもいかない。私もそうです。
ただ、自分が大人になって振り返ってみると、覚えてるのって、だいたい 間違えた所 なんですよね。スラスラ解けた問題の方は、もう覚えてない。
ここで一度、自分の中の定義を書いておきたい。
この 3 段目までやって、はじめて勉強だと、私は思っています。
問題を解くだけ、では勉強じゃない。
答え合わせまで、でもまだ勉強じゃない。
採点して終わり、丸が多い少ないで一喜一憂して終わり、だと、学力は上がらない。間違えた所を覚えるから、学力が上がる。そこが一番大事。
…と書いておいて、自分も子供の頃は採点で終わってた側なので、偉そうなことは言えないんですが。
ソフトウェア開発の現場には (最近はあまり聞かなくなったけど)「バグ曲線」という物があります。テスト工程でどれくらいバグが見つかったかを時系列でプロットするやつ。
面白いのは、現場の感覚として「テストしてバグが 1 つも出ませんでした」と言われると、逆に 大丈夫か? という空気になることです。
なんでかと言うと、開発の現場は 人はミスする という前提に立ってるから。
ミスが出ない方が異常で、出てない時はテストの方を疑う。0 件はゴールじゃなくて、たいてい「テストが甘い」のサイン。
ここがこの記事で一番言いたい所かもしれません。
開発の世界の話なのに、「人はミスする前提」って言った瞬間に、その知見、別に開発の中で閉じてなくないか、と。
人は、つまり、子も、私も。
人がミスする前提で組まれた仕組みは、たぶん勉強にもそのまま流用できる。バグが出ない状態を理想にしないのと同じで、バツが出ない状態を理想にしなくていい。
知らない人向けに、ざっくり TDD (テスト駆動開発) というのは、
def test_add():
assert add(1, 2) == 3 # ← 先に「答え」を書く (今は落ちる = Red)
def add(a, b): # ← 後から本体を書く
return a + b # ← テストが通れば Green
先に「こうなるべき」というテスト (答え) を書いて、落ちる状態 (Red) から始めて、通るように実装を直していく。そのループです。
これ、書きながら思ったんですが、問題集 って、もう完全にこれ。
そして子 (= 実装される本体) はまだ赤い。だから解く。間違える (Red のままになる)。答えを見て、なぜそうなるかを取り込む。次に似た問題が出た時、通る (Green)。
問題集を解く目的は、目の前の問題を解く事じゃない。
自分をグリーンにする事。
そう捉えると、バツがついた瞬間にがっかりするのも、ちょっと違う気がしてきた。バツは Red、ただのテスト結果で、これから直すべきポイントの場所を教えてくれてる、という意味でしかない。
「失敗確認駆動 (Failure Confirmation Driven)」、内容としてはここに着地。
書いてみると当たり前のことしか言ってないんですが、TDD の語彙を当てると、自分がなぜ子のバツを見て焦らないようにしてるのか、ちょっと説明しやすくなった気がしてます。
子供には、こう言ってる。
「問題を解くのが勉強じゃない。バツはいくらあったって良い。バツを理解する事が勉強だから。逆に何を理解すれば伸びるのかが分かって良かったね」と。
納得出来ない顔をしていたから、問題を出してみた。
1+1=?、1+2=?、1+3=?
もちろん、すぐ答えられる。
「成長した?」
「しない。だって分かってるもん」
「全部マルだったら、やる意味ないでしょ。バツを見つける為にやってるから。バツを見つけたら、成長できるのを見つけられたと思って」
当たり前の事なのかも知れないが。
そう思うと、宿題の問題を解く意味も変わってくる。先に予習してから、問題を解くのも良いんじゃないかな。問題はテストシナリオなんだから。