Software Quality.com

8.19 お知らせのコーナーに"ソフトウェアテストシンポジウム2010北海道 好評受付中! ”を掲載

ホーム
What's new
お知らせ
サイト マップ
Softwareを取り巻く状況
用語解説
要求工学
利用品質/人間中心設計
ソフトウェア品質特性
プロトタイプ
レビュー
レビュー計画
レビュープロセス
レビューの観点・切り口
マネジメント
SW構成管理
books
プロセス改善
独り言・私語
training
reference
当サイトについて
お問い合わせ
★HIT Forum
レビュープロセス
ここではレビューを構成するタスク群(=プロセス)を解説していきます。
プロセスを構成するそれぞれのタスクには目的や意図があり、しかもプロセス自体の目的を達成する手段になっています。
タスクの目的・意図を理解した上で、プロセス目的を達成するようにタスクを実践することが必要です。
それぞれのタスクをただ形式的に書かれている通りやればよいのではなく、目的を達成するように実践するのです。
極端なことを言えば、プロセスの目的を果たすなら、タスクで記載されている事項ではない方法や基準値を使っても構いません。
決まっているから、書いてあるから、誰かが言っていたから・・・・そういう安易な何も頭を使わない対応が目指す成果の達成や向上を阻みます。
十分注意して、自分で手を染め、行動し、いろいろなことを経験しながら活用して成果を上げてください。
 
■レビューの前に重要なこと
レビューをどんなにしっかりやったとしても、レビュー対象の成果物を作成する過程がいい加減なら、生産性も向上しませんし、成果物の質も向上することはないでしょう。
自分の分かる範疇でいい加減に成果物を作成し、セルフチェックもなくただ第三者に提出して見てもらい、指摘されたところだけを直せばよい・・・・・・そういう作業の仕方を許している組織、そういう作業で自分はいいんだ(楽だから)と思っている要員・技術者が、最終製品の質を、そして開発コストを悪化させている張本人である可能性大です。
そんな状態の場合は、レビューをしっかりやるまえに、作業の仕方、いやそのいい加減な(甘えた・自分勝手な・誤った)考え方から直すことをおすすめします。
以下に示すレビュープロセスの中では「開始基準」がそのことを防止する役割を持ちます。
開始基準をいい加減に適用している(いや開始基準がない)組織では、まず上記のようないい加減な(甘えた・自分勝手な・誤った)作業状態になっていないかどうかを確認することをおすすめします。
もし、そういう状態が存在していたら、対象要員、対象組織から十分に指導し、生産性の高い仕事の原理を認識してもらうべきです。
また、開始基準の目的・意味を十分理解して、粗悪な(ちょっと見ただけで欠陥がボロボロ見つかるような)成果物案が提出されたら即時差し戻し、状況と差し戻す意味を十分伝達してください。
 
一方で習慣は恐ろしいので、悪意がなくてもそうなっている場合も多いです。
そういう場合は、まず丁寧に説明するところから始めて、徐々に改善することも必要です。
その後、何度もその状態が継続される(認識されず、分かっていてもやってくる)場合は、対応の仕方を考えた方がよいと思います。
 
■開始判定
<目的>
(1)レビュー以前に準備するべき事項を持ち込ませないことで、レビューによるムダ工数低減する
(2)成果物担当者に適切な仕事を動機づける
 
<タスク>
(1)ここでは次のステップである「事前準備」に進めてよいかを判定します。
 
<解説>
レビューが定着していない組織、効果が上がっていない組織では、対象となる成果物を期限までに入手することすら難しい状態になることが多いです。
まずは成果物案がレビュー準備開始までに入手できるようにしてください。
例えば、レビュー実施日や準備のための関係資料(成果物案を含む)入手期限を組織内で共有しておき、数日前には期限までに提出できる状況かを確認する、などの手間を惜しまずに対応することも必要です。
 
次に、レビューを行う前に(ここでは事前準備を始める前に)対象となる成果物案を少しだけチェックしてみることをおすすめします。成果物の内容のうち、典型的な部分で見るのがよいでしょう。
この「ミニチェック」で多くの欠陥や課題が検出されるようなら、レビューへの事前準備には入らずに、作成者側に返却することが必要になります。
自己チェックすらままならない品質の悪い成果物案をもとにレビューすることほど、組織にとって無駄な対応はありません。
レビューは複数の人数で対応する活動ですから、自分でできることはやり遂げた上で自分では解決できない事項や気がつかない事項を教えてもらうために、その工数を費やすのが目指す姿です。
すぐに欠陥や課題が見つかる程度の成果物案はレビュー以前の代物として取り扱ってください。
 
以上は、成果物担当者に適切な仕事を動機づける、それが大事なんだ、そうすることが結局組織の生産性を高め、かつ高品質成果物を作り出す原則なんだ、ということを組織内で共有するために重要なことです。
 
※あえて開始判定を通過させる
技術者の力量次第ではあえて開始判定を無条件通過させ、設計成果物案をレビューすることもあり得ます。
こういう場合は、典型的な部分の設計をトライアル的に実施し、その部分成果物をレビューすることで欠陥や不具合を検出します。技術者の作業の癖や見逃しなどが反映された成果物案の欠陥や不具合を知らせることで、レビュー対象の部分的成果物案の品質を向上させることができるだけなく、以降の設計作業で注意するべき事項を把握したうえで設計作業を進められます。
このように設計作業全体の生産性と品質を向上させることもできると思います。
 
 
■事前準備
<目的>
(1)レビュー目的、目標、役割、概要を明確にし、参加者に動機づける
(2)個別(事前)チェックの効果・効率を向上する
(3)事前チェックによりレビューミーティング時間の浪費を防止する
<タスク>
(1)事前説明の実施(キックオフと呼ぶ組織もあります)
(2)個別事前チェックの実施
 
<解説>
事前説明の時点では関係者、参加者はレビューの目的、自分の役割、対応領域を十分に認識することが重要です。
不明点があればこの時点で解消しておきましょう。
いきなりレビューミーティングを実施するのでは、レビュー工数を無駄に使うことになります。
事前準備なしでレビューを行うと、その場で即興のチェックを行うだけになり、かつその場で解決策や評価の議論を始めることうけあいです。
まずは参加者個々に自分の担当する役割分の領域を十分に分析し、欠陥だけではなく、意味の分からないところや課題、改善提案なども抽出してすべてを記録しておきます。
ここでは誤字誤植の確認や表現形式のチェックだけに終始しないように注意しましょう。
そのような事前チェックにならないためにも、「欠陥チェックリスト」に基づき対応することをおすすめします。
 
「欠陥チェックリスト」
欠陥チェックリストに基づくことをおすすめしましたが、もちろんどのようなものでもよいという訳ではありません。
毎回ゼロから作成するのは大変ですし、それは現実的ではありません。
無理に即興で取り繕ってもチェックリストが形式的な内容になりがちです。それでは効果が期待できません。
もし欠陥チェックリストがない組織であれば、(あくまでも応急処置として、)関係書籍や外部ガイド類に記載されているチェックリストなどをもとに、レビュー目的に応じた切り口や自分たちの組織でいつも発見される欠陥や障害原因をベースにチェック項目を構築するとよいでしょう。
 
その後、レビュー結果を蓄積して必要なチェック項目(切り口)をどんどん更新していくこと、組織内の経験者、腕のよい方が持つチェックポイントを追加していくことなどを通じて、欠陥チェックリストを自分たちの役立つツールに仕上げてください。
 
■開始判定その2
<目的>
 →開始判定その1を参照
<タスク>
(1)次のステップ「ミーティング」に進めてよいかを判定します。
 
■ミーティング
 
 
■修正・フォローアップ
 
 
■終了判定
 
 
■分析・評価・改善