🧟 はじめに：そこは「Z-World」ですか？
あなたの開発現場は、こんな状態になっていませんか？
- 思考停止したエンジニアたち： 「なんでこのドキュメント書くの？」「ISOで決まってるから（思考停止）」「ISO詳しくないんだよ」と彷徨い歩く。
- 死してなお動くレガシーコード： 中身が誰にも分からないのに、秘伝のタレとして継ぎ足され、触ると噛みつかれる。
- 形骸化したプロセス： 中身のないチェックリストだけが、ゾンビのように追いかけてくる（カーゴ・カルト）。
- 感染する野良ツール： 誰かが作ったメンテナンス不能な「俺俺ツール」使うことになる。
ようこそ、自動車開発の最前線へ。
ここは、高度な技術と、泥臭い人間模様が交錯する「Z-World（Zombie World）」 です。
本アドベントカレンダーは、この過酷な荒野で、あなたが**エンジニアとして「死なず（心を病まず）」、「噛まれず（事故を起こさず）」、生き残るための「サバイバルガイド（生存戦略）」**です。
🛡️ 本カレンダーの目的
機能安全（ISO 26262）やA-SPICEは、本来あなたを縛る鎖ではなく、ゾンビから身を守るための強力な武器です。
現場は疲弊しています。一部の機能安全を知っているエンジニアに負担が集中しているのが現状です。一人でも多くの人が、正しく「強力な武器」を使えるようになって欲しいと思っています。これを読んで、仲間が増えることを切に願っています。
本連載では、教科書的な定義の解説と、
「なぜ、そのルールが必要なのか？」
「どうすれば、身を守れるのか？」
を、現場のドロドロとした私の実体験（失敗談）を交えて解説します。
学べること（生存スキル）
- 武器の扱い方: ISO 26262, A-SPICE, AUTOSAR, HARA/HAZOPの「本質」と「使いどころ」。
- 拠点の作り方: 「壊れない車」ではなく「壊れても安全なアーキテクチャ（EGASなど）」の設計思想。
- 感染対策: リコール、SUMS法規、PL法といった「経営レベルの致死的リスク」回避のためのマインドセット。
🎯 想定読者（サバイバー）
- 新兵（新人・学生）： これから自動車業界に飛び込むにあたり、丸腰で戦場に出たくない人。
- ベテラン兵： 「動けばいい」という現場の空気に辟易し、論理的な武器（説明責任）を求めている人。
- 噛まれた人： すでに炎上プロジェクトの中にいて、脱出ルートを探している人。
✍️ 執筆者について
現場経験がすこーしあるソフトウェアエンジニア
サプライヤとOEMの両方で、酸いも甘いも（主に酸っぱい方）を噛み分けてきたエンジニア。
「性善説」ではなく 「性弱説（人は弱く、ミスをする生き物である）」 を信条とする。
基礎教養を知っていない人が多いなと感じるようになってきたので、 「後続部隊への置き手紙」 として、現場のリアルな知見を全てここに記す。
教科書的な知識パートは、ISO26262実践ガイドブック（日経ビジネス出版）で得た知識をベースにGeminiと壁打ちしながら作成しています。体験談のパートは、全て筆者が・・・。ご想像におまかせします。
⚠️ 免責事項
- 本記事の内容は筆者の個人の見解であり、所属する組織や特定の団体の公式見解ではありません。
- 登場する事例は、特定のプロジェクトを指すものではなく、あくまで「よくある話」として抽象化されています（心当たりがあっても、それはゾンビの幻覚です）。
さあ、武器を学び、生き残る術を獲得しよう！25日間のサバイバルガイドの始まりだ。