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

« 2010年4月 | トップページ | 2010年6月 »

2010年5月

2010年5月28日 (金)

【ソフトウェア開発品質改善】チェックリストはユーザに対する背任行為

チェックリストの有効性というものは理解できる。
しかし、何かあると直ぐにチェックリストの項目追加で再発予防策は終了というのは、ユーザに対する背任行為ではないだろうか。

開発における構造的課題の存在可能性があれば、それを見つけ取り組むべきであり、それをせずに、安易にチェックシートで確認しますとして終わらせるのは、すべきことをせず小手先のチェックでやり過ごそうという姿勢として背任行為と考えるからだ。

「我々は1000項目に渡るチェックリストを持っています」と言われた場合、ユーザや上位経営層はどう感じるだろうか。
よくやっていると褒められるか、そんなにあるとチェックリストによるチェックがちゃんと行われているかのチェックがまた必要ではないかという危惧を覚えられるか。

チェックリストはユーザに対する背任行為・・・この視点でチェックシートを見直すことは意義あることだと考える。

チェックリストによるチェック作業は人手によるものなので、他の方法では実施できない場合、もしくは他の方法で見落とす可能性がある場合にそれを補完する手段として位置づけるべきではないだろうか。

2010年5月25日 (火)

【定量的管理】ソフトウェアメトリクスの業界基準はないのか!?

今日もこの世界の誰かがどこかでわめいているであろう言葉として「ソフトウェアメトリクスの指標値の業界基準みたいなのはないのか!?」を挙げても、この業界の人であれば反論しないであろう。

これは全く無いというわけでじゃない。
そのようなデータを商売道具にしている会社は現に存在する。

しかし、それをそのまま自社の開発指標として使うこは大抵の開発者/PMにとって違和感を覚えることのはず。

さて、先の質問は、大抵の場合、「システム、プロジェクト毎の特性から異なるべきもの」という言い訳の下、「そのようなものは無いし、あっても特性の考慮がなければ精緻な管理には使えない」と答えられることが多いだろう。

しかし、別に「システム、プロジェクト毎の特性」を鑑みたところで、「精緻な管理には使えない」というのが正解ではなかろうか。
そうでなければ、「システム、プロジェクト毎の特性」に対応する厳格なマニュアルというものが、この世に存在するであろうが、見たこと無い。

となると「システム、プロジェクト毎の特性」への対応自体があやふやなわけで、これではどうして「精緻な管理」ができようか。

逆に、「ソフトウェアメトリクスの指標値の業界基準みたいなのはないのか!?」は、真理をついた問いかけではないかと考える。

この問いかけをしている人は、基準が欲しいのではない。
このメトリクスを使って厳格な管理がしたいと言っているだけなのだ。
この人にとっては、業界基準値がなくとも、システム、プロジェクト毎の特性に応じた基準値の明確な策定方法が定義されていれば満足であろう。

ここに気づかず、「システム、プロジェクト毎の特性から異なるべきもの」と答えて「これだから分かっていないヤツは・・・」みたいに言ってはならない。

細かく考えれば精緻というわけではないのだから。

2010年5月 7日 (金)

【ソフトウェア開発メトリクス】単純化して考えることの意味【再考】

ソフトウェア開発におけるメトリクス管理の肝は、
   複雑なソフトウェア開発において、
   
その開発状況を一面から見ることで、
   単純化し
定量的に把握すること
にあるはずである。

故に、単純化し定量的に把握することの意味と価値を台無しもしくは無効化する活用法しか考えられないメトリクスに価値は無いのではないだろうか。

例えば、「このメトリクスだけで判断するのはダメ」の様な留保は、ではどうすれば良いかについてまで論理的に表現、少なくとも方向性は出さないと、実際に使いようがない。

「このメトリクスだけで判断するのはダメ」というメトリクスを100個組み合わせても、それで良いのかダメなのか分からないのでは、実施する意義を見出せない。

例えば、テスト実施件数が少ないかどうかは、本当のところ、テスト実施者の本心を聞いた方が、実施件数を開発規模(これが既に確定的に計測できるものでは無い)で割ったものをニラんでうなるより、よほど効果があるのでは無いだろうか。

先進的開発組織であれば取り組めばよいが、未だメトリクス管理実施前でも開発手順に改善の余地がある組織は、まず見えている改善に取り組んでからメトリクス管理を始めれば良いのではないか。

そのうちに「定量的管理の定石」が出てくるであろうからそれを待って開始すればよかろう(個人的には出ないと思っているが。またひょっとして寡聞にして私が知らないだけで既に存在しているのかもしれない)。

「定量的管理の定石」…これは、誰もがその通りに実施すればソフトウェア開発の定量的管理ができるようなもの。もちろん「その通り」にはテーラリングが必要であっても構わない、というかおそらくそれは必須だろう。

2010年5月 4日 (火)

【生産性向上】調達側からみた生産性向上の意味③

先に、「しかし、他者の努力による他者が得るべき利益を掠め取ろうとしてはならない。他者に自分が依存している時はなおさらである」と書いた。

これは、発注側の担当者レベルより経営者レベルでより重要な考えである。

担当者が「人月単価を1割減らしました」「SI会社提示の見積もりを1割減額させました」と言って来て、「よくやった」などと言えるだろうかと少し考えれば自明であろう。

SI会社も利益が欲しいのである。

まあ、発注側が1割減で喜んでいたところ、プライマリのSI会社は2次請けに2割減要求して・・・が繰り返され、最後に担当するのは当該言語は3ヶ月前に学びましたとかいう人が来るみたいな悲劇が展開される可能性は高い。

発注者側は、怒れば良い、締め付ければ何とかなる…とか思っているかもしれない。
しかし、怒らなければならない事態が起きるのを最初から想定した開発に明るい未来は無いであろう。

単価引き下げ交渉が成功して、単価以外何も変わらないと本当に喜んで良いのか。

答えは、イエス・・・発注者側の担当者ならば。
彼のミッションは単価引き下げ交渉なのだから。

では、経営者はどうであろうか。
単純に喜ばなくとも、担当者に「単価以外何も変わらないように良く監視しておけ」という経営者はどうだろう。

そんな経営者などいるはず無い?
ならば良いですが。

« 2010年4月 | トップページ | 2010年6月 »