最初の段階では、OpenAIのサービスをどのように使えばいいのかまったくわかりませんでした。 通常のAI APIだと、スポットに関する十分な情報がないうえに、Googleマップと照らし合わせると誤情報が混ざる可能性があります。

さらに、専用のAIをトレーニングしようにも、必要なデータ量とコストが膨大で、実用的ではありませんでした。

そこで、何度も計画を練り直してユーザーフローを描き出した結果、まずアンケートを使ってユーザーの好みを把握し、AIには「スポットのタイプ」を推定させるだけに絞ることにしたんです。 その後、AIが導き出したタイプをもとに、GoogleマップのAPIでスポットを検索する仕組みにしました。

アプリでは乗り換え情報も提供する予定でした。最初はGoogle Maps APIを利用して実装しようと考えていたのですが、実際に調べてみると日本国内の鉄道乗り換えには対応していないことが判明。インターネット上にも有力な情報が少なく、かつ無料で使える代替サービスも見つからず、解決策を探すのにかなり苦労しました。

そこで、独自に乗り換え機能を開発することに挑戦。アルゴリズムの調査やロジック設計を行い、駅データを提供する「ekidata」から全国の駅情報を取得して、乗り換え検索を実現しました。まだ運賃や所要時間など、正確さを高める部分は残っているものの、大量データを扱ったのは今回が初めてで、応答速度や70％ほどの精度（既存サービス比）を得られたのは大きな成果です。

今後は、この機能をAPIとして学内のサーバーに残し、後輩たちにも活用してもらえるようにするつもりです。

今回のチーム制作には、1年生・2年生・3年生が混在していました。特にエンジニアのポジションは私と1年生のメンバーのみで構成されていました。彼は非常に優秀な後輩でしたが、それでも技術的な差があるのは事実でした。

そこで、「技術レベルの差をできる限り縮め、1年生でもプロジェクトのコーディングに積極的に参加できるようにする」ことを意識しました。プロジェクトの進捗状況を踏まえ、Next.jsのコア技術を効率的に学べる学習プランを作成し、彼の理解度とやる気に合わせた指導を行いました。

その結果、「ここ」 にあるような簡単なテストを通じて、彼はプロジェクトのフロントエンド開発に十分貢献できるようになりました。

今回のプロジェクトの目的は HTML5 Awardへのエントリー であり、制作期間が短かったため、通常とは異なり 企画のブラッシュアップ・コーディング・デザインを同時並行で進める 必要がありました。

プロジェクト全体の進捗管理を担当する立場として、私はまず 各フェーズ（企画・デザイン・機能開発）ごとに短期目標を設定 しました。その上で、各メンバーのスキルに応じて、タスクを 細分化・具体化 し、適切に振り分けることで、効率的に進行できるよう調整しました。

プロジェクトを進める中で、メンバーの授業課題の進捗状況にも気を配り、負担をかけすぎないようにタスクの量を調整していました。しかし、その結果としてチームの進捗が遅れることもありました。

例えば、冬休み期間中は学年の後半ということもあり、メンバーが他の課題に集中できるようにタスクの量を減らしました。しかし、その影響でコミュニケーションが不足し、一部のメンバーがタスクの進め方を誤る「ミス」が発生してしまいました。

このバランスを取ることの難しさを今回のプロジェクトで強く実感しました。プロジェクトの進捗を維持しながら、メンバーの負担を軽減することの両立が、想像以上に困難であることを改めて学びました。

プロジェクト開始前に、Java Spring Bootを学習し、バックエンド開発のスキルを広げる計画 を立てていました。学習スケジュールも準備し、実際にプロジェクトで活用するつもりでした。

しかし、今回は デザインとコーディングを並行して進める という開発スタイルを採用したため、Spring Bootを使用する機会を得ることができませんでした。

次回のプロジェクトでは、必ずJava Spring Bootでバックエンドを実装します。