2013-02-23

ISO 26262との向き合い方 (21) 安全について理解を深める

ちょっとでも危険がある製品を開発するエンジニアが安全の概念について理解することは非常に重要だと思っている。※1 なぜなら、安全が必要なもの作りをしている者にとって空気のように当たり前と思っていたことが、安全に関わったことのない人には十分に理解してもらえず、話しがすれ違うことに気がついたからである。

※1 危険、リスクは思いもよらないところに潜んでいるので、自分が作ったソフトウェアが危険にはまったく関係ないと思っていても、思わぬ事故が起こることはよくある。安全ソフトウェアを目指す仕事をしていると、どんなリスクがあるが臭いで分かるようになる。

そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。

Microsoft の社員の肩書きで Evangelist(エバンジェリスト:伝道者)というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。

宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。(洗脳者のような胡散臭い感じもするが・・・)

安全について理解を深める

世の中で数学や物理、化学など再現が可能で証明できる定理はたくさんある。一方で、答えが同じにならないこともたくさんある。人間が作るソフトウェアに関することはほとんどがそうだし、安全に関する概念、定義も同様に絶対的なものは存在しない。

そこで、何をもとに安全(Safety)を説明すべきかずっと考えていた。実は、ISOやIECの国際規格でさえ、定義に矛盾や背反が存在する。

業務ドメインの違いによって対立軸がある場合もある。例えば、IEC 61508 に代表される機能安全のグループと ISO 14971 や IEC 60601-1, IEC 62304 といった医療機器関係の国際規格には考え方の違いがある。

安全(Safety)に対する概念は機能安全系の規格と医療機器系の規格では差異があるかもしれないということだ。(詳細に比較、検証したことはない) 国際規格を検討しているグループは、常に規格間の概念の差異や用語の定義の相違を是正すべく、努力を続けている。国際規格は一度決めたら終わりではない。常に生きているのだ。逆に言えば、国際標準でさえ、統一されていない考え方、主張も現実にはあるということである。

そういう現状があるから、医療機器系の安全(Safety)の概念をごり押しするような伝道では、自動車、鉄道、航空宇宙等のドメインの方達に受け入れてもらえないであろうと思っている。

そこで、考えたのが ISO/IEC Guide 51:1999 Safety aspects — Guidelines for their inclusion in standards (JIS Z 8051:2004 安全側面-規格への導入指針) を使って説明する方法だ。

ISO/IEC Guide 51 は、規格に安全に関する規定を導入する際に参照され、機械、電気、医療、科学など幅広い分野で作成される安全規格に適用されるガイドラインである。

だから、ISO/IEC Guide 51 は言わば、機械、電気、医療、科学に関する国際規格の上位に位置するガイドラインだ。そして、日本には、ISO/IEC Guide 51 の解説者として著名な明治大学の向殿政男先生がいる。向殿先生が監修されている『安全設計の基本概念』には、ISO/IEC Guide 51 のことが非常に丁寧に分かりやすく説明されている。

自分はこの本を引用しながら、ISO/IEC Guide 51が定義する安全の概念について、ここに記そうと思う。

安全の定義とは

下記の文章は記事の執筆を依頼されたあるガイドラインにために書いた原稿の一部で、安全の定義について説明した文章なのでまずは読んでみて欲しい。
安全(セーフティ)とは、〔ISO/IEC GUIDE 51:1999〕によれば,『受容できないリスクがないこと』と定義される。すなわち、安全(セーフティ)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。 
安全はリスクを経由して定義され、リスクはその時代、社会の情勢、環境によっても変化するため安全の尺度を一定にすることはできず、絶対的な安全を定義することはできない。そのため、製品、プロセスまたはサービスは相対的に安全であるとしか言えない。 
安全は、リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは、使用者の利便性、目的適合性,費用対効果、並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって、許容可能なリスクは常に見直す必要がある。 
技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して、最小リスクを達成できるような改善が経済的に実現可能になったときは、特に見直しが必要である。
安全(セーフティ)は『受容できないリスクがないこと』だから、リスクを想定しなければ、また、リスクを想定できなければ、安全を確保することはできない。安全に関して伝道したいことの中で最も重要なことがこれだ。

「具体的なリスクを想定しないでソフトウェア品質やソフトウェアの信頼性について語る人」「具体的なリスクを想定しないで、実装すると効果がある対策、方法論があるという人」「具体的なリスクを想定しないで、開発に採用すると効果があるツールであると主張する人」がいる。

これらの人達は安全(セーフティ)について語っているのではない。安全(セーフティ)を実現するためのリスクコントロール手段を説明しているのではない。

ソフトウェアの品質の向上施策・信頼性向上について語っているのだ。Quality(品質) や Dependability(信頼性), Reliability(信頼性)の話であって、Safety(安全)の話ではない。

ISO/IEC Guide 51より、安全性と信頼性の違いについての記述を引用する。
信頼性は機器で言えば、故障せずにその機能を正常に保つことを目標にするものであり、一方、安全性は人間に危害が及ばないように機器が機能し、使用することができることを目標としている。 
もちろん、故障しないで本来機能を発揮することにより安全性を確保することが望ましいが、故障しても安全性を確保する設計が安全設計では望まれる。これにより信頼性と安全性は異なる概念であることが分かる。
また、すべてのリスクに対して有効に働くリスク低減手段は存在せず、個々の製品、プロセスまたはサービスに対してリスクアセスメントを行った上でリスク低減策を設計しなければ安全は確保できない。
製品、プロセスまたはサービスに対する品質向上施策は信頼性向上には効果があっても安全性向上にも効果があるとは限らない。これは品質が高いことと安全であることは同位ではなく、品質の概念と安全の概念の間にも異なる観点が存在することを意味している。

なお、『ソフトウェア品質知識体系ガイド―SQuBOK Guide』には、品質についての定義がいくつも紹介されている。品質を価値と考え、安全は価値の一つであると定義すれば、安全は品質に包含されるのかもしれない。しかし、品質は概念が広すぎて、品質向上施策の御旗が何でもありのように安易に使われてしまう危険性を感じる。

抽象を尊び、具体を卑下する人たちをたまに見かけることがあるが(「そんな具体的な話しかできないのかよ」とか「○○理論も知らないのか」という目をされるとき)、それは間違いだ。抽象化はより多くの具体を取り扱うための手段であって、目的は具体の解決の中にある。具体に踏み込まず抽象のレイヤーで議論を終始している者は「おお、何か難しいことばを使って説明している」と一見カッコ良く見えるが、社会に貢献するためには具体の中にある問題を解決していかなければ意味がない。

この記事を読んでおられる読者は「抽象だろうと、具体だろうと、信頼性を目指しても、安全性を目指しても、結果的にやることは同じだろう」と思われているかもしれないが、それは違う。その違いを伝えるのが伝道師の役目だ。

分かりやすい例で言えば、鉄道では何かあったとときは列車、電車を止める制御をすれば安全を確保できる。(登山鉄道とか崩れかけた鉄橋の上といった危険状態ではその限りではないかもしれない) しかし、飛行機が空を飛んでいるときのリスクコントロール手段は飛行機を停止させることではない。飛行中に何か異常があった場合は、緊急着陸するまで飛行機を飛ばし続けなければいけない。鉄道のように止めてはいけない。同じ、輸送手段であっても、リスクや危険状態(Hazardous Situation)によって、リスクコントロール手段(Risk Control Measure)は異なるのだ。

例えば、車のエンジンサイズまで、容量を小さくした超小型の原子力エンジンが発明されたとする。(現実の世界では原子力空母の中に原子炉がある)

爆発すれば被害は甚大だが、20年間燃料の補給が不要で安全性も完璧だという触れ込みで発売されたとする。原子力エンジンの製造メーカーは、異常時には超小型原子炉を停止させる独立した安全装置が付いているので、どんな用途にも安全に使えると宣伝した。

※この話は、ISO 26262 に対応していると主張する CPU や、コンパイラ、ツールをセールスしている会社のメタファーだ。

しかし、最初の例示したように、この超小型の原子力エンジンの安全装置は飛行機のリスクコントロールには使えない。安全に原子力エンジンを停止すれば、飛行機が墜落してしまうからである。

飛行機の製造業者はそんなことは百も承知なので、例えば、エンジンを2機積むなどしてリスクをコントロールするだろう。(現実にもそうだ)

伝道師が強調したいのは、安全は最終製品に対するリスクを想定できるもののみが達成できるのであり、ソフトウェアの Quality(品質)やDependability(信頼性), Reliability(信頼性)のみを語る人には、安全は達成できないということである。(エンドユーザにとってどんなリスクが有りうるかを想定していないから、対応策がリスクを受容するに十分かどうか判断できない。すべてのリスクに対応できると言うならそれは銀の弾丸だ。)

だから、ISO/IEC GUIDE 51:1999 では安全を『受容できないリスクがないこと』と定義したのだ。設計者や機器のオペレータができるのは「リスクを許容可能なレベルまで低減させる」ことだけだ。リスクをゼロにすることはできないし、できると考えてはいけない。福島の原子力発電所の事故の経験がそれを裏付けている。

そして、、ISO/IEC GUIDE 51:1999 には「許容可能なリスクは、使用者の利便性、目的適合性,費用対効果、並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって、許容可能なリスクは常に見直す必要がある。 」と書かれている。

この常に見直しをする必要があるというところが重要なポイントである。下記の図を見て欲しい。これは、ISO/IEC GUIDE 51:1999 に掲載されているリスクアセスメント及びリスク低減の反復プロセスの図である。

リスクアセスメント及びリスク低減の反復プロセス
この図の最も重要なところは、リスクアセスメントとリスク低減は繰り返す必要があるということである。

なぜか。リスクはその時代、社会の情勢、環境によって変化するからである。

だから、これで完璧と思ってもそのリスクコントロール手段は時代や社会、環境の変化によって更新しなければいけないかもしれない。

アクティブ・セーフティとして代表的なABS(アンチ・ロックブレーキ・システム)も、ほとんどすべての車に装備されてしまったら、ユーザはさらなる対策を求める。

だから、リスクアセスメントとリスク低減はその市場で商品を売り続ける限り、ずっと繰り返さなければならない。

だから、安全が求められる商品は価格は高い。潜在的な価値を維持するためにコストがかかるからだ。そのコストを削ろうとすると、安全の実現に暗雲が立ち込める。(放射線治療器の Therac-25 の事故の例がそれに相当する。経済的利益を優先させた会社の判断が事故を生むトリガーになった。セーフウェアを参照のこと。)

そして、価格が高い=高利益だと思っても、セーフティ・クリティカルな商品を扱う市場への新規参入が簡単ではない。なぜなら、新規参入企業は「リスクアセスメント及びリスク低減の反復プロセス」を反復したことがないからだ。

簡単に言えば、安全に関するノウハウがない(フィードバックすべき市場情報=多くは製品の不具合情報)ので、このプロセスを回せない。

だから、各製品群ごとに安全に関する国際規格が存在する。機器の安全に関する国際規格は、リスクアセスメント及びリスク低減の反復プロセスを回したことがない企業が、いきなりもの作りをして危険な製品を作らないためのハードルであり、保険である。

逆に言えば、その商品群において、要求された安全規格をクリアすれば最低限の安全を確保できる可能性は高い。(規格を作っている人達は機器の使用環境とリスクを十分に想定しているのに、規格には危険状態:Hazardous Situation のことはあまり書いておらず、リスクコントロール手段しか書いていない点は問題だと思っている。)

ところが、ソフトウェアが絡むとそう簡単ではない。これをやれば安全という銀の弾丸のようなリスクコントロール手段はない。(最近の ISO 26262 絡みのセールスを見ていると、かつての『人月の神話』を別の形で繰り返しているように思える)

しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。(『ソフトウェア品質論の歴史的推移』を参照されたし)

そこで、ソフトウェアに関する安全規格が作られると、プロセスアプローチの面が強調され、リスクアセスメントやリスクコントロールの重要性が飛んでしまう傾向を感じる。(医療機器ドメインは今はそうはなっていないが常に危険にさらされている。)

そして、業務ドメインに依存しない ソフトウェアに共通の ISO/IEC 25000. System and software product Quality. Requirements and Evaluation (SQuaRE) のような規格や、CMMI(Capability Maturity Model Integration) が、安全(Safety)にも有効だと語る者が現れる。(正確にはすべてのソフトウェア開発に有効だという主張)

業務ドメインに依存しない商品、ツール、方法論が存在すれば、セールスが楽で、売り上げ向上が見込めるためみんなその路線に乗ってくる。

しかし、安全ソフトウェアの伝道師はここで釘をささなければいけない。それは、Quality(品質)やDependability(信頼性), Reliability(信頼性)のことを言っているのであって、Safety(安全)とは異なると。

安全を確保するためには、リスクアセスメント(ハザードの特定、リスクの見積もり、リスクの評価)とリスク対策を繰り返し行わなければいけない。一度では終わらないし、ずっと続けなければいけない。

だから、言いたいのは、Quality(品質)やDependability(信頼性), Reliability(信頼性)向上の方法論を知っている人、組織、研究者は、安全が必要な製品を開発している企業とタッグを組んで、「リスクアセスメント及びリスク低減の反復プロセス」が効果的にまわるように助けてあげて欲しい。

それは、泥臭く、効率が悪く、面倒くさいかもしれないが、それをしないと製品の安全は向上しない。そして、かつての日本ではそんなアプローチが盛んに行われてきたと聞く。詳しくはしらないが、品質機能展開は製造業者の問題解決と共に発展してきたと思うし、QCサークルだってそうだろう。

いつから日本のエンジニアは、銀の弾丸を買うこと(=方法論を一方的に受け入れる)しかしなくなってしまったのだろうか。

それと、日本の企業はソフトウェア絡みの事故情報を自分達だけで抱えて秘密にしておくなと言いたい。出せるものは出して、その情報を他の業界や研究者と共有し、再発防止策を提案していかないからいけないのだと思う。

安全対策の技術を向上させるために絶対に必要なのは、事故の詳細な情報だ。これは歴史が証明している。
  • スペースシャトルチャレンジャーの事故分析(宇宙)→ロケット開発に対する教訓
  • ミニッツロケットの安定化(軍事)→FTAの発明
  • ピントの事故(自動車)→FMEAの普及
  • Therac-25(医療機器)→医療機器のソフトウェア開発に対する教訓
これらの事故が、安全に貢献する方法論を生み出すきっかけを作った。事故情報をインプットにしないで、リスクコントロール手段を提案するのは間違いだと思っている。

自慢しいだと思われるかもしれないが、これは、過去に起きたソフトウェアが絡んだ医療機器のリコール情報を分析し、医療機器のソフトウェア開発プロセスの規格である IEC 62304 のどのアクティビティ、タスクが事故の再発防止の効果があるかを分析した Industrial Paper だ。

自動車だって同じことができると思う。ソフトウェア絡みの自動車の事故に対して、ISO 26262 を適用したら事故は防げたのか、どのプロセス、アクティビティが有効なのかを分析してみて欲しい。

自分は、ISO 26262 の中で、Part 8: Supporting processes(支援プロセス)の「ソフトウェア・ツールの使用への信頼」のところが最も役に立たないと思っている。なぜなら、これまで述べてきたように、ツールに対する信頼は、具体的なリスクを想定していないので何のリスク低減に有効なのかが分からないからだ。すべてのリスク低減に効くという論理は銀の弾丸と同じであることは説明するまでもないであろう。

例えば、下記は2005年にアナウンスされたあるメジャーな会社のCPUのコンパイラの不具合通知である。(cpuが特定できないように所々伏せている)

2.3 配列要素への代入式の注意事項
       if文の前とthen節内で、同じ配列への代入文が存在するとき、その配列の値
       が正しく代入されない場合があります。
       発生条件: 以下のすべての条件を満たす場合に発生します。
         1. cpu=○○ または、△△
            オプションを選択している
         2. optimize=1オプションを選択している
         3. 繰り返し文の中に選択文(else節のないif文)がある
         4. if文の前と(3)のthen節に同じ配列要素への代入式がある
         5. if文の前の代入式の右辺を"式1"、if文内then節の代入式の右辺を"式2"
            として、式1、式2の型が異なっている
         6. 5.の式1と式2は、以下のいずれかを満たしている
           -式1が式2の型で表せる範囲外の値をとることがある
           -式2が式1の型で表せる範囲外の値をとることがある

       例:
       -------------------------------------------------------
       #define MAX 10
       int A[MAX];
        int x, y, z;
        char sc0, sc1, sc2;
        test(){
            int i;
            for(i = 0; i < MAX; i++){
                A[i] = x + y;          /* 発生条件4, 5および 6 */
                /* if(z)がFALSEになるときに配列A[i]にx+yの値が
                    正しく代入されない */
                if(z){                 /* 発生条件3 */
                    A[i] = sc0;        /* 発生条件4, 5および 6 */
                }
                x++;
                y++;
                sc0++;
            }
        }
       -------------------------------------------------------
        回避策:
        以下のいずれかの方法で回避してください。
        (a) optimize=0オプションを選択する。
        (b) then節にnop()組み込み関数を入れる。
            発生例の回避例
            -------------------------------------------------------
            #include
    . . . . . . . . . . . . . . . . . . . . . . . .
              if(z){
              nop(); //組み込み関数の追加
                 A[i] = sc0;      
              }
            -------------------------------------------------------
        (c) else節を用意し、nop()組み込み関数を入れる。
            発生例の回避例
            -------------------------------------------------------
            #include
    . . . . . . . . . . . . . . . . . . . . . . . .
              if(z){
              A[i] = sc0;
              } else{
              nop();           /* 組み込み関数の追加 */
              }
            -------------------------------------------------------
        (d) 式1とif文の間にnop()組み込み関数を入れる
            -------------------------------------------------------
            #include
    . . . . . . . . . . . . . . . . . . . . . . . .
                A[i] = x + y;
                nop();            /* 組み込み関数の追加 */
                if(z){
                    A[i] = sc0;
                }
            -------------------------------------------------------
 「if文の前とthen節内で、同じ配列への代入文が存在するとき、その配列の値 が正しく代入されない場合があります。」などと、とんでもないことが平然と書かれているが、現実にこういう連絡はたまにある。正直に連絡してくれているから逆に信頼が持てる。お客に知らせないでしらばっくれることだって可能なのだ。不具合情報の連絡は保守契約の中に条件が書いてあるはずだが、日本の会社は保守契約書に書いてあるかどうかよりも、現実に対応しているかどうかの方を重視している。

この不具合情報をよく見ると、最適化オプションを選択したときのみ発生するとある。そういう危険性があることは勘で分かっているため、製品開発では最適化オプションはオンには絶対にしない。だから、このコンパイラの不具合情報が来たときも、自分達の開発では「セーフ」だった。

仮に最適化オプションをオンにしていたとしても、こんな複雑な条件に合致することはないだろう。ただ、絶対にそういうプログラムを書かないという保証はないし、安全クラスが高いソフトウェアアイテムで起こったらとんでもない話だ。

すでにリリースしてしまった製品のソフトウェアで落ちてきた売り上げを少しでもアップするためにソフトウェアを追加、変更して欲しいという要求がセールス部門から上がってきたとする。でも、古い製品でROMの領域がほとんどない。「じゃあ、コンパイラのサイズ最適化のオプションをONにするか」などというシチュエーションがあっても不思議ではない。

そのとき、経験を積んだプロジェクトリーダーはその要求を断固拒否するか、コンパイルオブションをONにしないで何とかする方法を考える。こういうオペレーションをISO 26262はプロセスで要求できるのか?と言いたい。

エンジニアはこの3Eで危険を抑えているのではないか。

【安全を実現するには3Eが必要】
  • Experience(経験)
  • Education(教育)
  • Enthusiasm(熱中、熱意、情熱、こだわり)
プロセスアプローチは全体的には賛成だが、実際に現場で起きている複雑で滅多に起きないソフトウェアの不具合を確実に排除できるとは思わない。

あったら困るが、見つけることは極めて難しい。それが、現実のソフトウェアの不具合だ。だから、そのようなソフトウェアの不具合を一律に抑えようとするのは賢いやり方ではないと思う。勘や経験、実績も総動員して防がなければいけないが、一番有効なのはリスクアセスメントとリスクコントロールである。

この例を提示した理由は、コンパイラの不具合は発生したとしても、ものすごく複雑な条件で起こるということを示したかったからである。

普通に使っていて、期待しないコードが吐き出されるようなコンパイラを、クリティカルな製品に使うはずがない。どのコンパイラを使うかどうかの判断で、一番確からしいのは使用実績だ。ようするに信用である。ただ、信用だけでは判断できないのが、大規模・複雑化した現代のソフトウェアなのだ。普通の使い方をして問題が起こるようなソフトウェアを平気で出すような会社は日本ではほとんどないと思っている。

だから、何か危険な爆弾が潜在していたとしても、上記のようなものすごく複雑な条件で不具合は発生する。そういう不具合が発生する可能性があるのかないのかは、何で判断するべきか。

それは、対象物の検証結果、テスト結果で見るべきだろう。間違っても、認証のあるなしのようなお墨付きで判断してはいけない。ようするに、どんなテストケースで、どんな判定結果でテストを行ったのか、どんな異常状態を想定してテストを行ったのか、要求仕様に対してどれくらいのカバレッジでテストをしたのかで判断することが大事だ。

このことは、TechVillage に『クリティカル・システムに使う市販ソフトウェアの検証方法』というタイトルで記事を掲載しているので、そちらを読んいただきたい。

ISO 26262-8 Supporting processes(支援プロセス)「ソフトウェア・ツールの使用への信頼」では、ちっとも安心できないというのが自分の意見だ。なぜなら、検査対象によって何を検証すべきかを求めていないからである。つまり、そのツールが使われる場面の具体的なリスクを想定しなくても、パスできる要求だから安全には使えないと思っている。

上記のような、非常に分かりにくい不具合を事前に見つけることはとても難しいと予想する。この報告書群は一度キチンと精査したいと思っているが、規格や方法論を使うことが目的になっていないだろうか。自分にはこれらの報告書を読んでも、執筆者達のソフトウェアが絡む自動車の事故を減らしたいという熱意がまったく感じられない。

報告群の随所で「方法論を適切に使用している」ことで目的(説明責任)が果たせているというくだりを見かける。それは方法論を使うことが目的なのであって、エンドユーザーの利益、エンドユーザーの安全が目的になっていない。規格を使うこと、方法論を使うことが目的なのだ。「こんだけ難解な規格を使いこなしているぞ」「こんなに難しい方法論を使っているぞ」ということを一所懸命主張している。「難しい問題を解くことができました、すごいでしょ。」と言っているように見える。それって、社会に対して何を貢献しているのだろう。

ちなみに、報告の中には具体的な事例が載ってるものもある。しかし、事例が例示されていても、すでに安全を確保できているシステム、制御方法を対象とする規格や方法論で分析し直したようにしか見えない。現在、発生している事故、未来に発生する危険性があるリスクを未然に防ぎたいという目標があるだろうか。

自動車事故を減らすための取り組み

TBSラジオ、森本毅郎 スタンバイ!で東京大学名誉教授の月尾嘉男先生が話されていたのは自動車事故によりなくなる人は世界中で年間150万人でそのほとんどが自動車の整備不良なのではなく、運転者の不注意などという事実だ。

日本では、交通事故による死亡者数は減少しており、2009年からは5000人を切っている。だから、問題の多くは日本の外で起こっているのだ。

この数字を突きつけられると、ブリクラッシュ・ブレーキシステム への自分の後ろ向きの発言は変えていかなければならないと感じる。年間、150万人の自動車事故による死亡者を減少させる取り組みには意味がある。それは目指すべき目的となる。

このブログでも取り上げた、制動制御が複雑化したことによる予期せぬ動作に対する責任は運転手ではなく、自動車メーカに問われるようになる。その責任の所在、責任の取り方についての議論は、制御システムの開発、改善とは別の次元で進めなければいけない。

そして、制動制御の複雑化が、基本性能、基本機能に悪影響を与えないようにする責任は技術者にある。ソフトウェアの複雑化による Systematic failure のリスクよりも、年間150万人の死亡事故を減少させる社会的な意義の方が大きい。

ただ、だからといって何も考えずに既存のソフトウェアに新しい機能を付け足すアプローチを取ってよい訳ではないので、どうすれば想定したリスクを受容しながら、リスクコントロール手段としてのソフトウェアアーキテクチャを崩すことなく、新しく追加した意図した使用(Intended Use)を達成できるのかを考えないといけない。

USのネバダ州では無人運転車にライセンスを付与できることにした。Googleが第一号を取得し、Google Map用に無人運転車がすでに50万キロ走り、無事故であるという。

技術革新は表の面は華々しいが、当たり前に問題が起こらないようにする努力は裏でやり続けないといけない。

ソフトウェアに関するリスクコントロール手段に関して足らないのは、複雑性に対応するための方法論だと思う。ヒントは下記の表にあるはずなので、有効な方法を考えて、現実の製品に適用し、本当に事故が減るのかどうか、リスクアセスメント及びリスク低減の反復プロセスを繰り返す。これが自動車業界が行うべきことではないか。

表 安全を考える上で必要な要件
[〔宮崎, 向殿,安全設計の基本概念,2007〕表2.5 の記述内容を元に表を作成]
対象
内容の例
何を”
(保護対象)
人の健康,身体,命
人の心の安定,安心
金銭,財産
機械,システム,プロセス,ネットワーク
情報,データ,品質
“何から”
(安全を脅かす原因,脅威)
機器のハードウェアの故障・劣化,ソフトウェアのバグ
地震,雷,台風
ヒューマンエラー,設計ミス,誤解など,機械を取り扱う人間側の過誤
破壊,ハッカー(厳密にはクラッカー),テロ,なりすまし,盗聴,などの人間の悪意のある行動
設計以外の負荷,通信の輻輳などの過負荷
大規模化,複雑化,ブラックボックス化などによる複雑性
時代(年代ギャップ,バージョンアップによるギャップ),文化(異文化ギャップ),などに起因するコミュニケーション不足
環境変化(景気の変化,社会の変化,時代の変化など)
“何により”
(対策)
高信頼性部品等を使用することで機械そのものを故障しないように作る。(フォールトアボイダンスと呼ばれる技術)
ソフトにバグが入り込まないように,設計に誤りが入り込まないように作る。(人間の設計ミスを少なくする技術)
冗長技術を利用する。(フォールトトレランスと呼ばれる技術)
部品や設備を二重化,三重化することで,一つが駄目になっても他のもので補う構造を採用する。(空間冗長)
何回か繰り返したり,やり直したりすることで正しいことを確認する。(時間冗長)
誤っても訂正可能なように情報を付加しておく。(情報冗長)
設計の段階から安全を考慮する。
危険の安全を最初からないように作る。(本質安全設計)
機械が故障しても安全なように配慮して設計する。(フェールセーフ設計)
人現が間違えても安全なように配慮して設計する。(エラープルーフ設計)
テストや保全が容易なように設計する。(テスト容易化,保全容易化設計)
監視機構,チェック機構等の機構を導入する。
事故が起きたときに被害が広がらないように設計する。
人間の注意により安全を確保する。(注意・訓練,マネジメント,組織,管理等による方法)
制度により安全を確保する。(法規制,標準化,認証制度,保証制,保険制度等による方法


ISO 26262 も リスク低減の反復プロセスの中で、規格が求めている要求事項のどれが有効に働いたのかを検証し、有効に働いたところを強化し、働かなかったところを削除していくことが必要だと思う。

ボーイング787に搭載したリチウムイオン電池の発火事故の原因が現在調査されている。一説には、飛行機の振動が当初の設計時の想定を超えるものであったと聞く。リチウムイオン電池はそもそも高エネルギーを蓄えることができ危険性が高いといわれていたが、安全設計、安全装置を施すことで、大きな問題を押さえ込んできた。しかし、想定を超える環境下での使用があったのかもしれない。

ハードウェアの問題は、リスク低減のプロセスを回し、安全対策を積み重ねることで、安全の成熟度を増すことが可能だ。しかし、ソフトウェアで問題が起こるたびに、安全対策と称して追加、変更を繰り返すのはきわめて危険だ。

ソフトウェアの複雑性は非常にわかりにくい不具合を作り込んでしまう危険があるからだ。だから、ソフトウェア搭載機器の安全を保つためには、ソフトウェアによるリスクコントロールの設計技術と、安全を考慮したソフトウェアシステムのアーキテクチャ設計が崩れていないことを監視し続けることが大事である。


ここで記事にした内容に具体的なリスクアセスメント、リスクコントロール手段の方法論の解説をプラスして SESSAMEの 1Day セミナーに仕上げ、6月に東京で実施することを計画している。(SESSAME へ企画提案済み)

安全ソフトウェアのエバンジェリストとしての役目を果たしていきたいと思う。(東京だけでなく)

2013-02-20

『組込みソフトエンジニアを極める』についてのニュース

2012年7月18日に韓国人のCho JinJe さんから下記のようなメールが来た。
酒井 様

私は韓国の組み込みソフトウェアエンジニアのCho JinJeともします。
1999年から組込みソフトウェア開発の仕事しています。
2000年6月から2006年11月まで日本資本の複合機のソフトウェア開発会社に勤めながらプリンタと複合機ソフトウェア開発の仕事をし、10回余りの日本出張に行きながら日本の組込みソフトウェア開発に関心を持って関連した本を読みました。

私は2007年からはセットトップボックス、DVRなどに組込みLinuxを利用した製品を開発し、今月から自分の会社を作ってエンベデッド ソフトウェアに対する講義、サービス開発などをしています。

昨年にはあなたの”リコールを起こさないソフトウェアのつくり方”を読んで多くの助けを得ました。 
最近では”リアルタイムOSから出発して組込みソフトエンジニアを極める”を読みました。
本当に良い本だと考えます。韓国の関連従事者も必ず読む必要がある本だと考えます。ぜひ私が”リアルタイムOSから出発して組込みソフトエンジニアを極める”を韓国のエンジニアのために翻訳できるようにして下さい。

お願いいたします。

もちろん、翻訳OKということになって、Cho さんとのやりとり(韓国語に直すにあたって意味がよく分からない点の修正や、韓国の読者向けに表現を変えるなど)を行い、2013年2月に韓国語版の発売が決まった。

韓国版の本の表紙がこれである。そして、Cho さんに韓国語版の発刊に当たってのコメントを書いて欲しいと頼まれたので、下記のコメントを送った。(韓国語に翻訳され、本に掲載されるはず)

韓国語版刊行にあたって
ソフトウェアは生身の人間が日々の活動によって作り上げるものであり、人間の特性を考慮せずしてソフトウェア開発の成功はあり得ません。
特に、組込みソフトウェアはセンサーやアクチュエータや表示デバイスを使い機器の実際の動きを見ながら開発を進めていきます。 
そして、技術者の熱意(Enthusiasm)が組込みソフトウェアの品質向上に直結します。このことはソフトウェア開発プロセスを重視して品質を高めようとする西欧のソフトウェアプロジェクトにはうまく伝わらないかもしれません。 
しかし、私はこれからも次の三つのEにこだわっていきたいと思っています。
  • Experience(経験)
  • Education(教育)
  • Enthusiasm(熱中、熱意、情熱、こだわり)
これらの3Eを取り入れたこの本を見いだして韓国語に翻訳してくれた Cho JinJe さんには大変感謝しているとともに、この本をきっかけに韓国の読者が自分達の製品をより価値の高いものにしたいと考えてくれることを願っています。 
2013年2月
酒井由夫
なお、時を同じくして、日本の『リアルタイムOSから出発して組込みソフトエンジニアを極める』 の重版もこのほど決まりました。2006年に日経BP社から発売された『組込みソフトエンジニアを極める』が初版で絶版になってしまい、脱稿時の原稿から校正をやり直して新に『リアルタイムOSから出発して組込みソフトエンジニアを極める』として、本を生き返らせてくれたエスアイビー・アクセスの富澤 昇さんにも感謝しています。

出版不況の中、電子版にせよ紙の本にせよ書籍として完成されたものがないと知識はきちんと後生に伝わっていかないと思っています。そして、書籍として生き残っているからこそ、Cho さんのように知見を広げてくれる人が現れるのだと思います。

リアルタイムOSから出発して組込みソフトエンジニアを極める』の日本語版のの第2版は、Cho JinJe さんからの多くの指摘も反映させたものになっています。

韓国語版の『リアルタイムOSから出発して組込みソフトエンジニアを極める』が日本と韓国のソフトウェアエンジニアの架け橋になってくれれば幸いです。

2013-02-16

ジャーナリズムについて

仕事ともコミュニティ活動とも直接関係ないが、ジャーナリズムについて昔からずっと考えていた。

ジャーナリストになりたかったわけではないが、ジャーナリストは何となくあこがれていたところがあった。命をかけてまで報道しなければいけないこととは何なのだろうと漠然と考えていたし、報道の自由と民主主義が結びついていることは何となく分かってはいたけれども、報道の自由が当たり前となっている日本にいて、それを実感することはできなかった。

しかし、中国の大気汚染の問題を目の当たりにして、ジャーナリズムの重要性について実感が湧いてきた。あのスモッグの状態を見てこのままでいいとは誰も思っていないだろう。しかし、今の中国で公害を止めるためには政府(中国共産党)が規制を強くするしかない。個人の努力ではすぐに限界が来てしまう。(デモで国を動かせるか?)

粉じんの排出には利害関係が絡んでいるため、政府に頼っていると埒があかない可能性がある。排ガス規制を行うと利益が下がるので袖の下を渡して見逃してもらうなどという行為が横行しそうだ。

そういうときに力を発揮するのがジャーナリズムだ。報道の自由があれば、問題点を掘り下げて民衆に伝えることができる。報道によって気付きを得た民衆は行動を起こすことができる。そのベクトルが一つの方向に向かえばそれは大きな力となる。

公害をなくすためには、そのような民衆の力の結集が必要だろう。報道の自由を奪われた状況では目的が成就できるとは思えない。

北京で起きている公害は人の健康に関わる問題であることは外から見ていても分かる。何十万人という人の健康の悪化を止められるのはジャーナリズムではないかと思うし、逆に言えば、報道の自由がない状況、報道にバイアスがかかる世界では民衆の願いが叶えられないように思う。

日本におけるジャーナリズムとは

冒頭で、日本には報道の自由があると書いた。基本的にはそうかもしれないが、バイアスのかかっている情報とそうでない情報を見分ける力は弱いと感じている。個々の意見を持って情報に対峙するというより、来るものをそのまま受け入れてしまう無防備さが目立つ。

マスコミも情報の受信者の特性に共鳴していて、一つの報道に対して、各社とも同じ方向に情報を発信する傾向がある。

例えば、テレビ、ラジオ、雑誌、インターネット等の情報には大抵の場合スポンサーがいる。情報の購読者が売り上げの100%であれば、情報の発信者は購読者の利益を考えるが、公告主がいれば、公告主に不利益な情報は流さない。

雑誌の購読者が毎月金を払っていたとしても、日本の購読者はおとなしいので文句があっても黙っているから、公告主の意見の方がより強く扱われる。編集部は営業担当から「公告主がこう言っている」と言われるとなかなか逆らえない。

だから、マスコミ=ジャーナリズムではない。自分はテレビや雑誌の情報に触れるとき、裏(スポンサーの影響)があるのかないのかを想像するようにしている。

ところで、最近の民放のテレビ番組のコマーシャルには本当にうんざりしている。番組の中で一位を発表したり、ここぞというシーンの直前で番組が途切れ、CMが長々と入る。10年前はそんなにえげつない番組構成ではなかった。昔ではあり得なかったが、7時とか、8時にはすでに番組が始まっている。これは、時間ぴったりにチャンネルを合わせたときに別のチャンネルに変えられないように引き留めるためだろう。

テレビ番組の構成の変化を制作者側の視点でなぜ?と考えると、いろいろなことが見えてくる。番組が盛り上がる直前でCMを入れるのは、そうしないとCMを見てくれない、チャンネルを変えられてしまうからだろう。

リモコンで簡単にチャンネルを変えることができるので、ザッピングしながらテレビを見ている人は相当増えたと思う。番組のおもしろいところだけ見られてCMを見てもらえないと商品が売れない。一回30秒で何十万円も支払っているのに商品の売り上げにつながらなかったら、番組の制作費を出す意味がない。

それでなくても、広告費はインターネット公告にシフトしているのに、テレビや雑誌の広告効果が落ちてくるとスポンサーは減るし、スポンサーが出せる広告費も減ってくる。

だから、テレビ局はCMを見て貰うために必死なのだ。番組の構成を冷静に観察していると、その必死さ加減が伝わってくるので、ほとほとうんざりしてくる。コマーシャルの入らないNHKGやEテレでおもしろい番組があるとほっとする。ラジオもテレビほどCMが多くないのでよい。テレビのCMの多さが異常なのだ。制作費を多くのスポンサーで負担しないと成り立たなくなったのだろう。

テレビ朝日の「お試しかっ!」という番組をご存じだろうか。最近、この手の商品や商品を作る工程をレポートする番組や商品のランキング対決番組が増えている。なぜか。CMではなく、番組の中で商品を宣伝できるから、また、スポンサーにとっては非常に宣伝効果が高いからだ。

2013年01月28日放送の帰れま10「とんかつ新宿さぼてん」編の翌日、地元の駅前のさぼてんでは午前中だけで普段の1日分の売り上げがあった。(店の人の話)

番組がおもしろくてスポンサーの売り上げになるのならこれはWin & Win の関係になる。帰れま10の番組にさぼてんのCMは流れていなくても、制作費を負担しているのは間違いない。テレビ朝日はこの手の番組が受けているせいか視聴率も稼いでいて、おもしろおかしい番組で勝負してきたフジテレビは苦戦しているらしい。

ここで言いたかったのは、情報を得るときはその情報にはひもが付いていないかどうか考える必要があるということである。悪意があろうとなかろうとひもが見えているのといないのでは、情報の受け取り方を変えなければいけない。

Wikipedia は紐が付いていないので、たまに寄付のお願いが掲示されるが、よくお世話になっているのでわずかならがでも寄付に応じるようにしている。

ビジネス誌に金を払ってニュースを掲載して貰い、情報を受け取っているものが情報にくっついている紐に気づかず、あたかも自分が発見した客観的な情報のように吹聴するのを見ることもある。これは正確にはジャーナリズムではない。意図的に流された紐付きの情報を意図通りに横に流しているだけだ。

だから、紐付きの情報を流す人、紐付きであることを認識していながら情報を流す人はジャーナリストなのだろうかということを、ずっと考えている。ジャーナリストだって、生きていくためには稼がないといけないからスポンサーは必要なはずだ。だけと、万が一スポンサーに不利な情報を報道しなければいけない場面がきたら、ジャーナリストはどう行動するのだろうと思う。

ようするに自分の倫理観と、生きていくための報酬を天秤にかけなければいけない時がきたら、ジャーナリストはどっちを取るのだろうかということに興味があるのだ。

組織の中におけるジャーナリズムとは

このことはジャーナリストだけの問題ではない。サラリーマンなら誰にでもあり得る話だ。例えば、自分の会社が食品の原材料の偽装をしていることを知っていたとする。しかし、それによって会社の売り上げが上がっており、給料はその売り上げから出ている。その事実を告発するのか、しないのか、どうする。といった問題だ。

単純なコンプライアンスの問題だけではない。原材料の偽装だけでなく、健康被害にいたるような薬剤を使っていることを知った場合はどうするか。自分や自分の家族には「その商品は買うな」と注意を促し、商品の購入者の健康被害は気にしないといった行動を取るのか。自分の良心は痛まないのか。かつてある農家が農薬を使わない自宅用の野菜を育てているという話を聞いてことがある。

ジャーナリズムはそういう事実を明らかにすることが仕事であり、それがジャーナリストの社会に対する重要な役目なのだと思う。

転じて、組織の中で多かれ少なかれ、これと似たような状況は日々起こっている。自分の倫理観に照らし合わせたときに、言った方がいいのか言わない方がいいのか迷うようなときだ。組織の一員として黙っていた方が自分に有利に働くこともある。しかし、自分は、顧客満足という価値に照らし合わせたときにマイナスに働くと判断されるときは意見を言うことに躊躇はしないようにしている。それがこれまで述べてきたジャーナリズムの精神に通じると思っているからだ。

スモッグでかすんだ空気で呼吸をしながら、「大丈夫」などと言われても、そのまま黙っていてはいけない。

これは、建設的な批判(Constructive Criticism)でもないと思う。黙っていてはいけない時に利害や上下関係を超えて発言しなければいけない時があることなんだろうと考える。技術者倫理を教えるところ、場面もあるように思うが、それって教わるものかなと思う。エンジニアたるもの、一度は突き詰めて自分の考えを整理しておく必要があると思う。

第二のガラパゴス

このブログ記事の最後に、建設的な批判になればと思って書いておきたいことがある。これがジャーナリズムなのかどうかは分からない。

日本の製造業者は目先の価値で近々の競争に勝つことしか考えていないのでないかと思うことがある。家電製品は一年に一回か二回、モデルチェンジをする。

いかにも画期的な機能を追加したように宣伝している。これまで自分は10万円を超えるような家電を買うときに少しでも新しい機能の付いているものを選んでいたが、買い換えのサイクルが10年くらいであることに気がつき、考え方を変えるようにした。

掃除のしやすさメインテナンス性、耐久性、基本機能、基本性能を重視するようにした。そういう目でみると、商品を見るところが変わってきて、目先の付加価値にとらわれないようになる。

そして、企業のマーケティング担当が短期的な売り上げを上げるために、開発チームに何を要求してきたのかが見えてくる。簡単に言えば、新製品の一押しとしている機能がそれだ。

それが、冷静に考えてあってもなくても基本機能、基本性能に影響を及ぼさないのなら、それは目先の付加価値であるし、基本機能、基本性能の向上に寄与しているのなら、画期的なことであり、それは開発者の底力だ。毎年、パラダイムシフトが起こるはずもないので、大きなネタがないときは、目先の機能アップを大々的に宣伝するしかない。

底力で勝負している会社と目先の付加価値で勝負している会社は、不景気になるとその違いがはっきりしてくる。地道に基本性能の向上に努力している企業の売り上げは安定しており、目先の付加価値を追っかけている企業は負けが込んでくる。景気が悪くなると消費者は目先の目新しさを切り捨ているようになるからだ。それに気がつかず、基礎技術に明るくないマーケティングチームが商品開発を主導していると、足下をすくわれる。

同様に最近引っかかっているのが、プリクラッシュブレーキシステムのコマーシャルだ。トヨタ以外の自動車メーカーが一斉にプリクラッシュブレーキステムの宣伝を始めたように見える。(トヨタがやらないのは何か理由があるのだろう)

自分がもっとも気になっているのは「みんな一斉に」という点だ。ブレーキをアシストする機能の研究はどのメーカーも何年も前から研究はしていたのだろうから、カードを切る準備はできていたと思う。

でも、今になって一斉に宣伝し始めたのはなぜか。この状況の裏にある「ひも」はこうではないかと想像する。

スバルが最初に iSightで、大々的にプリクラッシュブレーキステムのCMを流した。自動車会社のマーケティング担当またはボードメンバーは、それを見て、これに乗り遅れると取り残される、株主から「なぜやらないのか」と攻められる。だから、「うちもやろう」ということになった。

CMを担当する広告代理店が iSight の公告を見て、「CMの最後に一瞬免責事項を出していますよ」「こちらも出しておいた方がよくないですか」と進言し、「そうだな。あっちもやっているのなら、こっちもやっておこうか」ということになった。

もし、こんなシナリオでトヨタを除く各社がCMを始めたたのなら、これは携帯電話に続く第二のガラパゴスじゃないのかと感じる。

あそこがやり出したから「それ追いつけ」という日本の企業特有の目先のマーケティング、目先の付加価値でしか勝負できない日本の会社の典型的なやり方ではないのか。

こんなことがまかり通っているのは日本人が世界一厳しい消費者になりきれていないからではないか。自動車メーカー以外がスポンサーになって、プリクラッシュブレーキシステムの各車種の評価実験をやらないのかと思う。事故が起きてからやるのだろうか。

アメリカでも同じようなCMを流しているのだろうか。ヨーロッパはどうなのか。日本でしかやっていないのなら、日本人は受け身だから、情報流しておけばブームになると思っているのではないか。一方的な情報に煽られているだけじゃないのか。自動車メーカーは本当に消費者のことを考えているのか。目先の付加価値を追求して基本性能に対するリスクを高めていないか。これこそ悪しき「メイドインジャパン的ガラパゴス」じゃないのか。

走る、曲がる、止まるといった車の基本性能は盤石なのか。底力は向上しているのか。プリクラッシュブレーキシステムは車の「止まる」の基本機能・基本性能の中でどのような位置づけなのか。

このことについて議論するジャーナリズムはないのか。自動車雑誌は公告主が自動車メーカーだから、正面から議論できないのか。

自動車産業という巨大な市場に何かしらの恩恵を得ている者は、誰もが何も言わないのか。

と、自分の中のジャーナリスト的心が叫んでいる。

※このブログにはスポンサーは付いていないので紐はないと思ってもらっていいのですが、疑いの目を持って読んでもらうことは重要だと思っています。

※底力の技術とはこういうことなんではないだろうか。『車体軽量化に向けた開発加速』こういう技術革新ってウケが悪いのかなと思う。そうだとしたら消費者の方の見る目が未熟なのだろう。

2013-02-10

NHKのドラマ「メイドインジャパン」を見て2

NHKドラマ「メイドインジャパン」(全3回)の最終回が放送された。最終的に瀕死の日本の大企業TAKUMIが技術盗用で訴えていた中国企業と一転、業務提携して窮地を脱するというところが意外だったが、やっぱり何か違和感を感じる。

その原因をいろいろ考えてみたが、それは過度な組織への忠信、執着ではないかと思った。唐沢寿明演ずる会社再建のリーダーと高橋克実演じるTAKUMIの元技術者が廃棄製品置き場で昔開発した機器を見つけてうれしそうに動かしてみるシーンがあった。

そりゃ、自分が携わった製品や自分の会社の製品がテレビに出ていたり、現実社会で使われているのを見るとうれしい気持ちになる。周りに家族がいれば、「あれがな」と講釈したくなる。でも、それははしゃぐようなものではなく、静かにかみしめるものだと思う。

ドラマの演出として過去の栄光を回顧しているこのシーンがとてつもなく古くさく、プロジェクトX的なサクセスストーリーを求めている視聴者へのサービスショットのような感じがした。

起業した直後ならまだしも、巨大化してしまった会社での製品開発ってそんな単純なものではないと思う。技術者の自らの強い意志のみで成功するイノベーティブな開発というのは100のトライのうちのいくつかだろう。

巨大企業は主力商品でそんな賭けはしない。きちんとマーケティングして消費者に受け入れられる機能や性能を分析するから、エンジニアの思いだけでもの作りが進んでいったりはしない。

それよりも何よりも、個人と組織の関係性が昭和の時代とまったく変わっていないように描かれていることが気になる。今時、家庭や個人よりも組織の方を優先して「会社が命」みたいな人がそんなに多くいるだろうか。

日本以外ではそういう人の比率は低いことは分かっていたが、日本だって例外ではなく、どんどん少なくなっているように思う。

個人と組織の関係は対等であると考える人が増えていると思う。組織から「会社のために死んでくれ」(個人を犠牲にしても組織に尽くしてくれという意味)と言われたら「No」というのが現代人の正しい判断だと思うし、そういう人情論で乗り切るという考え方がグローバルマーケットで日本の企業で負けが多くなってきた原因ではないだろうか。

組織は何か実態があるわけではない、信じたってその時々の状況で社員を裏切ることなどいくらでもあるだろう。社員からは裏切りと感じられても、組織からは正当な行為だと言われることだってある。リストラなどはその典型的な例だ。個人から見れば裏切りだし、組織から見れば組織の存続と後に残った社員の生きながらえさせるための正当な行為だ。

だから、組織に全面的に身をゆだねたりしてはダメなのだ。個人と組織は対等な関係であり、組織が個人を必要としないというのなら、さらっと「バイバイ」とドライに手を振れるようにしておかなければいけない。それは、組織の中にいて個人の独立性を高めることにもつながるから、結果として自立した社員が増えることになり、組織にとってもプラスに働く。

「メイドインジャパン」はそれに逆行し、昭和の時代に回帰することがよいというメッセージを発信しているように感じた。それが自分が感じる違和感の原因だ。

今朝、たまたまNHKで サキどり↑「日本発!ピカッと輝く新技術“LED照明通信”」という番組をやっていて、LED照明による光通信の最先端について紹介されていた。1秒間に数万回点滅するLEDを制御し光通信をする技術で、画期的な技術だと感じた。

そして、この技術を最先端で開発しているのは皆小さい会社だった。一つの技術を実用化するまで持っていくためには試行錯誤の期間が数年はかかる。そこには時間だけでなく、必ず成功させるという強い意志が必要だ。だから、小さい会社でないと続かない。

大企業はその巨体を支えるために、今年度、来年度の売り上げを確保するのに必死で、10年後のための投資、10年かかった花開く技術へのこだわりを持続できるとは思えない。

繰り返すが大きな企業ほど「メイドインジャパン」にこだわるのは間違っていると思う。そして、個人と組織の関係は対等であると考え、組織に依存しすぎなくても生きていける人間になることが重要だと思う。

そして、組織にどっぷりつかりたい人は起業するか、できるだけ小さい会社を目指した方がよいと思う。

2013-02-04

NHKのドラマ「メイドインジャパン」を見て

週末にNHKのテレビ60周年記念ドラマ「メイドインジャパン」の第一回、第二回を見た。第三回は次の土曜日に放送の予定だ。

【ドラマのあらすじ】
円高、欧州債務危機、中国・韓国等新興国の追い上げ。
製造業が軒並み危機を迎える中、巨大電機メーカーが、「余命三か月」の倒産の危機に追い込まれた!
会社の命運を握るのは、営業、財務、工場の現場で先頭に立ってきた3人の男。
かつて世界中でテレビを売りまくった営業マンが、会長の特命でリーダーとなり、
秘密裏に七人の「再建チーム」を結成。起死回生の倒産回避に奔走する。
 
だが彼らの前に、一人の日本人技術者が立ちはだかる。
男は営業マンの盟友だったが、会社をリストラされ壮絶な過去を経ていた。
今、男は己のリチウムイオン電池技術を武器に、自分を切り捨てた友へ宣戦布告する。
「技術は誰のものか」という争いの中、日中の巨大企業の激突が始まる・・・。
 
日本人にとって、会社とは、人とは何なのか?
「メイドインジャパン」は生き残ることができるのか?
―ドラマは戦後の日本を支えてきた物づくりの意義を問いつつ、逆境を乗り切ろうとする日本人の姿から、 「メイドインジャパン」とは何かを正面から見据え、描いていく。
あと一回残っているのでどういう展開になるかは分からないが、二回までを見て何か引っかかるところがある。それは今の時代に「メイドインジャパン」にこだわる必然性があるのかという点だ。今の時代に日本が「メイドインジャパン」の看板を掲げようとするのは、現代においてイギリスがかつての大英帝国の復活を叫んでいるようなものではないだろうか。ようするに「メイドインジャパン」のタイトルには過去の栄光にしがみつこうとしているようなイメージがある。

物語は、巨大企業において開発中止に追いやられた日本人の技術者が、その技術を中国の会社で製品化し、巨大企業がその技術を巡り、争い、倒れそうになっている巨大企業の経営を再建するという話で、あの会社のこと?と感じさせるほどリアリティがある。

余命三ヶ月の巨大電器メーカーの会長もよくよく見ると、あの会社の創業者に似ていないとも言えない。NHKもフィクションだと言いながら、誰もが「ああ、あそこね」と想像できるようなドラマにしていいのかなと思ったりする。

「メイドインジャパン」に対する違和感は、ドラマが“日本”にこだわっているところにある。ちょっと癖のあるそれぞれの分野のスペシャリスト7人が会長直轄の極秘の経営再建チームを構成し、会社のピンチに立ち向かっていく。ドラマのその流れ自体はよいとして、かつて栄えた巨大企業が「メイドインジャパン」を掲げて復活するというのは、あまりにも単純なシナリオでドラマを見ている読者にいろいろ考えるきっかけを与えていないような気がする。

※つまらないことだが、中国企業の社長やドイツの会社の役員と日本のメンバーが話をするときは英語にして訳をテロップで出した方がリアリティがあったのではないか。通訳を介して日本語で話しているところがイマイチだった。

言語の問題はあるにせよ、今はSNSを使うと海外の人、海外の技術者とすぐに友達になれる。もの作りもいろいろな国の技術、部品が使われている。そう考えると「メイドインジャパン」は最終製品を組み立てた国がたまたま日本だったということでしかないのではないか。税金を納めたのが日本だったというだけではないだろうか。

ドラマ「メイドインジャパン」では、日本的な経営手法と中国の新興企業の経営手法の違いも描いていたが、エンジニア個人としては経営の方法にはあまり興味は感じない。ただ、中国の新興企業の社長が製品の品質に無頓着であるように描かれていたのは「それは良くない」と思い、引っかかった。しかし、iPad や iPhone を台湾の鴻海グループが高品質で大量に生産できているから、日本人しか高品質なものは作れないというイメージはステレオタイプのような気がする。

だから「メイドインジャパン」じゃなくて、日本の良さ、例えば世界一厳しい目を持つ消費者がいるとか、きめ細やかな配慮が得意とかいったところが活かされる、日本にこだわらないグローバルな企業に発展するというストーリーにした方が良かったのではないかと思う。

ドラマもドイツの会社が融資してくれそうなことになっていたので、第三回でドイツの会社が経営に乗り出してくるのかもしれない。ただ、だからといって外人が来ると日本の会社の経営がうまくいかないというストーリーはあまり好きではない。そういう環境であっても、日本の良さを活かした製品作りが実現できて、世界の市場に受け入れられるというシナリオにして欲しい。

まあ、次の回でそういう展開になるかもしれないけど。

住んでいる国は簡単には変えられないけれど、世界中とコミュニケーションできる世の中になったので、「メイドインジャパン」と閉じこもろうとするのではなく、「視野を外に広げてもよい商品、世界に受け入れられる商品は作れるよ」といったメッセージを発信したほうが将来の日本のためにもなったのではないだろうか。今読んでいる「ワーク・シフト」の描く2025年の世界の様子がまさにそんな感じに思える。

ただ、巨大企業がいったん傷を負うと影響が大きいということは事実だと思うので、そこそこの大きさの組織でグローバルな人や組織間の関係を保ちながら、自分のスペシャリティを活かせるようになっておかないとまずいなと「メイドインジャパン」を見ながら思った。