Day 1: システム設計インタビューの基礎

今日学ぶこと

システム設計インタビューとは何か
インタビューの進め方（5つのステップ）
機能要件と非機能要件の整理方法
Back-of-the-envelope estimation（概算見積もり）
よくある失敗とその対策

システム設計インタビューとは

システム設計インタビューは、大規模なシステムを設計する能力を評価する面接形式です。正解は一つではなく、思考プロセスとトレードオフの理解が重視されます。

flowchart LR
    subgraph Interview["システム設計インタビューで評価されるスキル"]
        A["技術的知識"]
        B["コミュニケーション"]
        C["トレードオフ分析"]
        D["問題分解能力"]
    end
    style Interview fill:#3b82f6,color:#fff
    style A fill:#8b5cf6,color:#fff
    style B fill:#22c55e,color:#fff
    style C fill:#f59e0b,color:#fff
    style D fill:#ef4444,color:#fff

面接官が見ているのは以下のポイントです：

評価ポイント	説明
要件の明確化	曖昧な問題を具体的な要件に落とし込めるか
設計スキル	適切なコンポーネントを選択・組み合わせできるか
スケーラビリティ	大規模なトラフィックに対応できる設計か
トレードオフ	技術的な選択のメリット・デメリットを説明できるか
コミュニケーション	自分の考えを明確に伝えられるか

インタビューの5ステップ

システム設計インタビューは通常45〜60分で行われます。以下の5ステップで進めましょう。

flowchart TB
    subgraph Flow["インタビューの流れ（45-60分）"]
        S1["Step 1: 要件の明確化\n（5-10分）"]
        S2["Step 2: 概算見積もり\n（5分）"]
        S3["Step 3: ハイレベル設計\n（10-15分）"]
        S4["Step 4: 詳細設計\n（15-20分）"]
        S5["Step 5: まとめと議論\n（5-10分）"]
    end
    S1 --> S2 --> S3 --> S4 --> S5
    style Flow fill:#3b82f6,color:#fff
    style S1 fill:#8b5cf6,color:#fff
    style S2 fill:#22c55e,color:#fff
    style S3 fill:#f59e0b,color:#fff
    style S4 fill:#ef4444,color:#fff
    style S5 fill:#8b5cf6,color:#fff

Step 1: 要件の明確化（5〜10分）

最も重要なステップです。面接官に質問して、システムの範囲を定義します。

聞くべき質問の例：

このシステムの主なユーザーは誰ですか？
どのような機能が必要ですか？
ユーザー数はどれくらいですか？
読み取りと書き込みの比率は？
可用性とレイテンシの要件は？

Step 2: 概算見積もり（5分）

Back-of-the-envelope estimationで、システムの規模感を把握します（後述）。

Step 3: ハイレベル設計（10〜15分）

主要なコンポーネントとその接続をホワイトボードに描きます。

Step 4: 詳細設計（15〜20分）

面接官が深掘りしたいコンポーネントについて、具体的な設計を議論します。

Step 5: まとめと議論（5〜10分）

設計を振り返り、ボトルネックや改善点を議論します。

機能要件と非機能要件

要件は大きく2種類に分けられます。

flowchart TB
    subgraph FR["機能要件（Functional Requirements）"]
        F1["ユーザー登録・ログイン"]
        F2["投稿の作成・閲覧"]
        F3["検索機能"]
        F4["通知機能"]
    end
    subgraph NFR["非機能要件（Non-Functional Requirements）"]
        N1["高可用性（99.99%）"]
        N2["低レイテンシ（< 200ms）"]
        N3["スケーラビリティ"]
        N4["データの一貫性"]
    end
    style FR fill:#3b82f6,color:#fff
    style NFR fill:#8b5cf6,color:#fff

種類	定義	例
機能要件	システムが何をするか	ユーザーが写真を投稿できる
非機能要件	システムがどう動くか	レスポンスタイムが200ms以内

非機能要件の主要な指標

指標	説明	典型的な目標
可用性（Availability）	システムが稼働している時間の割合	99.9%〜99.99%
レイテンシ（Latency）	リクエストの応答時間	P99 < 200ms
スループット（Throughput）	単位時間あたりの処理量	10,000 QPS
耐久性（Durability）	データが失われない確率	99.999999999%（11ナイン）

Back-of-the-Envelope Estimation（概算見積もり）

概算見積もりは、システムの規模感を素早く把握するための技術です。

よく使う数値

項目	値
1日の秒数	86,400 ≈ 100,000（10^5）
1ヶ月の秒数	2,500,000 ≈ 2.5 × 10^6
1年の秒数	31,536,000 ≈ 3 × 10^7

データサイズの目安

単位	サイズ
1文字（UTF-8）	1〜4 bytes
テキスト投稿（Tweet等）	≈ 300 bytes
画像（圧縮済み）	≈ 300 KB
動画（1分）	≈ 50 MB

QPS（Queries Per Second）の計算

QPS = DAU × アクション数 / 86,400

例: SNSプラットフォーム
- DAU: 10,000,000（1千万）
- 1ユーザーあたり1日10回閲覧
- 読み取りQPS = 10,000,000 × 10 / 100,000 = 1,000 QPS
- ピーク時QPS ≈ 通常QPS × 2〜3 = 2,000〜3,000 QPS

ストレージの見積もり

年間ストレージ = DAU × 1日あたりのデータ量 × 365

例: 画像共有サービス
- DAU: 5,000,000
- 1日1枚アップロード（ユーザーの10%が投稿）
- 1枚 = 300 KB
- 日次: 5,000,000 × 0.1 × 300 KB = 150 GB/日
- 年次: 150 GB × 365 ≈ 55 TB/年

flowchart LR
    subgraph Estimation["概算見積もりの流れ"]
        E1["DAU\n日間アクティブユーザー"]
        E2["QPS\nクエリ/秒"]
        E3["ストレージ\n必要容量"]
        E4["帯域幅\nネットワーク"]
    end
    E1 --> E2 --> E3 --> E4
    style Estimation fill:#3b82f6,color:#fff
    style E1 fill:#22c55e,color:#fff
    style E2 fill:#8b5cf6,color:#fff
    style E3 fill:#f59e0b,color:#fff
    style E4 fill:#ef4444,color:#fff

よくある失敗と対策

flowchart TB
    subgraph Mistakes["よくある失敗"]
        M1["❌ いきなり設計を始める"]
        M2["❌ 一方的に話し続ける"]
        M3["❌ 完璧を求めすぎる"]
        M4["❌ トレードオフを説明しない"]
    end
    subgraph Tips["対策"]
        T1["✅ まず要件を確認する"]
        T2["✅ 対話形式で進める"]
        T3["✅ 重要な部分に集中する"]
        T4["✅ 選択の理由を述べる"]
    end
    M1 --> T1
    M2 --> T2
    M3 --> T3
    M4 --> T4
    style Mistakes fill:#ef4444,color:#fff
    style Tips fill:#22c55e,color:#fff

失敗パターン	なぜ問題か	対策
要件を確認しない	間違った問題を解いてしまう	最初の5分は質問に費やす
一方的に話す	コミュニケーション力が評価されない	面接官にフィードバックを求める
細部にこだわりすぎ	全体像が見えなくなる	まず全体を描いてから深掘り
技術の羅列	理解が浅いと思われる	なぜその技術を選んだか説明する
数字を使わない	規模感が伝わらない	常に概算見積もりを添える

まとめ

今日のポイント

トピック	キーポイント
インタビューの目的	正解よりも思考プロセスが重要
5ステップ	要件→概算→ハイレベル→詳細→まとめ
要件整理	機能要件と非機能要件を明確に分ける
概算見積もり	DAU→QPS→ストレージ→帯域幅の順で計算
心構え	対話形式で、トレードオフを意識する

重要な公式

QPS = DAU × アクション数/ユーザー / 86,400
ピークQPS ≈ 通常QPS × 2〜3
年間ストレージ = 日次データ量 × 365

練習問題

基礎レベル

問題: システム設計インタビューの5つのステップを順番に説明し、それぞれに適切な時間配分を書いてください。

中級レベル

問題: 以下のSNSプラットフォームのQPSとストレージを概算してください。

MAU（月間アクティブユーザー）: 5億人
DAU/MAU比率: 50%
1ユーザーあたり1日平均5回投稿を閲覧、0.5回投稿
1投稿のサイズ: テキスト300バイト + 画像200KB（投稿の30%に画像）
3年分のストレージを見積もること

チャレンジレベル

問題: 「URLショートナー（URL短縮サービス）を設計してください」というインタビュー問題が出されました。Step 1（要件の明確化）として、面接官に聞くべき質問を10個リストアップし、想定される回答と共に、機能要件と非機能要件に整理してください。

参考リンク

次回予告

Day 2: スケーラビリティとパフォーマンス では、システムを大規模に拡張するための基本概念を学びます。垂直スケーリングと水平スケーリングの違い、ロードバランシング、CAP定理など、システム設計の根幹となる知識を身につけましょう。