QA最前線！ #1 を読んだ
当時、携帯電話の開発が爆発的に広まっていて、バグが山ほど出ていました。そのバグをどうやって管理するかが課題になっていたのです。ツールもなかったので、まず、不具合管理プロセスを整備することにしました。
ここ、大切だと思った。プロダクトに不具合がたくさん出ているからプロセスを整備する。自分だったら、↓↓のようなことはやってみるかもしれない
- 不具合報告書のフォーマットを作り、報告にかかる工数を削減する
- 重要度のレベルを定義し、重大な不具合から順に修正を始められるようにする
- 不具合が集中している箇所を特定し、テストのリソース配分を調整する
- 開発プロセスの見直し（≒振り返り活動）。不具合が多発している理由の分析と改善案策定
いろいろ良い技術や新しいツールを導入しても、なかなか定着しないことに悩みました。バージョンアップしていくシリーズ製品の開発など、既存の制約が多くある中に新しい技術を入れていくのは、現場の人々に納得してもらいながら進めていかないと上手くいきません。
これは現在でも現場あるあるだと思う。ステークホルダーとの関係づくり、社内営業、導入推進を主導する力、、お金も絡んでくる場合もあるから、きちんと説明できないといけない。また、導入後もしばらくは定期的に導入効果をアピールする必要があると思う。
プロセスがソフトウェアの品質を作り込んでいきます。つまり、システムやソフトウェアの品質は、プロセスの品質に左右されるというのが基本的な考え方になっています。
プロセスは「人」「手順と手法」「ツール」の3つで構成されていて、プロセスがプロダクト品質の土台になるという考え方。今更ながら、なるほどそうかと気がついた。
