Ryuute

Ryuuteは、予定だけでなく、その予定に間に合うための移動時間まで管理できるWebスケジュールアプリです。

例えば10:30から予定があり、移動に1時間かかる場合、予定だけでなく「9:20〜10:20 移動」のように移動時間もカレンダー上に表示します。

主な機能

• 月・週・日表示のカレンダー
• 予定・タスク管理
• 予定ごとの準備チェックリスト
• 予定場所までの経路検索
• 検索した移動経路のカレンダーへの登録
• Google Placesを使った場所入力
• Google Mapsとの連携

技術構成

• React / Vite
• FastAPI
• SQLite
• Google Places Autocomplete
• 駅すぱあと API スタンダード

予定、移動、準備を一つのアプリで扱うことで、「予定が何時からあるか」だけでなく、「その予定のために何時から行動すればよいか」まで分かるスケジュール帳を目指しています。

この成果物を作ろうと思ったきっかけ

NAVITIMEでは調べた乗り換えの案内をGoogle Calenderに登録することができます。しかし、その都度カレンダーに登録するのが面倒で、「スケジュールアプリから直接、目的地までの経路や乗り換えを入れられればいいなー」と思ったのがきっかけです。

乗り換え案内アプリ　→　スケジュールアプリ　→　登録

ではなく、

スケジュールアプリ　→　 登録　

というイメージを持って開発を進めました。

私たちが挑戦したこと

1. 初心者4人で、フロントエンドからデータベースまでつなげる

メンバー全員がハッカソン初心者（なんなら開発初心者）で、GitとGithubの使い方もわからない状態でしたが、Reactの画面だけで終わらせず、FastAPIのAPI、SQLiteへの保存、外部サービスとの連携まで含むWebアプリの完成に挑戦しました。

React
  ↓ HTTP / JSON
FastAPI
  ├─ SQLite
  └─ 経路検索サービス

予定やタスクを入力して終わりではなく、保存したデータを別の画面でも使い、経路検索の結果を移動予定として再びデータベースへ保存し、カレンダーへ反映するところまでを1本の流れとしてイメージです。

どこで詰まり、何を考え、どう挑戦したか

詰まり1：最初に選んだ経路APIで、必要な公共交通経路を安定して取得できなかった

当初はGoogle Routes APIを使って経路検索を実装しました。しかし、日本の公共交通を使う今回のデモケースでは、私たちが期待する経路を安定して取得できませんでした。

このとき、「一度実装したから使い続ける」のではなく、Ryuuteの中心価値は何かを考え直しました。中心価値は特定のAPIを使うことではなく、予定に間に合う出発時刻を利用者へ伝えること。そのため、公共交通の検索に適した駅すぱあと API スタンダードへ切り替える判断をしました。 アドバイスをくださったメンターさんには感謝です。

詰まり2：画面、API、データベースのどこか1つだけ直しても機能が完成しない

経路検索では、予定の場所と開始時刻を取得し、到着余裕時間を引いて到着希望時刻を計算し、経路を検索し、結果を表示し、利用者が選んだ時点で保存し、週カレンダーへ反映しています。

最初から全体を一度に作ろうとすると、エラーの原因が画面、通信、API、変換処理、データベースのどこにあるのか分かりにくくなります。そこで、小さな単位へ分けました。

具体的には、GithubのIssue機能を使ってチケット駆動開発（笑）を実践しました。

松野 git等のツールの使い方やwebアプリの構造などの技術面だけでなく、チームでどうタスクを振り分けるのか、どうコミュニケーションをとるのかなど、チーム開発ならではの学びが多く、非常に有意義な経験でした。

詰まり3：限られた時間で「作りたいもの」と「完成させられるもの」を両立する

開発を進めるほど、通知、経路候補の比較、より正確な徒歩経路など、追加したい機能が増えました。しかし、すべてへ手を広げると中心となるデモが完成しません。

そこで、まず「予定登録 → 経路検索 → 移動予定の登録 → カレンダー表示」という中心フローを優先しました。通知も、ブラウザを閉じた状態で届く複雑な仕組みではなく、未完了の準備をアプリ内で確実に確認できる形に絞りました。経路候補もMVPでは1件に絞っています。

これは挑戦を小さくしたのではなく、短い期間で利用者へ価値を届けるために、何を作らないかも決める挑戦です。

なんならこの記事も終了8分前に書いています。

学びと感想

丸山 開発をするのが今回が初めてで、どのように開発を進めていくのかが何となくですが分かりました。また、機能を実装することと、実際に使いやすいようにすることは違うのだと思いました。

橋本 まずは今までハッカソンにビビッて参加しなかった自分が一歩踏み出して参加したことを褒めたい。今回はコードを手書きするというより、チームでどうコミュニケーションをとって、どう開発を進めていくか、という過程が本当に重要だと学べた。

髙手 今回はじめてハッカソンに参加し、チームで一つのものを開発する経験をしました。分からないことや問題が出てきたときに、チームで相談することで解決できることを実感し、コミュニケーションの大切さを学びました。今回の経験を今後の開発にも活かしていきたいです。