バグを作ってしまったら？
| 77 票 / 7% |
| 275 票 / 26% |
| 47 票 / 4% |
| 40 票 / 3% |
| 104 票 / 10% |
| 351 票 / 33% |
| 71 票 / 6% |
| 70 票 / 6% |
投票所 | 他の国民投票
- 選択肢が少なくても文句禁止。だって、そもそもがジョークだし、場所は有限だし、選択肢を決めるのに事前投票なんてできないから。
- なんか良い投票ネタがあったら是非タレコんでくれ(国民投票用と明記)。毎回かなり悩みまくりなんだな、これが。ぶつぶつ言わずに助けてくれよぅ。
- この投票はとってもテキトーだ。四捨五入の誤差、投票マニア、ダイナミックなIP、 システムのバグ、プロキシーやファイヤウォールなんて考慮しちゃいない。統計だと思って このデータを大事な事に流用しようと思うなら小学校からやり直しましょう。
この議論は賞味期限が切れたので、アーカイブ化されています。
新たにコメントを付けることはできません。
犯罪 (スコア:4, すばらしい洞察)
ここは一つ、 (スコア:3, 興味深い)
直せるのがバグ、直せないのが仕様。
とか言ったらダメなんだろうか…。
Q. なぜ「直す」がないんですか？ (スコア:2, おもしろおかしい)
A. 直すと次の仕事がこなくなるからです
# えっ
Re:Q. なぜ「直す」がないんですか？ (スコア:2)
そう言うことだったんだ！
私も「直す」が無いので投票できなかったのですが、
直さないのが凡才サラリーマンプログラマーの常識だったとは！
でも、仕事が来なくなるから、完成させない。
というよりは、一応使えているのだから、ましではないだろうか？
Re:Q. なぜ「直す」がないんですか？ (スコア:1)
先生！一度直すと次から次へと直す仕事が降ってきます！
もう〇〇が書いたコードを読むのには飽きました
# でも人間として可能な限りは直したい
# mishimaは本田透先生を熱烈に応援しています
Re:Q. 紺猿とか文系出身の似非Ｅはそれが仕事だと思ってる。 (スコア:0)
相手に訴えられなきゃ正義だと思ってるよ。 人事紺猿とかそういう人たちも、そういう人間をコミュニケーションの
取れる人材とか言うし、日経ＢＰ＊も、そういう人こそがＰＭであり、
経営の解った技術者とか提灯付けてる。
でも、顧客の購買が一番、この手の似非Ｅと紺猿が好きなんだよね。
極楽院いずみこさんは (スコア:2, おもしろおかしい)
言葉通りニューヨークをビッグアップルにしちゃいました。
＃バグアップルの中ではZ-80の番号が付いたのが一番性質が悪いらしい
らじゃったのだ
うー、にゃー
発注元の責任者にダメ元で聞いてみる (スコア:2)
100点満点の完全無欠な彼女より、65点くらいのドジっ子の彼女の方が愛おしいと思いません？
You know？あはーん？
＃シラフじゃないのでID
Re:発注元の責任者にダメ元で聞いてみる (スコア:1)
アッーーーー!!乙。
なにその責任のとらせられ方こわい。
ぶっちゃけ、前ネタにしてから相当たつのにいまだにバグにバグをつんでくれてて納品できてないような素敵業者さんも、もし担当者が妙齢どストライクの女性で彼女になってくれるなら(略)
＃ということは、ありません。本当ですよ?
＃＃「お前は、本当にプログラムのセンスがないな。もう職業プログラマから足を洗ったほうがいい。」
＃＃「これからは、俺とお前の人生のプログラムを組んでくれ。」とかいう気はないですからね?
＃＃＃そして、影でデバッグしまくるというオチ
＃＃＃シラフジャナイノデ(略)
え? 男? ああ、「どじっこの男はもう全然だめだだめだ」とらき☆すたの中の人もいってたからだめです。
＃その判断基準もどうかと
Re: (スコア:0)
運用で対応 (スコア:2)
運用で対応するのが現実的で実際にもよくあるとおもうんだけどな。
バグの種類にもよるけど、部門間や会社間にまたがって作業しないと直せないようなバグだと、
無理して直さずに、アプリ内に注意書きを入れてしまうとかの対応になります。
Re:運用で対応 (スコア:2)
バグ仕様書と、制限仕様書を急いで書いて送った記憶が遠い昔に。
今回搬入したものには、このようなバグがあり、この範囲内で取り扱ってください。
改善予定はいついつです。
…と時間稼ぎして(笑)ある意味デスマ的に一生懸命直す。
直しつつ、次の段階のリリースもしなくちゃいけませんけどね。
運用でなんとか回避できる範囲ならいいけど。
(えてして追加した新機能とか、それがらみでのデグレだから、ほんとごめんなさい。)
行き着く先は一緒 (スコア:1, すばらしい洞察)
仕様と言い張る
↓
じゃあと納品後の仕様変更指令
↓
デスマ de GO!
これがお約束のパターン。あ、バグじゃなくて本当に仕様でもね。
Re:行き着く先は一緒 (スコア:2, 参考になる)
仕様書通りに作ったらバグレポート挙げられたでござる。
#まあ、誰もが通る道か
Re:行き着く先は一緒 (スコア:1)
触ってみて、気に入らない動作だった場合、自分たちで言った仕様でも「バグ」と言い出す集団もいます。
で、そういう人に限って「普通はこういう動作にしないでしょう」とか「一般的なシステムでは違う」とか言ってくる。
その「普通」とか「一般的」の基準を明確にしてくれ。
こちとら20年以上SEやってるが、顧客ごとに臨む動作はバラバラなんで「普通」や「一般的」が何なのか全くわからん。
Re:行き着く先は一緒 (スコア:3, おもしろおかしい)
>触ってみて、気に入らない動作だった場合
極端な実例を一席。
２０年近く前に、某家電メーカの資材関係のお方相手に、
GUIのアプリ作ってお試し使用してもらった。
誤ったトコロをクリックしそうになったので、「そこはまだだめですよ」というと、
あわててマウスを避けてくれたのだが、その後...
「ボタンをクリックしても起動しない、クリックを離さないと認識しない。
クリックは押すということだから、押した瞬間に指定機能が動かないといけない」
とかいいだす。で、そばにあったMacで、「他のOSやアプリも同じですよ」と
説明したのだが、「それはMacも間違っている、ちゃんとしたモノなら押した
だけで動く！」
Windows系とかでも試させたけど、頑として聞かない。
プルダウンにしても、選択してリリースしないと機能が発動しないという実例を見せても。
さらには「押す動作なんか不要なはずだ、マウスをもっていったら動く様にするべきだ」
とまで言い出すし...お前、GUI使ったことねぇのかよ？
「マウスカーソルが移動しただけで動くと逆に危険ですよ」というと、
横に居たその人の部下は頷いていたけど、ご本尊は無視をきめこんでいた。
「じゃ、すいません、直しますんで、明日にでも」
ついでに「マウス移動だけで稼働する様にすると大変ですよ」その人の部下にめくばせ。
翌日そのまま持って行ったら通った...www
>顧客ごとに臨む動作はバラバラなんで「普通」や「一般的」が何なのか全くわからん。
顧客の言うことの３割方は、その場の思いつきで、それも無知や無経験が背景にあると、推測しています。
Re:行き着く先は一緒 (スコア:1)
Lotus1-2-3（もち、Windows版）がその挙動で困った記憶があるな
いつものノリでボタン押して、あ、やっぱりやめよっかなって思った時は遅い
Re:行き着く先は一緒 (スコア:1)
就職してから、「普通」とか「一般的」とかって言葉が大嫌いになりました！
うらやましい (スコア:0)
言い張れる仕様が存在するんだ。
#仕様なんぞ無くともデスマ可能さ。
Re:うらやましい (スコア:2, おもしろおかしい)
(詠人:Anonymous Coward)
Re:うらやましい (スコア:1)
そして悲しくうたふもの よしや
うらぶれてIT土方となるとても
帰るところにあるまじや
まずは率直に協議 (スコア:1)
ユーザと協議して直す（それほど重要な問題でなければ仕様化する場合もあり）かなぁ。
（webサービス等でユーザと協議できない場合は協議はしないけど直す（それほど重要な問題でなければ仕様化する場合もあり）かなぁ。）
商品は作ってないから費用面は直す人の人件費や研究・開発日程の遅れとして間接的に発生かなぁ。
…ということで「協議」か「直す」に１票。どっちも選択肢にないけど。
全面的に謝罪 (スコア:1)
単純ミスなら謝って直すけど (スコア:1)
仕様漏れとか、仕様不明確とか、担当者によって言う事が異なる場合とか、直しようが無いケースの方が多かったり。
特に、担当者によって作業手順や解釈、定義が異なるのは勘弁して欲しい……
（ログインユーザ毎に処理ロジックが異なるシステムを作れと言うのか？）
notice : I ignore an anonymous contribution.
Re:単純ミスなら謝って直すけど (スコア:2, すばらしい洞察)
そんなのは、その違うことを言う人双方宛にメールなり双方参加の打ち合わせで合意を取ってもらって返答もらうなり、文書に残る形で問い合わせて合意を取ってから実装すべきでは?
合意とらない実装してぐだぐだになるよりそういう習慣を作ったほうが双方にとっていいと思いますよ?
Re:単純ミスなら謝って直すけど (スコア:1)
文句は言うけど、責任をとるのは嫌らしいです。
# お客様のとこのシステム部がまとめた仕様にしたがって作成すると……けっこうな割合で発生。
# 要するに業務フローが文書化できていない状態で開発しているって事です。 部署間の調整を外の人に押しつけられても……
notice : I ignore an anonymous contribution.
Re:単純ミスなら謝って直すけど (スコア:1)
そんなので合意が取れるなら、現場に来る前の段階で合意してると思うよ。
合意が取れないまま現場まで流れてきたってことは、合意する意志も能力もないって場合が多い。
しかも意志決定の権限は離したくないっていうんだから。。。
Re: (スコア:0)
検収が通ったんだから、あとは別料金ですよ。急いで欲しければ特急料金ですよって商売してたけど
これってあたりまえじゃないの？
品質最優先という言葉 (スコア:1)
私、部品メーカに務めているのですが、「安全第一」のつぎに「品質最優先」という思想を教えられました。
＃実情は納期優先ですけれども
また、物理的にモノを作っているところはＰＬ法を意識しなければいけませんし、最近では ISO9001 など品質に関する会社の取り組みが実を結んでいる会社も多いです。
これらのことができてないと、顧客から受注を取りにくくなるなどのリスクもあるため、会社としても一時期かなり力を入れて活動し、現在でもそれなりに継続しています。
で、本題なんですが、コードを書くことを生業としている会社って、品質保証に関する意識はどれぐらい高いものなんでしょうか？
ぶっちゃけ、品質事故を防止する役目の「品質保証部門」ってあるんですか？
デスマーチという言葉を見るにつけ、バグという言葉を見るにつけ、社員の安全（健康）やら売り物の品質やらどうなってるんだろうと思っちゃうんですが・・・
幸せ≒やまびこ [slashdot.jp]
ハードウェア業界とソフトウェア業界の根本的な違い (スコア:3, 参考になる)
日本のIT業界の階層構造のうち、上層の方の大企業には品質管理部門がありますが
業界の大半を占める中小にはまずありません。
日本の自称IT企業の中で、特に中小の9割以上は
たとえ自社の業務内容として「ソフトウェア開発」と書いてあったとしても
実態としては単なる派遣業者ですから独立した品質管理部門などありません。
そのため、品質は派遣先の企業側の制度と、派遣される個人個人のモラルによります。
#派遣業者もスローガンとして品質上げようと言ってたりはしますが専門部門作るなんてまず無い
日本のハードウェア業界は、小さな町工場でも自分の所で実際にモノを作ってるわけですが
ソフトウェアのほうの小企業だとオフィスには社長と事務員ぐらいしかおらず、なんにも作っていません。
これが日本のハードウェア業界とソフトウェア業界の決定的な差だと思います。
ハードウェアなら世界に誇れる技術を持つ町工場があるのに対して
ソフトウェア業界が貧相なのは、これが大きな要因の一つだろうと思います。
--------------------
/* SHADOWFIRE */
Re:ハードウェア業界とソフトウェア業界の根本的な違い (スコア:1, 参考になる)
＞そのため、品質は派遣先の企業側の制度と、派遣される個人個人のモラルによります。
品質が個人のスキルに依存するのはソフトウエアの基本的性質です。
これは組織や規則によっては解決できません。
この辺りはソフトウエアを理解できてない人が良く勘違いする所ですね。
＞たとえ自社の業務内容として「ソフトウェア開発」と書いてあったとしても
＞実態としては単なる派遣業者ですから
これは同感。
＞日本のハードウェア業界は、小さな町工場でも自分の所で実際にモノを作ってるわけですが
製造業だと、中小企業で作った「部品」を買い付けたり、部品を作ってもらったり
する例が多いと思うけど、ソフトウエアの場合にはこれが成り立ちません。
特にSI的な受託開発では、元請けによる部品の切り分けや品質管理など夢の又夢。
どれだけ優れた技術を持つ町工場的ソフトウエア開発会社があったとしても、
元請けはそれに対してお金を払いません。結果として利益を出せずに倒産するので
長生きできません。
Re:ハードウェア業界とソフトウェア業界の根本的な違い (スコア:2, 興味深い)
>＞そのため、品質は派遣先の企業側の制度と、派遣される個人個人のモラルによります。
>品質が個人のスキルに依存するのはソフトウエアの基本的性質です。
>これは組織や規則によっては解決できません。
>
>この辺りはソフトウエアを理解できてない人が良く勘違いする所ですね。
ハードだって同じです。
基本的に個人スキルにより大きな差異が発生します。
ただ、それが目の前の「モノ」として理解し易いが為に、管理も発達しただけです。
大量生産の物であったとしても人が絡む所では必ずスキルによる差異は発生します。
この辺りがソフトウェアは特別な物だと考える人がハマり易い処。
ソフトウェアはそこで目に見え辛い為に見逃されがちなだけです。
ライブラリやフレームワークをハード生産におけるの自動機器と考えれば、
実は品質管理として注意しないといけない所は同じような物です。
ただ、複雑化しやすく問題が見逃され易い上、後で対処できるってのが、向上を
求めない者達には都合が良かったってだけで、厳しい競争にさらされる物では、
それなりの品質管理は構築されつつありますよ。
＃個人問題として足を引っ張る人が多いんだよなぁ…。
Re:品質最優先という言葉 (スコア:2, すばらしい洞察)
「ハードウエア『製造』の品質 ≒ 精度」に対し、
ソフトウエア『開発』 はハードウエアの『設計』に相当し、
「設計品質 ≠ 精度」なので、
「精度を測る部門」としての「品質保証部門」は無意味です。
設計の品質は、計測機器により測ることは不可能です。
ソフトウエア開発を知らない人が、ハードウエアの品質管理手法を
ソフトウエアに適用しようとして失敗する最大の理由がコレです。
Re:品質最優先という言葉 (スコア:2, 興味深い)
サルが製造しても作れるような設計にしろ、と言われます。
設計の品質を測る方法もいろいろ模索されています。
それがちゃんと出来ているかどうかはともかく…
というかできてません。
開発と設計と製造で作り込んでます。
Re:品質最優先という言葉 (スコア:1)
聞くようになったのは割と最近かも知れません。
# 私が知らなかっただけという可能性も高いですが。
# と思って一応ぐぐってみたら、
# http://ja.wikipedia.org/wiki/FMEA
# やはり歴史は古いようで。。
Re:品質最優先という言葉 (スコア:1)
それは製造と開発の違いを述べているだけのような。
>「精度を測る部門」としての「品質保証部門」は無意味です。
> 設計の品質は、計測機器により測ることは不可能です。
設計を手順化して品質を確保する手法もISOの仕組みの一つだし、ハードウェア設計でも普通に行われていますね。
>ソフトウエア開発を知らない人が、ハードウエアの品質管理手法を
>ソフトウエアに適用しようとして失敗する最大の理由がコレです。
ハード／ソフト関係なく、単に設計・開発手法を知らないっていうだけのような気が。
品質設計と品質管理は違いますからね。
Re: (スコア:0)
(特に海外の)ソフトでは Quality Assurance はテスター的な役割ですね。
プログラムできる原因切り分け可能かつ開発の人としゃべれるテスターと、思いも寄らない挙動のできるユーザー感覚を持つ素人テスターが組んで品質部門を構成すればよい結果がだせると踏んでいますが...
大部分においてその2人分のコストはでないでしょうね。
# ただしどちらも目が節穴ではない必要はありそう
Re: (スコア:0)
Re:えっと (スコア:1, 興味深い)
メーカー界隈の用語で安全第一、品質優先、納期遵守っていったら、すべてが最上位です（マジ）。
これらをすべて兼ね備えてはじめて普通です。ソフトウェアと比べると中小企業でも数量の桁が違うので、ばら撒いたあとの品質クレームは簡単に経営を揺るがします。
そんな中でどれが一番なの？って言われたときに返す言葉は、「全部一番」になります。言い方には順番ありますけど、そこを茶化しても、エライ人からは10人が10人とも同じ言葉が返ってくると思います。
＃5Sの躾とか建前先行とか根っこのところで体育会っちゅーか軍隊式っちゅーか
Re:えっと (スコア:1)
>メーカー界隈の用語で安全第一、品質優先、納期遵守っていったら、すべてが最上位です（マジ）。
納入仕様に記載されてれば、その中の順位づけなど無意味ですねぇ。そこを判断するのは客ですし。仕様範囲外の要求が来た場合に、初めてどの優先順位が高いかという話になりますね。
製造できないものを客に売ってはいけません。
>＃5Sの躾とか建前先行とか根っこのところで体育会っちゅーか軍隊式っちゅーか
幾ら有能な人でも、決めた手順と違うことを勝手にやって違うものができる方がよほど困りますね。まぁ、実際には手順外の部分で結構個人技は重要なんですけど。
結局のところ (スコア:0)
「金で解決」って、実際に結構ありませんか？
仕様ですって言い張って、仕様変更（但しお客さんからは金を取れない（無償）ね）とかも結局金って事ですし...
#工数で考えると、百万単位で持ち出しとか、結構あったりするよなぁ...
Re:結局のところ (スコア:1)
個人的には完璧目指したいですが、やっぱり作る事もあります。
結局、バグの深刻度次第と金の天秤ですよね。
今は有効になってない機能とか、金払ってまで出来るかっとかありますし。
改修した奴を動くようにするためにお客さんが業務を止めないといけないとかになったら、
客が「じゃ、今回はスルーで、次の更新時に纏めて入れて」とかいうケースも有りうるでしょう。
「じゃ、業務停止に対する賠償ＸＸＸね、出来次第直ぐ入れて。」とかなるかもしれませんが。
結局客と相談が第一手だよね。
後は客がどう判断するか。
自分がするのは、もう諦観と次に作らないようにしないとって思うしかないでしょう。
新聞沙汰になってたらもう、自分一人でなんとかなるレベルじゃないだろうし。
後は再発防止を考える位ですかねー
# 正常系しか考えてなさそうなコード・仕様書を見ると無性にツッコミしたくなる難儀な子です。
# 日曜プログラミング時のコードはお仕事コードの5%でも異常系を考慮してる？的な出来ですけど。
誰も信じちゃいけない、裏切られるから。
私を信じないで、貴方を裏切ってしまうから。
こっそり直す (スコア:0)
こっそり直すことが多いかな。
で、
「おかしいですねぇ。もう一度やってみてくださいー。」
とか言ってごまかす。
仕様はバグだ バグが仕様だ (スコア:0)
Re:仕様はバグだ バグが仕様だ (スコア:1)
バグだと思ってプログラムを止めようとするとPCが爆発、
そこで止めずにOCするとPCがエメラルド色に輝きだすんですね。
らじゃったのだ
うー、にゃー
Re: (スコア:0)
責任を下請けになすりつける (スコア:0)
「我々の設計は完璧だった。バグを作ったのは『製造』した下請けの責任だ」
というのは元請けの方達の基本テクニックですよね。
たとえその設計が穴だらけの青写真に過ぎなくても。
Re: (スコア:0)
当たり前じゃん。金出してるんだから（会社の金だけど）。
「穴だらけ」って、上流工程ってのは、元々そういうものなの。 「すでにあるもの」ならパッケージ製品ですむでしょ？わざわざ金出して作っているのは「現時点でない」から。 「現時点でない」ものなんだから、そうそう完全な設計なんてできないでしょ。 そのユーザ要望を具現化する技術力に金出しているんだよ。最初に「できる」って言って、後で問題起こしたら、もちろん『協力会社様』の責任ね。なにを当たり前のことを。
それでできないなら、そのユーザ要望を具現化できる会社に乗り換えるまでのこと。その選択眼と交渉力こそ上流工程の腕の見せ所でしょ？
Re: (スコア:0)
釣りなんだろうけど、
そのセリフをお客さんに言ってみてよ。
言えるものならね。
＃まるっきりネタなんだろうけど、まれに本気でこういうこと言う馬鹿者がいるからなあ。
Re: (スコア:0)
期末試験で理論的には正解が複数ある選択問題、どれが欲しい解答かのサジェスチョンすらなし、そんな選択問題を出されたとしましょう。それで出題者の意にそぐわない選択肢を解答として選んだら落第の評定を受けたとしましょう。それでも文句を言わない人なんですね。ちょっと僕には理解できません。
この場合では上流工程は正解が複数ある選択問題を出した出題者、解答者が協力会社ですね。
上流工程というのは適切な開発をできるように仕様を定めるのが仕事なんだと理解していましたが、違うのですか？仕様を定めるというのはソフトウェア開発でもっとも重要な工程の一つでしょう。そうであるからこそ、協力会社に実際のコーディングをさせているとしても上流工程の会社はお金をとれるのです。上流工程の方が仕事していない責任を協力会社にとらせようだなんて無茶な話。どこが協力会社になってもいずれ大きな問題が起きますよ。