アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。
一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。
そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering Tokyo）でその成果を発表するとともに、元祖ハードウェアアジャイルともいえる1990年代の初代プリウスの開発プロセスを分析しています。
なぜいまトヨタでアジャイルなのか、具体的にどのような形で従来型のハードウェア開発にアジャイルの手法を取り入れているのか、パワートレーンカンパニーの竹内さん、南野さん、田中さんに伺いました。
▲ トヨタ自動車株式会社 パワートレーンカンパニーの竹内さん（左上）、南野さん（右上）、田中さん（下）
- 竹内 伸一（TAKEUCHI Shinichi） パワートレーン機能性能開発部 第1機能開発室 室付
- 南野 圭史（NANNO Keishi） パワートレーン統括部 プロジェクト進行管理室
- 田中 恵太（TANAKA Keita） TM開発部 第3TM開発室
- トヨタ自動車のパワートレーン開発、アジャイルに出会う
- スクラムの要素のいくつかはトヨタでもう実践されていた
- テスラの事例とともにハードウェアアジャイルを学ぶ
- トヨタなりのやり方でモブができるようになってきた
- プッシュ型の開発からプル型の開発へ
- ソフトウェアを含めたシステム全体のアジャイル開発を目指す
- 合わせて読みたい
トヨタ自動車のパワートレーン開発、アジャイルに出会う
── スクフェス三河やRSGTの発表では、現代のアジャイルの観点から初代プリウスの開発プロセスを分析され、さらに現在のアジャイルな取り組みも紹介されています。なぜいま自動車のハードウェア開発においてアジャイルに注目されたのかをお聞かせいただけるでしょうか？
竹内 私にとってアジャイルとの最初の出会いは、2021年に社内で見たWOVEN CITYに関連したアジャイルコーチによるスクラム紹介でした。 アジャイル開発について2時間くらいで簡単に紹介した動画だったのですが、そのころ自分が感じていた課題がちょっと解決できたように思えたのです。
── その当時のプロジェクトで何か課題があったということでしょうか？
竹内 具体的なプロジェクトというよりは、自分たちの開発全般に対するモヤモヤとした懸念ですね。 それがアジャイル開発の紹介を見たことによって解けた感じがしたのです。
ご存じのとおり、現代の自動車産業はカーボンニュートラルやエネルギーマネジメントといった大きな課題への対応が迫られています。 そうした中にあって、パワートレーンに関しても、EV（電気自動車）や水素自動車など、かつてない多様な技術開発が必要とされています。 メジャーな変更が次々と押し寄せてくる中で、どんどん新しいことを進めていかなければなりません。 社内でも「100年に一度の変革期」と言われています。
一方、その当時にパワートレーンの開発で中心だったのは、従来の技術に対する比較的マイナーな変更への対応でした。 トヨタでは80年にわたって内燃機関の燃費や性能の改良を加え続けてきて、90年代にはハイブリッドシステムを開発し、そこから20年以上かけてハイブリッドにも磨きをかけてきました。 そのため2021年ごろは、内燃機関にしてもハイブリッドにしても、無駄を省いたより効率的な開発に重点が置かれていたのです。
結果としてまったく新しい技術や複合的な領域の技術を開発していく力が弱まってしまっているのではないか、すぐにでも目を覚ます必要があるのではないかという懸念を、少なからぬ人が抱いていたと思います。
── そのタイミングで竹内さんはアジャイル開発に出会ったわけですね。
竹内 そうです。非常に価値がありそうなので、謙虚に学んでみよう、と。 それで交流があったアジャイルコーチにScrum Allianceの研修を紹介してもらい、認定スクラムマスター（Certified ScrumMaster、CSM）の資格を取得しました。
同じころ、トヨタで業務改善のために導入していたBR（Business Reform）組織の部長からも「アジャイル開発をしたい」という申し入れがあったようで、一緒に二人で教育を受けました。 そのとき講師をしてくれたのが、アギレルゴの川口恭伸（@kawaguti）さんやジェームズ・コプリエンさんです。
── 川口さんは、初代プリウス開発の分析プロジェクトでも分析チームの一人として登場されていましたね。研修を終えて、まずはこの調査分析に着手されたのでしょうか？
竹内 いえ、研修を終えた2021年の秋から、実際の開発でさっそくスクラムに取り組みました。初代プリウス開発を分析したプロジェクトは2023年になってからで、アジャイルの取り組みを振り返ってさらに広げるために実施したものです。
── 初代プリウスは初のハイブリッド車としてそれまでとまったく異なるエンジンを短期間で開発する必要があったため、必然的にアジャイルになったということでしたね。生々しい事例としてとても面白かったです。
スクラムの要素のいくつかはトヨタでもう実践されていた
── 開発プロセスの中身について少し踏み込んで伺います。2021年にスクラムを取り入れたのは、スクフェス三河で後半に発表されていた「新規開発パワートレーン」の新規ユニットと新規エンジンの開発ですね。
竹内 そうです。ものすごくわかりやすく言うと「すごいハイブリッド車」の部品です。
現在ではそれに留まらず、例えば田中さんのチームでは「すごい電気自動車」の部品の開発にアジャイルを取り入れています。 南野さんも、30人くらいの別のプロジェクトや、少人数ですが委託業者の方々ともアジャイルな取り組みを実践しています。
── すごいハイブリッド車では、どれくらいの規模でアジャイルを始めたのでしょうか？
竹内 最初は8チーム、100人くらいでしたね。 パワートレーンのユニット開発にはそれくらいの人数がいるものなので、思い切ってやりました。
── 取り入れたアジャイル開発手法は、いわゆる「スクラム」そのものでしょうか？
竹内 当初はスクラムのすべてのメソッドに挑戦してみるということで、それなりの期間にわたって本来のスクラムを実践しました。 スプリントレビューでチーム全員が進み具合や遅れ具合を共有しながら、互いに知らない領域についても話をしていくというやり方ですね。
一方で、トヨタには従来の組織体もあります。それらとの折り合いも含めた最適解はチームのフェーズによって異なります。 ある程度まで軌道に乗ったプロジェクトであれば、「連絡会」と呼ばれるトヨタの従来のやり方に乗っかって開発を進めるほうが効率がいいこともあります。
── スクフェス三河の発表でも、新規パワートレーンの開発をクネビンフレームワーク*1に当てはめて、開発のフェーズが進むと解決すべき問題が変化するので手法も変化させたと分析していますね。
竹内 はい。なので現在は完全なスクラムで開発を進めているチームはなく、アジャイル開発の理念を取り入れながらそれぞれに工夫をしてやっている形です。
南野 そもそもトヨタにおける従来のプロジェクトの進め方には、当然ながらスクラムと共通する要素がかなり入っているんですよ。 例えば、もともとトヨタではユニット開発のリーダーを含めた毎週の課題共有会という場があり、そこでプロダクトバックログとかスプリントバックログに類する課題リストをしっかり整理します。
これは事実上、スプリントプランニングやスプリントレビューに相当しています。 デイリースクラムに類する昼礼とか朝会もあるし、各グループの方針とかルール作りといったワーキングアグリメントに近い場もあります。
竹内 トヨタで伝統的にやってるT-KI（Toyota Knowledge-intensive-staff Innovation）という会合もかなり近い役割を持っています。 技術の深掘りや教育をKIが担っているので、そうするとデイリースクラムでは本当に短時間で全員が共有しなければならない困りごとや進捗を確認するようにプロセスが変化していく。
同じようにスプリントレビューも、開発が進んで従来の連絡会のような場で詳細を決めれば済むフェーズになったら、そのチームでは省略されるような形へと変わっていきます。
── そうした変化はチームごとに自然に発生するものなのでしょうか？
竹内 スクラムでやるメリットと、負担が増えることによるデメリットについてメンバー同士が意見を出し合いながら、フェーズごとにワーキングアグリメントとして決定していきました。
── 逆に従来のトヨタにはない、スクラムならではだと感じたプラクティスはありますか？
南野 スプリントごとに完成度を決めたりレトロスペクティブをしたりという進め方ですかね。 完成度については、長年にわたってパワートレーンを作ってきた中で定められたトヨタスタンダードとか内規、あるいは設計マニュアルがすでにあるので、よほど新しい技術でない限り、あえて決め直すことはありません。
レトロスペクティブに関しては、トヨタでは1つの開発が終わってから実施となっているので、スプリントごとに振り返りをするスクラムとの違いがあります。 あとはプラクティスというよりメンタル面の話ですが、従来型の開発より心理的安全性が確保しやすいところがあるように思いました。
テスラの事例とともにハードウェアアジャイルを学ぶ
── 先ほど竹内さんから、田中さんのグループではすごい電気自動車の部品の開発にアジャイルを取り入れているという話がありましたが、やはりスクラムでしょうか？
田中 いえ、私たちのグループではスクラムはまったくしていなくて、プロセス自体はトヨタのいつものやり方です。 ただし、仕事の進め方の中で、トヨタのやり方で会議体を開くところを、なるべくモブ（Mob）の手法でアジャイルにやろうとしています。
── モブというのは、チームでプログラミング作業を行うモブプログラミングをハードウェア開発に適用したものということですね。
田中 はい、ハードウェアアジャイルについて学べるJoeDXという認定資格の研修があり、このJoeDXで学んだ11のプラクティスの1つがモブでした。私だけでなく、竹内さんや南野さんを含めてアジャイルを推進する何人もがこの資格を取得しています。
▲ プリウス開発に見るアジャイル開発要素と今時の進め方：続編 - Speaker Deck（52ページより）
── JoeDXで学べる開発手法は、講師自身の企業のほかテスラやスペースXなどの事例をもとにしているそうですが、テスラといえばトヨタにとって完全な競合ですね。あえてその事例を学んだということでしょうか。
竹内 田中さんたちは、すごい電気自動車のユニット開発にアジャイルを取り入れようとしていて、それなら最先端で頑張っているテスラのやり方もしっかり把握したいはず。その上でより優れたものを作りたいだろうと考えました。私はCSMの後でJoeDXも取得していましたが、田中さんが勉強する素材としては一番でしたね。
田中 JoeDXについては、講座の概要ビデオを竹内さんから上司経由で見せてもらって知りました。 ハードウェアアジャイルの開発プロジェクトをマネジメントをするからには、これはぜひ勉強しなければいけないと懇願して、トヨタ社内で開催された2日間の研修に参加させてもらいました。
▲ プリウス開発に見るアジャイル開発要素と今時の進め方：続編 - Speaker Deck（50ページより）
── 先ほどJoeDXではモブを含めて11のプラクティスを学んだという話がありましたが、モブ以外で活用されているプラクティスはありますか？
田中 モブの他には、3つのプラクティスをハードウェア設計に取り入れています。 まず最初は「アジャイルDNA」と呼ばれているもので、「職位に関係なく全員が平等で全員が開発者である」といった、それこそテスラにおける考え方をルールとして明文化したようなものになります。
もう1つが「リーンコーヒー（lean coffee）」で、アジェンダなしで「とりあえず集まろう」という会議の実践です。 トヨタは「会議をやるならしっかりと議題や資料を事前に準備する」という文化なので、リーンコーヒーのようなやり方には馴染みがありませんでした。
それから「OST（Open Space Technology）」と呼ばれるミーティングの手法で、思い立ったらモブをやってもいいし、うまくいかなかったら中止したり別の内容にしたりしてもいい。 要するに出入り自由な会議体だと理解しています。これもトヨタにはない考え方でした。
── 会議の進め方に関するプラクティスが多いようですが、4つが選ばれて、ほかが採用されなかった理由が気になります。
田中 前年度に予算計画を立てて承認を取るといった、会社としてのプロセスを変えなえれば採用できないプラクティスもあり、それらは採用が難しいと考えました。
一方、モブ・リーンコーヒー・OSTといった会議の進め方やアジャイルのルールは、自分たちの考え方、マインドセットを変えれば実践できます。
── なるほど。先ほどスクラムの要素はすでにトヨタの中にあったという話もありましたが、プラクティスの形よりマインドセットが大切だという見方もできそうですね。
▲ プリウス開発に見るアジャイル開発要素と今時の進め方：続編 - Speaker Deck（53ページより）
トヨタなりのやり方でモブができるようになってきた
── 実際にモブをどのように実践しているのかを教えてください。
田中 モブは、1つの作業を進めるにあたり、いろいろな領域を担当する全員がそれぞれ開発者として知恵を出し合うというやり方です。
従来のウォーターフォールのやり方だと、設計を終えてから図面を作り、その図面から生産部門が自分たちの工程に落とし込んでチェックをして、それでようやく物を作り始めるという流れになります。 そうすると、生産部門から設計に対して何か質問があっても、図面を渡された後のタイミングでしかできません。 これだと無駄が多い。
そこで、例えば検討資料をもとにCAD上で図面を検討する工程で、設計の担当者がドライバー、生産部門の担当者がナビゲーターという役割を担いながら一緒に検討するようにします。 実際にハードウェアを作る前準備の段階でいろんな部署の人が集まって確認しながら進めていくわけです。
── 先ほど予算などは変化させることが難しいという話がありましたが、グループやチームの構成はどうでしょうか。部署の規模や参加者の役職などによってはモブの実践が難しい面もありそうですが。
竹内 モブをやるうえで最も大事なことは、各メンバーが自律的に動くことです。 そのためには、上司が部下を信頼して権限を与え、心理的安全性にも配慮しなければなりません。 それができれば、若い方々にとって学びの機会にもなりますよね。
田中さんのグループでは経験年数が少ないメンバーも多く、その中でプロジェクトをうまく進めるために、そういう効果も考えてモブを取り入れたようです。
南野 私も、モブを採用した背景として、経験年数が少ないメンバーがベテランと一緒に考えることで学習の機会が増える効果に期待したと聞いています。
竹内 田中さんのグループでアジャイルを推進している板津さんという面白い方がいるのですが、彼がそのあたりをいろいろ考えていたようです。 実際のところ、モブをいちばん楽しんでいたのは彼かもしれません。
田中 私たちのグループはメンバーの半数が社外の出向で構成されていて、そうすると出向期間が終わって新しい方に入れ替わるたび、プロジェクトの知見を1から共有し直してもらう必要があります。 そこにも危機感があり、全体のスキルを上げて開発の効率を高く保つという観点からモブに着目された面もあったようです。
── 知見を特定の人が占有せずにチームで共有することは、アジャイル開発の特長でもありますね。実際、その効果は出ているのでしょうか？
田中 若いメンバーが、作ったことのない資料を1人の知見者を交えたモブを通して作れるようになったとか、ベテランが休んだ日でも作業を止めずに他のメンバーで補填しながらモブを実践するとか、そういった効果は確実に出ています。 全体のスキルレベルが上がっているのも体感できています。
南野 ちょっと違う話になりますが、ExcelやPowerPointのようなオフィス系ツールの操作方法というレベルでも、ナビゲーターの指示でドライバーが操作をする過程で相互に研鑽されて上達する効果があると感じています。 結果として、モブを離れた通常の業務でも生産性が上がっているのを実感しています。
── 先ほどお聞きしたようなモブのさまざまな効果は、始めてみてすぐに得られたのでしょうか？ それとも試行錯誤の結果ですか？
田中 初めはツールや環境が整っていなくて、うまく続かないと感じることもありました。 例えば、最初は通常の会議机にみんなが対面で座ってモブをやっていました。 それではどうしても会議チックになってしまい、ディスプレイの前にいる人がファシリテーターになってずっと話しているような状態で、従来の会議とあまり変わらなかったんですよね。
── 写真を拝見すると、現在は全員が大きなディスプレイに向かって座り、参加者同士が互いに顔を見ないスタイルでやられているのですよね。
田中 そうです。そのディスプレイを竹内さんたちの尽力で導入してもらい、このスタイルで実践できるようになりました。 こうした設備の予算を期の途中に工面してもらうのは本当に大変なので、それで「使いこなさなければ」という意識が働いたことも、アクティビティとして継続する上で助けになった気がします。
▲ プリウス開発に見るアジャイル開発要素と今時の進め方：続編 - Speaker Deck（56ページより）
── モブの実践は、JoeDXの講座で推奨されているスタイルの通りでしょうか？
田中 真面目なメンバーが多いので「教わった通りにやるべき」という意識からなかなか抜けられないときもありますが、学んだスタイルでやらなければダメということもないので、わりと自分たちなりのやり方で進められています。 竹内さんや社外のアジャイルコーチにも相談しながら「トヨタの開発のやり方の中でいろいろやれている」という評価ももらえて、今は「これでいいんだな」と認識できるようになりました。
── 具体的にはどういったやり方を取っているのでしょうか？
田中 JoeDXの講座では2時間や3時間のモブを学びましたが、自分たちは従来の会議時間に沿って1時間で集中してやる形が多いです。 人数についても、ナビゲーターとドライバーを含めて4人程度でやることもあれば、他部署の人を交えて10人くらいでやることもあります。
チーフやリーダークラスで積極的にモブをやっているメンバーが数人いて、それぞれにスタイルが出来上がっている傾向もありますね。
プッシュ型の開発からプル型の開発へ
── 先ほどモブの説明で、ハードウェアを作る前の段階として複数な部署のメンバーが集まって確認しながらモデルを作り上げる例を紹介されましたが、最近ではそういったときに3Dプリンターなども使えそうですね。
田中 やはりモブでは、計画立案やモデルの作成といったPCの画面を見ながらの業務が中心になりますね。
3Dプリンターについては、金属から削り出さなければ評価できない部品は作れないものの、イメージを素早く掴むためであったり、部品どうしの組み付けを確認したりするといった目的で利用することはあります。そのための設備はもちろん以前からありますし。
南野 3Dプリンターの活用などは、アジャイル開発を進める上ではなく、リードタイム短縮の一環としてもともとやってきた施策ですね。 トヨタでは、とにかくリードタイムを短縮するためにTPS（トヨタ生産方式）として何が必要かをずっと考えているんですよ。
── そのようにTPSでリードタイム短縮がすでに強烈に意識されているトヨタでも、あえてハードウェアアジャイルに取り組む必要があるのでしょうか？
竹内 先ほどスクラムの話の際にクネビンフレームワークに当てはめた分析をしたのですが、アジャイル開発はその左上にある複雑系（Complex）の領域で有効だと考えています。
具体的には、ハイブリッドや電気自動車のパワーレーンといった新技術の開発や、複数の領域AとBとCを初めて組み合わせるケースがありますね。 その際に技術の必要性に対する変化や、品質の低下といった問題に早いタイミングで気づくには、スプリントゴールを定義するアジャイル開発が有効です。
南野 スプリントゴールに関しては、完成度をどう定義するかが難しいんですよね。 例えば自動車のエンジンを開発するとなったときは、過去の知見とか経験から決まる完成度があるので、それらの課題を1つずつ解決していけばいい。
しかし、そのような知見や経験がまだない新規の開発で、完成度をどう定義すればいいかについては、正直なところ不慣れな面があります。 そこをうまくできるようにすることが、ハードウェア開発でアジャイルをやるうえで肝の1つになるはずです。
トヨタの製造においては、プル型生産という考え方があります。アジャイルは、生産だけでなく開発でもプル型を実践することだと考えています。 そのためにも、過去に知見がない領域でも正常異常をしっかり判断することで完成度を定義できるようになることが重要だろうなと。
── プル型の開発という考え方について少し補足していただけると助かります。
南野 いわゆるウォーターフォール開発では、設計から製造まで進んでからV字に折り返した先で、ようやく対応する各工程のチェックが可能になりますよね。 それまで1年とか1年半といった期間がかかることもある。 ソフトウェアでは、シミュレーション技術の進化とともに、この間隔をキュッと短くできたことで、アジャイル開発が広まりました。
しかしハードウェアの開発では、なかなかそう単純にこの間隔を短くできない事情があります。 まず設計部門がモデルを作成し、それをシミュレーションの担当者に渡して、その結果が図面を描く人に渡り、それでようやく物を作って評価するという具合に、前工程から後工程へと「プッシュ型」で進めていくのがハードウェア開発では一般的だからです。
一方、トヨタの製造現場では、後工程から前工程にかんばんを使ってフィードバックをすることで製造を引っ張っていく「後工程引き取り」が絶対です。 つまりプッシュ型ではなくて、後工程から前工程を支えるプル型です。
このように製造の工程と開発の工程が対照的なんですが、アジャイル的な仕掛けをうまく取り入れることで、開発でもプル型をしっかり織り込んでいくことができれば無駄がなくなります。
ソフトウェアを含めたシステム全体のアジャイル開発を目指す
── 最後に、ハードウェアアジャイルに対する今後の取り組みについてお聞かせください。
田中 自分たちのグループでアジャイル開発を取り入れて特によかったと考えているのは、「全員が開発者だ」というマインドセットを得られたことです。 もちろん、リーダーであったり承認者であったりは必要ですが、このマインドセットを得たことで、課題解決に向けて全員がモブで知恵を出せる状況になりました。
まだ実践から1年も経っていない段階ですが、これから開発が本格化する中で、今後はこれを社内でもっと広めていくことが課題だと考えています。
南野 先ほど述べたように、プッシュ開発をプル開発に持っていくこと。そのため完成度をしっかり定義できるようにすることが大事だと考えています。 あとは、状況の見える化をもっとしたいですね。
竹内 私自身は、現在は実開発から離れてコーチングのほうを中心にやってるので、もっと関係者との会話を活性化するとか、必要な事柄をフラットに議論できる場を作るとか、心理的安全性を確保しながらタイムリーに速断速決できてやり直しを最小化するプロセスを作っていくことなどを課題と考えています。
トヨタには成功体験が強くて「自分一人で何でもできちゃうよ」という人が多くいるのですが、そういう人がいるとアジャイル開発はうまく回らないこともあります。 無理にやらせようとすると逆効果になったりするので、周囲のメンバーが組織としてアジャイルを実践していくことが重要ですよね。 開発が進めばソロで任せていい状態になってくることもあるので、フェーズごとにやり方を固定せずに見直すことも大切です。
あとは、ハードウェアアジャイル開発がもっと浸透してマインドセットと文化の変化が進んだ先の話として、最終的な姿はソフトウェアのアジャイルと連携したシステム全体のアジャイル開発だと考えています。 製品開発が目指すところは、ハードウェアとソフトウェアを個別にやった先にあるわけではなく、お客様を含めたトータルのシステムとして良い機能を実現することにあります。 まだまだ難しいと思いますが、いろいろな会社が挑戦されてる話も聞いてますので、我々としてもしっかりやっていきたいです。
── トータルのシステムとして自動車を考えることは大きな挑戦ですね。本日はありがとうございました。
※参考リンク インタビュー中で参照しているスクフェス三河とRSGTでの発表は動画も公開されています。
取材・構成：鹿野 桂一郎（@golden_lucky / ラムダノート）
編集・制作：はてな編集部
*1:リーダーが意思決定するためのフレームワークとして、ウェールズの経営コンサルタントで研究者であるデイブ・スノーデン（Dave Snowden）が開発し、2007年のハーバード・ビジネス・レビューに掲載した論文「A Leader's Framework for Decision Making」で広く知られるようになった。直面する状況を「単純（Simple）」「困難（Complicated）」「複雑（Complicated）」「カオス（Chaotic）」「無秩序（Disorder）」に分類することで、それぞれの状況に適した対応が分かる。日本語版ハーバード・ビジネス・レビューの「臨機応変の意思決定手法」などを参照。
