バグとプロスペクト理論

 

直接は関係ないんですけど、これ読んで思い出したので。

 

バグとプロスペクト理論

長期的に利用されるシステムやソフトウェアって、殆どの場合何らかの改修開発が行われるわけですよね。

 

で、修正するとバグも発生することがあるわけですが、改修開発の場合「新機能バグ」と「デグレバグ」がおきます。

 

新機能バグは、改修で新たに追加しようとした機能で発生したバグ。要は、追加機能が目標の機能を達成していない場合のバグ。

デグレバグは、改修してない既存の機能で発生したバグ。まあ、変更してない部分で思わぬトラブルを引き起こしたパターン。

 

バグはいずれにせよ顧客満足度を下げるものですけど、どちらのほうがユーザの不満を高めるかというとデグレバグの方が高めると思ってます。

 

 

 

プロスペクト理論 - Wikipedia

 

理由は上記の図の様なプロスペクト理論がバグにも適応されるから。

 

プロスペクト理論は「損失回避バイアス」。

 

同等の利益と損失を比較した場合、損失を回避するようバイアスがかかる、ってやつです。

つまり、新規機能のリリース延期をユーザに宣言するのと、無理矢理リリースした結果既存機能にデグレを生じさせるというのでは、時に後者のほうがユーザの満足度を下げる原因になるってことですね。

 

そんなこんなもあって、オッサンのとこのシステム開発の現場では、デグレバグはご法度、みたいな品質管理を行っているんですね。

テストの自動化など、ゴニョゴニョと。。。

 

まとめ

結局のところ、ソフトウェア開発をビジネスにするってことは、顧客満足度を如何に向上させるかという視点で、行動ファイナンス等の考え方が適合されるなって場面があると思ってます。

 

今回のバグの件もそう。今回はプロスペクト理論を提示しましたけど、他にも品質管理の考え方として適応できそうな物があります。

 

 

そんなこんなもあって、新規機能の追加を現行機能保証より優先しちゃったらユーザの怒り爆発だよな、なんて元記事見てたら思うわけです。

まあ、アメリカのベンダと一緒に仕事して、現行保証のところで痛い目を見たことが数度あったので、さもありなんって感じな。。。

 

ま、デグレには気をつけておきましょ。

 

以上