概要

大学のプログラミング授業における、課題採点業務をDX化するWebアプリ。学生が提出したコードをジャッジサーバーで自動採点し、教員・TAの採点負担を削減する。

背景・課題

大学のような法人のDX化が遅れているという社会課題を解決する。

現状、教授が手動でコードを読んだり、TAが動作確認してハンコを押しており非効率。 これを効率化し、教員・TAの負担を減らす。

機能概要

学生向け機能

• 授業参加 — 招待コードで授業に参加
• 課題提出 — コードを提出（複数回可）
• 即時採点 — ジャッジサーバーによる自動採点＋教師のコメント
• 成績確認 — 採点結果・成績一覧を確認

フロー: 授業参加 → 課題提出 → 即時採点 → 成績確認

オーナー・教師向け機能

• 授業作成 — 授業を作成・管理
• 課題作成 — 内容・テストケース(in/out)・期限などを設定
• 提出管理 — 生徒ごとに提出を確認
• 採点修正 — 自動採点結果の修正・コメントが可能

フロー: 授業作成 → 課題作成 → 提出確認 → 採点修正

技術

フロントエンド

• Next.js
• SWR, react-hook-form
• orval codegen
  • useSWRを用いたAPI呼び出しhooks, zodのバリデーションを自動生成
• Zod
• Biome

バックエンド

• Spring Boot / Java
• Spring Security — JWT認証
• Spring Data JPA / Hibernate — ORM
• PostgreSQL — データベース
• springdoc-openapi 2.6.0 — OpenAPI仕様自動生成・Swagger UI
• JJWT 0.12.3 — JWTトークン生成・検証
• Spring Boot Validation — リクエストバリデーション（@Valid）
• Spring Boot DevTools — ホットリロード（開発環境）

インフラ

• Docker
• PostgreSQL
• ECR, ECS
• Terraform
• main pushをトリガーに自動でデプロイ

アーキテクチャ図

Claude CodeとDraw.io MCPを使用して作成。

挑戦・成長

チーム開発の進め方を体得

手戻りなくスムーズに開発を進めるには、メンバーとこまめにコミュニケーションを取りながら進めること、そしてタスクを適切に分担・配分することが重要だと、実体験を通して学んだ。仕様書の整備や Issue 管理と合わせ、チームを円滑に動かす視点が身についた。

新しい技術への挑戦

初挑戦の Spring Boot をキャッチアップしながら実装をやり切り、手をつけられていなかったジャッジサーバーも形にした。未知の技術にも臆さず踏み込み、最後まで作り切る力がついた。

技術選定の深掘り

いつもより根拠を持って技術選定に向き合い、他言語と比較した Java のメリット・デメリットを具体的に理解。「なんとなく選ぶ」から「比較・根拠を持って選ぶ」へと判断の解像度が上がった。

チーム開発で工夫したこと

開発体制・進行管理の整備

チーム開発を効率化し、認識のズレをなくすために、進捗の可視化とドキュメント整備を徹底しました。

1. Discord 整備 — 進捗の常時可視化

• GitHub の通知（Webhook）を Discord に連携
• コミットや Issue・PR の動きがリアルタイムで流れるようにし、いつでも進捗を確認できる状態を構築

2. 仕様・ドキュメントの徹底整備（docs/ 配下）

• システム仕様 / DB 設計 / 各種ツールの使い方 / デプロイ方法を docs/ に集約
• 狙い:
  • MTG の時間が取りづらい中でも、メンバー間の認識の相違をなくす
  • ドキュメントを参照するだけで開発を進められる効率的な体制に
• 副次的メリット: Claude Code に仕様書ベースで実装させやすく、仕様ドリブン開発との相性が抜群

3. GitHub Projects による Issue 管理

• 各メンバーの「今やっていること / これからやること」が明確に

具体的な工夫:

• FigJam でアイデア出しを可視化し、認識を共有しやすくした
• Issue ドリブン開発で、GitHub にドキュメント・プロジェクト管理を一元化
  • Issue ベースでタスクを細分化・明確化し、複数の実装が混ざったぐちゃぐちゃなコミットを防止
  • 担当・進捗を可視化し、開発しやすい状態に

技術選定・技術活用

このアプリに適した技術選定を行うことで技術を適切に活用。

Java / Spring Boot

• 成績という重要データを扱うのでデータ消失、誤集計が許されない → 堅牢性が求められる
• TSは型が実行時に消える（コンパイル時のみの保証）、PydanticはAPIの境界でのバリデーションが中心で言語自体は動的 → Javaは言語の土台が静的型付けで、ロジック全体をコンパイル時に検査。実行時もJVMが型情報を保持するため、不正な型操作は例外で弾ける
• Node.jsやPythonに比べて高負荷に強い：JVMの標準マルチスレッドで、一斉提出時も多数の同時リクエストを安定処理
• 並行処理ならGoも強い、むしろ有利な面もあります。ただ今回は権限制御・採点修正・コメントなど業務機能の拡張が多いプロダクトなので、認証認可やORMが標準で揃うSpringの方が、限られた時間で堅牢に作れると判断しました。
• KotlinもSpringが使えて、null安全で簡潔なので有力候補でした。ただ今回はチーム初のSpring Boot挑戦で、まず情報量が最も多いJavaで土台を固めたかった。Kotlinは次のステップとして考えています

PostgreSQL

• 構造が決まっていて関係性・集計が多いデータは、リレーショナルDB（SQL）が向いている。
  • Firebase（NoSQL）は集計・JOINが苦手で、関係性の強い採点データに不向きなので不採用
• SQLiteより同時書き込みに強く、MySQLより高機能
  • PostgreSQLは標準準拠で高機能、データ整合性に厳格で、成績という消失・誤りが許されないデータや将来の機能拡張に対応しやすい。
• Supabaseとの比較
  • ① 速くなるのはCRUDだけ。難所は残る
    • Supabaseが時短できるのはデータの読み書きAPIのみ。本体であるジャッジ実行・採点ロジックは結局バックエンドが必要。どうせ作るならSpring Bootに一元化した方がシンプル。
  • ② 速さの裏でセキュリティリスクが上がる
    • フロントから直接DBを叩くと権限制御をRLS頼みになる。成績システムでは「他人の点数・コードを見せない」「成績を書き換えさせない」が必須で、RLSでの作り込みはミスると情報漏洩・改ざんに直結。バックエンドを挟めば認可を1か所で確実に管理できる。

遊び心

• 着せ替え機能