転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
開発は工程に分けて進めていて、工程ごとに手順書を作っています。
手順書はAIに書いてもらって、実装は自分でやる形です。
その手順書の中に、次の工程で踏みそうな落とし穴も書いておいてもらいました。
データベースの権限まわりで、2つ書いてありました。
その工程が終わったので、答え合わせをしました。
結果がきれいに3つに割れたので、記録に残しておきます。
予見した2つと、予見できなかった1つ
ひとつ目は、管理画面のSQL実行では権限の制限がかからない、という注意でした。
手順書の冒頭に書いてあったので、そのまま避けられました。
書いていなければ、制限が効いていないことに気づかず先へ進んでいたと思います。
ふたつ目は、権限で弾かれたとき、エラーではなく「0件更新しました」という形で返ってくる、という話でした。
これは予見どおりに踏みました。
しかも、そのとき自分がどう誤解するかまで手順書に書いてあって、書いてあるとおりに誤解しました。
読んでいたのに踏むのかと思いましたが、書いてあったおかげで数分で戻れています。
みっつ目は、予見していなかったものです。
権限の設定が二段構えになっていて、片方だけ設定しても通らない形でした。
この工程で止まったのは、ここだけでした。
時間の内訳
工程全体の見積は8時間でした。
実際にかかったのは4時間です。
手順書の前半と後半で分けても、どちらも見積の半分でした。
偏りがあったわけではなく、全体的に速く終わっています。
止まったのは、予見できていなかった1箇所だけです。
手順書は、時間を短くする道具ではなかった
半分で終わったので、最初は手順書があると速いという話だと思いました。
ただ、内訳を見ると少し違います。
速かったのは、既に知っている罠を知っているまま通れたからでした。
書けた罠は消えて、書けなかった罠だけが残る。
当たり前といえば当たり前ですが、実際の時間で出てくると納得感が違いました。
手順書の価値と限界が、同じ工程の中で同時に出た形です。
予見の数を増やすより、予見できない部分にどれだけ余裕を取るかのほうが効きそうです。
