ホンダ、SDVの大規模ソフトウェア開発で組織設計と開発工程の外側に目を向ける

　「SDV（Software Defined Vehicle）開発の仕事を組織に当てはめるのではなく、仕事に合わせて開発スタイルや組織のかたちを変えていかなければならない」--。本田技術研究所 SDV研究開発センター 副統括 兼 SDV開発改革室長の菅 有里子 氏は、こう強調する（写真1）。

写真1：本田技術研究所 SDV研究開発センター 副統括 兼 SDV開発改革室長の菅 有里子 氏

　SDVへの移行に伴い、OEM（完成車メーカー）は「クルマを作る」企業であると同時に「難易度の高い大規模ソフトウェアを作る」企業にならざるを得なくもなった。その菅氏はソフトウェア技術者、プロジェクトマネジャー、営業責任者、経営企画責任者、と幅広い立場を経験し、工場改革にも携わってきた。

　だが現場を数多く知り「いざ、OEMに飛び込むと印象は大きく違った」と菅氏は振り返る。「IT専門ではない企業で大規模ソフトウェアを始めて『こんなはずではなかった』と感じている方もいるのではないだろうか」（同）と、自身の立場から訴える。

手段やプロセスよりも「組織風土」が問われる

　当初「開発環境やツール、システムを整えれば前に進むと考えていた」と菅氏。だが実際にはそれだけでは足りず「長年クルマづくりを支えてきた強みそのものが、大規模ソフトウェア開発の前では見えにくい壁になる場面すらあった」（同）という。その経験を通じて「『技術力とは何か、開発力とは何か、組織力とは何か』という素朴な疑問に行き着いた」（同）

　菅氏が強調するのは「ソフトウェアの構造と組織の構造は切り離せない」という点だ。大規模ソフトウェアの開発では、どのチームが何を担い、どのように情報をやり取りするかが、そのままシステムの作りやすさや効果に跳ね返る。

　その根拠として菅氏が例に挙げたのが、米国の計算機科学者メルビン・コンウェイ（Melvin Conway）が提唱した「コンウェイの法則」だ（図1）。「システムを設計する組織は、自らのコミュニケーション構造と同じ構造の設計を生み出す」というものである。

図1：「逆コンウェイの法則」では、提供したいものに合わせた組織構造を採ることでコミュニケーションロスとシステムの変更コストを減らす

　この法則を逆手に取り、作りたいアーキテクチャーに合わせて組織を設計する考え方を「逆コンウェイの法則」とする。組織の境界がそのままソフトウェアの境界になる以上「組織設計は人事や管理の問題にとどまらず、SDVのアーキテクチャーを左右する技術そのものの問題にもなる」（菅氏）。

開発量は同じでもコミュニケーション量は15倍に

　とはいえ歴史の長い企業では、組織のあり方が既存の責任分担や人事評価制度と結び付いており、理屈どおりには変わらない。むしろSDV化によって「組織の壁はより鮮明になった」（菅氏）とも言える。

　かつてのクルマづくりは、ECU（Electronic Control Unit：電子制御ユニット）ごとに独立した組織の中で機能を作り込み、それを「組み合わせればつながる」というシンプルな構造だった。委託先として業界を熟知したサプライヤーを相手に「多少粗い依頼でも意図を汲んで仕上げてくれた」（菅氏）慣習もある。

　一方ソフトウェアの量が増えたことで、組織をまたがなければ実現できないクロスドメインの機能は一気に増えた。勝手を知ったサプライヤーに「お願い」で済んでいた仕事も、業種・業態の異なるITベンダーに発注するとなれば、仕様を詳細まで言語化しなければ伝わらない。菅氏の試算では、仮に作るものの量が同じだとしても「実現に必要なコミュニケーション量は単純計算で15倍に膨らんだ」という。

図2：1機種の開発に要するコミュニケーション量は増大している

　そして、SDVにおいて多くの開発者が経験する課題が「仕様変更の嵐」（菅氏）だ。ハードウェアは目に見えるものであり、終盤での変更が難しいという認識を誰もが共有している。ところがソフトウェアには「ちょっと変えて」が頻発する。すると「ハードウェアの帳尻合わせまでソフトウェアにしわ寄せが及び、ときにはプラットフォームの変更までも安易に議論に上がる」（同）という。

　このときに見落とされがちなのが、テストにかかる時間とコストだ。菅氏は、ソフトウェア技術者だったころ「設計どおりに作ったのに、なぜバグが出るのか。自分で作り込んだバグを直すのに、追加の費用を請求するのか、と投げ掛けられたこともある」と振り返る。