Download
1 / 19
190 likes | 261 Views
インスペクションレビュー. Ｆ. Ａ，Ｂ，Ｃ、Ｅ１. （１）計画策定 （リーダ）. Ｄ、ＥＩ、 Ｆ（開始基準）. （２）開始条件の確認（リーダ）. Ｇ（コメント）. （３）キックオフ（リーダ、チェッカ、オーサ）. Ａ，Ｂ、Ｃ、Ｄ、 Ｅ１、Ｆ. インスペクションレビューのプロセス. （４）個人チェック（チェッカ）. Ｇ（確認済みコメント）、Ｈ. Ｇ（コメント）. （５）ロギングミーティング（リーダ、チェッカ）. Ｇ（確認済みコメント）、Ｅ１、Ｇ. Ｇ（修正結果）、Ｊ、Ｅ２. （６）成果物の修正（オーサ）. Ｊ. （８）ソース文書変更要求（リーダ）.
E N D
Ｆ Ａ，Ｂ，Ｃ、Ｅ１ （１）計画策定（リーダ） Ｄ、ＥＩ、 Ｆ（開始基準） （２）開始条件の確認（リーダ） Ｇ（コメント） （３）キックオフ（リーダ、チェッカ、オーサ） Ａ，Ｂ、Ｃ、Ｄ、 Ｅ１、Ｆ インスペクションレビューのプロセス （４）個人チェック（チェッカ） Ｇ（確認済みコメント）、Ｈ Ｇ（コメント） （５）ロギングミーティング（リーダ、チェッカ） Ｇ（確認済みコメント）、Ｅ１、Ｇ Ｇ（修正結果）、Ｊ、Ｅ２ （６）成果物の修正（オーサ） Ｊ （８）ソース文書変更要求（リーダ） Ｂ、Ｅ２ Ｅ２（確認済み） （７）成果物の修正確認（リーダ、チェッカ） Ａ：ルール Ｂ：手順 Ｃ：チェックリスト Ｄ：ソース文書 Ｅ１：成果物（レビュー前） Ｅ２：成果物（修正後） Ｆ：マスタプラン Ｇ：レビュー記録 Ｈ：プロセス改善提案 Ｊ：ソース文書変更要求 Ｇ（確認結果） Ｆ（終了基準）、Ｇ （９）終了条件の確認（リーダ） （１０）成果物リリース（リーダ） Ｅ２ Ｅ２ Ｈ （１１）プロセス改善（ＣＤＥの作成者）
ポイント ・最も重厚なレビューである。 インスペクションレビューのプロセス
ポイント ・インスペクションリーダが選出されている。⇒詳しくは８章 インスペクションレビュープロセスの前提条件
ポイント ・ （１）インプット文書 ・成果物（レビュー前） ・ソース文書 ・ルール ・チェックリスト （２）アプトプット ・マスタープラン （３）活動内容 計画項目の内容決定 ・メンバと役割の決定 ・必要な文書（ソース文書、ルール、チェックリスト）の確認 ⇒★何をどのように確認し、どのようになっていれば良いのか？ ・ソース文書の確認 「ルール」にもとづいて成果物が作成される源となる文書※１ ・ルールの確認 ソース文書から成果物を生成するまでのタスクを記述した文書※２ ・チェックリスト チェッカが多くの欠陥を見つけられるようにルールに解釈を与えたもの※３ ・手順 インスペクションで実施される個々のタスクと期待されること ・必要な文書の特定 ・チームメンバが、必要な文書にアクセスできるようにする。 ・チェック作業の最適速度の決定（１回２時間１０ページなど） ・チェック作業の文書を分割する。（チェックの最適速度にあったボリュームに分割する）※４ ・各メンバの都合のよいチームミーティング（キックオフ、ロギング）の日時と場所を決める。 ・めざすべき品質レベルと、それを達成するために戦略の準備 ⇒★戦略？で何か。 （１）計画策定
※１ ソース文書 ・成果物をチェックするときに対比する主要な文書であり、成果物を生成する作業プロセスでソースとして用いられた文書 である。 ・ソース文書として、アイデア、メモ、契約、方針、要求、計画などがある。 ・ソースは文書化されなければ、チェッカが潜在する欠陥をチェックすることは不可能であり、口頭での情報でも文書化 すべきてある。 ・インスペクションが終了しているソース文書であっても、ソース文書に潜在する欠陥はゼロを期待できないので、例えば、 ４ページあたり１個以下の残存結果は許容する等、欠陥の除去を続けるよりも経済的に見合った条件であれば良い。 ※２ ルール ・ルールは成果物をどのようにして作り出すべきなのか定義したものであり、成果物を作成するのに用いられた文書である。 ・インスペクションは、成果物と同様に、ソース文書から成果物に変換するプロセスもチェックする。 ソース文書（入力）→ プロセス（ルール） → （出力）成果物 ・変換プロセスを記述したものがルールであり、インスペクションはルールが守られていることの確認でもある。 ・ルールは、「こうしたほうがよい」というような利己的な要素（好みの問題）を排除することができる。 ・「それはルールのＸＸに矛盾している」といった文書間の食い違いを適切なルールに従って特定することに専念できる。 ・ルールセットの例（「ソフトウェアインスペクションＰ５２) ・作業プロセスには以下のことを定義する。 どのソース文書のどの部分を読むべきか。 ソース文書中の情報をどうやって成果物の文章に変換するのか。 成果物の形式と構成はどうするのか。 成果物を作成するための既知のベストプラクティスは何か。 （１）計画策定
※３ チェックリスト ・チェックリストは、ルールの拡張および説明である。 ・何人かのチェッカが解釈できないかもしれないルールの解釈を容易にして、重要な課題の発見に導くことである。 ・チェックリストは発生した欠陥から学んだ経験を反映し、随時アップデートし続ける必要がある。 ・ある文書のための一連の質問は１ページを超えない。（２５項目ぐらい） ・通常、肯定的な質問で記述され、課題が発見されたときは否定的な回答になる。（例：すべてのページに番号があるか？） ・チェックリストは重大な欠陥を掘り起こす質問に集中し、すべての考えられる質問を含んでいる必要はない。 ・チェックリストに新たなルールを「定義」してはいけない。 ・チェックリストは、ルールを詳しく説明する役割もある。 ・チェックリストの妥当性は、チェックリストのどの質問が実際に重要な問題の発見に結びついたのか示す表を作り、長期に わたって、ある質問が記録されなければ、事実上誰もそれを使っておらず、その質問は削除すべきである。 ・ ※４ 成果物分割 ・リーダは、最適な作業速度と、チェッカに過度な負担（１回２時間程度）を与えないように、成果物分割を実施する。 ・文書全体のチェックが終わるまで、必要な回数、分割した成果物のチェックを実施する。 ・分割することにより、初期段階で対象文書に慣れさせ、チェックプロセスの調整を図る。 （１）計画策定
ポイント ・リーダは、インスペクション対象の成果物とそのソース文書を照らし合わせて、インスペクション開始基準（一般／特定基準）を満たしているか確認する。 （具体的な方法例）成果物を１～２ページサンプリングし、ざっと眺めただけで、多くの軽微欠陥あるいは重大欠陥が見るかる場合、インスペクションは開始できない。 ⇒オーサがより効率的に欠陥を除去できるインスペクション以前の修正レベルの品質の文書を、インスペクションでチェックするのは、インスペクショングループにとって時間の無駄である。 （１）インプット文書 ・成果物（レビュー前） ・ソース文書 ・マスタプラン （２）アプトプット文書 ・リーダが承認した証跡 （３）活動内容 ・リーダは、先のプロセスに進む前に、すべての関連する開始基準をチェックし、満たしていることを確認する。 一般開始基準 ・すべての成果物文書に適用される。 特定開始基準 ・特定のタイプやクラスの成果物文書（例：契約文書、工程計画書）がチェックされる場合に適用される。 ・実際の必要性と経験にもとづいて設定さえる。 （２）開始条件の確認
ポイント ・要望があって開催されるもので、すべてのインスペクションに強制するものではない。 ・リーダがキックオフミーティングの必要性を判断する。 ⇒成果物の特殊性、初めてのチェッカや外部からのチェッカが参加するなど ・全員が必要とする情報を同時に知らせることで時間を節約し、タスクを明確にする。 （１）インプット文書 ・ルール ・手順 ・チェックリスト ・ソース文書 ・成果物（レビュー前） ・マスタプラン （２）アプトプット文書 ・議事録 （３）活動内容 ・インスペクションにおける役割について、同意を得る。 ・インプット文書を配布する。 ・インプット文書の解釈の仕方について説明し、その文書に慣れさせる。 ・インスペクション実施後のプロセス改善提案を依頼する。 （３）キックオフ
ポイント ・チェッカは、役割スペシャリスト（特定のタスクを請負っているチェッカ）、オーサ、リーダ等があるが、除外される役割の人はいない。 ・チームのロギングミーティング開催日までにチェックが完了する。 ・与えられた専門の役割を完全に遂行する。 ・チェックが困難な問題に遭遇したり、インプット文書の問題でチェックの時間が無駄に費やされると予想された場合、リーダに相談する。 ・ルール、チェックリスト、手順に従うように努める。 （ベストプラクティスによる生産性確保のため） ・個人チェックのプロセスは、個々のチェッカがユニークな欠陥、だれにも見つけられなかった欠陥を最大数発見したときに最大の効果となる。 ・個々のチェッカが別々の視点で個人チェックを実施することにより、同じチェックによる重複を避け、生産性が高まる。 （１）インプット文書 ・キックオフでインプット済み （２）アプトプット文書 ・レビュー記録（コメント） （３）活動内容 ・チェッカは、決められた範囲であれば、適当なスタイルでチェックを行う。 どんな文書を組み合わせて見ても、どんな順序でも、誰かからアドバイスを受けても良い。 ⇒個人チェックは、チームの他の誰にも見つけられなかったユニークな欠陥（特に重大欠陥）をどれだけ多く発見できたかに より、個人の貢献が評価されるものである。 ⇒チェックリストは、欠陥発見のためのガイドとして利用するか、チェックリストは他人にまかせて、チェックリストでは見つける ことのできない欠陥発見を選択する方法もある。 （得られたノウハウはチェックリストに反映するが、その反映したチェックリストでのチェックは、スキル者でなくても良い。 スキルのあるチェッカは、誰にも見つけることのできない欠陥発見に注力すべきである） ※１ 大きな文書のチェック ・インスペクションは、文書を虫眼鏡や顕微鏡を使って検査する方法であることから、チェック速度が速くなるほど、文書を検 査する倍率は低くなる。 ⇒ 決められたチェック速度の範囲でチェックする。 ★最適速度の詳細は８．５節 （４）個人チェック
※２ 重大欠陥のチェック ・重大欠陥は後工程まで残すと、修復に多大なコストが掛かるが、発見された欠陥が、軽微であるか重大であるかは、すぐ にはわからない。 ・軽微欠陥を発見して、夢中になって多くの軽微欠陥を確認する方が容易であるが、コスト効果の高い重大欠陥の発見が 重要である。（軽微欠陥を自工程で取りきるよりも、重大欠陥を摘出する方が大事である） ・重大欠陥に注力する方法 ①重大欠陥の摘出を目的とした特定の役割チェックリストと特別の役割（経験？能力？）をもったチェッカを配置する。 ②キックオフミーティングで、重大欠陥の発見が重要であることを周知する。 ③手順、ルールに重大欠陥の発見が重要であることを明記する。 ④手順、ルール、チェックリストのページを少なくする。（１ページ程度） 重大欠陥を摘出するための、タスク、ルール項目、質問項目が追加され、些細ものは、「ページ外」にはじきだされると いう効果がある。 ⑤チェックリストの質問項目毎に、発見されるコメントの重要度の割合（実績）を付記する。 ⑥自分なりの重大／軽微の分類を記録させる。 ⑦チェックでいくつのコメントを発見したかチーム内に口頭に報告することにより、些細なコメントを数多く報告するチェッカ が減少する。（軽微なコメントを多く説明するのが面倒になる） ⑧ロギングミーティングで、チェッカに重大か軽微かの口述させ、軽微なコメントばかり報告することを難しくする。 ロギングミーティングの時間が短いときは、重大欠陥だけを報告させる。 ⑨インスペクションの効果計測に、重大欠陥を対象とする。 軽微欠陥は評価しない。 ⑩重大欠陥の発見を数値目標として設定する。 ⑪軽微欠陥の根本原因を議論しない。 ⑫軽微欠陥と重大欠陥を資料を分けて分析する。 ⑬リーダは重点欠陥をすべて確認し、軽微欠陥はサンプルだけを見るようにする。 ★重大欠陥をどのように定義するのか。試験項目の誤りや漏れを招くもの？後工程で発見できない可能性のあるもの？ （４）個人チェック
※３ チェッカーの役割 ・サッカーチームで監督が相手チームと有利に戦うために選手に特定の役割を指示しているのに似ている。 ①チェッカがユニークな視点（想像力、ＡＰや業務知識、会社要求等）を持つよう、チェッカの専門的興味や才能を見込ん で、役割を割り当てる。（特定の欠陥チェックを同僚より上手く行うことができる） ②重複する欠陥の発見を最小にし、ユニークなコメントの発見を最大にするために、キックオフミーティングなどで、すべて のチェッカが他のチェッカの特別や役割を把握できるようにする。 ③役割は、特定のタイプの欠陥のチェックを独占させるのではなく、どの欠陥もすべてのチェッカーが平等な立場で摘出 でき、役割に制限を与えるものではない。 ・役割の例 ユーザ：ユーザまたは顧客の視点に専念する。 テスタ：テストに関する考慮（テスタビリティ、テスト要求、テストの順番、平行テストのための開発順番など）に専念する。 システム（方式？）：より幅広いシステム的関連（ハードウェア、文書化、販売、納期）に専念する。 財務：コストと収益に関する含蓄、見積もり、不確実性、期日、金額に専念する。 品質：直接的、間接的に品質の属性の全視点に専念する。 サービス：フィールドサービス、メンテナンス、供給、インストールに専念する。 バックワード（全く違う視点での文書チェック？）：資料を最終ページから逆順に調べる。 ルール：成果物に対する手順、ルールに基づいているか確認する。 ※４ チェックの作業速度 ・作業速度：ある文書をすべての関連文書と対照してチェックするのに必要な速度。（拡大鏡の倍率） ・最適値は、経験値から計算される。 ①チェッカが精査する文書のページ数 ②精査するページは、どんなタイプか（コード、要求仕様書等） ③そのタイプのページの最適作業速度は、過去の実績データではどれくらいか。 ④平均速度からの変動幅はどのくらいか。 ⇒個人差（能力、経験）、文書の品質、インプット文書（ソース、ルール、チェックリスト）の総ページ数、 環境による変動（作業環境）、チェック時の個人的な疲労、その他 ・チェックの初めは、安定した速度でチェックすることは困難である。 最初はチェック対象を細かく分割し、早い作業速度は 設定しない。（１時間２ページ以内） ・チェッカの時間的な制約がある場合、分割するか、サンプリングを考えるべきである。 （４）個人チェック
ポイント ・ （１）インプット文書 ・ （２）アプトプット文書 ・ （３）活動内容 ・ （５）ロギングミーティング
ポイント （６）成果物の修正
ポイント （７）成果物の修正確認
ポイント ・ （８）ソース文書変更確認
ポイント ・ （１）インプット文書 ・ （２）アプトプット ・ （３）活動内容 ※ （９）終了条件の確認
ポイント ・ （１）インプット文書 ・ （２）アプトプット文書 ・ （３）活動内容 ・ （１０）成果物リリース
ポイント ・ルールの利用者が、ルールに関する何らかの問題を抱えた場合、あるいは建設的な提案をもった場合、ルールのオーサ（｢プロセスオーナ」ともいう）と、即時に自然なコミュニケーションが持てるようにする必要がある。 そうしないと多くの有益な「洞察」が失われ、人々はルールを無視し、生産性が低下することになる。 ・ルールには、オーサの名前と連絡先の記述が必要である。 意見や提案を円滑に実施することができる。 ・ルールは既知のベストプラクティスを文書化したものであり、鉄のおきてではない。 現状のベストプラクティスをルールに反映させる見直しが必要である。 ・ルールの記述は１ページ程度にしないと、利用者はそれを読み、利用する時間をもつことができなくなる。 大きなルールや複雑なルールは、利用者のために分割すべきてある。 ・ロギングミーティングで、ルール、チェックリストへの改善提案を記録できるようにする。 （１）インプット文書 ・ （２）アプトプット文書 ・ （３）活動内容 ・ （１１）プロセス改善
