特定の事業ドメイン（災害支援・避難管理）を想定し、インターンシップ選考用に開発した情報共有プラットフォームです。
本サービスは、災害時における「避難者のステータス管理」と「現場のリアルタイムな情報共有」の効率化を目的としています。 単なるSNS機能に留まらず、バーコード認証を用いた確実な受付管理など、実務的な業務フローをシステムに落とし込んでいます。
- QRコード受付・認証機能
- 管理者（避難所側）が一般ユーザー（避難者）の個人QRコードをスキャンすることで、ユーザーのステータスを即座に「避難済み」へと更新します。
- リアルタイム・ユーザーステータス共有
- 各ユーザーの現在状況（未避難 / 避難済み）をユーザー名の横にバッジ表示。コミュニティ内での安否確認を容易にします。
- 避難情報・救援要請の投稿機能
- 自身の状況や必要な支援内容をタイムラインに投稿・発信できます。
- パフォーマンス最適化（ページネーション）
- 投稿数が増加しても、ページ切り替え機能により、低速なネットワーク環境下でも快適な動作を維持します。
- 自動同期（自動リロード）
- Supabaseのリアルタイム機能を活用し、手動更新なしで常に最新の投稿やステータスを表示します。
| 技術 | 役割 |
|---|---|
| React | コンポーネントベースのUI構築 |
| Tailwind CSS | 迅速かつレスポンシブなスタイリング |
| Node.js | サーバーサイドロジックの実装 |
| Supabase | 認証、DB、およびリアルタイムデータの同期（BaaS） |
- 実用性の追求: 避難所での受付業務を想定し、スマホ一台で完結するバーコード認証フローを設計しました。
- UI/UX: 緊迫した状況でも視覚的に状況が判別できるよう、Tailwind CSSを用いて直感的なカラー設計を行いました。
React+Node+Tailwindにしました。この構成にした理由は、この構成ならバックエンドもフロントエンドもtypescriptで開発できるという点や 開発期間が短かったので、この構成だと初期セットアップである程度構築してくれるので短期間でも開発が可能になるという点。 また、このインターンシップ用のSNSを提出する先がこの技術スタックでの開発をしていたので、技術アピールになるとしてこの構成で開発しました。 デメリットとして、Nodeが単一バイナリでないので遅い。というものや、TailwindとReactが特定のバージョンだと相性が悪くてうまく動かない などがありましたが、そこまで重いサービスを製作するつもりがなかったので単一バイナリでないことにより発生する遅延は許容範囲だと考えました。 また、バージョン管理の問題についても.jsonでうまく調整すれば動くので許容できると考えました。また、MUIではなくTailwindを用いた理由としては MUIはカスタム性が低いけれど簡単に整ってしまうので、すぐに開発できる一方私のデザイン能力が選考先に伝わりにくいと考えたので、Tailwind cssを用いて、 cssを書くことで、AIでも苦手とするcssを書ける人間であることをアピールしました。
supabaseを選択しました。このような開発でよく使われるFireBaseではなく、supabaseを選んだ理由としては認証機能がfirebaseに比べて充実しているので将来的に 新しい認証機能を取り入れたくなった時に、簡単に取り入れられることから選びました。デメリットとして長く使われてない状態から開いたときに立ち上げに時間がかかる というのがありましたが、これは非同期処理を用いて画面にロードなどの表示をしておくことである程度許容できると考えました。
vercelを用いました。他のサービスと違いバックエンドまで含めてデプロイ出来るということで選択しました。デメリットとして通信料の無料枠が小さいというのがありますが、 このSNSは選考でしか用いないということ、画像のやり取りをしない構成にしていることから通信料が抑えられることから許容できると考えました。
開発の途中で、React-qr-readerを導入するためにreactのアップデートをしたところtailwind cssの設定がきちんと反映されなくなるという不具合が起こりました。 エラーメッセージからtailwind cssがエラーをはいているとわかりました、qiita同様の症状を検索しreactを適切なバージョンにすることで修正に成功しました。
カラムをroleごとに分離しなかったので、アカウント登録の入力欄やポストの入力欄でコードを書かれた場合にroleをadminに変えられうる構成になってしまいました。 今回は、将来的にこのSNSを大きくした場合adminにもっと大きな権限を持たせることが考えられること、さらに悪意のある第3者がadminになることで正確な情報が求められる 災害用SNSで不正確な情報が流れてしまうリスクを考えると、カラムを分離するべきだったと反省しています。
Developed by enari-K