ミスと寄り添っていく
仕事相手の仕事ってやつをあんたはどうやって見ている?
今の仕事で、相手の仕事ってやつをチェックするようなタイミングがちょいちょい発生する状況になっている。
システム開発の商売って、商売を受注して、協力会社さんに発注をかけて、その発注先の仕事内容のチェックをしながら、最終的な品質を担保するような動きをする。
いわゆる品質管理だよな。
上がってきた障害報告に対して、傾向を確認して、誰がどういう障害を起こしているかを分析する。
今回は、そのへんの品質管理の方法について、改めて振り返って見ようと試みる回だ。
なんか、あれだね。ヒトを疑ってかかるような感じがするかも知れないけれど、ちょっと付き合っておくれよ。
品質分析のやり方
品質分析ってやつは、大枠で2種類の作業をする。
定量分析と定性分析ってやつだ。
もともとは両方とも化学の言葉なんだね。知らんかった。
定量分析
まずは定量分析だな。
システム開発における定量分析ってのは、テスト項目数、障害件数、開発規模、レビュー時間などの数字が指標値と比べてどういう状況にあるかってのを確認する分析だ。
テスト件数ってのは、そのプログラムがきちんと動いていることを確認するための確かめる方法が何種類あるかってこと。
障害件数はそのテストで実際に「ダメ」ってなったのが何件あるか。
開発規模ってのはそのプログラムの行数のこと。
レビューっていうのは、そのプログラムの仕様書が正しいかを作ったヒトとは別のヒトが確認するってことだね。
例えば、5Ksのプログラムがあるとする。
プログラムの行数が5000行あるプログラムってことね。
で、普通プログラムを1Ks作ったら障害ってこんくらいでるよね~とか、1Ksのプログラムに対してのレビュー時間ってこんくらいかけるよね~とかいう指標値ってのがある。
その指標値に対して、実際はどうだったのかってのを比べるのが定量分析ってわけだ。
で、プログラムを作るのはヒトだから、作ったヒト別にその定量分析ってのをやっていく。
そうすると、「田中さんは指標値よりも障害件数が下回っているな」とか「渡辺さんがレビューすると指標値よりも時間がかかっているな」とかが見えてくる。
つまり、定量分析ってのはきちんとやるべきことが出来ているかってことと、結果としてミスを拾いきれているかってチェックってわけだ。
定性分析
お次が定性分析だ。
定量分析が指標値に対して物事を判断するのに対して、定性分析はその中身についての分析となる。
例えば、障害の中身を見ていった時に、単純な誤字脱字が障害内容のときと、仕様を取り違えていたってときでは対処が違うのはなんとなくイメージできるだろ?
例えば田中さんは誤字脱字が多いヒトなら、単純に出来上がったものをチェックするヒトが「ああ、田中さんだから誤字脱字があると思ってチェックしよう」でいいかも知れない。
でも渡辺さんは仕様の取り違えが多いって場合は、渡辺さんに仕様書を読んでもらってから、その仕様をチェックするヒトに一度説明してからプログラムづくりに入ってもらったほうがいいよな。
そういうふうにして、ヒト別に障害の内容の偏りを見つけ出すのが定性分析だ。
品質分析が管理するもの
品質分析ってのはつまるところヒトの特性を把握することだ。
ヒトは必ずミスをする。
そのミスを拾いきれているのかどうかをチェックするために定量分析をして、そのミスへの適正な対処方法を考えるために定性分析をする。
システムを作って、テストの時にバグが0件でしたってのは、定量分析からすると「ちゃんとミスを拾いきれていない」って評価になるし、全体的に誤字脱字が多いってことしか整理出来なかったら、それが誰が引き起こしているのかって定量分析が出来ていないってことになる。
な?ヒトのミスは敵じゃない。
ミスってのは寄り添って行かなければならないものなんだよね。
ミスを見つけたときの態度で「なにやってんの!?」は何も産まない。
ミスを見つけたときは「よし、おんなじようなこと他にもないかチェックしよう」なんだよな。
あんたの周りに「なにやってんの!?」ってやつ居ない?
そういうやつを見つけたら、「ああこのヒトは感情を表に出すってミスをやりがちなヒトなんだ」と定量分析をしてあげよう。
さて、あんたはどう思う?
あんたのことをまずは品質分析してみないか?
この記事が気に入ったらサポートをしてみませんか?