2010-05-22

レクサスのパワーステアリング不具合の原因分析について

トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。

今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。

レクサスホームページより引用】
レクサスLS460、600hのお客様へのお詫びとお願い

本日、レクサスLSのVGRSに関する報道により、お客様にご心配をお掛けすることになり、申し訳なく存じます。
現在、リコールの準備を進めておりますので、LSのお客様には次の項目に注意して運転していただきますようお願いいたします。
なお準備が整い次第 販売店よりあらためてご連絡申し上げます。

●注意していただく運転状況
・右左折やUターン等でハンドルを据え切り状態にしたのち、急ハンドルのような素早い戻し操作をすると一部報道されましたハンドルの中立位置ずれが発生しやすいので、急な操作はできるだけ避けていただきますようお願いします。

●運転中にハンドルの中立位置ずれが発生した場合
・車両の進行方向に注意してハンドルを操作するとともに、急な発進や加速は行わないようにお願いします。
・車両が直進状態でハンドルの中立位置がずれていることに気づいた時はハンドルに軽く手を添えていると車両の直進状態に合わせてVGRSシステムが自動的に中立位置ずれを補正(ハンドルが微動しながらズレを修正)します。
・ハンドルを中立位置にしたのに車両が直進状態でないことに気づいた時はハンドル位置に関係なく、車両が直進状態になるようハンドルを操作して いただきますようお願いします。

●当該現象は急ハンドルに相当するような素早い戻し操作をした場合に発生する場合があるものですが、走行中に現象を確かめるような運転は危険ですので絶対におやめください。

2010年5月19日
トヨタ自動車株式会社
【引用終わり】

なお、相変わらず報道各社の情報は問題の本質を分析するための材料となる情報が乏しい。Tech-On! のような技術寄りのサイトが解説してくれるとよいのだが、5/22現在ではこの件に関する記事はなかった。

一番詳しいと思われる記事が毎日jp に載っていた。

【『トヨタ:レクサスをリコールへ 信頼回復途上に痛手 イメージ低下、不可避』 毎日jp より引用】
トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサスの旗艦車種「LS460」など4車種のリコール(回収・無償修理)を決めた。台数は国内で約4000~4500台、海外分を合わせても1万台余と少ない。しかし、米国を中心に延べ約1000万台に及んだ大規模リコール問題の衝撃がようやく沈静化してきただけに、新たなリコールの発生は、ブランドイメージの低下など痛手となりそうだ。【米川直己】

「信頼回復には、顧客の不安に瞬時に対応する必要がある」--。トヨタ幹部は、今回のレクサスのリコール決定をそう説明する。一連の大規模リコール問題で、対応の遅れを厳しく批判されたトヨタ。豊田章男社長は再生に向けて「顧客の安心・安全を最優先する」との方針を掲げ、リコールを躊躇(ちゅうちょ)しない姿勢を示している。

ただ、今回、リコールの対象となったのは、高級車ブランド「レクサス」の中でも最上位クラスのLSシリーズ。セダンタイプの「LS600hL」は1台1000万円以上。メルセデス・ベンツなどに対抗するトヨタの看板高級車種だけに、リコール対象台数以上に、富裕層など顧客へのイメージダウンの影響が懸念されそうだ。

リコールの原因となったのは、ハンドル操作と前輪の動きを適切に調整する電子制御装置「ギア比可変ステアリングシステム(VGRS)」。もともとトヨタがベンツなど欧州の高級ブランドに対抗する武器の一つとして導入したものだが、今回はその自慢の高度なハイテク装置に落とし穴があった。

LSのパワーステアリングは電動式で、ハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つと、故障を防ぐためVGRSが停止する仕組み。1~2秒でVGRSは再び作動するが、作動前にハンドルを戻し始めると、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。VGRS作動後はハンドルとタイヤ角度のズレを検知する装置が働き、通常に戻るが、この際のタイムラグが顧客に不安を与えていたという。

今回の問題は通常の運転ではほとんど起こらないといい、トヨタは説明書に注意書きを入れていた。しかし、顧客からの不安の声が相次いだ以上、信頼回復途上のトヨタにはリコール以外の選択肢は無かった。

==============

■ことば

◇ギア比可変ステアリングシステム(VGRS)
車の速度に応じてハンドル操作を補助し、前輪の動きを最適に調整する電子制御装置。低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やUターン時の操作を容易にする。一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。トヨタは02年、SUV「ランドクルーザー100」に初搭載。「クラウンマジェスタ」や「レクサスGS」などにも採用を広げた。
【引用終わり】

断片的に次のような情報も流れている。
トヨタは昨秋、VGRSの制御プログラムを変更。その際に不具合を把握していたが、「安全性には問題がない」として取り扱い説明書への記載で済ませた。しかし、今年3月以降、トヨタに対して12件の苦情が寄せられた。
トヨタ幹部によると、ハンドルが一時的に戻りすぎるのは機構上の特性で、説明書に注意書きも入れていた。しかし「対象の車は戻り方が極端で、顧客に不安を与えてしまった。より運転しやすくするために昨年秋の一部改良でプログラムを変更したことが裏目に出た」と説明している。
「運転しやすくするため、モデルチェンジにあわせてプログラムを改良したのだが…」。トヨタのある幹部は、電子制御の改良が、リコールにつながったことを嘆いた。同時に「機構上の特性」としたことに対する悔恨もにじんだ。
このような情報を総合すると、次のような経緯があったのではないかと予測される。

【レクサスのパワーステアリング問題発生の経緯(予測)】
  1. メルセデス・ベンツなどに対抗するため、トヨタは低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動き駐車やUターン時の操作を容易にし、一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能「ギア比可変ステアリングシステム(VGRS)」をレクサスに搭載した。
  2. VGRSではハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つので、熱による故障を防ぐため(ある一定以上の熱を帯びると?)VGRSが停止する。1~2秒でVGRSは再び作動する。
  3. VGRSが作動前にハンドルを戻し始めると(当初、この行為は取扱説明書上の禁止事項としていた)、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。
  4. 2009年の秋にレクサスのモデルチェンジに合わせてより、快適な運転ができるようにVGRSのソフトウェアを変更したところ、3の角度不一致の度合いが大きくなり最大で90度までずれるようになった。(角度のズレは自動的に補正される)
  5. 今年3月以降12件の苦情が寄せられたため、ソフトウェアを改変(どのような改変かという情報はまだキャッチできていない)し、約4000台の回収に踏み切った。
メーカーは想定されるリスクは軽減のため機器に対して設計上の対策を講じる。しかし、どうしても設計でリスクを回避できないとき、効果効能に対してリスク回避の対策に莫大なコストがかかるようなとき、表記上の対策、すなわち取扱説明書に禁忌事項を掲載したり、機器にラベルを貼ったりしてユーザーに注意を喚起することでリスクを回避する場合もある。

あってはならないのだが、エンジニアが設計上の対策を講じるのが面倒(正確にはそこに注力を注いでいると期限が間に合わない)と考えたとき、「これは表記上の対策にしよう!」と問題に正面からぶつかるのではなく、逃げるケースがある。リスクの度合いにもよるが個人的にこのようなことを自分は絶対に許さない。「何のために、誰のために開発をしているの」か技術者に問うことにしている。

今回のレクサスのパワーステアリングの不具合のケースは表記上の対策で済ませるべきか、設計上の対策まで講じるべきが微妙なところだ。こんなことで、いちいちリコールしていたらたまったもんじゃないと思っている自動車メーカーはたくさんあるはずだ。現に、プリウスのリコールが話題になっていたときあまり大きく取り上げられなかったがいろいろな自動車メーカーが(裏で)リコールをしていた。

トヨタはプリウスのリコールの件で信用を失墜しかけたので、今はグレーでもある一定数のユーザーから黒ではないかと言われたら躊躇せずに「黒でした。設計上の対策を講じます。」というようにしている。

ソフトウェアのリスクとその回避の手段を常に考えている分析者としては、それはやり過ぎではないかと感じている。グレーか黒かの切り分けは、ユーザーリスクの大きさで判断するべきであってユーザーのクレームの強さで判断するべきではないと思う。顧客の感覚は主観的である場合も少なくなく、客観的な判断ができないこともあるからだ。

ただ、このブログでも何度も言っているがソフトウェアの不具合はハードウェアの部品ように故障率のような概念がないため、不具合に至る手順が分かると、確実に不具合を再現することができてしまう。(システマティックエラー)

だから、ユーザーが滅多にやらない行為であっても、「こんな風になります」と実験報道することが簡単にできる。これをやられるとマイナスイメージが瞬く間に広がる。

だからこそ、ソフトウェアが起因する不具合は表記上の対策では片付けられない。ユーザーは許してくれない。滅多にやらないからといって対策を取らなくていい、「発生確率が低いので安心してください」とは言えない。だから、実際に問題が起こってもリスクは小さいと言えるのなら、ユーザーがちょっとだけ不快に思うだけなのなら誠意をもって説明し、不快な気持ちを和らげる努力として何ができるか考えた方がいい。いろいろ考えても、それが設計上の対策になるのならはじめからヤレということになる。

■不具合が発覚したとの組織がエンジニアに取る態度について

今回もプリウスのブレーキのソフトウェア改変のときと同様に、ソフトウェアの複雑性が絡んでいるため問題を分析するとき「ソフトウェアのバグ」「検証し忘れ」などと短絡的に原因を決めつけてはいけない。

ソフトウェア絡みのリコールが発生すると組織内で鬼の首も取ったように「それ見たことか」という態度を取る人たちがいるが、自分はそういう人たちに言いたい。「では、同様の問題がリコールを実施する機種や他の機種にないかどうか調べる方策は考えているのか」「再発防止についてどんなアイディアがあるのか」と。

問題が明らかになってから大騒ぎするのは誰でもできる。ソフトウェア品質保証担当の重要な役目は是正と予防だ。なぜ、そのような問題が起こるのかを分析し、どうすれば今後起こさなくできるのか対策を立案し、実行し、うまくいったかどうかを継続的にウォッチすることがソフトウェアQAには求められる。

■顕在的価値(Real Value)と潜在的価値(Potential Value)のトレードオフ関係

プリウスのブレーキにせよ、レクサスのパワーステアリングにせよ、問題の原因には、ユーザー要求の多様化とソフトウェアの複雑化のトレードオフが関係していると思っている。『組込みソフトエンジニアを極める』でも『リコールを起こさないソフトウェアのつくり方』でも、組込み機器にはカタログに載せるような「顕在的価値(Real Value)」と、ユーザーが当たり前に確保されていると思っている「潜在的価値(Potential Value)」の両方の価値が存在し、そのバランスが保たれていないと長い目で見たときに顧客から信頼を得て高い業績を上げることはできないと書いた。

簡単に言えば、ユーザー要求は多様かつ複雑になっているので、その多様性や複雑性に起因する顕在的価値をソフトウェアで実現しようとすると、やり方によっては潜在的な価値が下がってしまう可能性があるということだ。

通常はその2つは、トレードオフの関係にある。多用で複雑なものが当たり前に動くことを実証するのは難しい。だから、安全や信頼が求められる潜在的価値の高い機能や性能は、多用で複雑にはせず、多用で複雑なものは安全や信頼とは切り離しておく方がよい。カーナビのように多用で複雑なものは安全や信頼と切り離しておかないと危ない。

■ギア比可変ステアリングシステム(VGRS)は顧客にとってどんな価値がある?

そこでまずは、ギア比可変ステアリングシステム(VGRS)の顕在的価値について考えてみたい。

<ギア比可変ステアリングシステム(VGRS)のポイント>
  • 低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やUターン時の操作を容易にする。
  • 一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。
  • レクサスやクラウン、マークXなどの一部に採用しており、高級車としての差別化を図るために採用した機能だと思われる。
さて、上記の機能、性能は顧客満足にどれくらい貢献しているといえるだろうか。分析にはQFD(品質機能展開=組込みプレス Vol.8 の特集記事参照のこと)を使うとよいのだが、まあ、普通に考えて他社と差別化するための付け足しの機能、性能であり、車としての本質的な機能や性能ではないことは明らかだ。個人的にはパワーステアリングが基本的な機能だけあれば十分ではないかと思う。

そして問題は、この付け足しの機能を実現するためにソフトウェアが複雑化し、ハンドルが曲がっている状態で直進してしまうという、車としての基本機能を損なう問題を埋め込んでしまったという点だ。基本使用における安全性は確保されていようだが、0.1%の品質にこだわるトヨタとしてはユーザーに不安を与える可能性があるので回収を決めた。

トヨタは今後、検査態勢を強化することで再発を防止するとニュースサイトに書かれていたが、それは本質的な改善策にはならないと思っている。なぜなら、これほどに複雑化したソフトウェアシステムを完全に検査するためのテストケースは爆発的に増えてしまっており、テストケースと結果が妥当かどうかを完全に検証していたら設計するときよりも時間がかかってしまうからだ。

検査で何とかなると考えていること自体、21世紀のソフトウェアシステムの品質管理の概念ではない。Verification(検証)でソフトウェアの完全性を追い込めるのは規模や複雑性が小さいときだけであり、10万行を超えるサブシステム、そして、サブシステム同士が相互の作用しあって動くシステムでは、Verification(検証)は安全や信頼の確率を高める効果でしかなく、絶対に安全である、信頼できるというお墨付きは出せない。

それを理解した上で、いかにユーザーリスクを受容できレベルまで引き下げるかという取り組みがSoftware Validation(妥当性確認)である。

■大規模複雑化したソフトウェアシステムの潜在的価値を高めるには

トヨタのみならず、多くの組込み機器メーカーの組織上層部は複雑化したソフトウェアの怖さ、当たり前にできていることの価値、すなわち潜在的価値(Potential Value)を高くキープすることも難しさを認識できていない。

そして、他社と商品を差別化する際に部品代がかからないからという理由ではソフトウェアによる機能追加を考える。それにより潜在的価値が犯される可能性など予想もしないし、不具合が発見されるとそれはプログラマのうっかりミスと決めつけられる。それで不具合の発生する確率が下がるのならいいが、ソフトウェアの規模が大きくなるにつれ、逆に確率は上がっていくだろう。

多くの組込み機器の開発に関わる組織は当たり前にできていることの価値、すなわち潜在的価値(Potential Value)を過小評価している。というよりは、細かい顕在的価値(Real Value)を積み重ねることでシステムが複雑化し、そのことによって当たり前に出来ていることに問題が起こることを想定できていない。

特にトヨタはその認識が不足しているのではないかと思う。それはなぜかと言えば、これまでは徹底的に顧客要求のチューニングのためにソフトウェアを変更しまくることで、98%の顧客満足度を0.1%刻みで100%に近づけることに成功してきており、その成功体験がリスクを見えなくしていると思うからだ。

トヨタはユーザーの使用環境を想定したソフトウェアのシステムテストとソフトウェア部品を供給するサプライヤーに対する厳しい検証要求で問題を潰しきれると思ってはいないだろうか。

日本のたたき上げの組込み機器産業ではよく見られる光景だ。顧客満足を高めるために尽力を注ぐことは正しい。しかし、ユーザーが当然できていると思っていること、すなわち安全や信頼がシステムが複雑になることで脅かされるリスクについてはみな鈍感だ。

理由は簡単。日本のたたき上げの組込み機器産業の組織上位層はソフトウェアはハードウェアを制御するつなぎ役として長い間見てきており、現在のように巨大化して複雑になったソフトウェアシステムに内在する爆弾の怖さを実感できていないからだ。

爆弾をサプライヤの管理とカイゼンの積み重ねでつぶせると思っているのなら、それは間違いであり、MISRA SA(『リコールを起こさないソフトウェアのつくり方』のAppendix B に概要を書いた)をよく読んだ方がよい。安全は上流の要求分析とアーキテクチャで押さえ込まなければならない時代になっている。

安全なアーキテクチャ、基本機能が脅かされない信頼性の高いアーキテクチャでソフトウェアが設計されているかどうかをソフトウェア開発の上流で検証する必要がある。それをせずにすり合わせ的手法、付け足し手法でソフトウェアを作って、徹底的にテストで爆弾を見つけようとしてもムリである。

■シンプルデザインの価値とは?

シンプルデザインの価値は有限なテストケースで Validation ができるということだ。一流の職人(ソフトウェア技術者)はシンプルなアーキテクチャを評価できるが、セールスマン、マーケットプランナーは一流でも、シンプルなアーキテクチャを評価できない。要求を実現できれば、シンプルなデザインになっているかどうかは気にしない。ソフトウェアの見えなさの弊害だ。

安全や信頼だ求められるソフトウェアはシンプルなアーキテクチャで潜在的価値を最大にする。どうしても複雑にならざるを得ないときは0.1%の表面的な顧客満足度よりも、数10%の潜在的価値=当たり前品質につながるシンプルアーキテクチャの方を取る。それができるのは、数々のものづくりを経験してきた職人(=システムアーキテクト)だけだ。

顧客の要求を取り入れメーカーが自分でアーキテクチャを設計せず、サプライヤーにものづくりを任せて何年もたつとその感覚はどこかに飛んでしまう。

自分はクルマ屋さんは頼むからカーナビとブレーキの機能を連動させるような複雑なシステムを作らないで欲しいと思う。時代は進化しているから、新しい機能がないとユーザーが買ってくれないからといって、システムを複雑にし、わざわざリスクを盛り込んでいったらシステムアーキテクチャはシンプルデザインとは言えなくなってしまうのではないか。(洗練されたアーキテクチャで、安全と複雑性の高い要求を実現できていると言えるようなら脱帽だが、本当にそうなっているだろうか)

真の銘品には洗練された美しさがあり、経験を積んだ仕事人はそれをかぎ分けることができるのだが、ソフトウェアは見えないからそう簡単にはいかない。できるといっていることが多用で複雑で使いそうにもない機能満載の場合、怪しいと感じる。

一時の快楽=おいしいカタログのうたい文句が顧客に効き、売り上げに貢献するのは最初だけであり、潜在的な価値のよさは長年使い込んだ時にはじめてユーザーに理解され、そして、それが理解されるとユーザーはそのブランドやメーカーのファンになる。長く惚れ込んでくれるファンを増やすためには、シンプルなアーキテクチャが美しいと感じる感性と、複雑よりもシンプルを選択する組織の分析力、決断力がいる。

フィールドで問題が起こったときメーカーはサプライヤに「コラー!なんてことしてくれたんだ!」と言っているだけではダメで、ユーザーニーズと安全が確保できるアーキテクチャであるかどうかを判断できなければいけない。そのためには自分自身でものづくりを主導し続けなければいけない。サプライヤーから提供された部品を組み合わせているだけでは安全アーキテクチャができているかどうかを見極めるスキルはつかない。

アーキテクチャの分析能力が大事であり、くるまドメインの方は、まずは、MISRA SA(Safety Analysis)を読むとよいと思う。

2010-05-16

『リコールを起こさないソフトウェアのつくり方』の感想

4月に感想を送っていただける方に『リコールを起こさないソフトウェアのつくり方』を進呈するキャンペーンを実施した。

本を読んでいただいた yuri_at_earth さんから感想が送られてきたので紹介したいと思う。

【『リコールを起こさないソフトウェアのつくり方』の感想】



まず、ソースコード20例が大変貴重なものだと思いました。ベテランになった著者の方が考えて書いた初心者っぽいコードでは、実際に初心者が書いたコードははまるポイントを押さえてはいたとしても、それ以外の素人っぽさは再現できなくなっていると思うので、リアル感がよかったと思います。実際に集められる人も限られていると思いますし。

しかも、2,3例でなく、20という数がいいですね。私自身、ちゃんとした集合教育的なものを受けたことがなく、同じ課題を多数の人が書いた結果というものを実際に体験したことがなかったので、とても貴重でした。さらに、同じ人が書き直したコードが改善された例など、この部分は新人時代に読みたかった、もしくは前職で部下だった人たちに見せたかった感じです。

次にこれまでの経験をもとに素直に読んで、「プライドを傷つけないようにする」という表現が、最もなのですが(だからゆえ?)笑えました。(私があまりほかの本を読んでないのかもしれませんが)こういう内容を強調されているところが特徴的というか、現場を経験されている方ならではだと思いました。

その他、実際に見聞きされたんだろうなという例がたくさんあって、心当たりがあり苦笑するものと、組み込みだとそうなのかと思うところがありました。ちょっと話がとびますが、エンプラ系はもともと進化が早く、新しいものを取り入れたものが偉い的な風潮があり、昔ながらのやり方だとだめ的な考え方があるためか、プライドを傷つけないように新しいことを取り入れていくという考え方は少ないように思います。

どちらかというと、新しいものについていけない方が悪いというような。。。
そして、やっぱり(吸収の早い)若い人にはかなわないよねという文化だと思います。とはいえ、上司のプライドを傷つけないように導入していけば、エンプラ系でありがちな、最近の技術はわからんから若いもんでやれ的な態度で投げ出すのでなくて、協力してくれるのかも?と思いました。

実際、以前の職場のマネージャは、javaはわからんとか、最近の~はわからんとかで実装は経験が数年レベルの部下に丸投げ状態で、その結果テストが全然だったことがありました。そこで、最近の開発環境とか、はやりとかはわからないかもしれないが、テスト設計をするときの考え方は今も昔も同じだし、彼らはそのスキルがないのでテストしたつもりになっていても、実際は肝心なところがテストされていないんですよ。なので教えてくださいという話をしたら、快諾してくれたことがありました。

プライドを傷つけずに導入することができていたら、(昔は言語は違えど現場でばりばりにコードを書いていたはずの)上司が、実装はわからないと目も耳もふさいでしまうことはなかったかも?と思ってしまいました。(本題とはかなりずれてしまいましたが・・・)

最後に、今の職場の問題に対してどう対処すべきか?という目線からです。まさに現状がこの本の例にあるように、「あたたかい人間関係の中のやさしい一員」状態なので、ここに書かれていることを気をつけながら導入していけばよいかな?と思ったのですが、現状でそれなりにうまく回っていて、現場的にも特に問題意識もなく、開発規模が大きくなることもなく。。。

ならば、このまま「あたたかい人間関係の中のやさしい一員」のままでいるのもひとつの解かと思ったのですが、ここはどうお考えですか?
【感想終わり】

まずは、感想を送っていただいた yuri_at_earth さんにお礼を言いたい。ありがとうございました。書籍にしてもブログにしても読者が何を考えているのか、こちらからの発信をどう受けとめたのか、じっと待っていてもが何も分からない。その点、Twitter は双方向のコミュニケーションが成立しているが、やはり不特定多数の読者の深い意見を吸い上げることができない。

そういった意味でも本の感想は貴重だ。Amazon のサイトにも「とら子」さんから「日本の開発現場にフィットする品質向上策」というタイトルで『リコールを起こさないソフトウェアのつくり方』の感想をいただいたので是非見て欲しい。

さて、yuri_at_earth さんの感想で Part1 の20のソースコードの例が貴重であると評価していただいたのが正直うれしい。重厚なタイトルにしてしまったため、新人や初級者、上司の方達には「自分には関係のない本」と思われたかもしれないが、実は Part1 だけでも切り離して多くの初級プログラマや指導する先輩、上司の方達に読んで欲しい内容なのだ。

Part1には他の本には書かれていない人間の本質からくる危うさを具体例で示している。その危うさは現場でまともに仕事をしていくとどんどん薄れていくのでほとんどの技術者が忘れてしまうのだが、「焦っているとき」「集中力が欠けているとき」「モチベーションが下がっているとき」などに、その危うさがプログラムに出る。また、プロジェクトリーダーが確固たる設計の規範を持っていないとき、持っていてもメンバーに指導しきれていないときに、その危うさがソフトウェアシステムの欠陥となって表面化する。

その根源がどこにあるのかを Part1 では具体的に読者に知ってもらいたかった。テストでよい点を取る手順のように、あらかじめ用意されたユニットテストのテストケースをパスすることだけに注力を注いでいると、そのソフトウェアを使うエンドユーザーにとって危険なプログラムを作り込んでしまう可能性があるということをソフトウェアを作ったことがない人、昔作っていたけど今のような大規模・複雑化してしまったソフトウェアの中身を知らない人に伝えたかった。

「プライドを傷つけないようにする」というのは特に日本のソフトウェアプロジェクトでプロジェクトを成功させるためには重要なポイントだと思う。この本では「あたたかい人間関係の中のやさしい一員」というキーワードを何十回も書いている。日本人がそういう性質を持っているからこそ、トップダウンでの指示よりも、プライドを傷つけないように気をつけながら導くことが大事なのだ。ちなみに、D・カーネギーの『人を動かす』にも同じようなことが書いてあるので特に日本人だけに当てはまることではないみたいだ。

yuri_at_earth さんからの「あたたかい人間関係の中のやさしい一員のままでうまくいっているので、これまでのやり方を変えていく必要があるのか」という問題提起に答えていきたい。

20年くらい前の組込みソフトウェア開発の現場は「あたたかい人間関係の中のやさしい一員」でうまく回っていた。開発効率は今ほど納期が厳しくなかったのでそれほどプレッシャーが強くなかったし、最終成果物の品質もよかった。しかし、現在、自分の周りではそんなにうまくはいっていない。ひとつの製品が自分のプロジェクトの中だけで閉じなくなってきている。スタンドアロンの機能だけでは他社に勝てない、ネットワークを使った連携機能が求められるようになってきた。

そんな時代になった昨今、「あたたかい人間関係の中のやさしい一員」の世界で培われてきたアプローチと「創造性と個性にあふれた強い個人」の世界で体系化されたアプローチの両方を使わないと顧客満足の高い商品をアウトプットできないと考えている。

もちろん、プロジェクトの人間関係という視点では「あたたかい人間関係の中のやさしい一員」のよさが前面に出ていていいのだが、大規模、複雑化したソフトウェアシステムの顧客に対する安全や信頼を保つためには「創造性と個性にあふれた強い個人」の世界で体系化された是正・予防のアプローチ等をきっちりやっていくことも必要だ。

ただし、マニュアルに書かれたようにシステマティックでなくても、大工の棟梁が失敗した職人を呼び出して説教をし、一度目は軽く、二度目は雷を落とすという、見事な是正・予防のアプローチをしていることもあるから「あたたかい人間関係の中のやさしい一員」もまんざら捨てたものではない。

また、CMMIには是正を言い渡してダメ出しした後に、相手と飲みに行って「本音で話す」などというアプローチは書いていないが、上記の大工の棟梁は雷落とした後に職人を飲みに連れて行ったりする。

従って、問題提起の答えは「顧客を満足させる品質が保てているのなら今のままでよい」「それが危うくなってきたら、変わる必要がある」となる。大工の棟梁のすごいところは顧客満足のことを第一に考えていながら、職人を一人前に育てることも同時に重要だと考えているところだ。どちらが欠けてもいけないことが分かっている。でも、どんなに優れた棟梁だって100人の職人を同じように気に掛けてやることはできない。そのアプローチの有効な範囲(プロジェクトの規模)はある。

西欧と東洋の良さを融合させながら、グローバルマーケティングにアウトプットする商品が多くの顧客に満足される品質を確保するにはどうしたらいいかということを『リコールを起こさないソフトウェアのつくり方』には書いたつもりである。

2010-05-05

人は教育によってどれくらい変われるか?

4月5月は教育計画を立てる時期ではないだろうか? その時期にいつも思うことは「人は教育によってどれくらい変われるか?」ということだ。

教育によって知識を増やすことは可能だ。しかし、知識を増やすだけでは組織内の問題はなかなか解決しない。今の世の中、知識を詰め込むトレーニングは意味がない。なぜなら、知識の多くはインターネットで検索できるようになってしまったからだ。

必要な知識は検索したりお金を払って手にいることができるようになった。人間に求められているのは、それらの知識を使ってさまざまな問題を解決することである。

今読んでいる『20歳のときに知っておきたかったこと スタンフォード大学集中講義』(5/5現在でアマゾンのランキング1位!)には次のように書いてある。

【『20歳のときに知っておきたかったこと スタンフォード大学集中講義』p21-22より引用】
 教師はたいてい、学生に知識を詰め込むことが自分の仕事だと思っています。教室のドアは閉められ、机と椅子は教師に向かって固定されています。学生は、後で試験に出ることがわかっているので、熱心にノートを取ります。教科書を読んでおくことが宿題として出され、学生は黙々と予習します。大学を出てからの生活は、これとはまったく違います。社会に出れば、自分が自分の先生であり、何を知るべきか、情報はどこあるのか、どうやって吸収するかは、自分で考えるしかありません。実社会での生活は、出題範囲が決められずにどこからでも出される試験のようなものです。ドアは大きく開かれているので、何か問題にぶつかったとき、職場や家庭で問題が起きたとしても、友だちとの悩み事も、世界全体の問題を考えるときも、身の回りの資源をいくらでも利用できます。
【引用終わり】

そうなると『20歳のときに知っておきたかったこと スタンフォード大学集中講義』に書いてあるように、イノベーションを起こせるような思考トレーニング、行動が必要であり、それがないと組織改善につながらない、ルーチンワークをこなすだけならルーチンワークのやり方を教えることでトレーニングは終わってしまう。多くの組織では中堅から上級の社員に対してはそれでは足らないと言われる。

しかし、プロジェクトリーダーの立場で考えると「人間はそう簡単には変わらない」と思う。上記の引用のようには考えていない大学の先生が大半ならいいが、現実はそうではないし、アメリカの大学でできることと日本の大学でできることは異なる。

人間何十年も生きてくれば育ってきた環境やこれまで関わってきた人々の影響を何らかの形で受けている。360度のうち1度、2度、3度くらいは変わることがあっても、10度、20度、30度も変わることはそうはない。

そう考えると、今いるプロジェクトメンバーに対して組織が欲しいと思う理想の型にはめ込もうとするのはあまり効果的ではないんじゃかと思う。どちらかと言えば、その人の特長、良さを引き出すようなマネジメントが効果的だと考える。

かねてからピーター・F・ドラッカーや、トム・デマルコはそれぞれの著書でそういっていたと思う。

仮面の忍者赤影(古い?)やゴレンジャー(まだ、古い?)や A Team や、幽遊白書のように、チームの中でそれぞれが特技、役割を持ちそれらを活かしてチーム全体としてのパフォーマンスを上げるのが一番いいと思う。

しかし、現実的な問題は解決すべき問題に対してどうしても現在のメンバーでは足らないスキルがあるときだ。こういうときにオールラウンドプレイヤーがいるとプロジェクトリーダーはとても助かる。プロジェクトのパフォーマンスを最大にすることできる。

そういうオールラウンドプレイヤーやキープレイヤーがいないときは、一時的にでも外から連れてこなければいけないのだが、そういうことができないときもある。だから、プロジェクト設立のときの人選はとても重要であり、それがうまくいくかどうかで7割方プロジェクトの成功が見えると思う。

このようなプロジェクト運営のやり方で起こる問題として次のようなことがある。

  • それぞれに得意な仕事を割り振った後に残った誰もがやりたくない仕事を誰にやってもらうか?
  • どうしても現メンバーでは足らないスキルがある。
  • 他のメンバーの足を引っ張るようなチームの和を乱すものがいる。
「やりたくない仕事」は見習いレベルの者がいれば「すべては修行」と言ってやらせるし、中堅、ベテランばかりのときはチームとして必要な仕事であることを説明したときに理解し同意してくれる者にやらせるべきだろう。そういう者はいずれ上位に上がっていく。

どうしても現メンバーでは足らないスキルがある場合こと、トレーニングのときだが、トレーニングしてもダメな時はダメなものだ。データベースの設計をやったことがないメンバーに一週間くらいのトレーニングに行かせてもデータベースの設計はできない。

多くの場合、そういうときはお金を払って外部の協力会社に開発を委託するのだが、お金がでないときはどうするか、自分の場合はプレイングマネージャーとして自分がそのスキルを身につけるようにしている。一時的負荷は増えるが新しいことを学ぶことは楽しいし、オールラウンドの範囲が広がる。

チームに悪影響を与えるような者がいる場合、JaSST'10 Tokyo の基調講演で、Ms. Johanna Rothman (Rothman Consulting Group, Inc.) は、早めにクビを切れ(実際には転職先を探してあげたそうだ)と言っていた。

そういうもろもろの複雑な事情含めて考えると、問題解決能力の高いメンバー、新しいことに対して臆せず取り組んでくれるメンバーがいかに貴重であるかがわかる。

そういう人材を高く評価し、さらに伸ばす仕組みが社会的に確立されるといいなと思う。それは、ヒューマンスキルではないんだよね。ITSSたETSSなどソフトウェア系のスキルスタンダードは整備されてきたが、イノベーターとしてのポテンシャルを測るスケールがなかなか世の中にないから『20歳のときに知っておきたかったこと スタンフォード大学集中講義』が売れているんじゃないだろうか?

P.S.

日経コンピュータ 2010.4.28 号の書評に『リコールを起こさないソフトウェアのつくり方』が載ったので紹介しておく。
高品質・高信頼なソフト開発手法の解決書。トヨタ自動車がブレーキ制御ソフトの問題で大々的なリコールを実施したのは記憶に新しい。ソフトは大規模・複雑になるにつれ品質維持が困難になる。解決にはプロジェクト管理の改善とソフトの資産化が肝要と、組込みソフト開発歴20年の筆者は主張する。リコールになりかねない「危ない」プログラムの例にも注目。
著者として短いながら当を得た書評だと思う。感謝!