転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分でやって、実装も原則自分で書きます。
AIには手順書とレビューと調査を任せている形です。
そのAIを2つ動かしています。
片方が開発の相談役で、もう片方が記録係です。
記録係には、作業時間と到達点を工程管理のデータベースに書いてもらっています。
台帳に間違いが載りました
ある日の夜、開発側が記録係に「今日終わったのは手順4と手順5」と伝えました。
記録係はそのまま台帳に書きました。
翌朝、開発側から訂正が来ました。
手順4の完了条件は、本番環境で実行した直後に公開ページが変わることでした。
その日にできていたのは、手元の環境までです。
原本のほうは読まれていました
引っかかったのはここでした。
開発の記録には、その日の作業が時間まで書いてあります。
読めば、手元の環境までしか進んでいないことが分かる内容です。
記録係はそれを読んでいました。
読んだうえで、短い報告のほうを採っていました。
訂正の範囲は、自分で確かめさせました
指摘は「手順4は未完了」というものでした。
そのまま直すと、隣の手順5も一緒に下げてしまいそうだったので、手順書を読み直してから訂正するよう伝えました。
読み直したら、手順5のほうは3つの条件とも手元の環境で満たせるものでした。
つまり、手順5は完了のままで正しい。
指摘をそのまま広げていたら、今度は逆に過小な記録になっていました。
同じ日の午前、逆の場面がありました
面白かったのは、その数時間前に反対のことが起きていたことです。
開発側が「プルリクエストを作った時点で完了にしてください」と言ってきました。
記録係は、前日までに決めてあった基準を理由に断っています。
翌朝の自動実行を確認してから完了にする、という基準でした。
数十分後、開発側から「進行中のままが正しかった」と返ってきました。
基準を持っている側が、報告に流されずに据え置いた形です。
短い報告は、長い原本より強く見えます
これはAIだから起きた、という話ではないと思っています。
人が何人かいる現場でも、議事録と口頭の報告は別の経路で流れます。
短い報告は、新しくて、短くて、結論の形をしています。
長い原本を読み直すより、そちらを採るほうが自然です。
読んでいなかったのではなく、読んだうえで負けていました。
依頼する側として決めたこと
2つ決めました。
ひとつは、原本と報告が食い違ったら、食い違っている一点だけを原本で確かめること。
全部読み直すと時間がかかるので、範囲を絞ります。
もうひとつは、訂正するときに、指摘された範囲を自分で確かめてから直すこと。
指摘をそのまま広げると、今回のように逆方向へ外れます。
