求人につながる対策バックログ
Nintendo Systems向け対策（現在の最優先）
Section titled “Nintendo Systems向け対策（現在の最優先）”求人・判断理由・確認事項を起点に、低レイヤーの性能観察と大量トラフィックの設計を接続する。Database / System Designを維持し、OS / Networkを第三の柱に加える。まず入口教材を読み、一回に一つのテーマを会話で深掘りする。詳細教材の一括消化や新しい固定日程は課さない。
はてな向け対策（比較候補）
Section titled “はてな向け対策（比較候補）”以下はIssue #14以前の準備方針。現在は比較候補用として保持する。
2026-09-11、本人の指定ではてなを第一志望とし、今後の企業別対策の起点をはてなへ変更する。応募方針はWebアプリケーションエンジニアのオープンポジション。リード職を前提にせず、サービス・役割は選考で相談する。今作っている個人開発を準備の中心に据え、設計・実装・テストの判断を説明できるようにする。
- 応募先と選考の確認：対象サービス・役割を絞り、希望年収800万円以上（提示が低い場合は内容を見て検討）、京都での対面勤務、残業・当番、副業条件を確認する。オープンポジションの選考形式・提出コードの条件を確認する。リード職で確認した選考内容はそのまま適用しない。
- 設計判断の説明：Database / System Designを主軸に、Webサービスのアクセス集中、DB・キャッシュ、課金の整合性などから一つずつ扱う。これらは準備用の候補で、実際のはてなの面接問題や内部構成を示さない。通常の復習では既存needs_revisitを優先する。
- 自分の実装・経験の説明：提出候補の個人開発や、公開可能な実務経験から、要件・設計・代案・テスト・改善点を整理する。既存の経験一覧を使い、本人の担当・成果を補わない。提出物は条件を確認してから選ぶ。
Coding課題の追加や週の時間配分は、選考要件と本人の希望を確認して決める。全テーマの並行学習は課さず、ゲーム制作に使う時間も確保する。今回の優先順位変更だけで学習評価・実績は更新しない。
次回の開始文：
はてなを第一志望として対策したいです。career/jobsとcareer/preparationの最新方針を読み、応募候補の職種と公式の選考要件を確認してください。そのうえで今日扱うテーマを一つに絞り、私の回答を待ちながら進めてください。未確認の経験や能力不足を推測しないでください。求人から学習を始める — 現在はNintendo Systems向けの準備を最優先にします。
方針に沿い、System Designを中心に準備する。以下は学習候補で、未出題の能力不足や習得実績ではない。実際の開始時はreviewのneeds_revisitを優先し、一問ずつ回答を待つ。
2026-09-11更新：現在はDatabase / System Design / Systems Performance・OS・Networkの三本柱。下表のCoding・経験整理は候補として保持し、自動で着手しない。具体的日程は未確定。学習後の口頭テストで、既存の再確認課題を問う。
はてなの採用思想・文化を知る資料
Section titled “はてなの採用思想・文化を知る資料”収集日：2026-09-11。はてな社の採用・開発文化を対象とし、単に「はてなブログに掲載された他社の記事」は含めない。肩書・組織・選考は記事当時の情報。古い資料を現在のオープンポジションの評価基準や手順として断定しない。
| 読む順 | 資料・発信者 | 時点・性質 | 読みどころ |
|---|---|---|---|
| 1 | はてなの選考設計、その深奥に迫る！ — id:motemen（当時CTO） | 2022-10-26、公式登壇資料 | 中途選考の設計意図を本人が説明。提出コード、プレゼン、技術対話を通した相互理解。スライド8・10・15・16を先に読む |
| 2 | 多様な構造の組織をマネジメントしていく — id:daiksy | 2025-05-19、公式ブログの本人インタビュー | 当時、技術グループ専任EMとしてカジュアル面談・採用改善を担当。技術組織とプロダクトチームの両方への所属、CTOとの役割分担がわかる |
| 3 | Webアプリケーションエンジニア職・中途採用 | 現在掲載、公開・更新日不明 | 技術への向上心、ユーザーへの影響を考える当事者意識、他職種との議論、OSSや発表への姿勢。オープン職は経験・希望に応じてサービスを選考中に決定 |
| 4 | はてなブログチーム エンジニア座談会 — onishi / hitode909 / cockscomb / shiba_yu36 | 古いチーム座談会、本文の公開日未確認 | テスト・レビューを継続開発の効率につなげる姿勢、自分たちも使うサービスや道具を改善する楽しさ。現在の残業・レビュー運用の証拠としては使わない |
| 5 | はてなの新卒エンジニアに贈った言葉 — id:motemen（当時チーフエンジニア） | 2015-06-25、公式ブログの本人発信 | 職種を越えて他者の仕事を改善すること、細かな情報も共有すること。文化の背景資料で、中途採用の現行基準ではない |
読み取れることと準備へのつなげ方
Section titled “読み取れることと準備へのつなげ方”2022年の選考資料では、応募チーム以外のエンジニアも参加し、互いの働き方を知る機会をつくる意図が説明されている。プレゼンは、非同期・テキスト中心の仕事で考えを筋道立てて伝えることにもつながる。技術対話では完成品の見栄えだけでなく、議論できる余地にも意味があると説明されている。これは当時の設計意図であり、完成度を軽視する・意図的に欠陥を残すという意味には取らない。
以下は資料からの準備上の推論で、会社が公開した採点基準ではない。
- 個人開発について、何が面白くて作ったのか、誰のどんな体験を良くしたいのかを自分の言葉で話す。
- 技術選定、迷った代案、失敗、テスト、次に改善したい点を、実際のコードや観測と結び付けて説明する。
- 指摘を受けたら前提を確認し、別案を一緒に考える。知らないことを知っているように話さない。
- 記事をまねて人物像を作るのではなく、自分がこのような会話・働き方を楽しめるかを確認する。
全記事の読了は課さない。まず選考資料と2025年のインタビューを読み、現在の求人と照らす。現行オープン職の提出形式・AI利用の扱い・面接構成は別途確認する。今回の記事収集を本人の学習実績や能力評価に変換しない。
求人要求から次の一題へ
Section titled “求人要求から次の一題へ”求人の再確認日: 2026-09-08。要求の出典と条件は求人比較に記載。題材は練習用で、各社の実際の面接問題・内部構成を示さない。
| 柱・求人の要求 | 次に扱う題材 | 既存の入口・記録先 |
|---|---|---|
| Coding / DSA — LINE Platformのアルゴリズム・データ構造・並行処理 | 配列・hash map・queue等を使う短い実装から、計算量と境界条件を口頭説明 | 専用topic・教材は未作成。初回は問題のみ提示し、実セッションで必要なら最小topicを追加。既存DB reviewへ混ぜない |
| System Design — PocochaのAPI・性能改善・再設計 | liveのイベント通知。最初に配信先・遅延・重複許容を確認 | 要件 → キュー・冪等性 |
| System Design — LINE Platformの大規模分散処理・信頼性 | chatの送信・再送・順序・未配信の扱い | 信頼性・スケール・可観測性 |
| System Design — Yahoo!タイムラインの非機能設計・技術選定 | feed / rankingの読み取り、更新遅延、人気投稿への集中 | キャッシュ・データ増加・replication |
| System Design — CyberAgentメディア＆IPの大規模サービス | video / liveのアクセス集中。配信とAPIの負荷を分けて考える | 要件・スケール・信頼性 |
| Backend — PocochaのRDB・運用、MIXIの性能改善 | API遅延からquery plan、lock、接続数、I/Oへ調査をつなぐ | 実行計画・transaction・MVCC / lock・pool |
| Backend — LINE Platformのnetwork・並行処理 | HTTPのtimeoutと再試行がDB更新に与える影響 | API / 冪等性・transaction。Linux / networkは必要な箇所を深掘り |
| Experience / Behavioral — Yahoo!タイムラインの合意形成・技術判断・CI/CD、Pocochaの運用 | BFF移行で自分が決めたこと、代案、切替・rollback、検証方法 | BFFの経験・deployment・migration |
一回の進め方
Section titled “一回の進め方”求人を一つ選び、必須経験と歓迎経験を分ける。本人の年数・担当範囲が不明ならunknownのまま確認する。演習で説明できても、実務経験の年数を満たした証拠にはならない。
まず既存topicの再確認を行い、次に上の題材を一つ選ぶ。流れは要件確認 → 小さな初案 → 理由・代案 → 条件変更 → 運用・障害対応。数値やシステム設定を足すときは「演習上の追加条件」と明示する。模範解答や巨大なConsumer教材を先に作らない。
CHATGPT.md、AGENTS.md、src/content/docs/career/index.mdとcareer/preparation.mdを読み、architecture-queues の practiceを始めてください。needs_revisitを優先した後、liveのイベント通知を練習題材にしてください。一問ずつ回答を待ち、追加設定は「演習上の追加条件」と明示してください。終了時は実際の回答とヒントをSession Syncにまとめてください。実セッションの結果は既存のSession Syncで、対象topicまたはexperience topicへ記録する。求人の整理・応募判断・このバックログの追加はImprovementとして扱い、学習evidenceにしない。