ソフトウェアアーキテクチャの改善はなぜ進まないのか

ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ（構造）を改善するということには意味がある。

家が完成してしまうと外面からはどのようなアーキテクチャ（構造）でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。

ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない人には見えない、理解できないからやっかいだ。

ソフトウェアアーキテクチャの改善（＝ソフトウェアプロダクトラインの導入）は組織のトップからおろしていくのであれば、品質面のメリットよりも、コストメリットや開発期間の短縮のメリットが強調されると思う。ただし、改善の実現には一時的にソフトウェア資産の再構築が必要になるため、成果が現れるまでには2～3回製品を開発するサイクル（1年以上）を回す必要がある。その投資期間をじっと我慢することができれば、その後から劇的な効果が現れる。

日本の組織ではそのようないったん我慢をして後々の利益を取るという判断ができる企業は少ないので、なかなかソフトウェアアーキテクチャの改善に踏み出せない。

そこで考えるのは、プロジェクトやエンジニアにアーキテクチャ改善の重要性を諭して取り組んでもらうというアプローチだ。しかし、それもなかなかうまくいかないケースがあることに気がついてきた。

既存のソフトウェアシステムのアーキテクチャを可視化して問題点を共有しても、思ったより改善に対する気持ちがイマイチ盛り上がらない場合がある。それはそもそも既存のソフトウェアシステムのアーキテクチャ設計を外部の協力会社の技術者に任せているケースだ。建築業界においてハウスメーカーが自社の商品の構造設計を外注することはないと思うが、ソフトウェアの世界ではソフトウェアシステムのアーキテクチャ設計を外部の技術者にゆだねることはよくある。悪い言葉で言えば丸投げだ。

アーキテクトがプロジェクトのメインメンバーの外にいる場合、アーキテクチャの改善は非常にやりにくい。なぜなら、アーキテクチャに問題があることに対してアーキテクトはすぐに理解できるが、プロジェクトのステークホルダには十分に理解できないからだ。協力会社のアーキテクトはアーキテクチャの改善をプロジェクトに進言するということは、これまで納品してきた自分たちのソフトウェアに問題があったことを告げることににもなる。アーキテクチャの改善とはこれまでのソフトウェアシステムの中にある問題点を自ら認め、未来のために一時的な苦労を強いることである。そのためには協力会社のエンジニアを含めたプロジェクト全体で現在のアーキテクチャの問題点について認め合い、目標となるゴールについての認識を一つにしなければいけない。

エンジニア個人としては、アーキテクチャが改善したことでどれくらい自分自身が成長し、仕事が楽になるのか感覚的に分かっていないと改善への第一歩を踏み出せない。

鶏と卵のような関係で、アーキテクチャの改善に必要なトレーニングを与えるのが先か、それともアーキテクチャの改善によるメリットを実感させることが先かは微妙なところだ。前者はメリットが実感できないと学習効果が上がらないし、後者はスキルがないとメリットを実感できないからだ。

日本でソフトウェアアーキテクチャ改善の話題がいまいち盛り上がらないのは、ソフトウェアアーキテクトの存在が組織内で認識されておらず、その職務が不明確で地位が確立していないからではないかと思う。建築業界では建築士という資格によってその地位が認められているが、ソフトウェアの世界では、そのような資格は存在しない。（資格があればいいってもんじゃないが）

ソフトウェアアーキテクチャを改善し、ソフトウェアコンポーネント間の関係がすっきりすると、開発は非常に楽になる。簡単に言えばソフトウェア資産に一切手を入れずにコンポーネントを再利用できるようになるから、資産の再利用のコストは限りなくゼロに近くなる。

かつて作ったソフトウェアの“流用”すると言っておきながら、新規にソフトウェアを開発するのと同じくらいの費用や期間がかかっていることに疑問を持つプロジェクトやクライアントの会社が少ないことに驚きを隠しきれない。ソフトウェアの再利用に成功したことが一度もないから、ソフトウェアはよく分からないが金がかかるものだと思っているのだ。

また、ソフトハウスの経営者としても再利用資産が増えることで工数が削減されることは利益の減少につながるから積極的にアーキテクチャ改善には動かない。しかし、それは発想を変えるべきで、ソフトウェアのアーキテクチャを改善し、再利用性が高まったら、その資産を利用して新たな派生製品を作り、そのアプリケーション開発のための仕事を受注すればよいのだ。前者の考え方は長期的な視点に立てば、コストダウンで開発費を縮小され、少人数で仕事量が増えるから悪循環に陥り、後者は資産の再利用により開発効率が高まるので長い目で見れば好循環につながる。

新しい技術を学びながら、自分のスキルと市場価値が向上し、開発効率が上がって、よりクリエイティブな仕事ができるようになるのに、なぜアーキテクチャの改善に積極的に踏む出そうとするソフトウェアエンジニアが少ないのか自分には理解できない。

その答えの一つは、自分や自分のプロジェクトが作成したソフトウェア再利用資産が他のプロジェクトや他の商品に利用されても、再利用できたことのメリットが表面にでてこないという現実がある。

どんなに自分自身が成長しても、その成果を自分の中だけにとどめておいたのでは自己満足に終わってしまう。組織に認められてこそ、組織貢献を果たすことができ、顧客への貢献につながる。

そんなこんなの問題が山積していることから、ソフトウェアアーキテクチャの改善は難しいのだ。

最後にソフトウェアエンジニアに言いたいのは、これからも続く長いソフトウェアエンジニアのキャリアパスを考えたときに、10年後、20年後に振り返ったら日々忙しくしていた自分しか見えないというのはあまりにも悲しくないかということだ。自分が組織に残したソフトウェア資産やアーキテクチャは「これだ」と言えるようになりたくないのか。一回やってみるとそのありがたみが分かるはずなのに、日々の忙しさを言い訳にして最初の一歩を踏み出せない技術者が多すぎる。

是正・予防駆動のプロセス改善アプローチ

ソフトウェアの開発をし商品に実装し、その商品を売って対価を得て、最終的にサラリーをもらう。ソフトウェアの一行一行の向こうには、そのソフトウェアを使うユーザー（お客様）がいる。それが医療機器などのクリティカルソフトウェアであった場合、そのソフトウェアは利用者の命を左右する可能性もある。

クリティカルでなくても、危険なエネルギーを制御したり、大切な情報を扱ったり、重要な設備を管理したりするソフトウェアもある。

ようするに職業としてソフトウェア開発に携わっている技術者はユーザーに対して何かしらの責務を負っている。これは、ソフトウェアがハードウェアと違うのは、Systematic Failures/Faults（決定論的原因故障/障害）と呼ばれる障害が多いことだ。Systematic Failures/Faults（決定論的原因故障/障害）は出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

故障や障害がランダムに発生せず、ある複雑な特定のシーケンスを実行すると必ず発生する故障や障害、それがSystematic Failures/Faults（決定論的原因故障/障害）だ。

Systematic Failures/Faults（決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去する。

そして日本人は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去のが苦手だ。

どちからというと、問題が発生した時点で修正し、個人個人が是正・予防する方が得意だ。だから、プロジェクトメンバーが入れ替わらなければ、是正・予防を繰り返すことで設計の規範が醸成され、そのプロジェクトからアウトプットされるソフトウェアの品質は徐々に上がっていく。

ところが、最近ではソフトウェアの開発をどんどんアウトソースしてしまうので、ソフトウェアの委託元では設計の規範どころか設計技術自体が醸成されないし、アウトソース先は人が入れ替わるため、是正・予防を繰り返す方法ではソフトウェアの品質は上がっていかない。

日本人が苦手な、Systematic Failures/Faults（決定論的原因故障/障害）をプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない。

しかし、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャなどは感覚だけは昔のままなので、気がついたら修正し、個人個人が是正・予防するマネージメント以外の成功体験がなく、プロセスアプローチによってソフトウェア品質が高まるというイメージがわかない。

その結果、Systematic Failures/Faults（決定論的原因故障/障害）は増加する一方で、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャはいらだつ。

これが今多くのソフトウェアプロジェクトが抱える悪循環の構図だ。

このままでは、ソフトウェアを使うユーザー（お客様）への責務が果たせない。ではどうすればいいか。

ひとつの解決策として、トップダウンでプロセスアプローチにシフトするのもいいが、日本人の得意な是正・予防で改善を進めるというのはどうだろうか。

問題が起こったら、関係者全員で問題が発生した原因を分析し、どうやったら予防できるのかを考える。これを進めていくと、当然のことながらソフトウェア開発の上流を改善しなければいけないことに気がつく。結局、プロセスアプローチを導入するという結論に至ると思うが、人から押しつけられるのではなく、改善の取り組みの中でプロセスマネージメントの重要性を学ぶ方が日本の技術者には合っていると思う。

問題が起こったときに、エンジニアを責めるのはたやすい。難しいのは問題の原因を分析し、是正、予防し、同じような問題が起こらないようなオペレーションを決断することだ。

結果を批判するだけの評論家はたくさんいるが、未来に起こるかもしれないリスクを皆に知らせ、プロジェクトを止めたり、方向を変えたりするには技術的な裏付けもいるし、何よりも勇気がいる。

ユーザーの顔を思い浮かべて、ユーザーリスクを防止するための決断ができる者こそ、プロジェクトのリーダーとなるべきだと思う。

事故の再発を防止する技術

3月8日の金曜スーパープライム「池上彰くんに教えたい10のニュース」のラストで3月一杯でTVの仕事から離れる池上彰氏が、「自分が生きている間にベルリンの壁が崩れるなどとは思っていなかった。チュニジアのデモからエジプトのムバラク大統領の退陣までこんなに早いとは思わなかった。時代の変化は早くなっている。今流れているニュースはいずれ歴史になる。そういう目でニュースを見なさい。」と言って去って行った。

3月8日は東日本大震災が起こる前だったから、想像もできなかっただろうが、まさに日本で流れているニュースは今後、歴史に刻まれることになる。

そう考えると、今、乗り越えなければならない問題の解決のプロセスは現在だけのことだけではなく、未来から見た歴史になるという意識で対峙しなければいけない。

品質マネージメントの観点から考えたときに、問題が起こったときに重要なのは、同じような問題が起こらないように予防と是正を行うことだ。

品質をマネージメントする技術者はCAPA （Corrective Action and Preventive Action：是正・予防措置）に注力を注がないといけない。問題が起きたときに犯人を見つけて責任を追及することは容易だが、再発防止の取り組みを築き上げるためには技術もいるし、組織的なマネージメントもいる。

再発防止を実現するためには、何よりもまして、同じ問題を起こしたくないという強い意志がエンジニアやマネージャになければいけない。

日々のビジネスシーンでは、QCD（Quality, Cost, Delivery）のうち、コストや納期が品質よりも優先される、優先しろという指示、圧力がかかることが少なくない。真の技術者は製品やサービスにおいて当たり前にできていることの技術、その品質を維持することの難しさをよく知っている。一方、製品やサービスを表面からしか見ていない者は当たり前にできていること＝潜在的な価値の重要性を常に意識することができない。

潜在的価値が意識されるのは、当たり前品質が当たり前でなくなったときだけだ。すなわち当たり前できているはずのことが、できなくなり故障、障害、事故が起きたときに当たり前品質の重要性と、その潜在的価値を支えている技術が十分出なかったことが分かる。

このときに、組織や社会が認識しなければいけないのは、当たり前にできていることの裏にある技術や、どんなリスクを想定し、どんなリスクコントロールをしているのか、していなかったのかというリスク分析である。そして、品質マネージメントのプロセスに従い、CAPA （Corrective Action and Preventive Action：是正・予防措置）を実施する。そのとき、技術者やマネージャは同じ故障、障害、事故を起こさないという強い意志を持たなければいけない。

エンジニアは事態の収拾でホッとするのではなく、再発防止の取り組みに力を注ぎ、組織はQCD（Quality, Cost, Delivery）の Quality を軽視しない、コストや納期を優先させて品質への意識を忘れてはいけないことを心に誓う必要がある。

実際には、Quality, Cost, Delivery の間にはトレードオフの関係があることが多い。納期やコストを優先させると品質が低下する可能性は高い。しかし、技術力によって QCDのバランスを確保することは可能だ。

例えば、商品群のコアとなるソフトウェア資産を抽出し再利用可能な管理ができれば、品質とコストと納期の要求を満たすことはできる。ソフトウェアプロダクトラインの技術だ。このとき、医療機器などのクリティカルデバイスにおいては、機器を取り巻くリスクに対して、そのリスクを受容可能なレベルまで引き下げるリスコントロール手段（設計上の対策）がコア資産に含まれいるとなお、その資産価値は高まる。（コア資産の顕在的価値と潜在的価値の両方を含めることができるとなお良い）

そのソフトウェア資産の安全性や信頼性を高めることに注力を注ぎ、その後何世代にも渡ってコア資産を再利用することができれば、QCD の要求を同時に満たすことができる。

クリティカルデバイスの開発は、失敗や事故との闘いであるとも言える。失敗や事故を再発されないためのノウハウを製品につぎ込み続けることが当たり前品質を高めることにつながる。だから、新規参入が難しいとも言える。ただし、大規模複雑化したソフトウェアの場合、単純に安全装置としてのソフトウェアを追加し続けると、これまで正常に動いていたシステムをデグレードさせてしまうこともあるから注意が必要だ。

ハザードやリスクがどう変化したのか、見落としていたのかを再評価し、リスクコントロール手段を要求としてとらえ、実現するアーキテクチャを設計する。日本人はこの設計上流の分析や設計がとても苦手に見える。試行錯誤で付け足しや修正をするのは得意だが、上流に立ち戻って再設計するのは下手だ。

障害や事故を再発されないという強い気持ちとリスク分析、リスクコントロールのアーキテクチャ設計ができないとないと、障害や事故はまた起こる。気持ちだけでもダメだし、技術力がなくてもダメだ。

そして、是正・予防措置は、気持ちだけでは進まない、組織に品質マネージメントを仕組みを根付かせ、日々前向きな気持ちで回していなければできるものではない。

そして、ジャーナリズムにお願いしたいのは、障害や事故が起きたとき、その後組織が再発防止の取り組みを続けているかどうかを監視することと、今は起こっていないが何かあったら大変なことになる社会インフラ、重要デバイスに問題が起こったらどうなるのかという視点を持ってもらうことだ。

何か起こってから追求するのは誰でもできるが、これから起こるかもしれない障害、事故を防ぐためには経験や知識、幅広い視点が必要になる。ジャーナリズムには事故を未然に防ぐ技術やマネージメントについての報道を期待したい。

プリウスブレーキ制御ソフト改変についての考察（再考）

日経ものづくりはソフトウェアには関係ないと思っている人も日経ものづくり8月号は単品(1400円）でも買った方がよい。

なぜなら、プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。

詳しくは 日経ものづくり8月号の特集記事『ソフトが揺さぶる製品安全』を読んでいただくとして、この記事のコラム「プリウスに見る、ソフトの落とし穴」の感想を書いてみたい。

まず、このブログの『プリウスブレーキ制御ソフト改変についての考察』の記事でも書いたように、何しろプリウスのブレーキシステムは非常に複雑だ。

これはプリウスだからではなく、現在のハイブリッド車はみな、このように複雑な制御でブレーキの機能や性能を実現しているのだと思う。

何が複雑化というとざっとこんなところだ。

• そもそもブレーキペダルを踏むとブレーキオイルの圧力が伝達されブレーキパッドを押し当てると思ったら大間違い。ブレーキペダルとブレーキパッドの間にはさまざまな構造物が間に入っている。
• ブレーキペダルを踏むとピストンのような油圧ブースターを押すような構造になっている。
• ピストンも密閉されているのではなく、リザーバタンクからブレーキオイルが補給されるようになっており、アキュームレータとポンプが接続されていて、ブレーキの圧力をモータとポンプの制御で高めることができる。
• ブレーキオイルの圧力はストローク・シミュレータに送られて、ここでドライバが要求する制動力とペダルに対する反力を計算している。
• ようするにドライバがあたかも、ブレーキペダルとブレーキパッドが直につながっているような感覚になるように、油圧を制御しているのだ。
• 強く踏めばブレーキは強く効き、弱く踏めば弱く効く。そこにタイムラグ（例えば0.5秒）があればドライバは強い違和感を感じるので、ハードリアルタイムの制御が必要となる。

日経ものづくりに掲載されているプリウスのブレーキシステムの構造図を眺めていると、ブレーキががこんなに複雑な構造になっていることに恐ろしさを感じる。車メーカーに全幅の信頼を寄せられなければ恐くて車には乗ってられない。個人的には、電気自動車の時代になっても新規参入してきた会社の車には10年間は乗りたくないと思う。それくらいソフトウェア制御が絡む複雑なブレーキシステムにはノウハウがないと危ないと直感する。

さて、プリウスのブレーキ問題は低速走行で緩やかに減速しているときにアンチロック・ブレーキ・システム(ABS）が動作すると、一瞬制動力が低下し、その結果、制動距離が延びる、または、運転手がペダルを踏み増さなければいけないという問題だった。

この問題が起こった流れを書くと次のようになる。

【新型プリウスのブレーキ問題が起こった背景】

1. プリウスは燃費を稼ぐために回生ブレーキを利用しジェネレータを回して発電する。（エンジンブレーキのようなもの）
2. しかし、回生ブレーキの制動力は弱いので、油圧によって制動力を足してやらなければいけない。（だから、構造が複雑になり、制御も複雑になる）
3. やっていることは超複雑なのに、ドライバには違和感を感じさせないように繊細な制御をすることが要求される。
4. ABSが作動するときは、回生ブレーキは使わずに油圧ブレーキだけで制動力を確保する。（回生ブレーキでは断続的なブレーキングは不得意だから）
5. ABSが作動するときは、ブレーキの油圧の供給方法を切り換えてドライバーが踏んだペダルの油圧を使うようにしている。
6. 先代プリウスではペダル油圧ではなくモーターとポンプで作り出すアキュームレータ油圧を使っている。（新型プリウスのブレーキ問題の後トヨタはペダル油圧から先代プリウスで実績のあるアキュームレータ油圧に制御を変えている）
7. なぜ、先代プリウスではアキュームレータ油圧を使っていたのに、新型プリウスではペダル油圧に変えたのか？
8. それは、ブレーキングの際に増圧デューティ制御弁から生じる騒音・振動を低減させようとしたからでもある。（先代プリウスでは高価な増圧リニア制御弁を各車輪ごとに使っていたが、新型プリウスではコストダウンのために安価だがノイズの大きい増圧デューティ制御弁に一部変更している）
9. 先代プリウスに比べて新型プリウスではペダル油圧の特性が強化されており、モーターとポンプを使わなくても、ペダルの踏み力でブレーキを動作させやすくなった。
10. これは、先代プリウスでは電源が故障するとブレーキが効かなくなるときの対策として予備電源のキャパシタを載せていたが、新型プリウスではこのキャパシタもなくしてコストダウンをはかり、電源が壊れていてもペダル油圧だけで制動できるようにした。（電源が死んだときは、ドライバの踏み力でブレーキを作動させやすくなった。）
11. そして、ABS動作時にアキュームレータ油圧を使うと増圧デューティ制御弁から発生する騒音や振動が目立つ（らしい）。（たぶん、ディーティ型は弁をパタパタさせる周期を変えることで制御をしているのでそのパタパタがうるさいのだろう）
12. この微妙な乗り心地感を向上させるために、改善したペダル油圧を使うように制御メカニズム（ECUのソフトウェア）を変更した。
13. ところが、低速で減速しているときのペダル油圧はアキュームレータ油圧よりも若干低い。（そこに落とし穴があった）
14. この差がドライバに微妙な「スカッ」という抜け感を生じさせてしまった。

ブレーキ制御ソフトの改変後、ABS動作時の制御をアキュームレータ油圧に戻したことから、騒音・振動は大した問題ではなかったのだと想像できる。

99.8% の満足度を 99.9% にするというトヨタの0.1%のコストダウン、乗り心地の改善が、結果的にブレーキシステムという基本性能に問題を発生させてしまった。

コストダウンや乗り心地のよさを追求した結果、すべての機能・性能に問題がないことを精査しきれないほどシステムが複雑になってしまったといえるのではないだろうか。

不具合が発生するメカニズムは分かってしまえば簡単だが、誰かから指摘される前にこのような問題を見つけるのは至難の業だ。特に複雑なシステムでは難しい。だから、メカもエレキもソフトもできるだけシンプルな構造（アーキテクチャ）を採用した方が安全面では有利だ。

シンプルであればあるほど、テストの網羅性を高めるととができる。妥当性を確認するために時間をかければかけただけの安心につながる。しかし、システムを複雑にすると、テストのカバレッジはいつまでたっても100%になならず、妥当性確認の時間は無限に必要になる。

このような　Systematic Failure を防ぐには個別最適の発想ではだめで、全体最適の発想が必要だ。

【日経ものづくり 2010年8月号 p39 図3 製品安全の方針より 引用】

明治大学理工学部情報科学科教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いといいう。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障やバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だという。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは、難しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

ソフトによって「信頼性≒安全」という認識は崩れつつある。ある意味では、本質的な安全に取り組む上で良い機会といえる。そこで重要になるのが「フェイルセーフ」や「フォールト・トレランス」といった概念だ。

フェイルセーフは、構成要素に故障やバグがあっても、安全側に落ち着くようにする設計である。例えば鉄道の踏み切りでは、遮断棒を支持する機構に何らかの故障が発生すれば、遮断棒が自重で落ちてくる。このとき、人や自動車は必要以上に足止めされるので信頼性という点では低下しているが、安全は確保できている。このように信頼性を犠牲にしてでも安全を最優先にするのがフェイルセーフとである。

ただし、製品や使用状況によって、明確な安全状態が存在しなかったり、コストなどの制約でフェイルセーフを盛り込めなかったりすることがある。その場合は、冗長化や多重化といったフォールト・トレランスを検討する。フォールト・トレランスは、信頼性を高めて昨日の継続を目指すという意味ではフォールト・アボイダンスと同じだが、欠陥やバグの存在を前提としている点が決定的に異なる。

構成要素ごとに信頼性を高めることが可能なフォールト・アボイダンスに対し、フェイルセーフやフォールト・トレランスは製品全体（システム）やサブシステムといった、大きな視点で見なければ実現できない。それには、製品開発の在り方を大幅に見直す必要がある。

【引用終わり】

日本のリスク分析の大家である向殿先生の主張が、アメリカの安全設計の大家であるナンシー・レブソン教授と根底でつながっているのはとても興味深い。

「日本の製造業は、欧米で確立された製品の改良設計で成長してきた」というくだりは、まさに目から鱗が落ちた。「だから全体最適や安全アーキテクチャの話しが通じないんだ」と思い当たるふしがある。日本の製造業の歴史的要因があるとなると、根が深いので安全アーキテクチャをシステム開発の上流で分析させるためには、攻め方を変えなければいけない。

全体最適の発想で安全アーキテクチャを考えなければ、どんなにがんばっても大きな問題を抑えきれない時代はすぐそこまで来ている。

ジョン・コッターの企業変革ノート

ソフトウェアに関する改善活動を行っていると、テクニカルなことでは解決できないことにすぐにぶつかる。そこでいろいろなことを試してみるのだが、つい最近『ジョン・コッターの企業変革ノート』 という本に出会った。久しぶりに付箋を手にしながら読んでいる。

この本に書いてあることは至極納得できるし、ここ数年自分がやってきたことにも重なるし、この通りにやってみようかなと思わせる。

『ジョン・コッターの企業変革ノート』のソリューションがうまくいきそうと思わせるには理由がある。この本の教訓は130もの組織の400名あまりの面談から得た情報（成功体験、失敗体験）から体系化されたものであるからだ。そもそも、ヒアリングの対象はアメリカの会社だろうから、そのまま日本の組織に使えないかもしれないが、日本人とアメリカ人の違いの奥にある人間としての共通項に響く部分も多々あると感じている。

まずは、紹介されている多数のエピソードのうちの一つを見ていただきたい。

【『ジョン・コッターの企業変革ノート』 －怒れる顧客を映したビデオ－ より引用】

■怒れる顧客を映したビデオ　　ティム・ウォラス

ある日、日頃の取引に感謝して得意先を夕食に招待した。当社の主力商品が話題になったところで、納品後に手直しを余儀なくされたと先方がこぼした。この製品は受注生産なので、おかしな話しだ。手直しには時間とカネがかかる。快く思っていないのは当然だ。

私は丁重に詫び、チームを組んでこの問題に早急に対処すると申し出た。誠意は伝わったはずだが、感動している様子はない。「この問題を御社の担当者に一度も話したことがないわけではありません。こちらの言うことは耳を貸してくれないのです」。先方の説明によれば、変更が必要な箇所を見つけたり、変更の方法を説明したりした時には、要求通りにするが、数週間後には元に戻っていると言う。「われわれは変更を何度もお願いしました。担当の方はうなずきはするものの、聞く耳を持たないようです」

この顧客から直接、話を聞いた人間は社内でもごく一握りだろう。しかも、この夕食の時ほど怒っているのは知らないだろう、とわたしは思った。そこで翌日、部下を出向かせるのでビデオで苦情を撮らせてもらえないかと打診した。先方は躊躇したが、わたしは真剣であり、お互いのためになるはずだと説明した。話し合いを重ねた結果、先方は少々、注文をつけたうえで、ビデオを撮ることを承諾してくれた。
翌日、数人の部下がビデオカメラを持って先方を訪ねた。すべてありのまま、包み隠さず喋ってほしいと頼んだところ、概ね、その通りにしてくれた。30分間収録したビデオは若干編集し、15分にまとめた。

工場の会議室に50人あまりの従業員を集めた。画面には、怒れる顧客が映し出された。従業員の反応は興味深いものだった。大半はただただ驚いているようだった。あまり顧客と接したことがなく、こうした強烈で否定的な声を聞いた経験がないのだろう。これは特殊なケースだと思った者もいたようだが、それでも画面に釘付けだった。ぽかんと口を開けている者もいる。当然ながら、顧客の方が間違っていると思う者もいた。「わかっていない」。「教えてやらなければいけない」「その理由は・・・」と口にする。だが、それは少数派だった。

ビデオ上映後、この問題をいかに解決するか、再発を防いで顧客に満足してもらうには何をすべきかを話し合った。次々とアイデアが飛び出した。もちろん、現実的でないものもあった。だが、話し合いは有意義だった。

このビデオは合計で400人あまりの従業員に見せた。ここでも少数ながら、自分が正しいと主張する者がいた。だが、同じ数だけ、「なんとかしなければ。対策を講じなければならない」と言う者がいた。自分たちの非を認めなかった者も、その後は工場に招いた顧客の声にもっと耳を傾けるようになったと思う。

ビデオはその後も撮り続けた。コストはほとんどかからない。これで問題がすべて解決できるわけではないが、改善を妨げる深刻な壁を取り払うのに役立った。この工場はもともと、当社が買収した企業のものだった。その企業は長らく業界をリードする立場にあったため、従業員は自分たちを万能だと考えていたのだろう。たしかに専門知識があり、仕事をよく知っている。だが、顧客を重視していなかった。「言いたいことはわかったから、仕事の邪魔をしないでくれ。われわれはプロで、あなたがたは邪魔でしかないことをわかっちゃいない」という態度をとっていたのだ。こうした態度では、行動を起こし、顧客のニーズに応えることができない。

【引用終わり】

この事例を見て「ああ、これをやってみたい」という衝動に駆られた。顧客満足を高めることは組織の誰もが考える共通の価値だ。だから、この価値を立脚して改善を促すことは正しいし、これまでもそうしてきた。しかし、ロジカルにテクニカルに責めるよりも、「見て、感じて、変化する」というアプローチの方が確実に効果があることを思い知らされた。

ソフトウェアは見えにくいから、この例よりもずっと「問題を見せて、感じさせる」のは難しいが、それができなければ変革は起きないというのは、その通りだという実感がある。

『ジョン・コッターの企業変革ノート』では、変革を成功に導くにはつぎに紹介する8段階を経る必要があると説いてる。第1段階の危機意識を高めるは、霊感商法のような感じもするが、でも、よく考えてみれば危機意識を共有できずに変革などできるはずもない。危機意識を高めるには、誠実な気持ちで本当の解決すべき問題を見せなければいけない。

【『ジョン・コッターの企業変革ノート』 The Heart of Change より引用】

＜大規模な変革を成功に導く8段階＞

■第1段階　「危機意識を高める」

大企業であろうと非営利の端末グループであとうろと、大規模な変革に成功した人びととはまず、関係者の間に「危機意識」を生み出している。ここでいう「関係者」とは、小規模な組織なら5人ではなく100人に、大規模な組織なら50人ではなく1000人に近いはずである。変革が順調に進まなかった事例では、変革リーダーが、5人あるいは50人を目標にするか1人も目標としておらず、現状満足や不安や怒りなど、ほぼ必ず起こる感情・・・変革の足かせとなる感情を容認してしまう。ときに創造的な手段で危機意識を喚起すれば、関係者がソファから跳び上がり、安全地帯から飛び出して、動き出す用意をする。

■第2段階　「変革推進チームをつくる」

危機意識が高まれば、変革の旗手を集め、変革の主導に必要な信頼、スキル、人脈、評判、権限を備えた変革チームをつくる。変革チームは、互いに信頼し、熱意を持って結束して行動する。変革が順調に進まなかった事例では、一人だけに頼ったり、誰も主導しなかったり、タスクフォースや委員会に力がなかったり、複雑な管理体制を築いたりしており、いずれに場合も変革を主導できるだけの地位やスキル、力が欠けている。タスクフォースをつくったものの、変革を生み出すだけの力がないために失敗した事例はきわめて多い。

■第3段階　「適切なビジョンを掲げる」

変革に成功した事例では、変革推進チームが、賢明で簡明で心躍るビジョンや戦略を策定している。変革がそれほど順調に進まなかった事例では、詳細な計画や予算だけを策定している。これらも必要であるが、それだけでは十分ではない。世界市場の動向や自社の状況にそぐわないビジョンを策定している場合もある。変革に失敗した事例では、戦略の動きが鈍く、慎重すぎて、激しく変化する世界にそぐわないものになっている。

■第4段階　「ビジョンを周知徹底する」

次ぎにビジョンや戦略を周知徹底する。シンプルで琴線にふれるメッセージを情報の溢れていない、いくつものチャネルを通して伝える。その目的は、成果を出すのに十分な数の人たちの理解を促し、やる気を引き出し、エネルギーを解放することにある。ここでは言葉よりも行動が重要になる。シンボルの効果は大きい。繰り返しも重要である。変革が順調に進まなかった事例では、効果的なコミュニケーションが不足していたり、下手だったりするが、そのことに気づかない場合が多い。

■第5段階　「自発的な行動を促す」

変革に成功した事例では、自発的に行動する人が増える。ビジョンに基づく行動を妨げていた大きな障害が取り除かれる。変革リーダーが特に重視するのは、部下のやる気をくじく上司の情報の不足、情報システムの不備、各人の心のなかにある自信というカベ、といった障害である。重要なのは、「権限を与えること」ではなく、障害を取り除くことである。権限は袋に入れて渡せるようなものではない。変革が順調に進まなかった事例では、権限を与えられた従業員は、障害だらけのなかで独力で突き進むように求められる。そのため苛立ちが募り、変革は行き詰まる。

■第6段階　「短期的な成果を実現する」

変革に成功した事例では自主性を持った人びとがビジョンに基づいて動くようになると、短期的な成果を生み出す。成果は欠かせないものである。成果が上がれば、変革が信頼され、資源が与えられ、勢いがつく。変革が順調に進まなかった事例では、成果が出るのが遅く、目に見えにくく、価値感に訴えず、成果であるかどうかもはっきりしていない。変革プロセスの管理が不適切で、最初に着手すべきプロジェクトが慎重に選択されず、早い段階で成果が上がらなければ、皮肉屋や懐疑的な者によって変革はつぶされる。

■第7段階　「気を緩めない」

変革に成功した事例では、変革リーダーはさらなる変革を推し進める。最初の成果が上がると、変革に勢いがつく。当初の変革が定着する。次ぎにどんな問題を克服するかを賢明に選択し、変革の波を次々と起こしてビジョンを実現する。変革が順調に進まなかった事例では、多くのことに一度に手をつけようとする。無意識に気を緩める。変革の勢いは衰え、絶望的なほど深みにはまる。

■第8段階　「変革を根づかせる」

変革に成功した事例では、各階層の変革リーダーが、新しい文化を育てることによって変革を根づかせている。新しい文化とは、ある集団で共有される行動規範や価値感であり、成果を生み出す行動が十分な期間続くことによって育まれる。ここでは適切な昇進人事を行ったり、新規採用者向けオリエンテーションを工夫したり、心を動かすイベントを行ったりすることによって違いが生まれる。それ以外の事例では、変革はもろく、表面的なものにとどまっている。伝統という風が吹けば、驚くほど短期間に、それまでの膨大な努力は吹き飛ばされる。

【引用終わり】

ジョン・コッターはハーバード・ビジネス・スクールで教鞭をとっているから、アメリカでは The Heart of Change について学べるということだ。日本ではどこで教えているのだろうか。また、日本の教育の中で、このような変革のメソッドをひとかけらでも教えているだろうかと考えてしまう。

小規模でも中規模でも何とかこの8段階をやり遂げて変革を起こしてみたいと思った。

問題解決の方法を100パターン作っておかないと動けない人材

今、組織が欲しい人材は、目的を示すことで自分の持ち駒（経験）を組み合わせて実現する方法を見つけ出すことができる人だ。

その対極に具体的な手順を示さないと動けない人がいる。例えば、目的はひとつ、工程が2つあって、それぞれの工程内での活動の選選択肢が10パターンずつあったら、サンプルのパターンを一つか二つ例示するのではだめで、今自分が置かれている立場にぴったり合う10×10=100のパターンの中から最も近い一つを示せと言われてしまうケースだ。

その程度はまちまちで、いくつかのケーススタディをするだけで済む場合もあれば、手取り足取り手順を示さないと動けない場合もある。

問題解決能力が高い人は、経験値が低くても工程を何回か繰り返すうちに具体的な手順から抽象度の高い解決方法を体系化することができる。

だから、組織は問題解決能力の高い人材が欲しい。

【1. 問題解決能力を身に付ける方法】

1. 達成すべき目的や要求を伝え「なぜ」も含めて合意する
2. 集中できる環境だけ用意して解決方法は示さない
3. 定期的に進捗を報告させてアドバイスを与える
4. 成果を当事者以外（一番いいのは要求を出した人）に評価してもらう
5. 2～4を何周か繰り返す

※たぶん、これがよく言う PBL(Project Based Learning/Problem Based Learning）なのだろう。

【2. 問題解決能力の低い人の学習環境（予想）】

1. 問題が指定される
2. 解決するために必要とされる一般的な知識を教わる
3. 試しに一つの解決方法を教わる
4. 複数の問題を解かせる
5. 採点して落第だった場合は補習をする

※この学習方法で訓練されると、そのパターンで解けない問題がくると最初から解けないと「問題」と「ソリューション」は一対一だと決めつけられてしまい、ぴったりくる解決方法が記憶の引き出しにないとさじを投げられてしまう。

問題解決能力があるかないかを判断するには、答えのない問題を実際に解決してみてもらえばすぐに分かる。

2の学習方法しかやってこなかった人は比較的早くあきらめて、解決方法を教えてもらえるまで指示を待つ。1の訓練を受けている人は、少なくとも解決方法の提案をレビューしてくれといってくる。自信があるものは問題解決に着手する。

Process （工程）を Activity （活動）や Task（仕事）に分解して Procedure（手順）に落とし込むというアプローチは問題解決能力が低い人にも成果を期待できる反面、不測の事態への対応が十分にできない。手順になれてしまうと、手順から逸脱する行為は悪と見なされる。

同じ品質のものを効率的に生産しなければいけない工場の生産ラインはこの方法でよい。製品ごとに手順は変わるので、工場の中でも手順を作る側の人は問題解決能力が高くないといけない。

商品を作る側の技術者は、新しいものを創造するのだから、不測の事態への対応能力は高くないとまずい。ただ、もしかすると要求仕様が固まった後のコーディングだけを行うプログラマの場合は、手順通りに手を動かしていればいいのかもしれないが、一生その仕事ではたまらないだろう。

技術者はProcess （工程）を、分解された Activity （活動）や Task（仕事）を Procedure（手順）に従って開発を進めることが求められる一方で、不測の事態、変化しなければいけない状況下では、Process や Activity, Task を柔軟に変更できる能力も求められている。

P.S.

日本の組織では「強くお願い」と「強制」の垣根がないと思うことがしばしばある。「強制」とはそれに従わなければクビということだが、日本の組織ではそれはないし、「ヤレ」と言われてやらないで、何もとがめられないこともある。それが「あたたかい人間関係の中のやさしい一員」という特性だ。

そういう環境下では「強くお願い」と「強制」の垣根がないので、権限がなくても「強くお願い」すれば、それを義務ととらえる者が多い。「何の権限があってそんなことを要求するのか」なんてことを言う人を見たことがない。

たぶん、普段から自分の責務もあいまいしているから、それを言ってしまうと自分に返ってきてしまうからだろう。

責任と権限が曖昧な日本の組織では頭ごなしに「強制」するのではなく、徹底的に「強くお願い」するのが効果的だと感じる。どっちもやることは同じなんだけどね。

ようするに誰かに言われて動いたという形になっていた方が安心して行動できるということ。（それって責任回避の心理？）

自動化がいつも優れていると思ったら大間違い

我が家の冷蔵庫の自動製氷機が数ヶ月前に壊れた。もう7年も使っているから壊れても不思議ではない。一通り調べてみたがどこが悪いのか分からなかったのであきらめて使わないことにした。

持ち運びできる家電なら修理に出す選択肢もあったが冷蔵庫ではそうはいかない。サービスマンを呼べばそれなりに修理代もかかる。

氷は必要なので昔ながらの氷の型枠を使って手動で作ることにした。型枠は100円ショップで2個買った。そうしたら、いっぺんに42個の氷ができる。

冷蔵庫の自動製氷機はタンクに水を入れておくと型枠に水が流れ、氷ができると型枠が回転して落ちるのだか、この方式よりも手動方式の方がはるかに短時間にかつ大量に氷ができる。

慣れとは恐ろしいものだ。自動でできているとそれが最善の方法な錯覚に陥る。氷を作る手順は自動製氷機も手動でやるのも実は全く同じだから、急いで氷が欲しいときは手動でやればよかったのに急速製氷モードに設定してイライラしながら「早くできないかな」と待っていた。

冷蔵庫の自動製氷機はタンクに水を入れておくしくみになっており、説明書には二週間に一回はタンクを掃除するように書いてある。実際一ヶ月ぐらい放っておくとちょっとぬるっとしたものがタンクの中に付くようになる。一方手動の場合は常にフレッシュな水を水道から注ぐから、定期的に洗うべきタンクがない。

自動製氷機が壊れたおかげで手動で氷を作るメリットが改めてわかった。

このできごとに似たことをソフトウェア開発にあることをふと思いついた。それは、たまにソフトウェアのテストを自動化したいので、いいツールはないかと相談を受けるときのことだ。

そういうときは、半自動でいいから少し時間がかかっても自分自身でテストをやりきってみなさいとアドバイスする。何人かは、その時点で先に進むことをやめ、何人かは自分でやってみて「ああ、自分でできるじゃないか」と気づきツールが欲しいとはいわなくなる。

前者は本当にテストを自動化したいのではない。自分がやるべき検証の作業をツールという他人にやらせて自分の責務を回避したいだけなのだ。そのような技術者は「自分で作ったプログラムのバグを自分で見つけることはできない」などとのたまう。そんなことはない。それを言うのなら「自分はカバレッジの高いテストの技法、バグが入り込みにくい設計のスキルを持ち合わせていないので、それらの技術を教えて下さい」と言いなさいと言いたい。

テストツールは（期待どおりの）テストケースを自動には作ってくれない。効率的なテストをやりたいのならテストケースは設計しなければいけない。テストツールは一度作ったテストケースのセットを自動で通すことはできる。また、テストツールを使わなくても自動で自分の作ったテストケースを自動で通す仕組みは作れる。

だから、テストの自動化を実現する前には多くの場合手動で一通りのテストを通す作業は必要になる。何回も同じテストを通さなくてもいい場合は、手動のテストをできるだけ効率的に実施する方法を考えた方がいい。

自動化がいつも優れていると思ったら大間違い、そんなことを自動製氷機の故障がきっかけで思い出した。また、エンジニアなら自動でできていることのしくみはどうなっているのだろうと考える習慣をつけないといけないとも思った。それが分かるようになると、どうやったらもっとうまくできるか見えるようになる。

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

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

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

【レクサスホームページより引用】

レクサスLS460、600hのお客様へのお詫びとお願い

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

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

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

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

2010年5月19日
トヨタ自動車株式会社

【引用終わり】

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

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

【『トヨタ：レクサスをリコールへ　信頼回復途上に痛手　イメージ低下、不可避』 毎日jp より引用】

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

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

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

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

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

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

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■ことば

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

【引用終わり】

断片的に次のような情報も流れている。

トヨタは昨秋、VGRSの制御プログラムを変更。その際に不具合を把握していたが、「安全性には問題がない」として取り扱い説明書への記載で済ませた。しかし、今年3月以降、トヨタに対して12件の苦情が寄せられた。

トヨタ幹部によると、ハンドルが一時的に戻りすぎるのは機構上の特性で、説明書に注意書きも入れていた。しかし「対象の車は戻り方が極端で、顧客に不安を与えてしまった。より運転しやすくするために昨年秋の一部改良でプログラムを変更したことが裏目に出た」と説明している。

「運転しやすくするため、モデルチェンジにあわせてプログラムを改良したのだが…」。トヨタのある幹部は、電子制御の改良が、リコールにつながったことを嘆いた。同時に「機構上の特性」としたことに対する悔恨もにじんだ。

このような情報を総合すると、次のような経緯があったのではないかと予測される。

【レクサスのパワーステアリング問題発生の経緯（予測）】

1. メルセデス・ベンツなどに対抗するため、トヨタは低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動き駐車やＵターン時の操作を容易にし、一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能「ギア比可変ステアリングシステム（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）のポイント>

• 低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やＵターン時の操作を容易にする。
• 一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。
• レクサスやクラウン、マーク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）を読むとよいと思う。

組込み開発現場のプロジェクトマネジメント＆プロセス改善

『組込み開発現場のプロジェクトマネジメント＆プロセス改善』を読んだ。この本は以下の6つのパート＆著者から構成されている。

■Part 1 新人管理者のためのマネジメントの基礎知識
著者：井上 樹(いのうえ たつき)
(株)豆蔵にて組込ソフトウエアを中心にオブジェクト指向/UMLの導入、プロセス改善等に関する教育、コンサルティングを担当。最近はモデルを活用したシステムエンジニアリングに注目中。

■Part 2 現場が共鳴する開発環境の姿
著者：杉浦 英樹(すぎうら ひでき)
1986年、富士ゼロックス(株)に入社。以来、複写機の組込みソフトウェア開発を担当。複数のドメインを複数のパラダイムで開発。開発現場の問題のほとんどが、コミュニケーションに起因し、真の管理の重要性を痛感。SESSAMEメンバー。

■Part 3 実践的プロジェクト計画の立て方
著者：竹山 寛(たけやま ひろし)
ビジネスモデル構築、ソフトウェア開発プロセス、プロジェクト推進支援、品質管理、プロジェクト管理、開発工程管理、セミナーなどITコンサルタントを手がける。著書に『管理者になって困らない[実践的]ソフトウェア開発工程管理』(技術評論社)がある。

■Part 4 プロセス改善のススメ
著者：玉木 裕二(たまき ゆうじ)
(株)東芝 ソフトウェア技術センター所属。入社以来十数年、社内のソフトウェア開発部門各所に、アーキテクチャ設計提案、プロセス整備やインフラ整備、コーディングやデバッグなど、いろいろな立場で関わってきた。それなりに知見も増えてきたけれど、まだまだ足らないと実感する毎日。

著者：荒見 美香子(あらみ みかこ)
(株)東芝 ソフトウェア技術センター所属。十年以上に渡り、CMM/CMMIなどのモデルを活用したプロセス改善活動に従事。社内のソフトウェア開発部門への改善コンサルに奔走しつつ、効果的な進め方を模索中。最近は、社内のプロセス資産化やインフラ整備に注力。

■Part 5 勘違いだらけのプロセス改善
著者：杉本 恭子(すぎもと きょうこ)
横河ディジタルコンピュータ(株)所属。最初の仕事はソフトウェアプログラマ。その後開発ツールベンダのテクニカルサポートやマーケティングを経て、現在はプロセス改善関連の企画営業を担当。日々、お客様の生の声やお困りごとに接し、支援部隊への橋渡しをしている。

■Part 6 プロダクトラインの歩き方
著者：今関 剛(いまぜき たけし)
(株)ビズモ コンサルティング部所属。日ごろから開発現場でオブジェクト指向やプロセス改善の指導をしているが、解決方法やツールを利用することが目的化して玉砕しているところが多いと感じる今日この頃。現在は、アーキテクチャリファクタリング、テスティング、モデリングを組み合わせ、人材や既存資産の能力をうまく引き出しながら、全体最適の視点に立った再利用型ソフトウェア開発を目指す。IEEE、SEA、SESSAME、EEBOFメンバー。

※プロフィールは掲載当時のものです。

見ていただければわかるように、それぞれのパートは技術評論社の『組込みプレス』に掲載されたプロジェクトマネジメント・プロセス改善に関係する記事（Part6 は再利用戦略の内容）であり、本書はこれらの個別の記事を集約している。

それぞれのパートのキーワードを拾ってみよう。

■Part 1 新人管理者のためのマネジメントの基礎知識

• QCD(Quality:品質、Cost:予算、Delivery:納期)
• PDS(Plan:計画→Do:実行→See:評価)　PDCAよりもわかりやすいPDSで説明しているとのこと。
• SWEBOK(Software Engineering Body Of Knowledge)
• PMBOK(Project Management Body Of Knowledge)
• CMMI(Capability Maturity Model Integration)
• モチベーション管理
• コミュニケーション管理

■Part 2 現場が共鳴する開発環境の姿

• ブルーオーシャン戦略
• 変化に取り残される開発現場
• どうしても人に依存してしまう開発現場
• 開発技術の退行
• PDCA(Plane-Do-Check-Action)の不在
• 改善/改革できない理由（非技術的要素、人的要素）
• 実践的な開発管理のヒント
• CMMIやPMBOKが目的ではない
• 現場中心の管理スタイル
• 改善するための具体的なヒント
• 開発者の気づきをどう促進するか

■Part 3 実践的プロジェクト計画の立て方

• プロジェクトマネジメントの失敗要因
• ソフトウェア開発の階層構造
• プロジェクトマネジメント作業の進め方
• アローダイアグラムによるプロジェクト計画の立て方
• アローダイアグラムの作成
• アロー代打グラムでの進捗管理

■Part 4 プロセス改善のススメ

• 混乱する現場
• スケジュールの逼迫（ひっぱく）
• 変わりやすい要求仕様
• 改造の繰り返し
• 外部リソース依存
• 不透明な進捗
• 混乱を抑えるのに有効な技術
• UML(Unified Modeling Language), MDA(Model Driven Architecture)
• リファクタリング
• CMM
• ソフトウェアプロセスとその改善活動
• ソフトウェアアーキテクチャとプロセス改善
• 改善事例（基本仕様書の標準化、単体テストの改善、構成管理の改善）
• 改善活動を推進する方のためのヒント
• プロジェクトの中に改善リーダーを見つける
• ときにはプロジェクトの開発者として作業を請け負う

■Part 5 勘違いだらけのプロセス改善

• プロセス改善とは何か
• いつから始めたらよいか
• どこから始めたらよいか
• CMM/CMMIを参考にする
• CMM/CMMIの上手な使い方
• プロセス改善の勘違いと落とし穴
• たちまち仕事が楽になる？
• たちまち工数が削減される？
• 目に見えて生産性が向上する？
• 教育と実践、どちらが先か？
• 身の丈に合ったプロセス改善
• プロセス改善は活動し続けるもの
• 外部から見てもらう
• 改善は組織全体の取り組み

■Part 6 プロダクトラインの歩き方

• どうしてプロダクトラインなのか？
• なぜ再利用が進まないのか？
• コア資産開発
• アーキテクチャ定義
• コンポーネント開発
• COTS(Commercial Off-The-Shelf ：市販ソフトウェア製品）の利用
• 既存資産の発掘
• 要求エンジニアリング
• テスト
• 構成管理
• デザインパターン
• 統合運営パターン
• 商品開発パターン
• 資産確立パターン
• コールドスタートパターン
• プロセスパターン
• プロダクトラインとCMMI
• 何をもってプロダクトラインと言えるのか？

キーワードを見てもらえばわかるようにテーマは似たようなところにあっても、それぞれの著者の組織、経験によって抑えるべきポイント、視点が異なることがわかる。

この本を購入しようとする読者は、この本をプロジェクトマネジメントやプロセス改善の教科書＝そこに書かれている通りに実施すればよいという手順書 と考えてはいけない。そうではなくて、プロジェクトマネージメントやプロセス改善の6つのプララクティス（実戦経験）から何かを学ぼうと考えるのが正しい読み方だ。

6つプラクティスもしくは体系は、似ている部分もあれば、異なる部分もある。その違いに混乱することなく、自分達の状態に一番近いものを選び、一番「その通り！」と思える部分に付箋をつけていく。

個人的には Part 4 に一番多く付箋が付いた。この本をお勧めするに当たりもっとも重要なのは、相手が人間である以上、改善の対象となる組織や組織を構成する人間、目に見えない文化や習慣を考慮して活動を進めなければ改善活動は成功しないということだ。

また、必ずしも論理的でない人間は、ロジカルにアプローチをしても予想通りの結果をもたらさない。だから、改善のサイクル(PDCA）を回し続けなければ、目的に近づかない。ソフトウェアの品質改善よりも人間や組織の改善の方がよっぽど手間と時間がかかる。

多くの著者がCMM/CMMIを取り上げているのは、それだけCMM/CMMIが優れた体系であるからだが、CMMやCMMIは自分達の身の丈にあった活動を続けていって、やっとサイクルがまわり成果が出てきたかなあと感じるようになった時点、CMM/CMMIを勉強するくらいがちょうどよいと思う。改善のサイクルが回っていない組織がいきなり CMM/CMMI を勉強し始めると空回りする可能性が高い。

何はともあれ、プロジェクトマネジメントやプロセス改善のテーマで6つの視点を比較することができるという意味でこの本は貴重な存在である。


P.S.

ときどき、「なんで自分はこのブログを続けているんだろうか」「このブログを読んでくれている読者は自分のことをどんな人物と受けとめているのだろうか」と考えることがある。一回の記事を書くのにだいたい1～2時間くらいはかかるから、たまに面倒くさいなあと思う。原稿料をもらっているわけでもないので締め切りもないので、「書き続ける」モチベーションを保ち続けるのもたいへんだ。

最初は本の読者と双方向の意見交換をするつもりだったが、結果的にはこちらかの情報発信が圧倒的に多い。（議論のもとになるネタまってます。以前、高校生からの「組込みソフトってなんですか」の質問では大いに盛り上がりました。）

でも、このブログを4年も続けていて実感しているのは、ブログに記事を書くことは明かに自分のためになっているということである。

他の人が書いた記事や、聞いた話を、ブログを通して多くの人に伝えるためには、いったんインプットされた情報を整理して読者を想定してかみ砕いて分かりやすくアウトプットしなければいけない。これはものづくりやソフトウェア開発にも役立つ。要するに、外界からセンシングした情報をインプットとして加工し特定のユーザーに受け入れられるようにアウトプットする訓練をしているのと同じだ。

コピペではなく、本や雑誌に書いてあることを、キーボードで打ち直すのは面倒だと思うかもしれないが、自分はこの作業がまったく苦にならない。なぜなら、文章を打ち直す行為は学校で先生が黒板に書いたことをノートに写すのと同じで、その行為によって理解や記憶が深まるからである。

もうひとつ。学校で授業を受ける際のインプットは先生が選択した情報だが、自分がやっているのは誰かから強制的に与えられた情報ではない、自分が自分の意志で選択した情報だ。そこに一貫性がないとブログの内容はその人の興味のあること＝日記風になり、何らかの目的、一貫したテーマがあれば、最終的にはその目的、テーマを達成るための体系になりうる。

もちろん、このブログは後者を目指しており、結果的に『組込みソフトエンジニアを極める』→設計に関する体系と『リコールを起こさないソフトウェアのつくり方』→V&Vの体系 にまとめることができた。

自分で自分のやることを選択して実行し、他人に認めてもらうというサイクルを回す際に一番苦しいのは、最初のステップ「自分で自分のやることを選択する」という点だ。なぜって、そこが最初だから選択した責任は自分にある。誰かから言われたことをやって失敗してら失敗した責任の一端は最初にヤレといった人にあるが、やるべきことを自分で選択したらすべての責任は自分にある。その覚悟をするのが大人になるとそれなりに重いのだ。

日本の技術者は自分でやりたいことを選択してやりきるという経験が非常に少ないように感じる。別にソフトウェア開発じゃなくてもいいから、料理でも作曲でも、目的を持ったブログでもちょっとした簡単なことでいいのでやってみるといい。やっていくうちにもう少し極めたいと思ったらしめたものだ。

そして「なんで、自分はこんなことをやっているのだろう」と必ず思うはずなので、そのときに根拠となるロジックを自分の中に構築する。これを習慣化すると自立したエンジニアになれる。

【参照】

1. モンテッソーリメソッド（子供向け）
2. モンテッソーリメソッド（大人向け）：自立したエンジニアを育てよう！

今回の記事を書きながら、そんなことを思ったのだった。

プリウスブレーキ制御ソフト改変についての考察 （新情報）

日経BP社から『不具合連鎖-「プリウス」リコールからの警鐘』が出たので早速注文して読んでみた。プリウスのブレーキ制御に関して新たに分かったことがあるのでそれについて考察してみようと思う。

【回生ブレーキと回生協調ブレーキについて】

ハイブリッド車や電気自動車には回生ブレーキがある。回生ブレーキとは減速時にモーターを発電機として回すことで運動エネルギーを電気エネルギーに変えてバッテリに貯める。ガソリンエンジンにはモーターがないからこのエコ機能は使えない。回生ブレーキを搭載することによって燃費が伸びる。

回生ブレーキがエコという価値の一部を担っているということだ。消費者が望むエコの価値を回生ブレーキという機能・性能が実現している。エコの価値を実現する回生ブレーキサブシステムはハイブリッド車にとって再利用可能なコア資産である。

そしてプリウスのブレーキは単なる回生ブレーキではなく、回生ブレーキと油圧ブレーキの配分をコンピュータで最適に制御する「回生協調ブレーキ」となっている。当たり前だが、回生ブレーキに比べて回生協調ブレーキはより複雑な制御を必要としソフトウェアの規模・複雑度も高まる。複雑であればあるほど他社には真似されにくいのでより価値の高いコア資産ということになる。（『リコールを起こさないソフトウェアのつくり方』 Part 3 を参照のこと）

■回生協調ブレーキ採用車
・トヨタのハイブリッド車
・ホンダのシビックハイブリッド
・2010年発売予定の日産自動車のリーフ（回生協調ブレーキ採用との噂）

■回生ブレーキ採用車
・三菱自動車の i-MiEV
・富士重工業の プラグインステラ
・ホンダのインサイト

回生ブレーキだけでは従来の油圧ブレーキと同等にはならない。なぜなら、絶対的な制動力が足らないからだ。だから回生ブレーキで不足した制動力を油圧ブレーキで補う必要がある。それが回生協調ブレーキである。

では、回生協調ブレーキでない、回生ブレーキの方はどうしているのかといえば、アクセルペダルを離したときだけ一定の回生ブレーキを効かせるようににして、ブレーキペダルを踏むときは油圧ブレーキを使うようにしている。（回生ブレーキと油圧ブレーキの併用）　ガソリン車でエンジンブレーキを使うときだけエネルギーを回収しているような感じだ。

ここまでのところですでにお分かりだと思うが、回生協調ブレーキはよりエネルギーの回収率が高い代わりに複雑な制御を要する。一方で回生ブレーキは回生協調ブレーキよりエネルギーの回収率が低いが、ブレーキペダルを踏んでブレーキをかける機能についてはシンプルな制御であるため複雑性からくるリスクは低いと言える。

英国MISRA(Motor Industry Software Reliability Association:
自動車産業ソフトウェア信頼性協会)が策定した、MISRAソフトウェア安全性解析ガイドライン 通称 MISRA SA （Safety Analysis）によると、単純なシステムと複雑なシステムの違いは次のようなものであると定義されている。（『リコールを起こさないソフトウェアのつくり方』のAppendix B にも掲載している）

－単純なシステムの定義－

A system is classified as smple if its design is suitable for exhaostive simulation and test, and its behavior can be entrely verified by exhaustive testing.

もし、その設計が徹底的（網羅的）なシミュレーション及びテストに適しており、かつ、その挙動が徹底的（網羅的）なテストによって、完全に検証可能ならば、そのシステムは“単純”と分類される。

－複雑なシステムの定義－

A system is classified as complex if its design is unsuitable for application of exhaustive simulation and test, and therefore its behavior cannot be verified by exhaustive testing.

もし、その設計が徹底的（網羅的）なシミュレーション及びテストに適しておらず、かつ、それ故にその挙動が徹底的（網羅的）なテストによって、検証可能ではないならば、そのシステムは“複雑”と分類される。

検証可能かどうかで単純か複雑かを分類するこの定義自体もかなりおおざっぱなような気もするが、MISRA SA の定義に照らし合わせると 回生ブレーキは単純なシステムに分類され、回生協調ブレーキは複雑なシステムに分類されると言えるのかもしれない。

なぜなら、回生協調ブレーキを採用したプリウスでは結果的にブレーキシステムのソフトウェアの改変を実施しており、そのことが徹底的（網羅的）なシミュレーション及びテストに適しておらず、その挙動が徹底的（網羅的）なテストによっても検証から漏れてしまった考えられるからである。

今後、システムが複雑化していくにつれ、似たような問題は次々と発生するだろう。

消費者はエコを求めている→エコ製品を作ると売れる→エコの実現には複雑な制御が必要→システムやソフトウェアの大規模複雑化をもたらす→これまで実現できていた安全や信頼を脅かす可能性がある

ひとつの考え方として、ホンダは低価格のインサイトについては燃費の追求よりもシンプルでローコストであることを目指したが、トヨタは低価格でも燃費や快適性を追求したためブレーキシステムが複雑になってリスクが増えたとも言える。

今の製品で実現している当たり前にできていることの重要性や、商品における潜在的な価値の大きさをイメージできない組織内のステークホルダはシステムやソフトウェアの複雑性によるリスクを想像することができない。何か事故が起こってから「なぜ？」と考え始める。

複雑性の中に潜むリスクを回避するために消費者の要望（例えば、燃費の向上）を犠牲にすることは悪だろうか。それは、複雑化しても絶対の安全を保証できるのなら悪だと言えるが、そもそも絶対的な安全など保証できないという前提に立つのなら必ずしも悪とは言えないと思う。

ソフトウェアで絶対的な安全や信頼など保証できないことは『リコールを起こさないソフトウェアのつくり方』の Part 1 で事例を使って解説した。そのことが理解できない組織は今後システムが複雑になるにつれリコールを起こす確率が徐々に高くなっていくと考えている。

【プリウスで不具合が起こりうる減速の仕方－『不具合連鎖-「プリウス」リコールからの警鐘』p39－より引用】

1. ハイブリッド車だから必ず回生ブレーキがある
2. 回生ブレーキはABSと相性が悪いので、非常時は回生を切り、摩擦を使った普通の油圧ブレーキに切り換えた
3. 回生が切れる分を補うため、摩擦を使った普通の油圧ブレーキを急に強める。従来はこのときに油圧を高めるポンプの騒音が出ていた
4. ポンプの騒音を低減するために従来の方法をやめ、ペダルからの力を使う方法に変えた
5. 動力源が切り替わるためブレーキの油圧が急に下がり、摩擦力が下がって“空走感”を感じさせた

【引用終わり】

プリウスはABSモードに入ると回生協調をやめて、油圧ブレーキだけ働かせる。今まで回生ブレーキを負担していたブレーキ力を油圧ブレーキが突然負担することになる。このとき、電動ポンプが動き出すと騒音が出るのだそうだ。

トヨタは騒音・振動・ハーシュネスにこだわる会社らしい。「レクサスLS600h」のカタログには「電子制御ブレーキは最適なブレーキ制御を行うためブレーキ操作時にモーター音が聞こえる場合があります」と書いているそうだ。新型プリウスではこの騒音（モーターと書いてあるが実際には電動油圧ポンプのこと）を軽減するために、先代プリウスのブレーキ制御方式を変えた。

しかし、結果的に今回わかった空走感の問題が明らかになったので、先代プリウスの制御方法に戻したため騒音が出るようになったと思われる。

詳しくは 『不具合連鎖-「プリウス」リコールからの警鐘』の p47-51を読んで欲しいが、簡単に書くと新型プリウスのブレーキ・バイ・ワイヤの仕組みはこんな感じの特徴を持っている。

まず、前提条件としてハイブリッド車では、ドライバーがブレーキを踏む側のサブシステム「バーチャル側」と、電子制御でブレーキを制御する「リアル側」のサブシステムが組み合わさってブレーキシステムを構成している。

ドライバーはブレーキペダルを踏んだときのその圧力が直接ブレーキに伝わっているかのように感じているが、実際はそうではなく電子制御によってブレーキングを実現している。だからドライバー側のサブシステムは「バーチャル」なのだ。

そして、通常バーチャル側とリアル側の油圧の配管は遮断弁で切り離されているがリアル側の制御が故障したときは遮断弁が開いてリアルとバーチャルをつなぎ、ドライバーがペダルを踏む力が各輪に伝わるようになっている。（プリウスの場合）

2代目プリウスでは電源が故障したときのために非常用電源に相当するキャパシタを搭載しておりこれでブレーキを効かせるようにし、キャパシタが空になったら遮断弁を開いてペダルを踏む力を伝えるようにした。（相当強く踏まないとブレーキは効かないらしい）

新型プリウスではコストダウンのためのキャパシタを省略し、高圧のブレーキオイルをアキュームレータに蓄えることで2～3回分補助できるようにした。

さて、新型プリウスではABSによる制動時の油圧ポンプによる騒音を減らしたいがために、ポンプをできるだけ使わずバーチャル側の力（油圧）で回生ブレーキが担っていた分の制動力をカバーしようとした。ところが、リアル側とバーチャル側は通常は遮断されているため、今回問題となったケースにように低速で走っていて、軽くブレーキをかけた状態で遮断弁を開くとリアル側の方が油圧が高くなっている。

だから遮断弁を開いたときに油圧がリアル側からバーチャル側に流れて、各輪にかかっているブレーキ油圧が一瞬（1秒くらいだろうか）下がる。リアル側とバーチャル側がつながっているので、ドライバーはこの油圧の低下感覚をもろに受けてブレーキ力がすっぽ抜けたように感じる。

リアル側とバーチャル側の油圧に差がないとすっぽ抜け感はない。おそらく高速走行中では問題はないのだろう。

結局、今回のブレーキ制御ソフトの改変でABS作動時にリアル側とバーチャル側の遮断弁を開くのをやめたのでこのすっぽ抜け感はなくなったが、騒音（どの程度の騒音かはわからないが・・・）は復活してしまった。

【プリウスのブレーキ問題を振り返って】

ハイブリッド車のブレーキ制御システムを知って、これほどまでに複雑化しているのかということを知って驚愕した。日本車ならこれくらい複雑になっても信頼できると言いたいが、これ以上複雑になるのなら、安全を重視してシンプルな制御システムの車かどうかという点も調べてから商品を選ばないといけないと思った。

なんだかんだいっても日本車が消費者から信頼されているのは、ユーザーがどのように車を使うのかについての妥当性確認(Validation）を徹底的に行っているからだと思う。

しかし、システムが複雑化すればするほど Validation では漏れや抜けが生じるため、検証(Verification）の重要性が増す。ようするに V&V が安全や信頼のポイントとなる。

MISRA SA が言う複雑なシステムにおいては、Verification や Validation の実施に先立って、ユーザーリスクに焦点を絞った安全分析が必要となる。

『不具合連鎖-「プリウス」リコールからの警鐘』を読んで複雑なシステムは恐いと思った方は、続いて『リコールを起こさないソフトウェアのつくり方』も読んでいただいて、どうすればユーザーの安全や信頼を得ることができるかという方法について考えていただきたい。

プリウスブレーキ制御ソフト改変についての考察 （訂正）

プリウスのブレーキ制御に関しては次々に新しい事実が分かるので過去の考察を訂正していかないといけない。

【いろいろな事実を総合して分かったこと（訂正を含む）】

• この問題はたぶんソフトウェアのデグレード（変更によって今まで動いていたところが動かなくなるミス）ではない。
• この問題は複雑化していたブレーキシステムの軽量化、低コスト化により、ブレーキシステムのハード・ソフトが変わった際に Validation（妥当性確認）の 漏れが生じたことからきている。
• 漏れがあったからといってトヨタやアドヴィックスがV&V(Validation & Verification)を十分に行っていなかった訳ではなく普通の企業に比べればよっぽど念入りにやっていた。（と予想する。）
• 軽量化やコストダウンの検討は悪ではなくエンジニアがトライすべきことだから、その流れは間違っていない。（だからデグレードではない。もとに戻してしまうと重量が重くなり、コストアップしてしまう。それは商品の価値を下げ、結果的に顧客満足度も下げてしまう）
• 結果的にソフトウェアの改変で問題を解決しようとしたがソフトウェア技術者のミスともいいきれない。（Validation のステージにおいてすべてのシチュエーションを想定して確認することは不可能）
• この問題は設計の工程で見つけられた可能性は低く、ユーザークレーム→原因分析→是正→水平展開という CAPA（Corrective Action & Preventive Action：是正処置及び予防措置）で改善する種別のものである。
• 結果的に今回の問題は受容可能なリスクと判断される。（実質的な安全性の確保とユーザーの気持ち悪さ、不安とは異なる）
• 上記のことから、今回の問題はエンジニアの過失はとは言い難い。

【Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』を読み解く】

Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』の記事を落ち着いてじっくり繰り返し読んでみた。日経Automotive Technology はすごい。どうして、トヨタのエンジニアでもないのにここまで詳しくブレーキシステムのメカニズムが分かってしまうのだろうと思う。

この記事をエンジニアではない一般の読者が読んでもよく分からないと思うので解説しながら内容を理解したいと思う。（途中、Tech-On!の記事をところどころで参照している）

【とんでもなく複雑化しているハイブリッド車のブレーキシステム】

プリウスは燃費を向上させるために、制動時に車両の運動エネルギーを回収する機能を備えた「回生協調ブレーキ」システムを搭載している。

ガソリンエンジンの車ではブレーキによって削減された運動エネルギーは全部熱エネルギーに変わる。プリウスは制動時の運動エネルギーでモーターを回し発電し発電した電気エネルギーをバッテリに蓄えることでエネルギーを回収している。

自転車のライトを光らせるときにこぎ手は負荷を感じるだろう。運動エネルギーの一部でモーターを回しそれを光に変えているからだ。でも坂道にさしかかると漕がなくてもモーターはまわりライトは光る。プリウスはいわばこのときのエネルギーをバッテリに蓄え燃費向上に使っているのだ。

回生協調ブレーキの基本的な作動原理は次の通りだ。まず、ドライバーがアクセルペダルから足を離した段階で、ドライバーに違和感がない程度に、軽い回生ブレーキをかけ、運動エネルギを回収する。次に、ドライバーがブレーキペダルを踏むと、ペダルを踏む速度と、ペダルの踏み込み量から、ドライバーが要求する制動力がどの程度かを判断する。この制動力の範囲内で、最大限の回生ブレーキをかける。そのうえで、回生ブレーキでは足りない分を油圧ブレーキで補う。

Tech-On! の記事には図が載っているのでそれも見ていただくとして、この部分を読んだだけでもとてつもなく複雑で繊細な制御をハード・ソフトでやっているのがわかる。以前読んだ記事ではプリウスは回生ブレーキと油圧ブレーキを切り替えていると書いてあったがそれは間違いで、回生ブレーキでエネルギーを最大限回収しておいて、それだけではドライバーが想定する制動力には足らないのでその不足ぶんを油圧の制動力で補っているのだ。

回生（モーターによる制動力）はリニアではない。ハイブリッドではない車のブレーキペダルを踏んぶんだけリニアに制動する感覚を再現するためには、リアルタイムかつセンシングとアクチュエータのフィードバックのハード・ソフトが必要になる。

この時点で安全アーキテクチャの基本であるシンプルデザインと安全をつかさどる機能・性能のアイソレーションは崩れかけている。しかし、これはしょうがないのだ。ユーザーニーズは多様化し、多様化したニーズを実現するためにシステムは複雑にならざるを得ない。

しかし、複雑にも程度はあって、ソフトウェアの場合指数関数的にぐちゃぐちゃにすることが簡単にできるので、ユーザー要求を満たすための最低限の複雑さにとどめておく必要がある。

そういう努力をおそらくアドヴィックスやトヨタはしており、たぶん、他の業界よりも進んだ取り組みをしていると予想する。それでもこぼれ落ちる問題は発生するのだ。

【なぜ、先代プリウスでは発生せず、新型プリウスでは問題が起こったか】

Tech-On! の記事によると、先代プリウスは回生協調ブレーキの機能を専用設計のシステムにより実現していた。これに対して新型プリウスでは、汎用的な横滑り防止装置（ESC）と部品の共通化を進めたらしい。

ちなみに、この取り組み自体はシンプルデザインと安全機能・安全性能のアイソレーションとは逆行しているから、ユーザーに対する価値（主にコストダウン）の向上を目指した取り組みであったとはいえ危険な領域に一歩踏み出しているといえる。（『セーフウェア』で解説されている放射線治療器セラック25の事故がセラック20のコストダウンがきっかけになって起こったのに状況はよく似ている）

トヨタは部品の共通化を進めた結果、ブレーキシステムの重量を29%も減らし、低コスト化も実現した。これは想像だが、メカとエレキのコストダウンを実現して、結果としてソフトウェアの負担（複雑性、規模）が増えることがある。コストダウンを達成して、めでたしめでたしの裏にソフトウェアの問題によるリスクの高まりが見落とされていることがあるので、ハードウェア出身の組織の上位層の方達はその点をよく認識しておいて欲しい。部品のコストダウンで一見成功したに見えた利益アップはソフトのリコールで一気になくなりマイナスになる可能性もあるということだ。（だからコストダウンをやめた方がいいのではなく、そういうリスクがあることを認識した上で慎重にソフトのV&Vを行う必要がある）

【新型ブレーキシステムの構成】

新型ブレーキシステムは次の部品から構成されている。

• 油圧ブースタ
• ブレーキアクチュエータ
• ストロークエミュレータ
• ECU（Electric Control Unit)ようするに頭脳の部分でここにソフトが入っている。

従来のブレーキシステムのと違い

従来のプリウスに搭載していた回生協調ブレーキは「ECB (Electronically Controlled Brake System)2 」と呼ばれているそうで、ブレーキペダルを踏む力が、通常走行時は直接各車輪には伝わらない「ブレーキ・バイ・ワイヤ」となっている。

※ECB2 というくらいだから ECB1 もあったのだろう。回生協調ブレーキとしてECB1→ECB2 と改善しながらハード・ソフトを枯れさせていったが、新型ブレーキシステムではコストダウンのために大幅に変更した。（一般的にそういうところに問題:Anomaly は潜んでいる）

先代プリウスではブレーキペダルからの油圧配管は、ブレーキ配管からは遮断されている。ドライバーが要求する制動力は、ブレーキペダルを踏む速度と、ペダルの角度をセンサによってセンシングしてコンピュータ制御＋モーター駆動の油圧ポンプで制動する。

このとき発生した油圧は、各輪に装備したリニア・ソレノイド・バルブによって制御し、必要な制動力を生み出している。

※このリニア・ソレノイド・バルブが高価で大きい部品らしく、新型プリウスではこの部品をデューティ型ソレノイドに変えてコストダウンをはかった。

【従来ブレーキシステムの欠点】

リニア・ソレノイド・バルブは内部のスプールバルブを高い精度で位置決めすることで、精密に油圧を制御できるとう特徴を持っている。ようするに高価だが性能のよい部品ということ。

これに対して、デューティ型ソレノイドは基本的にはオンとオフしかできないが、オン時間とオフ時間の比率を変えることで油圧を制御できる。その精度はリニアソレノイドほどではない。

※ここは今回の問題が発生した原因の中核となる部分だ。デューティ型ソレノイドはリニアソレノイドのように滑らかに制御できない。オンとオフを繰り返すことで制御するので振動が発生する。この振動を抑えるために変えた制御方法が今回の問題を生んだ。（たぶん）

リニアソレノイドは各輪にリニアソレノイドと圧力センサを備えることで、各輪のブレーキ油圧を独立して制御することができるので、ハイブリッドでない車種にも採用されている。そんな高価で高性能な部品を先代プリウスでは使っていた。ホンダのインサイトに価格対向するために新型プリウスでは高価な部品を使わないで要求されている機能や性能を実現する必要があり、結果的にこぼれ落ちた滴があった？のかもしれない。

【新型プリウスのブレーキシステム】

新型プリウスではシステム全体の油圧を決定する部分だけにリニアソレノイドを使い、この油圧を検知するセンサも一箇所だけ、そして、各輪には安価なデューティ型ソレノイドを使っている。

なお、もうひとつ新型プリウスでは低コストの取り組みをしている。従来型のブレーキ・バイ・ワイヤのシステムでは、電源が落ちるとポンプを駆動するモータが動かず、制動力を発生できないため、バックアップ電源としてのキャパシタ（一時的な蓄電池）が装備されていた。新型プリウスではブレーキシステムのくふうでキャパシタをなくしコストダウンを実現した。（くわしくは Tech-On!の記事を参照のこと）

この設計の変更により、新型プリウスはブレーキ・バイ・ワイヤとドライバの踏み力を直接各輪に伝える切り替えが可能になった。（と予想している）　そして、このメカニズムの変更を利用して、リニアソレノイドからデューティ型ソレノイドにコストダウンしたことによって低速で発生する振動ノイズを減らす制御を採用した。そこに落とし穴があったのではないだろうか。

前回の記事で、リコールによる改変で先代プリウスの性能にもどった→デグレードしたと書いたが、ブレーキシステム自体大幅に変わっているので、先代プリウスの性能にもどった訳ではない。

デューティ型ソレノイドを使っているぶん、ABS作動時に発生すると言われるノイズや振動は先代プリウスではなかった問題なのだろう。それが今回のソフトウェアの改変で復活したと思われる。そのノイズや振動は許容できるかどうかといえば、リスクとしては許容できるレベルであり、快適性とう点から考えると今後の検討課題になると思われる。（一度は低減する方向性を出している）

【従来ブレーキシステムから新型ブレーキシステムへの変更点】

• 従来ブレーキシステムではレクサスHS250h や SAI などにも搭載されているリニア・ソレノイド・バルブを使っていた。
• 従来ブレーキシステムではドライバーとブレーキが直接つながっていないブレーキ・バイ・ワイヤのシステムだった。
• そのため従来ブレーキシステムでは電源が落ちたときのバックアップとしてキャパシタが載っていた。
• 新型プリウスでは、リニア・ソレノイドの使用を減らし、デューティ型ソレノイドを採用し、さまざまな変更を行った結果 29%の軽量化、コストダウンに成功した。（キャパシタもなくなった）
• 変更を行ったことで、低速でのABS始動時にデューティ型ソレノイドによるノイズ・振動がブレーキペダルを通じてドライバに伝わるようになった。
• その問題を解決するシステム制御に今回の問題があった。（どちらも許容できるリスク）

【商品の価値を高めるためにコストダウンは必要】

コストダウンによるシステムの変更。それもメカもエレキも大幅に変えるとなると、ソフトウェアエンジニアはそれは危ないからやめましょうとはいえないし、変更をやらないという選択肢はない。やらなければ他社に勝てない。

だから、コストダウンの取り組みはメカもエレキもソフトも協力して実現しなければならず、かつ、安全性・信頼性も確保しなければいけない。

たぶん、今回の問題は受容できるリスクの範疇であったと思われる。低速でABSが働くときにしか起こらない。制動距離は70cm 伸びるが本当にドライバが危ないと感じればブレーキペダルを強く踏み込むので制動距離は縮まる。

こう理解すると、これまでのトヨタの記者会見では発表内容は逐一納得できる。ただ、コストダウンが目的によるブレーキシステムの設計変更が問題の発生を誘発したとは絶対に言いたくないだろう。そんなことを言おうものなら『コストダウンにより不具合混入』などという超短絡的な見出しだけが一人歩きする。

【安全を脅かす落とし穴はどこに存在するか】

• システムやソフトウェアの大規模化、複雑化に潜む
• コストダウンでメカ・エレキを省略する行為の中に潜む
• ソフトウェアが見えないというところに潜む
• ソフトウェアが見えないことを認識しないで問題を単純化するところに潜む

冒頭に書いたことを繰り返すと、今回の問題は結果的にソフトウェアを修正したが、ソフトウェアだけの問題ではなく、ブレーキシステムのメカ・エレキ・ソフトを変更した際の Validation （妥当性確認）に漏れがあったということだ。

そして、その漏れは受容できるリスクの範囲ではあったが、ユーザーの気持ち悪さと不安を取り除くためにリコールにした。

トヨタが反論しない理由は、説明しても一般の人が簡単に理解できるような内容ではないことと、説明すればするほど技術的な背景を理解できない者が「トヨタはいい訳をしている」と批判するからだろう。

この問題を通じて再認識したのは、一つの問題や事故の後ろには非常に複雑でテクニカルな内容と組織判断が含まれているということだ。今回の問題は事故ではないが、仮に複雑なシステムで事故が起こった場合、その深層に一般のジャーナリズムが切り込んで解明することはおそらく不可能だということだ。日経BPの記者だって、ソフトの中に問題があれば分析のしようがない。

そう考えると、日本も複雑なシステムの事故を客観的に調査する機関があるべきだと思う。航空機や鉄道にはあると聞いたことがあるが、専門分野のエキスパートが客観的に問題を調査できるようでないとまずいだろう。

P.S.

やっぱり、コストを含む市場要求と顕在的価値、潜在的価値（安全・信頼）とのバランス、トレードオフ及び、成果物の V&V(Validation & Verification）がこれからの複雑化するソフトウェア搭載システムの課題だと思う。

Tech-On!を見ていたら『Ford社、ハイブリッド車の回生ブレーキのソフトウエアを書き換え』という記事があった。これってプリウスのソフト改変とまったく同じに見える。同じブレーキシステムをトヨタやアドヴィックスが提供していたならともかく、そうでないのだとしたらプリウスをバラバラに分解してデッドコピーしたのでは？と思わせる。なんで、こっちはリコールじゃないんだろうか。

プリウスブレーキ制御ソフト改変についての考察 （まとめ）

(トヨタは社長と副社長が 2月9日の記者会見で、今回の問題について客観的なデータをもとに論理的に発生する現象及び原因を説明していた。

新聞やテレビの記者はエンジニアではないから、この技術的な説明の部分を全部すっ飛ばしてしまう。ラジオで聞いた制動力がが回復するまでの時間 0.4秒 というキーワード＋プリウス＋ABS で検索したら、今回の記者会見の技術的な説明が書かれている記事を見つけた。

Car Watch というサイトだ。この記事を読んでエンジニアとしては分からなかったことが全部分かってスッキリした。Car Watch さんありがとう。

詳細はこの記事を読んでもらうとして、自分が理解したポイントを書いていきたいと思う。

【今回の問題で制動距離が伸びるのか】

→想定する条件下において70cm伸びる

ブレーキペダルの踏力をそのまました場合、通常のABSが0.4秒で作動するところ、0.46秒かかるので、通常のABSでは60cmのオーバーラン（タイヤがロックしないようにするため）に対して、今回の問題が起こるとさらに70cmの距離が必要になる。

ちなみに、この説明だと 0.06秒 = 60msec しか遅れはないように見える。60ms という時間は人間が感じるのは難しいくらいの短い間隔だ。


【本当の問題】

本当の問題はこのABSの立ち上がり時間の遅れではない。実はユーザーのためによかれと思って変更したソフトウェアの改変が、非常に見つけにくい問題を生んだ。

そもそも、昔の車はブレーキを踏むとその圧力がダイレクトにブレーキパッドに伝わるようなシンプルな構造であった。圧力の伝達は油圧で行われていた。

しかし、車の制御のほとんどが電子制御になった今、先進の車ではブレーキペダルが踏まれた圧力をセンサーを使ってセンシングし電子データに変換してそのデータのデータ量をもとに電気式のポンプによって制動力をソフトウェアでコントロールしている。

ブレーキペダルとブレーキパッドは直接つながっておらず、その間にコンピュータとソフトウェアが入っているということだ。自分はソフトウェアが完璧にはならないことを知っているので、この事実は正直言って恐ろしい。ただ、恐ろしいからといっていつも車を運転しているときに不安に思っているかと言えばそうではない。いつも期待通りに動いていてくれるのでその恐れは忘れ去っている。本当に怖いと感じるのは実際に自分が問題を体感したときだろう。

昔なら、メカニカルな整備をきっちりやっていれば安心だということはユーザーにも確信があった。ブレーキの構造は教習所で教えてもらったとおり単純だったから、ユーザーと整備工場の信頼関係で安全・安心は確保できたのだ。しかし、今はメカの間にエレキとソフトが入っており、エレキはまだしもソフトは外からでは目に見えないから問題があるのかないのかはユーザーには分からない。ソフトウェアを作ったメーカーやサプライヤを信じるしかない。

さて、プリウスのブレーキ制御構造はかなり高度にできていて、電気式ポンプによる制御と運転手がペダルを踏んだときの圧力をダイレクトに伝える方法を切り替えられるようになっている。（信用できない新参メーカーが電子制御のブレーキシステムだけを搭載して、そこに怪しいソフトが入っていたらそれは本当の恐怖となるだろう）

プリウスではABSが作動した際には、この電気式ポンプで発生していた油圧から、実際にペダルを踏んだ力で発生する油圧へと切り替える制御をしていた。

その様子を説明したスライドはこちら。

なぜ、そうしたのか。

ABSが作動した際には電動ポンプやソレノイドを使った場合、ノイズや振動が発生し、従来のモデルではそうした部分に対し不満の声があったためとのこと。

→これはおそらく相当微妙な感覚で、ABSが働くときのガガガッという動作を考えればノイズも何もないだろうと思う。結果的に今回の改変でこの修正をやめたのでたいした要求ではなかったのだと考えられる。

そして本当の問題は電動ポンプの場合、軽い踏力の際にはブレーキの効きが悪くなるという感覚があるため、若干油圧を増すようにしていたことと関連している。

油圧ブレーキの場合、踏んだ力と実際の油圧はリニアに変化するのに対し、電動ポンプを使っているとブレーキの効きが悪くなる感覚がある？（回生ブレーキ＋電動ポンプになっている）ため、回生ブレーキ動作時には電動ポンプで油圧を増している。このようなソフトウェアを組み込んでおいて回生ブレーキ＋電動ポンプからユーザーダイレクトの油圧ポンプに切り替えると当たり前だが、切り替わった後で若干油圧と踏みの反発力が下がる。

だから、ABSの立ち上がりの遅れ 0.06秒は問題の本質ではなく、回生ブレーキ＋電動ポンプから油圧ポンプに切り替わったときの油圧の低下がスカッという抜け感覚を助長しているのだと思う。

油圧が低下する様子を示したスライドはこちら

【問題が発生するまでの系譜】

1. 先代プリウスでは回生ブレーキ動作中は回生ブレーキに油圧ブレーキを足して制動を制御していた。（回生協調ブレーキ）
2. 先代プリウスではABSに切り替わった際電動ポンプによる電子制御のブレーキングを行っていた。
3. 新型プリウスでは「ABSが作動時、電動ポンプで油圧を発生させていると、低速走行時にはユーザーが分かる程度の振動が発生していたため」油圧ポンプ制御に切り替えるソフトウェアの改変し、ABS動作時にはブレーキをユーザーの踏み込み力で油圧発生に伴う振動音を減らしていた。
4. しかし、新型プリウスの場合、低速でブレーキを踏むとそれまで油圧+回生を併用した状態からユーザーの踏み込み分の油圧のみにかわることで油圧が若干下がり制動力が低下してしまう。（低下するのは回生ブレーキのぶんだろうか）
5. この油圧の低下によりABSの立ち上がりの遅れ制動距離が70cm伸びる。
6. 回生協調ブレーキからABSの起動、油圧ブレーキへの切り替えが起こると油圧が低下し一瞬（感覚的には1秒くらいなのだろうか）「スカッ」というブレーキ抜けの感覚が感じられる。そのとき、スピードメーターも数km/h上がる。
7. 実際の制動には大きな影響はないが気持ちが悪いかつ、運転手に不安を与えるため、ABSに切り替わるときにも電動ブレーキのままにすることにした。（先代プリウスと同じ制御に戻した）
8. 「ABSが作動時、電動ポンプを使った場合、ノイズや振動が発生する」という問題は結果的には修正しなくても顧客満足には大きな影響を与えない程度のものだった。（予想）

2月4日の品質保証担当役員の方が記者会見で「ブレーキを踏み増せば問題ない」といったのはこの電動ポンプから油圧ポンプへの切り替えの際の油圧低下分を踏みましてくれれば同じ感覚になりますよといっているのである。問題発生のメカニズムが分かってしまうと「それはないだろう」と思うし、この圧力低下の状態はエンジニアの設計意図とは違うはずだ。より顧客満足度を高めようとして従来の枯れた制御方法から新しいソフトウェアの改変を行ったときに、油圧が低下し踏力とブレーキの効きのリニアリティが僅かながら崩れることは分かっていなかった、意識していなかったと思う。

大事なのは、そこでエンジニアを責めるのではなく、なぜ、見落としが発生するのか、見落としををなくすようにするにはどのような取り組みをしなければいけないのかを考えることだ。

残念ながら、複雑なシステムのソフトウェアを改変すると、このような分析漏れは発生する。システムやソフトウェアが複雑であればあるほどよかれと思って行ったソフトウェアの変更が悪影響をもたらす可能性は排除できない。

今回のリコール対策では、ABS作動時にメカニカルな油圧へと切り替えるシステムを廃し、従来のものと同様、ABS作動時も電動ポンプを使った油圧のままにし、こうした制動力の変化をなくしたということなので、ユーザーのためによかれと思って実施したソフトウェアの改変により問題が発生し、結果的に従来機種と同様のソフトウェアに戻しましたということになる。

酷なようだが、これはソフトウェアの変更管理的にいうとソフトウェアの変更によるデグレードだと思う。

【どうすれば同じ失敗を防ぐことはできるか】

1. クリティカルな機能や性能に関する要求分析をし、要求に優先度を付ける。
2. クリティカルな機能や性能を実現するソフトウェアの構造をできるだけシンプルにする。
3. それをモデルに示し可視化する。
4. V&V(Verification & Validation)を実施する
5. クリティカルなサブシステムへの変更時には変更の影響範囲を分析し、どのような影響があるか分析する。
6. それでも漏れと問題は発生するので、起こってしまった問題に関するデータをアーカイブして組織内で共有し、次回のソフトウェア改変時に同じような問題がないかどうかを水平展開する。

ちなみに感覚的には1～4で90%の品質が確保でき、5で97%の品質が確保でき、6で99%の品質が確保できるように思う。そして、ユーザーは1%の品質の違いを敏感に感じ取る。

ソフトウェア絡みの問題は恐ろしい。なぜなら、どんな問題でも修正すると100%現象を起こさないようにできてしまうからだ。故障率に起因する問題であれば確率が低いということで回収をしないという選択肢も取れる。

しかし、ソフトウェアの場合は発生するシチュエーションがどんなに希であっても、ソフトウェアの改変によって現象発生を0%にできるとわかれば、ユーザーは決して許してくれない。

ソフトウェアの変更容易性はソフトウェアのメリットであるとともに、機能や性能をデグレードさせる要因にもなるので最大のデメリットでもある。

そして、問題が発覚すると完璧な対応をしなければいけないので調査に時間がかかるが、対応策が分かるまで問題を公表しないと情報を隠蔽していると言われてしまう。問題があることを公開してしまうと対応策を実施するまでの猶予はあまりなく、その間エンジニアを含む関係者はフル稼働を強いられる。

そうならないようにするには余裕のあるときにきっちりと上記の1～6を実施しておくことが大事だと思う。エンジニアにとっての悲劇は1%の品質向上のためによかれと思って行ったソフトウェアの改変が、エンジニアの意志に反して逆に顧客満足を下げてしまう危険があるということである。

それを防ぐためには、品質を心配する強い意識と安全や信頼を達成するために必要なスキルの両方を備えておく必要がある。

P.S.

自分は一消費者として、企業を評価するとき不具合を起こしたかどうかではなく、不具合をどのように説明するのか、どのように再発防止に取り組むのかといった部分で評価する。

ユーザーとしては問題があったときに隠蔽せずキチンと対応してくれれば、何もないときよりも場合によっては信頼が増すことだってある。

そう考えると2月4日の記者会見の際には客観的なデータがなかったのでやや信頼を失いかけたが2月9日の会見で正直に問題発生のメカニズムをデータとともに説明してくれたので自分の中でのトヨタの信頼は高まった。今回の問題の分析と再発防止策について品質管理学会や情報処理学会などで発表してくれるとなおよいと思う。

その後、Tech-On! のサイトにとんでもなく詳しいメカニズムの解説があった。さすが日経BP。ちなみに、ソフトウェアの問題に関する考察はなかった。

Tech-On! 記事『トヨタ新型「プリウス」の不具合、快適性を高めるため油圧ブレーキの制御変更が原因』
Tech-On! 記事『プリウスのブレーキはこうなっている，汎用部品の活用で回生協調機能を低コスト化』

これらの記事を読むと、今回の問題はとてつもなく複雑化しているブレーキシステムにおいてメカとエレキとソフトの間に生まれた僅かな隙間から発生した見落としだったように思える。

ソフト絡みの問題を短絡的に考えてはいけないと主張している『セーフウェア』をやっぱり読んだ方がいいと思った。

プリウスブレーキ制御ソフト改変についての考察 （その後）

2月7日、フジテレビの夜『情報エンタメLIVEジャーナる!』で、プリウスのブレーキ問題を再現していた。テレビはすごい。現象を再現できるユーザーを捜し出したのだ。

場所は完全な雪道でスピードは30km/h くらいからゆっくり減速している状況で、カーブなどにさしかかったり、ブレーキを軽く踏んだりしたときに現象は起きる。

運転手の横に座っているカメラマンやディレクター、車を外から撮っているカメラマンにはその現象が起こったことは分からない。

運転手が「ほら、これ」といっても違いがわからないのだ。しかし、スピードメーターをプレイバックしてスローで見てみると30km/h からゆっくり減速しているのに、22km/h くらいのときに約1秒くらい数km/h くらいスピードメーターの値がアップする。これが1秒間の空白で、スカッと抜けた感覚なのだという。

20～30km/h 程度の低速走行時の雪道でブレーキを踏んだときの1秒間の抜ける感覚。確かに危険性は小さいのかもしれないが、効くはずのブレーキが一瞬でも効かない感覚はさぞ気持ち悪いだろうと想像する。

さて、2月9日に豊田社長は記者会見で、以下のように語っている。

私自身、プリウスを運転した。対策前の車は滑りやすい路面を走ると、（ブレーキを踏んでも）「抜ける」という表現が一番しっくりくる。速やかに直すのが、信頼回復の第一歩と思った。

自分自身で現象を確認するとは、さすがだと思った。ただ、正確には下記のような現象のようなので、制動距離はわずかだが長くなっているという事実はきちんととらえておく必要がある。

今回の不具合は、寒冷地の凍結路などで横滑りを防止するためＡＢＳ（アンチロック・ブレーキ・システム）が作動することでブレーキがかかりにくくなるというもの。氷の上など横滑りしやすい路面で時速２０キロメートルと低速で走行しながらブレーキを踏み込む場合、クルマが停止するまでに必要な距離が１３．６メートルと従来型プリウスよりも１割程度長くなる。従来よりも滑らかに停止できる一方で、ブレーキの立ち上がりが一瞬遅れる。

「快適性を追及しすぎた面があるかもしれない」というのはたぶん違うように思える。スカッと抜ける感覚は決して快適ではないからだ。

ただ、豊田社長が自ら記者会見にのぞみ、トヨタは「全能ではないが、失敗は必ず修正・改善してきた強い自信ある」とし、信頼回復のために全社一丸となりまい進する姿勢を強調したのはさすが並の会社ではないと思った。

新しい取り組みの中には必ず見落としや失敗はある。我々は全く新しい取り組みを行う際には、まず、ユーザーに対して大きな不利益にならないようにリスク軽減策に万全を尽くす。しかし、必ずこぼれ落ちる不具合はあるので、それが発現してしまったら修正と改善を粛々と行う。その際に反省は必要だが、くよくよしてはいけない。過去のことを考えるのではなく未来に同じ失敗を繰り返さないように再発防止の取り組みに邁進することが最も重要だ。

そのような再発防止の取り組みを続け水平展開してゆけば、技術は枯れ、信頼性・安全性は増す。ソフトウェア的に言えば堅牢な再利用資産になっていくのだ。

不具合が発見されたときはシステマティックに原因を追及し、是正・予防処置をし、再発防止策をノウハウとして蓄積し、再利用資産の構築の際にそのノウハウを使う。これによって、商品の潜在的価値が高まる。実際には、その価値をモデルや分析結果という形で可視化しないと組織の資産にはならない。トヨタの中で今回の件の再発防止策が可視化された形で組織内に蓄積されるかどうかは外側からは分からない。

業界的には分析結果を公表してくれれば再発防止に役立つのだろうが、残念ながらトヨタにその義務はない。

CAPAができていない組織の先行きは危うい

CAPA （Corrective Action and Preventive Action：是正・予防措置）とは問題が起こったときに再発を防止するための考え方である。

【CAPAのプロセス】

1. 問題点を明らかにする
2. 是正アクションの実行
3. 類似した問題が起こらないようにするための予防アクションの実行
4. 予防アクションのデータによる検証

いたって当たり前のように見えるが、これが組織的にはなかなかできない。日本では「問題点を明らかにする」と「是正アクションの実行」を個人的にやるところまでしかいかないことの方が多いように思う。

組織的に再発を防止するためには「類似した問題が起こらないようにするための予防アクションの実行」と「予防アクションのデータによる検証」が必要だ。CAPAはシステマティックにやらないとうまくいかない。犯人捜し、個人攻撃のような様相を呈するようになると、みんな積極的に動かなくなる。

基本的には問題が起きたらQA（品質保証）担当が、淡々と実施していくのだが、日本人は過度にミスを犯したことを追求したように受け取ってしまうため、次回からは自分が気をつけて類似問題を起こさないようにするだけで、組織的予防処置まで行動が広がらない。

自分のミスをさらしたくないという恥の文化もあってそうさせているのだろう。

しかし、それでは組織的な対応としてはまったくできていない。関係部署がそれぞれの責任のもと、再発防止策を考え、実施し、検証することで、組織内に是正策が定着する。

このブログで欧米発の方法論をそのまま鵜呑みにするのは良くないと言っているが、CAPAは欧米発の考え方でよいシステムだと思う。

でもよくよ見ると CAPA はQC活動、カイゼン活動とよく似ている。最大の違いは、QC活動では問題点を自分達で抽出して、自分達で再発防止策を考え実行する。他のチームにその改善策を押しつけることは基本的にしない。（と思う）

他人から言われたからやる、のではなくあくまでも自浄能力を高めようという精神が根底にあると感じる。

ところが、今ではその自浄能力はすべてのチームにはない。そうなると組織的に問題に取り組み是正予防策を共有する必要がでてくる。責任と権限のもとルールを作ったたり、変えて、そのルールを守っていくということも必要になってくる。

CAPAのしくみがあるのにこれが形骸化している組織は最悪だ。チームには問題が見つかり外部から指摘されたら、本来は「問題を見つけてくれてありがとう」という気持ちで再発防止策に取り組む必要があるのだが、CAPAが形骸化している組織では「ああ、めんどくさい」「早く収束させて仕事に戻りたい」となる。

QC活動、カイゼン活動を普及させて自立的に乗り切る方法と、組織がシステマティックにCAPAを回す方法と現代の日本の組織には両面の活動が求められていると思う。

今起こっている問題を解決することよりも、再発防止に重きを置いている組織の未来は確固たるものがあるように感じるが、是正・予防に力が入っていない組織の先行きは危ういと思う。

　

カイゼンの実現にはジャーナリズムが必要

今、政治が面白い。政権が交代し新しい施策・政策が次々と打ち出され改善が進んでいく過程を見るのは心地よいものだ。

組織内でなかなか進まないソフトウェア系のカイゼンをうまく前進させるためのヒントが今の政治に見いだせるのではないかと思った。

そもそもこれまでどうにかボトムアップ＆技術的なアプローチで組織的なカイゼンが実現できないか考えてきた。時間はかかっても実績を積み上げることでボトムアップアプローチでもなんとかなるだろうと思っていたが、なかなか道のりは険しく組織上位層の理解や協力がなければ難しいのではないかという気がしてきた。特に、ソフトウェアの再利用戦略であるソフトウェアプロダクトラインはトップダウンのアプローチが不可欠と言える。

今の民主党の政治の進め方は、まずマニフェストという基本方針・基本計画を記したドキュメントを作成し、それを実現することを宣言し支持を取り付け、トップダウンで具体的な実現の手段を発信するというやり方だ。

何か迷いが生じたときに立ち戻るための基本方針が活動のトップにあるのはとても大事だ。広範囲な施策を講じていけばどこかでA施策とB施策の間に矛盾が生じたり、調整しなければいけなかったりするときが来る。そういうときには基本に立ち戻って何が本質に近いのかを判断しなければならない。

しかし、何よりもこれまでうまくいっていると思うのは情報公開の姿勢だと思う。政府は今、これからやることやろうとしていること、部下に指示したことが何かを特に隠すことなくオープンにしている。問題点があればすぐにマスコミや個人から「問題だ」という情報が発信されるから、行動や発言には基本方針と矛盾がないようにしておかないといけない。また、指示を受けた官庁の職員達は指示の内容がオープンにされてしまっているためサボりたくてもサボれない。ちゃんと仕事しているかどうか常に不特定多数の観客から監視されている。おそらく成果が上がれば観客から「よくやった」と評価もされるだろう。

注目したいのは、この行動や成果の情報をオープンにして議論することを恐れないという点だ。今、組織内の活動で足らないのはこのことではないかと思う。目標を示し、それをリーダーが自分の言葉で語り、活動と活動の成果を逐一公開して議論をする、これが大事なのではないか。

実際の政治の世界で重要なのはジャーナリズムだと思う。複数のジャーナリストが公平な立場でいろいろな確度から施策を分析したり評価したりすることで、その施策が正しいのか、見落としている問題がないのか精査される。施策を実行している者がその情報をフィードバックすれば軌道修正できる。

ちなみに、新聞やテレビを見ている限りジャーナリストの一部は自分の立ち位置をどこにおいていいかという迷いが見られるように思う。これまで政治の世界では見えない部分の闇が必ずあったから、体制に対して批判的な要素を突っついていればジャーナリズムとしてバランスが取れているように見えた。読者、視聴者から見て体制側に日和っているように見られないような記事、報道のスタンスを必ず入れるという習慣が付いてしまっていた。

だから、闇がないアプローチ、発言を次々とされると、突っ込みどころがなくなる。そもそも、闇のある体制に日和っているように見られる心配がなくなったことに気がついていない。突っ込むべきは掲げている目標に賛成なのか反対なのか、賛成ならば目標の実現を阻害する要因は何か、目標実現の陰で不利益を被っているものはいないかという点だ。そういう報道がこれまで体に染みついてしまった習慣で体制に日和っていると感じてしまうジャーナリズムは何でもいいからアラを探そうとする。誰と誰の意見が微妙に違っているとか、裏でこんなことでもめているといったワイドショー的なネタをニュースの枠で取り上げたりする。

ともあれ、情報をオープンにして自由な議論を許容するということがこんなに大事であり、プラスの効果をもたらすのかとこの数週間感じている。もちろん、おおもとの基本計画がしっかりしていて行動がぶれないようにしないと議論も発散してしまうと思うが、トップダウンのメッセージ発信と行動の公開、ディスカッションの誘導がカイゼンに役立つように思う。

そして、意外に大事なのは誰のための活動か、施策かを常に頭に置いた上での賛成や反対のさまざまな意見をオープンに議論するジャーナリズムであり、ソフトウェアのカイゼンの世界でもジャーナリズムは必要なのだと感じている。

このブログも組込みソフトウェアの世界でジャーナリズムの一端を担うことができればいいと思う。

　

P.S.

先の衆議院選の選挙期間中自民、公明両党がインターネット上で展開した、民主党を批判するコマーシャル（ネガティブＣＭ）を見た人のうち６割以上、63.5％が、批判している自公両党に対して逆に「悪い印象を持った」という調査結果がでた。このネガティブCMはラーメン編とプロポーズ編が特にヒット数が多かった。百聞は一見にしかずでまずは YouTube でご覧あれ。

自民党はこららのCMのヒット数が多かったことからプラスの効果があると考え、次々にネットCMを作ったようだが、実は視聴者は面白いので見るけれど、作り手側の悪意に嫌気を感じたということだろう。

ジャーナリズムはただ単に相手をあげつらえばよいという訳ではない。十分な根拠を持った批判が必要だということが分かる。

ルールに振り回される日本人

日本人が本質的な目的を忘れルールに振り回された典型的な例がニュースで流れた。

制服ワッペン２万枚作り直し、３４００万どぶ…都下水道局

4月10日3時6分配信 読売新聞

東京都下水道局が昨年、制服に付ける都のシンボルマークを添えたワッペンを２万枚作製したところ、シンボルマーク使用に関する内規に反したとしてこれを使わず、新たに約３４００万円をかけて、ワッペンを作り直していたことがわかった。

　デザインは組織名の下に５センチ余の波線を付けたシンプルなものだったが、この責任を問い、都は担当幹部２人を訓告処分にしていた。内規を杓子(しゃくし)定規に解釈した「お役所仕事」の典型とみられ、公費の支出の在り方に批判が集まりそうだ。

　都下水道局では、所属する計約３０００人の職員用に、予備を含めて計約２万着の制服を作っているが、１９７８年から同じデザインだったため一新することにし、右胸に付けるワッペンも新たに作ることにした。

　ワッペン（縦２・５センチ、横８・５センチ）はシリコン製で、イチョウ形をした都シンボルマークの横に局名を記し、「水をきれいにするイメージを出したい」との願いを込め、その下に水色の波線（約５センチ）を添えることにした。職員が考案したものだった。

　ところが、約２万枚のワッペンが完成し、一部は制服への縫い付け作業が始まった昨年１１月に開いた局内の会議で、ワッペンのデザインが、シンボルマークの取り扱いについて定めた都の内規「基本デザインマニュアル」に抵触する疑いが浮上。内規には、マークの位置や文字との比率などが細かく記載されており、誤った使用例として「他の要素を加えない」と規定。同局では今回、この規定を厳格に解釈したという。

　ただ、この規定は例外も認めているが、同局では、波線部分を取り除いて作り直すことを決定。制服を含めた費用は当初、約２億１３００万円だったが、新しいワッペンの作製費と縫い替えの費用として、約３４００万円を追加支出した。

　都は今年３月、最初のワッペンのデザインを決めた担当の部長と課長（いずれも当時）を訓告処分とした。今月から制服を一新したことは発表したが、ワッペン作り直しに関する一連の事実は公表していない。

　下水道局は「事前に規定を見ていれば防げたもので、担当者のミス。多額の費用負担を生じさせて申し訳ない。次のデザイン更新は何年先になるかわからず、それまで誤ったワッペンを続けることはできなかった」と説明している。

　下水道局を巡っては、ＪＲ王子駅（北区）のトイレの汚水が、約４０年にわたって近くの川に流れ込んでいた問題で、２００７年６月にこの事実を把握しながら、対策を取らずに放置していたことが判明している。

冒頭の図の上が東京都下水道局が当初、採用する予定だったワッペンのデザインだそうだ。波線が入っていることがルールに違反している＝あってはならないという考えにとらわれてしまったわけだ。

この東京都下水道局幹部の判断について石原慎太郎知事は１０日、定例記者会見で「本当にたまげた。骨身に染みて反省するよすがにさせる」と述べ、作り直しを決めた同局の幹部らを処分する方針を明らかにした。石原知事は、この問題を報じた読売新聞を掲げながら、作り直す前のデザインについて「東京の下水はきれいだなって感じがするし、いいじゃない」とし、「規格に合わないからと作り直して、バカじゃねえかほんとに」と怒りをあらわにしたそうだ。

このニュースを聞いてたしかに「バカじゃねえか」と感じたが、実はこのような「バカじゃねえか」という話しは身近でよく見かけると思った。

この話しには日本人特有の2つの問題があると思う。ひとつは「組織やプロジェクトを構成するメンバーが組織やプロジェクトの目指す目的について十分に意識していない」ことと、もう一つは「組織やプロジェクトを構成するメンバーがルール作りに参加しておらず、ルールを改善することができると考えていない」ということだ。

【組織やプロジェクトの目指す目的について十分に意識していない】

ようするに組織目標という遠くにあるゴールを見ずに、自分の直近にあるものしか見ないため近視眼的な思考となり結果的に、遠くにある組織目標に背反するような判断や行動を取ってしまうケースだ。

東京都下水道局のホームページを見ると経営計画2007というページに以下のような3つのスローガンが掲げてある。

○安全で快適な都市生活をめざして　

○お客さまサービスの向上・経営効率化の取組

○危機管理対応の強化・地球環境保全への貢献

職員が組織内で一つ一つの判断をする際に、この3つの目標を常に頭に入れておいて、これらの目標に向かった行動になっているかどうか考える癖をつけていると今回のような問題は起こらなかったと思う。

都の内規「基本デザインマニュアル」でマークの位置や文字との比率などが細かく決め、使用例として「他の要素を加えない」と規定したのは、シンボルマークの基準を定めることによって、一般市民がシンボルマークによって都の各部門とその責務を一目で判断でき、分かりにくかったり、勘違いすることを防ぐことが目的だったと推察される。

一方で東京都下水道局の文字の下に水色の波線（約５センチ）を添えることにしたのも「水をきれいにするイメージを出したい」との職員のアイディアであった。どちらも、東京都民へのサービス向上が目的だった。

それに比べて、約３４００万円を追加支出してワッペンを作り直すという判断は、結果的にユーザーである都民の税金を無駄にすることになるから、組織目標であるサービス向上の目的にそぐわない。

こういう一見どっちを取るべきか判断が難しい事例は日々組織の中で発生している。本末転倒と思われる顧客の利益にならない小さな誤った判断、行動は組織の中で意外にも頻繁に発生している。「これはセクショナリズムだ」と思ったときは、組織目標に照らし合わせると顧客満足の向上を疎外するような判断や行動がなされていることが多い。

この違和感をすばやく察知できるようになると組織の中のどこを改善すると流れがよくなるのか、組織目標の達成率が高くなるのかが見えてくる。（組織目標というのは目標売り上げ達成というような低レベルの目標ではなく、顧客満足の向上や社会貢献といった本質的な目標のことなのでお間違えなく）

組織目標や組織のポリシーと自分の中にある価値観がオーバーラップしていて、組織の価値と個人の価値を一部でも共有できていれば、いつも正しい判断ができる確率が高くなる。ただし、組織の目的が金儲けで、個人の目的も金儲けというようなケースではいくら価値観が共有できていてもいい方向にはいかない。

上司から命令されたからとか、クライアントからの要求だからといった近い視点ではなく、その判断や行動はエンドユーザーの利益になるのかどうかという視点を常日頃持っていると、確実にプラスの実績が積み重なっていく。そうでないと、やったけど役に立たなかったとか無駄だったというマイナスの実績ができてしまう。ソフトウェアエンジニアとしての活躍できる時間は限られているため、日々の活動はプラスの実績につながるようにしていかないといけない。

【ルール作りに参加しておらず、ルールを改善することができると考えていない】

ルールは天から振ってくるものであり、絶対に守らなければいけないと信じ切っている人をよく見かける。外部のセミナーに行ってきてセミナーの講師から「これこれを守らないと大変なことになりますよ」と恐怖心を植え付けられてきた担当者は、ルールの本質を外れて枝葉末節にこだわり始める。組織内で改善活動を行っている者にとっては、この手の話しは自分達の活動に水を差されることがよくある。

セミナーの講師やツールベンダーの営業の一部の人は、自分達の売り上げを確保したいために、必要以上に法律や国際基準、業界ルールを強調して、それを守らないと大変ですよと吹聴する。それを真に受けた担当者が過剰反応すると開発の現場にそのしわ寄せがくる。

そもそもの法律や国際基準や業界ルールが作成された背景はすっとばされて、○○した方がよいという文言は、末端にいくにつれいつのまにか○○せねばならないという強制の言葉に置き換わってしまったりする。

法律だって時間がたてば、時代にそぐわなくなって修正しなければいけないときがくる。国際基準や業界ルール、組織ルール、プロジェクトルールだって同じだ。組織の目標を達成するためにルールは常に改善する必要がないかどうかを考えている必要がある。

日本人は自分達で自分達が守るべきルールを作るということがどうも苦手なようだ。自分にはルールを作る権利があるという意識も低いし、その権利を行使しなければ自分が損をするという意識も薄い。たぶんデモクラシーの教育や文化が弱いのだろう。（誰かが決めたルールに従うのが普通と考える日本人としての国民性もある）

そういう環境に慣れてしまうと「ルールは変えられるもの」という感覚がほとんどなくなり、まじめであればあるほどルールには絶対に従わなければいけないと思い込んでしまう人がたくさんでてくる。

実は自分はこの日本人の特性を理解した上で、その特性を利用している。組織内で支援活動をするときに相手のルールに対する考え方見定めてこちらの攻め方を変えているのだ。

例えば、「ルールは絶対」と考えている技術者に対しては、必要な活動の目的よりもルールの方に重きを置いて指導、支援し、やることが決まっている以上やらなければいけないよという持って行き方をする。そして、その活動がプロジェクトに浸透したところで、ルールの向こう側にある本質的な目的を伝えて、何をどう判断するのか、どういうときにルールを逸脱していいのかを説明する。

一方で「ルールなんかくそ食らえ」と考えるチームには、逆にルールの向こう側にある本質について説明し、その本質が目指している価値とチームの目指す価値は一致している筈であり、そのために必要な活動であると諭す。そしてその結果ルールに沿った取り組みとなると説明する。

どっちにしても、必要な活動をして、最終的な目標（顧客満足の向上や社会貢献）につながればいい、そう考えれば、最善の判断、最善の行動は何か自ずと見えてくるはずなのだ。

　

人と人をつなぎまくると物事はスムーズに流れる

今日の話題は、『人と人をつなぎまくると物事はスムーズに流れる』というテーマで、「あたたかい人間関係の中のやさしい一員」という特性を持った日本人が形だけ「創造性と個性にあふれた強い個人」のシステムを使おうとするとどうなるかという一例を紹介したい。

さて、今日「TBSラジオの久米宏　ラジオなんですけど」を聞いていたら、大分トリニータの社長 溝畑宏さんがゲストに来ていて、大分トリニータがナビスコカップで優勝を遂げ、地元に定着して地域振興に貢献するようになるまでの苦労と、サッカーチームをベースにして地域振興にかける溝畑さんの熱い想いを語っていた。

溝畑さんは、東京大学法学部卒、１９８５年自治省（現総務省）入省、１９９０年大分県に出向して、役人らしからぬ強い思いで大分をサッカーで盛り上げようと考える人だ。2006年に総務省を退職して、大分トリニータの社長として身を粉にしてチームと地域のために働いている。

お父様は溝畑茂　京都大学名誉教授、お母様は放送局のアナウンサーだったそうだ。父からは「厳しい道と楽な道があったら、厳しい道を選べ」と言われ、母からは「下を向かずに上を見て目立ちなさい」と言われて育った。

若干30代中盤の溝畑さんが大分で大分トリニータの設立等を進めているときに、県のお偉いさんたちに「溝畑さん、田舎では身の丈以上のことをしようと思ったらダメなんですよ」と言われカチンときて「あんた達の身の丈はこれくらい(20センチくらい）かも知れないが、自分の身の丈はこれくらい(2メートルくらい）なんだ。そんな考えだから、地方が活性化しないんだ。」と叫んだそうだ。

その後の溝畑さんの活躍を見れば分かるように、溝畑さんは「あたたかい人間関係の中のやさしい一員」という特性を持った日本人の環境の中で、親から教えられた「創造性と個性にあふれた強い個人」のとしてのリーダーシップを発揮することで、閉塞した環境をブレークスルーしたと考えられる。

今、まさに不況のまっただ中でプロサッカーチームを運営するのは非常に苦しいらしい。しかし、溝畑さんは「逆境よ、ようこそ」という気持ちで、人の3倍働くことで乗り越えるつもりだと語っていた。これまでも7回ほど、もうダメだという逆境があったが、それを乗り越えることで成長してきたと言う。逆境がなければこれほど成長もしなかったと。

今回の話しは、溝畑さんの話に比べるととてもスケールの小さいちっぽけな話しだが、本質は近いところがあるように思う。組織内で問題解決のためのシステムがうまく機能せず、人と人をつなぎまくって問題を解決したという話しである。「創造性と個性にあふれた強い個人」の世界で構築されたシステムを「あたたかい人間関係の中のやさしい一員」が導入しただけでは物事は流れていかないという例だ。

さて、例えば、ある組織で組織内のインフラをサポートするための部署を作ったとする。ITが発達した今日、対外的なITサポートも増加する一方、組織内のITサポートも個々の担当者レベルでは対応しきれなくなってきた。

そこで、ITサポート部隊は会社対会社で行われているようにサポート窓口（電子的な窓口）を作って、そこからいろいろなリクエストを受け付け対応するようにした。昔なら依頼書で動くところを、電子的な申し込みに対して、電子的に回答をするというシステムだ。やりとりの履歴がすべて残るので後々データを整理したりする際には便利である。

そこで、ITインフラを担当する部門に動いてもらわないと解決しない問題が発生した。いろいろな問題が絡み合っているのは分かっているが、残念ながら担当部門の中で誰が何の役割を担っているのか分からない。普段なら問題の解決についての情報を知っている人にあたりを付けて、そこにアクセスしながら情報を探り全体像を明らかにしていくのだが、今回に限って言えば誰にアクセスすればいいのか今ひとつ見えてこない。そこで、電子的なサポート窓口を使って調査依頼を出した。

後で分かったのだが、担当部門には複数のチーム（例えばAチーム、Bチーム、Cチーム）があり、今回の問題はBチームとCチームが動かないと解決できない問題だった。ところが問い合わせを受けたAチームは解決すべき問題の全容を理解していないため、BチームとCチームに相談することをせず、部門内でも電子システムをメッセンジャーとして使い、解決したい目的を理解せずに現象だけをBチームやCチーム別々に伝え、埒があかないという現象が発生した。

相手がブラックボックスの組織ならどうしようもないが、同一組織内の他部門ならもっとなんとか打つ手はあるはずだ。結局、いろいろなことを聞きまくることで、BチームとCチームが問題解決に関係していることがわかり、彼らに直面している障害を伝え協力してもらうことで問題は解決するめどが立った。

実は、この件は自分自身の直接的な業務の問題ではなかった。ある開発現場の効率を高めるために取り除く必要がある障害だった。当事者ができないことを解決する方法が分からなくてあきらめているのをみて、コーディネートしたのだ。「あたたかい人間関係の中のやさしい一員」の技術者は自分達の不便は自分達が我慢することで何とかなると考える人たちが大勢いる。「あたたかい人間関係の中のやさしい一員」のマイナス面だ。顧客満足向上という遠くの目標達成のために、取り除くべき障害があっても、そのままにして効率の悪い状態を放置してしまうのだ。こういう状況は放置しておくと巡り巡って技術者自身の残業の増加や顧客に対するコストアップなどの不利益となって降りかかってくる。結果的に不利益が生じることをはっきり認識している訳ではないので未必の故意(※)とは言えないかもしれないが、決してほめられたことではない。

※未必の故意 - 実害の発生を積極的に希望ないしは意図するものではないが、自分の行為により結果として実害が発生してもかまわないという行為者の心理状態。

このような各部門の各技術者が抱えているちょっとしたあきらめを見つけて、誰がどこまでを認識していて何を認識していないのか、誰と誰を結びつけると解決しそうかを調査して、関係者が断片的に持っている情報を総合的に分析して人と人をつないであげると物事がスムーズに流れ改善が進む。

誰と誰をつなぎ合わせると問題を解決できるのか分かってくると、逆にどうしてこんな簡単なことで多くのことが滞っているのか、改善の機会を止めてしまっているのかが見えてきて、そんなくだらないことで立ち止まっているのかとだんだんバカバカしくなってくる。

同じ部門内の中でちょっとだけ話しをすれば解決できる問題も、システムを通すとつなぎがうまくいかなくなることがある。これはシステムを都合良く利用しながら、システムを隠れ蓑にして問題解決の勇気や義務を放棄して「あたたかい人間関係の中のやさしい一員」の特長を殺している人間がいるからなのだ。

システムが組織内でうまく機能しない場合は、うまく言っていない点を報告し是正を要求する。これを繰り返すことで、システムは生き続けることができる。改善のプロセスが重要視されているのはそのためだ。逆に言えば、改善のプロセスを回すことができない組織がシステムを導入するとシステムは必ず形骸化する。システムの裏で技術者は「あれは役に立たない」とささやきながら、自分達のやり方で物事を進めようとする。

「創造性と個性にあふれた強い個人」の世界では責務を果たしていない個人や部門があることが分かったら、状況を発見した個人や部門には是正を要求する義務がある。是正を要求しなければ改善は進まないというシステムなのだ。それを理解していない組織はシステムを形骸化させる。

何からしらの「システム」を導入して、なぜうまくいかないのだろうと悩んでいる方がいたら、「あいつらが自分達の責務を果たしていないから」と愚痴を言っているのではなく、是正を要求しないとシステムの本来の効果が活きてこないし、放っておくとシステムが腐ってくる。

システムを改善していくのもいいが、日本人の「あたたかい人間関係の中のやさしい一員」という特長を活かすのなら、まずは人と人とをつなぐことで問題を解決することを推奨したい。単に人と人をつなぐだけでなく、AさんとBさんがいがみ合っている場合は双方に「あちらは、こちらがこんな事をしてくれるととても助かる、いつも感謝しているといっていましたよ」などと言うと流れがよくなることがある。「あたたかい人間関係の中のやさしい一員」の世界では是正を要求するよりも、問題解決に必要な人と人をつなぐ方が改善が進むスピードが速いことが多い。

「あたたかい人間関係の中のやさしい一員」の特性を活かして、物事を滞らせている原因を探偵になったつもりでヒアリングにより調査し、人と人とつなぎまくることで情報の流れをよくし問題を解決する。これがうまくいくと、うまく行かなかった原因がいかにバカバカしい小さなことであるかがわかり、「あたたかい人間関係の中のやさしい一員」の世界で必要なリーダーシップとは何かが見えてくる。コーチングとかティーチングといったテクニックではなく、当事者達とコーディネータとなる自分という関係性の中で、どの情報を誰にどうやって伝えれば問題解決するのか、ケースバイケースで最善策を考える。

「あたたかい人間関係の中のやさしい一員」の世界の中で人と人とつなぎまくることで、問題が解決されると、つなぎまくって問題を解決した人はそれまで困っていた人たちに感謝される筈だ。セクショナリズムが蔓延し、たこつぼ状態になっている組織では、コーディネータの役割を担おうと立ち上がった者が「これは自分の仕事ではない」とか「自分が動くとバカを見る」と思ってしまうと組織の硬直化はますます進んでしまう。

そうなると、コーディネータのエネルギー源は、困っている人の問題が解決したときの当事者からの感謝の言葉や、顧客満足を高めることができたときの満足感でしかないのだ。コーディネイトすることで問題解決を請け負っている人はコーディネイト成功の感謝の気持ちを対価に置き換えることができるが、組織内の場合はお金は動かないから感謝の気持ちを糧にするしかない。

「人と人をつなぎまくると物事はスムーズに流れる」、これは「あたたかい人間関係の中のやさしい一員」の世界だからこそ有効なアプローチだと感じる。逆に「人と人をつなぎまくると物事はスムーズに流れる」が通りにくい組織は黄色信号が点っていると考えた方がいいだろう。日本では人と人をつなぐ心やその役目を担う人がいないとせっかく導入したシステムもいずれは死んでしまう。死んでしまったシステムの利用者達にヒアリングして調査すればセクショナリズムやたこつぼ化が組織に蔓延しているのがわかるはずだ。

PS.

「創造性と個性にあふれた強い個人」と「あたたかい人間関係の中のやさしい一員」の元ネタを知りたい方はこちらの記事をお読みください。

　

カイゼンの範囲

日経ものづくりのセミナーで『トヨタ流モノづくりの人づくりの心　伝承塾～中堅社員コース～』というのが載っていた。（申込み受付は終了したとのこと）

講師はトヨタ自動車TQM推進部課長の方で、社員のやる気向上を基本に人財育成、国内企業の繁栄の為の社会貢献活動を行い「トヨタ流：モノづくりと，人づくり 心の伝承塾」を設立し，社内外を問わず精力的に講演活動を実施しているのだそうだ。

トヨタが惜しげもなく自組織での事例を外部に紹介するのは、このようなセミナーを通じてまったく違う業種、業務の人たちが行っている活動からトヨタ自体が得るものも大きいかららしい。

この話はソフトウェアエンジニアが組織の外で直接的な企業活動とは別にコミュニティ活動やIPA SEC（ソフトウェアエンジニアリングセンター）の活動などをすることにも通じる。

組織の外に出て、自分たちとは違う環境の人たちの活動や考え方、成功体験、失敗体験を聞くのは技術者個人の刺激にもなるし、いずれは自組織の改善にも役立つと思う。

でも、組織への貢献の度合いを数字で表すのは難しいので、組織の外で何らかの知見を得たことがない上司しかいないと、部下がそのようなコミュニティ活動したいといっても許可してもらえない場合がある。

組織の外には役に立つ情報があふれている（役に立たない情報もあふれているが・・・）のに、それらを利用せずに自分たちだけで解決方法を見つけようとするのはとてももったいない、非効率的だと思う。

さて、トヨタのセミナーの話に戻ろう。以下、セミナーの目次の一部だ

【トヨタ流モノづくりの人づくりの心　伝承塾～中堅社員コース～ 目次より引用】

2.【「お客様第一」の本質とは何か，その大切な心について】
【A】企業や社員が戦う相手は何か？
【B】お客様の心に感動につながる仕事をしてこそ，成果が認められる
【C】商品の品質不良と，そのトラブル対応の重要性について

＜トヨタの事例紹介＞
（1）｢１本の電話応対で３億円の仕事を失った話」
（2）「嫌われ，つまはじきにされた一人の社員が会社をナンバー１にさせた」
＜一般事例紹介＞
（1）「デパートに夢を買いに来たお客様への心ない店員の対応」
（2）「風呂場の掃除作業員が，日本一のゴルフ場にさせた話」
（3）「お客様の心に感動と言う商品を提供した店員の話」
（4）「レストランの店員のルールを破ったまごころの対応」


5.【仕事の業績を上げる職場改善の基本】
【A】問題解決に重要な「現地現物」の行動
【B】改善の基本は徹底した「なぜなぜ」の追求
【C】現場改善のネタを見つける方法
【D】職場にある７つのムダ
【E】「4Ｓ」の心と必要性について
【F】生産品質の管理と改善について
【G】新技術創造の環境づくりと発想のコツ

【引用終わり】

セミナーの目次を見ただけでも、ためになりそうな話が満載のようだ。でも、残念ながらこのセミナーに参加する予定はない。

さて、今回の記事で言いたいことは改善の範囲のことだ。あまり深い掘り下げはない。

何が言いたいかというと、改善を実施し顧客満足を高めることを考えるときは、メーカーだけでなくサプライヤーも含めて考えて欲しいということだ。

自分は現在メーカーに所属しているが、ソフトウェアを発注している会社を「外注」とは言わず「協力会社」と言うようにしている。「外注」ということばには何か見下したような響きを感じるからだ。

自分は協力会社のソフトウェア技術者の中に非常に優秀な人が何人もいるのを知っているし、彼らと仕事をすることでこれまで何回も助けられたし、何年も一緒に仕事をしていると仲間意識も強くなった。

サプライヤーはその名の通り供給者という意味で、ソフトウェアを請負契約で発注して、ソフトウェア（部品）の供給を受けるのでサプライヤーと呼ぶ。

大きな組織になると、メーカーは納期短縮のツケを結果的にサプライヤーに押しつけることになることがあると思う。発注者と受注者の関係があるためどうしても受注者の方が立場が弱くなる。

しかし、メーカーはサプライヤーの協力なしに顧客満足の向上を達成することはできない。メーカーのエンジニアだけが顧客満足の達成を実感し、サプライヤーは黙々と仕事してその対価としてサラリーをもらうという構図は何とかなくせないのだろうか。

そしないと、このブログで再三主張しているように、組込みソフトエンジニアのモチベーションの源泉を、実際に組込み機器を使ってくれる顧客の満足に重ねることができるのはメーカーの技術者だけで、サプライヤーの技術者には関係のないことになってしまう。

現場で製品作りをしてきた者にとって、メーカーの技術者とサプライヤーの技術者にそれほど大きな違いはないとずっと感じていた。むしろサプライヤーの技術者にも、その製品がどのようにユーザーに使われるのかをよく知ってもらった方が、よりよい製品、顧客満足の高いソフトウェアを作り上げることができると思っている。

だから、自動車でも携帯電話でもなんでもいいが、メーカーはサプライヤーのエンジニアを仲間であるという意識を持って、ソフトウェア開発に関するカイゼンの範囲に含めて考えるべきだと、『トヨタ流モノづくりの人づくりの心　伝承塾～中堅社員コース～』の内容を見たときにふと思った次第である。
　

高品質を生み出す日本の原動力

安全・安心は商品における大きな価値である。いつもは見えないでいるだけ。このような品質のことは当たり前品質と呼ばれ、自分は表面的に見える商品の顕在的価値と対比するために潜在的価値と呼んでいる。そして、当たり前品質や潜在的価値は、商品に関する不具合が発覚したり事故が起こったとき、すなわち安全や安心が失われたときに初めてその価値が知らしめられる。

もともと日本人は高い品質を好み、その重要性を認識し、高品質の商品を作り出せる民族である。意識的に強いコントロールをしなくても、少しだけサジェスチョンを与えてあげれば何をすべきかを理解できるし、自然とやるべきことがプロジェクト内に伝搬する。別な言い方をすれば、低い品質をよしとしない、品質の低い商品をお客様に提供する行為は恥であると考え、そのような事態が起こったときは再発防止を強制されなくても自ら進んで行う国民性を持っている。

品質の低さや自分自身のミスを恥であると感じ、指示されずとも自浄努力を行う性質は、『アメリカ人と日本人』の記事で書いた日本人の「あたたかい人間関係の中のやさしい一員」という性質とも相性がよい。

このことは、品質の高い製品を生み出す非常に強力な日本のアドバンテージではあるが、そのような国民性を持たない土壌で生まれた品質向上の方策とうまく融合しない場合がある。

例えば、高品質を維持するための方法として、ISO9001などの品質マネージメントシステムの国際標準が存在する。そして、ISO9001の中で高品質を維持する取り組みとして、内部監査というアクティビティがある。

内部監査は品質マネージメントの教育を受けた監査員が定められたルール通りに組織が行動しているかどうかを組織内部の人間同士で監査し、ルールからの逸脱を見つけた際には是正を勧告して、是正処置が確実に浸透したことを監視するという活動だ。

この品質システムマネージメントのアクティビティを「低い品質をよしとしない、品質の低い商品をお客様に提供する行為は恥であると考え、そのような事態が起こったときは再発防止を強制されなくても自ら進んで行う」という気質の組織に適用するとどうなるか。

自ら気がついてユーザーに対する恥を回避する気質を持っているにもかかわらず、明示的にかつシステマティックに重箱の隅をつつくような感じで問題点を指摘され、是正が完了することを管理されると、自らの自浄努力を無視され、組織から自分達は信用されていないと感じ、やる気をなくしてしまう技術者がでてくる。

そして、その状態が定常化すると、品質マネージメントシステムが結果的に形骸化する。技術者サイドの心理としては、「自分たちは自分たちのやり方で十分に高品質を維持できている」「我々を信用しない（性悪説）のシステムを押しつけるのなら、表面上だけ繕っておこう」「（監査する奴らは）現場を知らないで理想論を押しつけようとする」といったものになっていく。

日本の組織において、ISO9001が形骸化しやすく、TQC（Total Quality Control）が成功しやすい理由は、このような日本人の気質からくるのだと考えられる。簡単に言えば、技術者を性悪説で眺める西洋的なアプローチは日本人の技術者のモチベーションを下げる傾向にあり、性善説に基づいた自浄・改善を促すTQCのようなアプローチは日本では有効性が高いのだと思う。

トヨタ自動車がISO9001を採用せずに、独自のトヨタ式改善アプローチを進めているのは、そのことがわかっているからではないだろうか。

ISO9001における内部監査のようなアクティビティを使って品質マネージメント力を高めていくには、責任と権限を明確していくことが不可欠であり、是正を要求されたプロジェクトや当事者が「自分が責められているのではなく、是正を要求しているのは品質に対して責任を持った部門や担当者が、ルールに基づいてその責任を果たしている」と考え、是正の指摘を「恥」と考えずにシステマティックに対応していく必要があるルーチンワークだと考えなければいけない。もともと、「創造性と個性にあふれた強い個人」の世界で生まれたシステムなので、品質に対して責任を持ったものがその権限を使って、是正や再発防止を指導しいるとサバサバと処理していかなければ、品質マネジメントシステムは正常に回っていかない。

ところが、日本の技術者は責任や権限が曖昧なままでも「あたたかい人間関係の中のやさしい一員」という性質を使って、製品開発を成功させ、サービス残業をしてでも、恥をかくような仕事をしたくない（裏を返せば満足のいく仕事をして認めてもらいたい、喜んで欲しい）と思いがんばる。

そうやってがんばって高品質の商品を作り上げているにもかかわらず、一見役に立たないように見えるルールを盾にルールからの逸脱を責められ、是正を求められると、組織上位層やQA部門への不信が生まれ、溝ができてしまう。ボトムアップで高品質を確立してきたという自負があればあるほど、トップダウンでかつ現場での自浄努力を認めないかのようなやり方に反発がおきる。頭の中では違うと分かっていても、是正の指摘に対して恥をかかされたと条件反射的に感じてしまうのだ。

このような事態に対して、自分は半分は現場サイドの肩を持ちかわいそうだと思いつつも、半分は現場サイドの方が間違っていると考える。

半分間違っていると考える理由は2つあって、「恥の文化」と「あたたかい人間関係の中のやさしい一員」の性質で高品質の組込みソフトウェアをアウトプットできるソフトウェアの規模には限界があるということと、グローバルな商売をやっていくのなら文化の違いを超えて自分たちが作った成果物の品質が高いことを世界標準の方法で説明する責任があると思うからだ。

「恥の文化」と「あたたかい人間関係の中のやさしい一員」という日本人の性質で高品質のソフトウェアを維持・開発できるのは、30万行くらいまでのソースコード量、30人くらいのプロジェクト規模だろう。

それを越えたら、好きとか嫌いとかいうことではなく、システマティックな品質マネジメントの方策をとらなければ組込みソフトを高品質に保つことは難しい。

また、日本の組織にありがちなのはソフトウェアの品質が高いという自信はあるが、どうして高品質なのかを論理的に説明できないということだ。日本人の気質が商品の高品質を保っているという説明では、世界は絶対に納得しないし、日本の中でも他の組織からは納得してもらえないであろう。納得してもらえるのは、そのプロジェクトメンバの顔や性格をよく知っているいる人だけだ。（要するに人的要素で品質を保っているということ）

今日本の組織で組込みソフトの品質に赤信号が点り始めているのは「恥の文化」と「あたたかい人間関係の中のやさしい一員」だけで組込みソフトの品質を維持している組織、ISO9001などの欧米から来た方策が形骸化しつつある組織、TQCのような問題点を自分自身で見つけて改善する活動が行われていない組織だ。

このような組織に必要なのは次のようなことだと思う。

【日本の組織が組込みソフトの品質を高めるために行うべきこと】

1. 商品に求められる当たり前品質（潜在的価値）を認識すること
2. ISO9001などのアクティビティの本質（顧客満足を高めること）を理解すること
3. 日本人の気質と欧米人の気質の違いを理解すること
4. 日本人の気質を活かした改善活動を行うこと
   

みなさんの組織はどんな状況だろうか。

P.S.

今の若い人たちは、商品が当たり前にできていることの後ろにある技術や努力を見抜く力が弱いように思う。それは、商品のマーケティングや広告が進んで、ユーザビリティを向上させることに成功し、何も考えなくても商品を安全に安心して使えるようになったことの弊害だとも言えるが、その結果、商品を開発している作り手側の技術や努力が表面的には見えなくなってしまった。

しかし、当たり前品質（＝潜在的価値）の存在に気づき、その品質を実現している技術を見抜き、それが当たり前に実現できているこに感動できるエンジニアにならなければ、潜在的価値を高める技術を身につけるモチベーションにつながらないと思う。
　
　

組織にもの言える技術者になろう2

Tech-On! にリコー 社長　近藤 史朗 氏のコラム『旧来の手法では最先端の製品は開発できない』が載っていた。

【『旧来の手法では最先端の製品は開発できない』より引用】

　・・・設計者というのは変な話ですが「体を使う」と，ものすごく仕事をした気になるんです。分かりますでしょうか，この言い方で。例えば，発売日に間に合わせるためにみんなで徹夜して頑張ったとか，会社の言うことに逆らってプロジェクトを進めたとかいうエピソードは，多くの会社にあると思います。そして，最終的にはプロジェクトが成功に終わる。これが体を使うという感覚です。しかし複写機の場合，昔のような少人数のプロジェクトチームが徹夜して仕上げるようなやり方では，もう最新の製品は開発できません。

　僕が現場の最前線で開発に取り組んでいた時は，本当に少数の部隊で商品開発をやっていて，不眠不休でやるっていうのが当たり前でした。新製品の開発なんだから，そうやるものだという思い込みもありました。しかし，今のリコーで一切そういうことは許さない。そうしたやり方は悪だと宣言しています。

【引用終わり】

複合複写機の世界では1990年代に従来の力ずくのソフトウェア開発では立ちゆかなくなったため、各社ともオブジェクト指向設計を含むソフトウェア開発手法の改善を行ったと聞いている。おそらく、システムソフトウェアの規模が30万行を超えたのだと思う。

その過渡期を経験し、「このままではダメだ」と実感したことのある人がトップになるとこのような発言ができるのだろう。うらやましい。

逆に言えば、システムの規模が30万行を越えてきているのに、徹夜を美徳としているようなトップなら悪循環が一層進みかねない。

そんな環境下でエンジニアが目指すべきことは何か？

それは、技術を磨いてどんな環境でも通用するエンジニアになり、組織の中において個人商店として成り立つように立ち振る舞うことだと思う。

自分自身が個人商店だと考えれば、自分に仕事を振ってくる他部門や上司は大切なお客様であり、彼らが満足する仕事をアウトプットすることで対価を稼いでいることになる。

そんな一番近い位置にいる「お客様」に面と向かって文句を言っていいのは、彼らがエンドユーザーの不利益になるようなことを依頼してきたり、命令してきたりしたときだ。

簡単に言えば「偽装を指示された」ようなときだ。そこまではっきりしていなくても、セクショナリズムからくる意地の張り合いなどでエンドユーザーの利益にならないことを平気で指示するような上司はいる。

こういうときは我慢せずに言いたいことを言う。そういうことが積み重なるようならしかるべきところに直訴すべきだし、それでもだめならあまり迷わずに組織を出た方がよい。

そのとき拾う神があるかどうかは、自分自身が技術を磨いてきたかどうかにかかっている。

理系は文系よりも出世が遅いと理系白書に書いてあったが、理系の中でもソフトウェア出身の技術者が組織の上位層に上がるのは遅いかもしれない。組込みソフトエンジニアはものわかりのよい上ばかりではない世界だということを認識しつつ、組織の中における自分の立ち位置をどこに持って行くべきかを考える必要があると思う。