それ、力技の品質合わせであって品質管理じゃないんじゃないのかな
たくさんのRTやいいねいただきましてありがとうございます。
初めてのことなのでびっくりしています。
内定式に出られた学生さんにこっそり教えると、ガンダムファーストを生放送で見ていた中高生は今、部長や役員クラスになっている年齢です。
— ふみさん (@finayama) 2016年10月5日
迂闊にdisると余計な敵を作ります。
「なんで僕だけ配属が地方なんですか」
「坊やだからさ」
がリアルでおきます。
コメントいただいている件については、 s/ガンダムファースト/ファーストガンダム/ や s/生放送/リアルタイム方法/ と脳内変換していただければ幸いです。
こんなにツイートがRTされるなら、もう少しブログのいいねが伸びると…。
それ品質管理なの
計測範囲の中になるのである意味伝聞やレポートに基づく情報が混在しているますが、いわゆるシステム開発プロジェクトのテスト工程に入った途端にテスト消化が計画どおりにいかないとか、バグの発生件数に対して対処件数が追いつかないとかでXグラフの計画と実績の乖離から「テスト要員を追加するんだ」なんてやっているのを見かけると、「いつの時代の品質室管理しているんだ」と思うわけです。
何に対して思うことがあるかというと、作ってから設計仕様を満たしていないから直すというやり方自体です。それは品質管理とは言わない、とワタシは思うわけです。そんなのを品質管理と呼ぶなら、品質管理の管理はどこに行ってしまったのか小１時間くらいこんこんと問い詰めたい。
管理と名前のつく以上、制御が含まれていなければならいと思うのです。制御とはコントロールですよ。コントロール。テスト工程で「テストでバグがでたら直すからいいじゃん」というなら、どのくらいバグが出る予定か教えて欲しいものです。そうでないとテスト工程でかかる費用が計画できませんから。やってみたらバグが多くて人を追加してください、なんていってきたら、今までの工程で何やってきたんだよ、と言いたいですよ。
品質管理の計画とは
品質管理は、要求を満たすようにアウトプットの特性をコントロールする活動です。テストをしてみたら要求を満たしていないから直すような考えではないのです。アウトプットに対する要求を満たすように局面ごとのパーツとしてのアウトプットをコントロールしていく活動なのです。
そうすると、どう考えるかというと、局面ごとの作業標準のプロセスの中で品質をコントロールするアクティビティを組み込まないといけない、ということです。設計書であれば、レビューがそれにあたります。
実際は、どのプロジェクトでもレビューはやっているのにテスト工程でバグが出ているのが実情です。品質管理としてアウトプットの品質特性をコントロールするためには、品質をどうコントロールしたいか観点が必要になります。それが意識的にやられていないからバグが混入するわけです。
さらに言えば、テスト工程のテスト仕様もコードに合わせて作成しているからテストケースが成功するのであって、それではコードをなぞっているだけだから、想定外の入力や組み合わせが起きると思いもしないバグが発生するわけです。
本来は、V字モデルやW字モデルにあるように、設計仕様どおりに実装されているか、設計仕様以外は実装されていないかをテスト仕様の方法を駆使して仕様をつくらないといけないのです。それもテストの観点がなければみんな勝手に動いていることを確認するテスト仕様を作ります。
それは品質管理とは言わないです。
DevOpsやテスト自動化をいくら最新の技術を導入して実践しても、肝心の品質をコントロールすることをプロセスの中に組み込まないと本来、品質管理でやりたいことは全く実行されません。さらにいえば、DevOpsQAなんて別世界の話です。
作っちゃてから考えるのではなく、作る前に品質をコントロールすることをプロセスとして織り込まないともぐらたたきから抜けられません。
ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)
posted with amazlet at 16.10.06
