K-Bridge 制作記

テーマ

今回制作したK-Bridgeは、学生向けの生活アシスタントである。テーマは、学生生活で何度も発生する「次に何をするか」「次の授業はどこか」「空き時間をどこで過ごすか」「課題の提出は大丈夫か」という迷いを、一つの画面から減らすことである。

制作を始めたときは、K-passに対抗できるスーパーアプリを作ろうと考えていた。家計簿、教科書売買、割り勘、SNS、論文検索、空き教室、時間割など、思いついた機能をほとんど全部入れたかった。しかし、機能を増やすほど最初の画面で何を見ればよいのか分かりにくくなり、自分でも毎日開きたいとは思えない構成になった。そこで「学生が10秒で次の行動を決められること」を中心に置き直した。

サービスの説明

K-Bridgeの中心は「今日」「課題」「場所」「ツール」の四画面である。「今日」では、NOW、NEXT、GOの順に、いま進める課題、次の授業、向かう場所を表示する。時間割や締切を一覧で見せるだけではなく、上から読むと次の行動が決まる構成にした。

「課題」では、締切と提出状態に加えて、課題の概要、最初にやること、評価観点、提出前チェックを確認できる。科目名や学籍番号を含んだファイル名と、レポート冒頭のMarkdownテンプレートも生成できる。「場所」では、教室名を知っていることを前提にせず、「集中したい」「会話したい」「飲食したい」という目的から候補を探せる。

「ツール」には、傾斜付き割り勘、過去レポ・論文のサンプル検索、学習管理システムや図書検索などの公式サービスへの導線をまとめた。毎日使う核ではない機能を二階層目に置くことで、最初の画面が散らからないようにした。

• NOW / NEXT / GOによる今日の行動プラン
• 週間時間割、課題プレビュー、提出前チェック
• 目的、現在地、利用時間から探す空き場所
• ファイル名とレポート冒頭テンプレートの生成
• 傾斜付き割り勘、資料検索、学内公式サービスへの導線

設計の説明

フロントエンドはHTML、CSS、JavaScript、バックエンドはNode.jsとExpress、データベースはPostgreSQLで実装した。ブラウザはExpress APIから課題一覧を取得し、課題の状態を変更すると、バックエンドが入力を検証してSQLを実行する。PostgreSQLには科目、課題、利用者ごとの課題状態を保存する。

授業資料ではRenderが実習環境として示されていたが、すでにkumpei.comを運用している環境を活用するため、K-Bridgeは別のVercelプロジェクトとして公開した。フロントエンドをVercelの静的配信、Express APIをVercel Functions、データベースをNeon PostgreSQLで動かし、授業で扱った三層の責務を保った。

個人の認証情報をデモ用DBへ入れないため、ブラウザごとに匿名の識別子を生成した。提出状態はDBへ永続化し、表示テーマ、検索条件、提出前チェックなど端末固有のUI状態はlocalStorageへ分けて保存する。APIへ接続できない場合はローカル保存へ切り替え、画面確認を続けられるようにした。

PCでは左側、スマートフォンでは画面下部に主要ナビゲーションを置いた。配色は、ブルーを授業と主要操作、レッドを優先課題、イエローを場所と注意に割り当てた。公式ロゴは使わず、非公式の学生制作物であることとの区別も意識した。

• Frontend: HTML / CSS / JavaScript
• Backend: Node.js / Express
• Database: PostgreSQL
• Hosting: Vercel / Neon
• API: 課題取得、状態更新、デモ状態の初期化、ヘルスチェック
• Test: node:testによる入力検証、API、PostgreSQL永続化の確認

自分なりにこだわった点

最もこだわったのは、機能数ではなく判断の順番を設計したことである。最初の版は便利そうな情報を多く並べていたが、それでは利用者が自分で優先順位を考えなければならなかった。そこで全体構成を作り直し、NOW、NEXT、GOという流れを中心にした。「何が分かるか」ではなく、「次に何が決まるか」を基準に整理したことが、今回一番大きな変更である。

課題管理では、「提出済み」に変更する前に提出前チェックを終える仕組みにした。課題を出したつもりでも不安になって学習管理システムを開き直すことがあるため、締切通知だけではなく、確認行動そのものを画面に入れたかった。

空き場所も設備の一覧から探すのではなく、まず目的を選ぶ構成にした。発話できる場所を探す学生と、静かなPC室を探す学生では、同じ「空き教室」でも必要な条件が違う。利用者が教室名や建物名を覚えていなくても探せることを優先した。

難しかったことと判断

最も悩んだのは学習管理システムとの連携である。実際の学生生活で使うには、Canvas APIから授業資料、課題、提出状況を取得できることが理想である。しかし、安全に連携するには運営側のDeveloper Key、OAuth 2.0、サーバー側でのトークン管理が必要になる。IDやアクセストークンをブラウザへ保存する方法は危険なので、動いているように見せるためだけの認証は実装しないと決めた。

もう一つ、公開直前に大きな見直しがあった。当初はJavaScriptとlocalStorageだけで操作できる静的アプリとして完成させていた。しかし、第10回から第13回の授業資料を読み直すと、フロントエンド、バックエンド、データベースの三層を動かすことが最低目標として明記されていた。見た目が完成していても、設計要件を満たしていなければ完成とは言えない。そこでExpress APIとPostgreSQLを追加し、課題取得と状態更新を三層で動かす構成へ作り直した。

localhostで画面が開けなかったときも、コード、HTTPサーバー、ポートのどこに原因があるかを切り分ける必要があった。ブラウザに表示できるところまで含めてWebアプリの実装であると実感した。

学びになったと感じたこと

MVPでは「何を作るか」と同じくらい「何を作らないか」を決めることが重要だと学んだ。家計簿やSNSまで加えるより、学生が頻繁に行う課題、時間割、場所の判断を深く作る方が、サービスの目的が伝わる。

また、画面上で実現できそうなことと、安全にサービスとして実現できることは別だと分かった。APIの説明を読むだけでなく、誰が権限を発行するのか、秘密情報をどこに置くのか、取得したデータをどう扱うのかまで考える必要がある。実装しない判断にも設計上の理由が必要だった。

三層構造を追加したことで、ブラウザの変数を書き換えることと、HTTPリクエストを受け、入力を検証し、SQLで永続化することの違いを具体的に理解できた。APIのテストとDBのテストを分け、最後に実際のPostgreSQLで保存と再取得を確認する流れも学びになった。

AIは設計や実装の壁打ちに活用したが、提案された機能をそのまま増やすだけではよいサービスにならなかった。学生生活で本当に困る場面と授業資料の要件に戻り、自分で採用と不採用を決めることが必要だった。

感想

制作前は、K-passより多機能ならよいアプリになると考えていた。完成してみると、一番価値があったのは機能を足したことではなく、全体を作り直して利用者の行動順に並べたことだった。

Canvasとの自動連携は実装できなかったが、安全性や運営側の権限を無視して中途半端につなぐより、サンプルデータで責任を持って公開できる範囲を完成させる方がよいと判断した。一方で、認証を扱わなくても、課題の取得と状態更新をExpressとPostgreSQLで実装できたため、授業で扱ったWebアプリの構造は実際に試すことができた。

K-Bridgeは、情報を集めるだけのポータルではなく、「今日の次の行動を決める」アプリとして完成した。作りたいもの、期間内に作れるもの、安全に公開できるもの、授業で求められているものを照らし合わせる過程そのものが、今回の制作で最も大きな学びだったと思う。