リコールを起こさないソフトウェアのつくり方

投稿元：

レビューを見る

本書は初めから終わりまでどこをピックアップしても「人」に焦点が当たっているところが特長です。

つまり、リコールを起こすソフトウェアを作ったのは「人」であり、それは、「こういう事情から」だよとという構成になっています。 その視線は人として優しくかつ技術者として厳しいもので尊敬します。

もちろん「ではどうしたらよいか」についても書かれてはいるのですが、それよりも原因を具体的な例を元に掘り下げて読者に示しているところに本書の価値はあると思います。

ソフトウェアテストについての記述には全体的に気になる点が多く、ちょっと残念だったのですが、全てのソフトウェアエンジニアに読んで欲しい本です。

投稿元：

レビューを見る

組み込み業界に足先を突っ込むということで、
今までよりもクリティカルな問題に直面するんじゃないかと思い購入。

Part1～3とAppendixという構成になっており
１．ソフトウェアの危うさ
２．日本的ソフトウェア開発の管理
３．ソフトウェアの再利用性
Appendixでは安全標準、安全規格について取り上げられている。

意外だったのだが、本書中で一番繰り返し出てくるキーワードは「日本の開発者」だった。
「日本の開発者」の特性としては、それなりに能力はあるが「あたたかい人間関係のやさしい一員」となってしまい、責任の徹底は下手。
しかしそれでも小規模なソフトウェア開発を場当たり的になんとなくこなしてしまう。
しかし、その成功や職人気質などからソフトウェア工学の導入に抵抗（銀の弾丸じゃなきゃ受け入れない態度）や形骸化（やることになってるからやってる）してしまいがちだそうだ。大体合ってると思う。

そんな日本事情に触れつつも、ソフトウェアの危うさ・品質という点が本書の主題である。
例えばPart1で紹介されてる初心者のとんでもプログラム例は、見たらすぐにわかるようなものなのだが
それでも環境依存で問題が発覚しなかったり、ユニットテストケースはパスしてしまったりする。
この問題を防ぐにはコードデビューであったり、規約・規範の周知であったりする。
ペアプログラミングで底上げというのも効果的だろう。
Part2中では開発を支える管理手法、Part3ではソフトウェア資産の再利用性に触れている。
安全面・コスト面でハードを意識する事が多くなるものの、
品質のために必要なエッセンスは組み込みであっても一般的なアプリケーションであっても同じように思う。

Part3の後半ではソフトウェアのバグで起きた重大事故について触れられており、
身に染みる思いである、これが読みたかった。

AppendixではMISRA SA（ソフトウェア安全性解析ガイドライン）、
IEC 62304（医療機器ソフトウェア　ソフトウェアライフサイクルプロセス）について紹介されており。
特にIEC 62304は人命を意識したプロセスであり、普段はそこまで注意することは少ないだろうが参考になる。
中でもSOUP（開発過程が不明なソフトウェア）に対する注意の払い方が気になった。
品質を突き詰めていくと、追求出来ない所がネックになるということか。それでも責任は果たさないといけない。

と、気になったところだけかいつまんだが
・日本的ソフトウェア開発の特性を意識してみたい人
・品質至上な製品の開発に関わる人
が読んでみると良いと思う。

具体的開発テクニックについてはあまり載ってないので
それについては巻末の参考文献を漁ってみよう。

投稿元：

レビューを見る

おすすめされたので、chapter2だけ少し読んでみた。
結論、当たり前のことを、当たり前にやろうという話だったように思う。これを組織に徹底するための話が読みたかった。

> 品質という側面から見ると、前半は不良の入り込みの防止が目的の設計努力であり、後半がテストやレビューなどによる不良の摘出努力になります。大事なのは、設計努力と不良の摘出努力のバランスなのです。