長く使っていたトラックパッド用アプリの旧版が、OS更新後に動かなくなった。代わりを探す前に、実際に使っていた機能を数えてみた。Chromeのタブを閉じる、開く、移動する。この三つだった。
全部入りのアプリを再現する必要はない。この三つだけを持つMacアプリを作れないか。AIにそう頼むと、ファミレスで料理を待つ約15分の間に初版ができ、試した三つの操作は動いた。開発未経験の自分にとって、大きな変化だった。
ただし、15分は初版が動くまでの一例だ。誰でも同じ時間で作れるという話でも、業務用として十分な検証が終わったという話でもない。
作る範囲を狭めたから、確かめる範囲も見えた
今回よかったのは、依頼が『便利なアプリを作って』ではなかったことだ。困っている操作と、いらない機能を先に分けられた。三つの動作なら、期待どおりかを自分でも確かめられる。
もし多くの機能を再現しようとしていたら、作る量だけでなく、動きを確認する量も増えていたはずだ。欲しいものを小さくすることは、開発を速くするだけでなく、自分が良し悪しを判断できる範囲に収めることでもある。
一方、今回確認できたのは試した環境での操作だ。再起動後にも使えるか、他のアプリの操作と衝突しないか、OS更新後はどうか。継続して使うなら、初版とは別に確認したい。
既製品を使う、設定で済ませる、自分で作る
小さく作れるようになったからといって、何でも自作すればいいわけではない。まず既存機能や設定変更で解決しないかを見る。既製品に欲しい機能があり、更新やサポートも任せたいなら、その対価を払う意味はある。
自作が候補になるのは、必要な動作が限定され、使う人が少なく、失敗しても元の操作に戻せるような場面だと思う。反対に、請求額や顧客への送信、品質記録を直接扱うなら、『動いた』だけでは採用できない。誤りを見つける方法と、修正する担当まで必要になる。
比べたいのは作る費用だけではなく、使い続ける手間だ。安く作れても、自分しか直せず、止まるたびに仕事を中断するなら、その負担も自作の費用になる。
引き継ぎ資料も、成果物の一部だった
MacBook Proで作ったものを常時起動のMac miniへ移す際には、実装内容と使い方をまとめたMarkdownも作ってもらった。後で見たときに、何を作ったか分かる状態が残った。
会社で同じことをするなら、この説明に『何ができないか』『どこに保存しているか』『止まったらどう戻すか』も加えたい。AIとの会話を全部読み直さないと使えない状態では、仕事の道具になりにくい。
環境整備でも、変更の前に現物を見る
別の日には、古い設定が積み重なった開発環境も整理した。以前なら調査と更新に1〜2週間かけていた作業が、その回は約15分で終わった。これも自分の経験上の比較で、同じ作業を同条件で測った実験ではない。
重要だったのは、いきなり新しい設定を上書きしなかったことだ。実際の設定や導入済みツールを見て、残すものと更新するものを考え、影響が読みにくい変更はバックアップしてから進めた。
会社の小さな業務改善でも、先に現状を見ずに『AIで作り直そう』と始めると、今の手順が守っている条件を落としかねない。まず一つの手間を選び、必要な機能と確認方法を決め、戻せる状態で試す。その順番で考えたい。
15分で作れたこと以上に価値があったのは、必要なものを小さく定義すれば、自分でも改善を試せると分かったことだ。ただし、試作品を作る判断と、会社の仕事を任せる判断は分ける。その線を引いてこそ、この選択肢を長く使えると思う。
