SDV推進の組織体制と移行シナリオ（内製と外注）

SDVを推進するうえで見落とされやすいのが、組織の問題である。ハードウェア中心の擦り合わせ開発と、ソフトウェアを継続的に更新し続ける開発では、必要な人材・開発サイクル・意思決定の速度が異なる。既存のハード組織にソフト部隊を足すだけでは、たいてい噛み合わない。本記事は、SDVで組織の何が変わるのか、内製と外注の線引き、段階的な移行の考え方を論点として整理する。結論を先に言えば、組織は技術構造の変化に合わせて変える必要があり、それは人材の追加ではなく仕組みの転換である。

なぜ組織を変えないと回らないのか

ソフトウェア・デファインドな車は、出荷後もソフトウェアを更新し続けることで価値を保つ。つまり開発が「量産で終わる」のではなく「使われ続ける間ずっと続く」。この継続性が、組織に変化を迫る。何がどう変わるのかを対比すると、次のようになる。

重要なのは、これらが「ソフトだから」ではなく「ソフトで価値を更新し続けるから」生じる点である。SOAのように機能を組み替えやすくする設計や、OTAアップデートによる継続的な更新は、開発が終わらない構造を生む。組織はその構造に合わせて、継続運用を前提とした形へ変える必要がある。

内製と外注の線引きをどう考えるか

すべてを内製する必要はないが、すべてを外注すると知見が社内に残らない。一般的な考え方として、自社の差別化や継続的な価値更新の核となるソフトウェア能力・データは内製で蓄積し、周辺領域は外部の力を借りる、という線引きが取りやすい。ただし、どこを核と見るかは事業戦略によって変わり、唯一の正解があるわけではない。本記事は特定の組織モデルを「正解」として断定しない。重要なのは、外注する場合でも「知見が自社に残る関わり方」を設計することである。

段階的な移行の観点

組織の転換は、一気に行うより段階的に進めるほうが現実的なことが多い。既存のハード開発の強みを保ちながら、ソフトの継続開発を担う機能を育て、両者を接続していく。その過程では、意思決定の速度や評価の仕組みも、ソフトの反復開発に合うように見直す必要がある。組織図を描き替えるだけでなく、どう動くかの仕組みを変えることが移行の本質である。

よくあるつまずき

組織・移行で繰り返し起きやすい落とし穴を、一般的なパターンとして挙げる。

• 既存組織のままソフト部隊を足すだけ：意思決定や評価の仕組みが旧来のままで、ソフトの反復開発が速度を出せない。
• 丸投げ外注で知見が残らない：核となる能力まで外注し、社内に判断力や改善力が蓄積しない。
• 意思決定速度が旧来のまま：設計凍結を前提とした承認プロセスが、継続更新の足かせになる。

まとめ：組織・移行で自社が決めるべきこと

SDVの組織転換は、人材の追加ではなく、継続運用を前提とした仕組みへの転換である。具体化する際、まず決めたい論点は次のあたりになる。

• 自社にとっての「核となるソフト能力」をどこに定め、内製と外注をどう線引きするか。
• 意思決定や評価の仕組みを、ソフトの反復開発に合わせてどう見直すか。
• 既存のハード開発の強みを保ちながら、どの順序で段階的に移行するか。

全体像は 【SDV入門】経営層が掴むSDVの全体像 を、体制の構築・維持にかかる継続コストの捉え方は SDV関連予算の立て方・ROIの測り方 をあわせて参照してほしい。ここまでは組織設計の「考え方の枠組み」だが、自社の事業・既存組織に即した体制設計や移行シナリオは個別性が高い。自社固有の前提に落とし込む段階では、外部の視点を入れると論点整理が速い。