ソフトウェアの品質を上げるにはどうするべき？ 97
ストーリー by hylom
バグが何件出るかなんて予測できるの？ 部門より
バグが何件出るかなんて予測できるの？ 部門より
あるAnonymous Coward 曰く、
ITproにて、「品質管理のやり方として正しいのはどれ？ - 今日の腕試し！」なるクイズが掲載されている。品質を上げるの必要なのはバグ出しだけではないが、設問をつくるために敢えてバグ出しをターゲットにしたのだろう。それはいいのだが、個人的にみてこの3択には正解の要素が見受けられない。特に、正解をみてしまうと「今時、こんな方法をとっているベンダーとは疎遠になりたい……」と思ってしまう。
ちなみに、バグ出し（と、そのためのプログラム作り）には開発期間の半分はとるべきだと私は考えているが、そううまくいかないのも現実である。理想と現実に挟まれるSEやプログラマが多いであろうが、諸兄はどこを落とし所にしているのだろうか？ ちなみに、私の現職は中小企業のシステム管理である。前職はプログラマであった。
常に品質管理手法をフィードバックして見直すことです (スコア:4, おもしろおかしい)
その職場に合わせて常に改善をするべきです。 ねえ、富士通さんの SDEM！
日立さんの人海玉砕戦法よりはましだけど。
1人でやっているときは (スコア:3, 参考になる)
それでリリースになります。
グループでやるときは、知りません。
チーム・ファシリテーション・マネージメントが先決でしょうか。
Re:1人でやっているときは (スコア:4, 参考になる)
悟るのとリリースの順番は逆ですが
Re:1人でやっているときは (スコア:1, おもしろおかしい)
そもそも (スコア:3, 興味深い)
そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ
＃ＡＣの意味がないのは芸風です（言い切った）
Re:そもそも (スコア:3, 参考になる)
> 「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。
完全同意の、すごく良いこと言ってると思うんですけど、ここで言う 品質 に２つの意味が混ざっちゃってませんか？
「品質」と聞いて何を思うかは人それぞれですが例えばISO-9000でいう品質とは：
ということになってます。
つまり「その製品を要求事項にどれだけ近づけるか」が品質だ、とまずは定義しておいて、
じゃあ要求事項って何よ、としたとき、
「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とすると、
「『顧客満足』を満たすことが要求されたことだ」と、近頃は より踏み込んで品質管理を再定義する考え方が広まってきています。
巫女・・・失礼、ACさんのコメントで「バグの数＝ソフトウェアの品質」というのは前者の品質で、それ以外は後者ですよね。
この２つの品質は分けて語らないと やることが正反対になっちゃったりするので要注意だと思ってます。
# 仕様書原理主義と積極改訂派の聖戦を何度経験したことか
個人的には、どちらの考え方も大切だと思います。
巫・・・ACさんの、バグの数だけ見ていても後者の意味の品質には永遠に気づけない、という考え方は
お世辞抜きに、物作りに関わる全ての人に持って欲しい素晴らしい考え方です。
が、「バグの数を品質管理に利用する」という方式論も、前者の意味の品質管理においては決して短絡的でない、有効な手法であると思います。
Re:そもそも (スコア:2, 参考になる)
えっと、そのISOには、”要求事項”として、”暗黙の”要求事項も含まれると書いてあるので、「旧来の品質管理」であっても、仕様書に書いてあるのがすべてだなんてことはありません。
ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。
なので、
＞より踏み込んで品質管理を再定義する考え方が広まってきて
っていうのは、最近の流れではなくて、昔からまともな考え方です。
ありうるとしたら、ISOやCMMを誤解した人たちが一時期いっぱいいたということでしょう。
＞仕様書原理主義と積極改訂派の聖戦を何度経験したことか
仕様書原理主義者っては、言われたことをやるのに精一杯な若手のことでしょ？
顔が老けたり、態度のでかい若手もいるでしょうが、そういうときは、戦うのではなくて、にこやかにたしなめるのが、先輩としての態度でしょうｗ
Re:そもそも (スコア:1)
まず、トラウマに触れたのならすいません。
自分は元コメの話の流れから、「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とすると、」があたかもISOからそう導かれると読み取ってしまいました。
「ISOは、顧客の要求なんてどうでもよい。文章だけ整えればいいんだ。」という考え方を感じたんです。
自分には、そういう人たちに品質をずたずたにされたトラウマがあります。
トラウマで脊髄反射投稿してしまってすいません。
＞そのうえで明示＝旧来、暗黙＝新しい、と言い換えてわかりやすく説明してくれてるじゃん。
その言い換え自体が引っかかるんです。
なんで旧来のやり方は明示的なものだけだといえるんですか？
昔は悪いもの。現在はいいもの。というきりわけに感じてしまいます。これも誤読でしたらすいません。
＞最近っていつからいつまでさ。昔っていつさ。話者によってスパンが異なる概念をオレ目線でしか考えられないから
近頃と旧来を勝手に言い換えてしまいましたね。”近頃”、”旧来”がオレ目線でなく、”最近””昔”がオレ目線でしたらすいません。
以上
Re:そもそも (スコア:1)
ずいぶん親切な方のようでありがとうございます。
＞会議でそういう奴がいると迷惑だろ？そういう奴がいるとさ、どうでもいい話に時間取られて大事な話ができなくなる。
会議ではさすがにしませんね。雑談場だと思うからしましたけど。
元コメの主張と違う瑣末なところに突っ込んだから怒られてるんですね。ようやく理解しました。
それなら全くその通りで、弁明のしようがないです。
（ちがってたらどうしよう。）
自分は元コメの「『仕様書に書いてあるのが、要求されたことだ』と捉えるのが旧来の品質管理とすると」
というところに引っ掛かっていました。過去は過去で品質のいい時代もありました。
が、それにＩＳＯを絡めるとかよくわかんない展開してますね。
＞ISOとかCMMとか、馬鹿にする前にちゃんと読んでね。
ではなくて、
「昔の品質管理だって悪いものばかりではないよ」を主張とすべきでした。
それにしたって元コメの主張とは外れてますけど。
１７時のコメントはちょっと冷静さを失ってました。
ＡＣさんのような語調は、プロジェクトを散々ひっかきまわした挙句退社した元上司を思い出してしまい、苦手でして、すいません。
元コメの方にもお詫びします。
Re:そもそも (スコア:1)
Re:そもそも (スコア:1)
Re:そもそも (スコア:1)
実は顧客はそういう風に使いたかっただけだったりするし。
困ったことに、設計者も開発者も、ましてや顧客も、あらかじめそれが判らない。
Re:そもそも (スコア:3, 参考になる)
実際には、そういうことができる人から先に外されるのが常ですね。
技術的な落とし穴を指摘すると、「後ろ向きな発言をするな」と言われたりとか、ありがちです。
品質が安定していてうらやましい (スコア:3, 興味深い)
俺が師匠に言われたのは、
・BUGが無くなったっと評価したら、その評価がBUGである。
・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
・キチンとした「仕様書」が入手出来ていない仕事の場合、「おまえのセンスで何とかしろ。」
・・・そんなオチかよ！！
Re:品質が安定していてうらやましい (スコア:1)
＞・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
まあそうなんだけど。
セキュリティリスクくらいは指摘して欲しいと思う。
Re:品質が安定していてうらやましい (スコア:1)
同感。
非機能要件はユーザから見えませんので。
運用とか保守とかリカバリとかセキュリティとか。
# 今時、共通フレームとPMBOKとITIL辺りの理解は必須……
---- 何ぃ！ザシャー
Re:品質が安定していてうらやましい (スコア:1)
>顧客満足度の話が混じっているように思われますが、客の立場から
>言えば、極端な話、仕事に使えるかどうかだけが問題です。
仕事に使えるモノという定義が難しいんだよね。
実際、自分がやっている仕事の「実際やっていること」しか知らないで仕事している場合が多い。
そして、そういったお方は目の前でやっていることを、自分の言葉で言ってしまう。
そうなると、「ある全体の流れの一部の支流についての個人的見解」レベルになる。
どういった石を置くか？ではなくて、なんでその石を置いて、どう流れを制御するか？
流れているモノは何か？そもそもそれがなんで流れる必要があるのか？といったことでは
なくなってしまう。
なので、その流れがあるべきか？とかいった以前に、その流れに「似たような石を置いたら
流れなくなった」みたいなことが多いんだよな。
Re:品質が安定していてうらやましい (スコア:1)
流れなくなったり、流れ方がよくわからなくなったりしますね。
一方で小さな石だとたいした値段をつけられなかったりして。
# yes, fly. no, fry.
せめてリンク貼らないと却下されるんじゃ…と懸念 (スコア:2, 参考になる)
http://itpro.nikkeibp.co.jp/article/COLUMN/20100917/352079/?ST=system [nikkeibp.co.jp]
今日の腕試し
くらいは記さないと恥ずかしがりにもほどがある。
この三択に納得いかないようなら代替案をだしていただかないと連行されたビジネスパートナー各社メンバーは何をターゲットに進めればいいのかと。
ちなみにどっかにもぐりこんで仕事したときは主に2番のやり方でUT/IT/OTといくつかを後工程に積み残しながらというのが多かったかな。
Re:せめてリンク貼らないと却下されるんじゃ…と懸念:代替案 (スコア:1)
神に祈る。
ただし、生贄が必要。
ラリー・エリソンを社長にしてもいいかも。
たまたま彼と神はどう違うか、とかいう感じの本を今日読みました。
Re:せめてリンク貼らないと却下されるんじゃ…と懸念:代替案 (スコア:1)
Re:せめてリンク貼らないと却下されるんじゃ…と懸念:代替案 (スコア:1)
一番いい品質を頼む。
Re: 部門名 (スコア:2, おもしろおかしい)
当然です。今どき予測件数に対して1件の狂いもなくバグを出す程度の能力がなくては仕事を受注できるわけがありません。バグを1件も出さないなんてのは素人のやることです。
Re: 部門名 (スコア:1)
バグを出すっちゅうか、予定分作らないとＱなんちゃらが五月蝿い（ごがつばえい）んだってよ
＃友達に聞いた話にしとこうぜ
バグ数予測といえば (スコア:2, 興味深い)
テスト時に見つかったバグが予測数値より少ないと「テストが不足している」と文句を言われ、
バグが多いと「品質が悪い」と言われてました。
直接の担当の人はそんな計算数値通りになるわけないと分かってくれてましたが、
管理部門の人たちは計算からズレるとうるさいそうで。
いい加減、日経*の読者層や読み方を理解すべき (スコア:1, 参考になる)
ガイアの夜明けを死亡フラグと笑えるぐらいのスルー力が必要だよ。
テストにも金をかける (スコア:1)
どれだけ内部でテストしても基本的には無駄
できれば基本設計の時点から第三者にレビューしてもらうのがベストだけど、
そこまで品質にこだわるプロジェクトなんて滅多にお目にかかれないですね
＃あと「予備日」をスケジュールに入れておく。これをやるかどうかで格段に違う
懐かしの「マーフィーの法則」 (スコア:1)
真理だと思います。
如何なる内容であろうとACでの書き込みは一切無視します。
バグに気づける体制を作ることが大切だと思う。 (スコア:1)
どんなにやってもバグは絶対になくならないから上手に付き合っていくしかないと思う。。。
バグに誰も気がつかずに燃えていたなんていうのが一番いけないので、
バグに早期に気がつける体制、システムを構築して、早期発見早期治療を行っていけばいいんぢゃなイカと。
エラーがあったら、コンテキストをログに保存するとか、ユーザから簡単に問い合わせできるようにするか、アプリケーションログを取って、定期的にgrepしてアラート上げるとか、絶対に間違えが許されない場合、複数系統を作って多数決とるとか、定期的にデータの整合性を取るバッチを回すとか、、、
いろいろ方法はあるんぢゃなイカと思うでゲソ。
by rti.
ソフトウェア工学なんて勉強したことないよ!! (スコア:0)
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:0)
ソフトウェアテストにおいても「目標設定 → 計画 → (実行) → 測定 → 計画または目標の修正」という手順が必要だという，極めて一般的な話なんですけどね．
> バグが何件出るかなんて予測できるの？部門より
予測せずに，どうやって必要な工数(労力)を見積るんですか?
> バグ出し（と、そのためのプログラム作り）には開発期間の半分はとるべき
なぜ半分は必要だと言えるのですか?
述べられていませんが，どれだけの期間を割けば十分なのですか?
テストを行う人の技術レベルや人数を考えずに，期間を半分(以上)と設定することに何の意味があるのですか?
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:2, 興味深い)
>> バグが何件出るかなんて予測できるの？部門より
>予測せずに，どうやって必要な工数(労力)を見積るんですか?
なんか、いまだにバグはあってはならない！
あってはならないものの件数を考えるな、
そんな閑があるならとっとと潰せ！
みたいなお方もちらほら
> 測定 → 計画または目標の修正
測定している間になぜか、そのソフトウェアの規模が膨らんだりして、
再度の目標設定以前に、自分らが何を作っているかすらが曖昧になって
いたりしませんかね？
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:1, 興味深い)
>> バグが何件出るかなんて予測できるの？部門より
> 予測せずに，どうやって必要な工数(労力)を見積るんですか?
まあそうなんですが。工学と名乗るには、反復的な情報の収集と、それを元にした予測の妥当性が反復的が必要な訳で。それがPDCAサイクルなんですけれど、「ソフトウェア工学」なるものがPDまででCへ行かない、そんな感じはしています。
> テストを行う人の技術レベルや人数を考えずに，期間を半分(以上)と設定することに何の意味があるのですか?
工学的には意味はありません。芸能としては意味があるかもしれません。工学を志向/指向するなら「技術レベル」を考えるだけでは済まず、作業に携わる個々の要員の技術レベルや効率、作業傾向等々々々々を厳密に数値化する事が必要。そうしなければ、工学的にプロジェクト計画なぞ立てる事は不可能な訳で。でもそんな事を無しで計画とか立ててるでしょ？どこの時点でか、「えいっ、やっ！」をやっているんですよ、現実問題としては。工学から芸能への逸脱が発生しているのです。
# いつかアートを抜け出してエンジニアリングになるさ、いつかは
あらこんなこともご存じなかったんですか？ (スコア:0)
グラフ書いて予定数に達するまで頑張るのがふつうですよ
それが正しいのかどうかは別なので、論文でも書いてくださいな
そんなの簡単 (スコア:0)
もしくは、彼らに匹敵する技術者を育てるために金をかければよい。
私が知る失敗事例の殆ど全ては、金の出し惜しみの結果、出し渋った金額以上の損失を生んでいる。
Re: (スコア:0)
金だけで済まそうと思うのが、実は一番の失敗の元。
先ずは自分自身が仕様を理解するところから始めるべき。
発注者が理解していないものなんて、どんな腕利きですらまともに作れない。
Re: (スコア:0)
アルバイト [srad.jp]ならそんなに金はかからないんでは？
Re: (スコア:0)
たまに火が吹いたプロジェクトにただ人を投入するだけの上司がいますが
それで収束することはまれで、たいていは余計おかしくなるだけ。
なので正確には「ちゃんと必要な人材を揃えるだけの金」ですね。
研修上がりの実経験０の新人を火が吹いたプロジェクトに投入して
「しっかり勉強させて鍛えてやれ」なんていう上司をクビにすれば
多少は適材適所に金を投入出来るんでしょうけど…(遠い目)
# 本コメントはフィクションであり実在の上司とは一切関係は
# ありませんと言える会社ってどっかにないかなんて考えてません！！
Re:そんなの簡単 (スコア:1)
> たまに火が吹いたプロジェクトにただ人を投入するだけの上司がいますが
たまにしかいないんだ。うらやましい
Re: (スコア:0)
・たまにしかプロジェクトに火が付かないこと？
・たまにしか忠人を投入する事態にならないこと？
・たまにしかそういう上司がいないこと？
・全部？
Re:そんなの簡単 (スコア:1)
端折りすぎましたね、すみません。
>・たまにしかそういう上司がいないこと？
これかな？
私の読み方が悪くて、元コメを
「トラブった時の対策手段として『人員追加しかカードがない』上司はあまり居ない」
と解釈しちゃいました。
まぁ「戦闘要員として民間人を戦場に配備しないでよ！」ってことです。
最近テスト要員で非技術系の人が増員されたことがあったんですが、
ネットワーク処理のバグレポートで「パケットキャプチャです」といって
画像ファイルが送られたときは参りました。
(wiresharkの実行中の画面をPrintScreenしたようです)
Re: (スコア:0)
こんな記事 [nikkeibp.co.jp]が。
2ページ目以降は登録しないと読めないのでちょっと引用すると、こんな。
Re:そんなの簡単 (スコア:1, 参考になる)
大き目のベンダに勤めてますが、お茶汲みの可愛い女の子に書記を任せると、
会議で建設的意見が多く出易いという経験則を持ってます。
Re: (スコア:0)
時間やお金を掛ければ、奇怪な建築物を作り上げることも可能だと思う。
でも、お金や時間を節約するための体系的な知恵である工学を活用すれば
より簡単により凄いものが作れる。
別に不思議なことではない。そんなの簡単。
ソフトウェアアップデート禁止 (スコア:0)
Re:ソフトウェアアップデート禁止 (スコア:1)
Re:設問をよく読むんだ (スコア:1)
品質向上と品質管理については、ご指摘の通りと思います。
ですが、この設問自体が
＞システム開発では、テストで成果物のバグを見つ出し、それを修正することでシステムの品質を高めていきます。
＞品質管理のやり方として、最も適切なものを選んでください。
となっており、品質向上と品質管理をごっちゃにしている面が見受けられます。
＞システム開発では、テストで成果物のバグを見つ出し、それを修正することでシステムの品質を一定に保ちます。
でしたら、誤解を防げたかもしれません。
Re:設問をよく読むんだ (スコア:2, すばらしい洞察)
ちょっとつまらないろころですまんが
んなこたーない。
# 無限ではないにせよ相当なリソースを突っ込んだだろう Vista が実現予定だった
# 機能はどうなった？顧客満足度はどうだ？
# 無限にリソースを突っ込むというは同時に永遠に終わらないプロジェクトでもあるのかもね。
個人的に「品質を高める」には出来るだけ少数の優秀な企画〜設計と評価が出来る人材とプロトタイピングが有効だと思うね。
# そこからあとは既存のフローでOK
# さんざん既出だが、客から頂戴した企画書/仕様書という名のメモ帳から企画/設計
# の品質を高めずにそのまま開発に入るプロセスが一番悪い。
Re:営業が期間を値切らない (スコア:1)
>クリティカルなシステムだったら厳密に仕様を詰めるから
>真面目に作って真面目にテストすりゃ大丈夫でしょ。
ミッションクリティカルなシステムだからといって、厳密に仕様が詰められているわけでもないみたいなんだな。
「とある会社の大型電算機(ブラックボックス)」みたいなことになる。
そして、それをリプレースしつつアップグレードしようとして「元の仕様と同じ」,,,
といった詰め方でやろうとしてテストどころではなくなったな。
ミッションクリティカルでセビリティが高いシステムだから、
すでの仕様が詰められている(はず)という甘い前提はいけない。
ましてや、これから作るものがミッションクリティカルでセビリティが高い
のでちゃんとなされるはずだと思うと、ああ勘違い。
優秀なPMの予測力は超能力並みですよね (スコア:1, すばらしい洞察)
＃予想が外れたケースは棄却されるんだから、そりゃ精度のいい数字になるわな