ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ！

ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ！
今こそ「それは本当に役に立つのか」と問いかけろ！

自分達が作っているソフトウェアの品質は十分に高いのに、余計な要求を突きつけられて無駄なことをやらせていると思っているエンジニアはいないか。

そもそも、ソフトウェアの不具合は発見しにくいし、どの工程でも入り込んでくる可能性がある。だから、プロセスアプローチで相対的に対処しようとするのは分からないでもない。

でも考えて欲しい。それは、ルールと責任を重んじ、システムやツールを使いこなすことを得意とする欧米のやり方ではないか。

品質を心配する意識が強く、製品のライフサイクルを通じて同じ技術者が考え、問題にすばやく対処し、ルール化せずとも不具合の再発防止を継続的に実現できる日本のソフトウェアエンジニアに、もっとも有効なやり方か？

そして、規格適合の実態のばかばかしさ。本当に役に立つのかどうかの根拠が明白でないままに、規格のその要求に適合できないことは悪だとばかりに、責める認証機関やコンサルがいる。

彼らには、規格は金を生む宝であり、バイブルなのだ。

問題は規格そのものよりも、規格を認証する制度の問題だ。プロセス規格の場合、規格に適合できているかどうかの判定の白黒が付きにくい。だから、プロセス規格の適合を取ると決まったら、監査管、審査官のさじ加減で各要求のレベルが上がったり下がったりする。試験方法が明白な電気的安全性の試験などと違って、監査管、審査官の裁量に委ねられることも多く、適合している、していないで攻防をする結果、適合していることを示す明確なエビデンスがないことが不適合の根拠となる。

その結果、日本の企業では監査で実質的に出来ているのに、ルールやシステムの整備が十分でなく、承認されたエビデンスがないことがよく指摘される。

そういう状態で是正事項を指摘されると、表面的に取り繕うことが目的になっていく。中身はどうでもいいから手順と証拠があればいいという方向に流れていく。

だが、待て！　そもそも、その指摘は手順があって、ルールに縛られないと品質を担保できない者達へのアプローチではないか。

手順やルールがなくても、上司に言われなくても、問題があれば自助努力で解決できるチームには余計なお世話ではないのか。

ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ！もしも、その疑問が心の中に浮かんでいるのならば、今こそ、「なぜ」それが必要なのかを考えろ。

納得できる答えを見つけてから、動こう。「なぜ」それが必要なのかをチームでディスカッションしよう。

認証機関にも聞いてみよう。（認証機関はコンサルしてはいけないルールになっているので、答えることができないという言い訳をするかもしれないが）

コンサルにも聞いてみよう。この取り組みはどうして品質向上につながるのか。もしも、「規格で要求されているから」と答えたら、張り倒そう。

なぜなぜ分析って、知ってる？　問題が起こったときの根本原因を掘り下げるときによく使うけれど、今こそ、使うべきだ。なぜ、その規格を適合すると品質が向上するのか、安全になるのか？

無駄だと思ってやっていると、日本の組織では力にならない。最初の図にある「品質を心配する意識」に語りかけないとダメだ。今やっていることが役に立つという確信を持てれば、ガチガチのルールにしなくても、チームは率先して受け入れて効果も上がる。

ルールや責任ばかり強調して、システムやツールに頼ろうとするのは、欧米ではうまくいくかもしれないが、日本ではうまくいかないだろう。

なぜなら、ソフトウェアを作っているのは人間であり、人間や人間の集まりであるチームはその気質によって考え方や慣習が異なるからである。

欧米中心で作られた国際規格が日本のプロジェクトにフィットしないシーンはたくさん見てきたし、欧米振興の日本人が国際規格を神格化しているケースもある。

みんな、自分達のソフトウェアの品質が諸外国のそれらより劣っていると思っている？　そう思っていないのに、いいなりなんだ。

人が働ける時間には限りがある。「あの人はいい仕事をした」と後々言われるような仕事をしよう。

誰にも誇れる仕事、自分にも他人にも嘘をつかない仕事、エンドユーザーに役に立つ仕事をしよう。エンドユーザーにとっての価値が下がるような結果にしては絶対にいけない。（品質は上がらず、コストだけが上がったというのもその一つ）

コメント募集中！