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年5月 | トップページ | 2012年1月 »

2011年7月

2011年7月26日 (火)

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

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

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

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

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

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

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

2011年7月16日 (土)

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

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

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

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

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

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

2011年7月12日 (火)

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

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

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

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

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

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

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

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

2011年7月 8日 (金)

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

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

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

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

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

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

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

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

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

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

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

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

2011年7月 5日 (火)

【続定量的品質予測のススメ】定量的管理とは何をすることなのか

P36の「表1 組織の定量化のレベルと企業文化」において、定量化のレベル3のプロジェクトマネージャの定量化に対する意識として「数値目標の達成だけに注力している」というのが、未熟な意識として書かれている。

これは非常に微妙な記述ではないだろうか。
PMは現実主義であるべきで、このようなスタンスでいることが本当に未熟と言ってよいかためらわれる。

再考の定量化の最高レベル4では、PMの意識は「プロジェクトの実績を測定し、データを提供するのは当然であると考えている」「分析結果をプロジェクトの改善に役立てようと努力している」と定められている。
逆にこのような意識がPMの定量化に対する最高の意識というのは引っ掛かりを覚える。

「プロジェクトの実績を測定し、データを提供するのは当然であると考えている」というのは、現実主義者であるべきPMがこれほど盲目的に「当然であると考えて」いてよいのであろうか。

また、「分析結果をプロジェクトの改善に役立てようと努力している」という努力が無に終わることはないのだろうか。

定量的管理に「これとこれを実施すればソフトウェアの品質は必ず担保される」というものがあれば、上記2つを言い切っても構わない。
しかしそのようなものはない。

「数値目標の達成だけに注力している」のは、その数値目標を達成すれば良い品質を得られると信じているからだと思うが、それを否定するということはどういうことなのだろうか。
数値目標の達成よりも重要な事項があるのであれば、数値など測らずに、その重要な事項を行えばよいのではないだろうか。

「プロジェクトの実績を測定し、データを提供するのは当然であると考えている」のも、何もわからずに盲目的にデータを提供するという姿勢であるのであれば全く褒められたものではないと考えられないか。

工業製品で、例えば18センチ四方の折り紙を作成というようなものであれば、常に計測して異常値の傾向を掴むことは重要で、その場合は、「プロジェクトの実績を測定し、データを提供するのは当然であると考えている」「分析結果をプロジェクトの改善に役立てようと努力している」というのは全くその通りで推奨できよう。

しかし、それが本当にソフトウェア開発に当てはめて良いのであろうか。

先の折り紙であれば、作成後の折り紙を計測し「各辺が17.9センチから18.1センチなら合格」と定めれば、その検査を行うことで折り紙の品質は必ず担保される。
しかし一方、ソフトウェア開発には、「これとこれを実施すればソフトウェアの品質は必ず担保される」というものはない。

「プロジェクトの実績を測定し、データを提供するのは当然であると考えている」「分析結果をプロジェクトの改善に役立てようと努力している」という前向き姿勢だけでは未熟な意識ではないだろうか。

定量化に対し、批判的な視点にも立つ意識が必要であると思う。
実は、先の「・・・改善に役立てようと努力している」という表現にその意識が微妙に表されているとみえないこともないが、明示的ではない点で良くないと考える。

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