Phase 2 | Week 8: 技術選定ディベート入門（FE） | プロジェクト・ミーミル

「何を使えるか」ではなく「なぜそれを選ぶか」で技術者を見抜くための、技術選定ディベートの社内勉強会の資料です。

候補者の選択にあえて反対の技術をぶつけ、「なぜ？」を技術的な理由とチーム・組織の理由の2段階で引き出す型を扱います。題材はフロントエンドの必須概念（仮想DOMの差分検出、再描画と最適化、状態管理のローカル／グローバルの使い分け）。Redux と Zustand、MUI と Tailwind、Next.js と素の React といった比較カードを使い、ペアでのロールプレイに落とし込みます。

ねらいは、ツールを使えるだけの人と、原理を理解してコスト・保守・チーム体制まで語れる人を見分ける力をつけること。特定のフレームワーク経験がなくても、「なぜ」と「壊れ方」を掘れれば評価できる、という立場で組み立てています。

▼ プロジェクト・ミーミルとは
TLE（テックリードエンジニア）および技術面接官の育成を目的としたプログラムです。コンピュータ・ネットワーク・Web の基礎を体系的に学び直し、暗記ではなく「なぜそうなっているか」を自分の言葉で説明できる状態を目指します。週1回の勉強会で基礎から専門領域までを順番に扱い、技術面接で候補者の力を原理から正しく評価できる面接官を育てます。

Transcript

1. Week 8: 技術選定ディベート入門（FE） プロジェクト・ミーミル Phase 2 第1回 / 全15回 プロジェクト・ミーミル | Week 8 1
2. 今日のゴール 1. 「A が正解」ではなく A vs B の比べる観点 を持つ 2. 候補者の選択に あえて反対の技術を出し、 「なぜ？」を2段階で引き出す 3. その引き出しを ロールプレイで実際にやってみる → "ツールを使えるだけの人" と "原理を理解したシニア" を見分ける力 プロジェクト・ミーミル | Week 8 2
3. 今日のアジェンダ 時間 パート 分 0:00 キックオフ（ 「何を使うか」でなく「なぜ」で評価する） 4分 0:04 非FE勢向けインプット（3大必須概念）＋型 18分 0:22 ディベート＆ロールプレイ（カード5枚） 18分 0:40 振り返り・次回予告 5分 非FEでも評価できる — 鍵はツール名でなく「なぜ」と「壊れ方」を掘れるか プロジェクト・ミーミル | Week 8 3
4. Phase 1 → Phase 2 の転換 Phase 1: 共通の基礎を 理解して説明できる 状態（全員クリア） Phase 2: その基礎を 「面接で候補者を見抜く武器」 に変える 専門が浅い面接官 比べる観点を持つ面接官 やりとり 「React 使えますか？」 「はい」 で終了 「描画が落ちた時、どう特定してメモ 化する？」 見えるも の 表面的な経験 原理の理解・判断の深さ プロジェクト・ミーミル | Week 8 4
5. 「比較して『なぜ？』を2段掘る」型 1. 選択を聞く： 「状態管理は何を使う？」→「Zustand」 2. 反対案を出す： 「Redux じゃダメ？ 何が違う？」 ← 比べる観点 3. なぜ①： 「なぜそっち？」→ 技術的な理由 4. なぜ②： 「チーム規模・保守・コストでどう効く？」→ 組織・チームの理由 → 正解当てが目的ではない。選んだ理由の良し悪しの兼ね合いを、どこまで分かって いるかを測る プロジェクト・ミーミル | Week 8 5
6. 非FE勢向けインプット FE面接の3大必須概念 プロジェクト・ミーミル | Week 8 6
7. ① 仮想DOM の原理と目的 実DOM（HTML構造）の直接書き換えはコストが高く重い 仮想DOM＝メモリ上の軽量なコピー 内容 ◎ 良 い データ変更時に旧状態と新状態の差分を計算し、変わった部分だけ実DOM に反映してパフォーマンス向上 △ 不十 分 「裏で勝手にやってくれる」 プロジェクト・ミーミル | Week 8 7
8. ② 再描画と最適化 状態(State)・親からの Props が変わると再描画される 不要な再描画の多発は UX 低下（スクロールのカクつき等） ◎ 良い：原因を特定した上で抑制策を複数出せる React.memo （コンポーネント）／ useMemo ・ useCallback （値・関数） コンポーネント分割・リストの仮想化（見える分だけ描画） → 本質は 「状態が書き換わったと見なされないように防ぐ」 プロジェクト・ミーミル | Week 8 8
9. ③ 状態管理の戦略 状態＝画面をリフレッシュせず保持する動的データ（認証情報・入力途中のフォ ーム等） 内容 ◎ 良い 認証・テーマはグローバル、画面内で完結する CRUD はローカル、と使い 分けの理由を語れる △ 不十 分 「全部グローバルに置けばいい」 （メモリ圧迫・保守性低下） プロジェクト・ミーミル | Week 8 9
10. 型の実演 key の「壊れ方」で掘る プロジェクト・ミーミル | Week 8 10
11. 実演：候補者役で答えてみてください インプットした3概念を、面接ではこう掘ります。例として「key」を実演します。 「リストになぜ key が必要？ index を key にするなと言われるのはなぜ？」 引き出したい：index だと、先頭の1件を消したのに別の要素が消えた扱いになる ＝差分検出が誤る 助け舟： 「先頭の1個目が消えたら、index だとどう判断されちゃう？」と、うまく いかない場合で掘る → ここまでが面接官の「型」 。次は皆さんが面接官役で プロジェクト・ミーミル | Week 8 11
12. ディベート実践 比較カードで掘り合う プロジェクト・ミーミル | Week 8 12
13. やり方 ペアになり、面接官役 / 候補者役 を決める 下の比較カードから1枚選び、面接官役が 型に沿って 掘る（1枚 5〜6分） 1枚ごとに 役を交代。全員が両方を経験する → ねらいは「反対案を出して、 『なぜ？』を2段階で引き出せたか」 プロジェクト・ミーミル | Week 8 13
14. 比較カード（FE・5枚） カード 比較 引き出したいポイント 1 状態管理 Redux vs Zustand コード量／大規模での保守／シンプルさ 2 スタイリン グ MUI vs Tailwind コスト／デザイナー連携 3 フレームワー ク Next.js vs 素の React SEO・SSR（サーバー側描画）が要る案件か ／安全性 4 UIの作り方 jQuery vs React 命令的か宣言的か／部品の再利用 5 最適化の考 え方 先にメモ化 vs 計測 後 開発速度 vs 遅い箇所の特定 プロジェクト・ミーミル | Week 8 14
15. カードの掘り方 1 Redux vs Zustand：コード量が多い／大規模で保守が複雑。Zustand はシンプル 2 MUI vs Tailwind：有料コンポーネントのコスト・Figma 連携（デザイナー分業） 3 Next.js vs 素のReact：SEO・SSR が要る案件か・一方で安全性の落とし穴も考慮 4 jQuery vs React：実DOMを直接操作 vs 宣言的UI＋仮想DOM／部品の再利用 5 先にメモ化 vs 計測後：メモ化にもコスト。遅い箇所を計測で特定してから最適化 → 見抜き：技術的好みだけでなく コスト・チーム体制・リスク まで言えるか プロジェクト・ミーミル | Week 8 15
16. 評価の見極め 見るもの ◎ 良い △ 物足りない 仮想 DOM 差分検出でパフォーマンス向上、と仕組 みまで 「裏でやってくれる」とフワ ッと 再描画 状態変化が起点、抑制策を複数 「なんとなく重い」で止まる 状態管理 ローカル/グローバルを理由つきで使い分 け 「全部グローバルでいい」 選定 コスト・保守・チーム体制まで 「流行ってるから」 目安：再描画・状態管理・宣言的UIは 説明できて当たり前 のライン プロジェクト・ミーミル | Week 8 16
17. 振り返り・次回予告 振り返り 一番うまく引き出せた「なぜ」は？ 逆に掘りきれなかった所は？ 次回：BE ケーススタディ 単一DB依存 → クリーン / マイクロサービスで作り直すアーキ図を描く Week 6 設計論の延長。全員の伸びしろ領域 なので予習を プロジェクト・ミーミル | Week 8 17