作って見せて、使う人と一緒に育てる

夜のホームオフィスで業務アプリの改善点を整理する様子 なかま活動

システム開発といえば、最初にクライアントと仕様を細かく決め、目標を設定し、計画どおりに作って納品する。いわゆるウォーターフォール型の流れを思い浮かべます。

もちろん、仕様とゴールがはっきりしている大きなシステムなら、この進め方はとても有効です。ただ、中小企業の現場では、仕様を決めるための打ち合わせ時間そのものが取れないことも少なくありません。

🛠️ まずは動くものを作って見せる

今回作っているのは、バイクショップの予約や作業記録を管理するウェブアプリです。最初から完璧な仕様書を作るのではなく、まず予約画面や管理画面を形にして、「こんな感じでどうでしょう」と見てもらう。実際の画面があると、「この時間帯は受け付けない」「キャンセルも登録したい」「作業記録には写真を付けたい」といった、具体的な意見が出てきます。

現場独自のワークフローは、会議室で考えているだけではなかなか見えてきません。使う人が画面を見て、触って、初めて分かることがあります。

📋 Issueを一つずつ閉じていく

そこで、出てきた要望や問題をIssueという小さな課題に分けます。稼働日だけ予約できるようにする、受付時間を限定する、予約をキャンセルできるようにする、作業記録を複数登録できるようにする。こうした改善を一つずつ実装し、動作を確認して、問題がなければクローズしていきます。

🤖 バイブコーディングと手戻り

後から仕様が変わることは、従来の開発では「手戻り」として、できるだけ避けたいものです。設計書に戻り、データの持ち方を見直し、画面とテストを修正する。人間だけで対応すると、変更の影響範囲を考えるだけでも大きな作業になります。

一方、AIを使ったバイブコーディングでは、変更内容をIssueとして整理し、関連するコードや確認項目を洗い出しながら修正を進められます。手戻りがなくなるわけではありませんが、その負担を小さくできる。だからこそ、最初からすべてを決めきるのではなく、早く形にして現場と調整する進め方が取りやすくなります。


既製品をそのまま導入するだけなら、細かな打ち合わせは必要ないかもしれません。しかし、そのお店独自の仕事の流れに合わせたシステムを作るなら、使いながら一緒に育てていく方が現実に合うことがあります。作って見せる。意見を聞く。直して、また確認する。そんな開発の繰り返しが、使ってもらえるシステムにつながっていくのだと思います。

コメント

タイトルとURLをコピーしました