2回目が2013年12月に発覚したエンジンECUや変速機ECUにおけるプログラム不具合によって、エンジンがストールしたり、駐車状態から起動しなくなる恐れがあるもの。
そして、3回目が2014年2月で1速歯車のハブ上をスリーブが滑らかに動かず、1速がかみ合わなかったり、突然発進する可能性があるとのこと。最後の1件はソフトウェアの不具合ではないようだが、1速ギヤがかみ合いやすくなるようにエンジン制御ユニットのプログラムを変更するため、これも制御ソフトウェアの変更で対処する。
東洋経済のWEBサイトに【ホンダ｢フィット｣に不具合が多発する理由－早くも3度目のリコール､好調な販売に冷や水－】という記事があり原因について下記のようなことが書かれている。
【ホンダ｢フィット｣に不具合が多発する理由－早くも3度目のリコール､好調な販売に冷や水－より引用】
新しいHVシステムが原因
今回、十分な対応ができなかった背景には、DCTを使ったHVシステムがホンダにとってこれまでに経験がないまったく新しい複雑なシステムだったことがある。従来、ホンダはHVのシステムとしてIMAという方式を使っていた。これは常に稼働するエンジンを必要に応じてモーターがサポートするという比較的単純な方式のHVシステムだった。
これに対して新システムは、2つのクラッチを持つDCTにモーターを組み合わせ、発進時にはモーターのみで走行し、加減速や車速など状況に応じて変速機の段数を変化させてモーターアシスト走行やエンジン走行、充電を行う複雑な機構になっている。ホンダにとって、モーターのみで走行できるHVの経験はなく、DCTという変速機方式も初めての採用だった。
複雑な制御を行うため、変速機の制御ソフトウエアの開発工数は、ガソリン車や既存HVに比べて「半端なく増えた」（開発者）。DCTのユニットを供給するドイツの大手機械メーカー・シェフラーの開発陣とともに、本田技術研究所では最後の最後まで手直しを繰り返したという。
HV競争の緒戦でトヨタに完敗したホンダが、逆転をすべくHVシステムを完全刷新するという高い目標に挑んだわけだが、品質管理での詰めが十分でなかった。【引用おわり】
また、日本経済新聞の記事では下記のようなことが書いてある。
「次は許されないぞ」――。順風満帆に見えるホンダで、社長の伊東孝紳をいらだたせる問題が発生した。
：
伊東が掲げた目標を達成するには、どのくらいのペースで、これから販売台数を上積みしていけばいいのか。
答えは、今までの4倍近いスピードだ。
ホンダは過去10年間、販売台数を年平均で約14万台ずつ増やしてきた。しかし、600万台の目標達成には、向こう3年は年平均で50万台超の販売台数の積み増しが必要な計算になる。
そんな「4倍速」の成長を追っていけば、その分、開発部隊への負担が重くなって当然だ。そもそも研究所の技術者たちの仕事は、フィットなど「今の車」だけをつくることだけではない。
これらの記事の中で出てくるキーワードをまとめると下記のようになる。
- まったく新しい複雑なシステム
- 初めての採用
- ソフトウェアの開発工数が増えた
- ソフトウェアを最後の最後まで手直しを繰り返した
- 開発は急がされていた
ホンダの3回のリコールのソフトウェアの不具合の具体的な原因が表には出てこないので、ソフトウェアの技術的な分析はできないが、このキーワードを見ただけでさもありなんと感じる。
特に「まったく新しい複雑なシステム」で「手直しを繰り返し」ていて「開発は急がされていた」という条件とソフトウェアのリコールは相関があると確信する。
セーフウェアを書いたMITのナンシー・レブソン教授の最近の研究である (STAMP: Systems-Theoretic Accident Model and Processes) では、プロジェクトへのプレッシャーがシステムの安全に与える影響を分析している。そういった定性的な分析もさることながら、新しい複雑なシステムで開発が急がれていて手直しを繰り返していたら、アーキテクチャが崩れていくことが予想される。
ポイントは新規設計した際のアーキテクチャが綺麗だったとして、現実の状況に合わせてソフトウェアのすり合わせを繰り返してアーキテクチャを崩してはいけないということだ。デリバリーを急がされるプレッシャーに負けると、アーキテクチャは崩れる。ソフトウェアは外には見えないだけに、そこの防波堤はアーキテクトの考え方やポリシーにかかってくる。
早期リリースのプレッシャーに負けるとソフトウェアシステムの複雑度が増して、バグやデグレードの温床を生んでしまう。そんな危険はアーキテクトとしての経験がない者にはまったく分からないので、経営層はプロジェクトにリリースを間に合わせることを優先しろと言ってしまう。「リリースは間に合わせろ、バグは出すな」と言うのも同じことだ。バグを出さないようにするには、検証に十分な時間が必要であり、かつ、十分な時間が与えられたとしてもバグをゼロにすることはできないので、「リリースは間に合わせろ、バグは出すな」という指示は、結果として「バグ入りでリリースする危険を冒せ」と言っているのと同じなのだ。
東洋経済の記事も日経の記事も最後は品質管理の詰めが十分でなかったという結論になっているが、そこで終わらせたらダメだろうと思う。
じゃあ、品質管理の詰めって何だと聞きたい。ホンダだって ISO 26262 の取り組みをやっているはずだろう。なぜ、ISO 26262 の取り組みを行っているのに、ソフトウェアのリコールが起こるのか、誰か答えてはくれないだろうか。
下記の文章は 2006年 9月14日、15日に開催された 日科技連主催の－ソフトウェア品質シンポジウム－で広島市立大学情報学部教授 大場充先生が「ソフトウェアのテストと品質保証」について講演されたときの話を書き起こしたものだ。
答えは分かっている。ソフトウェア品質はプロセスで管理するのが1970年代からの主流ではあるが、不具合の発生を完全に防止できる訳でもなく、プロセスアプローチは安全性や信頼性を保証する方法ではないということなのだ。
ようするに、プロセスアプローチは組織やプロジェクトの活動を改善することには役立つが、安全の保証には使えないということだ。だから、「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」という問いに答えられるはずがない。
経営層が本当にリコールを防止したいのなら、ISO 26262 とは別の取り組みを進めなければならない。ISO 26262 の取り組みを進めることは無駄にはならないが、リコール防止の切り札として考えているのなら、今回のホンダと同じような痛い目に会うだろう。
一番やってはいけないのは、「新しい複雑なシステムに対して開発を急がせる」ことだ。経験主義者のアーキテクトからのアドバイスとしては、安全対策を施したリスクコントロール手段をアーキテクチャとして可視化し、リリースが近づいてきた時ほどアーキテクチャの崩れに注意を払い、「リリースが近いから早くしろ」とエンジニアを焦らせないことだ。
そして、いつも言っているように個別最適の発想ではなく、全体最適の発想を持ち、バグはあるものと過程して、バグがあっても大事故に至らないような設計の心掛けることが重要だ。
今回のホンダの3回のリコールも結局、死傷者は一人も出ていなかったのだから、その点フェール・セーフは達成できていたと考えて良い。後は、ブランドイメージ低下と販売の落ち込みの程度を計算し、十分な検証期間を取ったことで販売が遅れたときの機会損失とどっちが得かを比較すればよいのだと思う。
大きなリスクについては受容できる対策が取られているのならば、軽微な不具合は市場で発見されたものを改善することで対処するという考え方もある。消費者もそこは分かっていて新製品には飛びつかず技術が枯れるまでしばらくまったりするのはそのためだ。
この程度のマイナス記事は数ヶ月もすれば皆忘れてしまうとどっしり構えていればよいときもある。
ただ、あまりにも不具合の発生が多いと企業としての信頼を失うし、修正を繰り返しているとアーキテクチャは崩れていく可能性が高い。
最後に繰り返す。新しい複雑なシステムに対してプロジェクトに過度なプレッシャーをかけて開発を急がせてはならない。悪い結果を呼び込むだけだ。
特に「まったく新しい複雑なシステム」で「手直しを繰り返し」ていて「開発は急がされていた」という条件とソフトウェアのリコールは相関があると確信する。
セーフウェアを書いたMITのナンシー・レブソン教授の最近の研究である (STAMP: Systems-Theoretic Accident Model and Processes) では、プロジェクトへのプレッシャーがシステムの安全に与える影響を分析している。そういった定性的な分析もさることながら、新しい複雑なシステムで開発が急がれていて手直しを繰り返していたら、アーキテクチャが崩れていくことが予想される。
ポイントは新規設計した際のアーキテクチャが綺麗だったとして、現実の状況に合わせてソフトウェアのすり合わせを繰り返してアーキテクチャを崩してはいけないということだ。デリバリーを急がされるプレッシャーに負けると、アーキテクチャは崩れる。ソフトウェアは外には見えないだけに、そこの防波堤はアーキテクトの考え方やポリシーにかかってくる。
早期リリースのプレッシャーに負けるとソフトウェアシステムの複雑度が増して、バグやデグレードの温床を生んでしまう。そんな危険はアーキテクトとしての経験がない者にはまったく分からないので、経営層はプロジェクトにリリースを間に合わせることを優先しろと言ってしまう。「リリースは間に合わせろ、バグは出すな」と言うのも同じことだ。バグを出さないようにするには、検証に十分な時間が必要であり、かつ、十分な時間が与えられたとしてもバグをゼロにすることはできないので、「リリースは間に合わせろ、バグは出すな」という指示は、結果として「バグ入りでリリースする危険を冒せ」と言っているのと同じなのだ。
東洋経済の記事も日経の記事も最後は品質管理の詰めが十分でなかったという結論になっているが、そこで終わらせたらダメだろうと思う。
じゃあ、品質管理の詰めって何だと聞きたい。ホンダだって ISO 26262 の取り組みをやっているはずだろう。なぜ、ISO 26262 の取り組みを行っているのに、ソフトウェアのリコールが起こるのか、誰か答えてはくれないだろうか。
下記の文章は 2006年 9月14日、15日に開催された 日科技連主催の－ソフトウェア品質シンポジウム－で広島市立大学情報学部教授 大場充先生が「ソフトウェアのテストと品質保証」について講演されたときの話を書き起こしたものだ。
ソフトウェアの品質論は、1960年代のZD(Zero Defect)運動に始まり、不良を無くすことが、究極的な品質の実現であるとする経験主義的色彩の濃い統計的品質管理が行われてきた。その後、ソフトウェアの規模や複雑度の増加に伴い「ソフトウェア開発において良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるプロセス重視の品質論が主流になる。そして改めて経験主義者の代表として問いたい。「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」「なぜ、自動車の安全を目的に作られたプロセスを実践してもリコールを無くすことはできないのか」
プロセス重視の品質論は1970年代以降個々の理論の不備を修正しながら今日まで発展し続けており、その枠組みは強固である。しかしながら、「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」という経験主義者から提示される疑問に完全に答え切れていない事実も存在する。
答えは分かっている。ソフトウェア品質はプロセスで管理するのが1970年代からの主流ではあるが、不具合の発生を完全に防止できる訳でもなく、プロセスアプローチは安全性や信頼性を保証する方法ではないということなのだ。
ようするに、プロセスアプローチは組織やプロジェクトの活動を改善することには役立つが、安全の保証には使えないということだ。だから、「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」という問いに答えられるはずがない。
経営層が本当にリコールを防止したいのなら、ISO 26262 とは別の取り組みを進めなければならない。ISO 26262 の取り組みを進めることは無駄にはならないが、リコール防止の切り札として考えているのなら、今回のホンダと同じような痛い目に会うだろう。
一番やってはいけないのは、「新しい複雑なシステムに対して開発を急がせる」ことだ。経験主義者のアーキテクトからのアドバイスとしては、安全対策を施したリスクコントロール手段をアーキテクチャとして可視化し、リリースが近づいてきた時ほどアーキテクチャの崩れに注意を払い、「リリースが近いから早くしろ」とエンジニアを焦らせないことだ。
そして、いつも言っているように個別最適の発想ではなく、全体最適の発想を持ち、バグはあるものと過程して、バグがあっても大事故に至らないような設計の心掛けることが重要だ。
今回のホンダの3回のリコールも結局、死傷者は一人も出ていなかったのだから、その点フェール・セーフは達成できていたと考えて良い。後は、ブランドイメージ低下と販売の落ち込みの程度を計算し、十分な検証期間を取ったことで販売が遅れたときの機会損失とどっちが得かを比較すればよいのだと思う。
大きなリスクについては受容できる対策が取られているのならば、軽微な不具合は市場で発見されたものを改善することで対処するという考え方もある。消費者もそこは分かっていて新製品には飛びつかず技術が枯れるまでしばらくまったりするのはそのためだ。
この程度のマイナス記事は数ヶ月もすれば皆忘れてしまうとどっしり構えていればよいときもある。
ただ、あまりにも不具合の発生が多いと企業としての信頼を失うし、修正を繰り返しているとアーキテクチャは崩れていく可能性が高い。
最後に繰り返す。新しい複雑なシステムに対してプロジェクトに過度なプレッシャーをかけて開発を急がせてはならない。悪い結果を呼び込むだけだ。
0 件のコメント:
コメントを投稿