社内の研究開発プロジェクトの一環として、子ども向けのIT教育を目的とする「すごろく」を開発しました。
こちらの開発を通じて感じた「良かったこと」・「苦労したこと」をまとめます。
目次
1. はじめに
このプロジェクトは、小学生から中学生くらいの子どもたちに向けて、IT業界に興味を持ってもらうことと、将来一緒に働く仲間を増やすことを目的にスタートしました。
内容としては、子ども向けにITの要素を含めたコンテンツを提供することで、子どもたちに体験を通じて、ITに触れてもらおうと考えました。
提供するコンテンツは複数の案がありましたが、友だちや家族と遊びながらITを学ぶことができるという理由から、すごろくを開発することに決めました。
2. 技術構成
すごろくは、PC・スマートフォン・タブレットから遊べるように、ブラウザゲームとして開発しました。
技術的には、Webアプリケーションを開発する構成になります。
オンライン通信の実現については、今回は Socket.IO を利用しました。
フロントエンド
- next 15.4.4
- react 19.1.1
- socket.io-client 4.8.1
- typescript 5.7.3
バックエンド
- express 5.0.0
- node 22.12.1
- socket.io 3.0.1
- typescript 5.7.3
インフラ
- AWS ALB
- AWS EC2
3. 開発の中で良かったこと
開発を進める中で良かったことを、以下にまとめます。
3-1. 機能の洗い出し
1つ目は、すごろくに必要な機能を、あらかじめ洗い出したことです。
今回のすごろくに必要な機能としては、主に以下が挙げられました。
大まかに機能を洗い出すことで、機能に関連するタスクのイメージも併せて行うことができます。
これにより、見通しを立てながら開発を進めることができました。
| 機能 | タスク | ソケット通信 |
|---|---|---|
| アイテム | アイテムをつかえるようにする | あり |
| キャラクター | キャラクターをうごかす | なし |
| サイコロ | サイコロをふれるようにする | あり |
| イベント | イベントをはっせいさせる | あり |
| マップ | マップをデザインする | なし |
| ルーム | ルームをつくれるようにする | あり |
3-2. 最小限の機能開発
2つ目は、開発を段階に分けて、最小限の機能開発を行ったことです。
今回は研究開発のため、一度に全てを開発するのではなく、すごろくとして最小限の機能の開発ができた段階で遊んでもらうようにしました。
機能とタスクに優先順位を付けることで、機能毎に「開発できている」・「開発できていない」、または「課題」を明確にしながら開発を進めていくことができました。
第1フェーズ（子ども向けお試しバージョン）
- マップ
- サイコロ
- キャラクター
- イベント
- アイテム
第2フェーズ（社内向けベータバージョン）
- ルーム
- BGM
- SE
3-3. 開発言語の統一
3つ目は、フロントエンドとバックエンドの開発言語を TypeScript に統一したことです。
すごろくの開発はスモールチームのため、開発者はフルスタックのような形で立ち回る必要がありました。
そのため、フロントエンドとバックエンドに同一の言語を利用して、一部を共通化することで、効率的に開発を進めることができました。
4. 開発の中で苦労したこと
開発を進める中で苦労したことを、以下にまとめます。
4-1. フロントエンドの状態管理
1つ目は、フロントエンドでのデータの管理方法についてです。
すごろくはオンライン通信を行うため、フロントエンドとバックエンド間で頻繁にデータの送受信が発生します。
その際に、基本の状態管理である state だけでは、ページやコンポーネントが増える毎にデータを管理し辛くなることが予想されたため、どのように管理するべきか迷いました。
そこで今回は、主な状態管理に Context を利用することにしました。
Context を利用することで、ページやコンポーネント間でのデータの取得・更新を一元化でき、状態管理を容易にすることができました。
また、Context へのデータの更新は Reducer に一元化することで、ファイル毎の役割を明確にし、意図しない更新が行われないようにしました。
※今回の状態管理の流れは、以下の通りです。
1. フロントエンド から データ を 送信
2. バックエンド にて データ を 受信
3. バックエンド から データ を 送信
4. フロントエンド にて データ を 受信
5. フロントエンド にて 受信したデータ を Reducer に 渡す
6. フロントエンド にて Reducer が Context に 受信したデータ を 渡す
7. フロントエンド にて Contextのデータ が 更新される
4-2. フロントエンドの再レンダリング
2つ目は、フロントエンドにて表示される画面の更新についてです。
先に述べたように、今回はフロントエンドとバックエンド間で頻繁にデータの送受信が発生するため、それに伴い、フロントエンドにて表示される画面も更新されていきます。
画面の更新は意図した順番で行われる必要があるので、データの受信時は useEffect で検知させる、といった工夫をすることで更新のタイミングを調整しました。
しかし、更新のタイミングについては仕組みが難しく、現在も一部で意図しない更新が行われてしまっているため、解決できるように取り組んでいます。
※例えば、サイコロをふった後には、以下の順番で画面が更新されます。
1. サイコロ が 表示される
2. キャラクター が 表示される
3. イベント が 表示される
4. アイテム が 表示される
5. サイコロをふるボタン が 表示される（次のターンのプレイヤー）
4-3. ゲームの動作確認
3つ目は、開発したすごろくの動作確認についてです。
各機能の動作確認を行った際、狙った動作の発生に苦労することが多かったです。
具体的には、ゲーム中のルーム退出の処理の確認（プレイヤー毎）や、アイテムの効果の確認（約40種類）などです。
それぞれ複数のパターンが存在しており、1ゲームが約10～20分のため、動作確認の時間が長くなりがちでした。
ゲームにはどんどん機能を追加していきたいですが、それに伴い動作確認する対象が増えていくことが予想されるため、自動テストの実装も進めていきたいと思います。
5. さいごに
今回開発したすごろくについて、実際に子どもたちに遊んでもらう機会がありましたが、とても楽しんでもらうことができていました。
サイコロをふってキャラクターがうごいている様子だけでも、面白いと感じられたようです。
また、子どもと親が一緒に遊ぶことで、ゲームに出てくる言葉を聞いたり・教えたりしながら進めることもできるので、家族のコミュニケーションにも活用できそうです。
開発者は普段の業務と並行して開発を進めているので、あまり時間を取れないことが多くありましたが、できるだけ時間を調整して開発に取り組んできました。
現在は社内向けに公開するところまで達成できているので、より多くの子どもたち（大人も）に遊んでもらうために、引き続き内容をブラッシュアップしていきたいと思います。
おまけ
ゲーム画面①
ゲーム画面②
ゲーム画面③
