NHKの「就職難をぶっとばせ！」を見て

2010年12月25日クリスマスの日にNHKで『日本の、これから「就職難をぶっとばせ！」』という2時間の討論番組がオンエアーされた。

もちろん、超氷河期と言われる就職活動がテーマなのだが番組を見終わって、これは学生の就職という限れれた範囲の問題ではなく、日本の社会全体の問題だと思った。学校で何を教えるのか、企業はどのように人材を採用し、そして社会はどのように人材を流動させる必要があるのかといった社会構造の変革時期に来ているということがよく分かった。

番組は三宅民夫アナウンサーが進行役で進み、就活中の学生（内定あり、就職のための留年を決めた人、既卒者など）や、経営者、人事担当、高校の先生、就職した先輩などが集まっていた。

ゲストは、下記のような方々で、勝間さん、海老原さん、宮本教授がそれぞれの持論を披露し、それについてディスカッションをした。

文部科学副大臣…鈴木寛，株式会社クラレ代表取締役会長…和久井康明，東京大学大学院教授…ロバート・キャンベル，経済評論家…勝間和代，株式会社ニッチモ代表取締役…海老原嗣生，放送大学教授…宮本みち子

勝間さんは次の2点を主張していた。

1. 日本の企業は新卒一括採用をやめて、アメリカのように不定期にエントリーレベルから採用したり、インターンシップによる採用をすべきだ。
2. 企業が社員を解雇しやすくする（=もっと人材を流動しやすくする）ように、セーフティネットを準備し、解雇された後の職業訓練や雇用手当を充実させる。

議論の中で重要だと思ったのは、日本の企業が新卒一括採用をする際のメリットについてである。企業側は新卒一括採用によって、新入社員研修をまとめて実施することができ、かつ、「同期」の意識を高めることで、同期同士での助け合い、競争、情報の共有といういろいろなメリットが生まれるということだった。ようするに企業は新卒一括採用によって新入社員教育のコストを抑えることができるということだった。

しかし、考えてみればアメリカのエントリーレベルのプログラマなどは年収200万円くらいだと聞く。そんな低賃金で雇えるのならば、不定期に個別トレーニングを受けさせてもコストアップにはならないだろう。

問題は、日本式で何十年もやってきた日本の企業がアメリカ式の雇用スタイルには簡単には変われないということだろう。司会の三宅さんは、番組の最後の方で「我々団塊の世代は、小中高大と学校を通り過ぎ、企業に就職して定年まで勤め上げるという、レールに長い間乗ってきた。今、このレールを降りなければいけない時代に来ているようだが、果たして降りられるだろうか。」と言っていた。

まさにそのとおり。日本人が高度成長期にやってきてうまくいっていたシステムを変えるためには、危機感がなければ変わるわけがない。右にならえでやってきて大きく失敗しないでここまでこれたのになんでシステムを変える必要があるのだと思っている経営者や人事担当は山のようにいるはずだ。

でも、いろいろな方面で日本が世界の一番でなくなってきた今、ひとと同じことをやっていてはグローバルな競争には勝てない。韓国や中国やインドの企業に負けて、仕事がなくなって今のポジションを守ろうと考える社員が多くなり、会社が潰れたり、合併されたりしてから問題に気がつく。

どうも、これまでの日本では周り同業他社を見渡しながら同じようなことをコツコツをやっていれば、なんだかんだいって売り上げは上がっていったらしいのだ。国全体が成長期にあったから、そうだったのだが今は違う。今は、日本の中でそんなことをやっていても、同業のアジアの会社には勝てないし、変化のスピードが早いので海外他社の成功を見てから真似しても間に合わない。その状況に日本人の多くが気づいていない。別な番組で、日本にいると SAMSUNG の驚異はあまり感じないが、東南アジアや中東、南米などに行くと明らかにSAMSUNGの台頭に驚くという。日本の平和ぼけは経済においてもボケのようだ。

新卒一括採用という制度は護送船団のように見える。人事部門は他の会社がやっていることを真似していれば大きな失敗もなく、経営者から怒鳴られることもない、学歴で学生を選ぶからひどい人材を採用する危険性も低いが、飛び抜けてユニークな大きな組織貢献をする可能性のある人材の採用もできない。そこから脱することもできるはずなのにみんなが周りを見渡して顔色を伺っているから、だれも動かない。

もう一つ、人材コンサルタントの海老原さんは、学生や親は大企業ばかりに目を向けないで、世界でも有数の技術を持つ中小企業などを探しなさいと主張していた。中小企業が学内でちょっとした飲み会のスポンサーになって、学生と直接話しをする機会を設けたらどうかという話しもしていた。マスコミを通すと中小企業の良さが伝わらないから、直接話しをする機会をできるだけ多く作ろうとう提案だ。

実際、今の学生は大手指向が強く、自ら狭き門に殺到している。従業員数1000人以下、300人以下という企業なら求人倍率は1倍を遙かに上回っている。

日本だけでなく、世界でのシェアも高い卵の選別をする機械を作る会社などは、せっかく採用したのに親に「そんな会社は聞いたことがないのでやめておきなさい」と言われ、内定を辞退する学生が少なからずいるらしい。だから、今では親子に対して会社の説明をする説明会をやるのだとか。

この問題提起に対するディスカッションで、大企業は安定しているし、何はともあれ就活サイトでは大企業の情報しか載っていないという話しがあった。優良な中小企業の情報自体が得られないというのだ。

コメンテーターから毎日新聞各紙を読んでいれば、中小企業の情報も入手できるという指摘があった。自分もそう思う。新聞だけではない、インターネットや業界のニュースサイトからだって情報は得られる。興味のある業界が特定されているのなら、業界新聞やその職種のひとが書いているブログを読むことだってできる。

今なら、PCの前に座って各方面の情報を探ればいくらでも情報は得られるのに、やっていないだけなのではないだろうか。誰かに情報の検索方法を教えてもらっていないから、他の学生はそんなことやっていないからしないのだろうか。

就活サイトという与えられた枠の中だけでしか情報を探していないのではないだろうか。これも右にならえ症候群の影響だろうか。

討論会の中で、就活学生はリスクについて考えた方がよいという話しがあった。大企業に就職した入社二年目の社会人の方がいて、同期が500人もいると自分がやりたい職種があっても希望どうりになる可能性は低い、大企業では会社に入ってからも競争が続くと言っていた。それが大企業のリスクだ。中小企業なら、社長と直接話しをする機会も多く、自分がやりたいことを主張すればその心意気を汲んでやらせてくれる可能性もある。英会話の能力を活かしたいと言えば、海外シェアの高い優良中小企業なら即海外営業担当になれるかもしれない。そこで自信がないと言うようではチャンスは巡ってこない。ただし、給料は安いかもしれないし、もしかしたらブラック企業かもしれない。それが中小企業のリスクだ。

どっちのリスクを取るのかだ。もしも、今自分が就活する学生なら、絶対に大企業のリスクは選択しない。ブラックでない将来性の高い中小企業を探して就職し、やりたいことを思いっきりやって、スキルが徹底的に伸ばし、もしも、その会社の器をはみ出しそうになるくらい成長したら、その実績を引っさげて別の会社に転職する。

討論会の中で悲痛の叫びを口にする学生さん達を見ていて思うのは、彼らは完全に「就職できないかも知れない」という恐怖におびえているということだ。そして、その恐怖を振り払うための方策として、受験勉強で使った方法を使おうとしている。

つまり、中学二年の間に中学三年生までの教科を終わらせて、中学三年生の期間は受験対策をする。大学1,2年から就職活動を開始し、4年生になったら面接のための塾に通ったりする。ようするに高校、大学の難関校を受けるときの戦略そのままだ。

企業には偏差値は付いていないから、よくコマーシャルや全国ニュースに出てくる大企業がいい会社だと考える。

この戦略の大きな間違いは、皆が同じ土俵で闘おうとしている点だと思う。共通テストや私立大学の入学試験は公正を期すために、できるだけ同じ土俵で学生達を闘わせようとしているが、企業は別に同じ土俵で闘う必要はないし、同じでないからこそ生き残れる世界もたくさんある。それなのに自ら競争相手の多い土俵に登りたがる心理が自分には理解できない。

一つは他の人が着目していないような優良な土俵を探すこと、つぎにその土俵で自分が勝つためには何をしなければいけないのかを考えることだ。どちらもひとと同じことをしていたらダメで、ひとがしていないことで自分のやりたいこととのオーバーラップを探す必要がある。日本ではそういう訓練はしてこなかったのだろう。

一昔前は大学への進学率は10～20%。今では50%を越えている。昔は、大学は学問を学びたい者が行っていたのだが、今では大学は限られた若者がいくところではなくなっており、彼らを全部就職させるためには職業訓練的なこともしなければいけないというVTRがあった。

これに対して、大学がアカデミズムの立場を崩すのはよくないという意見があったが、東京大学大学院教授　ロバート・キャンベル氏が、どんな分野であれ、学び、議論し、改善を模索するという行為を大学で学び取ることができればムダではないと言っていた。自分はロバート・キャンベルさんの言うことが好きだ。50%が大学へ進学する時代なら、アカデミズムもあり、職業訓練もありにしなければ結局は不幸な学生がでてくる。

大学では何でもいいから勉強する対象を通して、深く掘り下げて考え、分析したり、理論を打ち立てたり、問題を解決する力を養って欲しい。

そして、変えなければいけないのは学生と親が持つ価値感だ。働くことの意味はなんだ？ みんなが知っている安定した企業に就職することか？

20世紀の時代には大企業=安定の式はなりたったかもしれないが、21世紀ではまったく信用できないし、大企業のリスクも存在する。

「みんなと同じ」=「安心」「仲間はずれにならない」

という価値感はそろそろ捨てよう。親は子供に「友達と同じことをするな」「自分だけのオリジナリティを磨け」と言おう。みんなが黒のスーツを着ていたら、自分だけはグレーにしてみなさい。「なぜ、君はグレーのスーツなのか？」と聞かれたらラッキーじゃないか。

ひとと違うことを突き詰めるのは「自分にはムリ」と言うのならば、職業訓練をしよう。学生のうちに、企業が興味を持つ分野のエキスパートになってしまおう。それが自分の好きなことと一致していればそれに越したことはないが、絶対にイヤだというわけではないのなら、何かの道を選んで一流と言われるまでスキルを高めてみたらいい。

『日本の、これから「就職難をぶっとばせ！」』を全部見て一番バカだと思ったのは、世界のトップシェアの中小企業に内定をもらっていながら入社を辞退した学生とその親だ。

本当にその親の顔を見てみたいし、「聞いたことがない会社だから」という理由で断った学生も親も親なら子も子なのだろう。

番組キャスターの三宅さんも言っていたがこの問題は就活学生だけの問題ではない、今一度我々は自分自身に「何のために働いているのか」という疑問を問い掛けてみる必要がある。

そして、その答えと今の社会のシステムにズレがあるのなら、未来の日本をしょって立つ若い人たちのために変える行動をしなければいけない。批判したり、評論したりするだけではだめだ。何かしらの行動をしなければいけない。

行動できなければ、それはひかれたレールから降りられないということだからだ。だれもレールから降りないのなら、さびれたレールは残り続け乗客はいなくなり廃線になるだけだ。

さしあたり、自分ができるのは学生向けにこのブログを通して情報を発信して「みんなと同じ」症候群から脱出する方法を授けることかな。

やっぱり手帳がいい

斎藤孝氏の著書『15分あれば喫茶店に入りなさい』には、喫茶店に持ち込んではいけないものとしてノートパソコンが挙げられているそうだ。

喫茶店の15分間という時間と空間を作るとアイディアが生まれるという。生まれるというよりは、アイディアを生むための時間を作るということだろう。

時間と空間を作るのなら家でも同じと思うかも知れないが、家には考え事をさせないような誘惑がたくさんある。喫茶店に入ってしまえばコーヒーを飲む間の時間は他のことはできない。

アイディアというものはふと思いついて覚えておけるだろうと思っていても、数時間もすれば忘れてしまうものだ。ということで自分はいつも手帳を持ち歩いている。

そもそも、PDA として SONY の CLIE を持っていたのだが、SONY のPDA市場からの撤退という裏切りとともに結局 PDA は使わなくなってしまった。 CLIE を使わなくなってから、もう一度原点に戻って手帳に切り換えた。この手帳にしてからもう5年になる。

今は iPod Touch があるけれど、これは手帳の替わりにはならない。ふと思いついたアイディアをささっと書き留めるには手帳が一番だ。この手帳を選んだ理由はカレンダーとノートだけのシンプルな作りで、透明のジップ付きのカバーにペンを入れられるからだ。値段も\1000円以下。毎年この時期になると東急ハンズに来年の手帳を買いに行く。

ただ、カレンダーは google カレンダーで情報をクラウド上に共有できるため iPod touch のカレンダーを使うようになった。でも、アイディアを書き留めるノートとしての機能は手帳にはまだまだ勝てない。

いろいろな電子機器を使うようになった今でも手帳は手放せないし、毎年来年の手帳を買いに行くということも考えようによっては楽しいことだ。

P.S.

SONY には CLIE では裏切られたが、薄型テレビの BRAVIA では感心している。起動時間が早い。Linux の立ち上がりには時間がかかっているがテレビを見るだけなら Linux の起動に関係なくすぐに見える。

同様にブルーレイディスクレコーダーの起動も「パッと起動！」とCMで強調している。ユーザーが本当に求めていることカタログスペックには出にくいことに着目して実現してくれた。今のDVDレコーダーの起動時間も遅くてうんざりしている。次に買い換えるときは SONY の Blueray にしようと思う。

新人と就活

今年の新人達がプレゼンするのを聞いた。ものすごくうまい。本当に信じられないくらいうまい。最近は個人情報ということで、どの大学の何を専攻してきたのか、学卒か院卒かも公開されないからプロフィールがまるでわからないが、プレゼン慣れしているのは確かだと思う。

あまり人前であがらないというのは現代的な特徴かもしれないが、観客が自分をどのように見ているのかを客観的に把握できているように見える。

就活で鍛えたのだろうか？　最近の就職は非常に狭き門となっているらしく就職を控えた学生の諸君は大変だという話しをよく聞く。

『内定の出ない学生は何が間違っているのか～学生、企業、大学、親がすれ違う悲惨な現状』を読めば大変な現状が分かる。

しかし、日本の企業はどうして「新卒」にこだわるのだろうか。これまでずっと同じシステムでやってきたから、いまさら変えることに不都合があるのか。能力主義、成果主義に切り換えたといいながら、実は年功序列が実態なので新卒という枠を外すと問題が生じるのだろうか。

日本の企業は大学、新卒とう枠を設けることで、自分達が欲しい人材がどのような人間であって欲しいか考えることから逃れていると思う。

ようするに新卒であれば世代という観点では同じ評価指標で考えられる。その土俵で人選すれば選びやすい。ところが、新卒という条件を外したら、もっと評価指標が増えるし、また、どのような人材を求めているのかをもっと明確にしなければいけない。

その組織にあった人材ということだけではなく、今、不足している、これから始めようとする事業に有効な能力、ポテンシャルを持った人材を選らばなければいけなくなる。というよりは選べるようになるのだ。

キャリア採用と似ているが、キャリアは十分ではないだろうから、人材を必要とする事業やプロジェクトに投入する際にポテンシャルの高い人を探さなければいけない。今まで以上に人事部門が事業部門と情報を共有し、どんな人材が必要か常日頃からディスカッションしておかねければいけない。

新卒しか採用しないのは、人事部門が新卒という枠でしか技術者を評価できないからではなだろうか。

その組織に、その事業に、そのプロジェクトに必要な人材がどのような者か、どのようなポテンシャルを持っているべきかを考えられるようになれば、新卒にこだわる必要がない。

ちゃんとそのコンセプトを示し、いろいろな経験をした広い範囲から人材を選べるはずだろう。

プレゼンがうまいのがもしも就活のために訓練したのであれば、それもよいが、エンジニアとして組織が求めているポテンシャルが高いのかどうかはそれだけでは分からない。

就職する側の企業が変われば、大学の姿勢や受験も変わるのではないかと思う。現在の就職状況では、一芸に秀でた人材が埋もれてしまわないか、日本ではチャンスは新卒の一回しかないのかどうか心配になる。

ソフトウェア品質を高く保つには哲学が必要

前回の記事『商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。

誰がどこに書いた文章かはご想像にお任せします。

------
明治大学理工学部に向殿政男先生という方がいます。

著書のひとつ『安全設計の基本概念』

向殿 政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)

その、向殿先生が、日経ものづくり 8月号 で日本のものづくりの歴史的背景を次のように語っています。

【日経ものづくり 8月号 特集 ソフトが揺さぶる製品安全より引用】

信頼性一本やりでは厳しい

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

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

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

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

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

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

【引用終わり】

この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。

ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。

安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。

クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。

それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。

これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。

そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。

簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。

・自分の商品の品質に自信があるか？
・自信の根拠は何か？

これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。

そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。

そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。

安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。

これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。

「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。

以上

商品リスクを低減するには哲学的思考が必要

日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』の中で明治大学理工学部情報科学科教授の向殿政男氏が次のように語っている。

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

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

この、「哲学的」というキーワードを見て「なるほど」と思った。もしかすると、これまでなぜソフトウェア開発やソフトウェア品質がなかなかよくならないのか、それはソフトウェア開発には哲学的な判断が必要なのに、それをしない、できない人が増えているからだと思った。

なぜ、ソフトウェアと哲学が関係するのか。安全を定義するには、社会が許容するリスクとは何かを考えそこに線を引かなければならない。商品やサービスの周りにはリスクが無限に存在する。

悪意を持った行為を含む Abnormal Use を除いても、誤使用(Use Error), うっかりミス(Slip), 過失(Lapse), 誤り(Mistake) は必ず起こる。

それらのリスクに対してどこまで企業は対処すべきか。リスクの基となるハザードは危害に発展しなければ表面化しない。だからこそ、作る側と使う側で認識のギャップが生まれる。

正しい使用と異常な使用の間にはグレーゾーン（メーカーが考える正しさ、異常さと、ユーザーが考える正しさ、異常さのギャップ）が存在する。

このグレーゾーンをメーカーが都合のよい解釈で広げていくと、ハザードが危害になる危険性が高まる。メーカーは製造物責任を回避するために大量の警告や注意を取扱説明書に記載することよって、責任を回避できると思いがちだが、世の中はそう甘くはない。

ユーザーが取扱説明書を読まずに禁忌事項を実施した場合は、事故の発生はユーザー側に責任があるから、メーカーは製造物責任を問われることはない。しかし、社会通念上、多くの人の認識と合わないような要求を製品の利用者に強いている場合、適正なラベリングを行っていなければ、製造業者は社会的責任を追求される。

ようするににニュースになるような事故が起こると表記上の対策で刑事責任は逃れられても、設計上の対策=リスクコントロール手段を実装していなけば世間が許してくれず信用ががた落ちになり、企業の対応によっては市場から No を突きつけられるということだ。

そうなると、企業はユーザーの安全のためにグレーゾーンのどこに線を引くのか決断しなければならない。これはそんなに簡単なことではない。数式で計算できるようなものでもない。

その組織やそのプロジェクト、その技術者のポリシーに寄るところが大きい。組織的なポリシーが確立されていれば、商品間、サービス間でのばらつきは少ない。プロジェクトや技術者個人に依存していてば、そのプロジェクトやその技術者が関わった製品のみグレーゾーンのユーザー部分が小さいことになる。

リスクを起こさない仕組み=リスクコントロール手段を実装するにはコストがかかる。ソフトウェアで実施する場合、材料費はかからないが分析や実装の時間を要する。ソフトウェアは常に納期を迫れれているから、納期とのトレードオフでリスクコントロール手段は省略される危険性があり、ソフトは見えにくいので省略してもその事実を確認しにくいという特徴がある。

障害の発生確率が低ければ「どうせ、そんなこと起こらないよ」という気持ちになり、対策を実装しない技術者がいても不思議ではない。そして、障害の発生確率が高くても、納期が迫っていると「どうせ、そんなこと起こらないよ」と考えたい悪魔の気持ちが大きくなっていく。

悪魔の気持ちを抑えるのが、エンジニアの倫理観であり、組織の品質保証の仕組みである。エンジニアの倫理観は、哲学的な思考で鍛えられると自分は思っている。何も考えていなければ、エンジニアの倫理観は醸成されない。1か0ではない物事に対して、何が正しいのか、何を持って正しいと考えるのかについて深く掘り下げていくことで、哲学的な思考能力は高まると思う。

そうなると、前述のグレーゾーンをユーザーのリスクを最小限にするためにかかる工数（行為）と納期やコストとのトレードオフをする際に、なぜ自分または自分たちはその選択をしたのか自信を持って言えるようになる。

それが言えないのなら、その人は組織の言われた通りにものづくりをしているだけなのであって、グレーゾーンはメーカーの都合のよい解釈になっている可能性が高い。

その危険を組織で抑えるか、エンジニアのコンプライアンス教育で抑えるのか、それとも両方かを選択するのは自由だが、技術者がやりたいようにものづくりする方がいいものができると考えているプロジェクトほど、エンジニアの哲学的思考能力は高くないと安全で信頼できる商品は作れない。

自分自身はマイケル・サンデル先生の『これからの「正義」の話をしよう――いまを生き延びるための哲学』と読んで、哲学的思考能力を高めようとしている。

Random Failures と Systematic Failures の違い

IEC 61508（機能安全）の中に、Random Failures （ランダム故障）と Systematic Failures （決定論的原因故障）の定義がある。

IEC 61508（機能安全）の定義そのものではなく、総合的にどんなことを意味しているのかいろいろ調べて考えてみた。

そうすると、前回の記事『ソフトウェア品質論の歴史的推移』につながるところがあることに気がついた。

■Random Failures （ランダム故障）

• 構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。
• 故障率を計測することで統計的に品質を管理する。

まず、ランダム故障は故障率が計測できる故障だから統計的に管理できる。だからこそ、統計的品質管理論によって品質を高めることができる。

つぎに Random Failures （ランダム故障）に相対する Systematic Failures/Faults  （決定論的原因故障/障害）はどんなものか見ていただきたい。

■Systematic Failures/Faults  （決定論的原因故障/障害）

• ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
• 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
• 開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。

Systematic Failures/Faults は故障率を予測することが難しい。部品の故障によって発生するのではなく、タイミングや複雑なユーザーオペレーション、まれに発生するイベントなどによって起こる障害である。

となると、部品の故障率を予測して品質を管理する手法が使えない。結果として開発プロセスで抑えるしかないということになる。これがプラグマティズム的品質管理論だと思う。

さらに、ソフトウェアの障害の場合、ユーザーオペレーションに起因する障害（バグ）の場合、障害が発生する手順を繰り返すと確実に障害を再現できる。あるとても複雑な手順を実施しないと発生しないが、その手順を実施すると確実に問題が起こるような場合、その障害の発生確率をどう考えるか。

たぶん、その障害の発生手順を知らない時点では、障害発生手順をやってしまう確率になるが、その障害の発生手順を知ってしまったら、製造業者のソフトウェア改訂責任という観点からすると発生確率は100%と言えるのかもしれない。

ソフトウェアが原因の場合、ソフトウェアを修正することで障害の発生を防止できることから、障害が原因で発生するハザード（潜在危険）の大きさによっては、ソフトウェアアップデートを確実に求められる。発生する状況がまれであるためソフトウェアを改訂しないという選択ができないこともある。

ソフトウェアに起因する障害の特徴でもある Systematic Failures/Faults の防止には、統計的品質管理論は効かず、プロセスアプローチが有効（というよりは他に有効な方法論がなかった）というのが定説だ。

ただ、広島市立大学の大場充先生が言うように商品の価値や顧客満足を重視した品質管理が21世紀のトレンドであるならば、 Systematic Failures/Faults が商品の価値や顧客満足に及ぼす影響度を分析（リスク分析）して、その優先度により、プロセスアプローチのしかたを変えるという方法がクローブアップされるのではないだろうか。

ソフトウェア品質論の歴史的推移

日科技連主催のソフトウェア品質シンポジウム2010（SQiPシンポジウム2010）で広島市立大学の大場充先生が、ソフトウェア品質論の歴史を解説するセッションがあった。

非常に興味深い内容だったのでここに概要を紹介したいと思う。

■品質という概の推移（概要）

• 「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
• 「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
• 今後の品質概念
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

■品質という概念の推移１

• 現在のソフトウェア品質論はプラグマティズム的品質論を元にした理論が主流であるプラグラマティズ的品質論とは米国企業に1980年頃から浸透しはじめた、古典的な経験主義に基づく統計的品質管理へのアンチテーゼとして提案された
• 興味の焦点は、品質管理の対象としての製品（プロダクト）ではなく、それを生み出しているプロセスにある。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。
• プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

■品質という概念の推移２

• プラグラマティズ的品質論とは「工程の最終段階でのテストによって欠陥を除去し、その情報に基づいてプロセスの状態を知る」というフィードバック方式から、「プロセスの状況を的確に把握し、その情報に基づいて生産されるプロダクトの品質を適切に管理する」フィードフォアワード方式に転換したと言える。
• 1980年代フェーガンが提案したソフトウェアインスペクション法は、古典的なテストに基づく品質管理と新しいプロセスの実態に基づいて品質を保証しようとする葛藤がにじみ出ている。
• その後、ミルズのクリーンルームプロセスの提案に統合されるしかし、結果的に品質保証を底辺で支える新技術の開発が遅れたため、このプラグマティズムに基づく方法は十分な成果を達成できなかった。

■品質という概念の推移３

• 1990年代センジ（プラグマティズム的組織論者）はプロセスの改善という組織の学習プロセスを管理することで、組織の目的に適合した成果を、効果的に達成できることを主張した。
• そのような組織目標を品質改善とすれば「プロセス改善によって品質向上を成し遂げる」という品質論になる。
• 「要求プロセス」「開発プロセス」「検証プロセス」「品質保証プロセス」「販売プロセス」「保守プロセス」などをそれぞれ独立したプロセスとしてとらえ個別に改善することが従来の考え方であった。
• これに対して、それら全てを統合したビジネスプロセスを見ることで全体最適を図ることが重視され、その成果が注目されるようになった。
• この思想の影響を受けたものの代表にハンフリーによって発表されたソフトウェア開発プロセスの成熟度評価モデルがある。

■品質という概念の推移４

• 「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問
• 仮に市場で最も受け入れられている製品の品質が良い品質とする前提が正しければ、プラグマティズム的品質論に根ざしたプロセス評価を受けた組織がソフトウェアは広く利用され、売れるソフトウェアである。
• Microsoft の製品はどうか？
• プラグマティズム的品質論は、現実を反映させて、個々の理論の不備を修正しながら時間とともに発展し続けている。その意味でプラグマティズム的品質論の枠組みは強固であると言える。

■品質という概念の推移５

• 観念論的品質論
• 1960年代のZero Defect運動は、生産現場における不良撲滅運動であり「不良率の低減が製品品質の向上に直結する」という考え方に基づき「不良をなくすことが、究極的な品質の実現である」とする。これは、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 1980年代後半から普及したシックスシグマ運動は ZD運動と同じ精神を引き継いでいるものの、プログラマティズム的解釈が根底にある。
• 観念的品質論では、まず普遍的で純粋な品質概念の存在を前提とする。マッコールの提案をユーザの視点から整理し、分類したのが ISO/IEC9126である。

■品質という概念の推移６

• 日本的品質管理の概念
• 「当たり前品質」と「魅力的な品質」の相対概念である。
• この概念は一見すると経験主義的な品質論に根ざしているように見えるが、本質的には経験を抽象化して獲得された高度に先験的で観念論的な概念である。

■品質論はどこに向かっているか？

• 1990年代から普及したCS運動
• CS (Customer Satisfaction)運動では、顧客（ユーザ）の製品やサービスに対する満足度ことが、効用であり、品質の根源であるとする。
• この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
• 「民主主義的原理に基づく品質論」
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
• 「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
• 開発者視点で重要なのは、そのような評価の結果を開発に結びつけることである。
• そこで重要な役割を果たすのが開発プロセスである。
• 「プロセスは良い品質のソフトウェアを開発するための手段である」
• 品質論においてプロセスは、目的ではあり得ない。
• プラグマティズムの立場から言えば、プロセスのみが、開発者が唯一管理できる対象であり、だからこそ最重要課題である。
• しかし、目的論的な立場から言えば、あくまでも手段である。

【感想】

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。

これは、試行錯誤で作り上げたソフトウェアを叩いて不具合を減らしていくという手法のことを言っているように見える。成熟度の低い組織が真っ先に考えつくのが一度作ってしまったソフトウェアの不良をいかにして取り除くかという観点だ。それだけでは無理と言ってもなかなか聞き入れてもらえない。

「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

この品質論が主流であることは納得できるし、結局、プロセスで品質を確保しようという活動をしているのも事実だ。

「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問

しかし、このことは常に開発現場の経験主義者から突き付けられる。昔は、網羅性の高いシステムテストでバグは潰し切れたし、ユーザーが行うであろうオペレーションのあらゆるパターンを再現できるベテラン技術者がいた。しかし、今ではすべてのオペレーションのパターンなど再現できるはずがない。システムテストでソースコードのテストカバレッジを100%にすることなどできるはずもないのだ。

だから、プロセスで不具合を作り込まない努力、プロセスにゲートをかけることで品質を確保することが必要になってきている。

「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である

今後の品質概念

「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。

評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。

同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

経験主義者を黙らせ、開発プロセスを管理することの重要性を訴えるには、「当たり前品質」や「魅力的な品質」といった日本的品質管理の概念や顧客満足を高めるために必要なプロセス、アクティビティ、タスクが何かという訴えかけが重要になる。

あなたの組織では「不良をなくすことが、究極的な品質の実現である」という古典的な品質論で考えが止まっていないだろうか？

品質に対する考え方は時代とともに変化しているのだ。

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

日経ものづくりはソフトウェアには関係ないと思っている人も日経ものづくり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段階をやり遂げて変革を起こしてみたいと思った。

人財と人罪

あるセミナーでおもしろい図を見た。「じんざい」を四つの象限で表した図だ。縦軸はモチベーション、横軸はスキル。

1. モチベーションが高く、スキルもある場合は組織の財産という意味で人財
2. スキルは高いが、モチベーションが低い場合は単なる材料という意味で人材
3. モチベーションは高いがスキルが低い場合は、居るだけだから人在
4. モチベーションも低く、スキルもない場合は居るだけで罪だから人罪

もう一つの図。会社がリストラの必要性に迫られたときに、誰を残すかという指標。縦軸はビジョンを共有。横軸は仕事ができる。

1. 組織とビジョンを共有し、仕事ができる社員は残す。
2. ビジョンを共有できているが仕事はできない社員も残す。
3. 仕事ができるがビジョンが共有できない者は会社を滅ぼす。
4. ビジョンも共有できず、仕事もできない者は不要。

【楽に生きていきたいと思っていると楽に生きていけないというロジック】

1. 楽に生きていきたい
2. 責任を負いたくない
3. 会社・相手に責任を転嫁する
4. 信用が落ちていく

1. 楽に生きていきたい
2. 面倒は避けたい
3. 処理が遅れる
4. 信用が落ちていく

1. 楽に生きていきたい
2. チャレンジする意欲はない
3. やれることしかやらない
4. 信用が落ちていく

1. 楽に生きていきたい
2. 自分の利益が最優先
3. 他は利用すべきもの
4. 信用が落ちていく

結果として楽に生きていけない。依存型の人間にどのようなよい仕組みを与えても、依存型は依存型としてこれを利用する。

【自立型人材のモデル】

1. 自分を活かして充実して生きていきたい
2. 率先して取り組む
3. 責任は自分が取る
4. 自分への信用が増す

1. 自分を活かして充実して生きていきたい
2. 面倒なことから逃げない
3. 処理が早い
4. 自分への信用が増す

1. 自分を活かして充実して生きていきたい
2. チェレンジしたい
3. 自ら新たな状況を作る
4. 自分への信用が増す

自分への信用が増すことにより、楽しく充実した人生が送れる。

【コンピテンシーモデル】

職能資格制度の欠陥を払拭するために高業績者の成果達成の行動特性（業績・成果と連動した顕在的能力）を重視したコンピテンシーモデルが有効である。

タワーズ・ペリン社のコンピテンシー ※1

1. コミュニケーション
2. チームワーク
3. 顧客志向性
4. 成果達成志向
5. 革新性/創造性
6. ビジネス感応性
7. リーダーシップ
8. 自身及び他者の能力開発/育成
9. 意志決定
10. 順応性/柔軟性
11. 問題解決

※1 コンピテンシーの定義の例　「継続的にその職務に求められる達成すべき最終成果責任を生み出すための効果的な行動を選択し、実際に行動に結びつけるという行動にフォーカスした能力で、しかも顕在的で他社から観察しうる行動レベルでの発揮能力」

【達成動機が強い人には成果に対するフィードバックを示すべし】

達成動機の強い人は成功報酬よりも個人的な達成感に関心を示すとともに、難しい問題に取り組んだり、解決すること自体に関心を示す。達成動機の強い人は自分たちの成果に対して具体的なフィードバックを求めることを強調している。

これは同感。解決すべき問題が部門間にまたがっているような場合、ルールやプロセスの変更が素早く承認されると達成感、満足感が生まれる。

ここまでの話し、どう考えても義務教育の学校では教えていないことばかりのような気がする。教えていないところか、正反対の依存型の人材を一生懸命作ろうとしていないだろうか？

改めて問題の根（依存型の社会人が多いという現状）は深いように思った。

問題解決の方法を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.

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

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

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

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

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

情熱とスキルと市場が重なり合うところ、あなたはそれを見つけられたでしょうか？

組織カイゼンにめげているとき、閉塞感に悩まされているとき、やろうかやるまいか迷っているとき、今自分が読んでいる本『20歳のときにしっておきたかったこと』を読み返してみるとよいと改めて思った。

【『20歳のときにしっておきたかったこと』 第6章 より引用】

成功の秘訣は、みずからの情熱につき従うことである－－－一体、何人からこうアドバイスされたことでしょう。きっと多くの人からこう言われた経験があるのではないでしょうか？何をすればいいのかわからなくて悩んでいる人に、こう言うのは簡単です。でも、このアドバイスは単純すぎて、人を惑わせます。誤解しないでいただきたいのですが、わたしも情熱は大好きですし、自分を突き動かすものを知っておくのは、とても大事だと思います。ただ、情熱だけでは足りないのです。

情熱は出発点に過ぎません。自分の能力と、それに対する周りの評価を知っておくことも必要です。とても好きだけれど、必ずしも得意でないことを仕事にしようとすると、悩みが深くなります。パスケットボールが好きだけれど身長が足りない人や、ジャズの大ファンだけど音程を外す人もいるでしょう。どちらの場合も、プロとしてではなく、熱心なファンとして、試合を見に行ったり、コンサートに足を運んだりすることはできます。

情熱を傾けられるものがあり、能力もあるけれど、それを活かす市場がない、という場合があるかもしれません。たとえば絵がうまくて描くのが好きだとか、サーフィンのボードつくりが好きで波乗りが得意だとしても、こうした才能を活かす市場は小さいのが実情です。自分が夢中になれることを仕事にしようとすると、欲求不満に陥るのは目に見えています。仕事にするのではなく、すばらしい趣味だと考えた方が賢明でしょう。

逆に、能力があり、それを活かせる市場が大きいのであれば、その分野で仕事を探すべきだと言えます。たとえば、実績のある会計士なら、財産諸表を作成できる人間のポジションはつねにあります。世の中のほどんどの人は、こうして生活をしています。自分のスキルを使える仕事があるけれど、早く家に帰って、自分が好きなこと－－－趣味に没頭したいと思っています。週末や休暇を指折り数えて待っています。あるいは引退の日を待っているかもしれません。

最悪なのは、仕事にまったく興味が持てず、その分野のスキルもなく、いまやっていることを活かせる市場もない場合です。古典的なジョークに、エスキモーに雪を売るセールスマンの話があります。雪が嫌いだし、セールスの腕もないのに、その仕事をやっているのです。これは最悪です。

情熱とスキルと市場が重なり合うところ、それが、あなたにとってのスウィート・スポットです。そんなスポットを見つけられたら、仕事がただ生活の糧を得る手段で、仕事が終わった後趣味を楽しめるのではなく、仕事によって生活が豊かになるすぱらしいポジションにつけることになります。こんなに楽しんでいてお金をもらっていいのかと思えることを仕事にする－－－これが理想なのではないでしょうか？中国の老子は、こんなことを言っています。

生きることの達人は、仕事と遊び、労働と余暇、心と体、教育と娯楽、愛と宗教の区別をつけない。何をやるにしろ、その道で卓越していることを目指す。仕事か遊びかは周りが決めてくれる。当人にとっては、つねに仕事であり遊びでもあるのだ。

【引用終わり】

「情熱とスキルと市場が重なり合うところ、それが、あなたにとってのスウィート・スポットです。」という一節を読んでちょっと目から鱗が落ちた。

• 情熱だけでもダメ、スキルがなければいけない
• 情熱とスキルがあっても市場がなければいけない

現実的な命題だなと思う。第一に好きなことがないという状態では話しが始まらない。好きでもスキルがなければその道で飯を食っていくことはできない。若いときはスキルがないし、何が好きかもまだよく分からない時期があった。スキルがつくことで、情熱を傾けることに値する仕事かどうかが分かることもあるだろう。

そして、残念ながら情熱があってスキルがあっても市場がなければ食っていけない。これはティナ・シーリングのような自分自身や他人が通り抜けてきた様々な経験を知っている者だからこそ持てる視点なのかもしれない。

自分は好きなこと、自分のスキルが活かせることで対価を得るにはどんな市場があるのかを考えるのが好きだ。それはすなわち、自分が他人からどのように評価されるのか、自分のスキルや成果に対してどのような対価が妥当と考えるのかを気にしているということでもある。

なぜか。なぜなら、それでいけるという分野があれば、ティナ・シーリングが言うようにそこが情熱とスキルと市場が重なり合う自分にとってのスウィート・スポットになるからだ。

それが見つかれば、こんなにいいことはない。そんなスポットを見つけられたら、仕事がただ生活の糧を得る手段で、仕事が終わった後趣味を楽しめるのではなく、仕事によって生活が豊かになるすぱらしいポジションにつけることになるからだ。

こうなれば最高だ。スキルを高める努力が苦にならないし、スキルが高まることでより価値の高い成果を上げることもできる。

この話は起業したいと考える人にだけ当てはまるのかというと、必ずしもそうではないと思う。日本では天職を探すというキーワードが広がっているように感じるが、現実問題としてはそこに市場があるかどうかという点は重要だ。

市場がないところに飛び出してしまうのはやはりリスクが大きいと思う。30代、40代はスキルを高めるとともにそのスキルが活かせる市場を見つけることに注力を注ぐべきかもしれないと思った。

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

我が家の冷蔵庫の自動製氷機が数ヶ月前に壊れた。もう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）を読むとよいと思う。

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

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人の職人を同じように気に掛けてやることはできない。そのアプローチの有効な範囲（プロジェクトの規模）はある。

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

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

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年の筆者は主張する。リコールになりかねない「危ない」プログラムの例にも注目。

著者として短いながら当を得た書評だと思う。感謝！

ひとりでは学食に入れないという若者が増えている

今週はもうひとつ映像コンテンツの感想を書こうと思う。NHK で4月23日（金）19:30に放送された特報首都圏「“ひとり”が恐い」というテレビ番組を電車の中でラジオで聞いた。


ゲスト ： 土井隆義
キャスター ： 中野純一

ひとりでは学食に入れないという若者が増えている。なかにはトイレで食事をすませる学生もいる。背景には、周囲から友だちがいないさびしい人間だと思われたくない心理が働いている。専門家は、携帯メールで２４時間常に維持される友人関係が、自己肯定感の大部分を占めるようになったと分析。大学では、友だち以外の分野で自分の居場所を持てるように、さまざまな取り組みを始めている。“ひとり”が怖いという若者の姿を伝える。

簡単に解説すると、学食でひとりで食べていることを見られることで、「あいつは友達がいないんだ」と思われることがイヤなので、そう思われるくらいなら歩きながらパンを食べたりトイレでささっと空腹を満たす方がいいとということなのだ。

「それほどまでに他人の目を気にするなんて」と思った人は、現代の若者達のコミュニケーションの方法について理解が足りていない。そうなる原因は携帯電話によるコミュニケーションの変化にある。

ようするに、現代の社会人になる前の若者達はメールで連絡を取り合うことで友達との連帯感を確保している。24時間「レス」できるようにしておくことが友達としての証であり、それができないと友達との距離が生まれる。

番組ではアドレス帳が500件までしか登録できないので700件まで登録できる携帯に買い換えた女子大生が出ていた。携帯電話のアドレス帳が友達の範囲であるような印象を感じる。

嘉悦大学では大学の入学式の前に新入生を集め大学構内を二人ひと組で回り、教授やサークルの先輩を訪ねるオリエンテーションゲームを行い、新入生の心のハードルを下げることに成功しているとのことだった。

冒頭に紹介したひとりで学食で食べられない学生に対して一緒に食事をしてくれるカウンセラーがいる大学もあるとのこと。（そうしないと辞めてしまう学生が後を絶たないのだとか）

もしも、自分が学生時代に携帯電話があったら確実に今の若者と同じ事をしていると思った。その環境があればもっとコミュニケーションが多くなって活動の範囲が広がったのではないかとも感じる。

ただ、その環境がなかったことでよかったのは一人で考えを巡らす時間が十分すぎるほどあったということだと思う。大学から離れた時にはたっぷりと一人の時間があった。

番組では携帯メールによる広くうすい四六時中つながっている状態の友達関係は若者の自立を疎外する傾向があるという。「自分は自分、他人は他人」という自己の確立が遅れるというのだ。

昔は、中学→高校→大学→社会人という流れの中で自己の確立が強まっていくのだが、携帯電話によるコミュニケーションにより、中学生レベルの自立にしかなっていないらしい。

twitter も24時間見ていてつぶやかないと疎外されるような感覚を持つようになると同様の問題が起きる可能性がある。

ちなみに、こういう時代になってしまった以上、パソコンや携帯電話が悪でありそれを排除すれば問題は解決すると考えるのはムリがあると思っている。なぜなら、これらのアイテムによるメリットもあるし、現実的に排除などできないからだ。

インフラの変化やコミュケーション手段の変化をキチンととらえて、それらのメリット、デメリットを把握しながら、どう向き合えばいいのかを考えていく必要があると思った。

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』という映画をTSUTAYAでレンタルして見た。あまりに内容がドラマティックだったので、これはどこまで脚色されているのだろうかと思って、もとのスレッドがまとめられているwikiサイトで記述をざっと読んでみた。驚いた。ほとんどスレッドに書かれていることが忠実に再現されているように見える。

考えさせられたのが、ここに描かれているのは組込みとITの違いがあるにせよ、同じソフトウェアを作るエンジニアの日々の風景だということだ。

この話しは本やコミック、映画になっているが、知らない人もタイトルを見れば、だいたい中身の予想は付くだろう。映画の中では R25 にブラック会社の条件が6つ書いてあり、主人公のマ男君が入社初日で全部当てはまることに絶句する。

【ブラック会社の条件】

1. 就業規則があるにも関わらず残業が当たり前
2. 何日も徹夜が続くことがある
3. 社内に情緒不安定な社員がいる
4. 必要経費が一切認められない
5. 同僚のスキルが異常に低い
6. 従業員の出入りが激しい

そして、確かにそういう会社がスクリーンに登場する。ちなみに、それはそれとして自分は主人公のマ男君や他のプロジェクトメンバーがやっている仕事の内容、流れについて見ていた。

【仕事の流れ】

1. 営業がクライアントから仕事を取ってくる。
2. 同行した技術担当は要求された仕事に対して開発期間が足らないと感じる。
3. 技術担当がクライアントにその日程ではムリと言おうとするとクライアントからダメなら他に回すよといわれ営業が受けてしまう。
4. 開発委託を受けた時点からすでにデスマーチが始まる
5. 納期に対してプロジェクト全体が責務を負い、遅れは分散するか特定のエンジニアへ集中させることでカバーする
6. 要求定義→設計→実装→テスト という工程はキチンと踏んでおり、プロジェクトの終了はシステムテストの成績書がすべてパスしたときになっている。
7. 死ぬほど残業してなんとか納期に間に合わせる。

そこでふと思ったのは、仕事の厳しさの違いはあるにせよ、この流れはどんなソフトウェアエンジニアも多かれ少なかれ経験しているようなことにように見えるということだ。

ブラック企業になるかならないか、もしくは、エンジニアが潰されてしまうかいなかの違いは、3のムリな日程を受けてしまうという部分と、5 の遅れの分散と特定のエンジニアへの仕事の集中のところだと思う。

【ムリな日程を受けてしまう営業】

クライアントとサプライヤという関係の場合、一般的にお金を払うクライアントの方が立場が強い。「イヤなら他に回すよ」と言われたら条件を飲まざる終えない。その条件を跳ね返すためには、ムリな日程を飲む以外の付加価値が必要になる。その付加価値が他の会社にはない価値でなければ競争に負けてしまう。

メーカーの場合、お金を払ってくれるのはエンドユーザーであり、リリースして商品が売れるか売れないかが分かるにはそれなりのディレイがあるから、請負開発の場合はよりプレッシャーが大きいと思う。

この問題は会社の経営者の考え方と経営方針で決まるのだろう。エンジニアを薄給でこき使って使い捨て目の前の売り上げを確保するという考えを持っているか、顧客満足を実現するのはエンジニアであり、顧客満足とエンジニアの満足・成長の両立を考えるのかで 180度環境は変わる。

後者よりも前者の会社に仕事を出すクライアントが多いとエンジニアにとって状況は改善しない。二次、三次といった下請け構造があると、下の階層になるほど環境は悪くなる。

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』の主人公は、実力はあり、唯一近くにいたよき先輩に鍛えられてブラック会社の中で成長するのだが、ブラック会社にしか入れなかったのは学歴で能力を判断されてしまったからだった。

もしこの話しが本当であったのならば、マ男君は死ぬほど苦労したが、3年間でプロジェクトリーダーを一回経験しプロジェクトも成功させたのだから、その実績を使ってもう少し環境のよい会社や、クライアント企業への転職などもできるのではないかと思った。ようするに、学歴以外の実績は実際の仕事を成功させることで積み重ねることができると思うのだ。

【遅れの分散と特定のエンジニアへの仕事の集中】

これは「あたたかい人間関係の中のやさしい一員」という日本人の特性のよい面と悪い面が両方でていると思う。プロジェクトの中で職制がはっきりしておらず、遅れを全体でバックアップするというやり方は連帯感を生むメリット、達成感を共有できるメリットがある一方で、個の確立を疎外する側面もあると思う。

技術者個人の成果や負荷が見えにくくなると思うのだ。責任と権限が明確な世界では他人の領域には指示がなければ踏み込まないから最終的な責務と成果が個人別にはっきりする。

それが曖昧だとブラック会社では優秀なエンジニアに負荷が集中し、その成果はプロジェクト全体に分散されてしまう。ブラック会社でなくても日本の企業ではそういう傾向があるように思う。

そうすると優秀な技術者が潰される可能性が高くなり、かつ、その様子を見ている他の技術者は積極的に仕事の効率化を目指さなくなる。

【『ブラック会社に勤めてるんだが、もう俺は限界もしれない』スレッドより引用】

スレタイの意味・・・
それは、木村くんの下克上でも、父ちゃんの病気でもない。
藤田さんが、会社を去る・・・。まさにこれこそが限界だったのだ。

何のためにスレッドを立てたのか。
確かに俺は限界だった。
このスレッドを立て、全てを書き終えた時、俺は退職しようと心に決めていた。
伸びても、伸びなくても、それは変わらない。
結果的にスレは物凄い勢いで伸び、パー速に移住するほどになってしまった。

そして、その中で俺への励まし、心配、叱咤。
色々なレスが俺に向けられて書き込まれた。
ブログのコメントは、続きを書いてくれ、という内容ばかりだった。
俺は今まで、誰からも必要とされない、居なくなっても誰も悲しまない
くだらない人間だと思ってたんだ。

だけど、このスレを立てた事で
俺はみんなから励まされて、心配されて、叱咤されて・・・
たった一人の力は確かに小さいかもしれない。
だけど、それが何十、何百となったら？
その小さな力が集まって、大きな一つの力となったら？

俺は奇跡を信じる気になったよ。
だって、スレッドタイトルが変わるんだもの。
『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』が
『ブラック会社に勤めてるんだが、まだ俺は頑張れるかもしれない』に。

【引用終わり】

スレッドの最終章を見ると、マ男君を支えたのは先輩の藤田さんと、ブログで応援してくれた人たちというだということが分かる。

ソフトウェアエンジニアは知識労働者だ。人間が人間の頭で勝負している世界だ。そう考えるとやっぱり人間を人間として扱ってもらえる環境と人間の頭を成長させてくれる環境と、自分自身の知識労働者としての意欲が大事であるということが『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て再認識した。

ポイントは実績がないときには、今の仕事を成功させてその中で達成した他から認められうる点を積み重ねてそれを武器にすることだと思う。そのためには今の仕事をやっつけでいい加減にこなしてはいけない。この一つ一つの仕事をまわりに自慢できるくらいきっちりこなして積み重ねることができれば、よりよい環境に進むことができるとはずだ。

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

『組込み開発現場のプロジェクトマネジメント＆プロセス改善』を読んだ。この本は以下の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. モンテッソーリメソッド（大人向け）：自立したエンジニアを育てよう！

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

ものづくりに関する共感した話し

何を隠そう自分はものすごいラジオ好きである。通勤の間、風呂に入っているとき、寝る前、朝早く起きてしまったときラジオのスイッチを付ける。一日のうちテレビを見ている時間よりも圧倒的にラジオを聞いている時間の方が長い。

さて、3月28日(日)の夜、何気なくラジオを聞いていたら、村田製作所がスポンサーになっているTBSラジオ『サイエンス・サイトーク』という番組に植松 努さんという飛行機好き、ロケット好きのいかにもものつくり職人といった方がゲスト出演していてその話しがとてもよかった。よかったと思ったのは植村さんと自分は同類だと感じたからかもしれない。

この番組はポッドキャストでも配信されており、今日紹介する話しはiPODに録音して、少しずつ再生しながらポメラでテキストに起こしたものだ。

前置きはそれくらいにして、植村さんが何を言ったのか紹介していこう。

【植松 努さんのプロフィール】

植松努(うえまつつとむ)植松電機専務取締役 1966年北海道芦別生まれ。子供のころから紙飛行機が好きで宇宙にあこがれ 大学で流体力学を学び、名古屋で航空機設計を手がける会社に入社。 5年後の1994年に実家のある北海道へ戻る。父(植松清)が経営する植松電機へ。 産業廃棄物からの除鉄、選鉄に使う電磁石の開発製作に成功。 分別用電磁石は全国のシェアの八割を誇るまでに導く。

■2010年03月28日放送 … ロケットを作った町工場(1)　番組の紹介文

北海道赤平市にある「植松電機」。親子二人だけの小さな町工場でしたが、現在は約20人の社員で、ロケットや小型人工衛星の製造を手がけています。

その背景には「将来はロケットの設計をしたい」という植松さんの子供の頃からの夢がありました。「どうせ無理」だと考えず、あきらめないで頑張れば夢はかなう、という植松さんは仕事のかたわら、講演や子供向けのロケット教室などで全国を飛び回っています。2回に渡ってたっぷり話を聞きます。

■植松さんの子どもの頃

• 飛行機・ロケット好きの植松少年は飛行機が作りたくて、独学で飛行機やロケットのことを学んだ。飛行機、ロケットを飛ばした人たちの伝記を読みあさった。
• 伝記を読んでいたのでいろいろな人が工夫をしていく様、トラブルの解決の仕方を学んだ結果あきらめ方（あきらめて投げ出すということ）を知らずに育った。

→成功と失敗を疑似体験し、最終は成功するというイメージトレーニングが出来たのだろう。伝記とはそういうものだ。

■飛行機を設計する会社に入ったとき

自分が小さいときからあこがれていた堀越二郎（ゼロ戦の設計者）がいた会社に入ることができた。（神様はいるものだと思った）そして念願の飛行機の設計をできることになった。

ところが、そのうち植村氏は周りが高学歴な人たちばかりであることに気がつき不安が募るようにる。そして、組織の中で自分が少しでも役に立ちたいと思い、飛行機の知識を周りにひけらかしまくるようになる。自分は子供の頃からのめり込んでいた世界なので他の人より遙かに多くのことを知っていた。しゃべり続ければ続けるほど徐々に自分が嫌われていくようになっていた。自分自身もそんなことをしているのが嫌になって引きこもるようになり、人と関わらなくなるようになった。仕事だけはやってそれ以外の対人関係はできるだけ避けるという状態。

■引きこもり状態からの回帰

自分が引きこもりになったときに救ってくれたのが寮の仲間たちだった。スポーツマンの同僚が自分を何かある度に誘ってくれていた。しかし、彼は自分の反対側にいる人だと思っていたので、誘われてもいかなかった。それでも何回も誘ってくれて、いつの日か誘われるままにスキーにいった。

自分はオールレンタルで滑った。誘ってくれた同僚に「おまえすごいな、転ばないな」と言われた。考えてみたら自分は北海道出身だし、子供の頃学校でもスキーをやっていたので当たり前のこと。それでスキーの技術をスポーツマンの同僚に教えていったらみるみる上達していった。そうしたら他の人にも「こいつに聞け」と紹介してくれた。それで自信を取り戻し、帰ってからスキーを一式買ってワックスかけてエッジを整備してとやっていたらどんどん人が集まる部屋になっていった。

そのときに「不安とは恐ろしいものだ」「自信はとても重要なものなんだ」と痛感した。

誘ってくる同僚に対して当時「なんで見ず知らずの自分に関わってくるのだろう」「嫌だ嫌だ」とずっと思っていたのだけれども、困っている自分を見てなんとかしなくてはいけないなと思ってくれたのだと思う。もしかしたら彼自身も苦しい時期があったのかもしれない。

■なぜ、飛行機を設計する会社を辞めてしまったのか？

自分たちよりも後に入ってくる人たちが飛行機から遠ざかっていることに気がついた。飛行機を作る仕事をしているのに飛行機にまったく興味がない。学研の図鑑を読んだことがない人たちが続々と入ってくるようになってくる。そうすると彼らは好きじゃないから頑張れない。そしていわれたこと以外ことをすると損をするという発想を持っている。だから要求されたことしかやらないようになる。当時、自分のいた会社には「奇跡は仕様書には書かれていない」「奇跡は要求されたことの中には書いていないからお人好しが起こすんだよ」という言葉があった。彼らはそれをやらない人たちになっていった。それはミニマムマキシマムだと思った。最低限これだけはやっておいてねといわれたことを、「それだけやっておけば十分なんだろ」「それ以上のことをしたら損する」という考え方。

好きなことはどれだけやっても損はしないはず。ところが好きなことが奪い取られるしくみがある。それは中学校くらいから始まる。「受験以外のことをしたら損をするよ」ということを誰かが教える。「必要最低限のやまを暗記してそれ以外のことを入れたら頭が損をするよ」と教えられるようになる。そうると受験勉強のこと以外のことをいっさいできなくなる。

この世の中に損なことはひとつしかなくて、それは何もしないこと、面倒くさいけど自分がやりたいこと避ければ避けるほど本当は損するのに「最短コースこそが美徳です」のようなことを教えてしまうと負のスパイラルは激しさを増す。

「効率が嫌いなんですか」というラジオパーソナリティの問いに対して、

手加減をしている一秒も自分の一秒ですから自分の人生短いんだから手加減したり楽したりしないほうがいいんじゃないのと思う。それを誰かが「楽をして暮らすんだよ」「楽した方がいいよ」と教える。楽ということを目標みたいに伝える人がいる。でも楽したら辛いと思う。

暇はつぶしちゃいけないんですよ。暇は自分にとって特になることに使えば人生の時間はすごく輝きを増すはずなんです。人生の幸せは生涯賃金の総額ではないことはみんな分かっていると思う。人生の時間を費やして得た知恵と経験と周りの信頼と愛情こそが人生の価値だろうと思う。

自分のくふうが報われたときに泣けるんです。泣くほどしんどいときに泣けるんだろうと思います。

自分は自分のことを職人だと思っているから、植村さんの言っていることがよく分かる。しかし、一方で自分がものづくりに寄せる想いの強さと、それほどまでに想いが強くない人たちと一緒に仕事をしなけれいけないという現実も分かっている。それがイヤなら植村さんの会社のように少数精鋭の組織で仕事をするしかない。しかし、もっと大きな組織でなければできない商品もある。

車の世界では新車種の開発はチーフエンジニアと呼ばれる技術者が全責任を担う。トヨタではチーフエンジニアのアシスタントを4～５年務めてからチーフエンジニアに昇格するのが普通だったが、車種の増加と開発期間の短縮で近年は「経験を十分に積まないまま、チーフエンジニアに抜擢されるケースも目立つらしい。昔はチーフエンジニアを中心に開発チームが寝食を忘れて徹底的に議論して一台の車を作り上げる泥臭さがあったがいまではパーツごとの縦割り開発にならざるを得ない。

プリウスのブレーキシステムの複雑さを見れば分かるように、今では車全部の機能やメカニズム、制御方法をチーフエンジニアが全部把握するのは無理だ。ひとりのエンジニアがシステム全体を見渡せるシステム規模ではなくなっている。

だから、植村さんが言うようなエンジニアが必要なことは間違いないが、プロジェクト全員にそういう意識を持たせるのは難しい。それでも、顧客満足は満たさなければいけないし、安全は絶対に確保しなければいけない。「品質を心配する意識の強さ」「エンジニアの商品にかける熱意」だけでは安全は確保できない時代に突入している。「品質を心配する意識の強さ」「エンジニアの商品にかける熱意」を保ちながら、システマティックに安全分析を行い、安全アーキテクチャを設計することが求められている。

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

日経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 の施策であるソフトウェア品質のマネージメント技術を修得する必要があります。
そして、最後に必要なのはソフトウェアの資産化です。昔からベテランのソフトウェアエンジニアは、枯れたソフトウェアモジュールを再利用することで品質と効率が高まることを肌で感じていました。だからこそ、枯れたソフトウェアを安易に変更せず、後々まで変更しないで済むようによく考えてソフトウェアモジュールを作っていたのです。

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

本書で提案したいこと

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

【引用終わり】