アカウント名:
パスワード:
>組織は書類の作成に注力して過剰なプロセスを生み
ソース内のコメントミスを1箇所修正するのに・修正仕様説明資料とその打合せ議事録(1,2次受けに2種類)・第三者込みのソースレビューと議事録(1,2次受けに2種類)・単体/結合/システムテスト仕様と議事録(1,2次受けに2種類)・単体/結合/システムテストの品質報告資料と議事録(バグ0の説明が必要w)・単体/結合/システムレベルでの性能評価資料と議事録(劣化無しの説明が必要w)・単体/システムレベルでのセキュリティ報告資料と議事録・水平展開調査資料とその打合せ議事録(1,2次受けに2種類)・バグ発生原因の追求資料とその打合せ議事録と発表会と発表会の議事録・出荷の申請書とソースマスタ変更依頼・出荷の作業手順書と議事録・顧客説明資料とその打合せ議事録・出荷の客先入館申請書・出荷の結果報告書 とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
ついでに言うと1.コメント変更前後に影響が無い事を証明するために、バイナリのハッシュ比較をする2.ハッシュの衝突で無いことを証明するために複数種のハッシュ関数を使う3.ハッシュ実装のバグで無い事を証明するために、異なるOS(Win/Linux)上でハッシュを取る とか、やらされた時には、コイツら病気か?と思った。 なお、作業結果はA4資料数枚にわたって仔細な手順付き資料を作った上で、1,2,3次受け全員(10人位)を集めて検討を重ねた……。※結果はNG、客にコメントミスを(悪印象になるから)報告できないからだってさ※※という結果なので、顧客に金が貰えず、埋め合わせで作業単価の下方修正を強要される
ハッシュの確認するなら、他の手順は全部すっ飛ばしちゃいたいですね。
つーか、バイナリをそのままコンペアじゃいかんの?
バイナリだと書類で保管し辛いからじゃない?でも、こういうおかしな手順って、たいていお偉いさんが恥をかいた(プレゼン時にエラーでたとか)対応としてやってるから意趣返しも兼ねてるから煩雑な作業が多いよね。
ハッシュを信用しないならバイナリdiffとれば良いのにね。
> ソース内のコメントミスを1箇所修正するのに~~~~~> とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
品質管理のための作業にうんざりしているのは理解します。確かにコメントの修正で、種々の調査の実施とドキュメントの作成を行うのは如何なものかとは思います。しかし、こういう品質管理手法への憎悪が、一切の品質管理手法の否定へ転化してしまうとすれば、それは大問題だと思いますよ。
コメントミスの修正にレビューを行うとの事ですが、ではコメントミスを含むコードが作成された時にレビューは行っていなかったのです
自分がやらないで効果を測定できる方法は無いんじゃないんですが?くりこみの先生の連載だって結局最後の最後まで何一つ使える例を上げてくれなかったし。
自分がやらない=盲目的にあがいている
と言って過言でないと思う。自分がやらないから、それゆえにクソみたいな手順を並べるんです。
> 自分がやらないで効果を測定できる方法は無いんじゃないんですが?
品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。実際、そう測定してましたし。手順の問題点の測定は自分で実施しないとしても、手順を実施している人にヒアリングして分析を行えば良い訳です。PDCAのCを実施、ですね。
品管の問題点は、手順の問題点の解消、つまりPDCAのCを実施しない事ですね。Cをやらないんだから、Aが出来るはずもないんです。#2680391の「合理性と効率性を念頭に置いて」は、そういう問題をなんとかしなければならない事を言っています。
で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。ならば合理的で効率的な品質管理が出来る様に、開発者がクソみたいな手順に苦情を言う(おとなしめの表現ですが)のもアリなら、対案を出すのもアリだと思いますよ。こういう問題は、ゼニの問題に還元して改善を主張するのが効果的ではあります。
話が少々違うのかもしれないが、、
>で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。
それそのものは否定したくはないのですが。
要するに品質管理するための「手順」は定められない(定めきれない)と考える方が正しいと思います。なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
システムの不良原因を除去するため、各工程の不良率を測定します。で、不良が多数発生した部分は正規分布する前提で、不良が多発する部分を除去する手順を策定するわけだ。
でも、システムは生き物で、必ずしも、不良原因が正規分布するわけじゃないような気がする。
最近、「サービス」製品(っても必ずしもソフトウェアだけではない)の、いわゆる「DevOps」っぽい、運用と開発が一体になったようなところにいますが。
そのようなところにいると、各工程の品質が云々、というは意味があると思えないのですな。。不良原因が、ころころ変わりまくるのではないかと思っています。
もちろん、品質は重要ですし、品質向上のために手順を定めるのは悪いことではありませんが実際には、手順を定めきれないのではないのかと疑ってます。
結局「統計データに表れる」というのは思った以上に、現れない部分がある気がします。
今後、ソフトウェア開発は、純粋にソースコードを記述するだけてなく、「サービス」や「IoT」なども「ソフトウェア開発」と呼ばれます。(というか呼ばれてますが)
その場合、いままでと同じような「システム開発」の「統計データ」を当てはめることはできないような気がしています。
なので、「統計データ」を取ると品質管理ができると仮定することは無理があると思っているのですが。
#だからなんもするなとは言わないのですが。。。
> なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
いやいや。
それすらやらないのが皆さん?の論旨でしょ?
> 統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
統計の意味を理解してないと言うか、統計の一部分を以て統計の全ての意味とか考えているんじゃないですか?統計とは、現象を数値で把握する事です。
統計データが正規分布していれば、あるいは正規分布していると仮定すれば、それによって確率とかを計算出来ますが、それは統計の一部分です。ちょっと考えれば分かる事ですよ。日本の都道府県
なんというか、他んトコは置いといて、そのメイトリクス構築において現場と評価者との感覚が離れていて、「なんでこんな意味のない数字を集めて俺らを評価しようとしてるんだ全部無意味だよこんなの」っていう現場の気持ちが表れているせいでもあるんじゃないかなーっと思ったり。
自分の仕事はこれらの数値じゃはかれないトコに価値があるんだよとか、外部要因での変化が激しい部分を直接的に俺の評価値に入れてんじゃねーよとか、数値出しの仕事のせいで本業が圧迫されてる感があったりとか。
顧客が求めるものでも現場が感じているものでもなく、単に「測れるもの」を集めて集計対象にしよう、みたいな状況が無くならない限りそのすれ違いは終わらないかと。
>品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。
有効性がいくら表れたって、すべての手法で有効性がかぎりなく0ならば意味は有りません。有効だと思える手法はどこにあるのでしょうか?そんなこと開発者に聞いたって出てこないですよ。
はい?一体全体、何が仰りたいのでしょう。
> 有効性がいくら表れたって、すべての手法で有効性がかぎりなく0ならば意味は有りません。
有効性が表れたなら、測定が出来る訳ですよね。有効性が表れない場合も、測定が出来る訳です、効果なしと言う測定が。なら、その有効性の測定値とそれに掛かるコストを評価する訳です。もし効果がないとか、効果に見合わないコストが掛かっているなら、それは策定した品質管理手法に問題がある、改善するか別の手法を採用するかは別にしても、何らかのアクションが必要と言う事になるでしょうね。その意味では、「有効性がかぎりなく0」であろうとも、
>開発者から品質活動に対して盛大な否定的意見が出て来るだとすれば、
探しても探しても測度が見つからないとなれば否定する方が大人として正しいです。
恐怖で人を縛るには限度が有ります。早々に結果をださなければ、舵を取り上げられて当然です。
探しても探しても測度が見つからないとなれば否定する方が大人として正しいです。恐怖で人を縛るには限度が有ります。早々に結果をださなければ、舵を取り上げられて当然です。
大人と言うより子供、単なる駄々っ子に見えるが。
何が恐怖?組織的な恐怖?それはイイカゲンにやってたのが出来なくなるから困るって事でしょ?コード変更の恐怖?イイカゲンにやって来た事のツケそのものでしょ。内部品質を一切考えないから、こういう事が起こる。失業の恐怖?これだって組織こぞってのイイカゲンのツケでしょ。イイカゲンな事をやってきたし、これからもイイカゲン
「挑戦する部下」と「逃げ出す部下」 [nikkeibp.co.jp]
逃げ出すヤツばっか、なのか?
>大人と言うより子供、単なる駄々っ子に見えるが。
んー、なんか違和感がありますかね。。
品質で重要なのは、「不良を出すな」と命令することではなく、不良を出さないように皆で協力する、ですよね?ちがうのかしら。
「不良の原因なんかわかんないよ」というのは駄々っ子ではなく、現場の実感なのでは。がちがちの手順で縛るのは、「不良を出すな」と命令されているようで、重要なところを外しているような気がします。
Pは糞みたいな手順、Dは他人が実施、CもAも実施しない糞コレクターに糞を提供する時間をほかの作業に回したいって事なんじゃないですかね?
> Pは糞みたいな手順、Dは他人が実施、CもAも実施しない糞コレクターに> 糞を提供する時間をほかの作業に回したいって事なんじゃないですかね?
開発者とすればその通りでしょうが、それではイカンと言っている訳です。品管にちゃんと仕事をして貰いましょうよ。開発者としても、唯々諾々だけど裏で盛大にグダグダ言うとか、単に反発するとかをやっていれば、品管はどんどん暴走するだけですよ。言う事は面と向かってしっかり言った方が良いんです。
実際問題として言えないというのが多くなってるんじゃないかと思うんだよね。開発の外注はよく聞くけど、品質管理を外に出すって聞かないよね?別部署に対しての話って自社でも面倒なのに他社(発注者)に対してできるくらいならそこには居ないと思うんだよね。
品質管理手法の中に、人の健康状態や凡ミスを見逃す忙しさを考慮したものがあるのか?飛行機のパイロットのように、十分な睡眠時間など、ミスの無いレビューができる状態を保証する項目でもあれば別だけど。
もしあったとしても、それを十分に守れる品質管理手順を作れば、採用できる会社はこの世に1社もない。だから、品質管理手法は机上の空論のままなんだよ。
トヨタ式に代表される工場の品管では当然、作業員の健康状態も取り入れているけど。そもそも労災要因だから体調不良者をラインに入れないのは上長の責任で当然実施されている。
そういう意味では、製造業に比べてソフトウェア産業の品管の後進性があらわれているといえるかもしれない。
とは言っても、機材屋やっていると製造業でも中堅以下では、製造機器導入時に求められる定番の要求が、「安全装置は外してくれ」なんで、実際は製造業も大差ないかもっと悪いと思う。油圧機器を扱う職場じゃ、指の1本位無い人間はザラだしね。ソフトウェア産業でもトヨタの位置に有るような企業では、その辺りはマシだろう。
doyxgen使えないじゃんと読みながら、「2.ハッシュの衝突で無いことを証明するために複数種のハッシュ関数を使う」で吹いた。バッシュ関数の衝突より、ほかに疑うべきものがありそうだが。
「ハッシュ?ふつうの開発者はそんなの知らん」というので使うなというのはあったよ。使うだけましなのかも?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
あるある過ぎる (スコア:5, 興味深い)
>組織は書類の作成に注力して過剰なプロセスを生み
ソース内のコメントミスを1箇所修正するのに
・修正仕様説明資料とその打合せ議事録(1,2次受けに2種類)
・第三者込みのソースレビューと議事録(1,2次受けに2種類)
・単体/結合/システムテスト仕様と議事録(1,2次受けに2種類)
・単体/結合/システムテストの品質報告資料と議事録(バグ0の説明が必要w)
・単体/結合/システムレベルでの性能評価資料と議事録(劣化無しの説明が必要w)
・単体/システムレベルでのセキュリティ報告資料と議事録
・水平展開調査資料とその打合せ議事録(1,2次受けに2種類)
・バグ発生原因の追求資料とその打合せ議事録と発表会と発表会の議事録
・出荷の申請書とソースマスタ変更依頼
・出荷の作業手順書と議事録
・顧客説明資料とその打合せ議事録
・出荷の客先入館申請書
・出荷の結果報告書
とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
ついでに言うと
1.コメント変更前後に影響が無い事を証明するために、バイナリのハッシュ比較をする
2.ハッシュの衝突で無いことを証明するために複数種のハッシュ関数を使う
3.ハッシュ実装のバグで無い事を証明するために、異なるOS(Win/Linux)上でハッシュを取る
とか、やらされた時には、コイツら病気か?と思った。
なお、作業結果はA4資料数枚にわたって仔細な手順付き資料を作った上で、1,2,3次受け全員(10人位)を集めて検討を重ねた……。
※結果はNG、客にコメントミスを(悪印象になるから)報告できないからだってさ
※※という結果なので、顧客に金が貰えず、埋め合わせで作業単価の下方修正を強要される
Re: (スコア:0)
ハッシュの確認するなら、他の手順は全部すっ飛ばしちゃいたいですね。
Re: (スコア:0)
つーか、バイナリをそのままコンペアじゃいかんの?
Re: (スコア:0)
バイナリだと書類で保管し辛いからじゃない?
でも、こういうおかしな手順って、たいていお偉いさんが恥をかいた(プレゼン時にエラーでたとか)対応として
やってるから意趣返しも兼ねてるから煩雑な作業が多いよね。
Re: (スコア:0)
ハッシュを信用しないならバイナリdiffとれば良いのにね。
Re: (スコア:0)
> ソース内のコメントミスを1箇所修正するのに
~~~~~
> とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
品質管理のための作業にうんざりしているのは理解します。確かにコメントの修正で、種々の調査の実施とドキュメントの作成を行うのは如何なものかとは思います。しかし、こういう品質管理手法への憎悪が、一切の品質管理手法の否定へ転化してしまうとすれば、それは大問題だと思いますよ。
コメントミスの修正にレビューを行うとの事ですが、ではコメントミスを含むコードが作成された時にレビューは行っていなかったのです
Re: (スコア:0)
自分がやらないで効果を測定できる方法は無いんじゃないんですが?
くりこみの先生の連載だって結局最後の最後まで何一つ使える例を
上げてくれなかったし。
自分がやらない=盲目的にあがいている
と言って過言でないと思う。
自分がやらないから、それゆえにクソみたいな手順を並べるんです。
Re: (スコア:0)
> 自分がやらないで効果を測定できる方法は無いんじゃないんですが?
品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。実際、そう測定してましたし。手順の問題点の測定は自分で実施しないとしても、手順を実施している人にヒアリングして分析を行えば良い訳です。PDCAのCを実施、ですね。
品管の問題点は、手順の問題点の解消、つまりPDCAのCを実施しない事ですね。Cをやらないんだから、Aが出来るはずもないんです。#2680391の「合理性と効率性を念頭に置いて」は、そういう問題をなんとかしなければならない事を言っています。
で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。ならば合理的で効率的な品質管理が出来る様に、開発者がクソみたいな手順に苦情を言う(おとなしめの表現ですが)のもアリなら、対案を出すのもアリだと思いますよ。こういう問題は、ゼニの問題に還元して改善を主張するのが効果的ではあります。
Re:あるある過ぎる (スコア:1)
話が少々違うのかもしれないが、、
>で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。
それそのものは否定したくはないのですが。
要するに品質管理するための「手順」は定められない(定めきれない)と考える方が正しいと思います。
なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
システムの不良原因を除去するため、各工程の不良率を測定します。
で、不良が多数発生した部分は正規分布する前提で、不良が多発する部分を除去する手順を策定するわけだ。
でも、システムは生き物で、必ずしも、不良原因が正規分布するわけじゃないような気がする。
最近、「サービス」製品(っても必ずしもソフトウェアだけではない)の、
いわゆる「DevOps」っぽい、運用と開発が一体になったようなところにいますが。
そのようなところにいると、各工程の品質が云々、というは意味があると思えないのですな。。
不良原因が、ころころ変わりまくるのではないかと思っています。
もちろん、品質は重要ですし、品質向上のために手順を定めるのは悪いことではありませんが
実際には、手順を定めきれないのではないのかと疑ってます。
結局「統計データに表れる」というのは思った以上に、現れない部分がある気がします。
今後、ソフトウェア開発は、純粋にソースコードを記述するだけてなく、
「サービス」や「IoT」なども「ソフトウェア開発」と呼ばれます。(というか呼ばれてますが)
その場合、いままでと同じような「システム開発」の「統計データ」を当てはめることはできないような気がしています。
なので、「統計データ」を取ると品質管理ができると仮定することは無理があると思っているのですが。
#だからなんもするなとは言わないのですが。。。
Re: (スコア:0)
> なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
いやいや。
それすらやらないのが皆さん?の論旨でしょ?
> 統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
いやいや。
統計の意味を理解してないと言うか、統計の一部分を以て統計の全ての意味とか考えているんじゃないですか?統計とは、現象を数値で把握する事です。
統計データが正規分布していれば、あるいは正規分布していると仮定すれば、それによって確率とかを計算出来ますが、それは統計の一部分です。ちょっと考えれば分かる事ですよ。日本の都道府県
Re: (スコア:0)
なんというか、他んトコは置いといて、
そのメイトリクス構築において現場と評価者との感覚が離れていて、
「なんでこんな意味のない数字を集めて俺らを評価しようとしてるんだ全部無意味だよこんなの」っていう現場の気持ちが表れているせいでもあるんじゃないかなーっと思ったり。
自分の仕事はこれらの数値じゃはかれないトコに価値があるんだよとか、
外部要因での変化が激しい部分を直接的に俺の評価値に入れてんじゃねーよとか、
数値出しの仕事のせいで本業が圧迫されてる感があったりとか。
顧客が求めるものでも現場が感じているものでもなく、単に「測れるもの」を集めて集計対象にしよう、みたいな状況が無くならない限りそのすれ違いは終わらないかと。
Re: (スコア:0)
>品管が策定した手順、その有効性は発生事象や統計データとして表れて来ると思いますよ。
有効性がいくら表れたって、すべての手法で有効性がかぎりなく0ならば意味は有りません。
有効だと思える手法はどこにあるのでしょうか?そんなこと開発者に聞いたって出てこない
ですよ。
Re: (スコア:0)
はい?一体全体、何が仰りたいのでしょう。
> 有効性がいくら表れたって、すべての手法で有効性がかぎりなく0ならば意味は有りません。
有効性が表れたなら、測定が出来る訳ですよね。有効性が表れない場合も、測定が出来る訳です、効果なしと言う測定が。なら、その有効性の測定値とそれに掛かるコストを評価する訳です。もし効果がないとか、効果に見合わないコストが掛かっているなら、それは策定した品質管理手法に問題がある、改善するか別の手法を採用するかは別にしても、何らかのアクションが必要と言う事になるでしょうね。その意味では、「有効性がかぎりなく0」であろうとも、
Re: (スコア:0)
>開発者から品質活動に対して盛大な否定的意見が出て来るだとすれば、
探しても探しても測度が見つからないとなれば否定する方が大人として正しいです。
恐怖で人を縛るには限度が有ります。早々に結果をださなければ、舵を取り上げられて
当然です。
Re: (スコア:0)
探しても探しても測度が見つからないとなれば否定する方が大人として正しいです。
恐怖で人を縛るには限度が有ります。早々に結果をださなければ、舵を取り上げられて
当然です。
大人と言うより子供、単なる駄々っ子に見えるが。
何が恐怖?組織的な恐怖?それはイイカゲンにやってたのが出来なくなるから困るって事でしょ?コード変更の恐怖?イイカゲンにやって来た事のツケそのものでしょ。内部品質を一切考えないから、こういう事が起こる。失業の恐怖?これだって組織こぞってのイイカゲンのツケでしょ。
イイカゲンな事をやってきたし、これからもイイカゲン
Re: (スコア:0)
「挑戦する部下」と「逃げ出す部下」 [nikkeibp.co.jp]
逃げ出すヤツばっか、なのか?
Re:あるある過ぎる (スコア:1)
>大人と言うより子供、単なる駄々っ子に見えるが。
んー、なんか違和感がありますかね。。
品質で重要なのは、「不良を出すな」と命令することではなく、不良を出さないように皆で協力する、ですよね?
ちがうのかしら。
「不良の原因なんかわかんないよ」というのは駄々っ子ではなく、現場の実感なのでは。
がちがちの手順で縛るのは、「不良を出すな」と命令されているようで、重要なところを外しているような気がします。
Re: (スコア:0)
Pは糞みたいな手順、Dは他人が実施、CもAも実施しない糞コレクターに
糞を提供する時間をほかの作業に回したいって事なんじゃないですかね?
Re: (スコア:0)
> Pは糞みたいな手順、Dは他人が実施、CもAも実施しない糞コレクターに
> 糞を提供する時間をほかの作業に回したいって事なんじゃないですかね?
開発者とすればその通りでしょうが、それではイカンと言っている訳です。品管にちゃんと仕事をして貰いましょうよ。開発者としても、唯々諾々だけど裏で盛大にグダグダ言うとか、単に反発するとかをやっていれば、品管はどんどん暴走するだけですよ。言う事は面と向かってしっかり言った方が良いんです。
Re: (スコア:0)
実際問題として言えないというのが多くなってるんじゃないかと思うんだよね。
開発の外注はよく聞くけど、品質管理を外に出すって聞かないよね?
別部署に対しての話って自社でも面倒なのに他社(発注者)に対してできるくらいなら
そこには居ないと思うんだよね。
Re: (スコア:0)
品質管理手法の中に、人の健康状態や凡ミスを見逃す忙しさを考慮したものがあるのか?
飛行機のパイロットのように、十分な睡眠時間など、ミスの無いレビューができる状態を
保証する項目でもあれば別だけど。
もしあったとしても、それを十分に守れる品質管理手順を作れば、採用できる会社はこの世に1社もない。
だから、品質管理手法は机上の空論のままなんだよ。
Re: (スコア:0)
トヨタ式に代表される工場の品管では当然、作業員の健康状態も取り入れているけど。そもそも労災要因だから体調不良者をラインに入れないのは上長の責任で当然実施されている。
そういう意味では、製造業に比べてソフトウェア産業の品管の後進性があらわれているといえるかもしれない。
Re: (スコア:0)
とは言っても、機材屋やっていると製造業でも中堅以下では、製造機器導入時に求められる定番の要求が、
「安全装置は外してくれ」
なんで、実際は製造業も大差ないかもっと悪いと思う。
油圧機器を扱う職場じゃ、指の1本位無い人間はザラだしね。
ソフトウェア産業でもトヨタの位置に有るような企業では、その辺りはマシだろう。
Re: (スコア:0)
doyxgen使えないじゃんと読みながら、
「2.ハッシュの衝突で無いことを証明するために複数種のハッシュ関数を使う」で吹いた。
バッシュ関数の衝突より、ほかに疑うべきものがありそうだが。
Re: (スコア:0)
「ハッシュ?ふつうの開発者はそんなの知らん」というので使うなというのはあったよ。
使うだけましなのかも?