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            
無料ブログはココログ

« 2011年3月 | トップページ | 2011年5月 »

2011年4月

2011年4月29日 (金)

【続定量的品質予測のススメ】レビューの専門知識を担保するための資格・認定制度とは

P28「1.3(2)設計レビューの要件」において「③一般的にレビューアは、もっている専門知識を資格・認定制度に結びつけて担保することが好ましい」とある。

この「専門知識を資格・認定制度に結びつけて担保」というのは何であろうか。
そもそも、レビューに必要な「専門知識」と一口に言っても、そのシステムが処理する業務に対する知識、システムに関する知識、システム開発に関する知識と少なくとも3つの分類はあろう。

このいずれの知識を言っているのか。もしくは、そのうちのどれかを言っているのか。
また、「資格・認定制度」は公的なものを言うのか、組織内のものを含むのか。
後者のような気もするが、本書での書き方ではあまりに抽象的なので、分からない。

専門知識を担保するための資格・認定制度の例がいくつか挙げられていれば良かったと思われる。

2011年4月26日 (火)

【続定量的品質予測のススメ】「リスクによっては」のリスクとは?

P22「(1)上流工程におけるレビュー」において、上流工程の設計について、「プログラム製造物と違い、インプットも知識もあいまいになりがちである(略)また、あいまいさを取り除くために、一般的にはレビューが用いられる。ただし、抜け漏れ、誤りを網羅的に発見する簡易な方法は存在しない。さらに、レビューに主観が入り込み、リスクによってはレビューの質は安定しない場合もある」と書かれている。

ここでいう「リスク」とは何であるか自明ではない。
この記述の前に、「リスク」の内容を定義するような記述はない。

もちろん、この「リスク」は一般的意味での「リスク」だととれなくもない。
しかし、一般的な「リスク」全てを考慮するのであれば、もはや「レビューに主観が入り込み」という記述さえ不要となるのでやはりここでの「リスク」は何らかの意味を有すると捉えるべきであろう。

また、
・抜け漏れ、誤りを網羅的に発見する簡易な方法は存在しない
ことと、
・レビューに主観が入り込み
については、「定量的品質予測」について非常な足かせになると思われるが、残念ながら本書ではここを更に突っ込んで検討されていない。
もちろんこれは簡単に解決できるものではないので仕方がない面がある。

しかし、ならば、より明確に、上流工程における定量的品質予測は難しいので定性的に管理の軸足を置くべきである」くらい言い切った方が良いと個人的には思う。

2011年4月22日 (金)

【続定量的品質予測のススメ】「前作のポイント」のポイント②

【前回の続き】

次に②の「測定値を集計することにより、当該工程の品質管理・分析が可能」について考えたい。
これも、当然、理屈としては問題ないように思える。現実にどうかということだ。

これは、測定単位を正しくとるだけではなく、管理・分析の元になる理論とその運用が妥当でなければならない。

この記述の次ページにある「●測定量」には、導出測定量として、「レビュー指摘密度」「レビュー工数密度」「レビュー指摘効率」「欠陥密度」「テスト密度」が例として挙げられている。
ここに挙げられた5つの理論は堅牢だろうか。その運用はいかがであろうか。

例えば、レビュー指摘密度ひとつとっても、以下について考えなければならないはずである。
算出方法として次の2つが挙げられている。
・レビュー指摘件数÷規模(FP、LOC)
・レビュー指摘件数÷レビュー対象規模(ページ数)
さて、これらの「管理・分析の元になる理論」は堅牢なのだろうか。
つまり、レビュー指摘件数は規模に対し明確に比例するというのは正しいのだろうか。

また、その運用(誤差等の範囲)も十分な合理性を有するのだろうか。

これらは「なんとなくそうではないか?」以上に合理的に説明すべきである。
「規模が大きければ指摘も多いだろう」という大雑把な直観が、「定量的管理」のベースであるならば、その精度も大雑把であるはずである。

4ページのレビューを行って出た指摘件数は2頁のレビューの指摘の2倍になっているものだろうか。そんな訳がないというのであれば、ではどのような場合、「レビュー指摘件数÷レビュー対象規模(ページ数)」が成り立つのだろうか。
この問いに対し、よく考えずに、

レビュー指摘密度=レビュー指摘件数÷レビュー対象規模(ページ数)

と言うのは、正しい定量的品質予測とは言えないだろう。
そもそも、正比例するとなぜ言えるのか、から考えるべきである。

もちろん、10ページと100ページでは、100ページの方が指摘の絶対数は多いだろうということは言えよう。しかし、これが正比例するかと言うと・・・。
仮に正比例するとしても、設計書の枚数が多いというのは、それは複雑な設計を表す可能性もあり、その場合、指摘の割合が一定ではなく、増えるかもしれない。

考えれば尽きない。
これを管理に値するように整理するのが、先に述べた、管理・分析の元になる理論の運用が妥当でなければならないということである。

レビュー指摘密度ひとつとっても、定量的管理が「驚くほど簡単にできる」とは思えないのである。
但し、ここでいう、定量的管理は、統計的意味での定量的管理を指す。
実は、単に開発者の目標、つまり「ここまでは必ず指摘を挙げろ」もしくは「われわれは過去実績対比これだけの指摘を挙げた、だからもう十分だろう」と宣言するための定量的管理であれば、有効であると思われる(普通はこれを定量的品質予測とは呼ばないとは思うが)。

2011年4月19日 (火)

【続定量的品質予測のススメ】「前作のポイント」のポイント①

本書では、本題に入る前に「前作のポイント 『定量的品質予測のススメ』のエッセンス」として、6ページにわたるおさらいがある。

基本的に前作の話なので触れないが、1点重要と思われる箇所を挙げておく。
P11「●測定単位」において、

①測定単位を小さくして品質データ(欠陥数など)を測定することにより、詳細な品質管理・分析が可能

②測定値を集計することにより、当該工程の品質管理・分析が可能

ということが書かれている(実際の記述は①②ではなく、「・」で列挙されている)。

これは、考えとしては正しい。
しかし、これの現場運営は非常に難しい。

まず①について。
「測定単位を小さくして品質データ(欠陥数など)を測定すること」は、1つの管理単位が小さくなることであるので、サンプルデータ数が少なくなることによる管理用基準値等の設定の妥当性が低くなるリスクがある。測定単位を小さくすればそれだけ個々のプロジェクト由来の誤差も増える可能性がある。また、妥当な測定単位の分割がなされないと、手間と誤差が生まれるだけで意味がないかもしれない。

よって、「測定単位を小さくして品質データ(欠陥数など)を測定すること」により、直接「詳細な品質管理・分析が可能」が導かれるのではなく、詳細な品質管理・分析の可能性が得られるだけである。

細かくすれば全てうまくいくのであれば、設計書であれば1行ごとの管理、プログラムソースであれば1LOCごとに定量的品質予測をすれば良いはずである。
しかし、これは誰もが暴言であると思うであろう。
ならば、妥当な単位があるはずであり、故に「測定単位を小さくして品質データ(欠陥数など)を測定することにより、詳細な品質管理・分析が可能」は言い過ぎなのである。
結局、どこを妥当な測定単位とするかは各組織でよく考えなければならないが、これは測定開始時によく考えるべきで、よく考慮せずに計測してみて、「うーん、大雑把過ぎた。もう少し細かくしよう」等とならないようにすることが肝要である。

2011年4月15日 (金)

【続定量的品質予測のススメ】誰でもできる定量的品質管理

P7の見出しに「誰でもできる定量的品質管理」とある。

キャッチーなフレーズで引き付けて、でも実際は難しいのですよと受けるのかと思いきや、本文には「実は基本的なレベルは驚くほど簡単にできる」とまで書かれている。

これは、著作者のスタンスを率直に表しているのであろうが、本心で簡単だと思っているのであろうか。

もし、ソフトウェア開発の定量的品質管理が、「驚くほど簡単にできる」のであれば、なぜ続編を作る必要があるのだろうか。本編で簡単に書ききれば良かったのではないか。しかも簡単だという続編は本編よりはるかに分量があるし、なぜか定量的管理そのものではない上流工程のレビューの方法について厚く書かれている。

もう一つ気になる記述は、定量的品質予測を行えば、赤字・プロジェクトメンバの疲弊・貧弱な品質を防ぐことができるかのように書かれている。

間違いなく言えることは、仮に定量的品質予測だけしっかりできても上記を確実に防ぐことはできないわけで、このような大風呂敷は、本書の本体に書かれている「地道な例」を挙げる努力を踏みにじるものである。

赤字・プロジェクトメンバの疲弊・貧弱な品質を防ぐことが驚くほど簡単にできるのであれば、苦労しないのである(これ以上は自主規制)。

本当に、本書で実現できるのであれば・・・、本書は一冊1000万円でも安い。
それが、1680円で手に入れることができるのである。

この書籍の甘言・・・信じる信じないはあなた次第です。

2011年4月13日 (水)

【続定量的品質予測のススメ】出版されました

「続定量的品質予測のススメ」が出版されました。

本書は、元の書籍である「定量的品質予測のススメ」で定量的品質予測を勧められても、なかなか実践できないという声に応えるため、「定量的品質予測を実践する上での阻害要因を明らかにし、問題解決を図ることで、現場で率先して定量的品質予測を実践できることを狙いとしています」ということである。

確かに、ソフトウェア開発における定量的品質予測の実践は非常に難しいものであるので、組織は「定量的品質予測のススメ」を読んでやる気になってもすぐ手が止まってしまうはずである。

「定量的品質予測のススメ」は、初心者向けの題名と体裁ながら、実際に初めて定量的品質予測を行う者には読みこなせない内容であると思える。
実践にあたっての落とし穴や注意点がすっぽりと抜け落ちているからである。段階を経ずにいきなり細い綱渡りはこうやるんだ、さあ渡れと言っているような感じだろうか。

おそらく、そのような意見が多く寄せられたのであろう、「続定量的品質予測のススメ」が「定量的品質予測のススメ」の行間を埋めるための書籍として発行された。
良いことである。

特に、行間の埋め方が、理論武装でというよりも、実践の知恵による武装に力点が置かれているように見える点が良い。

本書は、その意味で画期的であり試みは称賛されるべきものである。
しかし、その成果は道半ばと言わざるを得ない。

これは、本書の執筆者のせいというよりも、ソフトウェア開発における定量的品質予測が容易ならざるものであるという事実によるものと考える。

2011年4月 1日 (金)

【成功するプロジェクトマネジメント】そもそも成功とは何だろうか

ソフトウェア開発における成功とは何だろうか。

プロジェクトの失敗原因はリスク管理がまずいからであるとか、見積もりが甘いからであるとか言われたりする。一見信じられそうだが、このような一元的理解は良くない。

プロジェクトの失敗は、本当に見積もりやリスク管理が弱いからなのだろうか。実はその逆で、見積もりやリスク管理がなまじできるから失敗するということはないのだろうか。

リスク管理能力も見積もり能力も弱く心配症だが、弁だけはたつプロマネがいたとする。彼/彼女が、その話術で上手くジャブジャブの計画を認めさせることに成功すれば、そのプロジェクトの成功確率は上がるのではないだろうか。
コストとスケジュールを守れば成功だというのであれば。

しかし、これは真の意味でのソフトウェア開発の成功なのであろうか。

確かにソフトウェア開発をプロジェクトとして考えれば、予算通り計画通りにプロジェクトを終えることが成功なのであろう。
しかし、それはプロジェクトとしての成功なのであって、当該システムを調達するユーザにとって本当に成功なのだろうか。

ソフトウェア開発の失敗を単純に予算や開発期間の超過だけで評価してはいけないのではないだろうか。
もちろん予算も開発期間も大切である。それは当然のことである。

しかし、同じプロジェクトを別々に行ったとして、成功プロジェクト対比、低コストかつ短期間で終えながら失敗プロジェクトというレッテルが貼られるものがある得るのではないだろうか。

つまり、ジャブジャブに予算、コストを積むということは、SIにとっては成功プロジェクトの秘訣かもしれないが、当該システムを調達するユーザにとってはうれしくなどないことであると。

計画通りを是とする傾向がある組織は多いだろうが、ソフトウェア開発の成功は、いわゆるプロジェクトマネジメントの成功とは違うのではないかと言う視点・・・これを持つことは意義あることだと思いませんか。

« 2011年3月 | トップページ | 2011年5月 »