필사 모드: システム設計面接の準備法 — 正解ではなく「絞り込む過程」が採点される45分

はじめに — ホワイトボードの前で45分が蒸発する理由

よくある光景があります。面接官が「URL短縮サービスを設計してください」と言った瞬間、候補者はペンを取ります。クライアント、ロードバランサー、Webサーバー、データベース。箱が5つと矢印が6つ、3分で完成します。そして25分ほど経ったころ、面接官が尋ねます。「1日に何件を処理する必要がありますか」。候補者はそこでようやく、自分が何も決めないまま絵だけを描いていたことに気づきます。

この失敗は知識の問題ではありません。同じ候補者がKafkaも知っていますし、シャーディングも知っています。崩れたのは進め方です。システム設計面接は正解が存在しないようにわざと開いておいた問題であり、だからこそ採点表も成果物ではなく過程のほうを向いています。

正直に言えば、この形式が実際の業務能力をどれだけよく予測するのかについては業界の中にも懐疑論があります。45分間ホワイトボードでやることは、実務の設計作業とかなり違いますから。ただ、その議論とは別に、いま目の前の選考を通過しなければならない人に必要なのは形式のルールを知ることです。この記事はそのルールについてのものです。

面接官が実際に採点しているもの

アレックス・シューの『System Design Interview』(2020)は、この面接を4つの段階に整理しています。問題を理解して範囲を決めること、概略設計を提案して合意を得ること、深く掘ること、まとめること。この構造が広まった理由は、実際の採点フォーマットもおおむね同じ軸を持っているからです。

多くの会社で面接官が埋めるフィードバック項目は4つか5つです。要件を自分で絞り込めたか、概略構造が要件とつながっているか、一点を深く掘れるか、選択ごとに代償を語ったか、考えを相手にわかるように話せたか。ここに「最適なアーキテクチャを提示したか」という項目は普通ありません。

面接官が探しているのは正解ではなく、制約が与えられたときに候補者が何を手放せるかです。無限の予算と無限の時間があるなら設計は要りません。設計とは何かを「やらない」と決める作業であり、やらないと決めた理由を説明することがこの面接の本体です。

年次が上がるほど比重は移動します。ジュニア採用では「何を知っているか」が大きく、シニア採用では「何を知らないかを知っているか」が大きくなります。自分が運用したことのない領域を運用したことがあるかのように話す候補者は、知識が多くてもシニア判定を得るのが難しくなります。

45分の使い方 — 時間予算を先に声に出して始めます

時間配分を前もって決めておかないと、45分は必ず前半から漏れていきます。次が無難な既定値です。

• 要件整理に5分。機能要件を2つか3つに絞って範囲を切り出し、非機能要件を数字で確定させます。
• 概略設計に10分。箱と矢印はここで初めて登場します。APIを1つか2つと、データモデルの骨格まで。
• 深掘りに15分。面接官が関心を示した一点に入っていきます。この区間が事実上、配点の半分です。
• ボトルネックと拡張に10分。トラフィックが10倍になったらどこが先に壊れるか、そのとき何を変えるか。
• まとめに5分。残っているリスク、次に測るべきこと、時間がもっとあれば見たいこと。

ここで実戦的なコツを一つ。この予算を自分の中だけで守らず、声に出して宣言してください。「5分ほど要件を整理し、10分ほどで概略構造を描いたうえで、ご関心のある部分を深く掘る順で進めたいと思います。よろしいでしょうか」。この一文が二つのことを同時にやります。進行の主導権を取り、相手と歩調を合わせられる人だという合図を送ります。

そして時計を見ます。自己診断の基準は一つだけ覚えておけば足ります。15分たっても最初の箱を描けていないなら要件に長く留まりすぎですし、5分で全体像が終わったなら何も決めていないということです。

覚えておく価値のある数字

設計でやり取りされる判断のほとんどは、桁の感覚の上に立っています。なぜキャッシュを置くのか、なぜリージョンを分けるのか、なぜ同期呼び出しを減らすのかが、すべて下の表の間隔から出てきます。

この表の原典は、ジェフ・ディーンがまとめてピーター・ノーヴィグが広めた「すべてのプログラマが知っておくべき遅延時間の数値」です。2012年版を基準に引用されることが多いのですが、絶対値の一部はすでに古くなっています。特にストレージ側はその間に一桁以上速くなりました。それでも層と層のあいだの間隔はいまも有効で、面接で必要なのも正確な値ではなくその間隔です。

最後の行だけはハードウェアが変わっても縮みません。光ファイバーの中で光は秒速20万キロメートルほどで進みます。ソウルと米国西海岸は片道9000キロメートルほどですから、物理的な下限だけで往復90ミリ秒です。実際の経路の迂回まで足すと、実測はおおむね130ミリ秒前後になります。この数字を知っていると、「CDNとエッジキャッシュを置きます」が流行語の羅列ではなく計算の結論になります。

可用性の数字も一つ覚えておくとよいです。99.9パーセントは年間およそ8.8時間の停止、99.99パーセントはおよそ53分です。面接官に「可用性の目標は」と聞かれたときにこの換算を即座にできれば、そのあとの会話は自然にマルチAZと切り替えのコストへ移っていきます。

概算の練習 — DAU一つからQPSとストレージまで

概算は才能ではなく反復です。出発点は二つの丸めです。1日は86,400秒ですが、これを10万秒に丸め、1年は3000万秒に丸めます。すると計算が暗算の範囲に入ります。1日100万リクエストは平均10 QPSあたり(正確には11.6)、1日1億リクエストは1000 QPSあたりです。

実際に回してみます。日次アクティブユーザー1000万人、一人が1日20回リクエストすると仮定すると1日2億件です。10万で割ると平均2000 QPS。トラフィックは均等には来ませんから、ピークを平均の2〜3倍と見て5000から6000 QPSを設計基準とします。ここで読み書き比率を100対1と仮定すると言った瞬間、キャッシュとリードレプリカの話が無理なく続いてきます。

ストレージも同じやり方です。テキスト投稿1件が1キロバイトで1日100万件なら、1日1ギガバイト、1年で365ギガバイトです。5年保管で3重複製なら5.5テラバイトほど。ここに画像が付くと桁が変わります。平均200キロバイトの画像が1日100万枚なら1日200ギガバイト、1年で73テラバイトです。この計算をやってみた人だけが、「画像はオブジェクトストレージに分離してメタデータだけをデータベースに置きます」という文を根拠付きで言えます。

概算で採点されるのは正確さではなく、前提を外に出したかどうかです。1000万という数字が間違っていても構いません。ただ「ユーザー1000万、一人あたり20回、ピークは3倍」と言っておけば、面接官がその場で数字を直してくれますし、そこからは二人で同じ問題を解くことになります。

よく崩れる4つの地点

• 要件を聞かずに図から描き始めること。最もよくあり、最も致命的です。1日1万件のシステムと1日10億件のシステムはまったく別物なのに、聞かずに始めるとどちらでもないものを描くことになります。最初の5分で最低限この4つは確定させてください。規模、読み書き比率、遅延目標、一貫性の要求水準。
• 流行の技術を並べること。Kafka、Redis、Elasticsearch、Kubernetesを一画面に載せて「このように構成します」で終わってしまう場合です。面接官に「このキューがなかったらどうなりますか」と聞かれて答えが出ないなら、その箱は加点ではなく減点になります。コンポーネントを一つ描くたびに、それが取り除く問題を一文添えてください。
• 代償を示さずに断定すること。「NoSQLを使います」「マイクロサービスでいきます」といった文がそれ自体で答えになることはありません。ここでCAP定理を正確に扱えると印象が大きく変わります。2000年にエリック・ブリューワーが予想として提示し、2002年にギルバートとリンチが証明したこの命題は「3つのうち2つ」と要約されがちですが、ブリューワー本人が2012年の記事でその要約は誤解を生むと訂正しています。正確な言明はネットワーク分断が実際に起きたときにだけ、一貫性と可用性のどちらかを選ばなければならないというもので、平時には両方をかなりの水準で持てます。
• 深掘り区間で浅いまま留まること。面接官が「その部分をもう少し見てみましょうか」と言う瞬間が配点の中心です。そこで別のコンポーネントに話題を移すと回避と読まれます。準備しておく価値のある常連テーマは決まっています。シャードキーの選択とホットスポット、キャッシュの無効化とスタンピード、冪等性とリトライ、重複しないID採番、そしてテールレイテンシ。

「わかりません」を上手に言う方法

知らないことが出てくるのは事故ではなく設計です。45分の開かれた問題で知らない区間が出てこないなら、問題が易しすぎたということです。ですから準備すべきは「知らない状況を避ける方法」ではなく「知らない状況を扱う文」です。

3つの部分に分けて話せば、ほぼいつでも安全です。境界を認め、知っている原理から推論し、確認する方法を提示することです。

「Kafkaの Exactly-once 配信は、自分で運用した経験がありません。原理から推論すると、プロデューサーの冪等性とトランザクションコミットが揃っている必要があるはずで、コンシューマー側の処理まで含めると結局アプリケーション水準の冪等性が必要になると思います。実際にはドキュメントとベンチマークを確認したうえで決めます」

この回答が得るのは知識の点数ではなく較正の点数です。知っていることと知らないことの境界を正確に引ける人は、運用中に危険な判断を下すことが少なくなります。面接官はそこを見ています。逆に最悪の対応は二つです。知ったかぶりをして二つ目の質問で崩れること、そして「わかりません」の一言で会話を切ってしまうこと。

プレッシャーが強い瞬間ほど、この文は出てきません。面接で崩れる地点は、知らないという事実そのものではなく、知らないことを隠そうとする数分間です。その数分のあいだ思考は止まり、言葉は速くなります。この反応を扱う訓練は、プレッシャーのかかる場面で崩れない方法で扱ったストレス免疫と同じ原理です。実戦に近い条件であらかじめ揺れてみること以外に近道はありません。

そしてこの面接の半分は、結局のところ会話です。一人でつぶやきながら絵を完成させる人よりも、相手の反応を見て速度を調整する人のほうがよい点数を得ます。会話がうまいということで扱った原則が、ホワイトボードの前でもそのまま働きます。

おわりに — 採点されるのは結論ではなく絞り込む過程です

システム設計面接がうまくいった日の記録を思い返すと、たいていは華やかなアーキテクチャが出てきた日ではありません。要件を5つから2つに切り落とし、数字を3回計算し、一点を最後まで掘った日です。図はむしろ単純です。

準備も同じ方向でかまいません。問題を10個ざっと眺めるより、3個を時間を計って声に出しながら45分ずつ解いてみるほうが効きます。そして毎回、最後の5分は自分にこの質問を投げてください。今日の自分は何を手放し、なぜそれを手放してよいと判断したのか。その答えが整理されるぶんだけ実力は上がります。