Show original
Try the app
予定調整アプリ YOTEI
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
Share
予定調整アプリ YOTEIを更新しました
AI translation
「予定の確定」機能を新しくリリースしました！
About 4 min read20
AI translation
「予定の確定」機能を新しくリリースしました！
Try the app
予定調整アプリ YOTEI
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
I've released a new "Schedule Confirmation" feature for "YOTEI," a scheduling coordination app that I develop and operate independently.
I'll summarize the challenges that emerged while operating the scheduling coordination service and the implementation considerations for this release.
Until now, YOTEI has handled "presenting candidate dates and collecting responses (◯△×) from participants." However, by observing actual user behavior, the following workflow was occurring:
Since the app couldn't maintain a "confirmed" state, we had no choice but to rely on external chat tools for the final closing of the coordination. Therefore, I implemented the "schedule confirmation feature" to complete the entire process from aggregation to final notification within the app.
On the event page, the organizer can select one final candidate and change the status to "confirmed."
Rather than simply storing the ID of the "confirmed candidate," I reviewed the status management of the entire event. By maintaining the confirmed state in the DB schema, I've set up guardrails on the API side such as "reject POST requests for adding responses if confirmed," preventing data inconsistencies from accidental edits.
To handle cases where "we confirmed a date, but someone who can't attend appeared, so we need to reschedule," I also implemented a function to cancel the confirmed state (revert to unconfirmed). By not making state transitions one-way, I've ensured flexibility in actual operations.
YOTEI allows creating events as a guest without logging in. Therefore, the authorization for the confirmation process is based not only on account but also on an edit key issued at creation time, enabling secure confirmation processing for both logged-in and guest users.
Currently, users need to refresh the page to check the results, but in the future, I'm considering features such as "automatically notifying participants who have already responded the moment a schedule is confirmed" and "allowing the organizer to add a guidance message when confirming."
Rather than ending schedule coordination at "collecting responses," I'll continue improving it to seamlessly connect to "everyone confirming the decided schedule together."
個人で開発・運営している日程調整アプリ「YOTEI」に、新しく「予定の確定」機能をリリースしました。
日程調整サービスを運用する中で見えてきた課題と、今回の実装における工夫点についてまとめます。
これまでYOTEIは「候補日を提示し、参加者から回答（◯△×）を集める」ところまでを担っていました。しかし、実際のユーザーの行動を観察すると、以下のフローが発生していました。
アプリ内で「決定」という状態を持てなかったため、調整の最後のクロージングを外部のチャットツールに頼らざるを得ない状態でした。そこで、集計から最終案内までをアプリ内で完結させるべく「予定確定機能」を実装しました。
イベントページ上で、主催者が最終的な候補を1つ選び、ステータスを「確定済み」に変更できるようにしました。
単に「確定した候補」のIDを持たせるだけでなく、イベント全体のステータス管理を見直しました。DBスキーマ上でも確定状態を持たせることで、API側で「確定済みの場合は回答追加のPOSTリクエストを弾く」といったガードレールを設けて、誤編集によるデータの不整合を防いでいます。
「一度確定したけど、やっぱり参加できない人が出たので再調整したい」というケースに対応するため、確定状態の取り消し（未確定への差し戻し）機能も実装しました。状態遷移を一方通行にしないことで、実運用上の柔軟性を担保しています。
YOTEIはログインなしのゲストでもイベントを作成できます。そのため、確定処理の認可（Authorization）はアカウントベースだけでなく、作成時に発行される編集キーをベースにした判定も組み込み、ログインユーザー・ゲストユーザー問わずセキュアに確定処理を実行できるようにしました。
現時点ではページを開き直して結果を確認する必要がありますが、今後は「予定が確定した瞬間に、回答済みの参加者へ自動で通知を飛ばす機能」や「確定時に主催者が案内メッセージを添えられる機能」などを検討しています。
日程調整を「回答を集めるところ」で終わらせず、「決まった予定をみんなで確認するところ」までシームレスに繋げるように、引き続き改善を進めていきます。
