継続的な変更に耐えられるソフトウェア設計とは何か。本田技研工業株式会社（以下、Honda）で車載ソフトウェア／SDV開発をリードする坪内 一雄と、Webサービス開発を軸に設計・リファクタリングを実践してきたミノ駆動氏。異なる2つの現場から、長期にわたって変更し続けられるソフトウェア設計と、それを支える組織のあり方を探る。
【Honda技術者が識者と語り合う vol.4｜Honda×ミノ駆動氏コラボ】SDV時代の設計論──継続的な変更に耐えられるソフトウェアをどうつくるか
この記事に登場する人
INDEX
SDVで変わるクルマのソフトウェア開発
SDVの登場によって、クルマは「つくって終わり」ではなく、出荷後もアップデートで価値を高め続けるプロダクトへと変わりつつある。一方で、クルマには法規制や安全性の要件があり、Webサービスのように毎日更新できる世界とは事情が異なる。
まずは、SDV時代の車載ソフトウェア開発で何が変わっているのか、現場の視点から探っていく。
――SDV時代となり、クルマのソフトウェア開発はどう変わっていますか？
クルマに関係するソフトウェアはたくさんありますが、SDVの文脈でフォーカスして語られるのは、ADAS（先進運転支援システム）※1 や運転席周辺のコックピット、そしてクロスドメイン※2 と呼ばれる領域です。クロスドメインとは、複数の機能を統合的に制御すること。たとえば、車内カメラで乗員の動きを認識し、後部座席のほうを振り向いたら自動でシートを下げる。これは複数のシステムが連動して初めて実現できます。単なるソフトウェア化ではなく、こうしたシステム同士を連携させることでクルマの価値を高めていくのがSDVの考え方です。
※1 ADAS：「Advanced Driver Assistance Systems」（先進運転支援システム）の略。ドライバーの運転操作を支援する機能や技術の総称。 ※2 クロスドメイン：従来は別々に制御していた車両機能（パワートレイン、インフォテインメント、ADASなど）を中央コンピューターで統合制御する仕組み。
価値を上げるために、どれくらいの頻度でアップデートするんですか？
毎日アップデートできるかというと、難しい。クルマには法規制があり、安全性が確認されたものしかOTA※3 で配信できません。バグの修正なら1ヶ月～数ヶ月で対応できますが、ADASのような安全に関わる機能はもっと時間がかかります。唯一、Androidベースのコックピット部分は法規の対象外なのでアップデートしやすいですが、それでも社内の品質保証プロセスがあるので、週単位での更新は難しいですね。
※3 OTA：「Over The Air」の略。無線通信を介してソフトウェアやファームウェアなどのアップデートを含む、クルマとのデータの送受信を行う技術のこと。そもそもクルマの開発は、どのくらいの期間がかかるものなんですか？
通常は、企画から出荷まで4～5年です。ですから、私がいま手掛けているのは、2030年頃にリリースされるクルマです。
5年後に売れるものを今から企画するのは難しそうですね。
特にコックピットは、5年後のニーズが読みにくいので、クラウドと連携してすぐに新機能を入れられるようにしておく必要があります。だから自動車の開発は、領域によってスタイルが全く違うんです。
たとえば、エンジン制御は安全性最優先で、ウォーターフォール型が基本です。一方、車内の快適さや楽しさを提供する車載インフォテインメント領域はアジャイルが主流で、Webサービスの開発に近い。つまり、安全性やセキュリティが厳格に求められる部分と、変更を頻繁に加えたい部分、その両方が一つのシステムに同居しているんです。
だからこそ、どう設計するかが問われますね。業界は違えど、私たちに共通する問いだと思います。
設計を軽視したソフトウェア開発の末路
――次に、設計やリファクタリングの重要性を痛感した瞬間について教えてください。
もうずっと前、メーカーにいた頃の話です。50人規模のプロジェクトで、社員が仕様書を書き、派遣の方がそれを見ながらバーっとコードを書いて実装していました。いま振り返ると、「設計」と呼べるプロセスがなかったんです。当然コードは粗悪になっていく。20機能ほどまとめてリリースしようとすると、バグが200件ほど出るのが当たり前で、まるでモグラ叩き状態でした。
当時の私はまだチーム開発自体に慣れておらず、同僚に「これっておかしくないか？」と聞いてみたんです。そうしたら、「え、こんなもんでしょ」って。納得できなくて、ソフトウェア開発の本を片っ端から読みました。そんなとき、職場の本棚でマーティン・ファウラーの名著『リファクタリング―既存のコードを安全に改善する―』を見つけたんです。冒頭に「バグを低減する設計」とあって、「これだ！」と。書かれている手法を一人でこそこそ試してみたら、複雑だったコードがきれいに整頓できて、ものすごく感動しました。
それで現場は変わりましたか？
残念ながら変わりませんでした。そのうち致命的な障害が頻発するようになって、さすがにまずいということで、大規模なリファクタリングプロジェクトが立ち上がりました。ところが、それも頓挫してしまったんです。
なぜですか？
リファクタリングには内部のコードをよく知る人材が必要ですが、引き抜けば機能開発に回せるエンジニアが減る。「開発が遅れる」「競合に負ける」と猛反発を受けました。結局、品質より機能開発が優先された。十数年経った今でも忘れられない、苦い経験です。
組み込み開発の世界では、設計なしにものをつくることはあり得ません。ただ、私も以前の職場では状態設計をしない人が多かった。システムが今どういう状態にあって、何をきっかけに次の状態へ遷移するのか定義せず、シーケンス図だけ書いて実装してしまう。そうすると、レースコンディションが起きたり、ハードウェアが変わると動かなくなったりするんですよね。
「設計＝シーケンス図」という職場、私もありましたね。
また、以前ナビゲーションの開発をしていたとき、機能を積み上げていったら限界がきたことがあります。最初はシンプルだったのが、通信機能が加わり、CDやDVDとの連携が加わり、画面操作もボタンだけだったのがアニメーションを入れたいとなる。要望に応じてどんどん足していくうちに、新機能が入らない、入れるにも莫大なコストがかかるという状態に。結局、アーキテクチャごと作り直しました。
リファクタリングではなく、作り直しを選んだのはなぜですか？
そうせざるを得なかったというのが正直なところです。組み込みソフトは、昔は規模が小さくて、ずっと同じエンジニアが担当することも多かった。だから全体が見えていたんです。でも規模が大きくなると、一人ではできなくなり、一つの変更がどこに影響するか分からなくなります。部分的に直すより、構造から見直すほうが早いという判断でした。
改めて振り返ると、設計の目的が変わっていったんですよね。組み込み開発において設計は昔から大事でしたが、求められることが変わった。性能やメモリの最適化から、「複数人で開発しても壊れない構造」「長期的にメンテナンスできる構造」へ。設計とは何のためにするのか、考えさせられますね。
変更容易性を支えるのは「構造」である
――変更に強い設計を実現するために、開発のプロセスや構造で意識していることはありますか？
まず開発プロセスでいうと、「私たちはアジャイルでやっています」という会社は多いですよね。でも、アジャイルという概念は誤解が多く、妖怪のように独り歩きしているところがあると思っていて……
というと？
小さくつくって素早く改善するというプロセス偏重で、「では、あなたのシステムは速く開発できる構造になっていますか？」と聞くと、言葉に詰まる人が多い。変更容易性の高い構造があって初めてアジャイルは成立するんです。構造が粗悪なままアジャイルを取り入れても、絶対にスピードは出ません。
私たちがアーキテクチャを考えるときも、まず構造から入ります。安全にしなければいけない部分と、頻繁に変更したい部分を分ける。安全が最優先の領域に、変更の多い部分が影響を及ぼさないようにするためです。それから、部品同士のつなぎ方、インターフェースを最初にしっかり決める。つなぎ方のルールさえ守れば、それぞれの内部をどう変えても他に影響しない。最初に大枠を決めてから開発を進めるアプローチです。
構造を決めるときは、技術要件だけでなく、開発するエンジニアのことも考えなければいけませんよね。エンジニアのスキルにはかなり幅があります。絶対に壊れてはいけない、インパクトの大きい部分には経験豊富なエンジニアをアサインし、しっかり形をつくる。オプション的な部分はジュニアにも任せられるようにしておく。
私は「主目的」と「副目的」という言葉を使っています。システムで一番大事な機能が主目的。そこは明確にモジュール化した上で、リードエンジニアをアサインします。大事なのは、主目的と副目的を混ぜないこと。混ぜると、まだ経験の浅いエンジニアが意図せず重要な部分を触ってしまう可能性が出てくる。部屋をちゃんと分けることで、品質の維持・向上に努めています。
ドメインを超えた共通項──アーキテクチャとは何か
――クルマとWebサービス、業界は違っても、設計で大切にしていることには共通点がありますね。
そもそもアーキテクチャとは、ビジネスで実現したいことに対して、どんな品質を優先するかを形にしたもの。速度なのか、セキュリティなのか、変更のしやすさなのか。何を大切にするかを見定める。これは業界関係なく同じです。
ただ、品質にはトレードオフになるものもあって、特に変更容易性とパフォーマンスは相反しやすい。パフォーマンスを追求すると、どんどん人が読めないコードになっていく。すべてを完璧にした「最高のソフトウェア」なんて存在しません。だから、何を優先するかが戦略的な意思決定になっていくわけです。
そうですね。このソフトウェアを何年もたせるのか、どこまで変更を想定するのか、使う技術、チームのスキルや規模など、たくさんのことを考慮する必要があります。一律の正解はないと思います。もし、あればAIにお任せすることもできるでしょうけど、そうはなりません。
――優先順位を決める際に、大事になってくるのは何ですか？
そのソフトウェアの目的を明確にすることです。
目的がはっきりしていれば、設計の判断に一貫性が出る。「なぜ、こう設計したのか」と聞かれたとき、「こういう目的でこう設計した」と答えられるかどうかが、設計の質を左右すると思います。
目的が組織を動かす──脈々と受け継がれる、Hondaの「A00」文化
――お二人とも、目的を明確にすることを大事にされていますが、「目的」を組織に根付かせるために、どのような取り組みをしていますか？
Hondaには「A00」という言葉があります。プロジェクトの最初に定義する、絶対にぶれない指針です。
単なる性能目標ではなく、「お客様にどんな喜びを届けたいか」「社会にどう貢献するか」を言葉にする。壁にぶち当たったとき、意見が食い違ったとき、常に立ち返る原点です。そこから「では、何ができればいいか」をブレイクダウンしていく。それが「A0」と呼ばれ、さらに具体的な技術目標へと落ちていきます。
目的と手段が階層構造になっているわけですね。
そうです。「A00」は究極の目的、「A0」は活動目標、さらにその下には具体的な手段がある。大事なのは、目的と手段を区別すること。ここは本当にごちゃ混ぜになりがちなところだと思いますが、分けて考えないと議論がかみ合わなくなる。
Hondaでは「それってA00で言うと何？」という問いかけが頻繁に出てきます。
素晴らしい！ うちでも取り入れたいです。
目的と手段の話は、ソフトウェアに限りませんよね。「おいしいものが食べたい」という目的に対して、寿司にするか鰻にするかといった手段があるように、私たちのあらゆる行動は目的と手段で成り立っています。ただ、ものづくりではその一貫性が崩れやすい。目的を見失うと、期待した成果が得られなくなります。
プロセスやルールがまさにそうですね。導入当初は「なぜ必要か」が共有されているけど、時間が経つと目的が忘れられ、手段だけが残る。
目的は意識して言葉にしないと消えていく。だからこそ「何のためにやるのか」を問い続ける文化が大事なんですよね。
ミノ駆動さんは、目的の形骸化を防ぐために何かされていますか？
私は自社で設計講座を開き、「目的」に沿った設計とは何か実践形式で伝えています。
たとえば、ECサイトの「注文」機能。予約注文と抽選注文は、同じ「注文」でも目的が違います。やることも扱うデータも違う。これを「注文モデル」として一緒くたにまとめてしまうと、変更が難しくなる。ひどいものでは、抽選注文の仕様を変えたら予約注文が動かなくなる、といったケースです。だから、別々のモジュールとして設計する。こうした考え方を実際にコードを書いてもらいながら浸透させました。今では「目的」と言えば、チームのエンジニアが何を指しているかすぐに理解してくれます。共通言語ができたのは大きいですね。
「なぜ」を語れるエンジニアになれ
――最後に、読者の皆さまへのメッセージとして、お二人がエンジニアとして成長するために大切にしてきたことを教えてください。
やはり、考え続けることですね。私は20代の頃から質問には明確に答えられるよう意識してきました。先ほども、「なぜ、この設計にしたの？」と聞かれたら、「こういう目的だからです」と説明できなければならないと言いましたが、レビューでもその他の議論でも、よどみなく答えられるかどうかが全てだと思っています。
Hondaには「松明は自分で持て」という本田宗一郎の言葉があります。自分でリードして新しいことにチャレンジしようというメッセージです。そして、その挑戦を支える考え方として、「技術の前ではみな平等だ」という言葉もあります。肩書きや立場ではなく、目的の妥当性や技術的な正しさで判断し、良いアイデアなら誰が言ったかに関係なく採用される、という考え方です。目的を持った人が活躍できる環境かどうか、それが組織の力を左右すると思います。
エンジニアは技術が好きだから、どうしても手段のほうに引っ張られがち。でも、技術は何のためにあるのかと言ったら、顧客の課題を解決するため、目的を実現するためですよね。そこが抜けていると、いくら頑張っても成果につながらない。強いエンジニアは共通して、自分たちが解決すべき問題は何か、その目的を徹底的に突き詰めています。
AI時代になっても、そこは変わらないと思います。AIは優秀なツールですが、目的を定義するのは人間です。
AIに目的を伝えないと、AIも混乱しますからね。目的を言語化する力は、これからますます重要になります。
AIがコードを書いてくれる時代だからこそ、考える時間を増やせる。その時間を使って「なぜ」を深く追求できるエンジニアが活躍できるんじゃないでしょうか。
※掲載内容は、取材時である2025年12月時点のものです。
