はじめに
本記事はポートフォリオアプリ「DevJourney」開発の過程をまとめた連載の第3回です。
今回は第2回の要件定義で決まった要件を実現するために、どのような技術スタックを選んだのか。その「選定理由」と「比較検討のプロセス」を詳しく解説します。
技術選定の軸
以下の3つの軸を設定しました。
- 開発効率の最大化
- Infrastructure as Code(Iac)の実践
- 開発現場で汎用的に用いられているAWSサービスを扱う
クラウドプラットフォームの比較と選定
採用：AWS(Amazon Web Service)
本アプリケーションは特定のプラットフォーム（Microsoft 365等）に依存せず、高度なデータ分析特化でもないため、汎用性と安定性に優れたAWSを選択しました。
選定理由
- 国内シェアが最も高く、IT市場での需要が圧倒的。
- マネージドサービスが豊富で、個人開発でもエンタープライズ級の構成を組みやすい。
- 後述するIaC（CDK）やCI/CD（CodePipeline）との親和性が非常に高い。
- AWSの資格を取得したものの、会社の業務でほとんど扱う機会がなかったため。(個人的な理由)
バックエンドの比較と選定
採用：TypeScript × NestJS
選定理由
バックエンドには、Node.js上で動作するNestJSを採用しました。Angularにインスパイアされた厳格なアーキテクチャを持ち、依存性注入（DI）やモジュール化が標準で備わっています。
型安全性の徹底： TypeScriptを前提としているため、フロントエンドと型定義を共有しやすく、大規模開発にも耐えうる保守性を確保。
AWSとの親和性： CDKでインフラの実装を行う都合上、メインで扱われている言語がTypeScriptとなっているので、アプリ全体として扱う言語をTypeScriptに統一したいため。
| 比較対象 | 不採用理由 |
|---|---|
| Express | 軽量だが設計が自由すぎる（人依存になる）。AWSのような複雑なクラウド構成では、標準化されたNestJSの方が管理しやすい。軽量だが設計が自由すぎる（人依存になる）。AWSのような複雑なクラウド構成では、標準化されたNestJSの方が管理しやすい。 |
| Go | パフォーマンスは魅力だが、今回は「TypeScriptによる全レイヤーの言語統一」による開発スピード向上を優先。 |
フロントエンドの比較と選定
採用：TypeScript × Next.js
選定理由
ReactベースのフルスタックフレームワークであるNext.jsを採用しました。
市場価値の高さ： 求人数・ナレッジともにReact/Next.jsが圧倒的に優位である点。
AWSとの親和性： AWS AmplifyやApp RunnerでのSSR（サーバーサイドレンダリング）サポートが手厚く、デプロイ時の手間が少なくて済む。
| 比較対象 | 不採用理由 |
|---|---|
| Nuxt.js / Vue.js | AWSの公式ドキュメントやテンプレートはNext.jsが優先される傾向にあり、設定の平易さで一歩劣る。 |
| Angular | 学習コストが高く、かつ現代のSSRトレンドにおいてはNext.jsほどの勢いがない。 |
データベース・そのほかの設定
1.データベース
採用：Amazon RDS for PostgreSQL
今回の要件（学習ロードマップの構造化データの保持）を考慮し、RDBを選択しました。
| 比較対象 | 不採用理由 |
|---|---|
| MySQL | JSONデータ型の処理がPostgreSQLと比較して劣るため。将来的にロードマップの詳細を柔軟な構造で保存する可能性を考慮した。 |
| Aurora | 個人開発にはオーバースペック/高コスト。 |
| DynamoDB | 複雑な集計クエリに向かない。 |
2.認証
採用：Amazon Cognito
セキュリティリスクを最小化するため、ユーザー管理をフルマネージドサービスへ委譲。JWTベースの認証により、Next.jsとの統合が容易。
3.IaC
採用：AWS CDK (TypeScript)
今回の目玉の一つ。CloudFormationを直接書くのではなく、プログラミング言語（TS）でインフラを定義することで、ループ処理や条件分岐を活用した高度な抽象化を実現。
技術スタックの全体像
| カテゴリ | 選定技術 | 備考 |
|---|---|---|
| フロントエンド | Next.js (TypeScript) | SSR / App Router採用 |
| バックエンド | NestJS (TypeScript) | 明確な実装方式を意識 |
| インフラ | AWS (ECS on Fargate) | 運用負荷を下げつつコンテナ化 |
| DB | RDS (PostgreSQL) | 柔軟なデータ構造に対応 |
| 認証 | Amazon Cognito | フルマネージド認証 |
| IaC | CDK | TypeScriptでインフラをコード化 |
まとめ
今回の技術選定では、 「TypeScriptへの統一」 と 「AWSマネージドサービスの活用」 を軸に据えました。これにより、開発スピードを維持しながらも、実務で求められる「堅牢なアーキテクチャ」と「IaCによる自動化」を両立する準備が整いました。
特にDB選定においては、単なる慣習ではなく「データの特性（JSON処理）」や「コスト・耐障害性」といった実務的な観点で比較検討を行いました。
次回は、これらの技術を用いてどのようにシステムを組み上げたのか、「第4回：設計・実装編①（アーキテクチャ図・DB設計）」について解説します！