ポートフォリオ開発で「作れた」と「説明できる」を測ったら、0/8 と 0/27 で2回とも完全に分かれました

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

実装は自分で書くと決めて進めてきました。
分からないところは、AIに「お手本」を出してもらって埋めました。
公開後の細かい修正の工程は、判断を自分がして実装をAIに任せたものもあります。

動いています。
テストもCIも緑です。
期限より14日早く公開できました。

そのうえで、「面接で説明できるか」を基準に、難所を自分で判定しました。

2回とも、0でした。
「動くものを作れた」と「説明できる」は、ここまできれいに分かれました。

同じ1つの工程から、速さと理解が同時に出た

「実装の前に手順書を書く」進め方を試していました。
実装はたしかに速くなりました。

たとえば、色のコントラストとフォーカス表示を直す工程です。
この工程は、4つの論点の判断を自分がして、実装はAIに任せました。
見積は3〜5時間でしたが、実作業は1.4時間で終わりました。
判断に迷う時間が、手順書と実測で消えたからです。

同じ工程で踏んだ新しい概念は5点ありました。
5点とも、「説明できない」でした。

迷わなかったぶんだけ、考えていませんでした。
「手順書に『なぜ』が書いてある」と思っていました。
書いてあるのは資料のほうで、自分の頭のほうではありませんでした。

速さは資料に宿り、理解は宿らなかった。
同じ1つの工程から、両方の結果が同時に出ました。

27点のうち、自分で書いたコードの中にあるのは11点ほどです。
残りは、判断だけして実装をAIに任せた工程から出ています。
ただ、自分で書いた分も事情は同じでした。
手順書どおりに書いて動いたものは、書けても説明できませんでした。

足りていないのは3つだった

「コードを書く力」ではありませんでした。
書けてはいるからです。

3つ目がいちばん効きます。
「知っている」ではなく「たどり着ける」かどうか。
面接で聞かれたときに、その場で答えられなくても、どこを見れば答えが出るかを言えるか。

そこが空いていました。

測っただけで、これだけ出た

「説明できるようにする」工程を立てました。
でも実際には、判定だけやって、説明化は1点もやらずに閉じました。
閉じると決めたのは自分です。

プロダクトは1ミリも変わっていませんが、それでもここまでに書いた発見は全部、測っただけで出ました。

測らないと感想のままでした。
「なんか理解が浅い気がする」で終わっていたところが、0/27という形になりました。
形になると、次に何をするかが決められます。

ただし、27は網羅ではない

集め方は「各工程の完了時に、その工程で話題になった新しい概念を足す」でした。
話題にならずに通り過ぎたものは、最初からリストに入っていません。

自分でもそう申告しました。
聞かれていないところで分かっていないところは、まだあります。

だから27を分母に使わないことにしました。
進捗率にすると、実態より良く見えます。

これは失敗ではなく、決めたことの結果

「学びきらない。手を動かしながら進める」と決めていました。
0/27は、その方針の結果そのものです。
そして、その方針が14日前倒しの公開を生んでいます。

順番の問題だと思っています。
先に動かして、あとから言葉にする。

決めた以上、後半分を回収する工程は置いてあります。
今回はその工程で、回収する前に量を測った段階です。

次からは「なぜ」と「調べ方」を手順書に添えてもらう

予防の形も決めました。

AIと相談して、手順書に「何をするか」だけでなく、「なぜそうするか」と「後から自分で確かめるならどこを見るか」を添えてもらうことにしました。
実装が速いまま、資料に宿った理解を自分の側に移す入口を作る。

効くかどうかは、次に測ったときに分かります。
27点のうち何点が動いたかで判定します。