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