【ソフトウェア開発の定量的管理】基準値と目標値

定量的管理において難しいのは、一度基準値を設定すると、開発者は設定前と同じ状態で開発できるわけではないということ。

別に「あるべき数値」になるように開発をするのであるから何ら問題はないと言うこともできる。ナイーブな人ならばそれで納得するであろう。

しかし、少し考えれば、この状態は悲観したくなるだろう。
基準値が目標値になると、統計的コントロールは非常に困難になる。なぜならば一旦定められた目標値に開発者は縛られるのだから。

よって、基準値設定は非常に慎重に行うべきであると考える。

とはいえ、目標値を定め管理することがビジネス上悪いというわけでもない。
単に統計的に妥当な数字ではないというだけのことだ。

定量的管理という点では、目標値という定め方は問題ないが、定量的品質予測という点では、それ以降の管理ができなくなる可能性が非常に高まるであろう。

基準値と目標値・・・同じように使ってしまいがちであるが、厳格に区別して考えるべきものである。

【続定量的品質予測のススメ】 プロジェクト品質目標の伸縮

Ｐ６１「統計値は、過去のプロジェクトの実績を統計分析して得られた値であるから、たとえ同一プロジェクトでもそのまま現在のプロジェクトの目標として設定すべきではない」とある。

「たとえ同一プロジェクトでも」の部分の取り扱いは難しい。

現在実施しているプロジェクトの現時点までの実績は、そのままの形では統計値としてこれ以降のプロジェクトを進めるにあたっての目標値としてそのまま使用してはならないと言っている（と取れる）。

言いたいことは分かる。
同一プロジェクト中の小単位の中にも統計的観点で見た場合には様々な差異があるということだろう。
しかし、そもそもソフトウェアは同一の製品を作っているわけではない。差異を言い出したらキリがないのではない。この論法では、最終的にはコマンドごとに目標値を定めるとかいう次元に行きつくのではないだろうか。

そもそもだからこそ統計的に語っているはずである。

とはいえ、解決策が示されていれば主張することは構わないので、本書で示されている解決策をみると次のようになっている。

「現在のプロジェクトメンバのスキル、技術的な難易度、規模、工期、開発環境などの諸条件のなかで、特に変化した特徴的な部分があれば、その影響度を統計値に加味し、妥当性、納得性のある目標値を設定することが大切である」

どうだろう。
やろうとしていることは、プロジェクト目標値では不十分だからプロジェクト内の細分化された小単位の中での目標値を定めようということだろう。
であれば、その影響度は統計的に定められなければ意味がない。

よって、「その影響度を統計値に加味し」とあるが、これは「その影響度を統計的に加味し」とした方が良いと思われる。

現在のプロジェクトメンバのスキル、技術的な難易度、規模、工期、開発環境などの諸条件の差は、統計的に表現される必要がある。
そうでなければ、せっかくの統計的に算出したプロジェクトの目標値が台無しになるだろう。

「妥当性、納得性のある目標値」を算出するのに、プロジェクトメンバのスキルを松竹梅、技術的な難易度を高中低、規模を大中小、工期を長並短、開発環境を良並悪などというぶっちゃけた影響度を加算するのでは、（アバウトながら）精度は下手したら２ケタ落ちるだろう。

よって、この詳細な目標値設定方法に、定量的品質予測を希望する組織は頭を悩ませ答えを求めるのである。

しかし、残念ながら本書では、肝心のその算出方法が書かれていない。
これこそまさに企業秘密であり、競争の源泉だから書かれていなくとも仕方がないと思わねばならない。残念ながら。

【続定量的品質予測のススメ】 プロジェクト品質目標

Ｐ６０～６１「適切な目標設定」について。

前半は、定量的品質管理における品質目標のあるべき姿について書かれている。
これはあるべき姿なので、そんなに簡単にできるのだろうかということはあるがそのままスルーする。

Ｐ６１頭では
「実績データから得られた統計値に対し、品質目標は、
　　①実際のプロジェクトの特徴を分析して得た所見
　　②プロジェクトとしての到達意欲
の２つを加味して設定する。
」とある。

定量的品質目標と定性的品質目標を合わせた場合には、これはそのまま受け入れられよう。
しかし、本記述は定量的品質管理に関するものである。
定量的に意味のある①②とは何かを考える必要があろう。

本書では、これにつきページを割いて解説されているので、よく読み自組織でよく考えて対応すべきであろう。
プロジェクト目標値の設定…これは本当に難しいことであると思うから。

個人的には、プロジェクト目標値の設定は純粋に定量的方法で行うべきで、定性的なニュアンスを入れてはいけないと思う。しかし、それは非常に難しいと思う。

プロジェクト目標値の導入は理解はできる。しかし、現実にはしない方が良いのではと考える。
プロジェクト目標値を導入して上下限値幅を狭めようとするより広いままでよいのではないかと思うのである。

【続定量的品質予測のススメ】 「できるだけ客観性があり」の良否

Ｐ４２　「２）リスクの評価手順」の「手順１）システムリスクの評価」において「評価方法は、できるだけ客観性があり」と書かれている。

これは「手順２）プロジェクトリスクの評価」においても書かれている。

客観性は「できるだけ」で良いのだろうかという疑問が生じる。
しかし、この場合は良いと考えられる。

ここではリスクを取り扱っており、かつ評価方法の例として、
「④各要素の状況（値）と重み（値）の乗算結果を合計し、総合評価（ランク付け）する」
とあるように、そもそも客観性を精緻に捉えることは必要と考えていない。

よって「できるだけ」で構わないのである。
しかし、そもそもこれはいわゆる「定性的リスク管理」の方法の説明であり、なぜこれが定量的品質予測のガイド本に詳細に書かれているのかはよく分からない。

【又々信頼度成長曲線】「同じテストを繰り返せば曲線は収束するよね」が本質なのか

ISSRE2011のIndustry Papers発表にてTakeo Niwaさんが信頼度成長曲線について発表していた内容を記しておく。

＜発表概要　始＞－－－－－－
横軸が実行済みテストケース数の場合における信頼度成長曲線収束の意味についての発表。

立ち上がりや収束の振る舞いといった曲線の傾向がテスターの恣意やテストケースの実行順に由来するものでない場合、あるテストケーススイートにおける曲線の傾向は、テストケースの実行順に関わらず同一であるはずとし、その上で次のような思考実験を行っていた。

対象テストケーススイートの中で、全てのエラーが、
　　①各々１つのテストケースでしか発見できない場合
　　②各々２つのテストケースで発見できる場合
　　③各々３つのテストケースで発見できる場合
　　④各々N＋１つのテストケースで発見できる場合

に、テストケーススイート中のテストケースを乱数を用いてランダムに順序付けして実行した場合に得られる信頼度成長曲線は、それぞれ、

　　①直線
　　②収束しつつあるように見える曲線
　　③②よりもより収束しているように見える曲線
　　④Nつのテストケースの場合よりもより収束しているように見える曲線

となる。

以上から、信頼度成長曲線の傾向がテスターの恣意やテストケースの実施順に由来するものでない場合、エラーを発見できるテストケースに重複があれば、曲線は収束傾向を示し、テストケースが重複するエラーの数が多いほど、また個々のエラーに対し重複するテストケースの数が多いほど、早期かつ明瞭な収束となると言える。

これは、他に曲線が収束する要因があるか否かに関わらず成り立つ。

よって、信頼度成長曲線におけるテスト十分性の要素の１つとして「テストする内容が複数のテストケースで重複していること」があると言える。

ではこの「重複していること」のテスト十分性における意味は何であろうか。
重複していることが、テスト十分性の観点から良いことであるならば、極端な話、同じテストケースを何度も繰り返せば良いことになるし、現にそれで収束していくだろう。しかし本当にそれで良いのであろうか。

＜発表概要　終＞－－－－－－

最後の部分は問いかけで終わっており、発表内では答えは示されなかったのですが、どうなのでしょう。

確かに、過去、「テストケースを３回回せ。そうすれば収束する」みたいなことを言うコンサルもみたことがありますので、重複が重要と言う人もいるとは思いますが、違和感を覚えます。

発表では、まず最初に「信頼度成長曲線が活用されることは多いが、直観的に理解しているだけでなぜ傾きが寝ると信頼度が上がるのかを論理的に説明できる人は少ない」とも言われていた。

これは皆様どう思われますか。

【事務連絡】再開します

長期にわたり更新しませんでしたが、ゆっくり再開します。

最初はやはりというか、信頼度成長曲線です。
これについては、今まで否定的もしくはうがった見方ばかりしてきましたが、実は非常に味わい深く面白い玩具です。

【続定量的品質予測のススメ】 適切な作業量の品質管理方法

Ｐ４０に「プロジェクトには、そのプロジェクト特性に応じた適切な作業量の品質管理方法を提供する必要がある」となる。

その通りである。
ではどうすれば良いのか。

本書では、それにつき少しだけ掘り下げて記述している。
文は前後しているが同頁に「プロジェクトの品質を確保するプロセスとして重要なのは、Ｃ）プロジェクト管理プロセス、Ｄ）品質保証（ＱＡ）プロセスである。かれらの管理プロセスの軽重は、プロジェクト開発現場の負担感に特に敏感に影響するので、明確な合理性・十分な納得性をプロジェクト関係者に示すことが大切である」と書かれている。

これ以上は、ＰＭ、ＱＡ、上位管理層が信念をもってプロジェクト関係者に説明をすることにかかっているのだろう。

そして、品質関連プロセス推進に対するコスト・負担からの反対論に向き合う仮定で、より合理的な管理の芽が見つかるかもしれない。

但し、少し気になるのは「プロジェクトには、そのプロジェクト特性に応じた適切な作業量の品質管理方法」という文言である。
「プロジェクト特性に応じた適切な作業量」をプロジェクト毎に明確に定めることはできるのだろうか。

【ソフトウェアメトリクス】同じチームだから、同じということ

ソフトウェアのメトリクス管理において「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」というようなことが言われたりする。

これはどういう解釈すべきか。
同じメンバーなら同じ結果というのであれば、野球、サッカーにどうして人は熱狂するのであろう。
ソフトウェア開発とスポーツは違うのか。
違うとするならばどこが違うのか。

百歩譲って「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」が、統計的に成立するとして、しかし、その許容すべき誤差は最初から大きめで、沢山のプロジェクトを総括する際には良いかもしれないが、開発中の特定のプロジェクトに対し評価等を行うのは、見積もり時以外かなり厳しいしいと考えられる。

「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」と言うこと自体に問題があるわけではなく、それはちゃんと検証してから使うべきというのである。

いやいやそれは仮定であって、それで良いのだよ…と言われるのであれば、もはや何も言うまい。

【続定量的品質予測のススメ】組織ごとに特徴があり・・・

Ｐ３９「（２）品質管理レベルの特定」にて、「ＩＴシステム開発を担う組織ごとに特徴があり、開発文化が異なるので、それぞれの組織が自分自身を分析し、実情に合ったプロジェクト特性要素を決めることが肝要である」という記述がある。

組織間ではプロジェクトの特徴が大きく異なるので、それぞれに合った管理をせよということである。
これはしかし、定性的管理であればそれもそうだろうと納得できるが、定量的管理においては、この考えは少し疑問に思う。

「組織ごとに特徴があり」という言葉を許すと、「プロジェクトごとに特徴があり」や「機能ごとに特徴があり」とそれぞれ特徴を強調することを許しても何ら問題ないことにはならないのだろうか。

いやいや、組織ごとはわかるけれど、プロジェクトごとや機能ごとは行き過ぎだろう・・・といえれば良いが、言えるのだろうか。

定量的管理は、複雑なソフトウェア開発について、ある1つまたは複数の特徴に着目しその他は捨象して行うものであるので、「○○ごとの特徴」は捨象するか、そもそも管理のモデルの中に組み込むべきだと考えるため、「組織ごとの特徴」のみを強調することに違和感を覚えるのである。

自分の組織は特別だ・・・というのは、定量的管理に消極的な組織から出てくる典型的言い訳だそうだが、「組織ごとの特徴」の強調は、まさにこれに裏書を与えているのではないだろうか。

これを読まれている皆様の組織においては、どのように考えますか。

【続定量的品質予測のススメ】過剰な管理とは何か

Ｐ３８に「計量した『量』に応じて品質管理方法を選定し、必要な管理項目や管理強度を設定することは、過剰な管理を防止し、効率的なプロジェクト運営に役立つ」とある。

一般論として、正しいと思われる。

しかし、これを現実のソフトウェア開発プロジェクトに当てはめるとどうだろうか。
着目すべきは「過剰な管理を防止し」である。

「過剰な管理」はもちろん誰もがしたくない。
では、過剰か否かはどのように決めるのであろう。

戦略的重要度や顧客インパクト等過剰判定の切り口は色々あろう。

ここで、少し話を変えてソフトウェア開発における品質が良いというのはどういうことであろうか。
色々あるとは思うが「致命的な障害が発生しないこと」というのも現在においては重要な位置を占めている組織が多いのではないだろうか。

しかし、この「致命的な障害が発生しないこと」というのは非常に難しい課題ではないだろうか。
バグはどこに潜むか分からない。類似原因のバグでも、埋め込まれた場所次第で発生する障害が致命的であるか否かは異なることは珍しいことではない。

このようなバグに対する取組みの難しさに対し「過剰な管理を防止」するにはどうすればよいのだろうか。

もちろん、バグに対する取組みがソフトウェアの品質を担保する際のほんの一部であるのであれば、あまり意識する必要はないかもしれない。
しかし、現時点では「致命的な障害が発生しないこと」というのはソフトウェアの品質を考える点で大きな位置を占め、もしくは、中にはソフトウェアの品質イコール「致命的な障害が発生しないこと」と考えている組織も珍しくないので、これについて考えることは外せない。

「致命的な障害が発生しないこと」を品質の軸に据える限り、「過剰な管理を防止」するというのは、言うは易し行うは難しなのではないだろうか。

もちろん、その判別があまりに容易なケースがあることは否定しない。
しかし、そのほうがレアケースではないかを考えるのである。