🧭 なぜ自動車ソフトの属人化が許されないのか
📝 はじめに
このページでは、なぜ自動車ソフトウェア開発において「属人化」が致命的な問題になるのかを整理する。 多くのソフトウェア開発現場では「できる人に任せる」ことが合理的に見える場面もある。しかし、自動車分野ではその発想自体が成立しない。 ここでは、業界特有の前提条件と、それがA-SPICEの思想にどう結びついているかを構造的に説明する。
🚗 背景：自動車ソフトが置かれている前提条件
自動車ソフトウェアは、一般的なITサービスや業務アプリとは前提が大きく異なる。
⏳ 長期ライフサイクル
- 開発から量産、保守まで10年以上
- 仕様決定者・設計者が途中でいなくなるのが前提
🧩 巨大で分業的な構造
- ECU単位・機能単位での分業
- 複数企業・複数国にまたがる開発
⚖️ 失敗の許容度が極端に低い
- 不具合＝事故・リコール・法的責任
- 「後で直す」が通用しない世界
自動車ソフトは「人が替わる」「時間が経つ」「責任が重い」ことを前提に設計されなければならない。
🔁 人が入れ替わることが前提の世界
属人化が成立するのは、次の条件が揃っている場合である。
- キーパーソンが長期間在籍する
- 判断理由を暗黙知のまま共有できる
- 失敗しても致命傷にならない
自動車開発では、これらが一つも成立しない。
- 異動・退職・組織再編は避けられない
- 暗黙知はサプライチェーンを越えられない
- 失敗は即、組織全体のリスクになる
「あの人が分かっている」という状態は、将来の事故を予約しているのと同義。
🧠 再現性と引き継ぎ可能性が要求される理由
ここで重要になるのが、再現性と引き継ぎ可能性である。
🔄 再現性
- 同じ前提なら、誰がやっても同じ判断に近づく
- 個人の勘や経験に依存しない
📦 引き継ぎ可能性
- 設計・判断の理由が説明できる
- 後任者が「なぜこうなっているか」を理解できる
これらは「丁寧さ」や「親切心」の話ではない。 組織として生き残るための最低条件である。
再現性と引き継ぎ可能性が確保されていれば、人が替わっても品質は崩れない。
🏗️ A-SPICEが「人」ではなく「組織」を見る理由
A-SPICEは、個々の技術者の能力を評価しない。 代わりに、次の点を見る。
- 判断がプロセスとして定義されているか
- 誰がやっても同じ流れに乗る構造か
- 判断結果とその根拠が追跡可能か
これは冷たい設計思想ではない。 むしろ、個人を守るための仕組みである。
属人化を排除することは、「スーパーマンを不要にする」ことでもある。
❗ 実務で起きがちな誤解
🧑💻 「優秀な人がいれば問題ない」
短期的には正しい。 しかしその人がいなくなった瞬間、組織は機能停止する。
📄 「ドキュメントを書けば属人化は解消する」
違う。 書いてあるだけで、判断理由が説明できない文書は役に立たない。
属人化の問題は量ではなく構造の問題。
📌 まとめ：このページで伝えたい一点
自動車ソフトウェア開発では、
属人化は効率化ではなく、遅延と事故の種である。
A-SPICEが人ではなく組織を見るのは、 「誰が作ったか」ではなく 「誰が作っても破綻しないか」を問うためである。
この理解を踏まえ、次のページでは V字モデルとA-SPICEがなぜ密接に結びついているのかを、構造の観点から整理する。