2018年3月21日 (水)

【ソフトウェア開発データが語るメッセージ2017】「はじめに」について

IPAが2018年3月6日に公開した「ソフトウェア開発データが語るメッセージ2017~生産性・信頼性の経年推移の分析から~」(https://www.ipa.go.jp/files/000064508.pdf)を採り上げる。
IPAが長年蓄積してきたデータの経年推移をみるということで、試みとしては非常に良いのであるが、中身が微妙というか、そう分析するのかと思える箇所が多いので、IPAの考えについて、ななめからの切り口で見ていきたい。
本書の「1.はじめに」にあるが、本書は、『「ソフトウェア開発データ白書 2018-2019」(以下、白書)の最新データを試行分析した結果に基づいている』とのことである。つまり、本書はIPAの次の版の白書における”考え方”を公開していると予想して良いだろう。
また、本書の利用シーンは、「白書と併せて、主にプロジェクト 計画の妥当性評価や組織の品質・生産性マネジメント改善検討のためのベンチマーキングに利用されることを意図している。プロジェクトマネジメントにおいて本書を利用できる主なシーンは、主にプロジェクト計画及びプ ロジェクト再計画である」とのことである。
つまり、本書には、IPAが推奨するプロジェクト計画およびプロジェクト再計画の方法が記載されているので、これを利用して計画を策定すれば、何か誰かに言われた際も「IPAの公開文書に書かれています」とまずは返すことができるので、そのようなお墨付きで納得する相手に対しては非常に強力なツールとなる。

少し更新

ずっと放置していますが、少し気になることがありましたので、更新してみます。

2014年6月11日 (水)

【定量的管理の疑問点】バグ摘出密度へのu管理図の適用

さて、再度バグ摘出密度について考えてみる。

上下限値管理にはx管理図的な絶対値によるものではなく、u管理図を用いることで評価する規模に合わせた上下の管理限界(≒上下限値)設定をして管理すると言う方法もある。

これ、一見凄いことのように見える。
規模に応じた適切な値に上下限値が変わっていくのだから。

しかし、これは単に評価対象の開発規模が小さいとブレは大きいよと言っているだけの話で、それを有難がる意味は無いと個人的には思う。

但し、どんなに気合いを込めた開発だろうと、どんなに機械的な開発であろうと、ソフトウェアの開発である限り、バグは開発規模に対し離散的に埋め込まれるので、バグ摘出密度はバラついて当たり前だよということを視覚的に開発者および管理者に意識させてくれる。この点でu管理図はx管理図的な管理より啓蒙的であると言えよう。

とはいえ、u管理図も実績データからの平均値一本で全てが決まると言うモデルの性質上、限界はある。
しかし意外にも現実がモデルにあまりに上手く当てはまることも多く、個人的には神秘的なツールだという印象がある。

2013年11月27日 (水)

【定量的管理の疑問点】バグ摘出密度の上下限幅が2倍なのはどうなのか

バグ摘出密度の上下限値が2倍やそれ以上の幅となっている組織は多いと思われるが、これについて違和感を覚えないだろうか。

他の指標、例えば生産性実績を2倍以上の幅で管理されていたらどう思うのであろうか(個人的には別にそれもありと思うだけだが)。

管理するに妥当な範囲とは何か考えもせず適当な実績値持って来て箱ひげの見た目で判断してないだろうか。

そしてこのような大きな幅を持っていることに対して「バグ発生は離散的だし、統計的に十分な数のデータ集まっていないからこの程度のバラツキは許容すべき」とかを何の検証もなく直感で言って終わらせていないだろうか。

いやいや、このような管理はダメだと思われる。
管理というより管理もどき。

バグは離散的データ。だからこそちゃんと考えないと。

2013年11月20日 (水)

【品質保証】「チェックリストに追加します」がダメなわけ

何か問題があってうまい再発防止策がない際の苦肉の策である「チェックリストに追加します」の問題点。

本来チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するためのもの。しかし活用開始すれば直ぐ行動者は監査や品証への先回り的にチェックリストを満たすよう行動し始める。

チェックリストの項目いくら増えてもここまでならまだ問題は少ない。
しかし項目多くなるとその内チェックリスト項目を満たせば良いという者が出てくる。それでもまあチェックリストの体はなしているが、更に項目多くなると最後に"本プロジェクトでは対象外"をためらわず乱発するのが出てくる。何のためのチェックリスト。

また項目多いと本来のチェック側もよく分からなくり本来すべきをしなくなったり/できなくなったりする。実質使われないのと一緒の状態。それでも漏れのないフルスペックチェックリスト名の下に続々と項目追加され、一方で運用は破綻する。

最初に戻ると、チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するもの。しかしその予め定めた事項は詳細でないといけないのだろうか。チェックリストの使用者はチェック対象の素人なのか。チェックリストはチェックすべき項目全て詳細に網羅すべきものなのか。分野や使用目的によると思う。
チェック者でなく実施者がそれを満たすための用途ならもはやそれをチェックリストと呼ぶ必要はないし、基本的なことならいちいちリスト確認させるというより身につけさせるべき振る舞いである。だからチェックリストは本当に漏れやすい事項についてチェック能力を有するものが分かる程度に簡潔に作成するべきものであり、故に安易に増やし続けることは良くないのである。

2013年9月22日 (日)

【LOCとFP】違いを肉の値付けにたとえてみた

LOCとFC。

その違いが分かるように肉の値付けでたとえてみた。

【LOC】 
グラムいくらで価格を決定
部位が異なっても価格に影響しない
肉が牛か豚か鶏かを問わない

【FC】
部位のまとまりの単位(もも1足、ひれ1枚等)で価格を決定
もも一足が牛・豚・鶏で大きさが異なっても価格に影響しない
肉が牛か豚か鶏かを問わない

こんな感じではどうか。
LOCとFPでは異なる点に着目しているというのはそれぞれの存在意義であろう。

このように整理してみれば、両者が何をしようというのが多少わかりやすくなると思う。

肉の場合、大抵は、国産・牛・サーロイン・500グラムのように買う。
しかも、国産と言っても更に産地が細分化されたり、牛と言っても品種が明示されたり等級があったりする。

しかし、LOC的考えでは、「肉を500グラム」と言うだけであり、FP的考えでは「レバー1個ともも1つ」と言っているだけである。

肉を買うときにLOC的考えやFP的考えでは買わない。
LOCやFPのどっちが優れているか論争のもやもやはこのような点に根があるように思う。

2013年5月15日 (水)

【品質改善】組織は品質改善ツールと技法のどちらを積極的に採用しているか

自組織は品質改善ツールと技法のどちらを積極的に採用しているかを考えてみると、組織の品質改善に対するスタンスが分かるのではないだろうか。
(ここでは重要部分を人以外が行う方法をツールとし、重要部分を人が行う方法を技法とする)

さて、積極さである。
非常に簡素化して次の4つに分けて考えてみる。

1.【ツール】積極【技法】積極
2.【ツール】消極【技法】消極
3.【ツール】積極【技法】消極
4.【ツール】消極【技法】積極


1.【ツール】積極【技法】積極

拙速は手戻りが大きい等現実には色々考慮すべき点もあると思われるが総論的には、これは良い組織といえるだろう。


2.【ツール】消極【技法】消極

逆にこちらは、競合に置いていかれるから積極性を持つべきだというのは総論的には正しいであろう。
競合がなければ伝統工芸化することも可能かもしれないが。


そして、今回本当に議論したいのは次の2つ。
これらはどの様な時に生ずるのであろう。

こちらもステレオタイプで考えて行く。


3.【ツール】積極【技法】消極

このような組織は、品質改善施策というと、誰かがどこかからツール持って来てほら使えとなるケースが多いのではないだろうか。

ツール入れたがるが、頭使うのはちょっと…ということ。
組織の偉い人がどこかで聞いて来たツールというケースはまだ良いかもしれない。
偉い人が理解できないと採用できないという組織もこのケースになるのではないか。
ツール、特に有料ツールは営業用に採否決定者の能力に合ったプレゼン資料をうまく作るだろうから。でも、お金にならない技法はそういう採否決定者が理解できるプレゼン資料作ってくれる人いないから…。
折角高価で有益なツールを導入してもそれを活かす技法が偉い人用の割り算中心のメトリクス以上にならず、残念な組織は多いと思う。

このような組織は、ツールを導入することが即ち成果なので、元が丸のところに四角のツールを押し込んでも是とされる。
とにかく導入フェーズが全て。

しかしツールは本来、導入前と後、特に導入後が大切だと思う。当たり前だが。
どこかからツールを持って来て、さあ使え使えとやって、お、使ったな、はいOKではツールがもったいない。

これでも良いと言えるのは、どうしようもなく管理ができていない組織だけではないだろうか。


4.【ツール】消極【技法】積極

改善意識はあるが、原則現状と連続した改善が中心で、概念が変わったりフローが大きく変わるツール導入には消極的。

しかし考えることは出来るので、組織内では状況は改善し続けていると考えている。

3.と逆でトップが特にリーダーシップを発揮せず、現場主導の場合こうなるのではないだろうか。
だから、トップが一声掛かれば、1.になる素因を持っている…はず。


最後に…

ここまで勝手にステレオタイプな
考えを書いておいてなんだが、どの組織も1.を目指すべきなのだろうかとも思わなくもない。

…いや、やはり目指すべきなのだろう。

2013年5月14日 (火)

【LOCとFP】これこそまさに目的は何かの世界

LOCとFP。
一方の宣伝屋の言うどちらが優れているか論をただ受け入れるのではなく自分の使いたい用途で使い分けるべきだろう。

とはいえ、どちらも帯に短したすきに長し。というか、中には帯にもたすきにも使えない単なる布切れ程度と考える人もいるだろう。

しかしサイクロマチック数だとかハルステッドの何とかならOKと言われているのでもない。

そこで残念ながら冒頭の、

自分の使いたい用途で使い分けるべき

という言葉が出てきてしまう。
嫌いな言葉だけど。

LOCは言語や開発者によるバラツキが大きすぎるというFP側の人もいれば、FPは大雑把すぎて開発中の管理に不向きというLOC側の人もいる。

どちらも一面正しい。

調べるとFPの方が良い様な気がするが、これは、後発のFPがLOCへの批判を叫ぶことで売り出したからではないかと思えてしまう。個人的印象だけれど。

fault-proneモジュール予測でFP使うべきという人は見ないからやはり実際の開発フェーズではFPは使いづらそう。

LOCとFPとその他色々なもの…
不本意ながら用途に合わせて使い分けるしかないのだろう(今のところ)。

何を今更なエントリーとなったが…実際に開発している人でこういうの意識せずにどちらかのみを信じて?使ってる人多いと思うので改めて書いた。

2013年4月22日 (月)

【雑感】アカデミアとインダストリーの協働すべきポイント

久しぶりのエントリー。しかし単なる雑感(しかも短い)。


ソフトウェア工学分野も産学連携が言われるけれど、定量的管理分野の狭いところを見てもそれが上手くいっていないように思える。

ここ数年においても、バグ密度やテスト密度に触れる経験論文が生まれる一方で、fault-proneモジュール予測に関する研究論文が世に出ている。

これらは、結びついているのだろうか。両立するのであろうか。

一方でバグの数を予想し、もう一方ではバグを含むモジュールを予想する。

確かに両者が組み合わさればお互いを補い合って相乗効果が見込める…のだろうが、そんなに上手く行くのだろうか。

なぜこのような産学の分離が起きているのか考えた方が良いと思う。特に品質が利益に直結するはずのインダストリー側の人は。

この辺りは本当に協働すべきところだと思う。
不可侵条約結んだかのように無いものとして進めるのはもう無理な時期ではないか。

このような定量的管理分野の狭いところを見てるから上手くいっていないように思えるだけなのかもしれないけれど、ソフトウェア工学分野の産学連携、上手くいっていないように思える。


2013年3月 4日 (月)

【バグ曲線〜何度目かの…】なぜ収束するのか

ソフトウェアテストシンポジウムJaast Tokyo'13で「なぜバグ曲線は収束するのか~Microsoft Excelを使って考えてみる~」(丹羽)という発表があった。
その場にいたし、当日発表資料と論文が以下に公開されているのでこれについて書いてみる。
 http://www.jasst.jp/symposium/jasst13tokyo/report.html 

この発表の論旨は、つまるところ、

テストケース中にどうしても含まれるテスト確認項目の重複と、バグを早く出そうというテスト実施者の恣意によるテスト実施順の2つが原因となってバグを前倒しで叩き出すことでいわゆるバグ曲線はあの形になる

と言っている。

言っていることは理解できる。

ただし、この2つの要因だけで、たくさんの事例で見られるあの曲線が本当に生まれるのかは、今回の説明だけでは分からない。
収束に寄与しうるということが分かっただけである。
これは発表においても言及されている。

だから本当はここで説明されていない別な要因があって、その寄与の方が大きく、今回の2つはあまり収束に関係ないという可能性は残ったままである。

まあ、そうではあるが、バグ曲線の収束理由について、あまり考えずに活用している組織が多いのは、そうであろうし、この理由について考えるべきと問題提起した意義はある。


しかし、論文も発表も同じであるが、その構成はよくない。

この発表では、結局、上の2つの理由からテストケースを用いたテストのバグ曲線管理は非常に難しい、というか、実質無意味に近いということを言外に言っている(ように見える)。

それはそれで、まあ良い。

とはいえ、最後の最後にテストケースに縛られないベータテストや運用テストでは、この2つの束縛から自由なのでバグ曲線管理はうまく行くのではないかみたいなことをさらっと言っている。

これは酷い。
現状高々5枚半の論文なのだから、このテストケースに縛られないテストにおけるバグ曲線の性質について述べるスペースは十分残っている。

これについて説明しなかったのは出し惜しみと言われてもしかたがない。。

そうは言いながら、発表資料にもあるが、バグ曲線の活用について、ここで示された収束理由を元に、品質担当者、開発者、上位マネージャー、そしてバグ曲線を納品条件にするお客様と議論してみることは良いことなのではないだろうか。

このような管理を生業とする人たちの好きなExcelを使って…という提案は良いと思う。
本論文ではそのために、採り上げた2つのバグ曲線収束理由の説明をExcel関数を用いているのだという。

«【データ指向の…(デート本)】多分もの凄く中身のある本…多分、多分