新人さんは知らない「完璧なものを作ると、レビューやテストで苦労する」話

適当なことを書いているので、雰囲気で気持ちよく解釈してください。
新人さんは、無駄な作業だと思わずに、そこにあるもっと大事なものを勉強してください。

指摘密度の基準値

体裁厨 「お♪ ここだけフォント違うくない? それからなんか間隔せまいし。」
用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」
箇条書き過剰 「箇条書きにして。その方が分かりやすいよ。」
物忘れ激しい系 「こここんな仕様だっけ? え、設計書に書いてる? 作成者だれ? オレ? 決めた覚え無いけどなぁ…」



PMO 「指摘密度が基準値に満たないので、その他なんでもいいので指摘ありませんか?」
クソレビューアだらけのレビュー会


引用先は、WEB系のレビューなんですかね?ちょっとわかりません。

それはともかく、
指摘密度が基準値に満たないので、その他なんでもいいので指摘ありませんか?
一番の問題は、ここ!!

ねつ造?しても指摘件数が必要な場合があるケースが、意外と面倒なことになりかねないって話です。

まあ、ねつ造なんてしてはダメなんだけど、どんな理由があっても基準値を満たさないと事実上ダメというところもあるみたいなので・・・。

意味ないレビューはしないところもあります。引用先は、レビューの指摘のほどんとがいらない感じにも見えます。チャックシートを作成して、チェックさせるというのでほとんど消えてしまうので、その程度でできる指摘は、うっかりミスのチェックを除き、レビューですべきものではないとは思います。

レビューでは、原理原則厨の扱いが面倒なので、そういう指摘はさせないという意味でも、チェックリスト方式がよい気はします。

指摘密度が基準値ってなに?

【第3回】PMOの具体的な仕事ってなに? by 関 和美
設計レビュー指標値の算出 Calculation of design review index (PDF)
Quality Index

完璧なものを作ると、レビューやテストで苦労する

一番分かりやすい例だと、不良件数。
テストをして、不良になった件数。

完璧なものを作ってしまうと、不良件数が限りなく0になるので、あとあとちょっと面倒になるって話です。
品質は確保されていることは明らかなんだけど、周りがそう思わないんですなぁ。

プロとして作業したことがない人(新人さん?)は、工程とか手順とかしらないので、初めから完璧なものを作ってくるケースもあるわけなんですが、そういうこともあるよと知っていたらイイかなと思います。

まあ、新人さんの教育で、完璧なものをはじめから作るなって教育はできないので仕方がないですし、完璧なものを作るなというのもおかしな話です。

なぜそういうことが起こるのかというと、後工程で行うべき作業を先にやってしまうので、初めから完璧なものが出来上がるというケースが多いような気がします。まあ例外は、本当に優秀すぎて初めから完璧っていうパターンです。

WEB系とかだと、動かしながら作るとかすると、動作確認してるのと同じなのでそうなりますね。でも動かしながら作るという方法論自体が間違っているわけではありません。

件数のねつ造は、事実を隠ぺいする

個人的には、件数はねつ造しないほうが絶対にいいと思っている主義者なんで、そう思います。
品質管理という点でもねつ造しないほうが、数値から品質を導きやすいとは思います。

あと、ねつ造されると、基準値としての設定が妥当でないという間違いが、延々と訂正されない事態が起こり、永遠と無駄なねつ造作業に励まないといけないという無限地獄に陥ります。

でもって、基準値も品質評価も、最終的には意味のないものとなり下がることが多い気がします。

しかし、ねつ造するプロマネ?のほうが、理不尽なことに仕事で成果をあげてたりするので、なかなか難しい感じはしますけどね。まあ、要領がいいと成果を上げやすいという原理だとは思う。

ただそのタイプのプロマネは、炎上するプロジェクトやデスマ―チなプロジェクトでは、かなり無能なので付き合いには気を付けたほうがよいと思う。品質管理には能力がないので、炎上したものを何とかすることが出来ないって話です。

ねつ造について

■テスト件数が足りない
 追加すればいいんじゃないの?というのはその通りなんだけど、意味のないテストを追加しても数字を合わせているだけ。
 ひどいケースでは、本来は1件の物を2件に分けて書いて数だけ合わせている・・
■不良件数が少ない
 絶対にやってはいけないのは、不良をでっちあげる
 それに似たようなものに
 ・バグ件数達成の為に故意にバクを埋め込むのが暗黙の了解? - QA@IT

 これとかもダメ

数値は誤魔化さないで、解釈逃げがベター

無理に数字を合わせるように言ってくる人たちは、品質確保という部分では優秀でないのは明らかなので、そういう認識でいたほうがよいと思う。できれば、真似しないほうがよい手法。

基準値は満たさないけど、品質確保できているとする理由をつけるという手法のほうをお勧めする。
数値をでっちあげるより、理由をでっちあげるほうが、まだマシだとも思う。

理想は、きちんと品質確保できているかを調べて、問題がないことを確認したうえで、理由をあげるべきかと思う。

・担当者の技術レベルが高いため
・担当部分が単純で不良の作りこみがありえないため

など。

関連記事

「素人まがいのシステム開発」を見分ける方法
コードもまともに書けないエンジニアを雇って、騙されたという人たち
日本語でプログラムを書かされる世界があることを知ってますか?
コードがかける若手SEに依存しないことが目標だから

スポンサーリンク

コメントを残す

メールアドレスは公開されません。
また、コメント欄には、必ず日本語を含めてください(スパム対策)。