2011-03-27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2011-03-20

安心・安全を担うソフトウェアを実現するには

東北関東大震災で被災された皆さまにお見舞い申し上げます。

このブログで自分自身の業務ドメインについてクリティカルデバイスのソフトウェア開発を行ってきたと書いてきました。クリティカルデバイスとは医療機器のことです。これまで、ブログの記事投稿や外部における発表において自分が所属する業務ドメインを明らかにしてこなかったのは、サラリーマンであるにも関わらず、25年間務めている現在の組織のノウハウを漏らしているかのようなあらぬ疑いをかけられるのがいやだったからです。

しかし、今回の震災に東京地区で遭遇し、さまざまな苦難に多くの日本人が自分ができることを考えているのを見て、自分が社会に対してできるのは医療機器ソフトウェア開発で得た経験により、安心・安全を担うソフトウェアはどうすれば実現できるのかについて情報を発信することだと思いました。

もちろん組織内の情報を外に出すことはこれまでも、これからもありませんが、組織の利益以上に、社会への貢献について自分ができることを考えていきたいと思っています。

さて、東京電力福島第一原子力発電所の事故を見て、多くの方達は「なぜ、今回のような事態が起こることを想定しなかったのか」と思われているでしょう。

私は、商品やサービスの価値には「顕在的な価値」と「潜在的な価値」の両面があると思っています。「潜在的な価値」は当たり前品質と言い換えることもできます。できていて当たり前なので、何かのアクシデントが起こると「潜在的な価値」がとたんにクローズアップされます。

世の中の多くの商品やサービスでは表面に表れている「顕在的な価値」、例えばカタログに掲載されているようなスペックに消費者は着目しますが、「顕在的な価値=当たり前品質」に着目する人はそう多くないと思います。

しかし、私のような医療機器のドメインや社会インフラを実現している産業ドメインでは、この「顕在的な価値=当たり前品質」を軽視することは絶対にできません。なぜなら、そこに問題が起こるとお客様に多大な迷惑をかけたり、最悪の場合、健康被害をもたらしてしまう可能性があるからです。

そうならないために、私たちはリスク分析をし、ユーザーリスクを軽減するための対策をハードウェアやソフトウェアにインプリメントするのですが、それでもさまざまな問題は発生します。そして、リスクをコントロールすること以上に重要なのは、問題が起こってしまったことに対する原因の追及と同じ過ちを繰り返さないように是正し、予防する処置を行うことです。

エンジニアは顕在的な価値を高め、期せずして発生してしまった問題に対しては冷静に再発防止の対策を粛々と実行しなければいけません。

日本のエンジニアは長い間同じ商品開発に携わることが多いため、安全や信頼を実現するためのノウハウが技術者個人に蓄積しやすいと感じています。この状況は開発するソフトウェアの規模が小さく、複雑でなく、かつ技術者の安全実現への熱意が強い場合には有効に働きますが、実行コード行数が30万行を超え100万行以上の規模になったソフトウェアでは有効ではありません。

ソフトウェア開発プロセスを組織的に管理し、品質マネージメントシステムのもとで是正、予防も実施していかなければいけません。長い時間エンジニアの熱意や責任感と職場内で継承されてきたノウハウで安全を確保してきた日本のプロジェクトには開発プロセスで品質を確保するというアプローチは受け入れがたいことでもあります。(建前では受け入れつつも本音では役に立たないと思っている者は多いと思っています)

習慣化してしまった日々の仕事のやり方はそう簡単には変えることはできません。そして、プロセスアプローチを強固に推し進めてきた欧米の製品よりも、日本製の製品の方が品質が高いというケースも少なからずあります。しかし、その状況は長くは続きません。ソフトウェアの規模や複雑性が増大し、機器同士がネットワークでつながるようになると、これまでうまく回ってきた日本的なアプローチは徐々にほころびを見せてきます。

しかし、だからといって技術者の安心・安全実現に対する熱意なしに、クリティカルデバイスの品質確保はできないと思います。日本的なアプローチと欧米的なアプローチの両方を推し進めることで、安心や安全が確保できるのです。

話しは変わりますが、2011年2月10日に「ソフトバンク 医療分野におけるスマートフォン活用に関するセミナー」、2011年2月28日日経ものづくり主催の「医療機器開発の勘所」セミナーに参加しました。

前者は、医療分野において、iPad や iPhone などの IT機器を導入して、実際に活用している例を、後者は、グローバルマーケットにおいて日本から世界に医療機器を開発・販売していくためにはどのような責務を果たさなければいけないのかについてのレクチャーでした。

IT(ソフトウェア開発の意味も含む)は確実に医療の世界をより便利に、より効率的にすることができると感じました。しかし、使いやすさ、便利さといった顕在的な価値の後ろで、潜在的な価値=当たり前品質を維持し続けなければ、機器やシステムを安心して使うことはできません。

安全や安心にはコストがかかります。私たちは安全や安心のためにそのコストを負担しますが、特に日本人は消費者として厳しい目を持ち、その上で安全や安心に対するコストを支払います。安全や安心にかかるコストを値切ったりすることは少ないと感じています。

だからこそ、安全や安心を担うソフトウェアを開発しているエンジニアはその期待を裏切らないようにいい仕事をしなければいけないのです。私は、最近の技術者は納期のプレッシャーに負けて、安全や安心に対する責任から逃げたいと思う弱い気持ちが大きくなっているように思えてなりません。

そういうときに、私は「何のためにこの仕事をしているのか」ということを技術者に問うようにしています。消費者の皆さんには無理なお願いかもしれませんが、日頃、何事もなく動いているシステムを見たら、「これはどうやって動いているのだろうか」と気に掛け、何事もなく動いて役に立っているシステムを見たら、それらのシステムを作り上げた誰だか分からぬ技術者達にほんの少し感謝の気持ちを持って欲しいのです。

そのほんの少しの感謝の気持ちが技術者のモチベーションを高め、安心・安全をさらに強固にするためのインセンティブになると思っています。

私自身はそのようなシステムを実現するために、日本の技術者やプロジェクトが何をすればよいのかについて、自分自身の25年の医療機器ソフトウェア開発の経験を元に情報発信していこうと思います。