クオリティーコントロール

投稿者

投稿内容

たーぞう: ぬし; 会議室デビュー日: 2003/08/08; 投稿数: 317; お住まい・勤務地: お花畑

投稿日時: 2004-04-05 15:15

ソフトウェア開発における品質管理の方法として、例えば以下のようなものがあります。

　１．ドキュメントに対して
　　　レビューの開催
　　　　対象：　要件定義書、仕様書、設計書等のドキュメント
　　　　成果物：レビューシート
　　　　合否判定基準：レビュー指摘密度（例：０．５件／頁以上の指摘があること）

　２．プログラム、システムに対して
　　　　成果物：プログラムチェックリスト、バグレポート、・・・
　　　　合否判定基準：試験密度（例：５０項目／Kstep以上の試験を行うこと）
　　　　　　　　　　　不具合摘出件数（例：４件／Kstep以上不具合を検出すること）

テスト工程における合否判定基準は、単体テスト・結合テスト・システムテストによって当然合否判定基準は変わります。

バグレポートには、単に誰がどのようなバグを発生させたかだけではなく、バグの要因がどの工程で発生しているのかや、バグを発生させた動機を分類して記入します。これらの情報を集計することにより、システムの品質を統計的に分析することができるようになります。

ISO9001を取得している企業では、このような品質管理手法を必ず適用しています。このため品質管理のための工数がかなり取られることになりますが、これをやらないとソフトウェアの品質が悪化し、結果的にさらに多くの工数が取られたり、最悪プロジェクトが中止になったりするため、多少工数がかかっても品質管理は行った方がよい、とされています。

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2004-04-05 17:47

またまた蛇足ですが．．．

確かにISO等製造業と同様な「品質管理」というものはできつつあります。でもこれは
先ほども書いたように、「ばらつき」を無くす、つまりシステム全体、会社全体で一定
の品質を保つ為の手法なのですよね。
ですから、ある会社でISOの規定や社内規約が整備できていた場合、「どんな開発案件で
常にバグは３～１０件出る。」という状態は品質的には○なんですよ。
能力の高いベテランが開発しようと、初めて携わる進入社員が携わろうと、同じ不具合
件数であるということが、製造業における品質管理の目標のひとつなんですね。（何も
なければもっと不具合が多いということを考えれば、無駄なことではないのですが）

ただ、今ソフトウェアに求められる品質というのは「市場不具合」つまり、リリース後
に発覚する不具合が０ということが命題です。極端に言えば「内部テストで何百万件の
バグが見つかっても、カットオーバーまでにすべて修復できれば良い。」という考え方
になってしまいます。これをそのまま受け止めると１にもテスト、２にもテストという
具合になってしまうわけです。

ソフトウェアのように「同じものは２つと無い」というような開発における品質の捕ら
え方というのはもう少し踏み込む必要があるのではないかと。また逆にそこまで品質
に捕らわれてしまうと「開発」「研究」ということができるのか？という逆の問題にも
ぶち当たるわけです。

唯一というか、これをなんとかできそうなのが最近流行ってきたスパイラル手法等かなと
思うのです。ただ単に工程を繰り返していくのではなく、何回目かの繰り返しの段階で
品質に重点を置いた（いわゆる「製造」）作り方のフェーズを設ければ、製造業的な
品質管理もある程度、当てはめられるのではないかと思うのですけどね。

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2004-04-05 18:51

るぱんです。

非生産的な話です。
自己満足できるだけのテスト項目をテスト・・・。

様々な視点で自分なりにテスト項目を作って、
チェックしてもらう事だけはしてもらってます。

抜けが有る時は、
「負けた・・・。」
と落ち込んでしまいます。（汗

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-04-05 18:58

はにまるです。
分割登稿します

ＴＱＣは、障害発生に関係無く「問題を発見して、それを改善する」行動パターンを取ります。
この考えをシステム開発で取入れる際は、その問題を直接解決するのでは
多種性を持つソフトウェアの性質上、効果力が弱くなる為、
「問題の原因追求」と「問題のパターン化」と言う工程が必要となります。

これにより、単純なプログラムバグ、単純な作業ミスは減らせると考えますが、
「制御の複雑性から発生するバグや作業ミス」及び、
「サービス品質」という顧客満足度に関わる話に適合する事は困難です。

複雑な制御性から発生する箇所は、
制御の単純化、作業を制御する仕組みを取入れる必要があり、
これはテストの範疇ではありません。

また、サービス品質に関しては、
判断者がお客様である為、最終テストは開発側に存在しない事を
肝に銘じた対策をとる必要があります。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-04-05 19:10

はにまるです。
分割投稿その２

ＩＳＯですが、私のポジションで見たＩＳＯは、管理資料の作成を義務ずけるだけのモノにしか見えません。
（これはやはりＩＳＯ規格外ですよね？勉強不足です。

）
目的／問題発生時の対策手段／管理資料の提案先の連絡が無く、
一歩的な義務付けは「管理」の概念からすれば明らかにおかしい話です。

また、ＩＳＯにより管理工数が増える結果の費用を資格取得の企業が全て担うのであれば宜しいのですが、
実際にはその費用を発注先に依頼している企業が多いのも実状では無いでしょうか？
受注側の企業もバカではありません。そのツケは別の形で発注側へ廻します。
このサイクルを考慮にいれて無い所が、品質管理という概念の抜け落ちであり、
品質対策の形骸化となる原因の１例と考えます。

品質はいくつかの部類に分かれる為、個別の対策手段を講じ、その対策に用するコストの調達方法、
費用対効果を見極める手段まで提示して管理と言えると考えます。
また、管理である以上、経営管理とリンクして置かなければ「品質管理」が宙ぶらりんになる恐れが強い為、
そこの関連付けも提示する必要があると考えます。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-04-05 19:20

はにまるです
分割投稿その３です。（これで終わり）

今日システムが複雑化していますので品質は、そろそろ開発側の視点で無く、利用者の視点で対応する必要があると考えます。仕事の基本である依頼者が責任を持つ考えです。
実際には開発側からその案を直接提示する事は問題がある為、提示手段は考える必要がありますが．．．

現在の品質に対する根本が「契約」つまり開発側の商売に基づいて考えている所があります
この根っこを元に話をすれば、対策の限界、つまり品質の限界が生じます。

システム規模や性質により自社内のみで品質対策を取った方が費用対効果の視点から
管理上好ましいと判断したのであれば宜しいですが、
とりあえず、お客様を巻き込むか否か判断をするステップが必要と考えます。
当たり前のような話ですが、実際にお客様へ相談しているＰＭは少ないと感じます。

品質対策の為だけにプログラムを作る事も考える等、視点の切り替えが必要と考えます。

以上が本日、皆様の意見を読み考えた内容です。

たーぞう: ぬし; 会議室デビュー日: 2003/08/08; 投稿数: 317; お住まい・勤務地: お花畑

投稿日時: 2004-04-06 11:23

引用:

はにまるさんの書き込み (2004-04-05 19:10) より:
ＩＳＯですが、私のポジションで見たＩＳＯは、管理資料の作成を義務ずけるだけのモノにしか見えません。
（これはやはりＩＳＯ規格外ですよね？勉強不足です。）
目的／問題発生時の対策手段／管理資料の提案先の連絡が無く、
一歩的な義務付けは「管理」の概念からすれば明らかにおかしい話です。

それはISOの問題というよりは開発に携わる者の意識の問題でしょう。
そりゃ資料をでっち上げて提出したってISOの審査は通りますよ。でも、そんなことをやっていて痛い目を見るのは自分自身です。

それから、何もISOで定められた手法のみで管理を行えばいいというものでもない。必要に応じて、さまざまな管理を行ったとしてもISOは別に「ダメだ」とは言いませんよ。
ISOの認定さえもらえばすべてうまくいく、などということをISOは謳っていないと思いますが。

引用:

はにまるさんの書き込み (2004-04-05 19:10) より:
また、ＩＳＯにより管理工数が増える結果の費用を資格取得の企業が全て担うのであれば宜しいのですが、
実際にはその費用を発注先に依頼している企業が多いのも実状では無いでしょうか？
受注側の企業もバカではありません。そのツケは別の形で発注側へ廻します。
このサイクルを考慮にいれて無い所が、品質管理という概念の抜け落ちであり、
品質対策の形骸化となる原因の１例と考えます。

「実際にはその費用を発注先に依頼している企業が多いのも実状では無いでしょうか？」というのは、実際どの程度の比率なのでしょうか。その比率が高いことが証明されない限り、「品質対策の形骸化となる原因の１例と考えます」などと結論付けることはできませんよね。

# それにしても「テスト」という単語は出てくるのに「レビュー」という言葉が出てこないのはなぜ・・・？

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-04-06 13:05

はにまるです。
認識差から探った方が良さそうですね。

　１．ISO9000（品質管理マネージメント）を少し調べましたが、記録資料のみならず、
　　　プロセス規定もしている事を認識しました。

　２．品質管理である以上、「管理」自体の基礎レベルが低ければISO9000の効果は
　　　激減すると考えています。

　３．ＩＴ業界で求められる管理レベルは非常に高く、要求に対する実レベルは低い
　　　と考えています。

　４．ＩＴ業界では現場の人間はメインの仕事で手一杯の状態です。

　５．品質を考えて発言をさせていただいていますので手段（ISO9000の摘要手順)に問題があれば、
　　　それを述べさせていただくつもりです。

と言う認識で私は話をしています。

引用:

たーぞうさんの書き込み (2004-04-06 11:23) より:
引用:

はにまるさんの書き込み (2004-04-05 19:10) より:
ＩＳＯですが、私のポジションで見たＩＳＯは、管理資料の作成を義務ずけるだけのモノにしか見えません。
（これはやはりＩＳＯ規格外ですよね？勉強不足です。）
目的／問題発生時の対策手段／管理資料の提案先の連絡が無く、
一歩的な義務付けは「管理」の概念からすれば明らかにおかしい話です。

それはISOの問題というよりは開発に携わる者の意識の問題でしょう。

仰る通りです。ＩＳＯが上手くいかない事を現場に求めている以上「管理」とは程遠い物になっています。

引用:
そりゃ資料をでっち上げて提出したってISOの審査は通りますよ。でも、そんなことをやっていて痛い目を見るのは自分自身です。

仰る通りです。苦労してＩＳＯを摘要しているのに痛い目を見るのは現場の人間です。
踏んだり蹴ったりの状態です。

引用:
それから、何もISOで定められた手法のみで管理を行えばいいというものでもない。必要に応じて、さまざまな管理を行ったとしてもISOは別に「ダメだ」とは言いませんよ。 ISOの認定さえもらえばすべてうまくいく、などということをISOは謳っていないと思いますが。

ＩＳＯが駄目では無く、資格取得の組織がＩＳＯを駄目にしていると考えます。

引用:
「実際にはその費用を発注先に依頼している企業が多いのも実状では無いでしょうか？」というのは、実際どの程度の比率なのでしょうか。その比率が高いことが証明されない限り、「品質対策の形骸化となる原因の１例と考えます」などと結論付けることはできませんよね。

人の行動や思考についての話ですので「証明」と言う行為は、私には困難です。

私は、自分の考えや経験を元に話しをさせて貰っています。
実際に２箇所の派遣先であった話を抽象的にさせて頂いています。
「管理」のレベルが低いのであれば、「品質管理」と同じに「管理」自体も考慮する
必要があると考えます。

私の本音は、
「現在のＩＳＯ９０００は、ロゴの取得が目的になっており品質が目的となっていない状態で、もしロゴが無かったら、大半の企業は取得していないと考えます」
という感じですね。

たーぞうさんの所で上手く言っているのであれば、「この様にしたら上手く」と言うのを
是非お聞かせ頂きたいと思います。

«前のページへ 1|2|3|4 次のページへ»

クオリティーコントロール

スキルアップ／キャリアアップ（JOB@IT）