是正・予防駆動のプロセス改善アプローチ

ソフトウェアの開発をし商品に実装し、その商品を売って対価を得て、最終的にサラリーをもらう。ソフトウェアの一行一行の向こうには、そのソフトウェアを使うユーザー（お客様）がいる。それが医療機器などのクリティカルソフトウェアであった場合、そのソフトウェアは利用者の命を左右する可能性もある。

クリティカルでなくても、危険なエネルギーを制御したり、大切な情報を扱ったり、重要な設備を管理したりするソフトウェアもある。

ようするに職業としてソフトウェア開発に携わっている技術者はユーザーに対して何かしらの責務を負っている。これは、ソフトウェアがハードウェアと違うのは、Systematic Failures/Faults（決定論的原因故障/障害）と呼ばれる障害が多いことだ。Systematic Failures/Faults（決定論的原因故障/障害）は出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

故障や障害がランダムに発生せず、ある複雑な特定のシーケンスを実行すると必ず発生する故障や障害、それがSystematic Failures/Faults（決定論的原因故障/障害）だ。

Systematic Failures/Faults（決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去する。

そして日本人は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去のが苦手だ。

どちからというと、問題が発生した時点で修正し、個人個人が是正・予防する方が得意だ。だから、プロジェクトメンバーが入れ替わらなければ、是正・予防を繰り返すことで設計の規範が醸成され、そのプロジェクトからアウトプットされるソフトウェアの品質は徐々に上がっていく。

ところが、最近ではソフトウェアの開発をどんどんアウトソースしてしまうので、ソフトウェアの委託元では設計の規範どころか設計技術自体が醸成されないし、アウトソース先は人が入れ替わるため、是正・予防を繰り返す方法ではソフトウェアの品質は上がっていかない。

日本人が苦手な、Systematic Failures/Faults（決定論的原因故障/障害）をプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない。

しかし、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャなどは感覚だけは昔のままなので、気がついたら修正し、個人個人が是正・予防するマネージメント以外の成功体験がなく、プロセスアプローチによってソフトウェア品質が高まるというイメージがわかない。

その結果、Systematic Failures/Faults（決定論的原因故障/障害）は増加する一方で、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャはいらだつ。

これが今多くのソフトウェアプロジェクトが抱える悪循環の構図だ。

このままでは、ソフトウェアを使うユーザー（お客様）への責務が果たせない。ではどうすればいいか。

ひとつの解決策として、トップダウンでプロセスアプローチにシフトするのもいいが、日本人の得意な是正・予防で改善を進めるというのはどうだろうか。

問題が起こったら、関係者全員で問題が発生した原因を分析し、どうやったら予防できるのかを考える。これを進めていくと、当然のことながらソフトウェア開発の上流を改善しなければいけないことに気がつく。結局、プロセスアプローチを導入するという結論に至ると思うが、人から押しつけられるのではなく、改善の取り組みの中でプロセスマネージメントの重要性を学ぶ方が日本の技術者には合っていると思う。

問題が起こったときに、エンジニアを責めるのはたやすい。難しいのは問題の原因を分析し、是正、予防し、同じような問題が起こらないようなオペレーションを決断することだ。

結果を批判するだけの評論家はたくさんいるが、未来に起こるかもしれないリスクを皆に知らせ、プロジェクトを止めたり、方向を変えたりするには技術的な裏付けもいるし、何よりも勇気がいる。

ユーザーの顔を思い浮かべて、ユーザーリスクを防止するための決断ができる者こそ、プロジェクトのリーダーとなるべきだと思う。

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

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 の要求を同時に満たすことができる。

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

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

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

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

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

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

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

プリウスのブレーキ制御のソフト改変についての状況が徐々にわかってきた。

エンジニアはエンジニアらしく現象を客観的にロジカルに考えて、憶測の部分は憶測として断りを入れながら語っていきたい。

まず、問題を分析する前に、ABS（アンチロック・ブレーキ・システム）についておさらいしておく。

Wikipedia によれば、ABSの構造はこうだ。

1. ブレーキペダルを踏むことによって、油圧発生装置 (2) から油圧配管 (5) を通じて油圧がブレーキキャリパ (4) に伝えられ、ブレーキバッドがブレーキディスクに押し付けられて制動力が生じる。
2. 制御装置 (1)は回転センサ (3) により車輪の回転をモニターしており、他の車輪が回転しているのにこの車輪だけ回転していないことを検出するとブレーキがロックしたものと判断し、油圧発生装置 (2) から発する油圧を下げる。
3. 油圧が下がると制動力が弱くなるのでブレーキロックから復帰する。
4. ブレーキロックから復帰すると車輪の回転が生じるので制御装置 (1) は回転センサ (3) によりブレーキロックではないと判断し、油圧発生装置 (2) から発する油圧を上げ制動力を強くする。

制御装置 (1) は、この一連の操作を数ミリ秒という短時間で行うため、運転者がポンピングブレーキを行うよりも高精度な制御が可能となる。

この説明が難しいと思ったかたは、ABSが非常に分かりやすく解説されているページも見つけたのでこちらもどうぞ。

ハイブリッドではない車で油圧ブレーキ+ABSの組み合わせであれば、この説明の機能が正しく動作していており、技術も枯れているから問題はない。

つぎに今回のプリウスの問題について、正確と思われる技術的な情報を見てみよう。

以下は2010年2月5日現在の最新の情報を正確に表していると思われる記事（中日新聞）である。元ネタはトヨタの品質保証担当役員 横山裕行常務 の記者会見である。

【中日新聞：『トヨタ、ブレーキ欠陥を否定　プリウス苦情で会見』より引用】

プリウスはガソリン車と同じ「油圧ブレーキ」と、ハイブリッド車特有の「回生ブレーキ」を併用。走行状態に合わせ、自動的に車自体が最善の組み合わせを選ぶ仕組みだ。
ただ、凍結など滑りやすい路面で車体をコントロールするアンチロック・ブレーキ・システム（ＡＢＳ）が作動すると、回生ブレーキとの併用から油圧ブレーキ単独への切り替えに、時間差が生じるという。

【引用終わり】

もう一つ、朝日新聞より追加情報

【朝日新聞：『トヨタ、新型プリウス全車を無償改修へ　欠陥は認めず』より引用】

多くは、滑りやすい路面を低速で走行中、１秒前後、ブレーキが利かなくなるというもので、トヨタの調査では、車輪がロックしてハンドル操作が不能にならないようにするアンチロック・ブレーキ・システム（ＡＢＳ）の制御ソフトの問題という。

【引用終わり】

これ以外の NHKのニュース等も総合すると次のようなときに起こる現象のようだ。

回生ブレーキが効いているとき（減速中）にブレーキを踏んで油圧ブレーキに切り替えわろうとする際、たまたま路面が滑りやすい状態であるとABSを効かせる（切り替わる）のに約1秒かかる。

ここからは憶測が入る。

この問題では「回生ブレーキ」と「油圧ブレーキ」と「ABS」の3つの機能の微妙なバランスが絡み合っている。そもそも「油圧ブレーキ」単独のシステムは非常にシンプルで正しく動いていることもテストしやすい。

つぎに、「油圧ブレーキ」+「ABS」の組み合わせは冒頭のABSの仕組みを見てもらえればわかるように結構複雑であり、ソフトウェアの制御が入ってくるが、ガソリン車においてすでに枯れた技術となっている。

ハイブリッド車における「回生ブレーキ」と「油圧ブレーキ」の切り替えはさらに難しいソフトウェアの制御になっていると予想される。しかし、それが難しいのはトヨタだってホンダだって分かっていて、徹底的にテストしていたと思う。一節によると、トヨタは新しい技術の検証には5年以上かけているらしい。

だから「回生ブレーキ」と「油圧ブレーキ」の切り替えは正常に動いていて、例えば坂道で減速中に回生ブレーキが効いている状態で、運転者がブレーキを踏むとタイムラグなく油圧ブレーキに切り替わるのだろう。

同様に、「油圧ブレーキ」＋「ABS」の組み合わせもガソリン車で培った長年の技術の蓄積があるため枯れており問題はなかったのだと思う。

しかし、今回の状況は「回生ブレーキ」と「油圧ブレーキ」と「ABS」という3つの要素の境界領域の問題であり、レアなケースのように思える。ソフトウェアの機能のテストを考えるときに、一つのシステムのテストが100項目だったとする。2つの機能を組み合わせるとテストケースは1万になる。3つの機能を組み合わせるとテストケースは100万だ。100のテストはちょっと頑張れば検証可能。1万のテストはシステマティックにやならいと漏れが発生する。100万のテストはどんなに頑張っても漏れや抜けが出る。

もう一つの憶測は、「回生ブレーキ」チームと「油圧ブレーキ」チームと「ABS」チームが別々だった場合、それぞれのサブシステムの完成度は高くても、各サブシステムを組み合わせたときに想定される問題の追求には他のチームへの遠慮があるため徹底的に突っ込めない、突っ込みがあまくなる可能性だ。他のチームにケチをつける、すでに枯れていると思われるシステムをバラバラにする、疑いを持って検証のし直しを迫るのは勇気がいる。そこに遠慮があるとテストに漏れがでる可能性もある。

「回生ブレーキ」から「油圧ブレーキ」もしくは「回生ブレーキ」から「ABS」への切り替えに1秒かかるというのはあきらかに遅い。当初エンジニアが意図していた性能要求からは外れていると思う。

結果的に回生ブレーキが効いている減速中にしか、1秒の切り替えディレイが発生しないのであれば、ユーザーリスクは小さいのかもしれないが、100Km/h 以上の高速走行中に減速して回生ブレーキ中に滑りやすいところに入って思いっきりブレーキを踏んで油圧ブレーキが効くのに1秒かかったら、制動距離に変化はないとは言えないだろう。

Wikipediaによると、そもそも、ABSには下記のような注意点があるようだから、さらに問題の現象は複雑になる。

凍結路面（凍結状況によって左右される・ミラーバーンでは制動距離が延びる場合がある）や砂利道などの非舗装路面などではABSを解除した状態の方が制動距離が短くなる傾向が強い。理由の一つに、ABS作動時は一時的にせよタイヤが空転するからである。
凍結道路において乾燥路面と混在状態の時は、制動距離がABS非作動時の倍以上になることがあるので、低速走行時（時速40 km以下）においてはABSが自動的に解除される機構が必要である。

また、ABSはタイヤがロックしているかどうかを関知するセンサは最近は4輪独立しているらしいので、その点もソフトウェアを複雑化させているのかもしれない。

複雑化したシステムの境界領域の問題は、これからますます増えてくる。だからこそ、安全アーキテクチャを実践するにはシンプルな構造を目指すのが不可欠なのだが、だからといって機能を削ることは許されないのが現実だ。

ハイブリッド車において、回生ブレーキをあきらめればブレーキシステムはガソリン車と同じ構造になり枯れた再利用資産を使える。しかし、燃費向上のためには回生ブレーキも使わないといけない。安全のためにエコを捨てることは社会やユーザーが許してくれない。だからこそ、トップダウンの安全アーキテクチャ解析が必要になってくる。

ところで、ソフトウェアが絡んだリコールの問題、大企業で社会が注目しているリコールの処理の難しさは、一度改修を行ったら、同じ問題で二度三度とリコールを繰り返すことはできないということだ。そんなことをしたら信用ががた落ちになるだけでなく、マスコミから一斉に叩かれる。

だから、今トヨタと関連会社の一部のエンジニアは、この問題の検証と、これ以外にも問題がないかどうかここ数日間、徹夜で働いているに違いない。

安全や信頼は、表面に見えているところ以外にも幅広くケアしておかないと保証できないという事実をエンドユーザーやマスコミは知らない。

マスコミや評論家は何か問題が起こったときにはみんなで大騒ぎするが、同じような別な問題はないか、違うシチュエーションでは発生しないのかといった、隠れている部分を洗い出す力はない。

クリティカルデバイスに携わるエンジニアは見えないところの問題も改善する道筋をつけていかなければ、潜在的な価値（当たり前品質）を高くキープし続けることができないのだ。

サブシステムの完成度を高めても、単純にサブシステムを結合したのでは安全は保証されないということをこのブログで言い続けている。もしかしたら、今回のブレーキ問題はその例のひとつなのかもしれない。

P.S.

その後日経ものつくりにこんな記事が載っていた。

新型プリウスはABSが動作してから油圧ブレーキが作動するまでの時間が従来型に比べて若干長く，このことがドライバーに「ブレーキが利きにくい」と感じさせていたというのが同社の見解だ。同社に寄せられたブレーキが利きにくいという現象は，基本的にABS動作時にだけ起きるものだという。また，そうした現象が起きたとしても，フットブレーキを十分に踏み込めば問題なく停止できると横山氏は説明する。
改善策としてABS動作後に油圧ブレーキが動作するまでの時間を短くした。

• 若干が1秒だとしたら長い。人間が我慢できるレスポンスの限界はだいたい500ms。
• たぶん、回生ブレーキ動作中でない場合は反応が早い
• ABSはロックしないための機能だから、ABSの動作と油圧ブレーキの作動は同じ事を意味しているはず。正確に言うと、回生ブレーキがかかっているときにABSが動作するまで1秒かかっていたので、その時間を短くした？
• ソフト修正前と後では制動距離が異なるのではないだろうか？ ソフトの修正で制動距離が短くなっているのなら・・・

さらに、こちらの記事（一番参考になる）によると、ブレーキの踏み加減によってABSの効かせ方を調節している可能性がある。結果的には、単純な単機能の油圧のディスクブレーキの時代から比べたら遙かに複雑なソフトウェア制御の時代に変わっており、安全アーキテクチャ分析をしないと安全は確保できないところまで来ているということだろう。MISRA-SA （MISRA Safety Analysis）の出番かもしれない。

プリウスの場合は低速でブレーキを踏むと回生ブレーキのみで制動する。（この時油圧ブレーキは作動していない）
その状態でABSが作動するような状態になると、回生ブレーキを切って油圧ブレーキに切り換えABSを作動させるんだが、この切り替えに1秒程度かかる。すなわちその1秒間は何のブレーキも効いていない状態になる。

という記事も発見。回生ブレーキが作動する低速というのがどれくらいのスピードまでかが問題。回生ブレーキになる最大のスピードでの1秒間でどれくらい制動距離が伸び、ABSが働くのに時間がかかることで車の姿勢が崩れないのか否か。

CAPAができていない組織の先行きは危うい

CAPA （Corrective Action and Preventive Action：是正・予防措置）とは問題が起こったときに再発を防止するための考え方である。

【CAPAのプロセス】

1. 問題点を明らかにする
2. 是正アクションの実行
3. 類似した問題が起こらないようにするための予防アクションの実行
4. 予防アクションのデータによる検証

いたって当たり前のように見えるが、これが組織的にはなかなかできない。日本では「問題点を明らかにする」と「是正アクションの実行」を個人的にやるところまでしかいかないことの方が多いように思う。

組織的に再発を防止するためには「類似した問題が起こらないようにするための予防アクションの実行」と「予防アクションのデータによる検証」が必要だ。CAPAはシステマティックにやらないとうまくいかない。犯人捜し、個人攻撃のような様相を呈するようになると、みんな積極的に動かなくなる。

基本的には問題が起きたらQA（品質保証）担当が、淡々と実施していくのだが、日本人は過度にミスを犯したことを追求したように受け取ってしまうため、次回からは自分が気をつけて類似問題を起こさないようにするだけで、組織的予防処置まで行動が広がらない。

自分のミスをさらしたくないという恥の文化もあってそうさせているのだろう。

しかし、それでは組織的な対応としてはまったくできていない。関係部署がそれぞれの責任のもと、再発防止策を考え、実施し、検証することで、組織内に是正策が定着する。

このブログで欧米発の方法論をそのまま鵜呑みにするのは良くないと言っているが、CAPAは欧米発の考え方でよいシステムだと思う。

でもよくよ見ると CAPA はQC活動、カイゼン活動とよく似ている。最大の違いは、QC活動では問題点を自分達で抽出して、自分達で再発防止策を考え実行する。他のチームにその改善策を押しつけることは基本的にしない。（と思う）

他人から言われたからやる、のではなくあくまでも自浄能力を高めようという精神が根底にあると感じる。

ところが、今ではその自浄能力はすべてのチームにはない。そうなると組織的に問題に取り組み是正予防策を共有する必要がでてくる。責任と権限のもとルールを作ったたり、変えて、そのルールを守っていくということも必要になってくる。

CAPAのしくみがあるのにこれが形骸化している組織は最悪だ。チームには問題が見つかり外部から指摘されたら、本来は「問題を見つけてくれてありがとう」という気持ちで再発防止策に取り組む必要があるのだが、CAPAが形骸化している組織では「ああ、めんどくさい」「早く収束させて仕事に戻りたい」となる。

QC活動、カイゼン活動を普及させて自立的に乗り切る方法と、組織がシステマティックにCAPAを回す方法と現代の日本の組織には両面の活動が求められていると思う。

今起こっている問題を解決することよりも、再発防止に重きを置いている組織の未来は確固たるものがあるように感じるが、是正・予防に力が入っていない組織の先行きは危ういと思う。

　

見える化、見せる化、そして、見られる化

かつてこのブログで『組込みソフトは「見える化」より「見せる化」』という記事を書いた。「見える化」というのはよくよく考えてみると隠れているものを見せたいのか、見られたいのかはっきりしない。実際の問題を抱えた現場にとって「見える化」ということばはいわばきれい事のように思える。

ソフトウェアの世界で「要求仕様が見えない」「設計思想が見えない」「アーキテクチャが見えない」「インタフェースが見えない」「どこが再利用されているのか見えない」「そのモジュールの開発やバグ取りにどれくらい費用がかかったのか見えない」といった問題が蔓延している。

かつて「見える化」より「見せる化」と言ったのは、プロジェクトサイドがポジティブに見えないものを見えるようにして、悪循環を脱するために踏みだすべきだという意味だった。

しかし、問題を抱えているプロジェクトは必ずしもポジティブであるとは限らない。いや、どちらかと言えばネガティブなことが多い。そういうプロジェクトは「見せる化」どころか「見せないように」「見られないように」さえ振る舞うこともある。苦しい内情を知られてより強いプレッシャーをかけられるよりも、現状を隠して取りあえず今降りかかっている嵐をしのぎたいという心理だ。

ただ、残念ながらこのようなアプローチを繰り返しているとプロジェクトは徐々に疲弊し、モチベーションが下がり、長期の視点で改善の活動ができなくなっていく。

そのようなプロジェクトに対して必要なのは、「見られるのが普通のこと」という状況に持って行くことだ。ソフトウェアエンジニアは誰もがある程度の権限を得ると、自分のやりたいようにプロジェクトを運営したいと思う。その気持ちは、外部から余計なことを言われないように知られたくないことは見えないようにしておこうという行動を誘発する。

そのような状態でプロジェクトを放置していくと、「やってることはやってるんだから、文句は言わせない」という非常にわがままなプロジェクトになってしまう。このようなプロジェクトに対して、問題点を指摘し是正や予防を要求するのはやっかいだ。

解決方法は、プロジェクトに常に「見られていることを意識させること」だ。どのプロジェクトもみな、同じような環境で見られているという意識が広がると、自分達の行動に自覚を持つようになるし、外部からの指摘に過剰反応しなくなる。

そういう意味で「見える化」ということばは、改善を受け入れるか、拒絶するかといった真剣勝負からほど遠い甘っちょろい台詞に聞こえる。「見せる化」は、プロジェクトの「文句あるなら言ってみろ」という自信の現れでもある。そんな自信がないプロジェクトに対しては「見られる化」を定着されなければいけない。

よっぽど強靱な精神力を持ったプロジェクトでなければ、常に見られているということが必要であり、見られているという状態は、自分達の行動に自信を持ち、責任を持つというステージに導くために役立つのである。

ソフトウェア開発における暗黒面の誘惑

『西洋の真似をするだけというのはそろそろやめよう』の記事に ssw さんから以下のようなコメントをもらった。

初めまして。共感する記事だったので、サムライエンジニアの話も読んでみました。

仰る武士道エンジニアは、私の知る限り多くの場所にいました。しかし、成果を上げる能力を持った誠実なエンジニアほど、業界を去る例が多いように思っています。いくら注意してもバグやトラブルで切腹を余儀なくされる侍に重なって見えないでしょうか？

私も侍エンジニアを目指したいと思いますが、SW風に言う暗黒面の誘惑を断ち切れず、過剰防衛や飛び道具を捨てられません。もうちょっと修行が必要なようです。

面白い記事ありがとうございました。

sswさんの言う「暗黒面の誘惑」はソフトウェアの世界では特に多いように思うので、今回はソフトウェア開発における暗黒面の誘惑について考えてみたい。

ソフトウェア開発は「見えない」とよく言われる。だから「ソフトウェアの見える化」が大事であるとよく言われる。ソフトウェア開発が外から見えない状態ではソフトウェア開発における暗黒面の誘惑を減らすことはできないが、ソフトウェア開発を見えるようにしただけでは暗黒面の誘惑を断ち切ることはできない。

本題に入るまえに、ソフトウェアが原因となった事故とその事故を詳細に調査したナンシー・レブソン教授（現 MIT教授）のことばを見て欲しい。

【放射線治療器 Therac-25 の事故】

1985年～1987年 セラック25による事故。複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者（6名）がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソンらの努力により事故原因が詳細に調査され、レポートが発表された。このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられている。

英文ではあるが次のアドレスからレポートを読むことはできる。

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

http://sunnyday.mit.edu/papers/therac.pdf

ここでは、事故を調査したナンシー・レブソン教授のいくつかのことばを見ていただきたい。

• どんなに慎重に作ってもソフトウェアは満足できるほどに完璧にはならないため、ソフトウェアがどんな動きをしたときでも、人命に危険が及ばないようにシステムを設計する必要がある。
• ソフトウェアの信頼性をできるだけ高めるのは悪いことではないが、それでソフトウェアが安全になるわけではない。プログラマは要求を満たすようにコードを書くが、要求が正しいとは限らない。事故のほとんどは、プログラミングのエラーではなく、要求が間違っていたり、不完全であったりしたために起きている
• われわれの目標は、だれもがこの経験を生かせるようにすることであり、装置のメーカーや他の人を批判することではない。間違いは、このメーカーにだけ起きたのではなく、残念ながら、安全が最優先されるべきその他のシステムにも、きわめて日常的に起きている。
• いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。

これらをことばを聞いて思うのは、Therac-25 の事故から20年以上たった現在でもソフトウェアに関する問題は何も変わっていない。20年間の間進化したであろうソフトウェアシステム、ソフトウェア開発の方法論はソフトウェアに起因するこのような危険を回避できていないということだ。20年間技術が何も進化していないのはない。いろいろな技法、手法を使ってソフトウェアを作るのは人間であり、ソフトウェアの設計は人間が行っているのであり、安全なソフトウェアはナンシー・レブソン教授が事故調査で痛感した教訓を技術者が十分に理解し、意識し、設計の規範を組織が先輩が後輩に伝承させなければいけないことを20年もたっているのに多くの人が理解していないということである。方法論が先行して、目的が忘れ去られ、結果的にソフトウェアを作っているのが人間であるということが置いて行かれてる。

ナンシー・レブソン教授が残した「いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。」ということばについて考えてみよう。

ソフトウェアに関する問題が起こったときの分析者の問題分析の仕方、分析能力の低さに愕然とすることがある。一番多いどうしようもない指摘の仕方は、ソフトウェアにおける問題が発生したときに、原因を一通り担当技術者に説明させ「そのプログラムは一体誰が作ったのだ」と問いただし、問題の原因をそのプログラマの「うっかりミス」ということで帰結してしまうケースだ。

「プログラマのコーディングミス」。この原因ほど結論づけるのが簡単なものはなく、「プログラマのコーディングミス」が問題の原因であると結論づけるような組織は Therac-25 のような事故を起こす可能性が高い。

「プログラマのコーディングミス」を問題の原因とするのは、問題の分析者がソフトウェア開発の十分な経験を持っていないからだろう。ソフトウェアのことはよく分からないから、誰かのせいにしてしまうのが一番簡単なのだ。品質保証担当は問題の原因を特定し、再発防止策を指示する責務を持つ。だから、ソフトウェア開発の経験を持たず、品質保証についてスキルを高めることを怠っているQA担当は、問題が起こると、原因を聞いても内容がよく分からないから、誰がバグを作り込んだのかを特定し、そのプログラマに何かしらの教育を行うことで再発防止策としようとする。

ナンシー・レブソン教授が言う「事故の原因を一つに特定することは、大きな間違いだ。」を思いっきりやってしまっている。

かなり昔のことだが、ソフトウェアに関する問題が起こったとき原因が「境界値テストが十分でなかった」という報告が現場から上がってきたことがあった。「プログラマのコーディングミス」となっていないだけよいと思うが、「境界値テストを行っているかどうかを水平展開しチェックしろ」というおふれが回ってきた。

「チェックしろ」というのは「うちは境界値テストはやっているのか」という問いに対して「・・・はい、たぶんやっていると思います」という答えでもよしとしてしまうレベルのチェックである。当時、この話しを聞いたときに、組織の上位層はいかにソフトウェアのことをブラックボックスとして見ているのか、ソフトウェアの品質を評価する客観的な指標を持っていないと思った。

境界値テストというのは、システムやサブシステムやソフトウェアユニット（関数やクラス）に対する入力に範囲があったときに、その範囲の最大値や最小値、範囲の外側の入力を与え、期待通りになるかどうかをテストすることだ。

しかし、システムレベルでの入力に比べて、ソフトウェアユニットレベルでの入力値は非常に多いし、入力に対して同じ出力がでるとは限らない場合もある。入力に対して同じ出力がでないのは、外部の関数とグローバルな変数を共有している（外部結合：External coupling または、共有結合：Common coupling) ようなことがあるからだ。組込みソフトウェアの場合、外部の状況をセンシングして、センシングした内容によって、システムの振る舞いを変えることがあるから、出力値が入力データだけで決まるデータ結合になっていない関数やモジュールが少なからずあるのだ。

仮に、データ結合(Data coupling)だけの関係を持つ関数 1000個で構成されるソフトウェアシステムがあったとしよう。1000個の関数に引数がそれぞれ3つずつあったとする。関数一つに対する入力値の境界値テストは最低でも6のテストケースが必要だ。したがって、すべての関数に境界値テストをすると6000のテストケースが必要となる。

「うちは境界値テストはやっているのか」と聞かれたら、「今回開発しているソフトウェアシステムの関数は現在1000であり、それぞれの関数の引数の合計は3000で、各引数に対して取り得る範囲の最大値と最小値の入力テストを実施しています。」と答えるのが回答例となるが、この答えもこのシステムの安全性や信頼性が高いかどうかの根拠として完全ではないと、ベテランのソフトウェア技術者の方なら感じると思う。

そもそも、境界値テストが不十分で問題が起こったのであれば、プロジェクトに対しては「うちは境界値テストはやっているのか」などというミクロな質問をするのではなく、「うちのソフトウェア開発における安全性や信頼性の評価指標は何か？」と聞いた方がいい。この質問に明確に答えられないプロジェクトは、「どうなればソフトウェア品質が確保されている」をいう評価指標を持っていないということだから、日程のプレッシャーに負けて、問題が残ったままのソフトウェアをリリースしてしまう危険性が高い。

※さらっと「ソフトウェア開発における安全性や信頼性の評価指標」を持っていないといけない書いたが、実はその評価指標を確立することは簡単なことではない。評価指標を確立することは非常に難しいし簡単な指標にしてもキチンとできてることを内外に示すのにどんなに苦労することか・・・

もちろん、完璧なソフトウェアを作るために検証を続けていたら、時間がいくらあっても足りないから、どこかでベースラインを切る必要はある。しかし、どこでベースラインを切るか、どうなったら品質が確保されたと言えるのかという評価指標はあらかじめ開発の上流で決めておかなければいけない。

だから、「うちは境界値テストはやっているのか」と聞くのではなく「今回の問題を考えたときに、うちのソフトウェアの開発計画における品質の評価指標を見直す必要はないか？」と問うべきなのだ。

上がこんな感じだと、下は「何か問題が起こっても簡単にごまかせる」と思ってしまう。これが、ソフトウェア開発における暗黒面の誘惑だ。「上はどうせソフトウェアのことなんかこれっぽっちも分かっちゃいないから、適当な理由をつけていい訳しておけば、この場の辛い立場を逃れることができる」と考えてしまう。

「ソフトウェア開発における暗黒面の誘惑」の結果、もっとも悪い台詞はクライアントサイドの場合は「それは○○外注さんのミスです。」「○○外注さんにはきつく言っておきます。」であり、サプライヤーサイドの場合「あんなに納品を急がされたらミスもするよな。」といったものではないだろうか。クライアントサイドの台詞は自分達の問題として受け止めずに、サプライヤーに問題の責任を先送りして、根本的な再発防止策を取っていないから罪は重い。

「ソフトウェア開発における暗黒面の誘惑」をなくすことが難しい理由は、ソフトウェアに関連する問題やその原因、責任をごまかすことが簡単だからだと自分は考えている。

「ソフトウェア開発における暗黒面の誘惑」を断ち切るため是非、次のことを考えて欲しい。

【ソフトウェア開発における暗黒面の誘惑を断ち切る方策】

• 不具合や問題が発生したら正面から向き合い、プロジェクトとして再発を防止するための方策を関係者全員で深く掘り下げて考える。（個人の責任にしない）
• 再発防止策（設計の規範）はプロジェクトが始まる前にメンバ全員で確認し、規範に対する逸脱が見つかったら注意を促す。
• 誰のために、何のためにソフトウェアを作っているのか日々考えておく。
• ソフトウェアの開発フェーズによって気持ちを切り替える。集中的なテストを実施した後、リリース後のソフトウェアの変更に対する責任の重さはとても重いことを忘れない。

「あたたかい人間関係の中のやさしい一員」の日本人には苦手かもしれないが、ソフトウェア開発における暗黒面の誘惑を断ち切るためには、プロジェクトリーダーの「品質を気にする意識」に関するリーダシップが不可欠であることがお分かりいただけると思う。

ここ何回かの記事を読んでいただければお分かりかと思うが、日本のソフトウェア開発はシステムと職人気質の両立が必須の世界であり、どちらかだけに偏っていては大規模、複雑化するソフトウェアを高品質に保つことはできない。ソフトウェアの品質の高さを維持することができなければ、日本の組込み機器は世界で生き残ることはできない。

ソフトウェア開発は「見えない」ことの問題よりも、ソフトウェアの安全性や信頼性について「自分はよく分からない＝見ない、見たくない」とあきらめ、「問題を理解して確信を持って判断すること、責任を取ること」を放棄する人間がたくさんいることの方が本質的な問題であると思う。ソフトウェア開発における暗黒面の誘惑に負けると、暗黒の力に支配されてしまっていることさえ忘れてしまうから怖い。