🐈

車載BSW開発で誰も教えてくれなかった設計工程のリアル

に公開
キャリア
ソフトウェア開発
組み込み開発
idea

①はじめに

この記事は車載ソフトウェア開発、特にBSW（Basic Software）開発に関わり始めた方、またはこれから関わる方に向けて書いています。

自分の経歴を整理しながら、車載ソフトウェア開発業界を進路に入れている人の参考になるかもと思い始めました。

私はRH850シリーズを使った車載ECUソフトウェア開発に8年携わり、要求分析から詳細設計・検査まで一通り経験しました。

② V字工程は「守るもの」ではなく「守らせるもの」

V字工程はご存知の通り、要求分析→基本設計→詳細設計→実装→検査という流れで進む開発モデルです。

しかし現場で痛感したのは、自分の工程を守ることより、一段上の工程が正しく完了しているかを疑うことの方が重要だということです。

例えば詳細設計を担当しているなら、基本設計が本当に完了しているかを確認する。基本設計を担当しているなら、要求分析が顧客と正しく整合されているかを疑う。

この視点がないと、上流の未完了や曖昧さを引き継いだまま作業が進み、後半で顧客要求に圧されて必ず炎上します。

V字工程は自分が守るルールではなく、プロジェクト全体に守らせる構造として機能して初めて意味を持ちます。

③ BSW開発はPF要件定義から始めないと詰む

BSW開発において陥りやすい罠があります。それは製品の機能要求から議論を始めてしまうことです。

PF（プラットフォーム）開発で最初に整合すべきは機能ではありません。横展開先を含めた性能のスコープです。具体的には以下の2点を顧客と合意することが大前提です。

  • 性能上限：フルスペックモデルでPFが対応すべき最大要件
  • 性能下限：デチューンモデルでPFが対応すべき最小要件

このスコープが固まって初めて、機能をPFに載せる議論が成立します。

機能は後から載せられます。しかしPFの性能スコープは後から直せません。

④ SWC/Driverのスコープ交渉が品質を決める

③で述べた性能上限・下限のスコープは、具体的にはSWC（制御部分）とDriver（ハード部分）の適合範囲として定義されます。そのためこの交渉は技術的な議論であると同時に、ビジネス的な交渉でもあります。

スコープが曖昧なまま進むと2つの失敗パターンに陥ります。

  • 狭すぎる場合：互換性・汎用性のない専用品になり、他プロジェクトへの展開ができない
  • 広すぎる場合：自由度が高すぎて展開先プロジェクトでの設計コストが上がり、PFとして使いづらくなる

これを防ぐには顧客に対して強く、硬い提案が必要です。

  • 強さ：顧客を納得させる熱意を伝えること
  • 硬さ：根拠・提案・顧客事情の理解に筋が通っていること

この両輪が揃って初めて、顧客は「そのスコープで進めよう」と判断できます。熱意だけでは信頼されず、論理だけでは動いてもらえません。

⑤ 番外編：炎上プロジェクトの見分け方

新人・新規配属にもかかわらず具体的な作業が多すぎると感じたら、それは炎上のサインかもしれません。

ただし「多すぎる」は主観的な判断です。重要なのはその感覚をスケジュール管理者や技術監督者に報告したとき、彼らがすでに把握して理解していることです。

把握されている場合は炎上中です。そして把握されていない場合はさらに深刻です。報告漏れか、報告しても理解できない上長が存在するかのどちらかであり、**その時点で組織として焦げ付いています。**チームの状態は必ず悪化する方向へ転がります。

他にも現場で客観的に観測できるサインがあります。

  • 顧客折衝役のスケジュールが溢れている
  • 技術監督者・技術フォロー担当者のスケジュールが溢れている

ここでいう「溢れている」とは残業を常態的に必要としている状態です。

早めにこのサインを読み取り、自分の身を守る判断材料にしてください。

⑥ まとめ

この記事で伝えたかったことを整理します。

  • V字工程は自分が守るものではなく、プロジェクト全体に守らせる構造として機能して初めて意味を持つ
  • BSW開発はPFの性能上限・下限のスコープを顧客と整合することが大前提
  • SWC/Driverのスコープ交渉は熱意と論理の両輪で臨むこと
  • 炎上プロジェクトのサインは現場で客観的に観測できる

これらはすべて教科書には載っていない、現場8年で得たリアルです。

次回は「配属直後にやるべきこと」について書きます。

この記事が誰かの現場での判断材料になれば幸いです。

※この記事は自身の経歴をAIを活用して整理しながら記載しています。

このシリーズの記事

Discussion