はじめに
前回の投稿はこちらになります。
続編になるので詳しく知りたい方は前回の投稿もご覧ください。
前回から環境の大幅変更
最初は生成AIと対話しながらソースコードを書いてもらい、基本的に自分でディレクトリやファイルを作成してました。
ただ、
- 「他にどんな機能が必要なんだろう…？」
- 「全体の設計として正解が全く分からない」
- 「この先、何から手をつけていいのやら…」
そこで、現状を打破するために**Kiro (Amazon Q Developer)**を活用し、要件定義から設計までを強力にサポートしてもらう体制に切り替えました。
その結果、ようやく「プラットフォーム」としての全体像が固まってきました。
現在の画面イメージ（バス会社側）
バス会社が「回送バス」のスケジュールを登録する機能を実装しました。
-
スケジュール登録画面
出発地名と目的地名にキーワードを入力すると、自動で検索が走り、候補が一覧表示されるUIにしています。ユーザーは一覧から場所を選択するだけで入力が完了します。
POINT: フォーム入力の負担を減らすことで、現場での使い勝手を意識しました。
-
スケジュール一覧
登録されたスケジュールを一覧で確認できる画面です。
さらに「予約一覧」タブを設けることで、どの便に荷物の予約が入っているかを即座に把握できるようにしました。
現在の画面イメージ（荷主側）
荷物を送りたいユーザー（荷主）側の機能も形になってきました。
-
スケジュール検索
バス会社が登録した空き枠を検索する画面です。
現在は一覧内のスケジュールをクリックすると、地図上に対象の経路が表示されるギミックを搭載しています。
視覚的にルートが分かるので、利用イメージが湧きやすくなっています。
-
予約一覧
自分が予約した荷物の配送ステータスを確認できる画面です。
※現在はステータス変更の反映などは未実装のため、これから調整していく予定です。
おわりに
AI（Kiro）を設計パートナーに据えたことで、要件が明確になり、プロトタイプが現実味を帯びてきました。
実際に動く画面を触ってみると、
- 「こうしたらもっと使いやすそう」
- 「この項目は実は不要だったかも」
- 「このフローだと現場は困るのでは？」
といった、ユーザー目線での気づきが次々と出てきます。これが個人開発の醍醐味であり、非常に勉強になりますね。
コードについては、まだ整理が必要なためGitHubへのコミットは先になりますが、準備ができ次第公開する予定です。
引き続き、応援よろしくお願いします！