ひさびさに読んだビジネス系の雑誌を眺めて思うこと

自分の著書「リコールを起こさないソフトウェアのつくり方」が BUSINESS LAW JOURNAL という雑誌で紹介された。

「リコールを起こさないソフトウェアのつくり方」の編集者から雑誌の見本が送られてきたのでこの雑誌を読んでみた。

技術系、ビジネス系の雑誌を読むのは何年ぶりだろうか。すぐには思い出せないくらい読んでいない。でも、きちんと編集され、文章、図、写真などが計画的に配置された成果物を久々に眺めて「なかなかいいもんだなあ」と思った。

WEBサイトを作ったりDTP(Desktop publishing)をしたりして痛感するのは、読者が見やすくなるような編集というのは高度な技術（というか感性かもしれないが）が必要であり、素人ではなかなかできないということだ。

そういった意味で本や、雑誌の編集者はプロフェッショナルでありながら裏方であり表に出てこない。技術を持っていても裏方で表に出ないという意味ではソフトウェアエンジニアも同じかもしれない。

しかし、彼らの仕事をした結果の成果物は多くの人の目に触れることになる。編集や構成の善し悪しは直接読者に評価される。ソフトウェアの方は製品の機能、性能、品質を通してユーザーに触れられ評価される。

ソフトウェアの方は商品の中に組み込まれ複製されることで効率的な生産が可能で有り、売れる商品のソフトウェアを作ればエンジニアにもフィードバックされる。

問題は雑誌の方だ。雑誌も売れれば同じように編集者やライターにも恩恵がまわってくるはずだが、インターネットの時代になってから何しろ売れない。情報はタダで手に入ると思っている人が多い。

雑誌ではなく書籍にするところまで頑張って仕上げれば、今回のように出版してから4年経っても取り上げてもらえることはあるが、雑誌のようにサイクルが短いと「インターネットに情報があるのでは？」と考えられてしまう。編集技術としては本よりも雑誌の方が高度だと思うのだが、今の時代はその編集技術が報われているようには見えず残念だ。

久々に雑誌をマジマジと見てみると、良く出来ているなあと思う。何種類ものフォントを使い、写真やイラストをふんだんに配置し、縦書き、横書きの割り付けをしている。これをDTPでやったら、本当に大変だ。だから、これはある程度の単価を設定して部数を掃かないと絶対元が取れない。

BUSINESS LAW JOURNAL は本体1900円で、税込み2052円。本一冊並の価格だ。企業の法務部門の部長クラスなら個人でも買うかもしれないなと思うし、会社で買って法務部門においてある姿が想像できる。法務部門を持つ会社なら星の数ほどあるだろうからターゲットとしては悪くない。

それに比べて、エンジニア個人をターゲットにしている技術系の雑誌はこの時代厳しいだろうと思う。実際、廃刊、休刊になった技術系の雑誌はたくさんある。

BUSINESS LAW JOURNAL を見ていて感じたのは、技術系の雑誌も例えばソフトウェアという切り口で攻めるのではなく、ドメインで攻めるのはどうだろうかということだ。

例えば、自動車のソフトウェアに特化するとか、医療系のソフトウェアに特化するとか。Domain Specific な専門知識は希少価値がある。BUSINESS LAW JOURNAL は法務担当以外の部門はほとんど関係ない情報の固まりに見えるが、法務担当なら「これ知らないのはモグリでしょ」くらいの内容にも思える。

ソフトウェアって平たく構えてしまうと、インターネットに転がっている情報と同等にされてしまうが、Domain Specific なソフトウェアの専門知識はお金を払ってでも手に入れたいと考える技術者はいるだろう。読者の総数は最盛期の一桁も二桁も減るかもしれないが、それなりの単価と固定客の確保はできるかもしれない。

自分の本業で医薬品医療機器等法（薬事法改正後の法律の略称）に関わってよく分かったが、日本の法規制はクリアしなければいけないのに素人にはとても難しい。

どうしても乗り越えなければいけないこと、ルール、規制、技術があって、それが難しいとなればそこに需要はある。特に法規制は商売をする上で知らなかったでは済まないので、重要性が高い。

例えば、医薬品医療機器等法で新たに追加されたソフトウェアの規制や再生医療の規制について、解説してくれる雑誌があったら自分なら定期購読したいと思う。

ところで BUSINESS LAW JOURNAL でなぜ「リコールを起こさないソフトウェアのつくり方」が紹介されたのかというと、特集記事の「法務のためのブックガイド2015」の一冊に選ばれたからだ。

この特集記事では5人の専門家がそれぞれの視点で本を紹介しており、激動の「プロジェクトマネジメント義務」と「著作権」を理解する の記事の中でメーカー系情報システム子会社の法務担当者の方がこの本を紹介してくれた。

記事の中ではIPA SECの「共通フレームワーク2013」とともに「リコールを起こさないソフトウェアのつくり方」が紹介されている。ソフトウェアベンダーのプロジェクトマネジメントの義務として果たされるべき開発プロセスとは何かを知るのに有効と評価していただいたようだ。

著者としてもこの本で伝えたかったことを紹介していただき感謝している。

【BUSINESS LAW JOURNAL 2015.2 [特集1] 法務のためのブックガイド2015 より一部引用 】

本書で特徴的なのは、海外のモデルや国際標準に倣った、あるべき姿を押しつけるのではなく、日本のソフトウェアエンジニアの特性を尊重した提案が見られることです。几帳面さや助け合いの気質で品質をカバーしてきた従来の日本のソフトウェア開発を全否定はせず、そこにソフトウェアの品質マネジメント技術をプラスして、より優れた開発プロセスの実現を提案する本書は、開発部門との対話を掘り下げる必要が生じた場合に、これからも繰り返し参照していく一冊になるのではないかと感じます。

【引用終わり】

なお、BUSINESS LAW JOURNAL を発行する会社 レクシスネクシス・ジャパン株式会社 のサイトを見ていたら、とてもおもしろい本のカタログを見つけたので一部を紹介したい。

自分もメーカーにクレームを言うことがあるが、対応する側の立場を考えたときにどういった教育しているのかと思うことがある。こういったノウハウがあるんだと思った。

クレーム対応の「超」基本エッセンス　―エキスパートが実践する鉄壁の5ヶ条―
株式会社エス・ピー・ネットワーク 著

＜第１部：基本編＞
【序章】危機管理的顧客対応指針5 ヶ条の趣旨〜顧客対応を取り巻く社会環境の変化を踏まえて
一、なぜ顧客対応、特に悪質クレーム、不当要求対応が難しく感じられてしまうのか

【第１章】危機管理的顧客対応指針5 ヶ条による不当要求対応の実践ノウハウ
1．顧客対応における初期対応の実際
2．初期対応の重要性と意義
3．初期対応における3 つの基本
4．お客様の「話」の4 つの要素
5．要求の内容を見極めるための5 つの基準
6．クレームと不当要求の2 分類
7．不当要求対応の極意

【第２章】代表的な不当要求への対応例
1. 「おまえじゃ話にならない、上司（社長、役員等の決裁権者）を出せ」と要求された場合の対応
2．初期対応において、相手から「今すぐ回答しろ」と急かされたが、対応方針について上司等に確認したい場合の対応
3．初期対応において、お客様から執拗に書面（詫び状や補償の約束）を要求されていて、書かないと帰らせてもらえないという場合の対応4．お客様の極めて主観的、好みの問題でクレームがついた（モンスター系クレーマー）場合の対応〜現代的クレーマーへの対応
5．いつも丁寧に対応しているのだが、「誠意を見せろ」と執拗に迫られ、困った場合の対応

【第３章】電子メールやインターネット上での顧客対応に関する留意点
1．電子メールでのクレーム対応やインターネット上での顧客対応
2．インターネットの特性を踏まえた顧客対応指針〜電子メールでの顧客対応を視野に

【第４章】顧客対応リスクの変化を踏まえた戦略的視点と危機管理的顧客対応指針
　　　　5 ヶ条の内部統制的意義
1．顧客対応リスクの「経営リスク化」
2． 経営的視点〜顧客対応にかかる内部統制システムの充実に資する危機管理的
顧客対応指針5 ヶ条

＜第２部：事例編＞
クレーム対応・実践ケーススタディ
［事例１］お客様から商品の異常を訴えられた担当者が「お客様の主観的な問題」と認識し、重大事故の兆候を見逃した案件
［事例２］外回り中に事故に遭遇した営業担当者の対応の不備から発生した案件
［事例３］お客様からの電子メールでの問合せに対してメールで回答したところ、内容がエスカレートした案件
［事例４］ストーカー的顧客が従業員の発言に難癖をつけて対応を迫ってきた案件
［事例５］犯罪組織の名前で担当者に精神的圧力をかけ、不当な要求をする典型的なゆすり案件
［事例６］顧客を名乗る人物が、子会社の不祥事を口実に、電話で会社の方針や見解について回答を求めてきた電凸案件
［事例７］ 勤務状況に問題がある従業員に会社側の方針に基づく指導を行ったところ、従業員の親が乗り込んできた案件

タカタとホンダのリコール問題について考える

【タカタのエアバッグの問題に思うこと】

タカタのエアバッグの問題が話題になっている。ロイターの記事『特別リポート：タカタ欠陥エアバッグ、尾を引く「メキシコの誤算」』を読むと大量の不良品が出回ってしまったのはメキシコでの生産工程の問題が原因だったらしい。

タカタは、2000年頃エアバッグの基幹部品であるインフレーター（ガス発生装置）のコストダウンのため、インフレ―ター生産を米国の2つの工場からメキシコへ移管させた。その結果、インフレ―ター生産の1個当たりの労働コストは2ドルから約75セントに低下。2006年までの5年間に、同社は7000万ドルの労働コストを削減した。タカタの顧客である完成車メーカーにとっても、インフレータ―の購入コストが1個当たり20ドル未満と20%以上も引き下げとなり、大きな恩恵が及んだ。

しかし、記事によると生産現場の環境はさまざまな問題があったようで、結果的にこの工場移転がトリガーとなって不良品が市場に出てしまったようだ。

1980年代に起きた放射線治療器 Therac-25 の事故も、コストダウンによるハードウェアの安全装置を外したことが原因の一つだった。

安全性を左右する重要な機能に対するコストダウンのアプローチは時に重大な問題を起こす。

このような事件が起きると『USとJapanの文化の違い』の記事を思い出す。

左の図が意味するところは、アメリカ人はルールと責任はしっかりしており、システムやツールを構築することには長けているが、品質を心配する意識が小さい。一方、日本人は、品質を心配する意識はとても大きいが、ルールや責任を重要視する姿勢は小さく、システムやツールの構築もアメリカほどは進んでいないということだ。

改めてこの図の品質を心配する意識の強さはサラリーの高さには比例しないように思える。（新渡戸稲造の「武士道」的発想。現代の日本でも通用するか？）

一方で、ルールや責任を重視しプロセスで品質を担保するアプローチの成功の是非はサラリーの高さにも関係するように思える。

ようするに、プロセスアプローチで品質を担保しようとして、同時にコストダウンを断行するともともと品質を心配する意識が低い地域ではルールや責任による品質確保が崩壊するのではないかという仮説だ。

安全の実現には3Eが必要と言われている。3Eとは、1. Experience（経験）、2. Education（教育）、3. Enthusiasm（熱中、熱意、情熱、こだわり）だ。1と2は金と時間をかければなんとかなりそうだが、3はシステムやプロセスで解決しない。

Enthusiasm（熱中、熱意、情熱、こだわり）が十分でない組織でも一定の品質を確保するためにシステムやプロセスで押さえ込むのだ。でも、押さえ込まなくても従業員全体にEnthusiasm（熱中、熱意、情熱、こだわり）がある環境（工場）であれば、品質を確保することができるのではないだろうか。（QCサークルもEnthusiasmがなければうまくいかないだろう）

ガチガチのプロセスアプローチを取らなくても、みんなが品質を心配する意識を持っている組織（工場）で、品質を心配する意識に働きかけながらもの作りをすれば、トータルコストは安くなるのではないだろうか。

労働力の安さだけに着目する経営者はこの考え方ができず、選択ミスを犯す危険を抱えていると思う。安全はプロセスアプローチだけでは実現できないということが自分の持論だ。ただ、それを説明するには、日本人の国民性のような測れないものが要因になっていることを理解してもらう必要があるので簡単ではない。

【ハードの問題をソフトでカバーするリコール】

『ホンダのリコールを考えるメカとエレキの間で起きる不具合』（記事を読むには無料の会員登録が必要）という記事が2014年11月4日の日経ビジネスOnlineに掲載された。ホンダの「フィット ハイブリッド」の5回目のリコールの原因を分析する記事だ。

かつて、このブログで書いた『ホンダフィット自動変速機の制御プログラムの不具合について考える』も日経さんの記事をネタにしたものなので関連がある。

今回の『ホンダのリコールを考えるメカとエレキの間で起きる不具合』の記事では、ハイブリッドシステムの複雑な自動変速機のメカニズムを分かりやすく解説している。

一通り読んで思ったのは、ホンダはリコールでソフトウェアを変更したが、これはもともとソフトウェアに不具合があったわけではなく、前のリコールで改善したハブとスリーブの噛み合わせで、まだうまく噛み合わないケースが発生する可能性があるから、さらにプログラムを書き換え、よりスムーズにスリーブとハブが噛み合うように改善したということだ。

ようするにハードウェアの不具合をハードを交換するのは簡単ではないので、ソフトウェアの改変でカバーしたということだ。

結果としてソフトウェアを書き換える作業となるため、ソフトウェアに不具合があったように見えがちだが、実はハードウェアの問題をソフトウェアでカバーしたリコールは現実には結構存在する。

2010年に発生したソフトウェアの改変を伴う医療機器の世界のリコールのうち14%がハードウェアの不具合をソフトウェアでカバーしたものだったという研究がある。

ソフトウェアの変更容易性は時に問題も起こすが、時にハードのピンチを助けることにも使われるのだ。

『ホンダのリコールを考えるメカとエレキの間で起きる不具合』の記事を読んで改めて思ったのは、ハイブリッドシステムの自動車のメカニズムは昔の車とは比べものにならないほと複雑になっているということで、その複雑なメカ制御にソフトウェアも噛んでおり、安全との関係性が強くなっているということだ。

「昔の車と大して変わっていない」という外見のイメージとは裏腹に、ハイブリッドシステムは単純な構造ではない。それは自動変速機もしかり、ブレーキシステムもしかり。

我々現代のエンジニアはこの複雑性に向き合っていかなければ、安全なシステムを実現することはできないと確信する。単純に物事を解決しようと誘導する者がいてもその話に乗ってはいけない。

システムはすでに相当複雑になっている。その複雑性と向き合いながら、安全を確保するためには、複雑性の中に問題は存在するものだと考えて、そのような問題があってもシステムのリスクを受容できるレベルまで低減させるためには何をすればよいかと考える必要がある。

複雑性はソフトウェアだけに閉じるものでもなく、メカやエレキも含めて考えなければいけない。安全を確保するためには、メカ、エレキ、ソフトのすべてに精通している安全アーキテクトが今後必要になってくると思う。

安全性と信頼性

SEC journal 38号で安全学で著名な明治大学 名誉教授の向殿 政男先生が「信頼性と安全性」の記事を書いている。無償でPDFにて読めるので是非読んでいただきたい。

【まえがき より引用】

・・・とくに、個々の構成部品の信頼性を追求して行くだけで、私たちの安全な生活は保証できるのであろうかという疑問が湧く。主として信頼性はハードなどの施設・設備の問題であるが、安全性は私たちの身体的な傷害や精神的な障害の問題である。最終目的は安全性のはずであるが、信頼性だけを追求して、安全性が実現できると考えるのは素朴すぎるのではないだろうか。本来、信頼性と安全性は異なった概念と技術であるからである。システムが大型になって全体を把握するのが困難になると共に、いったん事故が発生すると取り返しがつかないような場合には、安全性のほうを重視して追求する観点が不可欠なはずである。とくに、ソフトウェアを含んだコンピュータがシステムの制御や監視に組み込まれる場合には、信頼性だけを追求する傾向があるので、上記の観点は必須なはずである。

【引用終わり】※この後もかなりの部分記事を引用しています。

向殿先生は「信頼性だけを追求して、安全性が実現できると考えるのは素朴すぎるのではないだろうか」と柔らかい表現で書いているが、「信頼性だけを追求して、安全性が実現できると考えるのは間違っている」と自分は言い直したい。

本文の中で、工学システムにおいて信頼性とは、「与えられた機能を果たし続けること」であり、安全性とは、「人に危害を及ぼさないこと」とされている。信頼性が高ければ高いほど、安全性は保たれている可能性が高いと考えられるので、安全性の問題は信頼性の問題に帰着できるという人もいるとあり、その後、これは正しくないことが列車の例で示されている。

安全性が確認できない場合、列車を止める。列車は走るという本来の機能は果たしていないので信頼性は低くなるが、人が事故に遭うことがないという点から安全性は確保されている。信頼性を下げることで安全性が確保される例である。

安全性と信頼性の関係で最も大事なことの一つに、安全を保つという機能が果たされている信頼度、すなわち、安全性に対する信頼性という考え方はある得る。その機能が果たせなくなったら、安全性が損なわれ、人に危害を及ぶことになる。しかし、信頼性は、機能が果たされなくなった後のことを考慮していない。いくら信頼性が高くても、いつかは壊れることになる。安全性はそこも含めて考えている。よって、信頼性と安全性はお互い強い関係はあるが、異なった概念であることは明かである。

信頼性(Reliability)はJISでは「アイテムが与えられた条件で既定の期間中、要求された機能を果たすことができる性質」、及び、その定量的な尺度である信頼度(Reliability)は、同様に「アイテムが与えられた期間与えられた条件下で機能を発揮できる確率」と定義されている。近年、前者の信頼性（Reliability）を表すのに Dependability という言葉が使われるようになってきた。Dependability には信頼性だけでなく、保全性(Maintainability)と可用性(Abailability)の概念が含まれている。

一方で、安全性の定義はJISでは「人への危害または損傷の危険性が、許容可能な水準に抑えられている状態」である。安全規格を作成するための国際的なガイドラインである ISO/IEC ガイド51では「許容可能でないリスクが存在しないこと(freedom from risk which is not tolerable)」と安全性を定義している。

安全においては、リスクゼロ（絶対安全）の存在はあり得ないとして最初から放棄している。どの程度のリスクならば安全といえるかは、時代により、社会により、与えられた条件（使用者、寿命、温度・湿度・環境など）により、異なるとしている。

リスクは危害の発生確率と危害のひどさの組合せなので、安全性を高めるためには、危害の発生確率を低くするか、危害が発生したときにそのひどさ（例えば、怪我の程度）を小さくするか、またはその両方で実現できることとなる。リスクを構成している二つの要因のうち、前者が主として確率に基づく安全性に関連し、後者が主として構造に基づく安全性に関連している。安全性は危害が発生しないように信頼性高く作る技術と、危害が発生したときにひどさを下げる技術の両方で実現される。主として、前者が信頼性技術に、後者が通常言われる安全性技術に関連する。

システムには通常、果たすべき二つの機能があり、一つがシステムが本来果たすべき本来機能であり、もう一つが安全を確保する安全機能である。安全機能には、システム本体が実現している安全機能と、安全防護策や安全装置などの付加的に追加された安全機能とがある。この二つの安全機能は、それぞれ、本質的安全及び機能安全と呼ばれる。後者の機能安全とは、簡単に言えば、本来の機能を果たしているシステムを安全に制御する装置や導入された安全装置等が果たす安全機能のことである。この場合には、その装置が正しく動いていること、すなわちその信頼度が重要となる。その機能を失ったとき、直ちに安全性の問題が生ずることになる。

【ISO 26262との向き合い方 (27) 最終回：何に向き合いますか？】で書いたように、機能安全規格であるISO 26262 はどうも自動車業界の産業構造が意識されていて、システム全体の安全性を高めるにはどうしたらよいかという考え方が欠落しがちであるように思う。

その理由は向殿先生が解説されているように、機能安全が本来機能や本質安全と切り離された概念であり、自動車業界では分離された安全機能の信頼性を高めることに主眼が置かれているからではないだろうか。

そうなってしまうのは、自動車は分業されたサプライヤの存在が前提となっており、サプライヤから供給された部品をくみ上げて完成させるという業態であるため、個々のサプライヤが納品する部品の信頼性を高めること、すなわち機能安全の追求が目的になっているのではないか。

自分が常々自動車業界の機能安全の取り組みに首をかしげたくなるのは、そういった背景があるからではないかと向殿先生の記事を読みながら思った。

システムが複雑化し、複数のサブシステムが協調して本来機能や安全機能を実現するようになると、自動車システムの安全は個々のサプライヤだけでは満たせなくなってくる。別な言い方をすればリスクを受容するためにシステム全体の安全アーキテクチャを設計し、維持することが必要で、OEMとサプライヤを切り離すことなく協力体制を作って3Eを共有する必要がある。

1. Experience（経験）
2. Education（教育）
3. Enthusiasm（熱中、熱意、情熱、こだわり）

父の元部下の方からの手紙

父の死後約、一ヶ月が経ち、いろいろな方から香典やお悔やみの手紙をいただいた。その中でかつて父の部下だった方から手紙が来た。

母に宛てた手紙であったが、認知症の傾向があるため、自分が手紙類を整理している。

この方は父が自分の死後に知らせるよう書き残した約20名のリストには載っていなかった方で、父が永年勤めていた建設会社の知人の方から訃報を聞いたらしい。

昭和45年頃(1970年）の思い出が書かれていたので、44年前に所長（父）と所員という関係だったようだ。

若かった頃、優しく指導し、トラブル解決の為に活躍し、楽しく営業所時代を過ごすことができたとある。父が営業所時代にたくさんの実績を上げることができたのは、柔和な笑顔、温和な話し方、豊富な知識によるもので尊敬していたとあった。

わざわざ、知人の方から住所を調べて、母の名前が分からず父の名前で送られてきた。（お詫びが添えてあった）

その他、いろいろな思い出が書かれており、心に響いた。

そして自問している。自分はこれまで人を育ててきただろうかと。40年も経ってかつての上司であった父との思い出を伝えてきてくれる方がいる。自分にはそんな人がいるだろうかと考える。

建築業界とは世界が違うので単純には比較はできないが、25年以上も同じ会社に勤めていて人を育てることが出来ていたかどうか考えてしまう。

組織内外で技術者教育に携わってきた実績はあるものの、一人の方にこんな深い感謝のことばをいただけるような関わり方をしてきただろうかと。

父のこのような仕事ぶりについて、自分が若い頃はまったく想像もできていなかった。子供に仕事の話など一切しないからだ。晩年になって、自分が家を建てた時のトラブル時などでその片鱗を垣間見ることができ、頼もしいと思ったことはある。

ただ、会社の方が見ていた父の姿と、家族が見る父の姿は同じではなかったと思うし、また、自分自身も同様に子供達からは、家では料理をするとき以外はごろごろしているおじさんににか見えていないだろう。社会の中で働いている父の姿を子供に見せることは重要かもしれない。

結局、自分は人を育てるという意味では広く浅くしか出来ていなかったような気がする。一つ言い訳をするとすれば、まだまだ、自分自身が学ばなければならないことがあると思ってるので、人に教える時間より自分が学ぶ時間の方が大事だと考えていたのだ。

でも、頭の方の瞬発力がピークを過ぎたと思うようになり、後身の育成に重きを置く必要を感じてきた。その際に重要なのが、「育つのを待つ」という感覚だ。頭では分かっているのに待てない。自分でやってしまった方が早いと考えてしまう。

問題を早期に解決することがすべてならば、それでもいいのだが、今は人を育てるフェーズであることを意識しないといけない。自分ができることを、教える相手が出来ないからといってイライラしてはいけないのだ。

実際、それができないから、深い師弟関係が生まれないのだと自己分析している。柔和で温和な感じの父がシニア向けの携帯電話がうまく使えずイライラすることがあった。それだからダメなのだ。

父の元部下だった方の手紙は、自分が大事に取っておこうと思った。いつの日か、こんな風に思ってくれる技術者を育てたい。そのためには寛大な（Generous）心を持てるようにならないといけない。

そして、いつの日か、自分が死に絶えるときが来たら、このブログが役に立った人にコメントをもらえれば本望だ。

自分が生きている間に遺せること

平成26年8月27日に父が亡くなった。86歳だった。体はかなり弱っていたものの、お盆休みに会いに行ったときはちゃんと話もできていた。腸閉塞の疑いで、8月26日に病院に緊急入院してから翌日の夜中に亡くなるまで期間が短かったので家族にとっては急なことだった。

父が亡くなった日の27日は朝から病院に行き、主治医の先生に状況を聞いた後、いつ容体が変わるか分からないのでその日は病室に泊まり込むつもりでずっと父に付き添っていた。

そして何かの運命だと思ったのは、その病院で使われていた生体情報モニタが自分の会社の製品だったということだ。父のバイタルサインを計測していた機器は自分が開発に携わった製品の後継機種だった。プロジェクトチームの面々とは顔見知りで今でも支援する立場にある。

そして、そのベッドサイドモニタからナースセンタのセントラルモニタに生体情報を送信する送信機は自分がかつて担当した製品だった。

父は意識はあるもののちゃんと会話ができる状態ではなかったので、面会に来た高齢の母が帰った後ずっとモニタの画面を眺めていた。

計測しているバイタルサインは心電図とSpO2（動脈血酸素飽和度）と呼吸（インピーダンス方式）と非観血血圧だった。SpO2はヘモグロビンが酸素をどれだけ運んでいるかを見る指標で、指で計ることが多いのだが、父の場合は耳たぶにセンサが付けられていた。指につけておくと外そうとしたのかもしれない。末梢の血液循環が悪くなってくるとSpO2の正確な計測が難しくなってくる。酸化ヘモグロビンの光の吸収量が異なる赤色光と赤外光を透過させてそれらの波形から酸素飽和度を測るため、末梢血管の脈動が小さいと正確な計測が出にくい。健常人なら95%くらいの値であるSpO2値が、酸素吸入していても父の値は90%を切っており、信号が小さいため感度が最大でノイズが多く波形がフラフラしていた。

血圧は30分に一回、上腕に巻かれたカフに圧力がかかり測定を繰り返す。腕も細くなっているし、体動もあるのであまり安定はしていなかった。

もっとも安定していたのは心電図だった。心電図は体表に貼った電極から微弱な電位の変化を計測する。生体情報モニタのパラメータとしては最も歴史が古く、体動にも強く、安定して測定するための技術も成熟している。

死期が近づいてくると心電図に不整脈が現れるようになり、重篤な不整脈を検知したことを表すアラームが鳴る。ちなみに、重症な患者の場合、設定したバイタルサイン計測値の上下限を超えることが頻繁にあるのでアラームはほぼ鳴りっぱなしの状態である。重篤かどうかはアラームインジケータの色で分かる。

父の場合も盛んにもぞもぞと動いていた時期を過ぎ、夕方になって静かになったなと思ってから、数時間後に不整脈が現れ始め、それまで安定的に拍動を打っていた心電図が徐々に乱れ始めてきた。自分も夜勤の看護師さんも状況は把握できており、そのまま息を引き取るまで見守っていた。

老いて死ぬのは自然の摂理だからなのだろうか、なぜだか冷静に状況を見ることができている自分がいた。

こんなプライベートなことをこのブログに書き残したのは、残しておかなければいつの日か自分の記憶が薄れて無くなってしまうかもしれないと思ったのと、記憶あるうちに残しておかなければ自分の子供達がいつの日か父が自分の父親が死ぬときに何を感じたのか知りたいと思うかもしれないと感じたからだ。

父は、数年前に約20名ほどの親しい友人のリストを作りもしもの時にと自分に託していた。そのときはまだピンピンしていたので話半分で聞き流していたが、本当のそのリストを使う時がきて、葬儀は近親者だけで済ませてくれというメモを見て、伝えるべきことを残してくことの大切さを感じた。

父は、満州で自分の父親と兄弟の何人が戦死して遺体が収容できず、きちんと葬式をあげることができなかったので、自分の時も葬儀は身内だけにして、親しい方には後から自分の死を知らせて欲しいと書き残していた。

そして、葬儀が済んだ後で20名の方達にそれまでの経過を記したはがきを出した。すると、満州時代からの父の友人で三十年あまり同窓会の幹事をされていた方から、父との思い出が書かれた便せん三枚の直筆の手紙がはがきの差出人である自分宛に送られてきた。その手紙をいただいた時には、後に残された者としてきちんと返信をしなければいけないと思った。残された者が果たさなければいけないことはいろいろある。

父の死後のいろいろな手続きや返礼などまだまだやることはあるのだが、今自分のこととして振り返ってみると自分も一生の中で社会や家族に何を残せるかを考える必要があるように思えてきた。

ある人と自分の仕事の行き詰まりについて飲みながら話をしていたときに、自分の本業とは別の部分での価値の創出や社会の貢献についても自分の中で評価してもいい、評価した方がいいという話をした。サラリーを稼ぐための仕事だけがすべてではないだろうという話だ。

会社では生きるために金を稼いでいるかもしれないが、会社の仕事は別に社会貢献したときも目に見えない価値が生みだれており、それも自分の中で積み重なっていくのではないかということだ。

評価されるために活動している訳ではないが、自分自身のモチベーションを維持するために創造した見えない価値を作り出したことを誇りたい気持ちはあるし、また、それが見えるようになれば自分にとってハッピィでもある。

自分はたまたま医療への貢献に結び付く仕事をしている。しかし、もちろんそこに直結しないさまざまなタスクも抱えている。そういった仕事と、組織から工業会のために行う仕事と、コミュニティでの活動などさまざまなことについて限られた自分の時間を使っている。

今現在の最大の悩みは人生の折り返し地点を通過し限られた自分の時間を何にどれだけ使うべきかということだ。残された時間は伝えたいことを残し伝えるために使うべきではないかと思っている。

平成26年8月1日に創設されたヘルスソフトウェア推進協議会のセミナーでは、ヘルスソフトウェア開発に新規参入を考えている組織に向けて、この一枚のスライドを使ってガイドライン適合のコンセプトを説明している。

ガイドラインに適合することが目的なのではなく、優良なヘルスソフトウェアをそれを必要とする個人や医療機関に提供し、社会に貢献することでヘルスソフトウェア開発プロジェクトのモチベーションにつなげて欲しいと。

それは理想論であり、現実はもっと厳しいという人もいるかもしれないが、優秀な職人としてプライドを持つソフトウェアエンジニアなら自分が作ったソフトウェアが使われている現場を見て、そのソフトウェアが社会に貢献していることを実感することができれば、明日へのモチベーションにつながるだろうし、同時に社会への責任も感じるはずだ。

いい加減なソフトウェアを開発していたら、エンドユーザーから感謝されることはない。いい仕事をしていれば、必ずその苦労は報われる時がくる。どこかで妥協してしまえば、プロの仕事にはならないのは、どの世界でも同じだろう。自分がこのブログで伝えたいことの本質はここにあると思っている。

この歳になって理想論じゃ済まないことも世の中にはたくさんあることも分かっていた。ただ、自分が進むべき道の方向に迷いが生じたとき、家族や組織や社会と自分の関わりについて考え、どこにどれだけ貢献してきたのか、またこれからどう貢献していけばいいのか、よくよく考えて何からしら答えを出していく必要がある。

父の死はそれを考えるきっかけにもなった。

自分が若かった時、特に20代まで、父と腹を割って話をしたことは無かったと思う。自分が父親になり、子供を育てることの大変さが分かり、相談したいことが増えてきて「精神的な頼りにしているから」と伝えていたここ数年だった。

何もしなくても時は刻まれるのなら、残された時間で何が遺せるのかをこのブログでも考えてみたい。

誰のため、何のために仕事している？

時事通信のサイトに、ドイツのダイムラーが社員が休暇中に届くメールを自動削除するシステムを導入したというニュースが載っていた。

社員10万人が希望に応じて利用でき、送り手には「休暇中でメールが受け取れない」という説明と、緊急要件に対応する別の担当者の連絡先を知らせることができるそうだ。

この話を聞いて、この夏、自分が気にしないからと思って、夏休み中にいろいろな方にメールを送って失礼なことをしたなと反省すると同時に、日本人は働き過ぎじゃないかと改めて思った。

思い起こせば、十数年前、家を建てるときに担当のハウスメーカーの営業の方の携帯電話に夜中だろうが気にせず電話して、いろいろな問題に対処してもらった。その方とは、個人的に長いつきあいをさせていただいているが、今から思えばあちらの家族に迷惑を掛けたと思う。

日本では、無理な注文を聞いてくれればくれるほど、顧客との信頼が増すといった慣習が色濃く残っているような気がする。それが、仕事にオンの時間ならいいと思うけれど、オフの時間にも対応してあげるのは、どうなんだろうと考えてしまう。

相手が仕事上の顧客なのか、それとも個人的な友人なのかによっても、その判断はかわると思うが、どちらとも言えないようなときが一番の悩みどころだ。前述のハウスメーカーの営業の方は、最初のつきあいは完全に仕事だったから、ずうずうしかったかなと思う。ちなみに、その人はやり手の営業マンで、当初家を買う気もないのに、あちらの会社持ちで地盤調査をしてしまうような強引さもあった。そんなこともあって、契約にいたり、いろいろ無理も利いてもらっていた。

「あの人のために何とかしてあげたい」と思うこともある。そういうときは、公私を忘れてなんとかしようと思うこともあるが、相手が一人じゃなかったり、それをやることで家族の時間が犠牲になってもいいのかという時もある。

仕事とプライベートに明確な線を引いていない自分としては、そのような悩みが常につきまとう。実際公私に関係なく、没頭してしまうとそのことが頭から離れなくなり、集中力が高まる一方で他のことができなくなるという問題もある。

それともう一つ、日本では優秀なエンジニアが仕事のパフォーマンスを上げれば上げるほど、そこに新たな仕事が降り注いでくるという傾向がある。ソフトウェアは見えないだけに、再利用性の高いアーキテクチャを構築したアーキテクトは現場レベルでは一目を置かれるが、組織としてその功績を目に見えるようにするのはとても難しい。

だから、場合によっては、作っちゃ直し作っちゃ直しを繰り返していつも忙しくしている方が表面的には頑張っているように見えたりする。

ソフトウェアの開発効率を高めて左うちわになるような功績を達成しても、それを評価できる組織はそう多くはなく、逆に楽になったぶん仕事を上積みされる。

そうなるとエンジニアはなんだか貧乏くじを引いた気分になる。誰の為に何のために技術を磨いているのは分からなくなることもある。

そういう話をすると、今の世の中独立して会社を興せばいいじゃないかと言われることもあるが、製造業（組込みソフト）の世界で生きていきたいのならば、そう簡単な話ではない。

製造業は生産設備が必要だし、さまざまな役割分担をしないとものつくりができない。形あるもの作りが好きな者としては、分業された組織が必要なのだ。

最初のダイムラーの話に戻ると、組織は社員に対して「この会社のために何とかしよう」と思わせる努力が必要なのではないか。

冒頭の話が「休みの間くらいゆっくり休んでリフレッシュしてくれ」ということなら、社員は「この会社のために何とかしよう」と思うかもしれない。

別に休暇だけがその方法ではない。何かしらのインセンティブや組織と社員の価値観の共有の努力かもしれない。

それがない状態で、成果だけを求められても、「この会社のために何とかしよう」という気持ちにはなかなかなれない。

ちなみに、こういった主張をこのブログでずっとしてきたのだけれど、ブロガーとして問題を分析するだけでなく、自分自身が組織の側に立ってエンジニアに「この会社のために何とかしよう」と思ってもらう立場に変わりつつある。

それは今までやってこなかったことだけに大きな悩みの一つになっている。エンジニアとして技術を追求するだけではすまなくなってきただけに、日々のいろいろな活動に対してモチベーションを維持するのが難しい。

歳を重ねるとエンジニアリングだけ考えていればよいという立場ではなくなってくるのがイヤだ。

P.S.

8月15日は終戦記念日だった。そこでラジオで紹介されていた『戦争の教室』という本を買って、読んでいる。この本は、1901年生まれから1990年生まれまで、各世代80名が戦争や平和について語った文章を集めたものだ。500ページとページ数は多いものの、それぞれが短く完結しているので、好きな年代から気まぐれに読んでもおもしろい。

みんながみんな戦争に向き合って堅い話を書いている訳ではない。元暴走族のリーダーだった中野ジローさんの話などは戦争とはまったく関係ないが、自分の親が自分に向けていたまなざしと、自分や奥さんが自分の子供に向けているまなざしの共通点が、平和を希求する気持ちとオーバーラップしているように思える。

また、もうすぐ結婚するという山﨑曜子さんという20代の女性が、婚約者の祖母に戦争体験を聞きに行く話は、現代の若者が素直に感じたこととしていい文章だと思ったし、教科書的でないところがすごくよかった。

衝突回避システムの試乗会事故で関係者が書類送検された

衝突回避システムの体験試乗会中に2人が重軽傷を負った事件で、関係者が業務上過失傷害容疑で書類送検された。


【「衝突回避」試乗会中事故＞マツダ系店長ら書類送検　毎日新聞 7月11日(金)」より引用】

◇埼玉県警、業務上過失傷害容疑で

　昨年１１月に埼玉県深谷市で開かれたマツダ車の「衝突回避システム（自動ブレーキ）」体験試乗会中に、２人が重軽傷を負った事故で、埼玉県警は１１日、主催した同市内にある「坂田自動車工業」の男性役員（３７）やマツダ系販売店「オートザム深谷」の男性店長（３４）ら３人を業務上過失傷害容疑で、試乗運転していた男性会社員（４０）＝同県本庄市＝を自動車運転過失傷害容疑で、さいたま地検に書類送検した。４人とも容疑を認めている。

　店長ら３人の送検容疑は、昨年１１月１０日の試乗会で７メートル先につり下げたウレタンマットに向かってスポーツタイプ多目的車「ＣＸ－５」を走らせることで同システムを体験させる際に、アクセルを踏み込むとシステムが正常作動しないなどの注意点を伝えず、事故を防止する注意義務を怠ったとしている。運転男性は操作方法を確認せずに車を急発進させ、時速３０キロを超える速度で暴走させた疑いがあるとしている。

　事故車はマットにぶつかり、さらに前方のフェンスに衝突。運転男性と助手席の販売店従業員が重軽傷を負った。

【引用終わり】

結局は、時速30km/h 以上では衝突回避システムが動作しないことを説明されなかった血気盛んな運転手がアクセルを踏み、ウレタンマットを吹き飛ばし、フェンスに衝突したというのがことの成り行きだった。

試乗会でユーザーにこのことを説明せずに車を突っ込ませた関係者も悪いことになっているが、市販車で自動ブレーキが当然効くものと思っていたユーザーが同じような状況で自動ブレーキが効かずに事故が起こった場合の責任は誰にあるだろうか。

事故で誰かを傷つけてしまった場合の責任や賠償は運転手だけが負うのだろうか。上記の書類送検の事例を考えれば、衝突回避システムについて十分に説明をしなかった者にも過失責任が発生するように思える。

衝突回避システムを搭載している自動車を売るときに販売店は説明して納得したことについてサインをもらっているだろうか。

最近、携帯電話やスマホを契約する際に、説明に納得して理解したことについてサインを求められる。たいして注意深く聞いてもいないのにサインだけしてしまうことが多いが、あれは裁判を起こされたときにキャリアや販売店側が自分の身を守るための次善の策だ。

いまどき、家電だって取扱説明書の最初の方に「警告」表示をたくさん書いている。そこに書いていることを守らないて事故が起きたときは、よっぽどのことがなければメーカー側が裁判で勝つ。

自動車の場合、メーカーは取扱説明書があっても読まれないことを前提としているということを聞いたことがある。説明書を読まなければ運転できないようではダメだというのだ。

これまでの「走る」「曲がる」「止まる」の基本機能だけですべてが成り立っていたときはそれでもよかっただろう。しかし、今では自動車の利用者が知っていないと危険に遭遇する仕様が増えている。衝突回避システムのその一つだ。使い方を誤れば人を傷つける危険性がある。

メーカーや販売店はそのことを事前にユーザーに伝える義務がある。医療機器の場合、EUで取扱説明書に注意喚起をすることだけでリスクを受容できると考えることを許さないという基準が出来て論議を呼んでいる。

このような基準が出来た背景は、何でもかんでも禁忌・禁止、警告、注意を取扱説明書に載せて、設計対策をせずにリスク回避ができるとする風潮を許さないという規制当局側の考えがあるようだ。

ようするにユーザーが実質的に読まない注意や警告でリスクを回避できると製造業者側が判断することはまかり成らんという考え方だ。

トヨタ以外の各社が衝突回避システムのコマーシャルの最後に一瞬だけ表示する「警告メッセージ」をこの考え方に当てはめると、この警告はメーカーや販売店の自己保身には使えないことになる。

そうなると、実際に自動車を販売するときに、注意事項を確認したとサインさせるのかもしれないが、CMであんなに宣伝しておいて、いざ自動車を売るときになって注意点に同意させるのは紳士的なやり方ではないと思うのだが、皆さんはどう考えるだろうか。

サインしたのが自分でも運転するのは奥さんの方が多いかもしれないし、誰かに車を貸すことだってあるかもしれない。

そういうことがあるからトヨタだけは、衝突回避システムという安全のための機能を「売り」にしにないのではないか。

試乗会で事故が起こったので、今度は公道で事故が起きるかも知れない。事故が起こるのを期待しているのでは決してない。そうなる前にできることをやるべきだと思うのだ。

しかし、人間は事故が起きないと、本気で安全に向き合おうとしないというのも事実だ。

「安全」を売りにしようとすると大きなしっぺ返しが来る。そのことは事故が起きたときに初めて分かる。

こちらの日経トレンディの記事も参照のこと。

“ぶつからないクルマ”で大ヒット、「自動ブレーキ機能」は各社でこんなに違う！

「残業代ゼロ」の賛成意見に思うこと

厚生労働相の諮問機関、労働政策審議会の分科会がいわゆる残業代ゼロ」の提言を出した。

労働基準法では１日の労働時間を原則８時間として、残業や休日・深夜の労働には企業が割増賃金を払うことを義務づけている。一方、企業には人件費を抑えたり、もっと効率的な働かせ方を取り入れたりしたいという要求がある。

いまは部長級などの上級管理職や研究者などの一部専門職に限って、企業が労働時間にかかわらず賃金を一定にして残業代を払わないことが認められている。今回の提言では、この「残業代ゼロ」の対象を広げるよう求める。

今回は、この提言自体ではなく、ニュース番組で取り上げられる「残業代ゼロ」についてのちまたの賛成意見について考えてみたい。

「残業代ゼロ」の賛成意見の中には「ダラダラと仕事をしているのに残業代で稼いでいるのはおかしい」や「時間内に仕事を終わらせているのに評価が低いのは納得がいかない」といった組織の評価に対する不満からくる意見がある。

これらの意見を聞くと、果たして仕事の成果は客観的に評価できるだろうか、トータルで考えれば労働時間の方が客観的な評価指標として優れていないか、と思う。

というのも、ダラダラ仕事しているのを社員を放置しているのは、組織マネジメントの問題であり、マネージャにも責任があるのではないかと思うし、ダラダラかそうでないかの判断は極めて主観的であり、評価する人の感覚にもよると思うからだ。

仕事の効率や成果を評価するのはとても難しい。営業職ならば、売上高が分かりやすい指標だ。でも営業だって売り上げが上がれば言い訳ではない。お客さんをだまして商品を売りつけ一時的に売り上げを上げても長続きはしない。顧客は長いつきあいならアフターフォローがしっかりしている信頼できる営業マンから買いたいと思うだろう。

だいたい、仕事の効率がいいというのは何と比べているのだろうか。同じ仕事を自分がやればもっと早くこなせると考えるのだろうが、その人の仕事ぶりを別な人が評価したら、ちょっと違った感覚を持つかもしれない。自分はたばこを吸わないので仕事中にたばこを吸いに行く人を見ると、その時間がもったいないように思うことがあるが、彼らもたばこを吸いながらいろいろなことを考えているらしいし、少しインターバルを置いた方が仕事の効率が上がることもあるかもしれない。朝から晩まで、こんを詰めて働けば効率がいいとは限らない。

人事担当だって、仕事の効率がいい人材ばかりを採用できればそれに超したことはないだろう。人間、一人一人個性が違うので、採用する方もたいへんだ。毎年、技術系の新人教育をしていて、そのばらつきを毎回感じる。

プロジェクトはチームで目的を達成する。個々人は得意不得意があるから、プロジェクトリーダーはプロジェクトのパフォーマンスが最大になるようにマネジメントしなければいけない。プログラミングが優秀な人でも、他部門との交渉は苦手かもしれない。そういう人に外部折衝を任せて、成果が上がらないと低い評価をするのは得策ではない。

残業をしないと評価されないという意見も聞くことがある。プロジェクトリーダーの立場に立ったとき、プロジェクトに対して厳しい日程や突発的に発生した不具合に急遽対応しなければいけないことはよくある。そういったプロジェクトのピンチのときに、率先して対処してくれるメンバーがいるとありがたい。多くのメンバーは特に指示をしなくてもその期限を間に合わせようとしてくれる。結果、それが残業につながってしまうことはよくある。

「残業をしないと評価されない」は「プロジェクトがピンチにときに率先して動いてくれると助かる」の裏返しではないだろうか。

残業時間を考慮せずに成果で仕事を評価するのはそう簡単ではないと思う。もしも、本気で自分の実力を評価して欲しいのなら、満足できる評価をくれる会社を渡り歩く覚悟を決めるか、それとも独立するかないだろう。

独立すれば、お客さんが直接自分の仕事を評価してくれる。でも、そのときに、会社組織がいろいろなものを背負っていることが分かるのかもしれない。（独立したことはないので想像）

「ダラダラと仕事をしているのに残業代で稼いでいるのはおかしい」や「時間内に仕事を終わらせているのに評価が低いのは納得がいかない」といった意見を持つ部下の査定をするマネージャの立場になると、査定の苦しみが分かる。いっそ、労働時間という客観的な指標で評価できるとどんなに楽だろうかと思ったりするに違いない。

やはり、もとが生身の人間だとその仕事ぶりや成果を客観的に評価するのは難しいのだ。だから、誰が評価したって公平にはならないし、評価される方は不満が残る。でも、給料はお金というしごく客観的な指標で現れるので、他人と明確に比べられちゃうところが問題だ。となるとマネージャは給料とは別にプロジェクトメンバーを褒めたり、愚痴を聞いてあげることで評価のギャップを埋めるしかないのだと思う。

新規事業の模索

今年になって、新規事業を模索している部門の方と話をする機会が何回かあった。日本の産業構造は変化してきており、従来の業態で減少する市場に生き残りをかけるのでなく、成長分野へのシフトを考えておられるのだろう。

シフトの選択肢には医療分野も含まれており、ニュースソースにおいても日本の優れた技術があればこの分野でも成功の糸口が必ずあるはずだという論調をよく聞く。

そのたびに、 2013年6月 東京ビッグサイトで開催された第4回 医療機器 開発・製造展 MEDIXのオープニングスピーチで話された 国立循環器病研究センター　研究開発基盤センター長 妙中義之 先生の話を思い出す。

※以下、妙中先生のスピーチ概要と補足コメント（→）

平成25年6月 産業競争力会議では国民の「健康寿命」の延伸がテーマとなている。

(1) 民間の力を引き出す。
医薬品、医療機器、再生医療の市場規模を現在の12兆円から2020年に16兆円に拡大する。

【→元ネタは政府が公開している日本再興戦略(PDF）】

④健康長寿産業を創り、育てる

＜成果目標＞
◆健康増進・予防、生活支援関連産業の市場規模を2020 年に10 兆円（現状4 兆円）に拡大する◆医薬品、医療機器、再生医療の医療関連産業の市場規模を2020 年に16 兆円（現状12 兆円）に拡大する

：

医療や介護、保育や年金などの社会保障関連分野は、少子高齢化の進展等により
財政負担が増大している一方、制度の設計次第で巨大な新市場として成長の原動力
になり得る分野である。今回の戦略では健康長寿産業を戦略的分野の一つに位置付け、健康寿命延伸産業や医薬品・医療機器産業などの発展に向けた政策、保育の場における民間活力の活用などを盛り込んだが、医療・介護分野をどう成長市場に変
え、質の高いサービスを提供するか、制度の持続可能性をいかに確保するかなど、
中長期的な成長を実現するための課題が残されている。

【引用終わり】

大手メーカの医療機器分野への参入が相次いでおり、例えば重粒子線の医療機器開発に日立、三菱電機が乗り出した。これらの医療機器には10万点を超える部品が使われている。

→大型の医療機器が開発されることで、部品の需要も増えるという示唆。
→ただし、自動車などとは出荷台数が一桁も二桁も少ないので部品メーカーはその点を勘違いしないようがよいと思う。
→また、1980年代に放射線治療器 Therac-25 がソフトウェアの不具合で6名の死傷者を出している。この事故がなぜ起こったのかを、重粒子線の医療機器を開発しているエンジニアは十分にリサーチしておく必要がある。（ソフトウェアの特性を考慮せず事故が起きた事例）

透析機器は日本はトップレベル。治療成績もよい。サービス全体を輸出した方がよい。
日本で承認を受けたら、海外でも使えるようにしたい。

医療現場のニーズからスタートする医療機器開発も進みつつあるが、失敗している例も少なくない。

単に製品を作ればよいというものではない。事業として収益が上がらないとダメだ。課題解決型ならばよいと思うかもしれないが、それだけではうまくいかない。

例えば、次のような失敗事例がある。

• 医師のニーズにそのまま応える。（特定の先生の要望）
• 市場の見極めができていない。（企業の事業計画が必要）
• 画期的な医療機器だという自負だけがある。
• 魅力的なら売れるはず。（販路が確保できていない。パートナーの選定ができていない）
• 薬事のハードルが高く、超えられない。

成功するためには、サポートするための支援組織が重要。（コンサルティング）

試作をどんどん作ってしまい、その後に薬事申請ができなくて頓挫する。事業戦略がないのに試作品だけ先に作ってもうまくいかない。事業戦略を先にやらないとダメだ。

USではミネソタでそれがうまく機能している。ミネソタには、医療機器を開発し、販売するために必要な支援会社が集まっている。医療機器のベンチャー企業はミネソタに行けば、一通りの支援を受けられる体制がある。

医療機器は今後は、リハビリやフィットネスで使われるようになる。これはヘルスケア機器である。
肥満抑制　採血しないで血糖値が分かる機器。スマートフォン、タブレット端末でできるのではないか。

USはモバイルアプリの規制や産業育成にいち早く対応した。日本でも同じような流れはある。

------ 妙中先生のスピーチ概要 終わり ------

スピーチの中の失敗事例は多くの教訓を示唆している。薬事法が改正され、医薬品医療機器等法になったことで、今後薬事申請のガイドラインはさまざま出てくるだろうから、薬事の「訳の分からないハードル」は徐々に解消されていくと思う。（訳は分かったが、対応することは難しいという状況は残るかもしれない）

問題は法規制の話ではなく、売れるものを作れるのかということだ。どんな業種でも基本はニーズから出発していなければ事業は成功しない。

ところが、従来の業態で減少する市場とは異なる分野に進出したいと考える企業は、今持っている自分達の技術が「医療機器開発に使えるはずだ」と来る。「この部品は使えるはず」とか「このアプリを応用すれば役に立つはず」とか。しかし、これはニーズからの出発ではなく、シーズの押しつけだ。

シーズから始めて事業が成り立つ可能性は低い。また、汎用プラットフォームが発達した現在、汎用プラットフォームに自社開発したソフトウェアを搭載しただけで医療機器することが日本でもできるようになる。そのため、今流行っていたり、こらから流行りそうだと噂されているアプリやサービスをソフトウェアで実現すればよいと安直に考える人がいる。

医療ドメインに初めて足を踏み入れるソフトウェアの開発会社でも、市場規模が拡大するこの世界で一攫千金をつかめそうな感じがするが、そう簡単な話ではない。

医療機器としての商品の価値を高めるためには、診断・治療・予防のいずれかを意図した目的とする必要がある。逆に言えば、診断・治療・予防を標榜する場合は、法規制の対象となる。たまに薬事法違反で捕まったと流れるニュースの多くは、法規制に対応せず診断・治療・予防を標榜して商売したというケースが多い。例えば、薬事法の申請をせず「癌が治る薬」と宣伝して商売したような場合だ。

また、「部屋の中のウイルスを死滅させることにより、インフルエンザにかからない空気清浄機を開発しました。」などと予防効果を宣伝した場合も、薬事法違反だ。シャープのプラズマクラスターの説明をよく見て欲しい。風邪やインフルエンザの予防効果があるとは一言も書いていない。書いたら、薬事法違反になるからだ。

ようするに、診断・治療・予防の効果を標榜して価値を高めたいのなら、臨床的に効果があることを証明する必要がある。

STAP細胞の件で、我々は十分に学習したが、科学における実証・立証というものは、地道な研究に積み重ねによって成り立つ。臨床研究には時間も金も、医療機関との連携も必要で、規制当局による有効性の審査は非常に厳しい。

一方で、診断・治療・予防を標榜しない、健康増進やヘルスユースを目的とした機器、ソフトウェア開発に進出することはできる。ただし、この場合、医療機器が持つ価値までには届かない。

例えば、医薬品としての認定を受けるのはとても難しいが、特定保健用食品としての許可を得るのは医薬品ほど難しくはないのと同じだ。特定保健用食品は医薬品ほどの劇的な効果はないが、一般食品よりも健康増進に役立つことを標榜することができる。

健康増進やヘルスユースを目的とした機器、ソフトウェアにも特定保健用食品のような表示があるとよいのだろう。

さて、シーズから出発して作ったしまった試作品はニュースでは取り上げられることはあっても、事業として成功する確率は低い。医療機器ドメインで勝負をしようと考えるのなら、それが、ソフトウェアアプリだったとしても、長い目で見れば何らかの臨床研究は必ず必要になってくる。

成長が期待される市場への参入を検討することはよいのだが、医療機器ドメインは思いつきで成功をつかめるところではない。何を解決したいのか、効果の対して自信があるか、リスク分析・リスク対策ができているか、販路も含めた事業計画があるかといったことを詰めていく必要がある。

医療機器、ヘルスユースソフトウェアは息が長く堅い商売ではあるが、その裏側には地道な臨床研究が要る。一攫千金を掴みたいと考える者にはまったく向かないドメインなのだ。新規参入を考えている方々には、そのことをよく考えてもらい、どんなニーズを満たすソリューションのネタを持っているのか、医療や健康増進にどんな効果があるのか、また、その裏側にどんなユーザーリスクが想定されるのか、今一度考えて欲しいと思う。

ホンダフィット自動変速機の制御プログラムの不具合について考える

ホンダが2013年に発売した「フィット」のハイブリッド車で、2月10日に3回目のリコールが出た。1回目が2013年10月に起きたデュアルクラッチ自動変速機の制御プログラムの不具合で、モータ走行モードでドグとスリーブがかみ合わず走行できなくなる恐れがあるというもの。

2回目が2013年12月に発覚したエンジンECUや変速機ECUにおけるプログラム不具合によって、エンジンがストールしたり、駐車状態から起動しなくなる恐れがあるもの。

そして、3回目が2014年2月で1速歯車のハブ上をスリーブが滑らかに動かず、1速がかみ合わなかったり、突然発進する可能性があるとのこと。最後の1件はソフトウェアの不具合ではないようだが、1速ギヤがかみ合いやすくなるようにエンジン制御ユニットのプログラムを変更するため、これも制御ソフトウェアの変更で対処する。

東洋経済のWEBサイトに【ホンダ｢フィット｣に不具合が多発する理由－早くも3度目のリコール､好調な販売に冷や水－】という記事があり原因について下記のようなことが書かれている。

【ホンダ｢フィット｣に不具合が多発する理由－早くも3度目のリコール､好調な販売に冷や水－より引用】

新しいHVシステムが原因

今回、十分な対応ができなかった背景には、DCTを使ったHVシステムがホンダにとってこれまでに経験がないまったく新しい複雑なシステムだったことがある。従来、ホンダはHVのシステムとしてIMAという方式を使っていた。これは常に稼働するエンジンを必要に応じてモーターがサポートするという比較的単純な方式のHVシステムだった。

これに対して新システムは、2つのクラッチを持つDCTにモーターを組み合わせ、発進時にはモーターのみで走行し、加減速や車速など状況に応じて変速機の段数を変化させてモーターアシスト走行やエンジン走行、充電を行う複雑な機構になっている。ホンダにとって、モーターのみで走行できるHVの経験はなく、DCTという変速機方式も初めての採用だった。

複雑な制御を行うため、変速機の制御ソフトウエアの開発工数は、ガソリン車や既存HVに比べて「半端なく増えた」（開発者）。DCTのユニットを供給するドイツの大手機械メーカー・シェフラーの開発陣とともに、本田技術研究所では最後の最後まで手直しを繰り返したという。

HV競争の緒戦でトヨタに完敗したホンダが、逆転をすべくHVシステムを完全刷新するという高い目標に挑んだわけだが、品質管理での詰めが十分でなかった。

【引用おわり】

また、日本経済新聞の記事では下記のようなことが書いてある。

　「次は許されないぞ」――。順風満帆に見えるホンダで、社長の伊東孝紳をいらだたせる問題が発生した。

　：

伊東が掲げた目標を達成するには、どのくらいのペースで、これから販売台数を上積みしていけばいいのか。

　答えは、今までの4倍近いスピードだ。

ホンダは過去10年間、販売台数を年平均で約14万台ずつ増やしてきた。しかし、600万台の目標達成には、向こう3年は年平均で50万台超の販売台数の積み増しが必要な計算になる。

　そんな「4倍速」の成長を追っていけば、その分、開発部隊への負担が重くなって当然だ。そもそも研究所の技術者たちの仕事は、フィットなど「今の車」だけをつくることだけではない。

これらの記事の中で出てくるキーワードをまとめると下記のようになる。

• まったく新しい複雑なシステム
• 初めての採用
• ソフトウェアの開発工数が増えた
• ソフトウェアを最後の最後まで手直しを繰り返した
• 開発は急がされていた

ホンダの3回のリコールのソフトウェアの不具合の具体的な原因が表には出てこないので、ソフトウェアの技術的な分析はできないが、このキーワードを見ただけでさもありなんと感じる。

特に「まったく新しい複雑なシステム」で「手直しを繰り返し」ていて「開発は急がされていた」という条件とソフトウェアのリコールは相関があると確信する。

セーフウェアを書いたMITのナンシー・レブソン教授の最近の研究である (STAMP: Systems-Theoretic Accident Model and Processes) では、プロジェクトへのプレッシャーがシステムの安全に与える影響を分析している。そういった定性的な分析もさることながら、新しい複雑なシステムで開発が急がれていて手直しを繰り返していたら、アーキテクチャが崩れていくことが予想される。

ポイントは新規設計した際のアーキテクチャが綺麗だったとして、現実の状況に合わせてソフトウェアのすり合わせを繰り返してアーキテクチャを崩してはいけないということだ。デリバリーを急がされるプレッシャーに負けると、アーキテクチャは崩れる。ソフトウェアは外には見えないだけに、そこの防波堤はアーキテクトの考え方やポリシーにかかってくる。

早期リリースのプレッシャーに負けるとソフトウェアシステムの複雑度が増して、バグやデグレードの温床を生んでしまう。そんな危険はアーキテクトとしての経験がない者にはまったく分からないので、経営層はプロジェクトにリリースを間に合わせることを優先しろと言ってしまう。「リリースは間に合わせろ、バグは出すな」と言うのも同じことだ。バグを出さないようにするには、検証に十分な時間が必要であり、かつ、十分な時間が与えられたとしてもバグをゼロにすることはできないので、「リリースは間に合わせろ、バグは出すな」という指示は、結果として「バグ入りでリリースする危険を冒せ」と言っているのと同じなのだ。

東洋経済の記事も日経の記事も最後は品質管理の詰めが十分でなかったという結論になっているが、そこで終わらせたらダメだろうと思う。

じゃあ、品質管理の詰めって何だと聞きたい。ホンダだって ISO 26262 の取り組みをやっているはずだろう。なぜ、ISO 26262 の取り組みを行っているのに、ソフトウェアのリコールが起こるのか、誰か答えてはくれないだろうか。

下記の文章は 2006年 9月14日、15日に開催された 日科技連主催の－ソフトウェア品質シンポジウム－で広島市立大学情報学部教授 大場充先生が「ソフトウェアのテストと品質保証」について講演されたときの話を書き起こしたものだ。

ソフトウェアの品質論は、1960年代のZD(Zero Defect)運動に始まり、不良を無くすことが、究極的な品質の実現であるとする経験主義的色彩の濃い統計的品質管理が行われてきた。その後、ソフトウェアの規模や複雑度の増加に伴い「ソフトウェア開発において良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるプロセス重視の品質論が主流になる。
プロセス重視の品質論は1970年代以降個々の理論の不備を修正しながら今日まで発展し続けており、その枠組みは強固である。しかしながら、「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」という経験主義者から提示される疑問に完全に答え切れていない事実も存在する。

そして改めて経験主義者の代表として問いたい。「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」「なぜ、自動車の安全を目的に作られたプロセスを実践してもリコールを無くすことはできないのか」

答えは分かっている。ソフトウェア品質はプロセスで管理するのが1970年代からの主流ではあるが、不具合の発生を完全に防止できる訳でもなく、プロセスアプローチは安全性や信頼性を保証する方法ではないということなのだ。

ようするに、プロセスアプローチは組織やプロジェクトの活動を改善することには役立つが、安全の保証には使えないということだ。だから、「なぜ、良いプロセスが実践されていることによって、悪い品質のソフトウェアが開発される可能性を低下させることができるのか」という問いに答えられるはずがない。

経営層が本当にリコールを防止したいのなら、ISO 26262 とは別の取り組みを進めなければならない。ISO 26262 の取り組みを進めることは無駄にはならないが、リコール防止の切り札として考えているのなら、今回のホンダと同じような痛い目に会うだろう。

一番やってはいけないのは、「新しい複雑なシステムに対して開発を急がせる」ことだ。経験主義者のアーキテクトからのアドバイスとしては、安全対策を施したリスクコントロール手段をアーキテクチャとして可視化し、リリースが近づいてきた時ほどアーキテクチャの崩れに注意を払い、「リリースが近いから早くしろ」とエンジニアを焦らせないことだ。

そして、いつも言っているように個別最適の発想ではなく、全体最適の発想を持ち、バグはあるものと過程して、バグがあっても大事故に至らないような設計の心掛けることが重要だ。

今回のホンダの3回のリコールも結局、死傷者は一人も出ていなかったのだから、その点フェール・セーフは達成できていたと考えて良い。後は、ブランドイメージ低下と販売の落ち込みの程度を計算し、十分な検証期間を取ったことで販売が遅れたときの機会損失とどっちが得かを比較すればよいのだと思う。

大きなリスクについては受容できる対策が取られているのならば、軽微な不具合は市場で発見されたものを改善することで対処するという考え方もある。消費者もそこは分かっていて新製品には飛びつかず技術が枯れるまでしばらくまったりするのはそのためだ。

この程度のマイナス記事は数ヶ月もすれば皆忘れてしまうとどっしり構えていればよいときもある。

ただ、あまりにも不具合の発生が多いと企業としての信頼を失うし、修正を繰り返しているとアーキテクチャは崩れていく可能性が高い。

最後に繰り返す。新しい複雑なシステムに対してプロジェクトに過度なプレッシャーをかけて開発を急がせてはならない。悪い結果を呼び込むだけだ。

サイエンスとエンジニアリング

STAP細胞の真偽のニュースを見ていて、サイエンスの論文はたいへんだなあと感じている。サイエンスの論文で大事なのは再現性とメカニズムだと思う。

STAP細胞で今問題視されているのは、まずは再現性だ。論文に書かれた方法で実験しても小保方さん以外でまだ再現に成功した研究者がいない。

そして、小保方さんの論文には、なぜSTAP細胞が（本当にあるとして）できるのかのメカニズムの分析や推定がないように思う。

再生医療で社会に貢献するためには、まず、「STAP細胞があるという証明」とともに再現するための手順が必要であり、さらなる研究を促すためにはSTAP細胞がなぜできるのかのメカニズムの説明・証明が必要だと感じる。

ただ、サイエンスの世界ではそれができれば、非常に大きな社会貢献が実現する。だからこそ、サイエンスの論文は権威が高く、査読や研究者からの評価も厳しいのだろう。

一方でエンジニアリングの論文はどうだろうか。自分もエンジニアリングの論文を書いたことが何回かあるが、サイエンスの論文との違いにいつも釈然としないものを感じる。

特に情報工学、ソフトウェア工学の論文についてはいろいろ思うことがある。

まずは、再現性について。ソフトウェア工学で普遍的な再現性は果たして言えるのだろうか。ソフトウェアを作っているのはまだ人間だ。例えばソフトウェア工学における新しい方法論の論文があったとする。もちろん、その論文では一つかいくつかのプロジェクトで効果があったという結論になっている。しかし、人間が作っている以上、別の会社、別のドメイン、別の国で同じやり方をやって同じ結果になるとはとても思えない。そこが、サイエンスとの大きな違いだ。

だとすると、ソフトウェア工学の論文の査読は何の基準で採用と不採用を決めるのだろうか。新規性なのか、論理の正当性なのか、それとも査読者の好みなのか。

それが自分には分からない。エンジニアリングの論文は、新規性のあるなしは審査基準になるとして、それ以外の部分では、雑誌の記事や書籍で言いたいことを言うのと何が違うのだろうかといつも疑問に思っている。

論文の難しい言い回しを使わず、先人の知恵を解説しながら、時代背景や条件を示した上で何をどうすれば期待する成果が出るのかを発表する場があり、読者がそれに納得できれば論文でなくてもいいのではないだろうか。

それに相当するのがシンポジウムにおける発表なのだと思うが、それと権威があると言われるソフトウェア工学の学会論文との差がよく分からない。

サイエンスにしてもエンジニアリングにしても、その功績は社会にどれだけ貢献するのか、したのかで評価されるのだろうと思う。

サイエンスの場合は、再現性やメカニズムの普遍性が証明できれば、評価の土俵に乗ることができる。しかし、エンジニアリングの場合は、どうだろうか。多くの支持を集めることができれば勝ちなのか。例えば、欧米の開発スタイルには合っていなくても、日本のプロジェクトには効果がある方法論があったとしたら、それは評価されないのか。（日本発でその後世界で評価された方法論はいくつかある）

今回のSTAP細胞の騒動を見て、サイエンスの世界は厳しくも客観的な評価によって成り立っていると感じた。

一方で、エンジニアリングの世界ではどのような評価をすればよいのか、公平で有効な評価の考え方が必要だと思った。自分はそれがCMMIのようなプロセスリファレンスモデルを使った成熟度の評価ではない、特に日本では有効ではないと思っている。

かといって代替え手段のよいアイディアを今持っている分けでもない。ただ、ソフトウェアエンジニアリングの論文評価がまさかその時代の流行によって左右されてはいないのだろうかという心配はしている。

今でも忘れられない授業

自分は30年以上前、埼玉県春日部市立東中学校の生徒だった。普通の公立中学校でそのころのことで覚えていることはほとんどないのだけれど、一つだけ鮮明に覚えている授業がある。

毎回英語の歌を合唱するという授業だ。本当に申し訳ないのだが、先生の名前は思い出せない。

先生が決めた英語の歌の歌詞が書かれたプリントが配られ、テープレコーダーから流れてくる曲に合わせてみんなで英語の歌を歌う。

英語を覚えたての中学生だから意味もよく分からないし、発音も難しい。選曲は短い簡単な曲から徐々に難しくなっていって、最後はジョン・デンバーのカントリーロード（オリビア・ニュートン・ジョン バージョン）だった。

覚えている限り、歌った曲は次の4曲だった。

1. We Shall Overcome （ピート・シーガー）

2. Where have all the flowers gone? （ピート・シーガー,唄　ブラザース・フォア ）

3. Blowin' in the Wind （ボブ・ディラン, 唄 ピーター・ポール&マリー）

4. Country Rode （ジョン・デンバー, 唄 オリビア・ニュートン・ジョン）

1. We Shall Overcome  と 3. Blowin' in the Wind は1960年代にアメリカで盛り上がった、人種差別を反対する公民権運動の象徴と言えるプロテストソング、2. Where have all the flowers gone?  は反戦歌だ。

Country Rode は公民権運動や反戦とは関係ないが、フォークソングの代表作で、当時TBSテレビ『おはよう700』のテーマソングとなっていたため、選んだと先生は言っていた。（カントリーロードは、日本では、今や映画耳をすませばバージョンの方が有名かもしれない）

当時、先生は曲の本当の意味や背景を一切説明していなかった。これらの選曲を今考えてみると単純にフォークソングが好きだっただけではなく、人種差別への反対や反戦の気持ちがあったと思う。

しかし、学習指導要領で指示もされているわけでもなく、思想教育とも取られかねないリスクもあるため、これらの曲が作られた背景や歌詞の意味を説明しなかったのではないだろうか。

その当時の中学生にとっては、意味を理解するどころではなく、歌詞を正確に発音しようとすることだけで精一杯だったので、ただ単に、ブラザーズ・フォアやピーター・ポール&マリーやオリビア・ニュートン・ジョンの美しい歌声を聞きながら、一緒に歌うことが楽しかった。

そして、ほとんど唯一、中学校での授業の記憶はこれらの英語の歌を歌ったことしかないのだ。

ジョン・デンバーやオリビア・ニュートン・ジョンはその後アルバムを買って聴いたりしていたが、大学生になったころ、Blowin' in the Wind（風に吹かれて）がボブ・ディランの曲であることを知ったあたりから、中学生のときに歌っていたあの歌はどんな意味だったのだろうかと思うようになった。

We Shall Overcome （我らは必ず打ち勝つ）
勝利を我らに

作詞：Zilphia Hart., Frank Hamilton, Guy Carawan
and Pete Seeger

訳詞：Paul Kim

We shall overcome, we shall overcome,
We shall overcome someday;
Oh, deep in my heart, I do believe,
We shall overcome someday.

我らは打ち勝つ、我らは打ち勝つ
我らは打ち勝つ、いつの日か
ああ、心の奥深くで信じてる
我らが打ち勝つということを

We'll walk hand in hand, we'll walk hand in hand,
We'll walk hand in hand someday;
Oh, deep in my heart, I do believe,
We shall overcome someday.

我らは手に手を取って歩くんだ
いつの日か手に手を取って歩くんだ
ああ、心の奥深くで信じてる
我らが打ち勝つということを

We are not afraid, we are not afraid,
We are not afraid today;
Oh, deep in my heart, I do believe,
We shall overcome someday.

我らは恐れない、我らは恐れない
今日の日を我らは恐れない
ああ、心の奥深くで信じてる
我らが打ち勝つということを

We shall live in peace, we shall live in peace,
We shall live in peace someday;
Oh, deep in my heart, I do believe,
We shall live in peace someday.

我らは平和の中に生きる、平和の中に生きる
いつの日か平和の中で生きる
ああ、心の奥深くで信じてる
我らが打ち勝つということを

The Lord will see us through, The Lord will see us through,
The Lord will see us through someday;
Oh, deep in my heart, I do believe,
We shall overcome someday.

神様が導いてくださる
神様が導いてくださる、いつの日か
ああ、心の奥深くで信じてる
我らが打ち勝つということを

We're on to victory, We're on to victory,
We're on to victory someday;
Oh, deep in my heart, I do believe,
We're on to victory someday.

我らは勝利へ向かってる
我らは勝利へ向かってる、いつの日かの
ああ、心の奥深くで信じてる
我らが打ち勝つということを

The truth shall set us free , the truth shall set us free,
The truth shall set us free someday;
Oh, deep in my heart, I do believe,
The truth shall set us free someday.

真実が我らを自由にしてくれる
真実が我らを自由にしてくれる、いつの日か
ああ、心の奥深くで信じてる
我らが打ち勝つということを


Blowin' In The Wind : Bob Dylan

ボブ・ディラン Bob Dylanの曲「風に吹かれて」Blowin' In The Wind（壺齋散人による歌詞の日本語訳）

　　How many roads must a man walk down
　　Before you call him a man?
　　Yes, 'n' how many seas must a white dove sail
　　Before she sleeps in the sand?
　　Yes, 'n' how many times must the cannon balls fly
　　Before they're forever banned?
　　The answer, my friend, is blowin' in the wind,
　　The answer is blowin' in the wind.

　　どれほどの道を歩かねばならぬのか
　　男と呼ばれるために
　　どれほど鳩は飛び続けねばならぬのか
　　砂の上で安らげるために
　　どれほどの弾がうたれねばならぬのか
　　殺戮をやめさせるために
　　その答えは　風に吹かれて
　　誰にもつかめない

　　How many years can a mountain exist
　　Before it's washed to the sea?
　　Yes, 'n' how many years can some people exist
　　Before they're allowed to be free?
　　Yes, 'n' how many times can a man turn his head,
　　Pretending he just doesn't see?
　　The answer, my friend, is blowin' in the wind,
　　The answer is blowin' in the wind.

　　どれほど悠久の世紀が流れるのか
　　山が海となるには
　　どれほど人は生きねばならぬのか
　　ほんとに自由になれるために
　　どれほど首をかしげねばならぬのか
　　何もみてないというために
　　その答えは　風に吹かれて
　　誰にもつかめない

　　How many times must a man look up
　　Before he can see the sky?
　　Yes, 'n' how many ears must one man have
　　Before he can hear people cry?
　　Yes, 'n' how many deaths will it take till he knows
　　That too many people have died?
　　The answer, my friend, is blowin' in the wind,
　　The answer is blowin' in the wind.

　　どれほど人は見上げねばならぬのか
　　ほんとの空をみるために
　　どれほど多くの耳を持たねばならぬのか
　　他人の叫びを聞けるために
　　どれほど多くの人が死なねばならぬのか
　　死が無益だと知るために
　　その答えは　風に吹かれて
　　誰にもつかめない

Where Have All The Flowers Gone?

花はどこへ行った?

作詞：Pete Seeger & Joe Hickerson 日本語歌詞：おおたたかし

Where have all the flowers gone?

Long time passing

Where have all the flowers gone?

Long time ago

Where have all the flowers gone

Young girls have picked them every one

When will they ever learn,

When will they ever learn?

野に咲く花は どこへ行く

野に咲く花は 清らか

野に咲く花は 少女の胸に

そっとやさしく 抱かれる

Where have all the young girls gone?

Long time passing

Where have all the young girls gone?

Long time ago

Where have all the young girls gone?

Gone to young men every one.

When will they ever learn,

When will they ever learn?

かわいい少女は どこへ行く

かわいい少女は おぼれる

かわいい少女は 若者の胸に

恋の心 あずけるのさ

Where have all the young men gone?

Long time passing

Where have all the young men gone?

Long time ago

Where have all the young men gone?

Gone for soldiers every one.

When will they ever learn,

When will they ever learn?

（young men の代わりにhusbandsも有り）

その若者は どこへ行く

その若者は 勇んで

その若者は 戦いに行く

力強く 別れを告げ

Where have all the soldiers gone?

Long time passing

Where have all the sodiers gone?

Long time ago

Where have all the soldiers gone?

Gone for graveyards every one.

When will they ever learn,

When will they ever learn? 

戦い終わり どこへ行く

戦い終わり 静かに

戦い終わり 土に眠る

やすらかなる 眠りにつく

Where have all the graveyards gone?

Long time passing

Where have all the graveyards gone?

Long time ago

Where have all the graveyards gone?

Gone to flowers every one.

When will they ever learn,

When will they ever learn?

戦士の眠る その土に

野ばらがそっと 咲いていた

野ばらはいつか 少女の胸に

そっとやさしく 抱かれる

あの当時、中学生の生徒達に先生は伝えたかったことがあったのではないかと思っている。そのときには分からなくても、成長した後に分かる、自分の意思を持って考える力が付いた時に分かる授業をしたのではないかと思っている。

日本は民衆が自らの力で民主主義を勝ち取ったのではなく、敗戦後米国から民主主義を与えられて今に至っている。そして、確固たる自分の意思を持たないふわふわした中間層が大多数を占める社会になっている。

だから、そのふわふわした中間層が風に吹かれて右にいったり左にいったりする民主主義で社会が動いている。（ここで言う風とは、そのときそのときの話題になっている事柄のこと）

（右とか左とかじゃなくて）日本の義務教育で欠落しているのは、自分が自分の意思を持って、その意思を他人と戦わせながら合意を形成するスキルやプロセスの教育だ。

だから、会議をすると誰かが何かを言うまで黙っている者が圧倒的に多い。決を採れば賛成や反対はするが、「自分はこう思う」といった意見が出てこない。

先生は教育指導要領で生徒に教える範囲や教え方を縛られているから、だからところてんのように同じような考えを持った子供が次々と押し出されていくのかもしれない。

あの英語の先生は、自分の考えを自分の教え方で子供達に教えたのではないかとずっと思っていた。それはたぶんリスクもあったのだと想像する。

そのときには分からなくても、成長した後に分かる、自分の意思を持って考える力が付いた時に分かる授業、そういう講義を自分もしなければいけないと思った。

フィールドでソフトウェアの不具合が発生したら粛々とリコールをするべし

トヨタが2月12日にプリウスを世界で約190万台、ハイブリッドシステムを制御するプログラムに不具合があるということでリコールを発表した。

【Tech On!  「プリウス約190万台をリコール、昇圧回路の素子に想定外の熱応力」より引用】

トヨタ自動車は、2009年5月から販売を始めた3代目プリウス（ZVW30）約190万台をリコールすることを明らかにした。2009年3月から2014年2月までに生産したもので、日本市場向けの約100万台、海外市場向けの約90万台が対象になるという。 

　トヨタ自動車の説明によれば、プリウスのハイブリッドシステムにおいて、制御ソフトが不適切なため、加速時などの高負荷走行時に昇圧回路の素子に想定外の熱応力が加わる恐れがあるという。このとき素子が損傷し、警告灯が点灯して「フェールセーフのモータ走行」になってしまう。加えて、素子損傷時にノイズが発生すると、ハイブリッドシステムが停止し、走行不能になる可能性もあるという。なお、損傷する恐れがある素子の具体的な内容については現時点で明らかにしていない。

　実際に前述の警告灯が点灯したことが市場から報告されたことがきっかけで、今回の不具合の発覚につながったという。トヨタ自動車によれば、事故などは起きていない。
　改善策として、全車両の制御ソフトを修正する予定。制御ソフト修正後に素子が損傷して警告灯が点灯した場合は、電力変換器(DC-ACインバーター)のモジュールを無償交換するとしている。

【引用終わり】

詳しい原因は発表されていないのでよく分からないが、ハイブリッドシステムの制御ソフトに問題があったようだ。制御ソフトを修正することで現象は発生しいなくなる。

『リコールを起こさないソフトウェアのつくり方』というタイトルの本を執筆しておきながら、こんなことを言うのもなんだが、極度に複雑化したソフトウェアでリコールを完全に防ぐことはできない。

だから現代のソフトウェア製品では、まず、人の死に至るような不具合が発生しないようなリスクコントロール対策を施す。

そして、それでも発生してしまった不具合に対しては、粛々とリコールを行い、再発防止策を実施する。マスコミが騒ぎ立てるのはしようがないが、組織内部、関係部署が浮き足だってはいけない。

上記の記事によると、加速時などの高負荷走行時に昇圧回路の素子に想定外の熱応力が加わって素子が損傷したときに、警告灯が点灯して「フェールセーフのモータ走行」になると書いてある。

問題が起きたときにフェールセーフのリスクコントロール対策が働くことで、大きな事故につながらないような設計がされていた。これが重要なのだ。

ISO 26262 でソフトウェアの開発プロセスのことしか指摘できないコンサルタントやISO 26262の認証を取ることにしか価値を見いだせない認証会社には理解が難しいかもしれない。

大事なのは大事故にならないリスクコントロール対策として何をすればよいのかということだ。その対策はソフトでもメカでもエレキでもいい。方法は問わない。

ただし、ソフトウェアに特徴的な問題点はあるので、そこに配慮が必要だ。ソフトウェアは複雑になればなるほど、内在する不具合を見つけるのが難しくなる。

よく考えもせずに追加・修正を繰り返した10万行クラスのソフトウェアが完全であることなど証明できない。だから、安全を実現するためのアーキテクチャが重要であり、最初に考えたアーキテクチャが崩れていないことを確認しながらソフトウェアを修正していかなければいけない。

プリウスのハイブリッド制御システムは、これまでの公になっている情報から想像するに複雑過ぎるように感じる。燃費を極限まで高めるために、ソフトウェアアーキテクチャがが犠牲になったような気がする。

どこかの時点でアーキテクチャを綺麗にしないと、ソフトウェアの変更によってデグレードが発生する危険性が高まると思う。

このことは前々からこのブログで書いているように「フォールト　アボイダンス」の個別最適を追求するのは無理であり、「フェールセーフ」「フォールトトレランス」「ユーザビリティエンジニアリング」などで全体最適によって安全を確保しなければいけないということだ。

この話は SESSAMEの e-Learning コンテンツ「ソフトウェア安全分析・設計」で詳しく解説しているのでそれを是非参考にして欲しい。

あと何年かすると自動車もネットワーク経由でファームウェアをアップデートするような日がくるのだろう。ただ、それが出来てしまうとソフトウェアはアップデートすればいいんだという考え方がはびこるのが怖い。付け足しによるソフトウェア改変が多くなればなるほど、安全アーキテクチャは崩れる危険性が高いからだ。また、セキュリティ面での対策を施さないと自動車をハッキングしてやろうという輩が出てくるだろう。

ソフトウェアエンジニアにとっては受難の時代だが、すっきりしたアーキテクチャを設計・維持できる技術者が高評価を得られる時代になってきたとも言える。

ヘルスソフトウェアの市場に新規参入しようとしている方達へ

電通大のにしさん(ハッシュダグ @YasuharuNishi) が Twitter で清水 吉男さんのブログの記事『国内回帰の動きの「陰」』に同調して、

つまり我々は、単価ではなくて技術力を理由とする国内ソフト産業の空洞化が始まっているという動きを無視してはいけないのだよ。要するに、スキル向上の施策も採らず組織改善にも取り組まず進化のかけらもない日本のソフトハウスは早晩倒産してしまうのだ。

とつぶやいていた。まったくその通りだと思う。

日本の経済環境変化の話題として、政府の旗振りの影響もあってか、医療や医療機器産業をを産業振興の柱のひとつにしたいという話がにわかに盛り上がってきている。

これまで医療機器ドメインを主力にしていなかった企業がヘルスケア事業に乗り出すことを発表したり、ヘルスユース目的のアプリケーションソフトを作る会社が増えてきた。

ヘルスユースのアプリケーションソフトウェア(ヘルスソフトウェア）はいろいろな用途に使え、ネットワーク接続できる汎用のプラットフォーム（iPhone, iPad, アンドロイド端末）が普及したことで、世界中で爆発的に増えている。中には iPhone の内蔵カメラで撮影した画像を解析し皮膚がんかどうかを診断できるとうたったものもあるらしい。

このような新しい分野への雪崩のような進出により、市場では大小様々な問題が発生していると聞く。そういうときに真っ先に動くのが米国 FDA（食品医薬品局）だ。

例えば、下記のようなアプリは 米国FDA は法規制が必要な医療機器だと認識はしているが、執行裁量権を使ってとりあえず規制を保留すると決めたアプリの例だ。ようするに、この手のアプリは雨後の竹の子のようにどんどん世の中に出てくるが、リスクが高いとは言い切れないので、とりあえずグレーゾーンに分類しておいて、市場で事故でも起こりようものなら、すぐに規制するぞというアプリだ。

• 禁煙しようとしている喫煙者、中毒から回復中の患者、または妊婦に定期的に教育情報、リマインダー、意欲を起こさせるガイダンスなどを提供するモバイルアプリ。
• 喘息患者に喘息症状を引き起こす恐れのある環境条件を警告する、または中毒患者（薬物乱用者）に予め特定された高リスクの場所に近づいたときに警告するために、GPSによる位置情報を使用するモバイルアプリ
• 患者または介護者が最初の応答者に警報または通常の緊急事態通知を作成し送信できるようにするモバイルアプリ
• 患者に自身の健康情報、例えば前回受診の際に把握された情報へのアクセスまたは過去のトレンド分析およびバイタルサイン（例、体温、心拍数、血圧、呼吸数など）の比較などへのポータルを提供するモバイルアプリ

出典 米国FDA 発行 『Mobile Medical Applications Guidance for Industry and Food and Drug Administration Staff』 Appendix B Examples of mobile apps for which FDA intends to exercise enforcement discretion

日本は FDA のような対応はそう簡単にはできない。そこで、あまり詳しいことは書けないが、今、ヘルスユースのソフトウェア開発に進出しようとしている方達に安心安全なソフトウェアを提供するにはどうすれば良いのかについて議論してガイドラインを作ろうとしている。

興味のある方は経済産業省から出ている「医療用ソフトウェアに関する研究会-中間報告書」を読んでみるとよい。

これに関連して自分達は、先を行っている経験者として、新規参入する方達にヘルスケアドメインの製品やソフトウェアを開発する際に、何が重要であり、どんなスキルを身につける必要があるのかをまとめている。

そして、新たに身につけるべき知識技術について議論していると、この分野の外にいた方達から「ハードルが高すぎる」「分かりにくい」「平易な表現でないと新規参入の妨げになる」という声が聞こえてきて、暗に「そんなもん、役に立つのか」と言っているように感じる。

欧米人が中心になって作った国際標準を神の啓示かのようにあがめ奉って、「そんなことも知らないのか」という態度を取る人達は嫌いだが、国際標準が求めることの意味や中身を理解しようともせずに、ただただ「面倒だ、役に立たない」と決めつけ、日本という島国のガラパゴス市場に引きこもる日本のソフトウェアエンジニアはもっと嫌いだ。

前者は手段が目的になっており、後者は目的がなく、ただ今という時間に流されている。オフショアをやめて国内回帰すると組織が決めたら「はいはい」と言って、指示に従う「どうせどうせ子ちゃん」のようだ。

日本のソフトウェアエンジニアはどうしちゃったんだ？と思っている。

よっぽど、自分達のソフトウェアの品質に自信があるのか分からないが、他のドメインでやられているが自分が知らないこと、新しいことはすべて余計なことで、自分達がやっているやり方だけが正しいというのか。

自分はヘルスソフトウェアの分野に新規参入してくる方達にまず、安全（セーフティ）とは何かを教えるためには何をすればいいか今、考えている。

そこで作ったのが冒頭のスライドだ。ヘルスソフトウェアの開発プロジェクトはヘルスソフトウェアを作って、ヘルスソフトウェアのユーザーとなる介護領域の方々や、持病を持った個人、医療機関などに使ってもらう。

そのソフトウェアが優良であれば、健康の増進、病気の予防などに貢献し、ユーザーに感謝してもらえる。「ありがとう」の声を聞くこともできる。

話がそれるが、自分は テレビ東京の和風総本家スペシャル「世界で見つけたMade　in　Japan」 が大好きで、いつも見ている。この番組でメイドインジャパンの逸品が世界のユーザーのところで役に立っているところをスタッフがビデオに撮って字幕を入れて、職人さんたちに見せるシーンがある。職人さんたちも工場のスタッフもみんなで食い入るようにモニタを見つめ、涙を浮かべる者もいる。自分達が苦労して作った製品が、海の向こうで役に立っていることを目の当たりにし、作り手側の感謝の気持ちと、さらなるやる気が満ちあふれてくる。

冒頭の図はこのことをヘルスソフトウェアの開発に新規参入する技術者達に伝えるために作った。

『和風総本家　「世界のメイドインジャパンを紹介！イタリアの職人が愛用するモノとは？」　2013年12月19日　テレビ東京　より引用』

【出演者】萬田久子、東貴博、梅宮辰夫、八嶋智人、マギー　【進行】増田和也

▽イタリアのバイオリン職人が愛用する小さなノコギリ
昔ながらの手作りで作っているノコギリ職人の方が、 大手企業の「替刃式の大量生産型ノコギリ」の開発により苦境に陥りながらも 新商品の開発や販売方法の改善により、今でも伝統的なノコギリ職人を続けているという内容です。

現在はイタリアの伝統的なバイオリン「ストラディバリウス」の修復にもそのノコギリが使われているそうです。 手作りで作ったノコギリは刃が真っ直ぐで、精密な作業をするのには欠かせないそうです。 そういったように、大量生産商品に比べると価格的には負けてしまいますが、 質が良い商品は、ターゲットを選び販売方法を変えれば十分勝負ができるようになる可能性があるということが分かる番組でした。

『引用終わり』

自分は医療機器メーカーに勤めて28年、自分達が作った製品が社会に貢献していることをモチベーションにして仕事の励みにしてきた。エンジニアのモチベーションは決してサラリーだけではない。自分達の商品が社会の役に立っていると実感することが、日々を困難を乗りきる動機付けになっているのだ。

組織内ではこのことを技術系の新入社員に話すことにしているが、今はこの分野に新規参入しようとしている企業やエンジニアに話す立場になりつつある。

ただし、冒頭の図で重要なのは「社会貢献」や「ありがとう」の気持ちをもらえるのは、「優良な」ソフトウェアを提供した開発プロジェクトだということだ。

意図しない動きを平気でするようなソフトウェアではダメなのだ。このことがなかなか伝わらない。どんな分野だってプロフェッショナルとしての誇りがあるのなら、自分達の仕事に対して自信とその自信を裏付ける技術、お客さんに対する責任感を持っているはずだ。

社会貢献の裏には大きな責任がある。ヘルスユースで役に立ちたいのならば、背負うもの、身につけるべき技術があると言いたい。

でも、必要な技術を習得できればそのスキルが組織のコアコンピタンス(核となる能力)となるし、企業の体質を強化しユーザーとのつながりが強いビジネスができるようになり、不況に強く安定的な利益を生み出す基礎体力（底力）を得る。次のようなメリットがある。

• 簡単には真似できない企業の強みとなる
• 競争力が付けば差別化が図れる
• 安全なヘルスソフトウェアを作れるという自信につながる

そういうレクチャーをしても心に響かない人や、新たに身につける必要のある技術を「面倒だ。役に立たない」と決めつける者がいる。

そういう人達は結局は世界一厳しい目を持つ日本のユーザーからそっぽを向かれることになる。「どうしちゃったのか日本のエンジニア」 と言いたくなるシーンが増えている。

日本の製品の多くは今だに世界一の品質を誇っているというのに、「自分達のソフトウェアの安全を自信を持って主張できないのかよ」と言いたい。

医療系のソフトウェアに新規参入しようと考えている技術者に言いたいのは、成熟した社会は安全への対価は惜しまない、しかし、信頼を裏切る製品やサービスは市場には残れないということだ。

利益の裏側には責任が伴うということなのだ。ソフトウェアだからリスクはないと思っているのは間違いだ。このことに早く気づいた方がよい。

「何でもいいから作りゃいいんでしょ」という考え方では感謝される商品も作れないし、エンジニアとしての成長もない。

P.S.

冒頭の図の右側の4つのイラストは無料のイラストサイトからダウンロードさせてもらった。左側のプロジェクトのイラストはいい物がなかったので、有料のサイトから1点、約400円で個人的に購入した。たかが図のためと思うかもしれないが、大事なことを伝えるのに必要だという判断だ。右側のようなイラストが無料であるということは、世の中でこのようなヘルス関係のイラストの需要は多いということだ。だから、個人ユースのヘルスソフトウェアの市場は大きい。ただ、単価は高くない。だからといって、いい加減なソフトウェアを作っていたのではこの市場で生き残れない。