DiluNova
AIで画面を作れた後、仕事で使えるアプリにするまでには何をすればよいのでしょうか。案件では、機能を実装する作業に加えて、依頼する側と完成の条件を合わせることや、公開後の運用を決めることも必要になります。
ここでは、ホットペッパーとInstagramのDMからお客様が来るお店を想定し、予約の受付・管理を改善する仮の案件で進め方を説明します。実際の顧客事例や納期の約束ではありません。期間や担当の分け方は、案件の規模と体制に合わせて調整します。
1．使う人と、依頼が生まれた背景を知る
「予約アプリがほしい」という依頼だけでは、必要な機能を判断できません。利用者が予約を入れるだけなのか、スタッフが枠を追加するのか、キャンセルや決済まで扱うのかで作るものが変わります。
そこで、まず直近の予約を一件受け付けたときの流れを聞きます。ホットペッパー経由かInstagramのDM経由か、誰が内容を確認し、どこで予約を確定して記録したのか。途中で別の人に確認したことや、後から修正したことまでたどると、実際に負担がかかっている作業が見えてきます。
例えば、InstagramのDMで日時の相談を受けたスタッフが、ホットペッパー側の予約状況も確認してから返事をしているとします。この場合は、お客様を集める経路がすでにあります。新しく予約画面を作る前に、DMの返信待ちや空き枠の確認など、今の流れでどこに手間がかかっているかを調べます。
お客様がお店を知る経路と、予約が確定する場所も分けて確認します。DMで相談した後にホットペッパーへ案内するのか、DMのやり取りで予約を確定するのかによって、必要な管理方法が変わるためです。ここでは流入経路だけを前提とし、予約の確定方法やスタッフの負担は確認する項目として扱います。
依頼した経営者と、毎日使うスタッフでは重視することが違う場合もあります。経営者は受付の負担を減らしたくても、スタッフがWeb予約を別の台帳へ転記する運用なら、かえって作業が増える可能性があります。予約するお客様、受け付けるスタッフ、管理する責任者それぞれの流れを確認します。
英国政府のサービス設計ガイドでも、利用者が達成したいこと、現在の方法、困っていることを調べ、想像と調査で確かめた事実を分けるよう勧めています。要望の背景を聞くときの参考になります。
打ち合わせでは「どんな機能がほしいか」に加えて、次のような話を聞きます。
- 最近その作業をしたとき、どこで手が止まったか。
- 今はどう対処していて、誰に負担がかかっているか。
- スマートフォンや店舗のパソコンなど、何を使って操作するか。
- なぜ今変えたいのか。繁忙期や担当者の交代などの事情があるか。
- ホットペッパーとDMのそれぞれで、どの時点で予約が確定するか。
- 日時の変更やキャンセルは誰が確認し、どこへ反映するか。
聞いた内容は、確認できた事実、まだ分からないこと、試す案に分けて残します。「使う人はこう思うはず」という想像が、そのまま仕様にならないようにします。
新しい仕組みも、別の予約アプリを作るとは限りません。既存の予約先への案内を整える、DMの対応状況をスタッフ間で共有する、予約の確認作業を補助するなど、調べた結果に合わせて範囲を決めます。外部サービスとの自動連携は、公式に利用できる機能や契約条件を確認してから検討します。
2．使った後にどう変わるかを完成条件に入れる
例えば「来月末に一店舗で試せるようにする」という目標を置くなら、公開に必要な機能と、その後に検討する機能を分けておきます。以下は、調査の結果、まずDMの予約相談を管理する仕組みを試すことにした場合の例です。
- 利用者：管理画面を使う店舗スタッフ。お客様への返信や案内への影響も確認します。
- 最初に作る範囲：スタッフによる相談内容の登録、担当者と対応状況の共有。
- 今回含めない範囲：外部サービスとの自動同期、DMの自動送信、新しい顧客向け予約画面。
- 完成を確かめる条件：対応中の相談と確定済み予約を区別でき、担当者と最終確認日時が分かること。
- 判断する人：店舗の業務責任者が試用して確認します。
機能の完成条件と合わせて、使う人の作業がどう変わればよいかも決めておきます。例えば、お客様が予約確定までに同じ説明を繰り返さずに済むことや、引き継いだスタッフが対応状況を確認できることです。新しい画面への入力作業が増えるなら、その手間も含めて評価します。受付の負担を減らしたいなら、試用前後の対応時間や転記の回数を比べる方法が考えられます。削減率を先に約束するのではなく、現状を記録してから変化を確かめます。
目標の期限だけを決めると、途中で機能が増え続けることがあります。期限と一緒に完成の条件を残し、変更する場合は費用・日程への影響も確認します。
外部サービスの空き枠を自動で同期できない段階では、管理画面への登録だけで重複予約を防げるとは言えません。予約確定前にどこを確認するか、誰が確定情報を記録するかを運用として決めます。
ここからは、相談管理に加えて自社側で予約を登録する機能も開発する場合を例に、設計と確認の進め方を説明します。ホットペッパーやInstagramとの自動連携を前提とした説明ではありません。
3．画面、データ、権限を一緒に整理する
画面案を見ながら、何を入力し、何を保存するかを決めます。予約日時、人数、連絡先など、項目ごとに必要な理由を確認しておくと、不要な情報まで集めずに済みます。
同時に、利用者ごとの操作範囲も整理します。お客様は自分の予約を確認でき、店舗スタッフは担当店舗の予約を管理できる、といったルールです。画面にボタンを出すかどうかと、実際に処理を許すかどうかを分けて設計します。
OWASPの認可ガイドでは、アクセスのたびに権限を確認し、ブラウザー側の判定だけに頼らないことが示されています。開発では、この原則を「他店舗の予約は取得できない」など、検証できる条件に落とし込みます。
ここまでの決定は、画面案、保存項目の一覧、役割ごとの操作一覧として残します。AIにも同じ資料を渡せば、実装のたびに前提を説明し直す負担を減らせます。実際の顧客情報や秘密情報を渡す場合は、利用するAIサービスの契約・設定と社内ルールを先に確認します。
4．動作を確認できる単位で作業を分ける
「予約機能を作る」という大きな作業を、空き枠の取得、予約の保存、スタッフ一覧への表示などに分けます。ただし、画面だけをすべて先に完成させると、後からデータとつなぐ段階で認識の違いに気づくことがあります。
最初は、一つの予約が画面から保存先まで通る小さな範囲を作る方法が考えられます。仮のデータで動きを確かめ、次に権限や同時申し込みの処理を加えていきます。
作業ごとに、目的、変更する範囲、完成条件、確認方法を記録します。GitHub Issuesは、こうした作業や不具合を追跡するために使える仕組みの一つです。
AIには、作る機能と一緒に利用者の状況も伝えます。背景があると、なぜその条件を守る必要があるかまで共有できます。例えば、次のような依頼です。
InstagramのDMから来た予約相談をスタッフが引き継げるようにしたいです。スタッフが相談内容、担当者、対応状況を登録し、一覧で確認できる機能を実装してください。外部サービスとの自動同期や予約の自動確定は含めません。決済とメール通知も今回の対象外です。保存後に再読み込みして登録内容を確認できることを完成条件にします。まず変更が必要なファイルと確認方法を説明してください。
依頼の中に含めなかった処理までAIが追加していないか、差分を見て確認します。GitHubのプルリクエストでは、変更内容やテスト結果をまとめてレビューできます。小さい変更から確認すれば、仕様との違いも見つけやすくなります。
5．業務の条件に沿ってテストする
テスト項目は、実装したコードだけを見て決めるのではなく、最初に合意した完成条件から作ります。AIにテストを作らせる場合も、この条件を渡して内容を確かめます。
予約アプリなら、正常に予約できることに加えて、満席の枠に予約を追加できないこと、別の利用者の予約を変更できないこと、通信に失敗したときに誤って完了表示にならないことを確認します。
画面の操作を通した確認には、Playwrightなどのツールを使えます。Playwrightの公式ガイドでも、利用者が見る動作をテストすることが勧められています。ただし、画面のテストが通っただけで権限管理やデータの整合性まで保証されるわけではありません。APIへの直接の要求や、同時に予約が入った場合なども別に確かめます。
試験にはテスト用のアカウントとデータを使い、結果と未解決の問題を記録します。
使いやすさは、開発の途中でも利用者に試してもらいます。例えばスタッフには「同僚が対応していたDMの予約相談を引き継ぐ」と伝え、操作手順を先に教えずに様子を見ます。言葉の意味が分からず止まった場所や、完了したか不安になった場面を記録すると、修正点が具体的になります。このように作業を試してもらう方法は、英国政府のユーザビリティテストのガイドでも説明されています。
お客様側は、DMの返信や予約先の案内を見て次に何をすればよいか、予約が確定したか判断できるかを確かめます。実際に使う端末や文字の読みやすさも確認します。確認中に迷った人を「慣れていないから」と片付けず、表示や手順を変えると進めやすくなるかを試します。
6．公開作業と、問題が起きたときの対応を決める
開発用の環境で動いたら、公開先の設定も確認します。接続するデータベース、認証の設定、通知の宛先などが、開発中のまま残っていないかを見ます。
公開前には、少なくとも次の役割を決めておきます。
- 公開してよいか判断する人
- 公開作業を行う人
- 公開直後に予約などの主要な操作を確認する人
- 不具合の連絡を受け、対応を判断する人
元のバージョンへ戻す方法も準備します。データの形式を変える更新では、コードだけ戻しても動かないことがあるため、データの移行と復旧の手順を合わせて考えます。
公開後に使うアカウントの管理者、費用の支払先、バックアップの扱い、保守の範囲も引き継ぎます。依頼する側が「困ったときに誰へ連絡すればよいか」を分かる状態にして、運用を始めます。
進捗は、完成した画面と残っている確認を分けて伝える
「ほぼ完成です」という報告では、何が使えて何が未確認なのか伝わりません。「予約登録は確認済み、同時申し込みの試験が未完了、次回は店舗スタッフに一覧を操作してもらう」と伝える方が、次の判断をしやすくなります。
DiluNovaでは、先に「いつまでに、どこまで行くか」を整理することを大切にしています。開発中に新しい事情が分かったら、目標への影響を確認して計画を調整します。追加機能を次の公開へ回すことも、先に調査の時間を取ることも選択肢です。
AIを使う開発でも、目的、完成条件、確認結果を共有できるようにしておくと、依頼する人と作る人が同じ前提で話せます。まずは最初の公開でできるようにしたいことを、一枚にまとめるところから始めてみてください。
最後まで読んでいただき、ありがとうございました。
記事一覧に戻る