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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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