転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
実装で難しかった箇所を、27点挙げていました。
それを「面接で説明できるか」で自己判定したら、27点中0点でした。
その話は前の記事に書きました。
この記事は、原因を探した話です。
探したら、確認の仕方の問題でした。
そして、直したつもりの確認にも、まだ隙間がありました。
最初の見立ては「バックエンドに歯が立たなかった」だった
自分では、こう思っていました。
データベースも認証もキャッシュも初めてで、バックエンドの領域に踏み込んで歯が立たなかったのだと。
全部自力でできたらフルスタックでは、とすら思っていました。
27点を、AIに領域で割ってもらいました。
| 領域 | 点数 |
|---|---|
| React・フォーム・フレームワークの作法 | 7 |
| CSS・Tailwind・アクセシビリティ | 8 |
| DB・認証・キャッシュ | 8 |
| TypeScript・テスト・設計 | 4 |
バックエンド寄りは8点だけでした。
残り19点はフロントエンドです。
しかも、CSSとアクセシビリティの8点は、Web制作の実務で何年も触ってきた、いちばん得意なはずの領域でした。
得意な領域でも説明できていない。
領域の問題ではありませんでした。
確認の仕方の問題でした。
確認はしていた。ただし全部「聞く」側だった
原因を整理していたとき、「理解を測る工程が最後にしか無かったのでは」とAIに言われました。
違和感がありました。
各工程で理解確認はしていました。
分からないところは、その都度聞いていました。
自分の感覚はこうです。
AIに解説してもらいながらだと、理解できた気になる。
でも改めて自分で解説しろと言われると、できない。
つまり、確認はしていたけれど、全部「聞く」側でした。
解説を読んで納得する。
それを確認と呼んでいました。
「先に答える」仕組みが、1工程にだけ存在していた
AIが手順書を検索したら、ある工程にだけ「本人レビュー関門」という節がありました。
完了条件は「3問に本人が答えられたこと」。
AIが解説するのではなく、本人が先に答える形式です。
1. ログインしていない人がこのデータを読むとどうなるか
2. ログイン中の人が他人のデータを読むとどうなるか。それは意図どおりか
3. 他人のIDを関数に渡したらどうなるか
1問目で外しました。
「対象を指定した＝制限した」と読んでいましたが、実際は許可の範囲が1ミリも変わらない変更でした。
手順書に答えが書いてある箇所そのものです。
2問目は自力で正解しました。
3問目は結論だけ合っていて、理由が違っていました。
「合っている」で流さずに済んだのは、理由まで言わされたからです。
| 形式 | 使われた範囲 | 検出した誤解 |
|---|---|---|
| AIが解説する。本人は聞く | ほぼ全工程・16日間 | 0件 |
| 本人が先に答える | 1工程だけ | 1件 |
なぜ1工程だけだったか
その工程は「実装を全部AIに任せる」と決めた工程でした。
だから、せめて理解確認だけは自分に通させよう、という意図で置かれていました。
分担の都合で偶然生まれた仕組みです。
1回試して当たっていたのに、横展開する発想が誰にも無かった。
発明済みのものが、1工程に置き去りになっていただけでした。
関門を通したのに、貼る直前で「説明できない」が出た
関門を次の工程にも置きました。
設計判断を3問、口頭で答える形式です。
このテーブルに所有者IDを持たせるか、といった問いでした。
3問とも自力で正解して着手条件をクリアし、そのまま実装に入りました。
そして、SQLを貼る直前で「説明できない」が出ました。
関門は機能していた。見ていた層が違った
関門が確かめたのは設計判断です。
「このテーブルは2段たどらないと所有者に届かない」と分かっているか。
でも、その判断がSQLでどう書かれるかは、一度も聞いていませんでした。
2段たどるポリシーをSQLとして書くのは、この工程が初めてでした。
それまでのポリシーは、全部1行で済んでいました。
口で答えられることと、コードとして読めることは別でした。
関門は設計判断の層を見ていて、実装の層を見ていませんでした。
同じ日、前の工程で説明済みのことも定着していなかった
同じ日に、「マイグレーションファイルとは何か」という質問も出ました。
これは前の工程で説明済みでした。
でもそのときは、手順どおり打つだけで、疑問が出る場面がありませんでした。
今回は自分で3ファイル作る場面があったので、疑問が出ました。
定着は「説明を聞いた回数」ではなく、「自分で作る側に回ったか」で決まっていました。
関門も口頭の問答だったので、同じ穴を通していました。
「答えられるか」から「書けるか」へ
読んで納得した状態と、答えられる状態は別物でした。
その違いは、出力させないと見えません。
さらに、答えられる状態と、書ける状態も別物でした。
その違いは、書かせないと見えません。
チェックを作るときは、そのチェックが見ている層を確かめる。
設計判断を確かめる関門は、実装できるかを確かめていない。
確認を「答えられるか」で終わらせず、「書けるか」まで持っていく。
一段ずつ、確認の場所を下げていく形になりました。
余談ですが、プロフィールに「説明できることを大事にしている」と書いた翌日、
「これって当たり前にできるものでは？」と自分で思いました。
反証は自分のデータにありました。
当たり前だと思っていることほど、測ると0点だったりします。
