機能を増やせば便利になる。そう考えていた企画を見直し、何を残し、何を作らないかを考えた。K-Bridgeの構想から実装、公開までを振り返る。
企画の出発点
K-Bridgeは、学生生活の中で生まれる「次に何をするか」「どこへ行くか」「課題を提出できたか」といった迷いを減らすためのアプリである。必要な情報を並べるだけでなく、次の行動を決めやすくすることを目標にした。
当初は、時間割や課題管理に加えて、家計簿、教科書の売買、SNS、資料検索など、多くの機能を盛り込む案を考えていた。しかし、機能を増やすほど画面の情報量が増え、何から見ればよいのかが曖昧になった。そこで対象を絞り、「短時間で次の行動を決められること」を企画の軸に据えた。
機能と画面構成
画面は「今日」「課題」「場所」「ツール」の4つに分けた。中心となる「今日」では、NOW、NEXT、GOの順に、いま取り組む課題、次の予定、向かう場所を表示する。情報を一覧にするだけでなく、上から確認することで行動を決められる流れを意識した。
「課題」では、締切や提出状況のほか、課題の概要、着手のヒント、評価の観点、提出前の確認項目をまとめた。ファイル名やレポート冒頭のテンプレートも作成できる。「場所」では、教室名を知らなくても、集中したい、会話したい、飲食したいといった目的から候補を探せる。
割り勘計算や資料検索、学習管理システム・図書検索へのリンクなど、利用頻度が限られる機能は「ツール」にまとめた。毎日使う情報を先に見せることで、トップ画面の役割を絞っている。
- NOW / NEXT / GOで今日の予定を確認
- 課題の締切・進捗と提出前チェック
- 目的に合わせた空き場所の検索
- 提出用ファイル名とレポート冒頭の生成
- 割り勘計算、資料検索、関連サービスへのリンク
システム設計
フロントエンドにHTML、CSS、JavaScript、バックエンドにNode.jsとExpress、データベースにPostgreSQLを使用した。ブラウザからExpress APIへ課題一覧を要求し、状態を更新するときはサーバー側で入力を確認してデータベースへ保存する。画面、処理、データ管理の役割を分けた三層構成である。
公開環境にはVercelとNeonを利用した。フロントエンドをVercelで配信し、Express APIをVercel Functionsで動かし、Neon PostgreSQLに課題の状態を保存している。既存のサイトとは分けて公開しつつ、授業で扱った三層構成を実際に動かせる形にした。
デモ用データベースに個人の認証情報を保存しないよう、ブラウザごとに匿名の識別子を発行する。課題の状態はデータベースに保存し、テーマや検索条件など端末ごとの設定はlocalStorageに分けた。APIを利用できない場合にも画面を確認できるよう、ローカル保存へ切り替える処理も用意した。
画面幅に合わせてナビゲーションの位置を変え、PCでは左側、スマートフォンでは画面下部に配置した。色は用途ごとに役割を決め、主要操作、優先度の高い課題、場所に関する情報を見分けやすくしている。
- フロントエンド：HTML / CSS / JavaScript
- バックエンド：Node.js / Express
- データベース：PostgreSQL
- 公開環境：Vercel / Neon
- API：課題取得、状態更新、デモデータ初期化、稼働確認
- 検証：入力、API、データベース保存のテスト
設計で工夫したこと
企画を見直す際、機能を足すよりも、利用者が情報を見る順番を整えることを優先した。NOW、NEXT、GOの流れをつくり、「何が載っているか」だけでなく「次に何をすればよいか」が分かる画面を目指した。
課題を「提出済み」にする前には、提出前チェックを挟んでいる。締切を知らせるだけでなく、提出物やファイル名を自分で確かめるところまで支援したかった。
場所探しでは、設備名や建物名を知っていることを前提にせず、利用目的から候補を絞る形にした。静かに集中したい場合と、会話や飲食ができる場所を探す場合では、必要な条件が異なるためである。
難しかった点と判断
学習管理システムとの連携は、実装範囲を決めるうえで悩んだ点である。授業資料や課題、提出状況を取得できれば便利だが、安全に連携するには運営側の許可やOAuth 2.0、サーバー側でのトークン管理が必要となる。認証情報をブラウザに保存する方法は採らず、今回はサンプルデータで動作する範囲にとどめた。
公開直前にはシステム構成も見直した。当初はJavaScriptとlocalStorageだけで動く静的なアプリだったが、課題ではフロントエンド、バックエンド、データベースの三層を動かす必要があった。そこでExpress APIとPostgreSQLを追加し、課題の取得と状態更新を三層で処理する構成に改めた。画面が完成していても、求められた要件を満たしているか確認する必要があると学んだ。
開発中にローカル環境で画面が表示されなかった際は、コード、HTTPサーバー、ポートを順に確認した。実装だけでなく、利用者がブラウザから使える状態にするまでがWebアプリ開発だと実感した。
制作を通して得たこと
MVPでは、作る機能を選ぶのと同じくらい、作らない機能を決めることが大切だと学んだ。家計簿やSNSまで広げるより、課題、時間割、場所探しという日々の判断を丁寧に支える方が、アプリの目的は伝わりやすい。
実装できることと、安全に公開できることは同じではない。外部サービスと連携する際は、権限の取得方法や秘密情報の保管場所、データの扱いまで考える必要がある。今回は連携を見送る判断を通じて、その理由を設計として説明する大切さを学んだ。
三層構成を実装したことで、ブラウザ上の状態管理と、APIで入力を検証してデータベースへ保存する処理の違いを具体的に理解できた。AIも設計や実装の相談に使ったが、提案をそのまま採用するのではなく、実際の課題や要件に照らして取捨選択することが欠かせなかった。
制作前は、機能の多さがアプリの価値につながると考えていた。完成した今は、情報を利用者の行動に沿って並べ直したことが、K-Bridgeの軸になったと感じている。作りたいもの、実装できるもの、安全に公開できるものをすり合わせる過程も含めて、学びの多い制作となった。