目次
DB選定の「型」を知る — RDBMSとNoSQL、なぜそれを選んだのか？
データベースには大きく分けて2つの「型」があり、それぞれ得意なことと、避けられない弱点があります。私たちが担当するサービスがどちらの型を選んでいるかを知ることは、仕様変更の難易度を測る上で非常に重要です。1. 信頼性・整合性重視の「RDBMS」（リレーショナルDB）
代表例: MySQL、PostgreSQL思想: 「絶対に間違えないこと」を最優先する。銀行やECサイトの決済など、データの厳密な整合性（トランザクション）が求められる場合に採用されます。
ディレクターの懸念点： データを表形式で厳密に管理するため、一度決めたデータ構造の変更が非常に大変です。大規模な機能追加や仕様変更の際は、RDBMS側の変更コストを高く見積もる必要があります。
2. 速度・拡張性重視の「NoSQL」
代表例: MongoDB、Redis思想: 「大量アクセスに耐え、速く動くこと」を最優先する。SNSのタイムラインやログデータなど、柔軟性や処理速度が重要な場合に採用されます。
ディレクターの懸念点： サーバーを簡単に増やせる（スケールアウト）メリットがありますが、その代償としてデータの整合性が一時的に緩くなる場合があります。「このデータはリアルタイムでなくてもいいか？」と確認する視点が重要です。
API連携で陥りがちな二つの「落とし穴」
フロントエンドの画面表示速度は、APIによるデータの受け渡し方に大きく依存します。ディレクターとして、この2つのパフォーマンス問題が発生していないか確認できるようになりましょう。1. N+1問題：サーバー負荷集中による処理遅延
これは、1つのリストを表示するために、不必要にAPIコール（DBアクセス）が何度も発生してしまう現象です。現象の例: 投稿記事一覧（N件）を表示する際、まず記事リストを取得（1回）。その後、各記事の「投稿者名」を取得するために、DBへさらにN回アクセスする。 結果: DBへのアクセスが集中し、画面の読み込みが極端に遅くなります。
対応策: 開発者に対し、1回のAPIコール（DB操作）で必要なデータをまとめて取得するよう促す必要があります。
2. オーバーフェッチング：無駄な通信量の発生
現象の例: 画面ではユーザーの「名前」と「アイコン」しか使わないのに、APIがDBから取得した「住所」「電話番号」「ログイン履歴」など、すべての情報をフロントに渡してしまうこと。 結果: 通信量が無駄に増大し、特にモバイル環境での表示速度低下を招きます。対応策: フロントエンドが必要とする情報だけをピンポイントで取得できるようにAPIのスキーマ（設計図）を見直す必要があります。
システム構成の懸念点に「口出しできる」ディレクターへ
システム構成の全体像と、そこで発生しうる懸念点を知ることで、「単なる要件を伝える人」から「システムの健全性を守るパートナー」へと進化できます。これらの基礎知識を持つことで、「RDBMSだから構造変更が大変ですね」「N+1問題は発生していませんか？」といった、具体的な懸念に基づいた質問ができるようになります。
