2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2008年10月 | トップページ | 2008年12月 »

2008年11月

2008年11月28日 (金)

【定量的品質予測のススメ】計測自体を設計せずにテキトーに始めることをススメているのかいないのか

P52「3.1.8 事例:プロセスパフォーマンスモデルを活用した潜在誤り予測」の「(4)効果」において「適用結果から以下の改善が必要であることも判明した」として、「ツールの利用度、ドキュメントの再利用率等のプロジェクトの複雑性要因の追加」が挙げられている。

検出欠陥密度を考える際に、ツールを使った場合と使わない場合を同一とみなし、更にドキュメントの再利用率が20%だろうが80%だろうが同じとみなすという仮定をして、計測してみたら、うまくいかないのでなぜだろうと考えた上で、初めて「改善」が必要だと分かったというのだろうか。
これらがデータ精度のブレとなることが計測して初めて判明したという記述が理解できない。
計測前から分かるのではないか。

このような組織がこの程度の測定を行って、P52「3.1.8 事例:プロセスパフォーマンスモデルを活用した潜在誤り予測」の「(4)効果」において「上流段階から、カットオーバー時の最終品質予測が可能となり」と書いている。
信じてよいのだろうか。

ちなみに、
「適用結果から以下の改善が必要であることも判明した」「ツールの利用度、ドキュメントの再利用率等のプロジェクトの複雑性要因の追加」
と、
「上流段階から、カットオーバー時の最終品質予測が可能となり」
が、同じ、P52「3.1.8 事例:プロセスパフォーマンスモデルを活用した潜在誤り予測」の「(4)効果」に書かれていることは、良心的である。
離れて書かれていたら、これは良いと、信じてしまうものも出てくるだろうから。

P50「3.1.8 事例:プロセスパフォーマンスモデルを活用した潜在誤り予測」の「(2)考え方」において、
  「業務・技術知識の深さ、レビュー内容の濃さで補正して、プロジェクトの最終品質を予測する」
とあるが、この「業務・技術知識の深さ、レビュー内容の濃さで補正」する方法についても「改善」が必要ではないだろうか。

2008年11月27日 (木)

【定量的品質予測のススメ】プロセスパフォーマンスモデルを活用した潜在誤り予測

P50「3.1.8 事例:プロセスパフォーマンスモデルを活用した潜在誤り予測」の「(2)考え方」において、
  「成功プロジェクトと失敗プロジェクトの測定値に差があるとの前提において」
  「業務・技術知識の深さ、レビュー内容の濃さで補正して、プロジェクトの最終品質を予測する」
とある。
ここで注意してお気べきは、この最終品質予測は、「前提」をおいて、かつ「業務・技術知識の深さ、レビュー内容の濃さで補正」して算出された定量データに基づいてなされるということである。

次の質問に「はい」と答えることのできる組織のみこの管理方法が使えるであろう。
  「成功プロジェクトと失敗プロジェクトの測定値に本当に明らかな差があるのか」
  「業務・技術知識の深さ、レビュー内容の濃さを定量的にきめ細かく測れるのか」
しかし、これに「はい」と即答できる組織は少ないであろう。

このような前提と補正をかけた数値を用いて、「予測値が、カットオーバー後の残存誤り目標以下の場合は品質良好。目標以上の場合は品質不良と予測する」と判断することは妥当なのであろうか。 

否定する必要はない。

ただし、補正誤差が評価に直結することを意識しなければならない。
たとえば「業務・技術知識の深さ」を4段階で評価するのであれば、最終品質もせいぜい4段階程度でしか評価できない。
同様に「レビュー内容の濃さ」を4段階で評価するのであれば、最終品質もせいぜい4段階程度でしか評価できない。

「業務・技術知識の深さ、レビュー内容の濃さ」両方を掛け合わせるのであれば、推して知るべし。

「業務・技術知識の深さ、レビュー内容の濃さ」を1から100までの数値化すれば良いのではないかという考えもあろうが、最終品質を測るときに、「業務・技術知識の深さ」が10%大きかったり小さかったりということは大きな影響を及ぼすとは思えない、というよりも誤差の範囲であろう。

まあ、このあたりは本書でも自信がないようで、「(4)効果」において、「適用結果から以下の改善が必要であることも判明した」と書かれている。

ここに挙げられた改善ポイントは、最後の「品質データ収集の自動化」以外は、どれも「予測値が、カットオーバー後の残存誤り目標以下の場合は品質良好。目標以上の場合は品質不良と予測する」ことができるほど収束していないのではないかと思わせるようなものである。

例として「プロセスパフォーマンスモデルを活用した潜在誤り予測」を出すことは、悪いことではない。
ただし、細部に関する記述がないと手が出せない、実行性があるか判断できないような例では困る。
特に本書は「定量的品質予測のススメ」と題したため、定量的品質予測の初心者も手に取る書籍なのだから。

2008年11月26日 (水)

【定量的品質予測のススメ】レビューメンバの能力が高い確率で3σに収まる組織であれば・・・

P49「3.1.7 事例:レビュー不足の予測&是正」の「(3)方法(方目、手法)」において「レビューメンバの能力が高い確率で収まる範囲(3σ)を限界値として設定した」とある。

3σの話が出ると、P20「コラム モデル化時の注意点」において「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」を出さねばならない。

ただ、ここは事例だから、この組織では3σで管理できるのだと言うのであろうけれど、P20のコラムの考えは無視できない。

「レビューメンバの能力が高い確率で収まる範囲(3σ)を限界値として設定した」が、「実際に統計的に扱えるデータが集まっていて、それが3σに収まっている」ことをいうのであれば良いが、「収集データは正規分布に従うことを仮定し、3σに収まるはずだから」という意味であれば、そのような管理の意味は何であろうか考える必要がある。
正規分布に従うのか、3シグマに収まるのか・・・と。

2008年11月25日 (火)

【定量的品質予測のススメ】チームごとの能力はほぼ一定とみなしてよいか

P49「3.1.7 事例:レビュー不足の予測&是正」の「(2)考え方」において「そのサブシステムやアプリケーション単位のチームメンバは同一なので、チームごとの能力はほぼ一定となる」とある。

一方、P20「コラム モデル化時の注意点」において「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」と書かれている。

P49は例なのだから、この例の組織では、「人的要因は大きな影響を与えず、測定値に大きなバラツキが出る傾向はない」というのかもしれないが、この例を真似て品質予測をしようとする組織がいないとも限らない。

「サブシステムやアプリケーション単位のチームメンバは同一なので、チームごとの能力はほぼ一定となる」は、いつでもどの組織でも当てはまるものではない。

P20のことを考慮して、自組織が人的要員は小さいと判断できるのであれば採用して良いかもしれないが、小さいと言えるか分からないときは鵜呑みしてはならない。

P43「(2)レビュープロセスの評価(現工程)」の「最初のドキュメントのレビュー実績(3回以上)を使用して標準偏差を算出し」と、たった3データで標準偏差をとって管理を始めることを推奨しているのだから、本書の立場では、「サブシステムやアプリケーション単位のチームメンバが同一ならば、チームごとの能力はほぼ一定となる」ということは汎用的に当てはまるとしているのかもしれない。

2008年11月24日 (月)

【定量的品質予測のススメ】レビュー指摘件数の絶対値による評価とは

P46「3.1.5 要求分析・設計の品質予測のまとめ」の「図表3.1-13 品質の測定項目別の予測指針」において測定項目
「レビュー指摘件数」の予測指針として「少ないときはプロダクトの品質が良いまたは、レビューが不適切と予測し、レビュー実施内容を調査する」とある。

一方で、、P34「3.1.3 方法(項目、手法)(1)分析と測定項目」において「単に件数の多い少ないだけでは、規模によって多くて良い場合、少なくてよい場合があるので、レビュー対象規模もしくはレビュー工数あたりの件数の密度で評価することに意味がある」と書かれている。

文章上は矛盾している。
この文章上の矛盾は、どのような意味を持つのかが説明されるべきである。

この両者でどちらかをあえて選べと言われれば、P34の記述が妥当であると考える。

ただ、だからといって割合万能主義で良いと言うわけではない。
割合は、分母と分子が比例関係にあることを前提にしているので、比例関係にないと思われるときには当然使えない。

10ページの設計書のレビュー指摘密度と200ページの設計書のレビュー指摘密度は同じです・・・に同意できるか否か。
同じと言う人は、管理限界を広く、違うと言う人は狭く取るのであろうから、一概にどちらが間違いとは言えないが、このような特性は理解した上で、定量的品質予測は行われなければならない。

尚、本書では「図表3.1-14 プロダクトとレビュープロセスの品質予測・評価の指針」においても「レビュー指摘件数の絶対値が少ないときは、レビューが不適切と予測し」と書かれている。

レビュー指摘密度とレビュー指摘件数の絶対値の両方で評価しろと言いつつ「単に件数の多い少ないだけでは、規模によって多くて良い場合、少なくてよい場合があるので、レビュー対象規模もしくはレビュー工数あたりの件数の密度で評価することに意味がある」というのであるから、理由があるはずなのだが、それが読み取れるような記述はない。

2008年11月14日 (金)

【定量的品質予測のススメ】「策」の3乗(対応策は対応策を策定する)

P45「3.1.5 要求分析・設計の品質予測のまとめ」の「図表3.1-12 要求分析・設計の品質予測の注意点」において「対応策は、対応コストに見合った効果がある対応策を策定する」とある。

P35「図表3.1-4 チェックリストの例」において「要求分析のレビュー指摘チェックリスト」の例が掲載されている。
ここで「非曖昧性」として「主語が明確であるか」と挙げられている。

さて、「対応策は、対応コストに見合った効果がある対応策を策定する」の主語は何であろうか。

「対応策は」であれば、述語は「(対応策を)策定する」となるが、「対応策は、対応策を策定する」というおかしなことになってしまう。

無理に「主語が明確であるか」をチェックしすぎたのであろうか。
そうではない。
ここは、主語はあえて書かなくても良い文であり、この「対応策は」は主語ではないと理解するのであろう。

「対応策は、対応策策定者が、対応コストに見合った効果がある対応策を策定する」

という意味であり、主語は「対応策策定者」なのであった。

あたりまえ、省略しているだけだ、と言われそうであるが、ならば、
もっと、省略して、
「対応コストに見合った効果がある対応策を策定する」
か、
「対応策は、対応コストに見合った効果があるよう策定する」
とすべきであろう。
更に言うならば、
「対応策は、コストに見合った効果があるよう定める」
で良いのではないか。

2008年11月13日 (木)

【定量的品質予測のススメ】値が許容範囲内にあるときでも、プロダクト品質が保証されているとは言えないことの理解

P45「3.1.5 要求分析・設計の品質予測のまとめ」の「図表3.1-12 要求分析・設計の品質予測の注意点」において、品質予測を行うための実務的な注意点がまとめられている。

その中で「データ分析時」として「値が許容範囲内にあるときでも、プロダクト品質が保証されているとは言えない(レビュー指摘内容の分析が必要)」とある。

どう言う意味であろうか。

・値が許容範囲内にあるときでも、プロダクト品質が保証されているとは言えない。
・レビュー指摘内容の分析が必要。

では、何のために要求分析・設計の定量的品質予測をするのであろう。

レビュー指摘内容の分析は、どちらかというと、定性的分析をである。
「値が許容範囲内にあるときでも、プロダクト品質が保証されているとは言えない」のならば、要求分析・設計品質予測をする意義は何なのであろうか。

言いたいのは、プロセス品質の定量的数値が許容範囲内にあるときでも、プロダクト品質が保証されることにはならない、ということだろう。

プロダクト品質が保証されることにはならないのに、プロセス品質の定量的数値を計測し、品質予測するのは何のためなのだろうかが、説明されていない。

この説明なしに定量的品質予測をススメるのはなぜなのだろうか。
ソフトウェア開発には、プロダクト品質以外にも向上させなければならない何かがあるからであろう。
その何かがここに合わせて書かれないと、
「値が許容範囲内にあるときでも、プロダクト品質が保証されているとは言えない」のならば、要求分析・設計品質予測をする意義は何なのであろうかという問いに答えることはできない。

2008年11月12日 (水)

【定量的品質予測のススメ】測定単位フラクタル

P44「(3)潜在誤り予測(後工程)」において、「組織的に統計処理したデータやモデルの活用は有効であるが、自部門や事業分野ごとのデータを蓄積し、統計処理やモデル化したものを活用した方が予測精度は向上する」とある。

これを読んで合点がいくであろうか。

「組織的に統計処理したデータやモデルの活用は有効であるが、「自部門や事業分野ごとのデータを蓄積し、統計処理やモデル化したものを活用」は、「組織的に統計処理したデータやモデルの活用」例ではないのか。

それとも「自部門や事業分野」は「組織」ではないというのだろうか。

おそらく、「組織的に統計処理したデータやモデル」でいう「組織」は、「自部門や事業分野」の上位概念例えば全社、更にはSI業界をイメージしているのであろう。

しかし、これを素直に読んで理解するのは難しいであろう。

加えて、この論法が成り立つのであれば、次の記述がなぜないのかということにはならないか。

すなわち、「自部門や事業分野に統計処理したデータやモデルの活用は有効であるが、個々のシステムごとのデータを蓄積し、統計処理やモデル化したものを活用した方が予測精度は向上する」という記述。

これを繰り返せば、予測精度向上のフラクタル論法が成り立ってしまう。

しかし、だからといって、「ソースごとに統計処理したデータやモデルの活用は有効であるが、個々のステップごとのデータを蓄積し、統計処理やモデル化したものを活用した方が予測精度は向上する」は直感的に成り立たない気がするであろう。

ところが、P11「2.2.1 測定単位(品質管理単位)」において「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」と書かれている。

本書は、「ソースごとに統計処理したデータやモデルの活用は有効であるが、個々のステップごとのデータを蓄積し、統計処理やモデル化したものを活用した方が予測精度は向上する」と信じているのであろうか。

定量的品質予測には、適切な測定単位と測定対象範囲がある。
細かいメモリの物差しで測定できるからと言って、測定対象がそのメモリ以上の揺らぎを内包もしくは許容するのであれば、物差しの限界を追求する必要はない。

精緻なハカリを持っているからと言って、「塩ひとつまみ」って、何ミリグラムのことですかと聞く人はいない。
なぜなら、そもそも味をつける対象が、にんじん中二本とかいうアバウトさなのだから。

2008年11月11日 (火)

【定量的品質予測のススメ】実データ3点に基づく±6σの管理

P43「(2)レビュープロセスの評価(現工程)」の最後の文において「プロジェクト内の実績値をもとに管理限界を設定する方法は、最初のドキュメントのレビュー実績(3回以上)を使用して標準偏差を算出し、管理限界を設定する」とある。

「管理限界を設定する方法は、・・・管理限界を設定する」という主語述語のアンマッチはともかく、「最初のドキュメントのレビュー実績(3回以上)を使用して標準偏差を算出し」については検討を要する。

P27「2.3.7 モデル利用上の注意点 (2)入力データのチェック」において「母集団が正規分布に従う場合、±3σをわずかに超えたデータは管理限界を超えたデータでは合ってもモデルの対象外のデータとは言えないことが多い。それに対して、±6σを超えるものは明らかに特異なデータとみなすことができるであろう」とある。

これらを合わせ考えれば、3点しかデータが無くとも、±6σの管理はしろと言っている。

一方で、P20「コラム モデル化時の注意点」において、「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」と書かれている。

これからは、3点しかデータが無い場合などそもそも想定していないのではないだろうか。

3点あればσは計算できるかもしれない。
しかしそこに6σを管理する意味があるのだろうか。

定量的品質予測のススメというのは、何でも測れれば使ってしまえと言うことであろうか。

2008年11月10日 (月)

【定量的品質予測のススメ】品質の評価と予測

P41「3.1.4 品質の評価・予測の適用領域と分析指針」とあるが、どうも本文においては評価・予測の語が厳密に使い分けられていないようである。

「(1)プロダクトの品質の予測(現工程・後工程)」という項目は「プロダクトの品質の予測・評価は・・・」で始まる。

項目名にはない「評価」が書きだし文で項目名にある「予測」と並列で書かれている。

項目名と本文で整合性を取るなら、
   「(1)プロダクトの品質の予測・評価(現工程・後工程)」

   「プロダクトの品質の予測は・・・」
とすべきではないだろうか。

ただし、本文内での使い方をみる限る、「予測」と「評価」の区別はあまり意識しなくとも良いようである。

2008年11月 7日 (金)

【定量的品質予測のススメ】主語の明確化

P35「図表3.1-4 チェックリストの例」において「要求分析のレビュー指摘チェックリスト」の例が掲載されている。
ここで「非曖昧性」として「主語が明確であるか」と挙げられている。

これを踏まえてP40「コラム 仕様変更による影響度合いの定量化」の記述を見てみる。

ここでは、

「【基本測定量と導出測定量】
この測定量は、仕様変更が発見された工程と混入工程の距離と仕様変更の重大度を掛けることにより、手戻りの『長さ』と『範囲(幅)』を考慮した測定量を算出する。(以下略)」

と書かれている。
まずこの文の主語は何であろうか。

いきなり「この測定量は」と書かれている。確かに「~は」となっているので、文法で言えば「主語」と言えよう。
しかし、見出しは「基本測定量と導出測定量」である。
ならば複数を表す「これら測定量は」とすべきであろう。

それ以前に、見出しで使っているからと言って文頭でいきなり「これら」と書くべきではなく、本文ではちゃんと「基本測定量と導出測定量は」と書くべきである。

ここまでは、表現の方法の問題。

次に、実質的な記述の中身を見てみる。

「この測定量は、仕様変更が発見された工程と混入工程の距離と仕様変更の重大度を掛けることにより、手戻りの『長さ』と『範囲(幅)』を考慮した測定量を算出する」の主語と述語に注目。

「この測定量は」「算出する)」という。

しかも、長い文なので、「この測定量は、・・・測定量を算出する」と読んでしまいそうである。

非常にわかりづらい。

本来は次のように言いたいのであろう。

つまり、見出しが「基本測定量と導出測定量」となっているが、書きだしの「この測定量は」は、「基本測定量」を指し、後に来る「測定量を算出する」は、「導出測定量を算出する」なのである。

しかしそれでも「基本測定量は、・・・導出測定量を算出する」というのは意味が分かりづらい。
基本測定量は自律的に算出するのであろうか。

結局文を整えて、

「基本測定量に対して、仕様変更が発見された工程と混入工程の距離と仕様変更の重大度を掛けることにより、手戻りの『長さ』と『範囲(幅)』を考慮した導出測定量を算出することができる」

というのが、本来記述したい内容であろう。

しかし、この文では主語がない。
「非曖昧性」として「主語が明確であるか」のチェックに引っかかってしまう。

だから、仕方なく「この測定量は」と主語を明確化したのかもしれない。

2008年11月 6日 (木)

【定量的品質予測のススメ】レビュー工数は、レビューアのレビューに要した時間か

P35「3.1.3 方法(項目、手法)(1)分析と測定項目(c)レビュー工数(基本測定量)」において「レビュー工数は、レビューアのレビューに要した時間である」、「有識者以外(育成等を目的とした要員)のレビューアのレビュー工数は、レビュー工数から除外する、または適切な係数で補正することが望ましい」とある。

もう2つ、除外もしくは補正することが望ましいポイントとして、
  ・定量化による予測が目的であれば有識者なら何人いてもレビュー工数計上して良いわけではない
  ・レビューで対応策等を議論をしてはいけない。もしくは当該議論の時間は計測対象外とする
を挙げておく。

有識者30人のレビューといえば壮観であろうが、だからといって1時間実施しただけで30人時分レビューしたとは言えないし、議論というものは、始めるとどれだけ時間がかかるかは論点によってまちまちであるので、これを含めるとただでさえ人間系が関与する計測値が更にぶれてしまうと容易に想定できるためである。

有識者以外のレビューアのレビュー工数は、レビュー工数から除外するのはわかるが、適切な係数で補正することが望ましいというのはわからない。
「適切な係数で補正」というと納得しそうであるが、「有識者以外のレビューアのレビュー工数」の「適切な補正係数」とはどう定めるのだろうか。

「適切な補正係数」ではなく「テキトーな補正係数」なら定められるが・・・。

2008年11月 5日 (水)

【定量的品質予測のススメ】単に件数の多少ではなく密度で評価することの是非

P34「3.1.3 方法(項目、手法)(1)分析と測定項目」において「単に件数の多い少ないだけでは、規模によって多くて良い場合、少なくてよい場合があるので、レビュー対象規模もしくはレビュー工数あたりの件数の密度で評価することに意味がある」と書かれている。

レビュー対象規模もしくはレビュー工数と指摘件数が線形になることを前提にしているようであるが、自明であろうか。

あるプロジェクトにおけるレビュー対象規模を1としてその10倍、100倍のレビュー対象規模のプロジェクトがあったとする。
レビュー指摘密度・レビュー工数密度は、どれも近い値、単一の指標で評価できる値になるか。

ここでは、何のために指標を定めるかから考える必要がある。

レビュー指摘密度、レビュー工数密度など、「がんばれば」いくらでも作れる。
目標を立てたら、ちゃんと遵守し、毎年目標値を見直しても、ちゃんと達成できる組織はすばらしい組織であろうか。

5枚の設計書で表現できるプロジェクトにおけるレビュー指摘密度、レビュー工数密度を用いて、100枚の設計書が必要なプロジェクトにおけるレビュー指摘密度、レビュー工数密度を評価できるのであろうか。

しかし、指標値を定めた上で、達成せよと言えば達成されてしまうし、達成されたら満足してしまう。

100枚の設計書でレビューすべき事項は、5枚の設計書でレビューすべき事項より多いはずである。様々な関連を考慮しなければならないのであるから・・・と言いたいが、そうとも言えない。5枚の方の設計書が難しい論理式が並んでいる一方で、100枚の方の設計書の大半が設定パラメータの羅列だけであった場合はそうとも言えないであろう。

それでも使えないわけではない。
「おおよそのつかみ」のために活用することはできるであろう。

ただ、「指摘があと4件足りない」というようなことはやめた方が良い。

厳密に適用しており、毎年指標が向上していると言う組織は、喜んでいるのではなく、「本当は絶対的にレビュー指摘密度、レビュー工数密度が低すぎるのではないか」と疑っても良いかもしれない。

どの指標でもそうであるが、「本当に比例関係にあるのか」も考えなければならない。
信頼度成長モデルでは、指数形モデルやゴンペルツ曲線などと言っているのであるから、ほかの指標も敏感になった方が良いはずである。

確かに、線形(比例関係)であると考えた方が数値を扱いやすいというのは理解できる。
しかし、扱いやすいからといって線形で考えたいと言うのと、それで品質予測ができるか否かと言うのは別な話である。

横軸がプロジェクトの開発規模(FP等)で、縦軸にそのプロジェクトで発見したエラー数を取ったグラフで、大多数が小規模プロジェクトであるが、大規模の1つ2つのプロジェクトによって傾きが決定されているような図を見たことはないか。

白書系書籍で簡単に見つけられるこれら正比例のグラフは、次の大規模プロジェクトデータが入ってきたらそれでまた大きく傾きが変更される要素を含んでいる。

人によっては「新しいデータが入ったのだから指標が変わって当たり前」という者もいる。
そうなのだろうか。

指標を何に使うかがやはり重要である。

2008年11月 4日 (火)

【定量的品質予測のススメ】要求分析、要件定義、要件の定義、要件の確定

P29「3.1.2 アプローチ」の図表3.1-1において「要求分析・設計」と書かれている。P11図表2.1-1では、「要件定義」となっており、P40「コラム」では「要件の定義、要件の確定」と出てくる。

「要求分析」、「要件定義」、「要件の定義、要件の確定」は、同じなのであろうか、それとも異なるのであろうか。
同じであれば用語合わせた方が良いし、異なるのであれば、それぞれ定義するか分かるように記述すべきであろう。

2008年11月 3日 (月)

【共通フレーム2007】「支援ライフサイクルプロセス」と「支援プロセス」

P146「2. 支援ライフサイクルプロセス」において、「支援プロセス」という語がある。
しかし、これは「図2-14 共通フレーム2007体系」には無いプロセスである。

読めば、「支援ライフサイクルプロセス」と「支援プロセス」とは同じ、もしくは「支援プロセス」は「支援ライフサイクルプロセス」を構成する個々のプロセスであろうことは「推測」できる。
しかしこれは「推測」であって、本当は違う意味で使われているのかもしれない。

共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っている。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

2008年11月 2日 (日)

【共通フレーム2007】監査において「問題点」か否かを判定するのは「監査した者」ではなく「監査を受けた者」

P170「2.7.1.6 監査結果と対応策の報告」には「監査終了後、監査結果を文書化し、監査を受けた者に配布する。監査を受けた者は、監査で見つけられたあらゆる問題点及びそれらを解決するための計画を、監査した者に知らせる」とある。

監査で見つけられたあらゆる問題点は監査を受けた者が監査した者に知らせるということは、「問題点」か否かを判定するのは「監査した者」ではなく「監査を受けた者」ということになろう。

ここでの監査と言うのは、警察的取り締まりの意味の監査ではなく、自律改善のための健康診断という位置付けのものと考えれば、これは納得できる記述である。

2008年11月 1日 (土)

【共通フレーム2007】選ばれた成果物及びプロセスとは

P169「2.7 監査プロセス」の「目的」では「監査プロセスは、選ばれた成果物及びプロセスが、要求事項、計画及び合意に対して、適合しているかどうかを独立して決定することを目的とする」とある。

ここでいう「選ばれた」とは何を意味するのであろう。

大きく分ければ、次の2つの考えがあろう。
  「対象とされた文書すべてを監査するのではなくサンプリングして監査する」という意味
  「あらかじめ、何を監査するかを決定しておいて、対象はすべて監査する」という意味

どちらなのか、それともさらに別な定義なのか。

ガイダンスに書かれるべきであろう。

とはいえ、常識的に考えれば前者であろう。

« 2008年10月 | トップページ | 2008年12月 »