学生エンジニア

背景

オンラインで気軽に遊べる作品を短期間で形にしつつ、スコア送信や公開後の修正に耐えられる構成が必要でした。

課題

リアルタイムの体験を損なわずに、ゲーム本体とバックエンドの責務を分け、公開後も手を入れやすい状態を作ることが課題でした。

実装ポイント

• - ゲーム体験に直結する通信と、スコア登録 API を分離して役割を整理しました。
• - Go で API を実装し、将来的な認証導入や機能拡張を見据えて責務を分けました。
• - Terraform でサーバー構成を管理し、再構築や修正の再現性を持たせました。

工夫 / 学び

• - 短期開発でも公開後の運用を想定し、変更が影響する範囲を限定できる構成にしました。
• - 公開して終わりではなく、改善しやすさまで含めて設計する視点が身につきました。

背景

災害時の避難行動に対して、どのような支援が判断を助けるかを検証したいと考え、探究活動として設計しました。

課題

現実を完全に再現できない前提の中で、シミュレーションとして意味のある条件設定と検証方法を用意する必要がありました。

実装ポイント

• - 避難行動に影響する要素を整理し、比較可能な条件に落とし込みました。
• - Live2D キャラクターによる助言表示と行動ログ取得を組み合わせ、行動変化を追えるようにしました。
• - 結果の解釈で誤解が出ないよう、前提条件と限界を整理したうえでまとめました。

工夫 / 学び

• - 見た目の面白さだけで終わらせず、取得データをどう読むかまで含めて設計しました。
• - 非常時でも機能する仕組みや、障害に強い基盤への関心が強まりました。

背景

学習アプリとして使い始めやすく、更新しやすい構成で公開まで持っていく経験を積みたいと考えて開発しました。

課題

短期間で形にするだけではなく、学習導線の分かりやすさと、個人でも保守できる実装のバランスを取る必要がありました。

実装ポイント

• - Firebase を利用して認証とデータ保存を小さな構成でまとめ、公開までの速度を確保しました。
• - 今後の改善を見据えて、UI とデータの責務を分けて整理しました。

工夫 / 学び

• - 体験面でのシンプルさを優先し、操作説明が少なくても使える画面構成に寄せました。