Yuto Onishi

【概要】IoT連携タスク管理アプリ「Tokiwa Calendar」
【チーム構成】学生4人（フロント１、バックエンド兼インフラ１、ハード２）
【担当箇所】バックエンド・インフラ構築
【利用技術】Go
【開発環境】AWS Lambda, Firebase, MQTT
【開発背景】大学のサークルによる夏の開発合宿より発足
「チーム開発を始めたばかりでタスク管理に不慣れな学生を助ける」というコンセプトで開発した、webカレンダーアプリです。
特徴は、「ログイン不要、URL共有で誰でも手軽に編集可能な機能」と、タスク放置を防ぐ「物理的なリマインド機能（期日が迫るとパトロールランプをガンガンに回す、冷房で部屋をガンガンに寒くする等）」の二つです。
当初は手軽に使えるwebカレンダーとして作りましたが、『技育キャラバン（2025/6/15）』で企業の方から「Googleカレンダーでよくない？差別化が弱い」とフィードバックを頂きました。
そこから課題を洗い出し、ペルソナを詰め直し、現在の「物理的介入で強制的に行動を促す」コンセプトに落ち着きました。
その後、『技育博vol.4（2025/9/13）』にてフィードバックを集め、現在さらなる規模拡大に向けアーキテクチャから再設計を行っています。
【頑張ったところ/工夫したところ】
最もこだわったのは、「実装したいユーザー体験から逆算した技術選定」です。
ただのWebアプリからIoT連携へと再設計した際、フロントエンドとハードウェアの通信をバックエンド側でどう確立するかが課題でした。
そこで私はMQTTを採用しました。MQTT通信にすることで、パトロールランプや冷房など、機能の異なるハードウェアを切り替えられるようにしました。これにより、ユーザー自身が「自分が一番タスクを実行できる手段」を選べる拡張性を持たせました。当時は42tokyoで体系的なプログラミングを学ぶ前で、GoやAWSも手探り状態でしたが、公式ドキュメントを読んでシステムを構築しました。
「ユーザーのフィードバックを受け止め、分析し、必要な技術を実装する」という経験が、現在の「ユーザー体験を意識して技術を選定する」という私の開発姿勢になっています。

「webアプリTokiwa-Calendar」開発

【概要】サークル内学習管理「Discord Bot もくもく」
【チーム構成】個人開発（設計の壁打ちとして先輩メンター2名）
【担当領域】バックエンド実装、インフラ構築、CI/CD整備すべて 
【利用技術】Go, Firebase, Discord API
【開発環境】AWS Lambda, GitHub Actions

【開発背景・プロダクトの特徴】 
サークル内の学習意欲の向上を目的としたBot開発です。Discordのボイスチャンネルの滞在時間を計測して週間ランキング化する機能や、メンション付きで定期通知を行う機能を作りました。学習時間が可視化することで、サークル全体を巻き込んだモチベーションの向上をしたいと思い開発しました。

【頑張ったところ/工夫したところ】 
主に「実行環境の深い理解と自動化」、そして「ユーザーの声の反映」の二点に力を入れました。
一点目は、AWS Lambdaへのデプロイにおける「クロスコンパイル」と「CI/CDによる自動化」です。 当初、手元のWindows環境でビルドしたバイナリが本番環境（Lambda）で動かず挫けました。そこでOSやCPUアーキテクチャの違いを調べ、Windows（amd64）とLinux（arm64）の差異に気づきました。単にツールを使うだけでなく「なぜ動かないのか」を理解し、PowerShellでGOOS=linuxやGOARCH=arm64といった環境変数を設定し、Lambda特有のbootstrapという命名規則に合わせて手動でクロスコンパイルしました。
しかし、この手作業（コマンド入力、zip圧縮、アップロード）は工程が多く、間違えやすいです。そこで、本来やりたい機能開発に集中するため、GitHub Actionsを用いたCI/CDパイプラインを構築しました。手作業の苦労と原理を体感したからこそ、テストからLinux向けビルド、デプロイまでの自動化を高い解像度で実装できました。

二点目は、生の声を受けた体験の改善です。 「別の雑談チャンネルに移動しても勉強時間が計測され続ける」等の指摘を受け、Discord APIのイベント検知のロジックを改善しました。

これらより、「実行環境の仕組みを理解して壊れない自動化機能を作り、ユーザーに沿った体験を作る」という開発サイクルを経験しました。

「Discord Botもくもく」開発

42Tokyo（ソフトウェアエンジニア養成機関）