お客様のビジネス成長を支援し、新たな価値を共に創造し、課題を解決するためのアプリケーションです。その名前は、さまざまな世代(Era)を同期(Sync)するというコンセプトに由来しています。
メンバーの日々の業務内容を要約し、マネージャーや育成担当とメンバーのコミュニケーションを円滑にして、エンゲージメントを向上させるコミュニケーション支援ツールです。
上司と部下など、年代や職務の異なる社員同士のコミュニケーションが活性化しにくい問題や、職場でジェネレーションギャップを感じる人は一定数いる現状を把握。多くは仕事への向き合い方やコミュニケーションの取り方にそのギャップを感じ、困った経験があると回答している調査結果などから、SyncEra は、これらの問題を解決し、チームの効率的なコミュニケーションと情報管理を支援することを目的として開発しました。
- mikiko - リーダー、フロント全般
- meme - バックエンド(主に LLM 関連)、データベース、環境構築、テスト
- sayoko - バックエンド(主に SlackAPI 関連)、インフラ
- ku-min - 決済、認証、フロント(左記関連)
Next.js & TypeScript (フロントエンド、言語)
-
類似技術との比較
💡 SyncEraでは、以下の理由からNext.js (App Router)を選択: Next.js (App Router)は、比較的導入されてまだ数年(Next.js 13 のリリースで導入:2022 年 10 月)と日が浅いが、Next.js (App Router)の直感的にファイルベースのルーティングができることと共通の UI 要素(ヘッダー、フッターなど)を複数のページで再利用などのレイアウト管理が可能なため、将来的にアプリを拡張性した場合にも対応できたり、開発を効率化できると思い選択しました。特徴 Next.js (App Router) Next.js (Pages Router) React 最新の React 機能サポート 完全サポート 部分的サポート 基本サポート ルーティング ファイルベースで直感的 ファイルベース 追加設定が必要 レイアウト管理 容易 やや複雑 追加設定が必要 ローディング状態管理 容易 やや複雑 追加設定が必要 エコシステム 発展途上 成熟 非常に成熟 SSR と SPA の両立 容易 容易 追加設定が必要 プロジェクト構造 やや複雑 シンプル 自由度が高い 従来の React 概念との互換性 やや低い 高い 完全互換 カスタマイズ性 高い 高い 非常に高い サードパーティライブラリ 一部制限あり 豊富 非常に豊富 初期構築時間 中程度 短い 長い
Python (バックエンド言語)
-
類似技術との比較
💡 SyncEraでは、以下の理由からPythonを選択:特徴 Python TypeScript 読みやすさ 非常に高い 高い 開発速度 速い やや遅い 型安全性 動的型付け(型ヒントあり) 静的型付け 大規模アプリケーション適性 中程度 高い データサイエンス/機械学習ライブラリ 非常に充実 限定的 データ処理ライブラリ 豊富(例:Pandas, NumPy) 少ない Web 開発フレームワーク 豊富(Django, Flask, FastAPI 等) 豊富(Angular, React, Vue 等) 実行環境 サーバーサイド中心 ブラウザ・サーバーサイド両方 コンパイル/インタープリト インタープリタ言語 トランスパイル言語 エコシステム 非常に大きい 大きい、成長中 SyncEraでは、LLM(自然言語処理)やSlackAPIから取得したデータの分析について重要な部分をもつアプリなため、データ処理分野で処理能力の高いPythonが適していると判断しました。 また、将来的に、ユーザー行動の予測分析などを行うことも想定して、高度な分析や予測機能の実装を拡張できるのではないかと思いPythonと選択しました。
FastAPI (バックエンド)
-
類似技術との比較
💡 SyncEraでは、以下の理由からFastAPIを選択:特徴 FastAPI Flask Django 非同期処理 強力 限定的 限定的 パフォーマンス 高速 中程度 中程度 自動ドキュメント生成 あり なし 限定的 軽量性 軽量 非常に軽量 重量級 柔軟性 高い 非常に高い 中程度 大規模アプリケーション対応 対応可能 追加設定が必要 優れている 機能の豊富さ 中程度 最小限 非常に豊富 学習曲線 緩やか 非常に緩やか 急 プロジェクト構造 自由度が高い 自由度が非常に高い 規約が厳格 コミュニティサポート 成長中 豊富 非常に豊富 FastAPIを選択した主な理由は、主には非同期処理のサポート がある点 SyncEraでは、Slackからのリアルタイムデータ取得や、クライアントへの非同期レスポンスとOpenAI_APIも使用していて、非同期的な処理が多く必要となるため、FastAPIが、SyncEraのアプリ開発の要件に適していると考え選択しました。
PostgreSQL (データベース)
- 類似技術との比較
特徴 PostgreSQL MySQL MongoDB (NoSQL) データモデル リレーショナル リレーショナル ドキュメント指向 拡張性 高度な拡張性 中程度の拡張性 高い拡張性 複雑なクエリ処理 優れている 標準的 制限あり JSON 対応 サポート 部分的サポート ネイティブサポート トランザクション処理 堅牢 堅牢 制限あり データ整合性 高 高 柔軟 大規模データ処理 優れている 標準的 優れている スケーラビリティ 垂直スケーリングに強い 垂直スケーリングに強い 水平スケーリングが容易 コミュニティサポート 豊富 非常に豊富 豊富 設定・最適化 やや複雑 比較的容易 比較的容易 非構造化データ処理 対応可能 制限あり 非常に適している 💡 SyncEra では、以下の理由から PostgreSQL を選択: MongoDB のような NoSQL ソリューションも検討しましたが、SyncEra のデータモデルは比較的構造化されており、リレーショナルデータベースの利点を活かせることと、Slack からのデータやアンケートの回答など、半構造化データを扱うため、PostgreSQL の JSON 対応により、必要に応じて柔軟なデータ構造も実現できると判断し選択しました。
Redis (キャッシュ)
-
類似技術との比較
💡 SyncEraでは、以下の理由からRedisを選択: Redis はリストやセットなど、複数のデータ構造をサポートしていて、リアルタイムなデータ処理、複雑なデータ構造の扱いが可能なため、SyncEra のアプリ開発で機体している高速なレスポンスとスケーラビリティ(ソフトウェアの拡張性に柔軟に対応)を満たしていると思い選択。そのほか、基本的なキャッシュ機能以外にもトランザクションなどの機能が提供されており、将来的な機能拡張にも柔軟に対応できる点も選択理由です。特徴 Redis Memcached(メムキャッシュド) データ構造 扱えるデータの形式や種類 キー・バリュー(単純な値の保存)、リスト(順序付きのデータ集合)、セット(重複のないデータ集合)、ハッシュ(ブジェクトのような構造化データ)など キー・バリューのみ 持続性 サポート 非サポート スケーリング システムの処理能力を拡張する能力 クラスタリング対応 ※複数のサーバーにデータを分散させること。システム全体の処理能力を向上させることができます。 一部サポート 機能 多機能 Redis は基本的なキャッシュ機能以外にも、パブリッシュ/サブスクライブ、トランザクション、Lua スクリプティングなど、多様な機能を提供 シンプル 使用例 セッション管理、キュー管理、リアルタイム分析など シンプルなデータキャッシュ データサイズ制限 データサイズに制限なし 1MB 以下が推奨 利用例 ソーシャルネットワーキングアプリ、e コマースサイト、リアルタイムデータ処理 ウェブキャッシュ、セッションストア 開発言語バインディング 多言語対応(Python, Ruby, Java, C, C++, etc.) 多言語対応(Python, Ruby, Java, C, C++, etc.)
Firebase (認証)
-
類似技術との比較
💡 SyncEraでは、以下の理由からFirebaseを選択:特徴 Firebase Authentication Auth0 AWS Cognito カスタム実装 セットアップの容易さ 非常に簡単 簡単 やや複雑 複雑 多要素認証 サポート 高度なサポート サポート 要実装 ソーシャルログイン 多数対応 多数対応 一部対応 要実装 カスタマイズ性 中程度 高い 高い 非常に高い スケーラビリティ 高い 非常に高い 非常に高い 要設計 コスト 無料枠あり、従量制 比較的高価 使用量に応じて 初期コスト高 クライアント SDK 充実 充実 充実 要実装 バックエンド連携 Google Cloud 連携 多様なインテグレーション AWS 連携 完全自由 セキュリティ 高い 非常に高い 高い 要設計・実装 ドキュメンテーション 豊富 非常に豊富 豊富 N/A - SMSやメールの多要素認証やGoogle、Twitterを利用してログインを利用できる機能が標準で提供されて
- コストは、初期段階では無料枠で開発が進められ、成長に応じて柔軟にスケールアップ可能
- 将来的なバックエンドサービスの拡張を見据えると、Cloud Functions、Cloud Storage、Firestore等との連携が容易でGoogle Cloud Platformの他のサービスとの統合ができ、セキュリティ機能(DDoS保護、暗号化等)が高い。
- 将来的にモバイルアプリを開発する際にも同じ認証基盤を利用できる。
SyncEraへの利点: バックエンドサービスの拡張や、データ分析、機械学習機能の追加など、将来的な機能拡張を見据えた際に、統合された環境で開発を進められ、
アプリの現在の要件(迅速な開発、基本的な認証機能)と将来の成長(スケーラビリティ、高度なセキュリティ要件)の両方に対応できると判断し選択。
Google Cloud Run (cloud)
-
類似技術との比較
💡 SyncEraでは、以下の理由からGoogle Cloud Runを選択:項目 Google Cloud Run AWS (ECS, Lambda, etc.) デプロイの簡便さ ◎ 非常に簡単。サーバーレスで自動デプロイが可能。GitHub との連携もシームレス。 △ 比較的複雑。ECS や Lambda など複数の選択肢があり、設定がやや手間。 スケーリング ◎ 自動スケーリングがデフォルトで設定されており、トラフィックに応じて自動調整。 ○ スケーリングは可能だが、設定やチューニングが必要。ECS では Fargate がサーバーレススケーリングを提供。 コスト効率 ◎ アイドル時はゼロインスタンスでコストが発生しない。従量課金制で予測しやすい。 △ 従量課金だが、スケーリングやリソース追加時にコストが複雑になりがち。 学習コスト ◎ 低い。シンプルな設定で初心者向けのチュートリアルが豊富。 △ 高い。多機能で柔軟だが、初心者には学習に時間がかかる可能性あり。 Firebase との統合 ◎ 非常にスムーズ。Google のサービス同士での連携が容易。 △ AWS は Firebase の代替サービス(Cognito など)を使用。連携に工夫が必要。 コンテナサポート ○ Docker コンテナをネイティブサポート。コンテナをそのままデプロイ可能。docker-compose は不可。 △ Docker コンテナを ECS や EKS でサポートしているが、設定が複雑。 インフラ管理 ◎ サーバーレスでインフラ管理の負担がほぼない。 △ ECS や EC2 の場合、インフラ管理が必要。Lambda はサーバーレス。 ネットワーク管理 ○ デフォルトで簡素なネットワーク管理。高度なネットワーク設定は手間がかかる。 ◎ AWS VPC を使用して細かいネットワーク管理が可能。柔軟性が高い。 Redis との統合 ○ Google Cloud Memorystore を使用。設定が必要だが可能。 ◎ Amazon ElastiCache で Redis が簡単に利用可能。 PostgreSQL との統合 ○ Cloud SQL を使用して PostgreSQL と連携。VPC コネクタが必要な場合もあり。 ◎ RDS を使用して PostgreSQL とシームレスに連携可能。 セキュリティ ○ Google Cloud IAM で簡単にアクセス制御が可能。Google のセキュリティ基準を利用。 ◎ AWS IAM で強力なアクセス制御が可能。細かい設定が必要。 初期設定の手間 ◎ 非常に少ない。デフォルトで多くの機能が自動化。 △ 初期設定に時間がかかる場合があり、学習曲線がある。 サポートとドキュメント ◎ Google Cloud の豊富な初心者向けドキュメントが揃っている。 ○ AWS のドキュメントは充実しているが、初心者には難解な部分が多い。 主に、AWSと比較したところ、デプロイが簡便にできるところや、システムの処理能力を需要に応じて拡張するこスケーリングが自動で設定されていること、そのほか、コスト効率やFirebase統合の面で優れている点が、
今回のアプリ開発(開発サイクルが短期間とチームの技術スキルレベル)にマッチしていると考え選定。
-
プロダクト要求仕様書 (pdr.md)
-
画面仕様書(WF)(WF.md)
-
デザインガイドライン(design.md)
-
API 設計書(api_design.json)
-
データベース構造(db_design.md)
-
ER 図(ER_0820.png)
-
アーキテクチャ図(architecture_diagram.png)
-
コーディング規約(coding_rules.md)
-
ESLint 各環境での設定方法(ESLint.md)
-
非機能要件設計書(nonfunctional_requirements.md)
-
認証系単体テスト(auth_stripe_test.md)
-
負荷テスト実施結果(jmeter_scenario.md)
-
E2E テスト(概要、結果)(E2E_scenario.md)
-
全て統合した compose を立ち上げる手順(standing_procedure.md)
- SyncEra/docs ディレクトリ>
プロダクト要求仕様書 (pdr.md)>
関係資料(issue の調査)


