ＳＥノウハウ ＩＴプロジェクト品質管理編: Ver1.0
価格： ￥0
カテゴリ： Kindle版
Overview:
This book has been written about the " IT project quality management " of Japan
*Contents are written in Japanese
＜本書の概要＞
IT開発プロジェクトの品質管理の担当者として行う業務・作業の全般を本書に纏めています。
＜章立て＞
1ＩＴプロジェクト品質管理
1.1.準備
1.1.1.用語等
1.1.2.本書の前提（体制・役割・要員）
1.1.3.本書の前提（システム重要度評価）
1.1.4.本書の前提（プロジェクトの管理レベルの判定）
1.1.5.成果物チェックリストの用意
1.1.6.レビュー記録票の用意
1.1.7.バグ管理票の用意
1.2.品質管理計画の作成
1.2.1.管理対象の決定
1.2.2.品質指標値の設定
1.2.3.第三者レビューの方針
1.2.4.第三者テストの方針
1.2.5.品質報告の方針
1.2.6.スケジュールの作成
1.2.7.運用ルールの周知
1.3.統計による品質評価
1.3.1.レビュー密度の妥当性評価
1.3.2.レビュー指摘率の妥当性評価
1.3.3.テスト密度の妥当性評価
1.3.4.テストの種別比率の妥当性評価
1.3.5.バグ検出率の妥当性評価
1.3.6.バグ収束曲線による評価
1.4.個票の確認
1.4.1.検出不具合の妥当性評価
1.4.2.真因分析・抜本的対策
1.4.3.横展開対応
1.5.第三者レビュー
1.5.1.一般チェック（形式チェック）
1.5.2.要件定義レビュー
1.5.3.設計レビュー
1.5.4.ソースコードレビュー
1.5.5.テスト計画レビュー
1.6.第三者テスト
1.6.1.意地悪テスト
1.7.品質報告
1.7.1.品質報告書の作成
1.7.2.品質報告（ベンダー⇒ユーザー）
1.7.3.品質報告（PMO⇒上層部等）
1.8.プロセス資産管理
＜冒頭＞
品質管理とは、ＩＴ開発プロジェクトにおいて、いわゆる品質問題を防ぐため、品質状態を可視化し、品質が悪い箇所について、対策を施し品質を確保する業務である。
品質管理の全体像として、大きく、設計書等のドキュメントレビューにより品質を作り込む作業と、プログラムのテストにより品質を確認する作業に大別される。また、これらのレビュー・テストについて、統計情報を用い品質を評価・改善するトップダウン型のアプローチ（※１）、ならびに、個々の問題に対策を施し品質を改善するボトムアップ型のアプローチ（※２）がある。
品質管理で最も大切なことは、QCD（品質、コスト、納期）のうち1つでも欠くことなく、限られたコストと期限の中で、品質を一定水準まで引き上げ、最大限に品質を確保することである。これは、ソフトウェアに欠陥があることを示すことはできても、欠陥がないことを証明することはできない、つまり、全パターンテストを実施することはコスト・納期の面で出来ない業務の実態があるためである。
＜トップダウン型のアプローチ（統計情報）（※１）＞
レビュー・テストについて、統計的な観点で品質状況を可視化し、品質評価・改善を行う作業である。
⇒1.3統計による品質評価 参照
なお、これを実現するためには、レビュー記録票やバグ管理票等の品質状況を可視化するための仕掛けが必要である。
⇒1.1準備 参照
＜ボトムアップ型のアプローチ（※２）＞
「品質の源泉は責任感」であり、小さなことも見過ごさず対策を積み重ねて品質改善に努めるのがボトムアップ型のアプローチである。
‐個票の確認
システム開発業務において、品質を確保するための実施事項は広く知れ渡っている所であり、個票（レビュー記録票、バグ管理票）を確認し、「当たり前のことを確実に実施」していることを確認し、必要に応じて品質改善を行う。
⇒1.4個票の確認 参照
‐第三者レビュー
第三者レビューにより品質を作り込む。
⇒1.5第三者レビュー 参照
‐第三者テスト
第三者レビューにより品質を確認する。
⇒1.6第三者テスト 参照
＜品質管理のメリット＞
品質管理を導入するメリットは、以下のとおりである。（デメリットは、管理コストの増加である）
〇品質状態の可視化・対策
レビュー記録票、バグ管理票等により、品質状態を可視化し、問題がある箇所に対し、対策を施すことが出来る。
〇品質の引き上げ・均一化
プロジェクト内の担当者の経験や技術の差は当然にあるものである。そして、プロジェクト全体として見た場合、品質にばらつきがあるように見えてしまう。品質の低いところに対策を施すことによって、品質を引き上げ、このようなバラつきを少なくすることが出来る。
〇レビューによる効率的な改善
設計レビューで問題を検出するコストを１とした場合、テスト工程で問題を検出・是正するには１０以上のコストがかかり、また、リリース後に問題を検出・是正するには１００以上のコストがかかることがある。つまり、後工程での対応になるほど修正にかかるコストが増大してしまうため、レビューにより効率的に品質の作り込むことが出来る。
〇プロジェクトへの牽制機能・ブレーキ
品質の評価により、品質が悪い場合、工程審議等にて、ブレーキをかける。これにより、品質の悪い状態のままプロジェクトが進み、後工程で問題が大きくなることを抑止することが出来る。
〇承認のし易さ
工程審議等に先立ち、事前に成果物の品質チェック・改善を行い、結果的に問題がなければ、承認者も承認し易い。
〇安定的なプロジェクト推進
以上のことをとおして、プロジェクトの安定的な推進に繋げることが出来る。
1.1.準備
1.1.1.用語等
以降の章を専門的に記載するため、基礎となる用語を以下に記す。
●レビュー
レビューとは、成果物が完成する前の中間成果物を確認することである。実際に作る（製造）前に成果物の内容でよいかどうかを確認するのが「レビュー」である。
●テスト
テストとは、上記のレビューに対し、製造後に実際にプログラムを動作させ、仕様書どおりの動作の確認や、不具合がないことを確認するのが「テスト」である。
●Ks
Ks（キロステップ）は、開発システムの規模を表す指標の一つである。１Ksは、ソースコードの１０００（K）行（step）である。本書においては、コメント行と空白行を除く実行ステップ１０００行と定義する。
1.1.2.本書の前提（体制・役割・要員）
品質管理にかかわる登場人物として、実際に開発を行う者、プロジェクト管理を行う者、品質管理を行う者等がいる。
企業により体制は様々だと思われるが、本書においては、具体的に以下の体制・役割・要員の前提である。
特に留意すべきことは、品質管理業務は、開発プロジェクトに対する、牽制機能としての役割があり、いわゆる“ブレーキ役”である。開発側との馴れ合い等が無いように、開発側とは独立した組織にすることが望ましい。
＜開発側とプロジェクト管理と品質管理の役割＞
●開発側（現場）
システム開発業務を実際に行う役割である（現場）。開発部署や、その外部委託ベンダー等で構成される。品質管理にかかわる主な実施事項は、以下のとおりである。
・ドキュメントレビューの実施
⇒概要は、1.5第三者レビュー 参照
⇒詳細は、『ＳＥノウハウ 設計・開発編』に記載予定
・テストの実施
⇒概要は、1.6第三者テスト 参照
⇒詳細は、『ＳＥノウハウ テスト編』 参照
●プロジェクト管理（PM/PMO）
システム開発プロジェクトを全体として推進する役割である（PM/PMO）。システムを所有・利用している部署、開発を推進する部署等で構成される。
品質管理にかかわる主な実施事項は、以下のとおりである。
・工程定義、工程完了基準の定義
・成果物定義
⇒詳細は、『ＳＥノウハウ プロジェクト管理編』に記載予定
【補足】開発側とプロジェクト管理の役割分担で揉めることは少ないが、プロジェクト管理と品質管理の役割分担については、“相手の役割である”と思い違いをし易いため、予めすり合わせておく必要がある。
●品質管理（品質管理チーム）
プロジェクト管理を構成する管理体１つである品質管理を管轄する役割である。（品質管理チーム）
主に以下のことを実施する。
・品質管理にかかわる枠組みの整備（規定類、体制等）
・品質管理の全体的な旗振り
・第三者レビューの実施
・第三者テストの実施
・品質評価・報告の実施
・過剰なレビューやテストへのブレーキ
This book has been written about the " IT project quality management " of Japan
*Contents are written in Japanese
＜本書の概要＞
IT開発プロジェクトの品質管理の担当者として行う業務・作業の全般を本書に纏めています。
＜章立て＞
1ＩＴプロジェクト品質管理
1.1.準備
1.1.1.用語等
1.1.2.本書の前提（体制・役割・要員）
1.1.3.本書の前提（システム重要度評価）
1.1.4.本書の前提（プロジェクトの管理レベルの判定）
1.1.5.成果物チェックリストの用意
1.1.6.レビュー記録票の用意
1.1.7.バグ管理票の用意
1.2.品質管理計画の作成
1.2.1.管理対象の決定
1.2.2.品質指標値の設定
1.2.3.第三者レビューの方針
1.2.4.第三者テストの方針
1.2.5.品質報告の方針
1.2.6.スケジュールの作成
1.2.7.運用ルールの周知
1.3.統計による品質評価
1.3.1.レビュー密度の妥当性評価
1.3.2.レビュー指摘率の妥当性評価
1.3.3.テスト密度の妥当性評価
1.3.4.テストの種別比率の妥当性評価
1.3.5.バグ検出率の妥当性評価
1.3.6.バグ収束曲線による評価
1.4.個票の確認
1.4.1.検出不具合の妥当性評価
1.4.2.真因分析・抜本的対策
1.4.3.横展開対応
1.5.第三者レビュー
1.5.1.一般チェック（形式チェック）
1.5.2.要件定義レビュー
1.5.3.設計レビュー
1.5.4.ソースコードレビュー
1.5.5.テスト計画レビュー
1.6.第三者テスト
1.6.1.意地悪テスト
1.7.品質報告
1.7.1.品質報告書の作成
1.7.2.品質報告（ベンダー⇒ユーザー）
1.7.3.品質報告（PMO⇒上層部等）
1.8.プロセス資産管理
＜冒頭＞
品質管理とは、ＩＴ開発プロジェクトにおいて、いわゆる品質問題を防ぐため、品質状態を可視化し、品質が悪い箇所について、対策を施し品質を確保する業務である。
品質管理の全体像として、大きく、設計書等のドキュメントレビューにより品質を作り込む作業と、プログラムのテストにより品質を確認する作業に大別される。また、これらのレビュー・テストについて、統計情報を用い品質を評価・改善するトップダウン型のアプローチ（※１）、ならびに、個々の問題に対策を施し品質を改善するボトムアップ型のアプローチ（※２）がある。
品質管理で最も大切なことは、QCD（品質、コスト、納期）のうち1つでも欠くことなく、限られたコストと期限の中で、品質を一定水準まで引き上げ、最大限に品質を確保することである。これは、ソフトウェアに欠陥があることを示すことはできても、欠陥がないことを証明することはできない、つまり、全パターンテストを実施することはコスト・納期の面で出来ない業務の実態があるためである。
＜トップダウン型のアプローチ（統計情報）（※１）＞
レビュー・テストについて、統計的な観点で品質状況を可視化し、品質評価・改善を行う作業である。
⇒1.3統計による品質評価 参照
なお、これを実現するためには、レビュー記録票やバグ管理票等の品質状況を可視化するための仕掛けが必要である。
⇒1.1準備 参照
＜ボトムアップ型のアプローチ（※２）＞
「品質の源泉は責任感」であり、小さなことも見過ごさず対策を積み重ねて品質改善に努めるのがボトムアップ型のアプローチである。
‐個票の確認
システム開発業務において、品質を確保するための実施事項は広く知れ渡っている所であり、個票（レビュー記録票、バグ管理票）を確認し、「当たり前のことを確実に実施」していることを確認し、必要に応じて品質改善を行う。
⇒1.4個票の確認 参照
‐第三者レビュー
第三者レビューにより品質を作り込む。
⇒1.5第三者レビュー 参照
‐第三者テスト
第三者レビューにより品質を確認する。
⇒1.6第三者テスト 参照
＜品質管理のメリット＞
品質管理を導入するメリットは、以下のとおりである。（デメリットは、管理コストの増加である）
〇品質状態の可視化・対策
レビュー記録票、バグ管理票等により、品質状態を可視化し、問題がある箇所に対し、対策を施すことが出来る。
〇品質の引き上げ・均一化
プロジェクト内の担当者の経験や技術の差は当然にあるものである。そして、プロジェクト全体として見た場合、品質にばらつきがあるように見えてしまう。品質の低いところに対策を施すことによって、品質を引き上げ、このようなバラつきを少なくすることが出来る。
〇レビューによる効率的な改善
設計レビューで問題を検出するコストを１とした場合、テスト工程で問題を検出・是正するには１０以上のコストがかかり、また、リリース後に問題を検出・是正するには１００以上のコストがかかることがある。つまり、後工程での対応になるほど修正にかかるコストが増大してしまうため、レビューにより効率的に品質の作り込むことが出来る。
〇プロジェクトへの牽制機能・ブレーキ
品質の評価により、品質が悪い場合、工程審議等にて、ブレーキをかける。これにより、品質の悪い状態のままプロジェクトが進み、後工程で問題が大きくなることを抑止することが出来る。
〇承認のし易さ
工程審議等に先立ち、事前に成果物の品質チェック・改善を行い、結果的に問題がなければ、承認者も承認し易い。
〇安定的なプロジェクト推進
以上のことをとおして、プロジェクトの安定的な推進に繋げることが出来る。
1.1.準備
1.1.1.用語等
以降の章を専門的に記載するため、基礎となる用語を以下に記す。
●レビュー
レビューとは、成果物が完成する前の中間成果物を確認することである。実際に作る（製造）前に成果物の内容でよいかどうかを確認するのが「レビュー」である。
●テスト
テストとは、上記のレビューに対し、製造後に実際にプログラムを動作させ、仕様書どおりの動作の確認や、不具合がないことを確認するのが「テスト」である。
●Ks
Ks（キロステップ）は、開発システムの規模を表す指標の一つである。１Ksは、ソースコードの１０００（K）行（step）である。本書においては、コメント行と空白行を除く実行ステップ１０００行と定義する。
1.1.2.本書の前提（体制・役割・要員）
品質管理にかかわる登場人物として、実際に開発を行う者、プロジェクト管理を行う者、品質管理を行う者等がいる。
企業により体制は様々だと思われるが、本書においては、具体的に以下の体制・役割・要員の前提である。
特に留意すべきことは、品質管理業務は、開発プロジェクトに対する、牽制機能としての役割があり、いわゆる“ブレーキ役”である。開発側との馴れ合い等が無いように、開発側とは独立した組織にすることが望ましい。
＜開発側とプロジェクト管理と品質管理の役割＞
●開発側（現場）
システム開発業務を実際に行う役割である（現場）。開発部署や、その外部委託ベンダー等で構成される。品質管理にかかわる主な実施事項は、以下のとおりである。
・ドキュメントレビューの実施
⇒概要は、1.5第三者レビュー 参照
⇒詳細は、『ＳＥノウハウ 設計・開発編』に記載予定
・テストの実施
⇒概要は、1.6第三者テスト 参照
⇒詳細は、『ＳＥノウハウ テスト編』 参照
●プロジェクト管理（PM/PMO）
システム開発プロジェクトを全体として推進する役割である（PM/PMO）。システムを所有・利用している部署、開発を推進する部署等で構成される。
品質管理にかかわる主な実施事項は、以下のとおりである。
・工程定義、工程完了基準の定義
・成果物定義
⇒詳細は、『ＳＥノウハウ プロジェクト管理編』に記載予定
【補足】開発側とプロジェクト管理の役割分担で揉めることは少ないが、プロジェクト管理と品質管理の役割分担については、“相手の役割である”と思い違いをし易いため、予めすり合わせておく必要がある。
●品質管理（品質管理チーム）
プロジェクト管理を構成する管理体１つである品質管理を管轄する役割である。（品質管理チーム）
主に以下のことを実施する。
・品質管理にかかわる枠組みの整備（規定類、体制等）
・品質管理の全体的な旗振り
・第三者レビューの実施
・第三者テストの実施
・品質評価・報告の実施
・過剰なレビューやテストへのブレーキ