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

日経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 の実施に先立って、ユーザーリスクに焦点を絞った安全分析が必要となる。

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

和製ピープルウエア

今回リリースした本『リコールを起こさないソフトウェアのつくり方』が、和製ピープルウエアなどというと見識者から「何を思い上がっているのか」と怒られそうだが自分自身はそう思っている。

今回はなぜ、そう思っているのかについて書いてみたい。

『ピープルウエア』（原著：Peopleware: Productive Projects and Teams）はトム・デマルコ と ティモシー・リスターが1987年（23年前）に書いた名著で、今でも多くのソフトウェア技術者に読み継がれている。『ソフトウェア開発の名著を読む 【第二版】』の中でも紹介されている。

トム・デマルコは、構造化分析手法の考案者としても有名だ。 『ピープルウエア』が他のソフトウェア系の書籍と一線を画しているのは、ソフトウェアに焦点を当てるのではなく、ソフトウェアを作る人に焦点を当てていることにある。

最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、1980代当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はほとんどなかった。

さて、そもそも自分の卒論のテーマは「脳神経系のシミュレーションモデルの作製と検証」だった。今から冷静に振り返ると、このテーマは高校生の時代に読んだ日本の脳科学者の草分けである東京大学医学部教授/京都大学霊長類研究所教授の時実利彦先生の本「脳の話」に感化され、これもまた脳神経科学者の井上馨先生の『脳の情報処理』で紹介されていたモデルをシミュレーシ実験で再現しただけの研究だったのかもしれない。大学生の卒業論文としてはそれくらいが精一杯だった。ただ、当時の自分としては人間の思考回路とコンピュータの情報処理の方法について探求心をもって調べていたので、このこと自体はよかったと思う。

このときの研究内容をベースにした読み物については　『Software People Best Selection』の記事 「人間の考え方,コンピュータの考え方」p226-p234に掲載している。

そんなこともあってコンピュータの合理性、論理性と人間の非論理性の違い、その狭間にいて時に苦しむソフトウェアエンジニアの立場について常に考えてきたし、自分自身も20代、働き盛りのころ人間の思考や行動もコンピュータと同じように論理的に分析すれば分かるなどと考え、現実はそうではなく、その結果人間不信となり精神的に苦しんだ時期もあった。その後、カウンセリングを受けたり心理学を学んだり、河合隼雄さんの本（お気に入りの本は『こころの処方箋』）を買い込んで読みふけり、そもそも人間は臨床的にはまったく論理的ではないことを理解した。（トム・デマルコが　JaSST'04　で来日したとき、基調講演の後の質問コーナーで三十代最後の自分が「ソフトウェアエンジニアがカウンセリングを受けるのはアメリカではふつうのことか」などという突飛な質問をしたことを覚えている。トム・デマルコならきっと分かってくれると思ったのだろう。）

しかし、卒論でコンピュータと人間の脳の情報処理の方法がまったく違うことを研究していたにも関わらずソフトウェアエンジニアとしてバリバリ仕事をしていてうまくいけばいくほど、自分はコンピュータも人間も論理的であると勘違いしていた。そうじゃないっていうことを研究していたのに、自分自身のことに置き換えることができていなかった。だからこそ、人間の脳は論理的でないといえるのだ。

【こころの処方箋－こころの中の勝負は51対49のことが多い－　より】

中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。

あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。

こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。

51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。

【引用終わり】

人間の脳神経の情報処理の仕組みはコンピュータとはまったく違うし、その素子の数が非常に多い（140億以上といわれている）し、人体実験するわけにはいかないから、情報処理システムとしての構造、動作についてはまだ十分に解明できていない。

ジェフ・ホーキンスは Palm ComputingとHandspring の創設者で Palm OS の開発者で、その後、神経科学の研修者となりレッドウッド神経科学研究所を設立した脳科学研究者である。そのジェフ・ホーキンスが『考える脳 考えるコンピューター』で最先端の脳の情報処理の仕組みを記している。（Palm Computing 社でビジネス的に成功を収めたのにそれをすべて捨てて研究者となったところがすごい）

この本を読むと脳神経学の積み上げによって、実際に人間の脳の中で起こっていることを科学的に解明するのがいかに難しいかがわかる。でも、ジェフ・ホーキンスは脳神経学と臨床心理学の間を埋めるべく、仮説と論証と積み重ねてそのしくみについて分析をしており納得のいく内容になっている。

そんなこんなで、自分の中ではソフトウェアの論理性とそのソフトウェアを日々作っている人間の非論理性を常に意識しているつもりだ。そして、自分自身がプロジェクトの中で、もしくはプロジェクトリーダーとして振る舞うのではなく、他人のソフトウェアプロジェクトを支援する立場になって、さらに「人間の脳が論理的ではない」という問題・現実を認識しながら行動しアドバイスしなければいけないことを痛感している。

そして、そこで培った体験を踏まえつつ抽象化され責任と権限が明確な世界で体系化されてきたソフトウェア工学を日本のソフトウェアプロジェクトでどう適用していくべきかについて書いた。だからこそ本人としては『リコールを起こさないソフトウェアのつくり方』は和製ピープルウエアの“つもり”なのだ。

『リコールを起こさないソフトウェアのつくり方』では、もちろんソフトウェアの安全や信頼を実現する方法論についてもきちんと書いているが、それ以上に方法論に乗っかるだけでは安全や信頼を確保することはできないということも切々と語っている。

そう言い切れるのは自分が人間の脳神経系のしくみについて過去の研究者の研究成果を読んでいるからだと思っている。どうしてもこのようなテーマは比較文化論的な切り口になってしまうが、できるだけ客観的に議論するための資料も掲載しているので、このような背景を理解しながら読んでいただくと著者の意図が伝わると思う。

リコールを起こさないということ

本はリアル書店でもインターネット書店でもまず手にとって興味を示してもらわなければその他の本の中に埋もれてしまい誰にも目に触れずに日の目を見ることなく消えてしまいます。だからこそ、手にとってもらうために奇抜なタイトルを付けます。

タイトルに引かれて本を購入した読者に「タイトルに騙された」と言われないために、まじめにソフトウェアの安全や信頼を実現する方法を提案していることを分かったもらうために、このブログで本の一部を紹介していきたいと思います。

【『リコールを起こさないソフトウェアのつくり方』　本書を読む前に－リコールを起こさないということ－より】

ソフトウェアでリコールを起こすということはソフトウェア製品やソフトウェアが搭載された機器の価値を低下させることに他なりません。そのソフトウェアやソフトウェア搭載製品の価値がもともと非常に高かったり、多くの人が使っているものであったり、人の命に関わっていたりすると、利用者に大きな不利益がもたらされ、その後始末をするために組織は多額の費用や工数を負担することになります。
ユーザが被った不利益のフォローアップもさることながら、組織が受けるイメージダウンの影響が大きな痛手になります。消費者、特に日本の消費者は、メーカーのブランドを信用して製品を買う傾向が強いため、リコールを頻発したりしてユーザの信頼を失うと、未来の製品の売上に大きな影響を与えてしまいます。へたをすると会社自体が潰れてしまうこともあるでしょう。

プログラマが直面する状況

Part1では、SESSAMEの演習コンテンツを受講した C言語プログラミングの初心者が書くとんでもないプログラムを見て、ソフトウェアというものはどれほど慎重に作ったとしても、テストをすり抜けて残ってしまうバグが製品の価値を押し下げ、組織の信用を失わせる可能性が十分にあるということを読者のみなさんに実感してもらいます。
製品がどのように使われるかをよく知らないプログラマは、リコールがユーザや組織に与える影響について考えてプログラムを作ることはありません。一方、ベテランプログラマは、日本の小規模なソフトウェアプロジェクトにおいて自分が作っているソフトウェアがユーザにどのように使われるのか、ソフトウェアがユーザの期待を裏切るような振る舞いをするとどのような迷惑がかかるのかを意識しながらプログラムを作っています。
それが、ソフトウェアの規模が大きくなり、ソフトウェアプロジェクトの人数が増え、協力会社にソフトウェア開発を委託することが普通になり、どのようなプロセスで作られたかがわからずソースコードが見えないソフトウェア部品を使うようになって、何をどうすればユーザリスクを最小限にできるのか、長い間ソフトウェアで飯を食ってきたベテランのソフトウェアエンジニアにもわからなくなってきています。

日本のソフトウェアプロジェクトが目指すべきこと

日本のソフトウェアプロジェクトがとるべき舵取りは3 つあると思います。

1. ソフトウェアを利用するユーザのユーザリスクが何かを知り、そのリスクを受容できるレベルまで引き下げるにはどのようにソフトウェアを作ればよいかを分析して設計できる力を身につけること
2. ユーザがソフトウェアやソフトウェア搭載製品を使う場面を想定できない、または想定しないで仕事をするプログラマがプロジェクト内にいると仮定して、彼らが意図せずに作り込んでしまったリスクの種をどのように組織的に取り除いていくかというマネージメントの技術を学ぶこと
3. 再利用可能な信頼性の高いソフトウェア資産を作って、その資産を再利用することで開発効率と品質を同時に高めること

第1 の施策は、ソフトウェアシステムの構造設計者であるアーキテクトの責務であり、航空および宇宙、医療、プラントなどのクリティカルデバイスのソフトウェアの世界では専任のソフトウェア安全分析者の役割になります。
リスクの中には安全に対するリスクだけでなく、携帯電話やデジタル家電、自動車のリコールなどで見られるような経済的なリスクも近年顕著になってきています。したがって、この取り組みはクリティカルデバイスソフトウェアだけに求められているわけではありません。また、これまで日本人の几帳面さや助け合いの気質で品質をカバーしてきたソフトウェアは、その日本人の特性を活かしながらもマネージメントの要素を上手に組み込んでいかなければ品質を保てないほど、規模が拡大しています。そのような意味でも、これからのソフトウェアプロジェクトは、第2 の施策であるソフトウェア品質のマネージメント技術を修得する必要があります。
そして、最後に必要なのはソフトウェアの資産化です。昔からベテランのソフトウェアエンジニアは、枯れたソフトウェアモジュールを再利用することで品質と効率が高まることを肌で感じていました。だからこそ、枯れたソフトウェアを安易に変更せず、後々まで変更しないで済むようによく考えてソフトウェアモジュールを作っていたのです。

ソフトウェアの規模が増大し複雑化した現在では、この昔のベテランエンジニアがとっていたアプローチを体系的に実施していく必要があります。体系的に行うとはいっても、考え方や基本思想は昔と同じです。ユーザに対する価値が凝縮されており、システムのコアとなるソフトウェアモジュールを見つけて、設計（場合によっては再設計）し、資産化してそれを管理するのです。それは、ユーザがソフトウェアやソフトウェア搭載製品にどのような価値を求めているのかを知っているソフトウェアエンジニアにしかできません。ソフトウェア工学の知識を十分に身につけていても、それだけでは足りません。製品や製品を使うユーザのことをよく知っているか、マーケティング担当が分析した情報をユーザの身になって理解できるソフトウェアエンジニアでなければダメなのです。

本書で提案したいこと

本書が他のソフトウェア工学の書籍と異なるのは、ソフトウェアエンジニア、特に日本のソフトウェアエンジニアの気質を強く意識した施策を提唱し、ソフトウェアやソフトウェア搭載製品が使われる市場やユーザを分析対象にしなければ、効率的かつ高品質なソフトウェア開発は実現できないと主張しているところです。そこにはソフトウェアを作る職人の個人商店としての立場と、自分の仕事の成果によってユーザであるお客さんの役に立ちたい、喜んでほしいという気持ちが根底にあります。ただし、そのためにはプロフェッショナルとしてのワザを身につけて、努力するだけではなく、製品の本当の価値を高める成果が伴っていなければなりません。そうでなければ自己満足になってしまうのです。
「リコールを起こさない」という言葉を裏返すと、「製品の価値を高いまま維持する」「いつまでもお客さまに満足し続けてもらう」ということになります。日本のソフトウェアエンジニアは、製品の価値を意識しながらソフトウェアを作るということに長けた人種だと思います。ただ、残念ながら、その気質だけで高品質なソフトウェアを作れる世の中ではなくなっているのです。本書で日本のソフトウェアエンジニアに最もフィットした改善および技術習得の手法を提案したいと考えています。

【引用終わり】

『リコールを起こさないソフトウェアのつくり方』を出版しました

技術評論社さんから『リコールを起こさないソフトウェアのつくり方』を出版しました。『組込みソフトエンジニアを極める』を2006年にリリースして以来4年ぶりの新刊本です。

※今回はですます調でいきます。

タイトルがタイトルだけにやけにタイムリーと思いになる方が多いかと思いますが、この本の企画は2008年の5月に提出したもので2年弱かけてじっくり仕上げた内容であり熟成の味の自信を持ってお届けいたします。

本に書いた内容は過去に技術評論社の組込みプレスに書いた記事が主体となっています。今回はソフトウェアの安全や信頼をテーマに、大規模、複雑化したソフトウェアにどのようにして問題が入り込むのかを実例をもとに解き明かし、日本のソフトウェアプロジェクトにフィットしたマネージメント技術および、ソフトウェアの品質と開発効率向上の両立を実現するためのソフトウェアの資産化の技術を解説します。また、付録で自動車分野向け機能安全規格 ISO 26262 に影響を与える MISRA SA（MISRA ソフトウェア安全解析ガイドライン)概要を紹介しています。

さまざまな電子機器がソフトウェアで制御されるようになった昨今、トヨタのハイブリッド車プリウスのブレーキ問題をはじめソフトウェアが絡んだリコールが年々増加しています。ソフトウェアは見えないだけに、何がどのようにして問題を起こしているのか簡単には解明できません。

今、プリウスのブレーキソフトウェアの改変リコールはホットな話題ですが、本書は決してこの問題が世間で取り上げられているからではなく、ずっと前からソフトウェアが要因となる、また関連するリコールが社会問題になることを予測して原稿を書いてきました。

【『リコールを起こさないソフトウェアのつくり方』はじめにより】

日本のソフトウェア製品やソフトウェア搭載機器がグローバルマーケットで支持され続けるためには、「品質がよく割安感のある商品」を市場にアウトプットしていかなければいけないと思っています。リコールを繰り返すような品質の悪いソフトウェアではダメなのです。

一方、ソフトウェア開発の側面を見ると、欧米で体系化されたソフトウェア品質改善の方法論の多くが日本のソフトウェアプロジェクトに紹介されています。ところが、日本のソフトウェア開発現場の多くでそれらが役に立っておらず形骸化しているように感じています。また、大部分の方法論は欧米で実践されているはずですが立ち遅れているといわれる日本のソフトウェア搭載製品のほうが品質が高いという事実があります。

それはなぜなのでしょうか。それならば、日本のソフトウェアプロジェクトはこのままの方法で開発を続けていればよいのでしょうか。この命題を解明し、ソフトウェア工学をどのように日本のソフトウェアプロジェクトに適用すると有効なのかを示すことができなければ、日本のソフトウェアエンジニアは決して幸せにはなれないと思っています。これが本書を書こうと思った動機です。

本書は、たとえば、次のような方に有用です。

•  ソフトウェア開発の初級者の方
  
•  新人でこれから目指すべき道筋が見えていない方
  
•  ハードウェアエンジニアで「なぜ、ソフトウェアは問題を起こすのか」を常々疑問に思っている方
  
•  ソフトウェアプロジェクトマネージメントの技術を学んでいて、どうして自分のプロジェクトでうまくいかないのか悩んでいる方
  
•  組織内でソフトウェア品質問題に頭を抱えている方
  

その他にも、ソフトウェアの品質管理、構成管理、再利用資産、安全設計などに興味を持っている方にもおもしろく読んでいただけると思います。　まず、ソフトウェアエンジニアの新人や初級クラスの方は、Part1のソースコードのケーススタディを見て、自分がいまどのレベルにいて、何を学ばないとまずいのかを考えてみてください。きっと答えが見つかるはずです。中堅、ベテランのエンジニアのみなさんは、Part1でソフトウェアの本質的な危うさを認識し、日本人の特性を理解したうえで、日本におけるプロジェクトマネージメントの適用方法を Part2で学んでください。

そして、プロジェクトリーダーやソフトウェアアーキテクトとしての責務を負っている方は、ソフトウェア再利用資産の抽出方法を Part3で修得し、現行のソフトウェア製品群の開発効率と品質向上に役立ててください。
最後に、自組織のソフトウェア製品やソフトウェア搭載製品が市場で問題を起こしており、その問題を解決する責務を負っている方は、本書の最初から最後までを通して読み、ソフトウェアと日本人の特徴を理解し、自組織において何に手をつければよいのかを理解してほしいと思います。
本書が、初級や中級のソフトウェアエンジニア、アーキテクト、マネージャ、リーダーの方にソフトウェア品質の改善活動の参考書として役立つことを期待しています。

2010 年 3月 酒井由夫

【引用終わり】

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

Part1　ソフトウェアの危うさの本質を体感してみよう
Chapter 1　ソフトウェアの危うさを知ろう
Chapter 2　危ないソフトウェアのプログラム例とケーススタディ
Chapter 3　ソフトウェアはなぜ危ないのか
Chapter 4　ソフトウェアの品質を高く保持するために
coffee break　アメリカ人と日本人

Part2　日本的ソフトウェアプロジェクトの管理はここから
Chapter 5　ソフトウェア開発の理想と現実
Chapter 6　日本のソフトウェアプロジェクトに求められる取り組み
Chapter 7　ソフトウェア構成管理
Chapter 8　ソフトウェア変更管理
Chapter 9　レビュー
coffee break　問題解決能力：自ら考え行動する力

Part3　ソフトウェア資産化の技術がリコール防止につながる
Chapter 10　ソフトウェア開発のプラットフォーム
Chapter 11　ソフトウェアシステムとソフトウェア搭載機器の価値
coffee break 3　ものづくり戦略とソフトウェア品質：品質＝Qualityの話
Chapter 12　再利用資産を抽出するためのアプローチ
Chapter 13　再利用資産を抽出する手順
coffee break 4　UML導入のススメ
Chapter 14　再利用資産の抽出のケーススタディ
Chapter 15　再利用資産の抽出後のアプローチ
coffee break 5　テストカバレッジ
Chapter 16　安全性が求められるシステムに対するアプローチ
Chapter 17　安全アーキテクチャの検討
Chapter 18　ソフトウェアを資産化して品質と開発効率を高める

本ブログサイトのヘビーユーザーの方は「なんか見たことある話し」と思うかもしません。そう、そのとおりでこのブログに書いた記事もふんだんに取り入れてあり今回のテーマに合わせて追加修正にして読みやすくなっています。

インターネット書店のアマゾンではすでに予約が始まっており、大手リアル書店では3/15の週に店頭に並ぶと思います。

このブログサイトでも是非、読者の方々と双方向の意見交換をしていきたいと思いますので、是非本書をお読みになり、ご感想、ご意見をどしどしお寄せください。

できる限りブログでも本に書いた内容の一端を紹介してさらに深い解説をしていきたいと考えています。

この本をリリースするにあたりご協力いただいた関係者の皆様には、この場をお借りしてお礼を申し上げます。ありがとうございました。

練習が必要なのはオリンピック選手だけじゃない

バンクーバーオリンピックでは数々の名勝負が繰り広げられた。なかなか見応えがあったが、選手のみなさんがこれまでさぞたくさんのトレーニングを積んできたに違いない。

スポーツは練習しなければうまくならない。スポーツだけではない。人間がやるもの何でもそうだ。知識労働者だって知識だけ知っていれば仕事ができるとはいえない。特にソフトウェアエンジニアがスキルアップするに繰り返しの練習が必要だと思う。

そう考えるとソフトウェアエンジニアがスキルアップしていく様があるとすれば、それはスポーツ選手が技術を身につけていくのに似ているような感じではないかと思う。

どんなスポーツだって練習しなければうまくならない。そして才能のある選手には必ず優秀なコーチがつく。コーチは科学的な理論に基づいてどうやって選手を育てていけばいいのか考え、いろいろなトレーニングメニューを組み立てる。選手が出す成績にもとづいてトレーニングメニューを変えたりもする。

ソフトウェア技術者の教育も同じではないか。優秀なエンジニアに育て上げるには優秀なコーチが必要だ。また画一的なトレーニングではなく、選手一人一人に合わせたトレーニングが必要だと思う。

今、ソフトウェア技術者を取り巻く世界では選手とコーチと練習という環境ができていないのではないだろうか。

選手はいつだって自主練習のみ。自主練習どころか練習する時間も取れない。また、コーチは外部コーチで何人もの選手を一斉に面倒みるため、選手の個性に合わせたトレーニングメニューを用意することはできない。

よく、OJT(On the Job Training）が大事というが、OJTというよりは、スキルが身につくまで繰り返しの練習をさせる環境が必要なのではないかと思う。よい練習問題を用意して、繰り返し繰り返し練習するのだ。プログラミングでもモデリングでもよい。同じような問題を繰り返しながら自分の血となり肉となるまで鍛錬する。人間の脳は一回教えただけで修得できるようなしくみにはなっていないのだ。（これは精神も肉体も同じ）

繰り返し練習をする時間はないとあきらめてしまうか、いろいろとやりくりして時間を作るかは遠い将来にメダルを獲得した自分や自分が育てている選手の姿を思い浮かべることができるかどうかで決まる。

ソフトウェアエンジニアもスポーツ選手と同じでハングリーな選手と実戦経験を積んだよいトレーニングメニューを持ったコーチが出会って初めて優秀な成績が残せるような気がする。