ソフトウェア開発201の鉄則 原理29:一般:組織の評価と個人の評価を合わせよ

要旨

* ソフトウェアの不具合、バグや成果物のエラーが発見されたときは、担当の開発者は「感謝すべき」である
* 技術的なエラーは隠すのではなく、逆に広く公開すべきである
* エラーを知らしめることは、他の技術者の同様のエラー発生を防ぐ、エラーから知見が得られるといったメリットがある
* なので、組織は、エラーを発生させた開発者を責めるのではなく、相応の評価をしなさい

解説

要旨の最後の文章に相当することは、原理には書いていない。きっとこういうことだろう、という私見。

前半に、日本のソフトウェアベンダーでの不具合の扱いについて書いてある。日本だと、

- ソフトウェアのエラーは「恥ずべきもの」と組織はとらえる
- なので、技術者にとっても「恥ずべき」ことである

というふうにとらえている。と。確かに。

ソフトウェアの不具合に限らず、日本人は、一般的な傾向として、失敗を後ろ向きにとらえがちである。

失敗は恥、なので、このようなことが発生しては決してならない

武士道をへんてこりんに解釈したこんなスタンスがまかり通っているように、思う。

なので、たしかに、不具合発生部分を担当した開発者は、そのことを恥ずかしいと思い、管理者や組織も、きっとそのことに対してマイナスに評価するだろう。

なので、軽微な、いや、重要なものであっても、不具合がわかったら、それを公にせず隠す、といった行為をとる開発者がでることもあるだろう。

ある面、タイトル通り、組織と個人のエラーに対するスタンスや評価が「一致している」ことを示している。

で、ここからが本題。

失敗は、「恥ずべきもの」でなく「感謝すべきもの」ととらえて、「受け入れる」これが正しい姿であろう。

人は、必ず、失敗する、ソフトウェア開発でも同じ。重要な部分であればあるほど、担当領域が広いほど、チャレンジすればするほど、エラーが起きる可能性は高くなるものだ。

同じような間違いを何度も繰り返すのは良くないが、エラーからは、必ず「気づき」がある。振り返って、気づきを得て、それでよし、としよう。

失敗は成功の母。