発注者の教育について

スマホ、アプリ、コンシューマーゲーム、などSNSで良く炎上を起こすのが、新機能追加に伴い既存機能に影響(バグ)が発生した時です。

ネットワーク技術が発達する以前は、簡単にバージョンアップが行えない為、デバッグと影響確認にはかなり時間を要したものです。
(それでも、完全にバグを無くすことは不可能ですが)

昨今は、余程致命的なバグでない限り、リリース後にアップデートで対応する事が多くなった気がします。

海外のゲーム会社では、デバッグにAIを使う所も出て来ているそうです。
日本の大企業も、AIを活用する為の研究を進めていると思われます。

機能を追加するだけなら簡単です。ですが、その結果どのような不具合がおきるか、おきそうか、を想像して確認できるデバッガは貴重です。

普通の人ならやらないような使い方を行う必要もあります。

バグの検出に関する冗談のような話として
「あいつのせいで、バグの検出数が減らない。首にしろ」
↓
「バグが減った。品質が上がった」
↓
「バグを減らした成果で昇進し、異動だ」

バグが減ったのでは無く、見つけられなくなった、と言うネタで使われます。

最近はデバッグ機能が充実したとは言え、使うのは人間です。ミスもあれば、使いこなせない人もいます。

開発初期の段階から、拡張性と共に、デバッグ方法を想定して組み込む事が理想ですが、重要性を理解せず、資金と時間を優先する傾向が今も強いです。

その結果、機能拡張、デバッグに余分に資金がかかる。バグだらけのシステムを納品され、結局使い物にならない。機能が足りておらず、セキュリティに問題があるシステムを納品される。

システムを受け入れる側が理解しておらず、仕様書のチェック、プロトタイプでの評価、エビデンスのチェックを出来ない。

開発者を増やすのも重要ですが、発注し受け入れる側が理解を増やす事が重要です。

安い会社を優先するのではなく、提案が妥当か否かを判断した上で発注先を決める事ができる企業が増える事を祈っています。