アカウント名:
パスワード:
>組織は書類の作成に注力して過剰なプロセスを生み
ソース内のコメントミスを1箇所修正するのに・修正仕様説明資料とその打合せ議事録(1,2次受けに2種類)・第三者込みのソースレビューと議事録(1,2次受けに2種類)・単体/結合/システムテスト仕様と議事録(1,2次受けに2種類)・単体/結合/システムテストの品質報告資料と議事録(バグ0の説明が必要w)・単体/結合/システムレベルでの性能評価資料と議事録(劣化無しの説明が必要w)・単体/システムレベルでのセキュリティ報告資料と議事録・水平展開調査資料とその打合せ議事録(1,2次受けに2種類)・バグ発生原因の追求資料とその打合せ議事録と発表会
> ソース内のコメントミスを1箇所修正するのに~~~~~> とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
品質管理のための作業にうんざりしているのは理解します。確かにコメントの修正で、種々の調査の実施とドキュメントの作成を行うのは如何なものかとは思います。しかし、こういう品質管理手法への憎悪が、一切の品質管理手法の否定へ転化してしまうとすれば、それは大問題だと思いますよ。
コメントミスの修正にレビューを行うとの事ですが、ではコメントミスを含むコードが作成された時にレビューは行っていなかったのです
自分がやらないで効果を測定できる方法は無いんじゃないんですが?くりこみの先生の連載だって結局最後の最後まで何一つ使える例を上げてくれなかったし。
自分がやらない=盲目的にあがいている
と言って過言でないと思う。自分がやらないから、それゆえにクソみたいな手順を並べるんです。
> 自分がやらないで効果を測定できる方法は無いんじゃないんですが?
品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。実際、そう測定してましたし。手順の問題点の測定は自分で実施しないとしても、手順を実施している人にヒアリングして分析を行えば良い訳です。PDCAのCを実施、ですね。
品管の問題点は、手順の問題点の解消、つまりPDCAのCを実施しない事ですね。Cをやらないんだから、Aが出来るはずもないんです。#2680391の「合理性と効率性を念頭に置いて」は、そういう問題をなんとかしなければならない事を言っています。
で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。ならば合理的で効率的な品質管理が出来る様に、開発者がクソみたいな手順に苦情を言う(おとなしめの表現ですが)のもアリなら、対案を出すのもアリだと思いますよ。こういう問題は、ゼニの問題に還元して改善を主張するのが効果的ではあります。
話が少々違うのかもしれないが、、
>で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。
それそのものは否定したくはないのですが。
要するに品質管理するための「手順」は定められない(定めきれない)と考える方が正しいと思います。なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
システムの不良原因を除去するため、各工程の不良率を測定します。で、不良が多数発生した部分
> なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
いやいや。
それすらやらないのが皆さん?の論旨でしょ?
> 統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
統計の意味を理解してないと言うか、統計の一部分を以て統計の全ての意味とか考えているんじゃないですか?統計とは、現象を数値で把握する事です。
統計データが正規分布していれば、あるいは正規分布していると仮定すれば、それによって確率とかを計算出来ますが、それは統計の一部分です。ちょっと考えれば分かる事ですよ。日本の都道府県
なんというか、他んトコは置いといて、そのメイトリクス構築において現場と評価者との感覚が離れていて、「なんでこんな意味のない数字を集めて俺らを評価しようとしてるんだ全部無意味だよこんなの」っていう現場の気持ちが表れているせいでもあるんじゃないかなーっと思ったり。
自分の仕事はこれらの数値じゃはかれないトコに価値があるんだよとか、外部要因での変化が激しい部分を直接的に俺の評価値に入れてんじゃねーよとか、数値出しの仕事のせいで本業が圧迫されてる感があったりとか。
顧客が求めるものでも現場が感じているものでもなく、単に「測れるもの」を集めて集計対象にしよう、みたいな状況が無くならない限りそのすれ違いは終わらないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
あるある過ぎる (スコア:5, 興味深い)
>組織は書類の作成に注力して過剰なプロセスを生み
ソース内のコメントミスを1箇所修正するのに
・修正仕様説明資料とその打合せ議事録(1,2次受けに2種類)
・第三者込みのソースレビューと議事録(1,2次受けに2種類)
・単体/結合/システムテスト仕様と議事録(1,2次受けに2種類)
・単体/結合/システムテストの品質報告資料と議事録(バグ0の説明が必要w)
・単体/結合/システムレベルでの性能評価資料と議事録(劣化無しの説明が必要w)
・単体/システムレベルでのセキュリティ報告資料と議事録
・水平展開調査資料とその打合せ議事録(1,2次受けに2種類)
・バグ発生原因の追求資料とその打合せ議事録と発表会
Re: (スコア:0)
> ソース内のコメントミスを1箇所修正するのに
~~~~~
> とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
品質管理のための作業にうんざりしているのは理解します。確かにコメントの修正で、種々の調査の実施とドキュメントの作成を行うのは如何なものかとは思います。しかし、こういう品質管理手法への憎悪が、一切の品質管理手法の否定へ転化してしまうとすれば、それは大問題だと思いますよ。
コメントミスの修正にレビューを行うとの事ですが、ではコメントミスを含むコードが作成された時にレビューは行っていなかったのです
Re: (スコア:0)
自分がやらないで効果を測定できる方法は無いんじゃないんですが?
くりこみの先生の連載だって結局最後の最後まで何一つ使える例を
上げてくれなかったし。
自分がやらない=盲目的にあがいている
と言って過言でないと思う。
自分がやらないから、それゆえにクソみたいな手順を並べるんです。
Re: (スコア:0)
> 自分がやらないで効果を測定できる方法は無いんじゃないんですが?
品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。実際、そう測定してましたし。手順の問題点の測定は自分で実施しないとしても、手順を実施している人にヒアリングして分析を行えば良い訳です。PDCAのCを実施、ですね。
品管の問題点は、手順の問題点の解消、つまりPDCAのCを実施しない事ですね。Cをやらないんだから、Aが出来るはずもないんです。#2680391の「合理性と効率性を念頭に置いて」は、そういう問題をなんとかしなければならない事を言っています。
で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。ならば合理的で効率的な品質管理が出来る様に、開発者がクソみたいな手順に苦情を言う(おとなしめの表現ですが)のもアリなら、対案を出すのもアリだと思いますよ。こういう問題は、ゼニの問題に還元して改善を主張するのが効果的ではあります。
Re: (スコア:1)
話が少々違うのかもしれないが、、
>で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。
それそのものは否定したくはないのですが。
要するに品質管理するための「手順」は定められない(定めきれない)と考える方が正しいと思います。
なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
システムの不良原因を除去するため、各工程の不良率を測定します。
で、不良が多数発生した部分
Re: (スコア:0)
> なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
いやいや。
それすらやらないのが皆さん?の論旨でしょ?
> 統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
いやいや。
統計の意味を理解してないと言うか、統計の一部分を以て統計の全ての意味とか考えているんじゃないですか?統計とは、現象を数値で把握する事です。
統計データが正規分布していれば、あるいは正規分布していると仮定すれば、それによって確率とかを計算出来ますが、それは統計の一部分です。ちょっと考えれば分かる事ですよ。日本の都道府県
Re:あるある過ぎる (スコア:0)
なんというか、他んトコは置いといて、
そのメイトリクス構築において現場と評価者との感覚が離れていて、
「なんでこんな意味のない数字を集めて俺らを評価しようとしてるんだ全部無意味だよこんなの」っていう現場の気持ちが表れているせいでもあるんじゃないかなーっと思ったり。
自分の仕事はこれらの数値じゃはかれないトコに価値があるんだよとか、
外部要因での変化が激しい部分を直接的に俺の評価値に入れてんじゃねーよとか、
数値出しの仕事のせいで本業が圧迫されてる感があったりとか。
顧客が求めるものでも現場が感じているものでもなく、単に「測れるもの」を集めて集計対象にしよう、みたいな状況が無くならない限りそのすれ違いは終わらないかと。