打ち上げじゃなく反省会

梱包発送直前、仕様変更や追加仕様による影響範囲の先っちょで、不具合発生。 致命的な欠陥では無いけど、重箱のスミよりは、デカイ。

以下のことは、重々承知の上なんだが、、、

• 作った本人の「大丈夫」は信用できん
  「基本的に大丈夫」という感覚での試験になるから。

• 試験仕様は宝物
  変更前に影響範囲を隈なく走査して、メモでも良いから、試験仕様を作成するべき。
  もしくはテストプログラムを作るべき。
  そして、ユニットテストは資産だね。

• 内部設計書は必要です
  影響範囲を隈なく走査するために、内部設計書が必要。
  空想では大げさに言えば8割方の試験が漏れる。

• 後付け設計書は世界を救わない
  納品物でなくても、設計書類は、事前に作っておかなければダメ。
  後付けで成果物から作成する内部設計書に、世を救う力は無いからな。
  また、デグレ対策に有用なリグレッションテスト/回帰試験を後から作る意味も無い。

しかし、開発中は、「やってるつもり」になってるだけで、最後の最後に細かいバグがボロボロ出て、とても恥ずかしい思いをする。

---

ところで、

大規模なソフトウェア開発では（特に二次請け以下）、大量の設計書を納品する場合がほとんどだと思うけど、 小規模開発では「設計書は納品しなくてよいですよ」ってのが結構あって、こういう時、請け側は往々にして設計書なしで進めてしまう。

ハードウェアを製作している人たちには信じられないと思うけど、ソフトウェアを作る行為って、設計事務所と製造工場が一緒になっているようなもので、小規模なものだと特に明確に線が引かれていなかったりする。なので、理由はともあれ「手抜き工事をしよう」という判断を簡単にしてしまいがちなんですね。

発注側からの「安く請け負え」というプレッシャーに負けて、そうせざるを得ない場合もあるけど、単に請け側で「邪魔くさいから」ってことも多々。「納品物じゃないから作らない」っていうふうに直結してる人も多いと思います。

---

ということで、結構深く凹んだ次第。

知識だけあっても実践できひんなら意味ねーわなー！

などと、過去に言ってるジブンを蹴飛ばして、

明日からがんばろう。