転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
進め方は、AIに手順書を書いてもらって自分で実装する形です。
設計の工程が終わった日に、その日のやりとりを振り返りました。
AIが出した案を、3回却下していました。
丸投げしない、というのは言うだけなら簡単です。
実際に何が起きたのかを書いておこうと思います。
1件目、押せる範囲が狭くなっていました
カードをクリックすると中身が開く画面を作っていました。
AIの案は、押せる範囲をカードの見出し行だけにする、というものでした。
使ってみると押しにくいので、カード全体を押せるようにしたいと伝えました。
やりとりして分かったのは、AIが2つのことを混ぜていたことでした。
ひとつは技術的な制約です。
ボタンの中にリンクを置くことはHTMLの仕様上できません。
これは本当の制約です。
もうひとつは、どこを押せるようにするかという設計の話です。
こちらは自由に決められます。
制約のほうに引きずられて、設計の幅まで狭くなっていました。
開く部分をボタンの外に出す形にしたら、両方とも成立しました。
2件目、同じ言葉が2つのものを指していました
開いたカードを閉じたときの隙間について、埋めない、という案が出ました。
後ろのカードは繰り上がってくるのではないか、と聞き返しました。
ここも言葉のせいでした。
閉じたときに後ろのカードが詰めて並び直すことと、空いた場所に別のカードを差し込むことを、どちらも隙間という言葉で話していました。
前者は必要な動きで、後者は要らない動きです。
そのまま案を受け入れていたら、必要な動きまで止めていました。
3件目、枠の外に出たら問題が消えました
一番大きかったのは3件目です。
公開ページのURLと、管理画面のURLが衝突しそうだという論点がありました。
AIは解決案を4つ出してきました。
4つとも、ルートの直下をどう分けるかという話でした。
どれも成立しますが、どれも複雑です。
サブドメインに置けばいいのでは、と言ったら、それで終わりました。
分ける必要そのものが無くなったからです。
この論点は、その工程で一番重いと見積もっていた部分でした。
それが問題ごと消えました。
2種類ありました
あとから並べると、1件目と2件目は同じ型でした。
説明の中で2つのことが1つの言葉になっていて、そのまま受け取ると仕様が狭くなります。
3件目は種類が違いました。
与えられた枠の中では、4案とも正確です。
枠そのものを疑う、というところだけが抜けていました。
気づけたのは、中身を分かって進めているからでした
この工程は見積8時間に対して5.5時間で終わっています。
速かったのは、描く作業を任せたからです。
ただ、判断のほうは渡していません。
渡した直後に1件目の却下が起きているので、そこは分けて進めていたことになります。
自分で実装するというルールを守っているから、案のおかしさに気づけます。
全部やってもらっていたら、3件とも通っていたと思います。
