開発プロセス
ソフトウェア開発
ソフトウェア工学
システム工学

あるビジネスニュース

あるビジネスニュースの中の発言だった。
「△△の経済効果は、△△を見にやってくる人の入場料・交通費・宿泊費・その期間の食費だけではありません。
その食事に用いられた地元の食材の費用もあります。このように△△の経済効果は実に幅広いのです。」

典型的なダブルカウンティングだ。△△を見に来た人が、食費を払っていれば、その中に既にその食事に用いられた地元の食材の費用も含まれている。
 にもかかわらず、「その食事に用いられた地元の食材の費用もあります」というのは適切ではない。

このような発言をする人は、このようなダブルカウンティングをしてはいけないということを知らない人か、知っているにもかかわらずそのように述べている人だ。

不誠実な発言

「円安になると輸出が増加する」と今の時点でも言っている人も同類である。多くの工場が海外に進出してしまっていることや、価格以外のところで差をつけられてしまっている分野が増えてきていることを無視して、教条主義的に「昔は正しかった答」を繰り返す。

「日本は技術が高いのに」と分野を限定せずに言っているのも同様だ。コンピュータ言語で日本から発信されて普及したのは、ほぼ1つに限られる。初めてノートパソコンを作ったときの企業は技術が高かった。しかし、先に進むことを止めてしまった時期の企業をそう呼ぶことはできない。

知っているにもかかわらず、そのように述べている人は、自分にとって都合のいいようにねじ曲げて伝えても構わないと考えている人だ。
「自分のためじゃない、組織のためだ。」というかもしれない。上司や組織をかぼうとしているとしても、それは結局は「上司や組織に対していい顔をしている自分を作り出すという自分自身の損得」に基づいて行動していると言えるだろう。

ここに取り上げた理由

ソフトウェア開発への有用な情報を書くべきサイトに、なぜこの記事を書いたのかは、次のとおりだ。

事実を歪めて伝えてしまうと、本来なら取りうる対策がなされず状況を悪化させてしまう

悲しいことにそのような不誠実な生き方が、たくさんの場所で生じているということだ。本気で事実に対して向き合って考えれば方策があることも、不誠実な生き方を選んでしまえば、問題を悪化させるだけのことになる。

スペースシャトル チャレンジャー号の爆発事故

スペースシャトル チャレンジャー号の爆発事故について次のように書かれている。
当日朝の異常な低温が射ち上げに及ぼす危険に関する技術者たちからの警告を無視し、またこれらの技術的な懸念を上層部に満足に報告することもできなかった。

問題があることを認めてさえいれば、打ち上げを別の日にすることで何もトラブルを生じなかったであろう。

問題がある(かもしれない)ことに対して、十分な検討なしに「問題なし」としてしまう組織的な生き方が、トラブルを大きくしてしまった。

ソフトウェア開発でも起こりえないか?

このような、「問題がないことになっている」ことが、対策を事前に取り組むことを組織的に不可能にしていることはないのか?
問題があることを認めてくれれば、対策をとることに対してチームとして取り組むことができる。
しかし、問題がないことになっていれば、「問題がないことになっている」のに、なぜお前は勝手なことをやっているんだとなって、対策に取り組むことが不可能になってしまう。

私もソフトウェアの開発を長年やってきたが。問題のないテーマはなかった。精度をどれだけ改善できるのかという分野では常にエラー(誤差、誤判定)はあり続けた。だから問題を解決。工夫し続けることが課題だった。

「システム開発の技術力は高いのだが、....」などと言うのはやめよう。
何度もトラブルを生じるのを予防できなかったシステム開発のプロセスマネジメントを含めて「問題がある」と認めてかかってはどうだろうか。うまくいくことが自動化テストによって確保されていない限り、問題があると認めよう。

「システム開発の技術力は高いのだが」と言った時点で、問題を拾い上げる力が失われないか。

不誠実な対応はトラブルを大きくする。
と私は言い切りたい。

人為ミスもソフトウェア工学の対象だ

あうるトラブルが人為ミスだったとしよう。でも人為ミスをことさらに強調するのはやめよう。
 人為ミスが生じたときに、「ミスをした△△が悪かったんだ」とか、「人為ミスが原因なんだから、それ以外のところには問題がないんだ。(私の責任の範囲じゃないよ)」とか主張しているように響くのです。

 でも、そうじゃないと思うんです。「人為的なミスが発生しうる余地があること」が問題だったり、「人為的なミスにより、トラブルが拡大しうる」ことが問題だったりすると思うんです。

次の資料の中ではヒューマンエラーという言葉でシステム障害の3大原因の1つにあげている。
システム障害事例情報の分析に基づく 教訓・対策を共有する仕組み ~智の共有が安心・安全社会を創る~

 開発現場・運用現場での必要なコミュニケーションが保たれるかどうかもソフトウェア工学の対象だと思うんです。だれがどう責任を持つのか、権限と責任とが明確になっていない運営のしかたも、問題だと思うんです。

 システム開発の分野で、「容易に換えの効かない分野の技術者が集団的に離脱してしまう」などという事例も、ソフトウェア工学の対象でありうると思うんです。そこには、何か不誠実な対応のしかたがあって、そのような出来事が発生するんじゃないかと思うんです。

おそらくは、多くのシステムでなんらかのトラブルが発生したときに「正常な動作が確保されていない」プロセスがあることを、現場の技術者は指摘しているのではないかと思う。しかし、その声が組織の中で押しつぶされているのではなかろうか。(スペースシャトルのチャレンジャーの事故と同じ構造だ。)

 そんな気がしてならない。

銀行系のシステムが今回もトラブルを生じた。

「人為的ミスによりネットワーク障害が発生。」と発表している。

この記事に書いている人は、その開発現場について何も知らない。「忖度という美徳がある」官僚社会とある意味似通った大企業の中では、
同じような現象が起きていても不思議はないと推測している(あるいは邪推している)にすぎない。

「みずほ証券カード」についても、提携する金融機関のATM(現金自動預払機)で入出金ができない状況という。」のも、何かのトラブルが別の分野へ波及してしまっているのを疑わせる。

もし、そのような邪推が的外れならば、「私達はシステム工学において無能だ」ということを認めなくてはならない。


付記:

次のような記述をweb上に見つけました。私には、これが本当かどうかを判断することはできません。

真の原因は、統合するシステムそのものの設計書・仕様書レベルで、負け組(=新システム開発に乗れな
かったカイシャ)が、意図的なイヤガラセで、「現状」の仕様や設計を開示しなかったことにあります。

【ワレコのIT講座】みずほ証券三日連続で取引不能【開発はNECか?日立か?】