システムの仕様の決め方は、本来はお客様と何度もやり取りしながら固めていくものです。予約管理アプリ「Appointly」というサンプル開発の中で、本来お客様と一緒に整理すべき仕様の判断を、あえて自分ひとりで下ろした経緯と、その理由を振り返ります。
きっかけ
Appointlyは、実在のお客様がいないサンプル開発として作っています。本来、業務システムの仕様は、お客様に説明資料や提案をお見せしながら要望をすり合わせ、内容にご了承をいただいてから開発を進めるのが基本の流れです。実務であれば、仕様を1つ変えるだけでも「なぜ変えるのか」「他にどんな選択肢があったか」をお客様にご説明し、判断は最終的にお客様にしていただきます。
ですが今回はお客様役が存在しないため、受付時間の設定から予約・チャットのやり取りまでの一連の流れを、実際にお使いになるお店やお客さんならどう感じるかを想像しながら、自分で判断して形にしました。この進め方は、実務としては本来あり得ない、サンプル開発ならではの特殊なものだという前提でお読みください。
判断のポイント:仕様の決め方を自分で担った場面
分岐点1:確定した予約のキャンセルは、ボタンではなく相談に
最初は、確定済みの予約もお客さん側からワンタップでキャンセルできる作りにしていました。ですが、確定したはずの予約が突然キャンセルされると、お店側の受付枠の管理が崩れてしまいます。
本来であれば、「どこまでキャンセルを許容するか」はお店の実際の運用を伺いながらお客様と決める部分です。今回はお客様がいないため、一般的な予約管理でトラブルになりやすいパターンを想定し、キャンセルボタンは「まだ確定していない予約」だけに絞り、確定後の変更はチャットでお店に一言相談してもらう流れに、自分の判断で倒しました。
分岐点2:アプリを使わない予約も、同じ画面で管理できるように
電話や口頭で入る予約は、アプリ経由の予約とは別扱いにせざるを得ないと最初は考えていました。ですが、それでは「アプリ経由の予約」と「それ以外の予約」が別々の場所で管理されることになり、お店側の二度手間になってしまいます。
これも本来なら、お店が実際にどれくらいの割合で電話予約を受けているかをお客様に伺った上で、機能として必要かどうかを一緒に判断するところです。今回は「アプリを導入するお店でも、電話予約がゼロになることは考えにくい」という想定のもとに自分で仕様を決め、お店側が名前と電話番号だけを入力すれば、アプリを使っていない相手の予約も同じカレンダー・同じ一覧で管理できるようにしました。
分岐点3:一覧の表示期間は、使ってみてから決め直した
確定済みの予約をいつまで一覧に表示するかは、最初「今週の月曜日以降」という基準で作りました。しかし実際にダッシュボードを操作してみると、週の切り替わりのタイミングで表示が不自然に感じられ、翌日には「今日以降」というシンプルな基準に直しています。
この部分は、実務であれば公開前にお客様に画面を見ていただき、使用感を確認していただく工程にあたります。今回は自分がお店役・お客さん役の両方を兼ねて画面を触ることで、その代わりとしました。
AIの活用
いずれの判断も、「お店だったらどう困るか」「お客さんだったらどう感じるか」という2つの立場を自分の中で行き来しながら、AIと一緒に壁打ちする形で進めました。実際のお客様への確認の代わりにはなりませんが、思いつく限りの利用シーンを想定し、その場で仕様を試しては直す、というサイクルを短い時間で何度も回せたのは、AIと一緒に手を動かしているからこそだと感じています。
結び
実際のお仕事では、こうした仕様の判断はお客様に選択肢とメリット・デメリットをご説明し、ご了承をいただいてから進めます。今回のサンプル開発のように、自分だけで仕様を決め切ってしまうことはありません。仕様の決め方や、ご自身の業務に必要な機能の整理に不安がある方は、一度ご相談ください。一緒に整理しましょう。
