【定量的管理雑話】定量的管理を信じない人が定量的管理推進を命じられたら

Ｑ：
定量的管理を信じないのですが、上司にやれやれ言われています。どうすればよいでしょうか？

Ａ：
簡単です。
有名どころのコンサルに頼みましょう。アドバイス業務として。
そして自分の疑問を徹底的にぶつけましょう。質疑はすべて記録してください。録音しておくことがベター。

で、あなたが納得できたら…、
おめでとう、あなたは定量的管理を始められますね。
納得できなかったら…今迄の記録をまとめて、上司に報告しましょう。もしくはコンサルの終盤に入る頃に上司も一緒に参加してもらいましょう。

しかし残念ながら定量的管理実施が自分の上司レベルではなくもっと上からの「命令」ならば頭を使うしかない。
きっと活路は見出だせる。

自分で解決できなければニーズを満たすコンサルを探せ。
先のコンサル結果を示した上で受けてくれるコンサルを。

こういう課題を提示した時に「具体的に見ないとわからない」というコンサルとそんなことに言及しないコンサルがいると思う。
前者は慎重であり信頼できるというよりも、汎用的な解を持っていないと「明言」していると考えた方が良いです。
後者は汎用的な解を持っている可能性もあるし、逆に何も分かっていない可能性もある。

そして、コンサル料は、先のコンサルより格段に高いでしょう。
・・・というより、これを受けることができるコンサルは日本に何人いるのだろうか。

【定量的管理雑話】言い訳のネタ集めとしての定量化

定量的管理は言い訳のネタ集めとして割り切ると先が開けてくる。

散々仕様変更飲まされたのに期限にバグが多かったり間に合わなかったりしたら叩かれる。しかしその変更依頼日や内容、プロジェクトへの影響が記録されていれば大丈夫。対抗できる。

しかし実は定量的データ集めの実務メリットはそれだけではない。

次からの見積もり時に、仕様変更の多さ等のプロジェクトに影響を与える特性を最初から加えることができる点だ。ここを平和的にまとめることができれば、次からはプロジェクト中の説明さえ減らすことができよう。

しかし、これはおそらく「便宜上」の定量管理であって、真の意味での改善につながる定量化ではないだろう。

【定量的管理雑話】「測る企業は成功率が2倍に」をもう少し考える

「測る企業は成功率が2倍に」で重要なのは組織文化と大括りで言えると考えたが、個別にみると、定量的管理をすれば説明責任を果たしやすくなるという面は確かにある。

６００ケースもテストしたんだよと言うより今回のテスト密度はこれこれなので過去データから見て十分と言った方が顧客や上位管理層も納得する＝つまり「成功」に近づく。
何かあっても、でも今まで通りちゃんとやったんだから不可抗力だよとなる可能性も高まる。

プロジェクトの成功とは失敗の烙印を押されないことである。だれに？顧客や上位管理層に。ならば口頭の定性的説明だけでは失敗の烙印を押される場合でも、信頼度成長曲線みたいな手法を使って相手が納得すればそれは失敗ではなくなる。「測る企業は成功率が2倍に」はそういう意味なら納得できる。

この場合相手が納得することが一番重要。厳密であるが難しい式見せても納得しないような人でも、直感的に納得できる説明なら満足するケースは多い。例えば信頼度成長曲線。これは開発現場では賛否両論あるが上記のような人には抜群の効果を示す。その理論と結果の両方が直感的かつ簡単に理解できるから。

しかし、直感的に理論が理解できて適用結果判断も直感的にできるようなものは、開発現場ではわざわざグラフ化しなくとも体感しているはず。いや、そう思っているだけで厳密には違うかもしれないからグラフ化は必要という方もいよう。しかし信頼度成長曲線に限れば体感の方に軍配をあげたい。

しかし説明責任を果たす場で抜群の効果を発揮するならそれは「有効」である。テスト密度も一緒。品質の維持改善に使う分にはこのような定量的管理は意味があると考える。

【共通フレーム２００７第２版】マイナーバージョンアップ

新しい共通フレーム２００７について見て行きます。どこがどう変わり、どう変わらなかったのかを中心に考えていければと思います。
１１月より更新していきます。

それにしても、これはマイナーバージョンアップというのだろうか。
共通フレームとしてはマイナーバージョンアップでも、共通フレーム２００７としてはメジャーバージョンアップといえそうであるし。

共通フレーム２００９としなかった点からみればマイナーともいえるが、２００９年も終わりに近づいた今、２００７というのもインパクトに欠けるのではないだろうか。

【定量的管理雑話】測る企業は成功率が2倍に・・・これ自体定量的にいかがなものか

「測る企業は成功率が2倍に」という日経コンピュータの記事（２００８年１２月１日号）
http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323651

これの意味するところは何か。
「そうか・・・では我々も定量的管理をしよう。しかし負荷をかけたくないしよくわからないから上手くいってる組織の管理項目を聞いてそれを実践しよう」という考えは是か否か。

もうひとつ記事を。
子供の学力は親の年収に比例する傾向にあるそうだ。ただ年収が低くとも、ニュースについて語りあったり読み聞かせしたりする家庭の子は学力が高いらしい。
http://www.yomiuri.co.jp/kyoiku/news/20090805-OYT8T00352.htm

それでどこかの教授が、「低所得でも親の心がけ次第で学力向上につながる」とかなんとか間抜けなコメントをしていた。なぜ間抜けか。

持たざる者は工夫で乗り切れと言っているのだ。
所得による教育格差が小さな差であればそれは可能であろう。
しかし、本当に工夫で乗り越えられるのであろうか。
敵戦闘機に対して竹やりで頑張れみたいなことを言っていないか？

まあ、確かに大学受験のために塾に行ったり家庭教師を雇うのにお金はかかる。
だからそれをお父さんお母さん方が代わりに教えれば金はかからない・・・というのならば納得はできる。しかし、大学受験のための勉強を教えられる父母がどれだけいよう。

読み聞かせしたりニュースについて語りあったりする家庭は、それだけしているわけではない。親が子に何をすべきかを考えて色々行っているのだ。その一例が読み聞かせ等であるにすぎない。だから読み聞かせやニュースについて語り合うことだけすすめても意味がない。

ポイントは、読み聞かせたりニュースについて語り合う家庭環境にあるのかだ。この環境が家庭内になくても、親の年収があれば塾や習い事で補われるということではないだろうか。逆に親が今の生活に精一杯ならば、読み聞かせ等はしたくてもできない。結局、一義的には親の年収が重要だと思われる。

しかし年収はそれほど多くなくとも読み聞かせやニュースについて語り合うことができる家庭はあろう。ここで間違えてはいけないのは読み聞かせとニュースについて語り合うことだけ実践すれば良いと考えることだ。この二つは親の年収に関係なく成績が良い子をあぶり出す単なるパラメータに過ぎない。

これが必要十分条件ではない。要は読み聞かせやニュースについて語り合おうという家庭内の文化があるか否かがポイントなのだ。しかしこの文化をマニュアル化することは難しい。勢い読み聞かせをすすめる某教授みたいなことになってしまう。

教育の専門家ではないのでこの件はこれくらいにして、ソフトウェア開発組織の定量的管理に戻る。ポイントは同じ。定量的管理を行う組織のプロジェクト成功率が高いのは定量的管理を行っているからと短絡的に考えるべきではない。定量的管理を行おうと思える組織文化が成功率を上げていると考えるべき。

だから開発が上手くいかない組織が定量的管理を始めたからといって成功率が上がる保証はない。というか個人的には必ず下がると言いたい。定性的にやることやらずして定量的管理はできないだろうから。定性的に見つけられることをわざわざ定量的に発見して嬉しい組織は別だが。

長々と書いたが、要は定量的管理を行う組織の成功率が高いからといって定量的管理を始めるのはナンセンスだということ。そんなことを言い出す上位経営層がいたら「花さかじじい」を読み聞かせると良い。表層的な形だけマネた隣りのじいさんがどうなったか教えるために。舌切り雀でも可。

以上のように考えれば、この「測る企業は成功率が2倍に」という記事自体が、定量的に怪しいのではないかと検証されるべきだと思う。
詳細に分析したら、「測る企業は、測らない企業より多く成功率向上のための他の施策を行っていることが多い。このため、実は測ることは成功に何の因果関係もないが、他の様々な施策の結果により成功する確率が高いのである」という結果になったりして・・・個人的にはこれは十分あり得る話であると考えている。

まあ、雑誌の記事なのでキャッチーな方が良いとも言えるが、これを見て「測る企業は成功率が2倍だそうだからうちも測ろう」という人が周りにいたら、「ちょっと待て」と言ったほうが良い。昔の記事だし、もう始めているかもしれないが。

バナナダイエットでバナナだけしか食べなかったらきっと病気になります。
一方、神に感謝する生活をしていれば、本当は神などいなくとも幸せに暮らせるでしょう。
何か変なたとえ。

【定量的管理雑話】パラメータ追加でメトリクスの精度を上げることについて

品質系カンファレンスの経験発表においては、今後の改善策として、測定するパラメータの追加でより詳細に計測し制度を上げていく…というパターンが昔からある。

このパラメータ追加でメトリクスの精度を上げようという試み。
気持ちは分かる。
しかし、そもそもなぜメトリクス管理を行うか振り返るべきである。
複雑で混沌としたソフトウェア開発プロジェクトの状況を、特徴的に表すパラメータに着目して人が認識できるようにしようというのが、定量的管理の元々の目的のはず。

なのにパラメータ増やしたらまた混沌とするのではないか。
バグ密度測るのに１００個のパラメータ計測するか？
所詮は、発見バグ数を開発規模で割るだけならその程度のものと文字通り割り切るべき。

まして１つのメトリクスだけで評価するのではなく複数のメトリクスを見て判断すべきだとか、管理限界を超えた値も一概にダメと決めつけずその原因を追求すべきと予防線をはる定量的管理などは、労多くして…となりかねない。

大量のパラメータからなるメトリクスデータをこれまた大量に手に入れたとして、それをどうするのか。
結局はプロマネやチームで総合的に判断することになるのでしょう。しかし、その判断は恐らく定性的に行われる。ではわざわざ計測した意味はどこにあるのか。

定量的管理の使い方を間違っているのではないだろうか。
定量的管理は何をするために行うのか今一度よく考えるべきである。

「レビュー指摘率が高いけれど○○○の理由から問題なし」「レビュー指摘率が低いけれど△△△の理由から問題なし」というような定性的分析を都合よくくっつけることで、全ての定量的アラームが、問題なしとして何も対応されないのであれば、手間をかけて定量的にデータ収集をする意味がない。

【定量的管理雑話】ロジックの理論的裏付けの弱さを収集・管理ツールで補うことはできない

工業製品の製造は組立ラインの速度といったペースメーカーがあるので人の作業が関与しても生産性を把握しやすい。逆に、如何に人の作業を速くするかで速度が決まる面もある。
究極は全自動化。

一方ソフトウェア開発にはこのようなペースメーカーはない。
計画はあるが流れ作業ではないので緻密な管理はできない。
やはりよく言われるようにソフトウェア開発には直接測れる物差しが今のところ発見されていないことと人起因およびプロジェクト毎の要件のバラツキが大きくかつ避けられないことが、定量的管理手法を難しくさせる、というかうさん臭くさせる。

このあたりを解決しようとする場合に、現行の管理ロジックはそのままで、早く・精緻で・簡易に算出するような改善を考えることよりも、開発手法自体や管理ロジック自体を論理的裏付けに基づいて変えないとダメなケースが多いのではないかと思う。

自動で欠陥密度が分かり過去データとの統計的比較からプログラムの品質がわかるようになりました…っていわれても、そもそも欠陥密度の算出方法はどうなの？それで良いの？…ということを考えた方が良いことがあると考える。

【定量的管理あれこれ①】ソフトウェアの定量的管理とPMBOKとの両立

ソフトウェアの定量的管理とPMBOKというかプロジェクトマネジメントは両立するか。
マネジメント能力に開発の成否が左右されるなら定量的管理など意味がなくなるはず。

このあたり整理が必要。

プロマネは計画を立てて管理するのであるが、実際のところソフトウェア開発において失敗プロジェクトがあとをたたない。ここに定量的管理を持ち込めば成功するのか。
それとも定量的管理を既にしていてダメなのか。定量的管理ができない分野があって、かつそこが成否のキーなのか。おそらく一面では全てが正しいであろう。

生産性…、頑張る時もあればサボるときもある人の特性を含むこの活動を、定量的に把握するためにはどのような統計的？もしくは算術的？処理をすべきか。

考慮すべきパラメータはざっとみても沢山ある。やる気、残業時間、個人差、プロジェクトの状況や時期、要件変更の頻度や時期…キリがないが、どれも生産性に大きな影響を及ぼすように思える。

そして一番厄介なのはやる気。プロジェクト初期は余裕持って臨んで、末期に徹夜してなんとか間に合ったなどという組織に生産性のメトリクス管理は早い(とはいえ現在の多くの組織がそうである気もするが)。

まずは定性的管理をしっかり行う。
ＰＭはこのあたりに重点を置いて作業を平準化してメンバーを導くことがプロジェクト管理と定量的管理の共存点かもしれない。

以上のような書きぶりでは、全然うまく伝えられていないと思うが、このあたり既にどなたかが整理されているのだろうか。

【定量的管理と定性的管理に優劣はあるのか②】定量的管理の先にあるもの

定性的管理より定量的管理の方が高度だと思いがちだが・・・。
より良い定量意的管理を行うにはどうすればよいのだろう。ツール類の進歩で定量的データが簡単に得られるようになってきている。このトレンドは今後も続くであろう。
将来的にはデータの洪水に見舞われるのではないだろうか。ここで我々はどうすべきか。定量的データを選別し、使いたい条件・精度での活用を行うのに必要なのは・・・定量的データを元に定性的に考える力ではないだろうか。

結局、定性的管理と定量的管理のどちらが高度かと考えることは意味がない。

【定量的管理と定性的管理に優劣はあるのか①】ＣＭＭＩの進化は定量的管理と共に

定量的管理と定性的管理では、どちらが高度な管理なのであろう。

ここでどちらが優れているのかと考えると変なことになる。
ＣＭＭＩでは「定量的に管理された」がレベル４なのだから定量的管理の方が優れているに決まっていると即答できれば良いのであるが、そういうわけにはいかない。

どちらも重要であるが、導入の順序でいうと定性的管理から入ることが普通…というのが模範回答と考える。

そもそもＣＭＭＩでは、マチュリティレベル４は「定量的に管理された」となっているが、マチュリティレベル２は「管理された」であって「定性的に管理された」とはなっていない。単に「管理された」だけである。

ここ、実は奥が深い。

ＣＭＭ時代は、レベル３は「定義された」で、レベル４が「管理された」であった。

つまりＣＭＭＩでは、ＣＭＭのレベル４を分断し、レベル３を間に入れたのだ。

ＣＭＭが公開されて、１０年経過した時の話だ。
そのＣＭＭＩ登場から更に１０年が過ぎた。

再度大きな波が来るか…と思いきや、来年出る予定のＣＭＭＩ　v１．３は、一応マイナーバージョンアップということらしい。
但し、マチュリティレベル４が大きく加筆されるとのこと。

これは、ＣＭＭからＣＭＭＩへ変化したときに似た行為、つまりレベル４をイジる行為に思える。
定量的管理が１０年前に比べ高度化してきていることを示すのではないだろうか。

１０年前なら「定量的管理ができている」となりえた管理手法が、今後は「レベル２の管理ですね」となってしまうということ。

さて、話は元に戻って、定量的管理と定性的管理。どちらが高度な管理なのであろうか。

難しい数式やツールを使うという点では定量的管理の方が高度といえそうな気もするが、少し考えてみたい。

例えば、信頼度成長モデル。
実績値を元に最適と思われる曲線を自動で選んでくれるなんていう便利なツールまである。
理論を何も知らない品質保証担当者が、テスト実施結果の内、数字だけしか見ずにＰＣに打ち込んだ後、「このツールによると、あと７件のバグを発見すべきなので、発見するまでテストを継続してください」と言われたらあなたはどう思うか。

これは、定められたツールによって数学上の処理を行っているわけで、特別なトレーニングも要らずツールに組み込まれた高度なロジックにより自動処理されるため、だれがやっても同じ結果がでるので、外形上は、標準化されかつ定量的な管理としては理想系と絶賛されるべきもののはずだ。

しかし、実際問題、なかなかそうは思えないであろう。
では、この管理において何が足りないのだろうか。

【ソフトウェア開発定量化再考②】とりとめもなく・・・

あなたの組織の過去データは高精度で当てになりますか。

勿論、開発ツールや方法論の進化で開発の管理精度は上がってきているので、先進的な組織では可能かもしれない。

しかし、現時点における大多数の開発組織では、そんな高度な管理ができる基盤になっていないのではないのではなかろうか。

開発品質の向上についてコンサルに相談して、すぐに定量化をすすめてきたら、「全く泳げない人に泳ぎを教えるのにタイム測るところから入るというのですか？」と切り返して反応を見てほしい。

定量化の方法が分からずにコンサルに相談しているのならば別ですが、通常はそれ以前の状態だからコンサルに相談するケースが多い。

単純割り算の欠陥密度で品質を「管理」をするのは、かなりハイレベルなスキルが要求されると思われる。
できないとは敢えて言わない。ただし、これから定量的管理を始めるという方々には絶対すすめられない。

だからといって、指標を増やせばよいというものでもない。
単純割り算の指標を１００種類集めたからといって、手間が増えこそすれ大した益はなかろう。

とにかく集めろどんどん集めろというのは、違うと考える。

しつこいが、泳ぎを知らない者にタイム計測から入っても仕方がない。
ましてや、それ加えて手を何回掻いたかとか、息継ぎ何回したかを測ることは何の益もない。

まず泳法を学ぶこと先にありきでいくべき。

しかし、ならば標準化を徹底しろと言っているのかというと、個人的には微妙に違うと考える。
ある程度の標準化は必要だとは思うが・・・。
現時点では私には「ある程度」を説明できるほど頭が整理できていないのでうまく説明はできないが・・・、
水泳の選手は、もはやどのように手足を動かし息継ぎをしということを頭では考えていないであろう。そして、基本の上に自分の体の特長や体調に応じて応用を自然に利かせて泳いでいるのではないか。そのような臨機応変さを許容する様な「型」となるような標準化であればよいが、逸脱を一切許さない「型」だと逆効果であろう。

とりとめもなく書いたため話がぴょんぴょん飛んでしまいましたが、ある意味今まで書いてきたことの総まとめの内容のような気もするのでこのまま公開します。

【ソフトウェア開発定量化再考①】大掴みで定量化を再考

定量化において重要なことは、定性的な視点による前提・仮定であると考えるのであるが…。
定量化の前提や仮定自体を定量的に定めることはできるのであろうか。

このエントリーを読んでいただいた方々、済みません。いきなりこの書き出しでは何のことか分からないと思いますが、結局、定量化とは何なのだろうと改めて考える必要はどの組織にもあるのではないか。

定量的管理というと定性的管理より凄いことしているように響くし、多分世の中ではそういうことになっていると思うのですが、実際は逆だとは考えられないだろうか。

つまり、ちゃんとした定量管理をするということは、想像力を最大限働かせて前提・仮定を決めなければならず、それには、定性的に過去の状態等を「感じる」ことが必要であると考えるのである。
となると、これは即ち定性的な管理の範囲ではないかと。

あるプロジェクトで発見された全バグ数をそのプロジェクトで開発された全ＦＰ数で割って欠陥密度測っていますと言える方たちは、定量的管理は定性的管理より優れていると真顔で言える人だと思う。

別にそれが悪いわけではない、ただ、定量的データはその前提・仮定に応じた使い方が必要だというだけである。
先の単純な欠陥密度の考え方でいえば、これで５％１０％の精度の評価をするのはどうかと個人的には考える。

欠陥密度が４．５６であるが、基準値は４．６０なので、後０．０４分だけバグを探せと言うことに意味はあるのであろうか（あえて算出式や単位は書かないですが）。

こういうことを言うと「ではどの程度なら良いのか」と言わるのですが、数字を眺めていても答えは出ない。
確かに統計的に計算すれば数字だけから色々分かるでしょう。しかしばらつきの原因がどこにあるか等を考えずに数字だけ見ていては分からないことの方が多いのではないだろうか。

そもそも、仮に同じ開発案件を複数回実施したとしたら、同じ欠陥密度になると信じられるか。

同じわけないではないか人と組織は学習するのだから段々改善していくよ、という人も中にはいよう。
しかしそのようなことを言っていたら、そもそも過去のデータに基いた定性的管理の前提が崩れてしまう。

先の欠陥密度の例では、大体これくらいバグが出てくるね・・・程度の使い方しかできないのではないか。
個人的には、これで「管理」と呼べるような活動をするのは無理だと思う。

【ソフトウェア生産性の定量的管理とは③】ＬＯＣで測る生産性

「ソフトウェア品質工学の尺度とモデル」(Stephen H. Kan 著　古山恒夫・富野壽 監訳　2004,　共立出版株式会社) Ｐ７５には、生産性の研究におけるＬＯＣの使用は問題が深刻として、次のように記述されている。

「ソフトウェアの生産性に関してＬＯＣを用いることは、飛行機のスピードと能力を測るために飛行機の重量を用いるようなものである」
「ＬＯＣは生産性においては非常にミスリーディングで、Ｊｏｎｅｓは『複数言語にかかわる全ライフサイクルアクティビティの生産性研究におけるＬＯＣの使用は、職業的不当行為とすら見なされる』と述べている（Ｊｏｎｅｓの資料　１９８６，１９９２，１９９４，１９９７，２０００参照）」（ここでＪｏｎｅｓとはＣａｐｅｒ　Ｊｏｎｅｓのこと）

そんなことはない、生産性をＬＯＣで評価することは意義がある…という方もいるであろうし、ある特定の条件の下では、成り立つ可能性はあるだろう。

しかし、
「ソフトウェアの生産性に関してＬＯＣを用いることは、飛行機のスピードと能力を測るために飛行機の重量を用いるようなものである」
というたとえは、ＬＯＣで生産性を測ることの問題を上手く言いえており、「ソフトウェアは、飛行機とは違うからスピード・能力と重量は強い相関がある」と示すことは困難であろう。

【ソフトウェア生産性の定量的管理とは②】ソフトウェアの生産性定量化で何を把握したいのか

他にないから仕方がない…。
「製造量／工数」といった、大量生産される工業製品の生産性指標を、１つとして同じではないソフトウェアの生産性評価に適用する際に言われることである。

次善の策というわけであるが、本当に次善たりうるのだろうか。

そもそも、ソフトウェアの生産性とは何であろうか、生産性を定量化することで何を把握したいのだろうか。

人月の弊害が叫ばれて久しい
といえば、
そうは言っても人月は簡単に比較的精度高く測れるよ
と返ってくる。

ＳＬＯＣのメトリクスのベースに使うことの違和感もあちこちで言われている
といえば、
しかしＳＬＯＣはツールで確実に測れるではないか。
と返される。

だから、生産性は、
　　　ＳＬＯＣ／投入人月
で測るしかない…と言って良いのか。

生産性の定量化。
そもそもこれで何をしたいのであろうか。

【ソフトウェア生産性の定量的管理とは①】たとえ話～ソフトウェアと肖像画の生産性

ソフトウェアの生産性はどのように定量化されるべきか。
そもそも、ソフトウェア開発における生産性とは何なのか。

未だ決定打と呼べる答えは無いし、現在一般に行われているソフトウェア開発のプロセスや手法を使う範囲では、「客観的に正しい生産性計測方法」というものは構築できないと思われる。

それは、肖像画家の生産性にたとえられよう。
肖像画家は、毎回異なる顧客に対し、同じ画材・同じ技術で肖像画を描く。
この肖像画の客観的値付けはできるであろうか。
また、それに基づく生産性の向上はできるのであろうか。

値付けには、絵の大きさ、かけた時間、そして出来栄えが加味されるのかもしれない。
その内、かけた時間、出来栄えは個々の画家の技量による面が強いだろう。

肖像を残すだけなら写真もある。
写真家に撮影してもらうと、これも写真家により値段が変わる。
撮影技術により値がことなるという理由からである。
出来栄えは個々の画家の技量による面が強いだろうが、かけた時間はあまり変わらないだろう。

そして誰でも撮影できるスピード証明写真やデジカメ撮影プリンタ印刷という方法もある。
これは、誰にでも出来て値付けも成果物量に完全に一致した均一料金である。
撮影してその場で写真を入手できる。
出来栄え、かけた時間ともにあまり変わらないだろう。

肖像画、写真家による写真、スピード写真・デジカメ写真。

この中で、生産性を論じることが出来るのは、スピード写真・デジカメ写真だけであろう。
出来栄え・かけた時間が個々の撮影であまり変わらないので再現性が期待できるからである。
これは、撮影者の技術のバラツキに製造されるモノの品質や生産性があまり依存しないということである。
カメラという撮影用ツールの進歩があったからこれが可能になったといえよう。

さて、ソフトウェア開発はどうであろうか。
プログラミング用ツールは、
　　　プログラマの技術のバラツキに製造されるモノの品質生産性があまり依存しない
という域に達しているだろうか。
プログラマの生産性の差は１０倍あるという伝説は今は昔のことなのだろうか。

以上は、あくまでたとえ話であり、
　　　ソフトウェアは、肖像画・肖像写真ではないから、たとえること自体ナンセンス
という一言で一蹴することができる。

しかし、ならば「製造量／工数」といった、大量生産される工業製品の生産性指標を、１つとして同じではないソフトウェアの生産性評価に何の疑問もなく適用することに疑問を感じてよいのではないだろうか。

　　　ソフトウェアは、肖像画・肖像写真ではないから、たとえること自体ナンセンス
と言うならば、
　　　１つとして同じではないソフトウェアは、大量生産される工業製品ではないから、たとえること自体ナンセンス
と言い返されることに対する答えを用意しておくべきであろう。

【ソフトウェア開発における生産性②】簡単な生産性向上策②

そもそも品質は品質、生産性は生産性と分けて考えると、スパゲッティプログラムを一生懸命レビュー、テストするという沼にはまることは十分ありえる。
なぜなら、生産性は単独で評価されるのであるから、それはそれで向上したくなる。

しかし、品質もコストも開発期間も全部ばらばらに定量的な改善を求めることは欲張りである。
例えば、自動車で、速くて安全で広くて小回りがきいて、安いものを、一気に求めるのは無謀だと思わないだろうか。

どれかを立てれば、どれかを犠牲にする方が定量的管理・改善においては妥当だと思われる。

もちろん、全てを抜本的に改善することはあり得るが、これは、パラダイムシフトであり、定量的管理・改善とは別物である。

やはり、定量的管理においては、品質は品質、生産性は生産性と分けて考えてはいけないのであろう。
どうすればよいのか。
最も簡単なのは、ゾーン分析的アプローチになるのであろうか。

しかし、単純に品質指標と生産性指標を組み合わせたところで、複雑な開発作業を上手く言い表せるとは限らない。
両者を個別に評価するよりマシな可能性があるというだけである。
では、組み合わせる指標を増やして３次元、もしくは４次元で評価すればよいのか。

最初に立ちかえって考えてみる。
生産性にしろ、品質指標にしろ、指標と言うものは、複雑なソフトウェア開発という作業および成果物の状況を、その状況を特徴的に表すと思われるいくつかの基本測定量の組み合わせによって単純化して表すものである。

目的が指標値の改善であるならば、状況を特徴的に表さないと思われるものは、指標値の改善を考えれば、無視してよいことになる。
しかし、指標値の改善が最終的な目的であるとは思えない。

生産性を上げるということがなぜ必要かを考え、そのなぜに答える改善策を定性的に考えることもした方が良いのではないだろうか。
指標と言う単純化のせいで指標値の改善が目的化することは容易に陥る過ちである。

先の①～③の例に対し「なんて、おかしな例なんだろう…」と言う方も多いだろうが、自組織において類似のことを行っていないか詳細にチェックしてみたら、驚きの結果となる組織も多々あるのではないだろうか。

【ソフトウェア開発における生産性①】簡単な生産性向上策①

以下は現実的な生産性向上の話ではないことを予め断っておきます。

生産性を上げるためには何をすればよいか。
それは簡単、生産性指標の構成要素＝基本測定量を良く分析することだろう。

とにかく、秘訣は、
①最初の設計段階からスパゲッティプログラムで構わない、もしくは敢えてこれを心がけること
②品質など問わず、設計書類も最低限に絞ってとにかくプログラムを書かせること
③自動化ツール等のプロセスやシステム的な改善策をこっそり導入すること
これに尽きるであろう。

そうすれば、高生産性を上げて評価されるであろう…って本当だろうか。

「安かろう悪かろう」で良ければ、簡単に生産性など上げられる。

「品質が悪かったら意味ないだろう」と言われそうであるが、通常行われている「生産性」の管理手法に品質を評価する測定項目はない。
だから、①の方法を使っても「それで何が悪いのかわからない。だって指標値は改善しているではないか」と言われれば返す言葉が無かろう。

品質も必要であるならば、品質と生産性とを合わせて定量的評価を行う仕掛けが必要である。

品質は品質、生産性は生産性として完全に分けて定量的管理を行っているのであれば、両者を合わせた管理を検討してみると新しい視点が得られるであろう…と言うのは簡単であるが、実際のところどうすればよいのであろうか。

【ソフトウェア開発における定量的管理⑤】あなたは泳ぎ方を知らないときにタイムを測りますか？

そもそも、できるかどうかわからないことをやろうとするのは、余裕のあるときにすべきである。
効果に確信が持てないことを建て直しと称して実施することは、実施してみて効果が無かったときに責任問題になりかねない。
定量的品質管理よりも、定性的品質改善により効果が見込めそうな場合は、迷わず定性的品質改善を実施すべきである。

よく、計測無ければ改善無しとか計測しなければ何も分からないとか言われるが、改善したことを数字で示すことが組織の目的であればそうであろうが、明らかに実施した方が良いことは、改善したことを数字で示されなくとも実施すればよい。

計測しなければ状況が分からない、改善のきっかけがつかめないというところに至って初めて計測無ければ改善無しとか計測しなければ何も分からないと言えると考える。

例えれば、水泳でバタフライを習得するときに、全く泳ぎ方が分からないときから５０Ｍのタイムを計測することに意味があるかということ。泳法をある程度身に付けるまでは、コーチに腕の振りがどうの、全身の使い方がどうのと直してもらった方が、コーチにつかず最初からタイムだけ測って練習するより、上達が早いだろうということと同じだ。
ある程度泳ぎ方が分かってきてから測定を開始すれば、自分の現状のタイムがわかるし、泳ぎ方をどう変えるとどうタイムが変わるか等、泳法改善の指針にもなる。

タイムと言う定量的指標は泳ぎ方を教えてはくれない。
しかし、コーチは泳ぎ方を教えてくれるし、コーチがいなくとも解説本があればコーチには効果で劣るかもしれないが泳法を知ることはできる。

バタ足から始めて、ストローク、バタ足・ストロークのバランス調整、最適化とカリキュラムが進むにつれて、速く泳げるようになるであろう。
しかし、これはタイムを測らなければ分からないものではなくて、体感できるものであろう。
逆にカリキュラムなしでタイムだけを測っても泳法はなかなか身に付かないであろう、

コーチや解説本だけでは十分ではなく、自身で色々試行錯誤する段階に入って初めてストップウォッチが改善に寄与するのではないか。

開発支援ツールを入れる、レビュー方法、テスト方法を変えるといった、定性的な改善を実施する余地が明らかにあるのであれば、まずそちらから取り組むべきであろう。

ツールを導入したら、生産性が○○％上がりましたとかレビュー手法を変えたらテスト時のバグ抽出密度が半分になりましたとか報告したいのであれば、定性的改善の前に計測を初めても良いが、それは継続的改善のための定量的管理ではなく、ツール、手法の導入効果報告のためであって、計測自体が改善をもたらすものではない。

計測無ければ改善無しが、改善策を実施しても定量的に表せないのであればわからないという意味で使うのであれば、それは否定すべきと考える。
定性的改善は、計測しなくとも実施すればよいし、単純な指標で改善がわかるような定性的改善策なら、計測しなくとも効果は実感できるだろうから。

あなたは泳ぎ方を知らないときにタイムを測りますか？

【ソフトウェア開発における定量的管理④】定量的管理を始める前に

作られたもののバラツキが「工程上のちょっとの差」に起因するのであれば、定量的に計測してその差を見つけて改善すれば良い。
「ちょっとの差」だけに定量的に計測しないと見つけることも、改善されたかどうかもできないだろうから。

しかし、実際のソフトウェア開発現場における品質の差は定量的に計測しないとわからない「ちょっとの差」ばかりなのだろうか。

開発者毎もしくはプロジェクト毎の成果物品質のバラツキが「大きな差」であるならば、わざわざ計測して原因推測・改善案検討するよりも、「大きな差」はどうしたら減るだろうと定性的に考えて対策を講じた方が良いのではないか。

また、「ちょっとの差」以上に、定性的にも分かる手順・方法のばらつき、個々人の能力の差による誤差が大きければせっかくの計測値から正しい傾向を把握することは困難であろう。

定量的管理をしなければとあせる前に定性的管理で他にできることはないかと辺りを見渡すことは、顧客や上位経営層等に改善をアピールするためではなく、自分たちのためだけに改善を行いたいのであれば、非常に意義があることであろう。

【ソフトウェア開発における定量的管理③】開発者は指標値を意識すべきか否か

既に述べたように、ソフトウェア開発の定量的管理におては、達成しなければならないバーを定めて行う未達成事項の取り締まりと、開発プロジェクトの健全性を簡易的に把握しようという健康診断がある。

「計測を始めて何件かの実績値が集まったら、３σの範囲で上限下限を決めて管理を始めることができる」と言う考え方は、後者の健康診断的考え方だ。

しかし、一度上限下限の考え方を打ち出すと、その値に開発者が縛られる可能性がでて来る。
そうなると、その後の計測値は、それまでの指標値を睨んだ値となる。
これを積み重ねていった上で、継続的見なおしと称して、指標値をそれまでのデータで見なおしを行っても、最初の段階で定めた指標値に縛られている可能性が捨てられない。

だからといって、自然体で計測したデータを統計的に収束するであろう数だけ集めようとすると、今度は計測された値のバラツキが大きく、指標値が定まるまでにかなりの期間を要するであろう。統計的に確からしい計測値が定まる前に対象ソフトウェアの寿命が来て運用が停止されたというようなことになりかねない。

工業製品における製品品質は、「同じ品質」の「同じもの」をつくるために行うものである。

一方、ソフトウェア開発においては、「同じもの」を作ることはない。
「同じ品質」の「違うもの」を作るのだ。

「同じ品質」の「同じもの」というのは、「同じ品質」なら「同じもの」であり、かつ「同じもの」であれば「同じ品質」が成り立つことである。だから、「同じもの」というものの直接的な特性に対して計測することで定量的管理が可能になる。
長さや重さは一定の範囲内に収まっているか、性能は予め定めた程度を満たすか等を検査し、それから外れたら「同じもの」ではないとするのである。
長さ、重さ、スピード、処理能力、ゆがみの程度等、ものに対して直接観測できる事項を計測するのである。
また、プロセスの品質保証にしても、「同じもの」を作るために同じプロセスを徹底するのである。

工業製品では「同じもの」か否かの検査をすることが、「同じ品質」を保証するプロセスの１つになる。

これに対し、ソフトウェア開発は、「同じもの」を作らないので、「同じもの」か否かの検査アプローチで「同じ品質」を保証することはできない。

以上のことは、既に多くの人に言い尽くされている。
しかし、これを意識してか無意識にか忘れて管理をしているところが多いのではないだろうか。

【ソフトウェア開発における定量的管理②】定量的管理は母集団に共通の「定量的」かつ「妥当」な特徴があってこそ

指標値をどのように定めればよいのか…これはかなりの難題である。
「計測を始めて何件かの実績値が集まったら、３σの範囲で上限下限を決めて管理を始めることができる」と言う方もいらっしゃるようだが…。

確かに、数学的には計算可能でしょう。
しかし、それを元に管理することは妥当な結果をもたらすのであろうか。

ここで突然だが、カレー屋さんを例に考えてみたい。
最初店主一人で切りもりしていた時は、店主自身でご飯やルーを盛っていた。一人前のご飯やルーの量が同じになるようにするのには、店主の勘に依っていた。
しばらくして、店が繁盛してきたのでアルバイトを雇うこととなった。一人前のご飯やルーの量が人によりばらばらにならないようにする必要が出てきた。

そこで次のように定めた。

・ご飯　…　ハカリを用意し１人前のグラム数を定めた
・ルー　…　適当な大きさのお玉を用意し、すりきり１すくいを１人前とした

これで、改善の余地はないか。
ご飯は、いちいち重さを量りながらでは手間がかかることが分かった。
それで、ルーと同様の考えで、型にご飯を詰めて一定量とすることとした。
一定の容積のご飯は一定の重さであるという前提で、以前と同じグラム数となるようご飯を提供した。

次に改善対象となったのは、ルーである。
お客様からの次のようなクレームが多発していた。
「私のカレーと隣の人のカレーでは肉の量が全然違う」

お玉でのすくい方次第で、このような自体が発生することは十分にありえる。

ご飯はおおよそ均質なので、どこの部分をよそっても「一定の容積のご飯は一定の重さである」と言えるが、ルーはお玉１すくい中の具の内容はバラツキが大きい。

キーマカレーなら比較的均一であるが、ごろごろとした鶏肉の入ったチキンカレーでは大きな差が生じる。
では、どうするか。
チキンカレーの鶏肉は別に煮込み、大きなバラツキの要因となるような具のないルーをお玉でよそった上で、予め何個と決めた鶏肉を乗せることとした。

これで、お客様からのクレームは無くなった。
これは、厳密には個々の鶏肉の量にバラツキはあるが問題視されなくなったということであり、お客様の許容範囲内の誤差に収めたことを意味する。

以上のように、料理をよそうという行為はご飯でもルーでも同じはずであるが、定量的に管理する方法はそれぞれに合わせて異なっていたほうが良く、更には、同じルーといっても内容が異なれば定量的管理方法もまた異なった方が良いことがありえる。

さて、ソフトウェア開発において同様の課題はないだろうか。
ソフトウェアは、上の例で言う「料理」に相当しないだろうか。

どれもソフトウェアだからと同じ物差しで測って良いのだろうか。

ご飯のように、均質かつ重さと容積が比較的小さい誤差で比例するのであれば良いであろう。
しかし、ソフトウェアは均質で誤差が少ないのであろうか。

そもそも、カレーと違って、いつも同じ量を作成するのではない。
加えて、物差しが直接の計測値ではなく、バグ摘出率等といった割合で表されることが多いのであるから、カレーより更に難しい。

定量的管理は母集団に共通の「定量的」な特徴に着目して行うのであるが、しかし、「お玉」でどのプログラムも測れるからといって一律に「お玉」だけで管理しようとしても上手く行かない。

「定量的」かつ「妥当」な特徴があってこそ管理できるのだ。

そしてこの「定量的」かつ「妥当」な特徴を１つのメトリクスに求めることは難しいことが多いであろう。
一つにこだわらず、複数のメトリクスを用いて判断すれば良いのであるが、たくさん組み合わせたからといってよく分かるとは限らないので、数字にこだわりすぎることは止めた方が良い。
厳密には個々量にバラツキがあっても、問題視されなければ良いのだ。
問題視されないということはどういうことか、を考えることが重要である。

【ソフトウェア開発における定量的管理①】指標による定量的管理は健康診断なのか、取り締まりなのか

指標値を定めて行う定量的管理は、達成しなければならないバーを定めて行う未達成事項の取り締まりなのか、もしくは開発プロジェクトの健全性を簡易的に把握しようという健康診断なのか、

どちらの考えも有ってよい。

達成しなければならないバーというのは、開発者にバーを意識して達成させるることで、一定レベルの維持を目指すものである。

健康診断というのは、プロジェクトマネジャー等が、開発が計画通りに進んでいるかを確認し異常や懸念を発見し対応のきっかけにするものである。

この２つの側面を両立できれば良いのであるが、この両立は単純ではない。
理由は以下の通り。
　
達成しなければならないバーというのであれば、開発者、プロマネ、品質管理担当者はそのバーを意識して活動する。
すると、以後の計測値は、そのバーを意識した結果になる。
故に、バーが実は妥当でなかった場合、関係者は、不適切な管理を続けることになる。

健康診断というのであれば、その指標値を開発者が意識した段階で、結果に作為が混入する可能性がでてくる。
作為が入った段階で、それは健康診断ではなくなる。

故に、ソフトウェア開発の定量的管理におては、達成しなければならないバーを定めて行う未達成事項の取り締まりと、開発プロジェクトの健全性を簡易的に把握しようという健康診断は両立は通常できない。

【ソフトウェア信頼度成長モデルとは何なのか】始めに帰って

結局のところ開発現場における信頼度成長モデルとは何のことでどう使うべきものだろうか。

ソフトウェア信頼度成長モデルに関する記述の始めに「ソフトウェア信頼度成長モデル」「ソフトウェア信頼度成長曲線」「バグ成長曲線」等という色々な呼び方を書いた。
また、そもそも成長曲線は寝るものであると考える人もいることも書いた。

厳密な、学問的意味でのソフトウェア信頼度成長モデルのさわりも見てみた。

その上での個人的な感想は・・・・、
学問的意味でのソフトウェア信頼度成長モデルが使えるケースより、民間療法的な使用法の方が「使える」気がする。

上手に線が描けるツールを探すよりも先に、信頼度成長曲線とは何で、どのような前提を満たした上でそれが成り立つのかを知らねばならない。

直感的に理解しやすいだけに誤用は多いであろうが、その場合は「最初は新規機能の確認でバグが多く出て、後ではレグレッションテストを行うから不具合は相対的に少なくなるので寝るんだよ」くらい大きく間違えた方が、変に前提を満たさないのにツールを使って綺麗な曲線を書いて予測するより、「開発に悪影響を与えない」使い方であると思う。

「最初は新規機能の確認でバグが多く出て、後ではレグレッションテストを行うから不具合は相対的に少なくなるので寝るんだよ」のようなあるがままのテスト状況をプロットしていく図の表し方を、「信頼度成長曲線」と区別して「バグ曲線」と呼ぶ人もいる。

「信頼度成長曲線」とは、予定調和で「寝ていたらテストを終わってよい」ということをテスト実施側と検収側が確認する為の形式的儀式という考え方もありだと個人的には思うし、それ以上の使い方は「かなりの上級者向け」であると考える。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑧】信頼度成長モデル評価のための基準

書籍「ソフトウェア品質工学の尺度とモデル」には、「８．４　モデル評価のための基準」として、１９８４年に専門家のグループ(Ianninoら)が考案したという５つの基準を挙げている。
---------------------------------------------------------------------------
１．予測妥当性
２．能力
３．仮定の質
４．適用性
５．簡潔性
---------------------------------------------------------------------------
そして、本書ではその中でも、「予測妥当性、簡潔性、仮定の質」の順で重要であると強調されており、能力と適用性はそれほど重要ではないとされている。

重要な３つについて考えてみる。

○予測妥当性
　　でてきた予測が妥当でないことが明らかなものは、モデルたりえないことは明らかなのでこれは重要であろう。
　　但し、妥当か否かを判定する基準がそもそも定義することが難しいと思われるが。

○簡潔性
　　簡潔性については、この基準が考案されたのが１９８４年ということに注意が必要である。
　　確かに、収集したデータをプロットし、予測値の計算を行うことは当時のコンピュータシステムの環境では容易ではなかったと考えられる。
　　しかし、現在は、当時と比較して格段に高性能なＰＣにより、この簡潔性はそれほど重要ではないと考えてよいのではないだろうか。

○仮定の質
　　仮定の質…これを満たすことが非常な難関であることは既に見てきた通りである。
　　３つの重要な基準の中でこれが最も充足することが難しいのではないだろうか。
　　開発の実践において、十分といえる程度に充足するような仮定というものは、そもそも立てることが難しいであろう。
　　そして、統計処理に統計処理を重ねることが「指標としての価値」という点から、個別の開発の当てはめにおいて、十分活用するに足るものであるかということに、細心の注意が必要であると考える。

　　信頼度成長モデルは、一本の線で進むべき道が表示される神の啓示にみえてしまうが、本当にそうであろうか。

　　大雑把な道筋を見せてくれるだけのツールと考えるべきであろう。
　　しかし、統計的に正しいに過ぎないことなど神の啓示であるわけがない。

　　但し、使い方として、「上位管理層」「顧客」に、テストの十分性をアピールするためであれば、それはそれで意味がある。
　　「テストはちゃんとやっているよ」ということを「管理する側に」見える化するには分かりやすい図だといえるからだ。
　　この場合は、５つの基準は、ゆるやかに考えれば良い。
　　そして、「Ｊ－Ｍモデルの曲線と一致するのでテストは十分と考えます」等と言い切れば良い。

　　信頼度成長モデルを何のための活用するのかという目的に合わせた仮定の質を考えればよい。
　　実践上において仮定の質を上げることばかりに注意がいくと、本来何をするために信頼度成長モデルを活用するのかの目的を見失ってしまう。
　　ソフトウェア開発においては、ソフトウェアの開発が目的であって、信頼度成長モデルの厳密な活用が目的ではない。
　　作りたいソフトウェアのスコープからみてＴｏｏ　Ｍｕｃｈな信頼度成長モデルの適用をすべきか否かはよくよく考えるべきである。
　　これは信頼度成長モデルに限らず、仮定に基づく管理全てに言える。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑦】２つ目の仮定：欠陥発見数モデルの基本的な仮定（Goel, 1985）

書籍「ソフトウェア品質工学の尺度とモデル」に挙げられている２つ目の仮定を見てみよう。
---------------------------------------------------------------------------
欠陥発見数モデルの基本的な仮定（Goel, 1985）

１．テストの時間区間は相互に独立である。
２．時間区間内のテスト作業は妥当な程度に一様である。
３．重複しない各時間区間で検出された欠陥数は相互に独立である。

---------------------------------------------------------------------------

「１．テストの時間区間は相互に独立である」
これは、信頼度成長モデルで表そうとする一連のテストの中では、複数の時間区間を入れ替えてテストを行っても結果が変わらないことを示す。別な言い方をすれば、前の時間区間内の作業を前提にして次に続く時間区間のテストが行われてはならない
ことを示す。

「２．時間区間内のテスト作業は妥当な程度に一様である」
これは、なかなか理解が難しい。
中小的に言えば、各々の時間区間における「テスト作業」の進み具合に大きなバラツキが無いことをいうのであるが、そもそも「テスト作業」とは何かの定義が難しい。
テスト作業が２時間の日もあれば、１０時間の日もあることは認めないということでもあるし、ある１日のテストケース消化数が１００個の日もあれば１個の日もあることは認めないと言うことでもある。

ここでいうテスト作業をテストに費やす時間（人時でもおそらく可）と考えれば、「妥当な程度に」というものが曖昧ではあるが、この仮定は充足可能であろう。

しかし、実際の現場では、時間区間内のテスト作業を算出するにあたって、テスト作業にそのテストのための環境設定時間は含むのか含まないのか、欠陥らしきものを発見した場合に再現テストを行った場合の時間は含むのか等、仮定を満たすためには、一々面倒な事象につき定義しておく必要がある。

「３．重複しない各時間区間で検出された欠陥数は相互に独立である」
これは、各時間区間では、他の時間区間では欠陥が発見できないことのみをテストするようにテスト設計しろと言っているわけではない。そのようなことは開発の現場では無理であるから。
理論上は無理ではないにせよ、それは、言いかえると、常に未確認の部分をテストするというのであるから、途中で曲線が寝たと言ってテストを止めてよいかは疑問が残る。
「３．重複しない各時間区間で検出された欠陥数は相互に独立である」は、実際の開発現場においては、同じ原因による欠陥は、最初に発見されたときにのみ挙げ、それ以降は挙げないと解釈すればよいであろう。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑥】１つ目の仮定：Ｊ－Ｍ(Jelinski-Moranda)モデルの仮定③

以上から、
　　２．故障はランダムに起こる－－故障間隔は独立である。
　　３．全ての欠陥は故障発生に等しく寄与する。
の２つは、特に満足することが難しい仮定であることがわかる。

そして、達成が絶望的に難しい仮定でありながら、この２つは、曲線がモデル通りに寝ていくための必須条件であるのである。

Ｊ－Ｍ(Jelinski-Moranda)モデルの５つの仮定を満たせば、モデルに従った綺麗なカーブを描きますよといわれても、開発現場において、では全部満たした上で採用しようかとはなかなか言えないと思う。

尚、書籍「ソフトウェア品質工学の尺度とモデル」に挙げられているが、上の５つの条件のうち、３．の制約を克服するためにLittlewoodのモデルが、Goel-Okumotoの不完全デバッキングモデルが４．,５．を改善しようとして提示されている。
ただ、プログラム中の欠陥のばらつきや数については、統計技術で収束できるかもしれないが、テスト工数・テスト時間というものは「テスト実施者個々の能力」「テスト実施者のやる気」により、同じことを同じレベルで実施するにしても大きなばらつきがあるように思えるので、ここの部分を統計的に収束させることは難しいのではないかと考える。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑤】１つ目の仮定：Ｊ－Ｍ(Jelinski-Moranda)モデルの仮定②

３．全ての欠陥は故障発生に等しく寄与する。

これも実際問題難しいであろう。
かなり細かい条件を満たさないと故障が発生しないバグと、プログラム実行の入り口で発生してしまうバグとでは、故障発生の寄与は異なるであろう。
この仮定は、ある程度複雑なプログラムでは満足することは困難であろう。
実用に供することができるプログラムの場合、まず満足することは無いのではないかと考える。

４．修正時間は無視できる。

まあ、これは、理論上はそのように運用すればよいので、可能ではある。
バグが発生した都度、テストを中止してプログラムを直せばよいのであるから。
実際の開発現場でこれを満たすようにテストを行うのは困難ではあろうが。

５．各故障に対する修正は完全であり、欠陥修正中に新しい欠陥は混入しない。
まあ、これも、実際には発生するであろう欠陥修正中に混入した新しい欠陥の数及びそれにより影響を受けたテスト時間、もしくは工数等横軸にとった数量を考慮することとすれば可能ではある。

【ソフトウェア信頼度成長モデルを少しまじめに考える④】１つ目の仮定：Ｊ－Ｍ(Jelinski-Moranda)モデルの仮定①

先に挙げた書籍「ソフトウェア品質工学の尺度とモデル」には、ソフトウェア信頼度成長モデルのモデルの仮定を２組紹介している。
この２組の仮定のうちどちらかを十分に満たすような実際の開発案件があれば、ソフトウェア信頼度成長モデルを上手く導入できるであろう。

---------------------------------------------------------------------------
Ｊ－Ｍ(Jelinski-Moranda)モデルの仮定

１．テスト開始時点で未知のＮ個のソフトウェアの欠陥が存在する。
２．故障はランダムに起こる－－故障間隔は独立である。
３．全ての欠陥は故障発生に等しく寄与する。
４．修正時間は無視できる。
５．各故障に対する修正は完全であり、欠陥修正中に新しい欠陥は混入しない。

---------------------------------------------------------------------------
なかなか、クリアすることが難しそうな仮定である。

１．は、まあ、そう仮定すればよいのであろうから満たすと言ってよいであろう。

２．は、つまり、テストケースの実施順に関わらず、同じテスト対象プログラムであれば、理論上は同じ形の曲線になることを意味する。
実際の開発現場でこれを実現することは少し難しい。
「ソフトウェア品質工学の尺度とモデル」でも触れられているが、あるバグが見つかったら類似バグが無いかをテストすることや、バグが多く見つかったプログラムに対し集中的にテストすることは通常の開発においてはよく行われる。
しかし、これは「故障はランダムに起こる－－故障間隔は独立である」に反する可能性が高い。
また、重要な機能や複雑な機能などを先に集中的にテストすることも行われるが、これも。故障間隔の独立性に反する結果となる可能性がある。

テストケースの実施順に関わらず、同じテスト対象プログラムであれば、理論上は同じ形の曲線になることを満たすテストは限られてくる。
テストケースの挙げ方・実施順に恣意性があると、条件を満たすことが困難になるし、プログラムの新機能におけるバグと、性能上の問題、従来機能のデグレードによるバグが、ランダムに起こるようにテストすることは難しいであろう。新機能確認テストと、性能テスト、レグレッションテストは、通常、それぞれをフェーズに分けて実施されることが多いからである。

「２．故障はランダムに起こる－－故障間隔は独立である」を満たすには、そもそも本質的にそれを満たすようなテストであるか、もしくはそれを満たすように注意深く設計されたテストをする必要がある。
これは、テストケースに「ここの部分は怪しいから最初に深めにテストしよう」とか「ここにバグが見つかったからちょっと重点的にテストしよう」といったテスト実施順番の恣意性が無いことを要求しているのである。
「２．故障はランダムに起こる－－故障間隔は独立である」は、テスト実施順番に関わらず、同じ曲線になることを言っているのである。
リスクベースのテストとは両立しないと思われる。

　・そもそも本質的にそれを満たすようなテスト
　　　　プログラムの個々の機能には着目せず、業務面に着目して設計されたテストがこれに当てはまるであろう。
　　　　具体的には、実際にはそのプログラムが使用法に準じた使われるのと同じ方法で

　　　　たとえば、プログラムが対象とする業務について１日を通しての業務処理を何日分も廻すテストやカーナビソフトのテストで実際に車に積んで色々な場所を何時間も走って行うテストがこれに該当しよう。
　　　　しかし、「そもそも本質的にそれを満たすようなテスト」というものは、あまり実施されることが無いのではないだろうか。
　　　　そもそも業務処理の日廻しやカーナビの実走の段階で曲線が立ちあがって後に寝ることがグラフで分かるようなプログラムはそれまでのテストで何やっていたんだという危険なプログラムであろう。

　　　　モジュールテスト、結合テスト、初期のシステムテストでそもそも本質的に「２．故障はランダムに起こる－－故障間隔は独立である」を満たすテストとはどのようなテストなのであろうか。解があれば教えてほしい課題である。

　・それを満たすように注意深く設計されたテスト
　　　　テストケースの一覧から乱数等を使ってランダムにテストの実施順を決定してテストすることで、機能のまとまり毎にテストすることによる故障発生可能性の偏りを回避しようとするようなテストがこれに該当するかもしれない。

　　　　自動化されたテストツールで行うテストであれば単に実施順を入れ替えるだけで対応は楽だが、人手でのテストであれば、テスト実施者にとってはなかなか嫌なテストであろう。
機能のまとまり毎にテストすることは、類似操作が並んでいることが多く、テスト実施に習熟しやすいが、都度、違う部分のテストを行うのは、設定等の準備も都度発生するであろうし、操作も一々再確認しなければならないであろうからテストに集中するのが大変であると予想される。

　　　　但し、一定程度の自動化が進んだテストであればこれは可能であるので、その場合は「２．故障はランダムに起こる－－故障間隔は独立である」ようにテストを実施することは可能である。

【ソフトウェア信頼度成長モデルを少しまじめに考える③】直感的理解容易性のために忘れられがちであるが悩ましい前提③

○応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し、逆も成り立つ。言い換えると、仮定が妥当なものであればあるほどモデルはより役に立つものとなる

＝＞ソフトウェア信頼度成長モデルの有効性に付いて、
　　　　　モデルはより効力を発揮し
　　　　　モデルはより役に立つ
　　　程度にしか書かれていないのであって、
　　　　　モデルの精度は高くなる
　　　とは言っていない。
　　　なぜ「精度」という語を使わないのであろうか。
　　　そもそもソフトウェア信頼度成長モデルは、「精度」云々を論ずるレベルのものではないと著者が考えているからなのではないだろうか。

「応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し」
に対して、逆も成り立つとわざわざ言っていることからもそれが推測される。

「応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し」
「仮定が妥当なものであればあるほどモデルはより役に立つものとなる」
を、逆にすると、
「応用に際しては、基礎となる仮定が満足されてないとき、モデルはより効力を発揮できない」
「仮定が妥当なものでないほどモデルはより役に立たなくなる」
となる。

ソフトウェア信頼度成長モデルが自己の0ソフトウェア開発においてどの程度満足できるかは、その仮定を見ていけばよい。
実際の開発現場で仮定を十分に満たすようなモデルを探すことが、ソフトウェア信頼度成長モデル導入の成功の秘訣ということになる。

【ソフトウェア信頼度成長モデルを少しまじめに考える②】直感的理解容易性のために忘れられがちであるが悩ましい前提②

○モデル化する物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できないので、モデルの開発にあたっては仮定を曖昧でない形で明らかにする必要がある

＝＞最初の文と実質的に同じことを言っている。
　　　繰り返すということは、重要であるという意味であるし、言葉は過激になっている。
　　　「物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できない」ということは、高い精度を期待できないなりに、なんとか管理しようということである。
つまり、仮定を曖昧なままとしたら、管理できるようなものではないと捉えてよいと考える。

ソフトウェア信頼度成長モデルにおいて、「ソフトウェア品質工学の尺度とモデル」の著者は「物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できない」と言い切っている。

高い精度を殆ど期待できないものを、高い精度で表そうと言うことは考えられないと帰着できよう。
故に、ソフトウェア信頼度成長モデルは、高い精度で管理する類のものではないということを実戦で活用する際は肝に銘ずるべきである。

しかし、実際の活用においては、様々な曲線を表すモデルが考案され、管理描画ツールも種々ある。そして、これを使えば、手っ取り早く「高い精度」で管理できると考えてしまいがちである。

モデルが洗練されることは、「前よりまし」になるだけの話で、それで「高い精度」となるわけではない。
低い精度が多少高くなるだけと考えた方が良い。
なぜなら、取り扱う元の現象である物理プロセス(ソフトウェア故障現象)に、そもそも高い精度を殆ど期待できないのであるから、
それをどんなに洗練された方法で取り扱っても「高い精度」にはならない。
全くでたらめではなく、多少傾向が出る、辛うじて管理できるようにするために、仮定を曖昧でない形で明らかにできるモデルが必要なのである。
高い精度で管理できるようにするために、仮定を曖昧でない形で明らかにできるモデルが必要だと考えるべきではない。

あくまで、個人的な考えであるが、取り組みやすいし誰にも直感的にわかりやすいからと、ソフトウェア信頼度成長モデル１本にテストの止め時判定の責任を押し付けることは勧められない。
統計的な処理結果にも関わらずブレを表現しない曲線１本で表すソフトウェア信頼度成長モデルは、「複雑な現実」の開発現場において主役にはなり得ない。あくまで脇役として使うべきである。

【ソフトウェア信頼度成長モデルを少しまじめに考える①】直感的理解容易性のために忘れられがちであるが悩ましい前提①

直感的な理解が容易であるために忘れられがちであるが、ソフトウェア信頼度成長モデルの悩ましい前提について詳しく考えておきたい。

考察のベースとして、
　　　Stephen H. Kan 著　古山恒夫・富野壽 監訳
     「ソフトウェア品質工学の尺度とモデル」(2004,　共立出版株式会社)
を用いる。
本書の「第８章　指数分布と信頼度成長モデル」にソフトウェア信頼度成長モデルについて述べられている。
そして「８．３　モデルの仮定」において、次の記述がある。

「信頼性のモデル化は、複雑な現実を正確な統計の言葉でまとめるための１つの試みである。モデル化する物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できないので、モデルの開発にあたっては仮定を曖昧でない形で明らかにする必要がある。応用に際しては、基礎となる家庭が満足されているとき、モデルはより効力を発揮し、逆も成り立つ。言い換えると、仮定が妥当なものであればあるほどモデルはより役に立つものとなる」

この引用部分は、ソフトウェア信頼度成長モデルの適用を考える上での課題を簡潔に言い表していると考える。

○信頼性のモデル化は、複雑な現実を正確な統計の言葉でまとめるための１つの試みである

＝＞ソフトウェア信頼度成長モデルが対象とするものは、本来的に「複雑な現実」なのである。これを忘れてはならない。
　　曲線１本で表されて、あたかもその線の指す方向が従うべき道に見えてしまうが、誤りである。
　　ソフトウェア信頼度成長モデルから導き出される曲線は、統計的に引かれた線にすぎず、個々の「複雑な現実」によってブレることは、異例なことではないのである。

また、曲線の算出式自体が、ソフトウェア開発プロセスの論理的帰結から導き出されているのではなく、経験的に曲線は寝るはずであるからどうやって実際の計測値に合う式を見つけるか…から来ているので、そこから導き出される曲線１本にどの程度の管理が可能であるかを予め考えておくべきである。

実際の開発現場において、ソフトウェア信頼度成長モデルで表される曲線１本に、「複雑な現実」のどの程度を表現させることができるかを、自らの開発プロセスや過去の実績を省みて予め考えておく必要がある。

【ソフトウェア信頼度成長モデルを考える⑤】グラフが寝るとはどういうことか②

簡単な仮想事例で考えてみる。
ソフトウェア信頼度成長モデルを用いてテスト十分性を見ようという場合に、新機能確認Ａを２０００件行った後、新機能確認Ｂを２０００件、レグレッションテストを５０００件行ったところ、綺麗に曲線が寝たという場合に喜んで良いのか。

次の３つの順番で行っても、同様に寝るのか。

①新機能確認Ｂを２０００件行った後、新機能確認Ａを２０００件、レグレッションテストを５０００件行う
＝＞これはまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

②レグレッションテストを５０００件行った後，新機能確認Ａを２０００件、新機能確認Ｂを２０００件行う
＝＞モデルが想定するような綺麗な形には寝ないだろう。

③新機能確認Ａを１０００件行った後、新機能確認Ｂを１０００件、レグレッションテストを５０００件行う
＝＞これもまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

ある程度のケース数のレグレッションテストを最後に持ってくれば、新機能確認のケース数の多少に関係無く一般的に曲線は寝ることが多い。

つまり、先ほどの例で言えば、

　　　・最初から寝ることが分かっているレグレッションテスト
の前に、
　　　・通常寝ない新機能確認Ａ、Ｂ

を持ってくれば、実際のソフトウェア内のバグの残存に関わらず「最初から寝る」可能性が非常に高い。
これを以って、「ソフトウェア信頼度」が成長したとか言うのは全くナンセンスである

このようなことは、わざわざ例示までしなくとも、誰にも理解できるであろう。

しかし、頭で理解できてもこれを考慮してテストを実施することは、非常に難しい。
通常、実際のテストにおいては、テストの実施順番は、機能・重要度・リスク等によってグルーピングしており、
　　　　バグがテストケース全体にわたって同じ発生確率でばらまかれていること
という前提が、十分仮定として成り立つようなテストの方が少ないであろう。

ソフトウェア信頼度成長モデルの前提については、別途詳しく考えることとする。

【ソフトウェア信頼度成長モデルを考える④】グラフが寝るとはどういうことか①

グラフが寝るとはどういうことなのだろうか。
テストを実施するにつれてバグが見つかりにくくなるから寝るという考え方は、直感的には理解できる。
故に手を出しやすいのであるが、何故寝るのかについては、直感ではなく、理論的に考える必要がある。

その上で、自分たちの開発において、グラフが論理的に寝ることの必然性が確認できれば採用すべきであるし、そうでなければグラフがきれいに描かれるからといって採用するべきではなかろう。

なぜ寝るのか。
①バグがテストケース全体にわたって同じ発生確率でばらまかれていること
が大前提である。
また、
②テストケースは、基本的に、特定の１機能のみに絞った確認を行うのではなく、１ケースで複数の機能の確認ができ、かつ、各機能は複数のテストケースで発見される可能性を有していること
が前提となる。

①の前提がなく、テストケースのある一群を実施している段階ではバグがほとんど出ず、別な一群で大量に出るようでは、実施順によってグラフの傾きが変わってしまう。
同じソフトウェアに対して、テストの実施順によって傾きや寝方が変わるというのは、モデルとして不適当であるということは理解できよう。
故に、①の前提が意味することは、ソフトウェア信頼度成長モデルにおいては、テスト順によらずグラフは同じ形で収束する、つまり寝ることが理論的前提となっているということである。

また、②の前提がなく、それぞれのテストケースで発見されるバグは他のテストケースでは見つからないようであると、こちらも実施する順番によって、グラフが寝たり立ったりする可能性が出てくる。

このように、信頼度成長モデルには、「テストケースの挙げ方」「テストの実施順」についての前提がある。
この前提があるからこそ、曲線が寝るということがソフトウェアの信頼度が上がることと結びつくのである。

そしてまた、この「テストケースの挙げ方」「テストの実施順」という前提故に、ソフトウェア信頼度成長モデルは直感的には容易に理解できるにも関わらず、実際活用してみると色々悩みが出てくる。既に挙げた「テストサイクルを通じて寝るように計画されている」や「同じテストを何ショットか繰り返すから寝るように計画されている」という、定量的把握とは言い難い活用法も出てくるのである。

【ソフトウェア信頼度成長モデルを考える③】現場における様々な言い方、使われ方（３）

２．曲線の意味

（１）テストを実施するにつれてバグが見つかりにくくなるから寝るという考え方
　　一般的な考え方。但しこれも、深く考えると難しい問題に直面するがそれは別途述べる。

（２）そもそも寝るように計画されたテストであるという考え方

　（ア）テストサイクルを通じて寝るように計画されているという考え方

　　　例えば、既存のシステムに大規模な改定を行った場合のシステムテストにおいて、
　　　　　①まず新しい機能およびその影響を受ける部分を確認する
　　　　　②次に非機能要件を確認する
　　　　　③最後に既存部分は無影響であることを確認する
　　　まあ、直感的には③は①と②に比べバグが出ることも少ないであろうことは理解できる。
　　　しかし、これを言ってしまうと①②をどんなにいいかげんに行っても③を行ったら寝始める。
　　　だから、確かにグラフは誰もがイメージする形になるが、これから何が分かるのかというと、何も分からないのではないか。

　　　馬鹿げていると言う方も多いであろうが、信頼度成長モデルをこのように理解している人もいる。
　　　また、上記のように書くとばかげていると言う方でも、実際のテストでは、無意識のうちに、
　　　　　　　新しい機能およびその影響を受ける部分、非機能要件、既存部分の無影響確認
　　　の順にテストして、結果をプロットして寝た寝たと言っているなら結果的にこの考えで捉えていることになる。

　　　尚、だから、
　　　　　　　新しい機能およびその影響を受ける部分、非機能要件、既存部分の無影響確認
　　　の順番でのテストが意味が無いというものではない。
　　　この順番でテストすることの合理性は、リスクベースという面からも理解できる。
　　　但し、この順番でテストした結果をわざわざ信頼度成長モデルに当てはめることに意味が無いのではないかというだけである。

　　　
　（イ）同じテストを何ショットか繰り返すから寝るように計画されているという考え方
　　　まず、１ショットテストケースをこなす。バグを潰して１回目と同じテストケースをもう１ショット行う。バグが出たら繰り返す。
　　　で、バグ修正によるデグレードが収まったところでカーブは寝るはずだという理屈。
　　　これも、この結果をわざわざ信頼度成長モデルに当てはめることに意味が無いのではないかというだけである。

　　ちなみに、（ア）も（イ）もコンサルタントとして金を取っている人から聞いたことがある。
　　現場において信頼度成長モデルを適用するにあたっての説明の難しさが伺える。

【ソフトウェア信頼度成長モデルを考える②】現場における様々な言い方、使われ方（２）

１．対象となるテスト期間

（１）特定テスト内でのモデル
　　　例えばシステムテストの最初から最後までを対象とするという考え方
　　　結合テストとシステムテストと２つのテストを合わせて実施するのもこちらに入れておく。

（２）テスト全体を通じたモデル
　　　例えばモジュールテスト（単体テスト、ユニットテスト）からユーザ受け入れテストまでのおよそテストと名の付く工程全てを対象とするという考え方　　

モジュールテスト、結合テスト、システムテストは、それぞれ異なる視点でテストするものであるから、それら全てを通じて、統計的に有意な形でグラフ化されるということは考えづらいので、（１）の使い方が良いであろうし、一般的であろう。

【ソフトウェア信頼度成長モデルを考える①】現場における様々な言い方、使われ方（１）

ソフトウェアテストにおける発見されたバグの傾向をみる手法として、「ソフトウェア信頼度成長モデル」「ソフトウェア信頼度成長曲線」「バグ成長曲線」等と呼ばれる考え方がある。
これらは、意識的にどれかを選んでもしくは使い分けている人もいれば、同じものを指しているのに場面場面で違う名称で呼んでいたりする人もいる。

つまり「ソフトウェア信頼度成長曲線」「バグ成長曲線」を使い分けている人もいれば同じであると思っている人もいるので、話がかみ合わないこともある。

名称が違うだけなら、まだ良い。
その内容自体が人によって違っていたりする。

これは、学問的な定義がどうのということもあるが、信頼度成長モデルが、直感的視覚的には理解しやすいので手を出しやすく、開発現場で活用されているが、実際の運営においては前提条件や過程において難しい点が多いモデルであることから来るものでもあろう。

次からは、とりあえず「ソフトウェア信頼度成長モデル」と呼ぶことにするが、これが開発の現場でどのような意味で使用されているか考えたい。

【定量的品質管理あれこれ③】ソフトウェア品質の定量的管理ができる条件とは

ソフトウェアは人が作成するものであるから、計測する定量データにバラツキが生じるのは避けられない。
また、そもそも毎回同じ仕様のものを作るわけではないから、それぞれの成果物のバラツキ（規模、難易度等）が本来的に内包されている。

これらも考慮した上で、定量的管理ができる開発とはどのようなものであるか考えてみる。

要は、定量管理する測定項目が開発毎にばらつかない、もしくはバラツキが小さければ良い訳である。

そのようなな開発はあるのか。

開発自体のフレームワーク化、部品化を高度に進めて、ほとんど人手によるコーディングという作業を行わずしてプログラムが書けるような開発であれば、バラツキをより小さくすることが可能であろう。
また逆に、開発サポートツールやプログラムの自動生成の仕掛けがほとんど無い、昔ながらの手で一行一行書いていく開発野場合に、開発標準・規約をガチガチに定めれば、可能かもしれない。

そうではなく、ツールを使えるところはツールで、ツールが無い部分は手作業で、といった開発では、開発量（ＦＰにしろＳＬＯＣにしろ）を分母にした定量管理はバラツキが多くなるであろう。

既に書いた通り、開発とは名ばかりで、実際は既にある部品の組み合わせと、それらに与えるパラメータとテストケースを考えるだけで、実際ほとんどコーディングをしないような開発・・・、この場合は定量的管理が出きるのではないかと考える。

部品毎に、考えるべきパラメータ数とその難易度、テストケースパターン数等の定量的管理項目が予測でき、部品の組み合わせは、各々の部品の定量的管理項目の何らかの組み合わせで評価できるであろうから。

この次元に至っていない開発の場合は、人手によるバラツキとの格闘は避けられないのではないかと考える。

【定量的品質管理あれこれ②】定量的管理におけるデータのばらつきに目をつぶるな

システム開発において定量的管理を難しくするデータのばらつきについて考える。
データのばらつきはどのようなときに生じるのであろうか。

個別のデータ項目によらないばらつき要因としては、
　　・作業者の能力レベルの違い（プログラマの生産性は１０倍以上と言われる等）
　　・プロジェクト毎、要件毎の要求レベルの違い
　　・開発支援ツールの活用度合い
等が挙げられる。

これら要因によるばらつきは無視できないと考えるべきである。
定量的管理を行う際に最も注意すべきは「出てきた数字を盲信しない」ということである。
ばらつきを考慮した上で数字を取り扱わねばならない。

たとえば、新人とベテランプログラマの混成チームの人月当たりSLOC量はどうやって定量化するのかという場合に、単純に各人のSLOCの和と労働時間の和を出して割ればよいというわけではないと、分かるであろう。

分かるであろうが、そのように行っている組織があるのは何故か。
それは、ある程度の規模のプロジェクトではそれらが収束するであろうと期待しているからだという理由付けがなされることが多いと思う。

しかし、「人により１０倍の差があるものが収束などするのだろうか」という疑問に統計学的に答えることは困難であろう、

にもかかわらず、
　　単純に各人のSLOCの和と労働時間の和を出して割る方法
で、生産性が測られることが多いのは何故か。

それは、そこでいう生産性が何のために算出されるのかと言う目的に遡れば理解しやすい。

純粋な意味で自己の開発プロセスを改善するためであれば、ばらつきは厳密に評価されねばならないのではないかと思われる。
しかし、これを出すことで「誰かを説得できる」のであれば話は別である。
ばらつこうが何だろうが、「今回のプロジェクトの生産性はこれこれで、所期のパフォーマンスを出せています」と顧客や上位管理層にアピールするためであれば、個々のデータのばらつきについては「どうでも良い」と言えるかもしれない。

このような使い方は邪道だ、という意見が出ることは理解できる。

しかし、これも定量的データの活用方法として認めるべきであると考えるし、個人的には、これがソフトウェア開発における定量的データの最も有効な使い方であると考える。
あまりにバラツキが多いデータから改善の機会を見つけたり、改善の効果を定量的数字で表すことは、非常に困難なことであると考えるからであるし、劇的な改善の契機は地道な計測からではなく、定性的管理で発見できると考えるからである。

ツールを導入して「導入前対比○○％生産性がアップしました」というのは「顧客や上位管理層にアピールするため」であって、それで更なる改善のきっかけにはならないのではないか。

但し、「顧客や上位管理層にアピール」はしないと、新しい取り組みが許可されないこともあるだろうから、そのために計測することは「あって良い」と考える。

【定量的品質管理あれこれ①】プロジェクト内で完結する定量的品質管理

ソフトウェア品質の定量的管理の切り口として、同一システムの過去の蓄積データや別システムの類似プロジェクトデータを使用した管理と、同一プロジェクト内データを使用した管理に分ける考え方がある。

過去の蓄積データ･類似プロジェクトデータを使用した管理とは、過去のプロジェクトにおいて計測したデータを元に、今回のプロジェクトにおける当該データの傾向を予測し管理するもので、通常の場合に定量的管理と言えばこちらを指すことが多い。

次に、同一プロジェクト内データを使用した管理とは、例えばパイロット的に一部を開発し、そこで採取されたデータを指標値としてそれ以降の開発を管理していくものである。他の例としては、結合テストやシステムテストの段階で、不具合発生プログラムを追跡し、特定のプログラムもしくはプログラム群に何らかの傾向がないかをみることや、同様の考えから、複数の基本設計書を作成した場合にそこから発展する詳細設計書、プログラムソースの欠陥傾向を分析し、特定の基本設計書が他と対比して異なった傾向を示している場合に何らかの手を打つ等の管理がある。

過去の蓄積データや類似プロジェクトデータは、あくまで今回とは別のプロジェクトのデータであり、蓄積データは、個々のプロジェクト毎の前提条件の違いを無視したものであり、今から取り組むプロジェクトに適用するにあたっては、それら違いに応じた精度で定量的管理を行わねばならない。
例えばSLOCの生産性を３桁４桁の精度で管理することができるか否かは、算数的なことではなく、個々のプロジェクト及び同一プロジェクト内における様々なばらつきを考慮して決めるべきことがらである。

同一プロジェクト内データを使用した管理においては、特定の個人が作成した成果物や特定の機能に不具合が集中するという傾向をつかむことができる。
プロジェクトを走らせながら定量的に見てパイロットデータもしくはその他のデータと歩調が合わないデータを発見するという考えである。

当然のことではあるが、個人を責める材料にこのデータを使用することは厳禁である。しかし、本来的に個人を追い詰める可能性を秘めているデータと言えるので取り扱いには細心の注意が必要である。
そもそも、同一プロジェクト内といえど、成果物間で要件の複雑度や要求される品質レベル等の差があることが多いので、外れ値なのか誤差なのかの判別の難易度は、過去の蓄積データや類似プロジェクトデータ対比では易しい可能性はあるが、それでも難しいことには変わりはない。

【ソフトウェア品質の定量的管理における想像力④】毎年目標値を改善しても毎年達成できてしまうという表彰すべき組織

見積もりを誤ったため実際の工数が計画対比オーバーして失敗したという事例が多い組織は、逆に、見積もりを誤ったため実際の工数が計画対比アンダーして失敗したという事例も多くてよさそうなはずである。
もし、工数オーバーの事例のみしかないのであれば、慢性的に見積もりを適正値より低く行っているか、実績対比見積もり工数が多いときは、なんとなく消化してしまっているのであろう。計画通りと言うことで、だれも文句を言わないのだからそれで良いという考えもあろう。
しかし、工数オーバーの場合はそうはいかない。誰かがその工数を負担しなければならないし、誰かが責任を取らなくてはならなくなる。

ここで指標値に戻って考えると、工数オーバーの場合は工数・成果物量ともに実際の数が計上されるだろうが、工数アンダーの場合は、どうだろう。

実際は、見積もり対比小さな工数で開発が出来たはずが、見積もり通りの工数が計上されていたら、生産性は小さくなろう。
計画対比かなり早く出来そうであれば、ゆっくりとやろう、早く帰ろうという気にならないか。

このあたりに生産性の指標値における作為の可能性が潜む。
定められた生産性を達成するため、最低限のバーは超えねばならないが、あるプロジェクトで見積もりを誤ったのか生産性が劇的に向上する見込みとなったからと言って、そのまま報告されると期待してよいのだろうか。
なぜずば抜けて良い結果になったかわからない値を素直に報告して、指標値見なおしにあたって上方修正されるのでは、開発者としては積極的に報告する気にはなれないのではないか。

一度数値が設定されたら、それが色々な意味で開発のベースになる。
数字を設定された値に近づけようというモチベーションが働くことを止めるのは難しい。

最初に実際の開発能力対比低すぎる値を設定してしまったら、それは本来得られるべきパフォーマンスを低下される方向に働くという可能性があることを意識するべきである。

ゆえに、３つや４つの計測データを採って、それを元に仮指標を作成して、以後はデータが増えるたびにその結果を取り込んで数字を精緻化していけばよいという考えは、仮に採用するのであれば、取得するデータが恣意的要素が入り込む余地の無いものに限った方がよいであろう。

さもないと、毎年目標値を改善しても毎年達成できてしまうという表彰すべき組織を、希望すればいつでも作れてしまうことになろう。

【ソフトウェア品質の定量的管理における想像力③】想像力について始めに立ち戻って再考

実際に、ある項目について定量管理を行う場合、

①計測項目もしくはそれらを組み合わせて導出された数字が、知りたい情報を定量的に表しているという合理的理由はあるか
②①で定量的に表すと結論できたとして、管理限界の範囲は、管理する上で有効な幅に収まるか

の２つについては、必ず検討しなければならない。

①は、普通行うだろう。
工数と生産量や生産量とテストケース数など、何らかの関係が想像された上で組み合わせが定められるはずだ。

しかし、②はどうだろうか。
生産性の管理図を作成してみて、上限と下限の値が１．５倍以上になったりしていないだろうか。
１．５倍の範囲なら収束しているよと言える組織であればよいが、それは予算のぶれが中心値対比そＲＲぞれ２５％ぶれても構わないということに近い。
本当にそれでよいのだろうか。

計測開始して、いくつかのデータが採れたら、それを元に仮指標を定めて管理を始めればよいという考え方もある。
そのように定量的管理を始めることがまったくナンセンスであるとは言えないが、留意すべきことはある。

最も意識すべきは、そのデータの使い方である。
生産性であれば、始めに測定したデータはそのシステムに対する担当者の経験が浅い段階での測定値であるので、開発が進むにつれて生産性が上がっていくことが見こまれる。

当然、品質管理担当者もそれは知っているので、データの集まり具合を見て生産性指標値を上位補正することを考えるであろうが、開発側からすれば、少しでも楽をしたい、儲けたいという自己の利益のためだけではなく、いざと言うときの予備工数を取っておきたいと言うプロジェクトを成功させたいという意識からの心理も働き、意図的に生産性を調整することが可能な計測方法の場合、集められた数字が恣意的なデータになるリスクがある。

これは、別に指標値をデータ収集の初期段階で始めた場合に限らないが、最初に定められる目標値、もしくは上下限値の設定は最も重要である。

指標値の多くは、人による作業の一面に着目して計測される。
生産性なら。成果物量と工数が真に正比例の関係にあれば計測を正しく行う限りごまかしようが無いが、実際には、成果物量に対しては難易度が、工数においては個人の能力差が、真摯に開発に取り組んで計測を正しく行ってもデータのバラツキ要因となるし、工数に関しては、上手く言っているときや開発の初期には、たとえ見積もりが実際に必要であった工数対比過大であっても、それに合わせた開発をするために工数はちゃんと消化されるであろう。

【ソフトウェア品質の定量的管理における想像力②】想像力を働かせる上で注意すべき点

ここで間違いやすいのは、データがたくさん集まれば、全体としては収束するであろう、という考えだ。
考え方としてはその通りだと言えるが、収束すると言えるほど実測データは取れるのだろうか。
加えて、管理図の下限上限の値の差が２倍かそれ以上担ったとした場合に、それで生産性を定量的に管理していると言ってよいものなのだろうか。
数学的にその通りということと、それが実際の管理上、何に役立つかは別である。

組織のカルチャーとして、「計測してみたけど、有意な結果が得られなかったのでこの品質評価モデルは捨てて、別のモデルをやってみよう」と言える組織であればよいが、やってみたけど、有意な結果が得られなかったとなったら経営層を始めとして周囲から集中攻撃されるような組織では、計測値に対する深い想像力がなければ上手く進められない。

もう一つ間違いやすいのは、では計測項目を増やせばよいのではないかという考えだ。
先の生産性のケースでは、生産量と工数だけでなく、難易度や担当者の能力も係数として加味した上で導出した値で評価しようという考え方や、生産性は、難易度別・担当者の能力別に定めようという考え方だ。

前者の考え方には、難易度や担当者の能力を数値的に表すことができるのかという問題がある。
前者では、難易度や担当者の能力を５段階にランク付けする等は行われがちであるが、これは、あくまでそうみなすと言うことであり、客観的厳密性に欠ける。しかし、ひとたびランク付けされたら、それ以降はなぜか厳密な数値として取り扱われてしまうことになりがちである。
しかし、ランク付けという乱暴な補正係数を含んで導出された値は、そもそも管理精度が高いとは言えない。

後者の考え方には、それだけ細かく分類して、それぞれの分類において有意な数のデータが集まるかという・問題がある。

仮定やみなしに基づいた補正係数等を施して導出された値は、見積もりの上では顧客もしくはユーザに、納得させると言う意味で有用ではあろうが、開発が進んでいるときの定量的管理指標値としては、通常は妥当ではない、もしくは精度はそれなりであると考えるべきである。

【ソフトウェア品質の定量的管理における想像力①】一段深く想像力を働かせる必要性

定量的管理を行うためには計測される値およびそれらの組み合わせから導出される値に対する深い想像が必要となる。

そもそも、予め計測した値を元に定めるにしろ、予め相関関係を推定してから計測するにしろ、定量的管理をするにあたっては、　「それを測れば何が分かるのか。それは何故か」や「それを知りたければ何を測るべきか。それは何故か」を考えた上で、評価するための評価モデルを定めているはずである。

しかし、その程度の想像力で充分のか否かということを考えてみたい。

計測した値をモデルに基づいて評価する場合に、集まったデータの相関関係はどの程度なのかについては、算数的に相関の強弱を見ることは簡単であろう。
しかし、それだけでメトリクスとして使えるかどうか判断してしまうのは危ない。

さらに想像を働かせて、個々の実測データを生みだした背景も考慮して、考えるべきである。
例えば生産性を見るなら、難易度や担当者の能力が開発によって異なるわけで、
　　　非常に簡単なプログラムを新人が開発したときの生産性
と、
　　　非常に難しいプログラムを熟練者が開発したときの生産性
が、近い値になったからと言って、
　　　このシステムにおける生産量と工数には非常に強い相関がある、
として指標値を定めた場合に、
　　　非常にプ難しいログラムを新人が開発したとき　や　非常に簡単なプログラムを熟練者が開発したとき
の生産性予測を行っても上手く行くであろうかと考えてみる。

【ソフトウェア開発における計測と改善③】指標に引きずられる可能性の考慮

定量的管理を行う場合、指標に引きずられる危険も考えなければならない。

「指標となる基準値は毎年見直しされ、実績が毎年上回るため毎年基準値も向上している」という組織があったとする。

これは良いことなのだろうか。
実績が毎年上回るため毎年基準値も向上しているということは、毎年改善されているということなのであろうか。
ＰＤＣＡが回っていると胸を張って良いのだろうか。

そもそも指標となる値は毎年向上できるものだろうか。
「継続的改善」と「目標」「業績評価」とが結びつくと、「一度にあんまり改善すると来年のネタがなくなるので今年はここまで」と、改善スピードを調整するといったとんちんかんな事態が発生する懸念を考えた方が良い。
また、最初に異様に低い基準値が設定されたため、逆にそれに合わせるように開発が調整されている可能性もある。

指標は一度定めると、それを意識した開発を行うことになる。
開発者が指標を意識して開発を行うことは両刃の剣である。
マッケーブのサイクロマチック数やコメント率等は、開発者が指標を意識しこだわるべき指標であろうが、純粋に統計的な数値においては、開発者の指標への意識過剰は真の意味の品質・生産性の向上には結びつかないことも生じよう。

但し、毎年の指標値改善がお客様との契約上の合意事項であれば、それもやむをえない面がある。
お客様が「刈り取れる成果は前倒しで取る変わりに毎年改善することは望まない」のか「毎年必ず改善することを望むのか」で、受注側はビジネス的振る舞いを変えることはあって良い。

【ソフトウェア開発における計測と改善②】定量的管理の限界を知ること

定量的管理が出来ていないと自称する組織が「障害が多い」と言うのはどのような理由によるのであろう。
「うちのシステムは障害が多いから、品質を上げなければならない。その一施策として定量化を行いたい」というような話は普通に聞かれるのであるが、「うちのシステムは障害が多い」という判断自体がすでに定量的管理がなされているからこそできるはずである。

実際、手順化・文書化されていないだけで定量的管理をしているのである。
ただ、どうしてそういえるのかが整理できていないから、説得力がないだけであるのだ。
しかし、「うちのシステムは障害が多い」と言う者に、「どうしてそう言えるのか」をしつこく質問すれば、説得力のある理由が明らかになるだろうし、その説明の過程は定量的なロジックに基づくであろう。
管理が定義されていないということは、計測と評価のプロセス・ロジックに客観性が無く、評価が個人の思い込みで評価されるリスクは高くなる、評価の共有も難しいという面がある。

以上を元に、組織だった定量的管理とは何かを考えると、これは、定量的な計測と評価のプロセス・ロジックを予め定めておき、実際のプロジェクト進捗に合わせてデータを当てはめ妥当性を確認することが、計測者・評価者によらず行えることと言える。

故に、それぞれの指標が何を説明するのかの意味を忘れ、数字だけ見て「結合テストでの発見バグが少ないですね、あとＸＸ個出るまでテストしてください」と言うのは愚の骨頂である。

なぜなら多くの指標が、単なる確率・統計の話なのだから。
色々な事項をはしょって、計測した項目のみに着目して管理していることの限界を考えるべきである。

サンプル数が少ないときや特殊なケースは、直感の方が良いことさえある。というより、「うちのシステムは障害が多い」と言うなどという組織では、直感でカバーできる改善余地がまだまだいくつかあるであろう。

サンプル数が３ケースでも統計処理して指標化せよという者もいるが、乱暴だ。
算数としてサンプルが３つあればσも出せるというだけの話である。
プログラマにより生産性は１０倍以上違うと言われるのに、単純に算数を信じることは愚かである。

定量的品質管理は算数ではない。

また、定量的品質管理が目的化してもいけない。
定量的品質管理がＳＬＡ等でお客様との契約事項になっているのでなければ。

【ソフトウェア開発における計測と改善①】何が何でも定量的管理をすべきか

ソフトウェア開発において、計測と改善はどのような関係にあるのであろうか。

測るからこそ、改善されたかどうかわかるのであると言うことはできる。

しかし、改善したい個所は、計測にしなければ見つからないと言うわけではない。

改善策は定性的、感覚的に生みだされることは多々あるだろう。
改善されたことが、測ることなしに定性的･感覚的に分かると言うのは、余ほどの改善でないとありえないかもしれないが。

では、計測によらずに考えられた改善策の成果を、改善策の実施前後で計測・評価することに意味があるであろうか。

例えば、新しい開発支援ツールの導入前後で不具合発生率がどう変わったかを計測で示す意義はあるであろうか。
無いのではないだろうか。
新しい開発支援ツールが定性的に見て品質・生産性に寄与すると分かれば、わざわざ事後的に定量的に示しても本質的な意味は無い。
意味があるとすれば、新しい開発支援ツールのための予算を負担してくれた組織や顧客に対して「これだけ効果がありました」と示すことくらいである。

障害が多いシステムの開発プロセスを見直す場合に、定量的管理以前に定性的にみて改善する余地が大きいのではないかと自問することは重要である。
障害が多いから定量的管理を始めようと短絡的に発想する必要は無かろう。
定量的管理、定性的管理の両面から見直しをかけることが良いと考える。

【ソフトウェア品質の定量的管理とは⑤】まずつべこべ言わず測ってみようよ、どこでもやっているから・・・と言う前に

お客様を納得させるために定量的管理をすると言うケースであるが、これは突き詰めればSLA締結に行き着く。SLAまで行かなくとも、「われわれはこのような基準で管理しています」と顧客に言うときに、定量的管理というキーワードは有効である。

この場合に設定する数値は、開発側が自主的に定めることとすると、既存の開発プロセスで実現が容易なものが定められ、決して「がんばって改善しなければ達成できない」ようなものは定められないであろう。
「顧客が納得すれば」実際に改善余地があろうとなかろうと「低い目標」で良いのである。

そんな品質管理指標に何の意味があろうかという考えもあろうし、一定水準を維持すること自体に意義があると考えることも可能である。

以上のように、「なぜ、何のために品質･生産性の維持･向上を目的とした計測が必要なのか」に対する答えの違いにより、何をどのように計測するかが変わってくるのである。

定量化手法や計測手法が巷間色々あるが、自らが計測に何を求めるかを深く考えた上で適用すべきものを選択すべきである。

まずつべこべ言わず測ってみようよ、どこでもやっているから・・・というのも考え方として間違ってはいないと思うが・・・それが品質･生産性の維持･向上を目的とした計測といえるかという観点から考えるとお勧めできない。

【ソフトウェア品質の定量的管理とは④】定量的管理と言っても大掴みができる程度と考えよ

計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めたいという目的に対しては、定量的管理が本来力を発揮するはずである。

しかし、なかなかそうはいかないのが現実である。
なぜこのようなことになるのだろう。

定量的管理に厳密さを求めすぎているのではないかということが、理由の一つであると思える。
ソフトウェア開発は、まだ人手の介する割合が多いのだから基準値に対し１０％以内とかなんとかの精度で行うことは難しいことが多い。２倍や２分の１を超えなければ問題ないという割り切ったスタンスで考えれば良いのではないか。

コーディングの生産性は人により１０倍以上の差があると言われているのに、生産性を５％、１０％の精度で管理して何か良いことがあるのであろうか。

もちろん、統計的に収束すると言えるほどのプロジェクト規模、過去データがあれば多少は精度が上がるだろうとはいえる。

一番気をつけなければならないのは、数字が出るからといって、それを鵜呑みにしないことである。
たとえば、生産性をSLCP／人日で測るとして、大抵の場合割り切れないのですごい桁数が計算機上に現れるが、生産性の有効数字はいくらまでとすべきか意識して考えなければならない。
小数点以下切捨てだとして喜んでいては最悪であるし、そもそも人手作業であることの誤差もあるから、算数的な有効桁数で考えるべきでもないだろう。
通常の組織であれば、せいぜい有効数字２桁で考えるべきであろう。

指標に対する下限が８０％だからといって、８０．１８％で良かったと安堵し７９．８９％で大騒ぎする必要はないであろう。

このように記せば誰もが納得するであろうが、現場ではえてしてこのような茶番劇が起きうるから注意が必要である。
指標を評価に使うとなるとこれが高い頻度で発生するであろうし、それに伴う悪しき数字操作も行われるであろう。

【ソフトウェア品質の定量的管理とは③】定量的管理が最も業務上の効果を発揮するのは・・・

さて、先に、なぜ、何のために品質･生産性の維持･向上が必要なのかとして次の３つを例示した。

　　･お客様を納得させるため
　　･利益率を上げるため
　　･計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため

この中で、色々と建前はあろうが、実際のところ、ソフトウェア品質の定量的管理が最も業務上の効果を発揮するのは、１番目の「お客様を納得させるため」ではないだろうか。

ソフトウェア開発は、様々な不確定要因から、データのばらつきが大きく、また個々のプロジェクトの特殊要因も多いため、なかなか収束しないと言われる。

利益率を上げたいのであれば、開発プロセス、手法などを見なおした方が地道に何かを測って改善するより良いのではないか・・・という意見に抗えるほど定量的計測の精度が高いと言い切ることは難しかろう。

定量的管理手法は、開発プロセス、手法などを見なおした結果を確認したり、なぜばらつくのかなぜ低下してきているのかといった開発プロセス、手法などの見なおしの契機となることに否定はできないが、それは、定性的に観点からの開発プロセス、手法などの見なおしが既にある程度行われている段階での話であり、定性的な視点からの改善余地がある組織にとっては、定量的視点の改善に手を出さなくとも、利益率を上げるための方法は他に色々あるのではないか。

まさにＣＭＭＩはその建てつけになっており、定量的管理を始めようとする組織は、まずCMMIの段階モデルにおけるレベル２、３のプロセスを自組織が達成できているかどうかを確認してから定量的管理を考えても無駄ではないだろう。
もちろん、CMMIのレベル３を達成するまで定量的管理を始めるべきではないというわけではない。

ただ、利益率を上げたいのであれば他の方法も色々あるので定量的管理にこだわる必要がないというだけである。

故に、

　　･お客様を納得させるため
　　･利益率を上げるため
　　･計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため

の中で、ソフトウェア品質の定量的管理が最も業務上の効果を発揮するのは、１番目の「お客様を納得させるため」であると考えるのである。

「御社ではソフトウェア開発品質についてどのような取り組みをしているか」という問いに、「・・・というように定量的に管理しています」と言えることは現在のＳＩｅｒでは、必須条件のようになっている。

で、そう言った会社の実体を見てみると・・・どうなのであろうか。

【ソフトウェア品質の定量的管理とは②】戦略的な視点をもった定量的管理

戦略的な視点をもった定量的管理とはどういうものか。

例えば、生産性を維持向上しているということを示すにしても、「お客様を納得させるため」と「利益率を上げるため」では、異なる精度･視点で計測されるべきである。

「お客様を納得させるため」であれば、生産性指標データが、
　　　予めお客様と合意した設定値を達成していると言えること
もしくは、
　　　これだけの値であれば、世間で言われる指標値対比十分な生産性とお客様に言えること
が重要であり、そのためにどうするかが重要となる。

一方、「利益率を上げるため」であれば、
　　　現状対比、より高い生産性にするために測定以外の改善活動の評価とリンクづけた活動となること
が重要となる。　　　

両者の違いを端的に表すと、
　　　「お客様を納得させるため」では、自組織のソフトウェア開発がちゃんとできていると示すことが重要であり、
　　　「利益率を上げるため」では、何が原因で生産性は変わるのかもしくは変わったのか、どうすればより改善できるかもしくは一定値に維持できるのかの契機を発見することが重要であるという点にある。

これは、
　　　「お客様を納得させるため」では、「生産性はプロジェクト間で基本的には同じで、改善活動を行えば、それ以降のプロジェクトでは全て生産性データは改善されるはず」　を前提としているが、
　　　「利益率を上げるため」では、「生産性は個々のプロジェクトで変わりうるが、その変動を一定の範囲内に収める手段が何かあるはず」を前提としている。
これは、両者が正反対の前提を置いているということもできる。

この視点の違いは、測定方法や評価方法、測定精度の選択に影響を及ぼす。

「生産性が一定に保たれていることの確認」のための定量的管理と、「生産性の変動を一定の範囲内に収める手段発見」のための定量的管理とは異なる。

これを区別せず「生産性を維持向上するため」とひと括りに考え、安易に他社事例等を持ってきたりしても、利益率を上げたいのに「生産性が一定に保たれていること」を確認するための定量的管理をしてみたりということが生じうる。

【ソフトウェア品質の定量的管理とは①】何のために計測するのか

ソフトウェアの開発にあたり、計測は何故必要か。
何のために計測するのか。

この問いに正面から向き合ったことはあるか。

この問いには、品質･生産性の維持･向上のためと答えて終わりとされることが多い。
品質･生産性の維持･向上というのは大きな括りであるから正しいといえば正しいであろう。
しかし、そこからいきなり「では何をどう計測しようか」と具体的に考えるのは難しいし、おかしな話ではないだろうか。

なぜなら、計測の理由が品質･生産性の維持･向上ということはわかるが、品質･生産性の維持･向上には計測しか手段が無いわけではないからだ。

だからといって、計測が無意味だと結論付ける必要は無い。

一歩進めて、なぜ、何のために品質･生産性の維持･向上を目的とした計測が必要なのかと考えてみると、先が見えてくるように思える。

･お客様を納得させるため
･利益率を上げるため
･計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため
他･･･

この「なぜ、何のために品質･生産性の維持･向上を目的とした計測が必要なのか」に応じて、「品質･生産性の維持･向上」のためのデータ計測と活用方法が変わってくるはずである。

ソフトウェア開発においては、「製品品質を上げたいから教科書に書かれている何々を計測しよう」「生産性を上げたいからＡ社で測っている何々を我々も計測しよう」というような戦術的計測ではなく、「お客様を納得させるため」「利益率を上げるため」「計画精度を上げ失敗プロジェクトをなくすため」といった、もうひとつ掘り下げた戦略的計測が本来は必要だと考える。

品質･生産性の維持･向上は、何のために測定されるのかという問いの答えではない。
品質･生産性の維持･向上はなぜ必要なのか、までさかのぼって考えなければならない。