「予約アプリが必要です」という説明だけでは、製品の種類は分かっても、多くの判断が未確定のままです。誰が予約枠を提供するのでしょうか。顧客はキャンセルできますか。変更にはスタッフの承認が必要ですか。こうした問いを実際の業務と結びつけることで、プロジェクト概要は役立つものになります。まず代表的なワークフローを一つ取り上げ、その実現に必要な役割、制約、確認時の判断事項を加えていきます。
このページの内容
現在のワークフローと問題を説明する
業務が始まるきっかけから、完了を示す結果までの流れを書き出します。人やシステムの間で行われる引き継ぎも含めてください。予約を扱う事業を例にすると、顧客が日時を希望し、スタッフが共有カレンダーを確認して、手作業で確認連絡を送る流れが考えられます。課題は予約の重複かもしれませんし、顧客が状況を把握しにくいことかもしれません。画面の一覧を提案する前に、どの問題が重要なのかを明らかにしましょう。
- どのような情報によって依頼が始まりますか。
- 進められるかどうかを誰が判断しますか。
- 何をもって全員が完了を確認できますか。
利用者ごとの責任を明確にする
顧客、スタッフ、管理者のニーズを分けて考えます。顧客は自分の予約を確認し、スタッフはスケジュールを管理し、管理者はそのアクセス権を付与するといった役割が考えられます。通常の操作だけでなく、訂正の手順も説明してください。スタッフが予約を変更した場合、誰に変更が見え、元の予約枠はどうなるのでしょうか。こうしたルールがあれば、デザインと開発のチームは同じ製品像をもとに話し合えます。
初回リリースの境界を定める
予約の例では、初回リリースを絞り込み、顧客が空き枠を選び、確認を受け取り、後から予約を確認できるようにし、スタッフは空き枠の管理やキャンセルに対応できるようにする案が考えられます。定期予約や会員特典を後回しにできるなら、理由を添えて別の一覧にまとめます。メイン画面ほど目立たないというだけで、合意した利用の流れを成立させるために必要な補助ステップを取り除いてはいけません。
- 依頼から結果まで、一連の利用の流れを含めます。
- 運用に必要なアクセス管理と訂正機能を含めます。
- 見送るアイデアには、再検討する条件を定めます。
依存関係を整理し、未確認事項を示す
アプリケーションが必要とする可能性のある既存のカレンダー、決済サービス、顧客情報、その他のシステムを特定します。対応言語、対象端末、移行の必要性、業務上の制約も記載してください。確定した要件と質問は区別します。「既存のカレンダーからリアルタイムの空き状況を取得できるか」という質問も、概要にとって有用な情報です。取得できると決めつけると、必要な調査が見えなくなり、当初の範囲を誤って見積もるおそれがあります。
要件を確認できる具体例にする
受け入れ確認の内容を平易な言葉で記します。予約ワークフローの例なら、顧客が空き枠を予約すると、本人のアカウントとスタッフのスケジュールに予約が表示されること。同じ定員一名の枠を別の顧客が予約しようとしても、二件目の確定が行われないこと。キャンセルによって空き枠が戻る仕組みも合意します。こうした例によって、「予約管理」という表現では未定義だった判断事項が明らかになります。誰が確認し、範囲の変更を承認するかも決めてください。
- 実際の利用者を代表する人と、一連の作業を確認します。
- 質問は承認済みの要件と分けて記録します。
- 優先順位が競合した際に判断する担当者を一人決めます。
日常業務への移行も含める
公開後に誰がアプリケーションを管理し、既存データを取り込み、利用者を支援するかを説明します。チームに必要な研修や引き継ぎ資料を明確にしてください。問題の報告方法や更新内容の確認方法も検討します。これらを含めることで、動くデモから、事業で運用できる製品へ移るための実務も開発範囲に盛り込めます。