アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
テストとコスト (スコア:1)
工数とは、そのまんま「人件費」です。
人件費は減らしたい、というのが客先の第一の要望です。
人件費は減らしたい、というのが開発会社の第一の要望です。
よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の１つになります。
つまり、ご質問へのお答え
Re:テストとコスト (スコア:1, すばらしい洞察)
なんて考えを持っている発注側はもちろん、受注側にも大きな問題があるのでしょうねぇ。
本来外すことの出来ない工程を外すことを許容してるんだから。
なんなら、開発工程もさくっと削減してもらえませんか？
Re:テストとコスト (スコア:3, 興味深い)
「お金は払うから*ちゃんと*テストしてくれ」
ってのが偽らざる本音。 いや、正確に言うと
「何テストしたんだか教えれ」
って事でしょうか。
どぉぉぉぉ考えてもテストしてたら出ないだろそんなバグ、という「不具合」をポロポロと発見するにつけ、「やっぱ単体レベルのテスト仕様書も見せて欲しいなァ」と思う今日この
Re:テストとコスト (スコア:2, おもしろおかしい)
>単体レベルのテスト仕様書も見せて欲しい
こういうお客さんに巡り会いたい(T_T)
＃会えてないのでG7
結局、「小難しい。なにいってんだか判らん。
そんなもんはいちいち見せるんじゃねえよ」なんていうお客は
自分の首を締めてるんだよね。
てか、確実に理解できる保証なんてものは無視して、
とりあえず「多め」に情報を納めさせるほうが、
絶対に有利であるはずだ。お客にとって。
だって理解できなくて「困ったら」、誰か理解できる人を掴まえて読ませりゃいいだけなんだもん。
でも情報そのものを納めさせていなけりゃ、永遠に読めない。
幸いにして現在は、多めの文書を仕舞っておく場所には(電子データなら)苦労しないんだしさ。
ただ、
>if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると
それは、アーキテクチャ(の不味さ)次第では、なんぼでもありえることです(T_T)
逆にいえば、作りかけの時点でも観察することは、
お客にとっても利益(つーか損害を無くす)のために重要だと思う。
「技術的負債」を抱えまくった開発を受注者がやってんじゃねーの？ってのを
建築^H^H開発途中にも頻繁に査察したほうが良い、と俺は思うっす。
＃無理の有る査察のしかただと困るけど、ね。
あ。そういう意味でも、XPは旨いよな。
Projectはお客に、常時査察されてるようなもんだもん。
>どの程度開示しているんでしょうか
ウチの社長が何考えてるかはともかく、開発者たる個人としての俺は(^^;、
相手が吐き気催すまで出すのもヤブサカじゃないですよ。
ほら。ここでのカキコみたいにさ(藁
＃最近、ソースごと納入な仕事ばっかりしてる気がするんだが、
＃お客がそのソースだのなんだのといった情報を有効活用してるのを、見た験しがないのでG7
Re:テストとコスト (スコア:0)
報告書は書かなくちゃいけないけど
小難しいといわれる
分かりやすい報告書を書こうと思うと
筆力が足りない。。。
自分の力が足りないのかと一人鬱。
Re:テストとコスト (スコア:1)
「調査した結果、何々となる事が判りました。」
で、その何を調査したかは説明してない。結果だけ。
良くわかってない上司とかはそれを分かり易いとか言って鵜呑みにしてしまうけど、
それではミスや調査不足があっても判らないし、その後それに基づいて改良しようとしても
何を調べて、何を試してないのか判らないから、同じ事をやる羽目になるという事が判っているのか...。
Re:テストとコスト (スコア:1)
あ。それ有る有る。
判りやすくするためには2つの方法が有って、1つは文字通り判りやすく「する」こと、
そしてもう1つは、判りにくい(説明がしんどい)部分を削るだけっていう奴(笑)。
で、元々「判りやすい」ってのは相対評価だから、ヤバイんですよね。
なんぼ下手くそな削り方をしてしまった(=情報量スカスカなドキュメントにしてしまった)としても、
「情報量スカスカである」ことを知るための情報自体が無くなっている(笑)ので、
そのドキュメントの不味さは、読み手に伝わらないんです。
それと比べると、見た目が「判りやすくない」かどうかは、読めばすぐ判るんで、
そこを「評価」するのは簡単なんだよね。
まあ、だからこそ、ああいう人々は見た目の判りやすさばかりを評価するんだろうな。
情報が足りないかどうかは評価のしようがないわけだ(^^;
>同じ事をやる羽目になるという事
「後で役立てる」という発想をそもそも採用していないのではないかと。
積読するためだけに作らせてる、と。
「効果的にバグを報告するには」 [unixuser.org]みたいな境地は、遠いです…しくしく。
まあ、肝心の納入ソフトすら積読する企業は珍しくないようなのでね。
＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
＃バグレポが2年(!)後に来たから何かと思えば、初めて評価したのが先週だったというオチ…などなど。
＃＃AprilFoolじゃないのでG7(T_T)
で、結果的にソフトにとって「どんな情報をどう伝えれば」役立つのか？っていうパターンって、
それなりに有るわけじゃないですか。
だけど、そういうのは門外漢(だよな)なお客とかにはしばしば「小難しく」映るらしい。
で、そういう真に有意義なパターンを正に「禁じ手」扱いしてくれちゃったりするのな。
つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
わざわざ作ってくださる。
Re:テストとコスト (スコア:1)
>そのドキュメントの不味さは、読み手に伝わらないんです。
私は結論からその根拠を文章中に探したときに何も説明していないことに気がつきました。
書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。
>＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
ほんとにデバックしたしたかと思うほどバグバグな物を納期に納めてくれたりして
それを受て開発する予定がずるずると延びて、納期ってなんなのて思った事もありました。
>つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
>わざわざ作ってくださる。
どう仕様書を書けばその様になるのは解りませんが、
文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。
Re:テストとコスト (スコア:1)
>書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。
あはは。なるほど。
そういう…これも一種の「論理的思考」っていうのかな…考え方を、
理解する人間と、しない人間が、居ますよね世の中には。
＃論理思考の苦手な人間は、少なくともソフト受注者や「発注者」には成らないほうが良いと思うのでG7
＃受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に説明できないようじゃ駄目です(コッチが対応しようが無いので)。
>>＃じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
>仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
状況によりけりなんでしょうけど、
「真のエンドユーザ」からの声が来ない状況ってのに出くわして、困ったことは有ります。
客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」してたんですが、
ここで情報の欠落(伝言ゲーム)や遅滞が起きるんですね。
おかげで、ユーザが実際に困っている事柄が、正確かつ迅速に、伝わってこない…
>>つまり、無意味なドキュメントや無意味なバグレポ「しか書けない／受け取れない」という状況を
>>わざわざ作ってくださる。
>どう仕様書を書けばその様になるのは解りませんが、
フォーマットの問題です。
「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
＃そうすれば「正確に」伝わる、と先方は思ってらっしゃるらしい。
ところが、そのフォーマットには、実用上困ってしまうような過不足が色々有って。
「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っていう事態が頻発しまして。
そういう場合、そのフォーマットに従えば従うほど、情報は欠落するわけです。
結局、備考欄しか役に立たなかったりする。それなら最初から備考欄(フリーフォーマット)だけでいいじゃん…
>文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
>最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
>人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。
あー。「相手が知りたいこと」と、こちらが用意する「結論」とは、一緒じゃない可能性が結構あるんですよね。
結論も、こちらが用意する限り、あくまで「知らせたいこと」の範疇でしかないのです。
結局、アジャイルが最強なんじゃないか？という気がしています。
つまり、フォーマットはあまり気にせずラフに書き始めて、
その代わり要求を随時フィードバックしてバンバン改訂してく、という奴ね。
＃ただし、「フォーマットをきちんとしてくれ！」という要求は、聞かないほうが良さそうですが:-)
言い換えると、「まず結論を書いて…」みたいな、結局は書き手側の発想でしかない方法論は、
古典的な書籍みたいに改訂をやりにくい環境に「特化」した方法論なんじゃないか？と思っています。
改訂できないという制約のもとで最高なものにしようとしたら、
仕方ないから自分が言いたいこと(の核心)を最初に相手にぶつけるというスタイルしか無い、という。
で、仕様の打ち合わせみたいなものってのは、
もともとそんな制約とは無縁であるはずです。
製品の仕様を向上させるのが目的であって、
前述の制約を守ることが目的ではないから、です(笑)。
つまり便利な媒体は随時選べばいいし、
まして現代なら電子媒体が情報の改訂し易さを大幅に援助してくれる。
つまり、「たまにしか会えない」ことを前提にしちゃ、
駄目なんだと思うんです。
Re:テストとコスト (スコア:1)
>理解する人間と、しない人間が、居ますよね世の中には。
特に作業報告書などはやった事とそこから得られる結論を書けばいいのに、
何故か、やった事を書こうとしないのですよね。
「調査した結果」とか適当な言葉でお茶を濁しているのですよね。
理数科系の職業のハズなのに～とか思ってしまうのですよ。
>＃受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に
>説明できないようじゃ駄目です(コッチが対応しようが無いので)。
それは耳が痛いなと思いつつ。
私も顧客から受注して、その一部を外注に投げている身なので、
発注者／受注者、両方の立場なのですが、
「曖昧な仕様を確認、明確化させるのも仕事の内」なのではないかと。
私の場合、殆ど仕様書なし。お客から聞出してこっちが書くものと成っているの
で。
仕様書が出てくるだけましかと。もっと色々仕様を書いてくれー。
>客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」
>してたんですが、ここで情報の欠落(伝言ゲーム)や遅滞が起きるんで
よくあります。相手先の営業が間に入って理解しないまま適当な事をしたりとか、
担当者として紹介された人と話したはずなのに、実際にはその人の部下に丸投げとか。
ちゃんとしたところは質問票を作って確認してきますね。
うちの会社ではレビューで顧客に確認したかという事をしきりに聞かれるのですが
他の所ではやってないのですかね。
>「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
>「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っ
ていう事態が頻発しまして。
昔、発注先から要求された事がありましたが、結局破綻しました。
問題や質問があると新規項目に書くのですが、説明になっていない説明で
終了させようとするので、全然意味がなかったですね。
>あー。「相手が知りたいこと」と、こちらが用意する「結論」とは、一緒じゃない可能性が結構あるんですよね。
>結論も、こちらが用意する限り、あくまで「知らせたいこと」の範疇でしかないのです。
相手の質問に対して回答するような形式だと、そうですね。
そういった場合、これ(ここ)はどうするつもりなのかと、逆に考えを問うてみて
相手の思考の枠を広げるという事も必要でしょう。
>言い換えると、「まず結論を書いて…」みたいな、結局は書き手側の発想でしかない方法論は、
>古典的な書籍みたいに改訂をやりにくい環境に「特化」した方法論なんじゃないか？と思っています。
>改訂できないという制約のもとで最高なものにしようとしたら、
>仕方ないから自分が言いたいこと(の核心)を最初に相手にぶつけるというスタイルしか無い、という。
それは一面にしかすぎない。会話にも使える話ですよ。
書くのも話すのも、結局相手にどう伝えるかに尽きると思います。
その時に相手の立場に立って伝えられるかどうかで、
同じ内容を伝えるのでも伝わりやすさが全然変ってきます。
判断して貰うのであれば、選択肢を提示するなど、
これを怠ったり、無意識に片方の選択肢を捨てているために
後で問題になるんですよね。
>で、仕様の打ち合わせみたいなものってのは、
>もともとそんな制約とは無縁であるはずです。
同意。
>つまり、「たまにしか会えない」ことを前提にしちゃ、
>駄目なんだと思うんです。
ソフトウェアの技術者にメールで済まそうとする人が多いですよね。
ずぼらな人はメールすらしない。
やはり、コミュニケーションが重要という事ですね。