🧭 なぜ自動車ソフトの属人化が許されないのか

~~NIP~~

📝 はじめに

このページでは、なぜ自動車ソフトウェア開発において「属人化」が致命的な問題になるのかを整理する。多くのソフトウェア開発現場では「できる人に任せる」ことが合理的に見える場面もある。しかし、自動車分野ではその発想自体が成立しない。ここでは、業界特有の前提条件と、それがA-SPICEの思想にどう結びついているかを構造的に説明する。

🚗 背景：自動車ソフトが置かれている前提条件

自動車ソフトウェアは、一般的なITサービスや業務アプリとは前提が大きく異なる。

⏳ 長期ライフサイクル

開発から量産、保守まで10年以上仕様決定者・設計者が途中でいなくなるのが前提

🧩 巨大で分業的な構造

ECU単位・機能単位での分業複数企業・複数国にまたがる開発

⚖️ 失敗の許容度が極端に低い

不具合＝事故・リコール・法的責任「後で直す」が通用しない世界

自動車ソフトは「人が替わる」「時間が経つ」「責任が重い」ことを前提に設計されなければならない。

🔁 人が入れ替わることが前提の世界

属人化が成立するのは、次の条件が揃っている場合である。

キーパーソンが長期間在籍する判断理由を暗黙知のまま共有できる失敗しても致命傷にならない

自動車開発では、これらが一つも成立しない。

異動・退職・組織再編は避けられない暗黙知はサプライチェーンを越えられない失敗は即、組織全体のリスクになる

「あの人が分かっている」という状態は、将来の事故を予約しているのと同義。

🧠 再現性と引き継ぎ可能性が要求される理由

ここで重要になるのが、再現性と引き継ぎ可能性である。

🔄 再現性

同じ前提なら、誰がやっても同じ判断に近づく個人の勘や経験に依存しない

📦 引き継ぎ可能性

設計・判断の理由が説明できる後任者が「なぜこうなっているか」を理解できる

これらは「丁寧さ」や「親切心」の話ではない。 組織として生き残るための最低条件である。

再現性と引き継ぎ可能性が確保されていれば、人が替わっても品質は崩れない。

🏗️ A-SPICEが「人」ではなく「組織」を見る理由

A-SPICEは、個々の技術者の能力を評価しない。代わりに、次の点を見る。

判断がプロセスとして定義されているか誰がやっても同じ流れに乗る構造か判断結果とその根拠が追跡可能か

これは冷たい設計思想ではない。むしろ、個人を守るための仕組みである。

属人化を排除することは、「スーパーマンを不要にする」ことでもある。

❗ 実務で起きがちな誤解

🧑‍💻 「優秀な人がいれば問題ない」

短期的には正しい。しかしその人がいなくなった瞬間、組織は機能停止する。

📄 「ドキュメントを書けば属人化は解消する」

違う。書いてあるだけで、判断理由が説明できない文書は役に立たない。

属人化の問題は量ではなく構造の問題。

📌 まとめ：このページで伝えたい一点

自動車ソフトウェア開発では、

属人化は効率化ではなく、遅延と事故の種である。

A-SPICEが人ではなく組織を見るのは、「誰が作ったか」ではなく「誰が作っても破綻しないか」を問うためである。

この理解を踏まえ、次のページでは V字モデルとA-SPICEがなぜ密接に結びついているのかを、構造の観点から整理する。