はじめに
情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？
実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。
また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。
そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。
システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。
品質分析とは？
試験で発生したバグの内容をメトリクスとして取得・分類することで、バグの原因を分析すること。
- 定量的な情報から、問題点を洗い出し、調査対応などを行う。
※機能Aにおいてバグが多いので、その機能の内容を確かめるなど。 - バグ状況においては、前工程への差戻を判断する必要がある。
品質分類例
分類項目例としては以下
- 機能分類 ：バグを発生した機能軸で分類する。
- 重要度 ：バグが上市した後に顕在化した場合の重要度で分類する。
- 不具合分類 ：バグがなぜ発生したのかを分類する。（犯人探しが目的ではないことを注意
- 混入工程 ：バグがどのタイミングで混入したのかを分類する。
それぞれの分類項目・内容を勘案し、取るべきアクションを決定する。
機能分類
各種設計書の大項目分類に従い作成を行う。
重要度
分類例は以下
- 大 ：正常系のプログラム動作に不整合が発生するバグ。
- 中 ：異常系などのエッジケースにおいてプログラム動作に不整合が発生するバグ。
- 小 ：設計書の修正であっても対処可能なバグ。
- 極小：修正不要なレベルの軽微なバグ。
不具合分類
分類例は以下
- 設計(誤り)
- 設計(曖昧)
- 製造(誤り)
- 製造(漏れ)
- 環境(誤り)
- 環境(漏れ)
- ｺﾒﾝﾄ
- 試験ミス
- 試験仕様(誤り)
混入工程
分類例は以下
- 要件定義
- 基本設計
- 詳細設計
- 製造
- 単体試験
- 結合試験
- 総合試験
品質分析確認
品質分類に従い、どこにバグが集中しているのかを確認し対応を行う。例えば、結合試験にて”基本設計”の”設計（曖昧）”な項目が多ければ、基本設計の内容を改めてレビューするなどの対応を行う必要がある。
また、バグ密度とテスト密度がテスト計画時の目標に対して、どのような分布になっているか確認を行う。特にテスト密度が想定より遥かに小さい場合は、テストが十分であるかを観点から改めて確認していく必要がある。
バグが多い・少ないことが問題ではなく、出現したバグに対して想定される潜在バグを見つけ出すことが非常に重要である。
品質確認後、品質が非常に低いことが想定される場合は、”勇気を出して差戻を行う”ことが必要である。差戻は非常に勇気のいる作業である、内部からも外部からも非難され、追加のコストとスケジュールが発生するためである。しかし、必要なタイミングで十分なチェックを行い、継続する場合のリスクを丁寧に確認し、これをプロジェクト全体に周知し差戻を行うのは、プロジェクト全体でみると結果として良い結果を導くものである。（特に非IT企業では理解されない傾向があるため、ステークホルダーとの丁寧な調整が必要となる。）
コメント