ハードウェア中⼼だった本田技研工業（以下、Honda）が、いまソフトウェア開発組織の活性化に本気で取り組み始めている。本対談では、現場課題に向き合うHonda ⽶森 力、横⽥ 裕二と、技術組織づくりの第⼀⼈者・広⽊ ⼤地氏が、「開発者体験（DevEX）※」を軸に、今まさに直⾯している課題とそれをどう乗り越えるかを具体的に掘り下げる。
※開発者体験（DevEX）とは 開発者の生産性と満足度を向上させることを目的とした概念や取り組みのこと。
【Honda技術者が識者と語り合う vol.2｜Honda×レクター広木大地氏コラボ】 Hondaのソフトウェアエンジニアは、なぜ自らテストコースを走るのか ——HondaにおけるDevEX（開発者体験）の現在とこれから
この記事に登場する人
INDEX
なぜ、いま“開発者体験”を⾒直すのか？
——最近、「開発者体験（以下、DevEX）」という概念が注⽬されています。なぜ、いまそれが注目されているのか、まずDevEXを研究テーマの一つにされている広木さんに伺わせてください。
私自身の定義だと、DevEXは開発者が高速に仮説検証をしたりするための環境や文化、あるいは仕組みが整っている状態を指しています。単に、エンジニアが楽になるとか楽しく仕事ができるということではなく、試行錯誤のプロセスをどんどん高速化していくことで実際に価値を創出することができる、それが開発者のモチベーションにも繫がっている状態です。
DevEXが進んでいない会社では、例えばソフトウェア開発でバグが発生したときに、エンジニアが始末書を書かされたりする。これではみんな怖がって、新しいチャレンジなんてできない。逆にDevEXが進んでいる会社では、たとえバグを出してもそれを適切なリスクの範囲でハンドルするための仕組みがあります。
エンジニアは試行錯誤を繰り返しながら毎日のように新しい価値を提供し、それをお客様の元に届けるデリバリーのスピードも速い。そういう仮説検証のサイクルが高速に回転することで、本当にいいものを届けることができます。
それがあれば、エンジニアも自分の価値で事業や社会に貢献できていると実感が得られるので、彼らの仕事は誰かに言われてやらされているものではなくなります。特に、最近の若手社員は、自らの仕事を通して社会に貢献することにこだわるので、DevEX、つまり開発者体験が豊かにできるとなると、それは社内エンジニアのキャリア形成にも、エンジニアの採用にとってもプラスに働きます。
DevEXは主にソフトウェア領域で使われる言葉ですが、実は、企業活動をデジタル化させ、競争優位性を確保していくことを示す「DX（デジタル･トランスフォーメーション）」とも深い関係があります。
DXによって事業モデルを変革していくためには、それこそ新しいテクノロジーや試みを素早く導入し、その価値を検証し、それを安全にビジネスに反映していくプロセスが不可欠です。DXを進めるためには、DevEXが前提になるし、DevEXによってソフトウェアの価値を創出することができていれば、それはDXの実現に繫がります。このように、DXとDevEXは両輪の関係にあると考えています。
HondaのDevEXを考える上で、クルマを動かすハードウェアとそれを制御するソフトウェアの二つの開発領域があります。
仮説検証を重視する文化は、ソフトウェアに限らずハードウェア領域にも根付いており、特にハードウェア領域ではHondaとして長年の実績があります。これからのSDV時代に向けて、このハードウェア開発で培ってきた知見を、ソフトウェア開発にどう応用していくか、まさにそこが今日の議論のポイントのひとつだと思います。
DXとDevEXは高い相関性があるという観点は、とても貴重です。DevEXは私たちの仕事そのものを考え直すきっかけになるんだろうなと思いました。
Hondaが働きたい会社であり、かつ存在を期待される企業であり続けるためは、Hondaのフィロソフィーである人間尊重の基に、個々人が個性を発揮し、多様性を活かせる組織である必要があると思っています。それにはソフトウェア開発者も個性を基にやりたいことに没頭できる環境作りが重要な課題であると認識しています。
DevEXは主にWebやITの世界で注目されてきましたが、建設・土木・金融のような業種でも重要になっています。
工事中の事故を未然に防止するために、デジタルツインのようなシミュレーション技術を使い、そこで仮説検証を繰り返すとか、金融でもミッションクリティカルな実務においては、システムに意図的に障害を発生させ、その影響を観測することで、システムの堅牢性を向上させるカオスエンジニアリング手法を使って検証を重ねるとか、そういう取り組みが始まっていますね。
ソフトウェア開発者が実機に搭載して、自分でコースを走らせる文化
——Hondaのこれまでの技術検証文化を振り返ると、どんな価値があったとお考えですか。
Hondaは2021年に世界で初めて自家用車にレベル3の自動運転機能を搭載しました。これが実現できたのは、やはり徹底的な仮説検証の文化が社内に根付いていたからだと思っています。Hondaのソフトウェアエンジニアは、OEMとしては珍しく、自分で開発したソフトウェアを実車に搭載し、自ら運転して検証するんです。栃木にはプルービンググラウンド（試験走行コース）があり、実際にそこで走行させて確かめる。これもHondaならではの開発者体験の一つなんじゃないかなと思います。
もちろん、実機を使った検証の前に、デジタルツインを用いたシミュレーションも不可欠です。ただ、これがなかなか難しい。現時点では、車両全体の機能を一気通貫でシミュレーションするのは難しく、どうしても一部機能ごとの再現にとどまります。部分的には正確な検証ができても、すべてを統合して再現するとなると、膨大な手間と時間がかかってしまい、なかなか理想的な姿には至っていません。
とはいえ、中国やアメリカのEVメーカーでは、統合的なシミュレーション環境がすでに整っているとも聞きます。個人的には、そこでどうやってクルマの安全性を証明しているのか、そこが不思議に思うところもあります。ただ、他社でできていることなら、Hondaにもできるはずです。そこは私たちも本気で取り組んでいきたいと考えています。
今後はシミュレーションでも実機でも問題なかったという事例をしっかり積み重ねて、シミュレーションの適用できる範囲を広げていくことが大事だと思います。
私の担当部門はスマートキャビンで、AIとHMI（Human Machine Interface）技術を統合させたデジタルコックピットの開発を目指しています。そのうちインフォテインメントシステムの領域では、我々はAndroid OSを使った製品を開発しています。Android OSはスマートフォンでも使われていますが、クルマの制御系で使われるリアルタイムOSと異なり、信頼性は低いけれども自由度があるプラットフォームです。
それをなるべくうまく使おうということで、例えばAndroid OSの上に載る機能には、もしそれが止まってしまうと安全に支障があるような機能はあえてつけていません。ASIL（Automotive Safety Integrity Level＝自動車安全水準）に引っかかる機能は排除しているんですね。
つまり、たとえAndroid OSが落ちても、クルマの安全性は担保されるというアーキテクチャの上でソフトウェアエンジニア自らが、自分で作ったアプリをクルマにインストールしてデバッグし、実車で試すことをふつうにやっています。そういう意味で、私の領域はとても仮説検証がやりやすい領域といえます。
そこで、今年の4月に私が部門長になったときに掲げたのは「ここの部門の最大のKPIは学習」という目標でした。私たちの領域で怖がっていては価値が出せない。どんどん新しい取り組みをして、たとえ失敗しても、それを糧に学習して、結果的にみんなでいいものを作れるようになっていこう、とみんなに話をしました。
SDVでは、同じソフトウェアでも色々なレイヤーがあるということを前提にしないといけないですね。エンジンなどクルマの基本部品にソフトウェアを組み込んで制御するレイヤーが一番下にあるとすれば、その上にマイコンECU※があり、さらにその上に、自動運転を実現するためのソフトウェア、そしてさらにその上にはインフォテインメントシステムなどが載っている。
アーキテクチャ自体が階層化されているため、要求される安全基準やスピードもそれぞれ異なります。ゆえに、開発者体験についてもまた階層化して考え、それぞれの向上を図る必要がありますね。
Webの世界でも、基幹システムに相当するレイヤーでは堅牢性を最重要視してテストを重ね、アップデートもそう頻繁には行わないけれど、スマートフォンのような顧客との最終接点のところでは、スピーディーに価値提供しなきゃいけないので、SoE（System of Engagement）※的な考え方で、素早く開発できる仕組みにします。
レイヤーを分割して考えるというのは、事業会社におけるDevEXを支えるアーキテクチャの一手法なんですが、SDV開発においても、こうしたレイヤー分けをしながら議論していく必要があります。
※マイコンECUとは エンジンの運転制御を電気的な補助装置を用いて行う際に、それらを総合的に制御するマイクロコントローラ（マイコン）のこと。 ※SoE（System of Engagement）とは 顧客や取引先との結びつきを強化する、あるいは絆を深めることなどを目的として使われるシステムを指す用語のこと。
――米森さんがご担当のAD/ADAS領域ならではの取り組みにはどんなものがありますか。
私の所属するAD/ADAS部門で、ちょっと面白い取り組みとして「アジャイルカー」というプロジェクトがあります。通常のクルマの開発では、量産レベルの完成度を求めるとなると、試行錯誤のハードルがとても高くなってしまうんです。
その点、アジャイルカーはそうした制約にとらわれず、思いついた機能を実車にすぐ載せて自由に試すことができる環境になっています。自身の開発したソフトウェアにとどまらず、OSS（オープンソースソフトウェア）も自由に活用できる特徴があります。新しい機能を試作して、実際にドライバーとして体感することで初めて価値が見えてくる。価値があるとわかれば、それを市販車に搭載するのかどうかの判断もできる。つまり、プロダクションに載せる前の段階で、本当に意味のあるものかどうか見極める、そうした価値起点にトレーニングに取り組んでいます。
アジャイルカーですか。私は初めて聞きましたが、Hondaでそのような取り組みをやっているのは面白いですね。
もう少し社内的にもアピールしていく必要があるかもしれませんね(笑)
アジャイルカーに取り組んで、意外に効果的だと感じたのは、分かりづらい機能を実際に試すことができる点です。特に、先進安全機能ってどうしても分かりづらいんですよね。自動運転のように勝手に運転してくれる機能は比較的イメージしやすいですが、緊急時警報の効果などは、その価値が具体的に分かりづらい。
そういった見えにくい価値をアジャイルカーなら実際に体感することができます。新機能はやはり価値が理解されづらいものですが、実際にその機能を搭載した車両に、経営陣に乗ってもらい、体感を通じて価値を理解してもらう、そういった使い方ができるのも、アジャイルカーの利点だと思います。
過去の成功体験を“アンラーン”することで生まれる新しい経験価値
——新しい技術を頭ではなく、身体で体験することで、変わるものは大きいですね。
お二人の話にも出てきた、「失敗をしてもいいよ」とか「学習が大事だ」という文化。これって、多分多くの人は「それはそうだよね」って納得してもらえるんじゃないかと思います。
ただ、これがもうちょっと仕組みとか仕掛けによって有機的に機能していくようになるためには、実はこれまでの成功体験を一回忘れる「アンラーン」が必要なんですね。アンラーンは「学習棄却」とか「学びほぐし」とも呼ばれるもので、これまでに学んだ知識や身につけた技術を振り返り、さらなる学びや成長につながる形に整理し直すことです。
ソフトウェア開発でも、私より前の世代の人と話していると、「プロセスの標準化」が重要だとよく言われます。それを極めていけば、正解に辿り着けるよと。ところが、私ぐらいの世代だと、標準化よりも「自動化」や「アジャイル化」が重要なキーワードだったりする。
これは世代や人によって、問題解決の型が違うということ。かつてはそれで成功したパターンを経験した人は、会社の中では往々にして偉い立場なので、新しいパターンを持っている若い人と話が合わなくなる。
偉い人は若い人に、もっと「合理的に説明しろ」みたいに抑圧的になったりする(笑)。若い人は若い人で「なんであんな無駄なことをやるのか」と反発する。そういう文化的な対立が起こったりするわけです。
しかし、偉い人も、若い人の型を一度、経験すると、その良さがわかることがある。今までの成功体験とは違う価値基準が存在することを認め、それを体験することで、新しい学びが得られるのです。
まさにこれは、DevEXの話でもあり、DXの話でもある。例えば、完全にオートマティックなテストがされていて、それがお客様にダイレクトに届いているようなWebシステムを一度体験すると、もう他の環境には戻れなくなる。
そのやり方、新しい価値観を広めていこうという側に転換できるけれど、それを体験していないと、いくら一生懸命説明しても「事故が起こったらどうするんだ」と、全然理解してもらえない。理解できないというのは、「腑に落ちない」「腹落ちしない」からなんですね。
広木さんのお話は、私が「これからは学習を一つのKPIにしよう」と話しても、ついこの前まで量産開発など重厚なプロセスで仕事していた人にはなかなか通じないのと似ていますね。
いわゆる「両利きの経営」（既存事業の強化と新規事業の立ち上げを両立させる経営）でいうところの、「知の探索」と「知の深化」で言えば、深化側にいた人間が急に探索側に来たもので、「僕ら、どう動いたらいいんですか？誰に判断をもらったらいいんですか？」となる。いやいや、「君たちで判断していいんだよ」って言うんですけど、「いや、それは⋯⋯」と。文化的な慣れというか、そこには結構大きなギャップがあることは、私もよく目にしています。
自動車業界にある「なぜなぜ文化」の意義を問い直す
——知識を深掘りする方向でいえば、自動車業界の「なぜなぜ文化」は有名ですよね。
確かに自動車業界では、何かミスが発生すると「なぜ？」を最低でも5回は繰り返して、その原因を徹底的に追求するという文化があります。いわゆる「なぜなぜ分析」が品質保証や再発防止のためには欠かせない正義とされてきたんです。実際に、それによって改善が進んだ、そういう成功体験がありました。
しかし、「なぜなぜ」が行き過ぎると、ミスをした本人を追求するような懲罰的な雰囲気になってしまうこともあります。開発の手が止まり、スピードも損なわれる。だからこそ「なぜなぜ文化」は決して絶対的なものではなくて、必要に応じて見直していくべきではないかと思います。一度、そうした従来の価値観をアンラーンして、ソフトウェアの価値の新しい作り方を考える必要があると思いますが、どう変えていくかは模索中ですね。
「今までやってなかったことを、今やるのはなぜ？」と聞くのか、「他のところもやってるし、どんどんやんなきゃいけない。なぜ新しいことしないの？」と聞くのか、どちらも言葉は同じ「なぜ」なんですね。しかし、その疑問を発する人の向きというか、姿勢によってもたらされる効果は変わってしまう。どっちの方向性を持つかは、けっこう質問を発する人の恣意性に任されてしまっている。
「なぜなぜ文化」が新しいチャレンジを削ぐ方向に働いてしまうのはやはり問題です。それを突破するには、同じ「なぜ」でも、上長自身が新しい価値観の方向に導いてあげようというつもりで「なぜ」を発し、メンバーのマインドセットを変えていくという方法が一つあります。
もう一つは、いちいち「なぜ」を聞いても答えが出ないから、それだったら新しいやり方をしたいメンバーを「出島」みたいなところに集めて、まあ、勝手にやらせましょうという方法ですね。そこから新しい文化や方法論が生まれるのを期待する。そこで成果が生まれれば、それをリードした人が新たなリーダーになって、組織文化全体を変えていくという循環も生まれます。
なるほど、その通りだと思います。
しかし、見方を変えると「なぜなぜ」そのものは悪いことばかりじゃないと思うんですよね。単に「なぜ」を発する人が納得するためだけに説明を求めるのは不毛ですが、「なぜ」を開発者が自発的に考えることによって自分がやったことを振り返り、新しい気づきが生まれることもある。振り返り、反省してもらった上で、次にどんな成長があるのかを見届けることができれば、「なぜなぜ」も悪くないので使い方次第ですね。
ディレクション次第ってことですね。
よく子どもを𠮟るときに、「なんでこんなことをしたの？」と「なぜ」を頭ごなしに否定的な表現で使ってしまうことがあるのですが、「なぜ、君はそういうやり方を選んだの？」「どうすればこのようなことになってしまったと思う？」と聞いてあげるのとでは、子どもの反応もかなり違いますからね(笑)
現場の意思決定力は、Hondaにとっての貴重なDNA
——生成AIなどの登場で、クルマのソフトウェア開発にも大きな変化があったのではないでしょうか。
生成AIが登場した当初は、それを使うと社内の情報が抜き取られるんじゃないかと懸念して、利用を禁止する会社もあったと聞きます。でも、Hondaはその点でかなり先進的だったと思います。
例えば、マネジメント層のトップが企業戦略を立てるときに、ChatGPTに問いかけながら壁打ちのようにつかっていたんです。そのやり取りを通じて戦略を深めていく。そういった層の方々も実際に活用しているのを聞いて、最初は正直驚きました。
大手の企業でもやっぱりトップが触っているところは、AIの活用はスタートアップなどよりもずいぶん早かったんです。ソフトウェアの他の新技術に比べたら、エンドのユーザーも触れる技術だったということもありますが、まさに自分で「体験して」、これはすごいなとなったケースです。体験価値が重要だというのはそういうことでもあるんですよね。
上層部の体験価値について話をしましたが、実は、現場レベルでも同じことが言えます。新しい技術にチャレンジするにしても、それを忌避するにしても、その意思決定権が現場にないと、悲劇が生まれます。例えば、開発者用のPCがものすごく遅くてイライラするから新しいのに替えてくれというのでも、その遅さを意思決定者が体験していないと、「なんで今のPCだとだめなのか」が分からないままです。
でもですね、もともと日本の製造業の強さは、現場の意思決定力が高いところにあったんじゃないかと思うんですよね。現場の意思決定が尊重される度合いが高ければ、比較的スムーズに環境改善はされていくはずです。
確かに、かつてHondaのハードウェアの開発者は、今以上にいろんな失敗が簡単にできる環境だった、というふうには聞いています。いろいろチャレンジして、「えっ、ほんとにこんなクルマ出すの？」ということもあったようです。
実際、開発者用のPCは、自分で申請さえすればすごく速いものが使えます。ただ、Hondaは自分から言わないと何も始まらない会社なので、それを言えなくて我慢しているエンジニアが、もしかするといるかもしれません。そういう人を救うためにHondaの文化を周りが体現して見せる必要がありますね。
現場からどんどん要求を出せる文化というのは大切ですね。それを許す上長や部署なのか、まだそういうマインドセットになっていない上長や部署なのか、そのあたりは組織の中でも部署や人によって温度差があって、まだら模様なのかもしれない。しかし、進んでいるところがあるんだったら、それはいずれ企業全体の組織文化の改革に波及していくと思います。
あとは、やはり経営のトップ層にもっとソフトウェアエンジニアが入っていってほしいですね。今でもだいぶ増えてはきましたけれど。
やはりHondaは、CTOを置くべきだと思いますね。経営層に対して技術的に意見できるパスがあれば、正しい経営判断がこれからもできるはず。マネジメントを行う部門長と技術的なエキスパート性を持つCTOは構造的に分けておくべきだと思います。
エマルジョン（乳化）作用を組織に埋めこんで、新しい文化を創りだす
——CTO、ぜひ作っていただきたいなと思います。
CTOは必要ですが、同時にソフトウェア開発だけが唯一の価値観だとは私は思いません。やはり人を乗せて走るクルマですから、ハードウェアとしての安全性は絶対で、そのための堅牢なシステムは不可欠です。
そういう安全性や品質を担保すると同時に、スピーディーにソフトウェアをリリースできる環境、その両方について目配りができ、それを経営判断につなげるのがHondaのような会社のCTOの役割ですね。
一つの価値観だけが絶対じゃなくて、違う価値観を持ってる多様な人たちで組織が構成されているということこそ、最も重要。これまでの当たり前が、もはや当たり前じゃないかもしれないという問題意識をもって議論を活発に交わすことが大切ですね。
私はよく「エマルジョン」という言い方をするんですが、水と油のような本来、混ざり合うことのない物質が、よくかき混ぜることで、「水の中に油が、もしくは油の中に水が分散している状態」⋯⋯。
パスタソースをつくるときによく言う「乳化状態」ですね。私は料理が趣味なので、よく意識します。
そうそう。そのエマルジョンを使って、いかに美味しいパスタソースを作れるか。そのためにはよくかき混ぜるしかない。そうしないと、水と油は分離したままになってしまう。それに近いことを組織でやらなきゃいけないと思っていて、価値観の異なるものを、混ぜ合わせて、新しい企業文化を作り上げること。今まさにHondaはその過渡期にあるんじゃないでしょうか。
Hondaでも、だいぶソフトウェア領域の認知は進んできました。以前は車種ごとにハードウェア側からソフトウェア側への要求が異なっており、それぞれ別々のことを言うものだから、「A様とB様、どちらを僕らは優先したらいいんですか？」みたいな状態があったんです。この調停に現場は非常に多くの労力を使ってしまう。へたしたら自分たちが積み上げたものを壊さざるを得ない時もある。
けれど、私自身、一度勇気を振り絞って「こんなんじゃやってられません」と拳を振り上げたら、意外とみなさん分かってくれて、対等なコミュニケーションができるようになりました。
横田さんが拳を振り上げてくれたおかげですね(笑) ソフトウェアの面白さが、全社的に認知されてきたと私も思います。ソフトウェアエンジニアについてもかなり市民権を得てきたと感じます。
実は、私たちが所属するSDV事業開発統括部など、ソフトウェア部門につく開発予算も想像以上に大きい。もちろん、ハードウェア部隊がひたすらコスト削減努力を続けてくれたおかげで、その分をソフトウェア開発に投入できているというありがたい話ではあるんですが。
そういう意味で、今すごくソフトウェアエンジニアにとって、自動車業界ってチャンスなんじゃないかなって。つまり、ソフトウェアエンジニアが自分の技術を世に知らしめたいとか、社会貢献したいという欲求を叶えやすい会社に、今Hondaはなりつつあるんじゃないかと自負しています。
1on1ミーティングの徹底で、現場の知恵と課題を引き出す
——最後に、今日の対談を踏まえてHondaのお二方はどんなことにチャレンジしていこうと思われたか、また広木さんからはHondaのソフトウェアエンジニアへ、応援の言葉をいただけると嬉しいのですが。
私のいるAD/ADASの領域では、これからもクルマの安全・安心とソフトウェア開発者の体験価値の両立を、大切にしていきたいと思います。
先ほどの広木さんのお話にもあったように、自動車会社には本来現場の強さという大きな力があるとご指摘もありました。そうした現場の声や力をしっかり拾い上げていきたいですね。具体的には1on1ミーティングの重要性をあらためて感じているところです。
昨年は150人ほどのメンバーと一人ひとり30分ほどかけて対話を重ねました。そこから得られた気づきは本当に多く、現場のリアルな声を聞くことの価値を再認識しました。現場の開発者がどんな体験をしているか丁寧に聞き取りながら、何が足りないのかを見極め、どう補強できるかを一緒に考えていきたいと思います。
冒頭も話しましたが、Hondaには「人間尊重」というフィロソフィーがあります。「一人ひとりの個性を発揮してこそ、Hondaの社員だ」ということは、私自身もいつもメンバーに言っています。
一人ひとりの個性を発揮できる環境をつくり、そこから多様性が生まれて初めて、ソフトウェアエンジニアとしての価値が実現できると思っています。それを抽象的にではなく、具体的にわかってもらうためには、やはり、小さくてもいいから少しずつ成功体験を積ませることが大事。
それと、品質のことばかり口を酸っぱくして言う「品質おじさん」(笑)たちとも、水と油のように利害対立するんじゃなくて、お互いのスキルを寄せ合って、エマルジョンしあって、次のHonda文化を作っていきたいと思います。
アジャイルの歴史をたどっていくと、日本の製造業が淵源だったことがわかるんです。かつてのアメリカ人にとっては、日本の製造業現場がどんどん改善していいものを作っていくことが脅威でもあった。その品質改善の仕組みを学びながら、ソフトウェア開発における新しい手法を作り上げたんだろうと思います。
実はHondaも、そのDNAをずっと残している会社の一つ。それがあれば、SDVの時代にも、新しい価値を作っていくことができないわけがない。そこに期待しています。
※掲載内容は2025年7月時点のものです。
