転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
同じ種類の失敗を3回やっていました。
書いたテストが壊れていても合格を返す、という形です。
テストは通っているのに、実は何も確かめていない状態でした。
3回目のあとに、手順書へ歯止めを入れました。
着手する前にひとつ問うだけの、短いものです。
このテストが不合格になるデータを、いま自分は持っているか。
歯止めを通したら、着手前に2件見つかりました
次の工程でこの1問を実際に通してみました。
手を動かす前に、2件見つかりました。
どちらも、そのまま書いていたら合格を返すだけのテストになっていたものです。
うまくいった、と思いました。
そして、これを記録に書くとき「教訓の4回目」として並べようとしました。
止められました。
前の3件とは、立っている場所が違いました
言われて並べてみたら、確かに違いました。
前の3件は、踏んでから気づいています。
テストが合格を返して、それから壊れていることが分かりました。
今回は、着手する前です。
きっかけも、自分で入れた歯止めを実行したことでした。
前の3件は教訓の更新で、今回は仕組みが効いた1件目でした。
まずいのは、次に読んだときでした
4回目として並べると、記録の上ではこう見えます。
3回直したのに4回目が出た。
つまり、効いていない、と読めます。
実際には逆で、仕組みが働いた最初の記録です。
改善の証拠が、悪化の証拠として残るところでした。
何回目かより、どちら側で見つけたか
数え方の問題だと思っています。
再発の回数を数える欄は、失敗の回数として作ってありました。
未然に止めた回を置く場所がありません。
置く場所が無いので、いちばん近い欄に入れようとしました。
それが失敗の欄でした。
歯止めを入れても、それが効いた証拠を残す場所を作っておかないと、効果が見えないままになります。
同じ出来事でも、どの欄に書くかで逆の結論になりました。
何回目かを数える前に、踏んだのか、踏む前に止めたのかを分けるほうが先だと思います。
まだ1件しか無いので、これで直ったと言えるところまでは来ていません。
