会議室とデスクの予約アプリを作る前にルールを決める
空き状況、繰り返し予約、チェックインルール、競合通知を明確に定義してから、会議室とデスクの予約アプリを計画しましょう。
まず解決したい予約の問題を整理する
会議室とデスクの予約アプリは、見た目が洗練されていても、毎日使う人を困らせることがあります。カレンダーだけでは、チームが会議室を午後いっぱい予約できるか、1人がデスクを2つ押さえられるか、誰も来なかったときにどうするかまでは判断できません。これらはポリシーの問題であり、アプリが一貫して適用する必要があります。
まず、今すでに報告されている問題から始めましょう。多くの場合、問題はごく身近なものです。誰かが会議室を予約したのに使わなかった、来訪者が使えるデスクを見つけられなかった、2つのチームが同じスペースを予約したと思っていた、といったケースです。ボタン、色、通知文を決める前に、こうした状況を書き出しましょう。
オフィスの予約ルールが曖昧だと、スペースは気づかないうちに無駄になります。従業員が毎週月曜日のデスクを何か月も予約していても、その多くの日はリモートで働いているかもしれません。その結果、別の人は空きデスクがないと思って出社をやめますが、実際には予約された席の多くが空いています。会議室でも、「念のため」と余分な時間を予約すると同じことが起きます。
まず、次のような判断を少数に絞って決めます。
- 各種類のスペースを誰が、どれだけ先まで予約できるか
- 1回の予約を何時間まで続けられるか
- 1人が同時に複数の予約を保持できるか
- 誰もチェックインしなかったとき、アプリがいつ会議室やデスクを解放するか
- 予定が変わったとき、誰が予約を上書きできるか
ポリシーと画面設計は分けて考えます。「30分チェックインがなければデスクを解放する」はポリシーです。「予約の横にカウントダウンを表示する」は画面上の選択です。ポリシーが公平な利用を作り、画面がその内容を理解しやすくします。
例えば、6人のチームが10時に会議室を必要とし、同じチームの1人がその朝にデスクを予約しているとします。これは問題ありません。ただし、会議室に15分のチェックインルールがあり、誰も来なければ、アプリは10時15分に会議室を解放してチームに通知する必要があります。
従業員が質問し、見直せるように、ポリシーは簡単な文章で書きます。「使われていない予約をすぐにキャンセルする」のような表現は避けましょう。時間、処理、例外を明記します。「主催者がチェックインしない場合、アプリは開始時刻の15分後に会議室を解放する」と書けば、ルールが明確になります。ルールが明確なら、繰り返し予約、競合通知、通知機能も作りやすくなります。
アプリを使うスペースと人を一覧にする
すべてのスペースに同じルールを適用すると、予約アプリはうまく機能しません。実際のオフィスに合わせて、個室、オープンデスク、静かなゾーン、電話ブース、研修エリア、駐車スペース、必要に応じて共有機器などを一覧にします。
各スペースには、利用者が認識しやすい名前を付けます。2つのフロアに同じ「3号室」があると、間違いが起きます。「2階ハーバールーム」なら、来訪者も場所を理解できます。デスクゾーンも、「窓側デスク」や「サポートチームエリア」のように用途がわかる名前にすると使いやすくなります。
利用者が選ぶときに影響する情報を記録します。6席、スクリーン、ビデオカメラがある部屋は顧客との通話には向いていますが、12人のワークショップには不十分です。アクセシビリティ情報は、予約後のメモに埋め込まず、予約前に表示しましょう。
リソース情報には、次の項目を含めます。
- 場所、フロア、近くの目印
- 定員と利用できる設備
- 段差のない出入口や高さを調整できるデスクなどのアクセシビリティ情報
- 予約を受け付ける時間帯
- 管理者による承認が必要かどうか
アクセスルールも同じくらい詳しく決めます。カレンダーを作る前に、各リソースを誰が予約できるかを決めましょう。営業チームは顧客用の会議室を予約でき、全従業員はフリーアドレスのデスクを予約できる、といった形です。部署専用の会議室を、特定の時間以降は全員に開放することもできます。
「スタッフのみ」のような曖昧な権限は避けます。従業員、契約社員、オフィスマネージャー、来訪者、管理者など、アプリ内のグループを具体的に定義しましょう。そして各グループができることを記載します。契約社員は1日だけデスクを予約できても、会議室は予約できないかもしれません。オフィスマネージャーは、部屋の詳細を更新したり、メンテナンスでスペースを閉鎖するときに予約をキャンセルしたりできます。
実際の問題を防ぐ場合に限って承認を求めます。大きな会議室、役員用スペース、時間外の利用、専門設備のある研修室には承認が必要かもしれません。通常の2人用会議室には、たいてい必要ありません。承認手順が多すぎると、利用者はチャットやスプレッドシートに戻ってしまいます。
Koder.aiなら、チャットを通じてこの一覧を初期アプリ計画に変えられます。各スペース、ユーザーグループ、権限をわかりやすい言葉で説明すれば、画面や通知が推測で作られるのではなく、オフィスのルールに沿って設計されます。
空き状況を段階的に定義する
空き状況は、カレンダー上の空白だけでは決まりません。スペースごとに利用時間、制限、予約不可の日を設定する必要があります。カレンダーを設計する前に、これらのルールを簡単な言葉で定義しましょう。
まず、スペースの種類ごとに考えます。静かなデスクは月曜から金曜の8時から18時まで使えるかもしれません。会議室は顧客との通話のため、もっと遅い時間まで使える場合があります。ある部署が部屋を管理しているなら、スケジュールを公開する前に、そのアクセス制限を適用します。選択できるのに、最後の段階で予約を拒否されると利用者は不満を感じます。
予約の最短時間と最長時間を決めます。デスクは半日または1日のブロック、会議室は30分単位にする方法があります。最短15分では、カレンダーに扱いにくい隙間が増えがちです。多くのオフィスでは、会議室は30分、デスクは半日単位にすると管理しやすくなります。
予約枠が空いているかを判断する順番を明確にします。
- 希望時間にスペースが利用可能か確認する。
- 祝日、メンテナンス、清掃、非公開イベントを確認する。
- そのスペースに別の予約が入っていないか確認する。
- 予約時間とアクセスのルールを適用する。
- 予約可能な期間の上限を適用する。
管理者が予約不可の時間を設定するときは、理由を追加できるようにします。「プロジェクター交換、13時から16時」と書けば、カレンダーに灰色の空白だけを表示するよりも明確です。会社の休日なら関連するスペースをすべてブロックし、非公開イベントなら1部屋だけをブロックできます。
どれだけ先まで予約できるかを決めます。出社状況が頻繁に変わる場合は、2週間先までの予約が適しています。ワークショップや来訪者との会議を計画するチームには、60日先までの予約が便利かもしれません。主催者だけ予約可能期間を長くすることもできますが、その違いはアプリ上で明確に示します。
ルール同士が衝突していないか確認します。デスクを終日予約できる一方、オフィスが8時から18時までしか開いていないなら、「終日」の意味をアプリで定義します。会議室が18時に閉まるなら、2時間の予約を17時から始めることはできません。こうした小さな点が、後のわかりにくい競合通知を防ぎます。
最初のルールセットは、オフィスマネージャーが数分で確認できる量にします。ポリシーが承認されたら、Koder.aiを使って、文章にしたルールをカレンダーのロジック、管理者用の操作、通知に変えられます。
繰り返し予約のルールを決める
繰り返し予約があれば、毎週同じデスクや会議室を予約する手間を省けます。一方で、繰り返し予約を永続的な1つのブロックとして扱うと問題が起きます。カレンダーを設計する前にルールを決めましょう。
一般的なオフィスの習慣に合う繰り返し方法を用意します。毎日、毎週、毎月です。毎週の予約は、毎週火曜日10時のチームミーティングに向いています。毎日の繰り返しは、短期プロジェクト中に同じデスクを使う人に適しています。毎月の繰り返しは、毎月第1月曜日の給与確認などに使えます。
すべてのシリーズには終了日が必要です。「無期限」という選択肢は避けましょう。人気の会議室を何か月も気づかないうちに占有する可能性があります。利用者が最終日または回数を指定できるようにします。オフィスのポリシーに合わせて、12回までなど、シリーズに上限を設けることもできます。
保存前にすべての日付を確認する
アプリは最初の予約だけでなく、すべての予定日を確認する必要があります。シリーズの途中でメンテナンスのため部屋が閉まったり、別のチームが後の時間帯を予約したりすることがあるからです。
確定前にプレビューを表示します。会議室またはデスク、時間、繰り返しパターン、終了日、予約総数を表示しましょう。予約できない日がある場合は、その日付と理由を示します。
例えば、Priyaが毎週水曜日の14時から15時まで、8週間にわたってCedar Roomを予約するとします。施設管理チームが4週目の水曜日に修理のため部屋を閉鎖する場合、アプリは空いている7日だけを確定し、修理日を飛ばせるようにするか、その日の会議だけ別の空き部屋に変更できるようにします。
許可なく会議を別の部屋へ移してはいけません。場所が変わると、参加者、設備、アクセシビリティに影響する可能性があります。
変更の結果を予測できるようにする
利用者には、1回分だけ変更するか、シリーズ全体を変更するかの2つの編集方法が必要です。Priyaが6回目の会議だけを木曜日に移した場合、残りの7回は水曜日のままにします。シリーズ全体の時間を15時に変更する場合は、アプリが今後のすべての日付を再確認し、保存前に競合を知らせます。
キャンセルも同じ考え方で設計します。1日だけ、今後の日付すべて、またはシリーズ全体をキャンセルできるようにします。これにより、同僚が使えるはずのスペースを、使われていないデスクの繰り返し予約が塞いでしまう問題を防げます。
チェックインの方法を決める
予約は、誰かがスペースを使って初めて役に立ちます。予約の少し前に始まり、開始後すぐに終了する短いチェックイン時間を設定します。例えば10時から予約した部屋なら、9時50分から10時10分までチェックインできるようにします。これなら到着までの時間を確保しつつ、空の部屋を朝から押さえ続けることも防げます。
出席を確認する方法を1つ選びます。アプリで「チェックイン」をタップする、ドアのコードを読み取る、部屋の外のタブレットを使う、といった方法があります。オフィス全体で方法を統一しましょう。デスクはアプリ、会議室は壁掛けタブレットを使うなら、両方の方法をわかりやすく説明します。
チェックインされなかったスペースを解放する
通知を作る前に、チェックインされなかったときのルールを書きます。チェックイン時間が終わったら、アプリは予約をキャンセルし、会議室やデスクを再び利用可能にします。元の予約者にも、その結果を伝える必要があります。
公平なポリシーには、通常、短い猶予時間を含めます。直前の会議やエレベーターの混雑で遅れることがあるためです。1時間の会議室予約なら15分が適しているかもしれません。30分の会議が多い職場なら、5分程度がよい場合もあります。
チェックインを何度も忘れた場合の対応も決めます。まずはリマインダーを送り、それでも使わないスペースを繰り返し押さえる人には、先の予約を一時的に制限することを検討します。1回予約を逃しただけで厳しいペナルティを科す必要はありません。予定は変わるものです。
会議の主催者が出席を確認できるようにする
グループ会議では、主催者が全員分のチェックインをできるようにします。参加者全員に確認を求めると、不要な手間が増えます。主催者が来なかった場合は、会議開始後に招待された別の参加者が引き継げるようにしてもよいでしょう。
ルールが発動したら、アプリは使われていない部屋をすぐに解放します。その部屋が空いたら知らせてほしい人に通知することもできます。簡単なメッセージで十分です。「Orchid Roomが11時まで利用可能です。ほかの人に予約される前に予約しましょう。」
予約時間、チェックイン時間、キャンセル、解放理由を記録します。オフィスマネージャーは、書類上は混んでいるのに実際には空いている部屋を見つけられます。2つのチームが同じスペースを主張したときの確認にも役立ちます。
Koder.aiなら、画面を細かく整える前に、こうした操作をモデル化できます。時間設定、誰が出席を確認できるか、解放ポリシーをチャットで説明し、現実的な予約を使ってチェックイン漏れをテストしましょう。
わかりやすい競合通知を書く
予約競合の通知は、何が問題なのかを簡単な言葉で説明し、次に何をすればよいかを示す必要があります。「予約に失敗しました」のようなメッセージでは、問い合わせが増えます。明確な通知があれば、利用者は迷わず別の会議室、デスク、時間を選べます。
同じスペースの重複予約はすべてブロックします。Mayaが10時から11時までAlder Roomを予約しているなら、10時45分から11時30分のように、その1時間の一部でも重なる予約は拒否します。個人用デスクにも同じルールを適用します。
通知には、スペース、日付、競合する時間帯を示します。例えば、「Alder Roomは火曜日の10時から11時まで予約されています。希望時間の10時45分から11時30分は、その予約と重なっています」と表示します。オフィスのポリシーで許可されていない限り、既存の予約者の名前は出しません。
次に取れる行動を示す
アプリが代替案を見つけられるなら、表示します。希望時間に利用でき、席数も足りる部屋や、同じ部屋を最も近い空き時間で提案します。デスクの場合は、別のフロアを勧める前に、選択したゾーン内の空きデスクを示します。
提案は元の希望に近いものにします。
- Birch Room、8席、10時45分から11時30分まで利用可能
- Alder Room、11時から11時45分まで利用可能
- Cedar Room、6席、10時45分から11時30分まで利用可能
「予約確定」「予約不可」「予約変更」「予約キャンセル」のように、状態を直接示すラベルを使います。それぞれの結果に応じて、必要な情報は異なります。
繰り返し予約を慎重に扱う
シリーズを作成してから数か月後に決まったオフィスの休業が、繰り返し予約と競合することがあります。チームが毎週月曜日にCedar Roomを予約していたところ、管理者がある月曜日をメンテナンスのため休業にするケースです。アプリはシリーズ全体を削除せず、その日だけを問題として知らせる必要があります。
何が変わったのかを正確に伝えます。「10月14日月曜日のCedar Roomの予約は、メンテナンスによるオフィス休業のためキャンセルされました。ほかの毎週の予約は有効です。」休業が一日の一部だけなら、空いている時間や別の適切な部屋を提案します。
変更の影響を受ける全員に同じ情報を送ります。明確な通知があれば、アプリがすでにブロックまたはキャンセルした会議やデスク予約のために、誰かが現地へ行ってしまうことを防げます。
ルールに合った画面を作る
詳細を入力してもらう前に、何を予約できるかを表示します。空き状況の画面では、利用者のオフィス、今日の日付、通常の勤務時間を初期値にします。主催者のチェックインが必要、定員に制限がある、メンテナンスで閉鎖中といった状態も、検索結果に表示します。
多くのオフィスでは、シンプルなリストが使いやすいでしょう。各結果に、スペース名、フロア、空き時間、定員、ディスプレイやビデオカメラなどの設備を表示します。14時に使える6人用の部屋を探す人が、何度も画面をタップして比較する必要はありません。
予約フローを短くする
スペースを選んだら、選択した日付と時間をフォームに引き継ぎます。時間の変更、対応していれば参加者の追加、適用されるルールの確認ができるようにします。デスクの繰り返し予約では、終了日と、これから作成される予約数を表示します。
保存前に確認画面を1つ設けます。利用者が間違えやすい情報をもう一度表示します。
- スペース名、オフィスの場所、フロア
- 日付、開始時刻、終了時刻
- 定員と選択した設備
- 繰り返しスケジュールがあれば、その内容
- チェックインの締切とキャンセルルール
「予約を確定する」で予約を作成し、「戻る」で編集画面に戻れるようにします。変更が保存されたかどうかを、利用者が推測しなければならない状態にしてはいけません。
利用者が期待する場所に変更機能を置く
各利用者に「自分の予約」エリアを用意し、今後の予約を先に表示します。確定、チェックイン待ち、キャンセル済み、チェックイン漏れによる解放済みなどの状態も示します。変更とキャンセルの操作は、離れた設定メニューではなく、予約カードまたは詳細画面に置きます。
繰り返しのデスク予約を変更するときは、選択肢を簡単な言葉で説明します。今回の火曜日だけ更新するのか、今後すべての火曜日を更新するのかを選べるようにします。新しい時間が別の予約と競合する場合、利用者が空いている選択肢を決めるまで元の予約を残します。
Mayaが10時の会議室予約を11時に変更しようとしたとき、別のチームがすでにその部屋を予約していたとします。アプリはそのことを伝え、近い時間や似た部屋を提案します。警告なしに10時の予約をキャンセルしてはいけません。
現実的な予約シナリオを確認する
Mayaはハイブリッド勤務のオフィスで働いています。プロダクトチームの近くのデスクを毎週火曜日と木曜日に使いたいため、D-14のデスクを9時から17時まで繰り返し予約します。アプリはシリーズを保存する前にデスクのカレンダーを確認し、利用可能な日付をすべて確定します。
数週間後、施設管理者がCedar Roomの修理が必要だと知ります。部屋は水曜日から金曜日まで閉鎖され、木曜日の午後に予定されているMayaのチームの定例計画会議も影響を受けます。管理者は部屋を利用不可にし、修理期間を記録します。
アプリはMayaの会議を何の連絡もなく消してはいけません。休業期間と重なる予約を見つけ、影響を受けない毎週の会議はそのまま残し、木曜日の予約だけを対応が必要な状態にします。1つの例外のために、利用者がシリーズ全体を作り直す必要はありません。
Mayaには明確な通知が届きます。「Cedar Roomは修理のため、5月16日木曜日の13時から15時まで利用できません。」影響を受ける会議、日付、時間が示されているため、Mayaはすぐに対応できます。
アプリは、可能な限り元の人数と時間に合う代替案を提示します。
- Birch Room、木曜日の13時から15時
- Maple Room、木曜日の13時30分から15時30分
- Cedar Room、金曜日の13時から15時
- 時間はそのままにしてビデオ会議へ変更
MayaがBirch Roomを選んで変更を確定すると、アプリはその回だけを更新し、参加者に通知します。後の木曜日のCedar Roomの予約は変更しません。アクティビティ記録には、修理による閉鎖が例外の原因だったことを残します。
同じアプリで、MayaがD-14に到着したときのチェックインも求められます。許可された時間内にチェックインしなければ、アプリはそのデスクをほかの人のために解放します。Mayaがキャンセルしない限り、今後の火曜日と木曜日の繰り返しパターンは有効なままです。
このシナリオでは、繰り返し予約、一時的な閉鎖、通知、代替案、チェックインのルールが連携して機能するかを確認できます。紙の上でわかりにくい手順は、アプリでも利用者を混乱させます。
ルールをテストして構築計画を立てる
ルール同士が矛盾すると、予約アプリは機能しません。カレンダー、ボタン、通知を磨き込む前に、ルールをテストします。まずは少数の会議室、デスク、ユーザーと、数日分のサンプル予約を使いましょう。
最初に基本的な空き状況を確認します。各リソースには、予約可能な時間、タイムゾーン、必要に応じた定員、清掃、メンテナンス、非公開イベントによるブロック期間が必要です。8時に空いているように見えるのに実際は9時からしか使えないデスクがあると、すぐに信頼を失います。
短いテスト項目を用意します。
- 通常の利用時間内と、利用時間外に会議室を予約する。
- すでに別の人が予約しているデスクを予約しようとする。
- 祝日やブロックされた日をまたぐ繰り返し予約を作る。
- 時間どおり、遅れて、まったくチェックインしない場合を確認する。
- 予約をキャンセルし、スペースが利用可能になることを確認する。
繰り返し予約には特に注意します。Mayaが8週間、毎週火曜日にDesk 14を予約し、そのうち1日がオフィス休業日なら、アプリはその日を飛ばし、理由を説明する必要があります。誰も使えない予約を作ってはいけません。1回分だけの編集と、シリーズ全体の編集もテストします。
チェックイン漏れも同じように確認します。猶予時間を過ぎてもチェックインがなければ、アプリは会議室またはデスクを解放して本人に通知します。解放の1分前、解放時刻ちょうど、1分後にチェックインした場合をテストしましょう。スタッフには、新しく空いたスペースがすぐに表示される必要があります。
忙しい従業員の立場で通知を読む
競合通知には、スペース、日付、時間を記載します。「Desk 14は10時から14時まで予約されています」は、「予約が競合しています」よりはるかにわかりやすい表現です。可能なら、近くの空きデスクを見る、別の時間を選ぶといった次の操作へ直接進めるようにします。
繰り返し予約の通知もテストします。利用者は、1回分だけ失敗したのか、シリーズ全体が変更されたのかを知る必要があります。同じ出来事について通知を何通も送るのは避けましょう。明確なメッセージは1通で十分です。
テスト済みのルールを構築計画に変える
承認された各ルールを短い文章で書きます。誰が予約できるか、いつ予約できるか、何が予約をブロックするか、チェックイン漏れの後に何が起きるかを明記します。例外は別の文書に分けず、関連するルールの近くに置きます。
Koder.aiの計画モードなら、開発前にこれらの流れを整理できます。会議室とデスクの予約アプリについてチャットで説明し、ルールとテスト項目を含めましょう。そのうえで、リソース一覧、空き状況カレンダー、予約フォーム、チェックイン操作、競合メッセージを備えた小さな初期バージョンを作成します。管理者向け機能やレポートを追加する前に、サンプルユーザーでテストしましょう。