アカウント名:
パスワード:
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、という前提が必須です。社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる人を育てないと、どうにもならないと思いますよ。
こう書くと、顧客満足度の話が混じっているように思われますが、客の立場から言えば、極端な話、仕事に使えるかどうかだけが問題です。その情報としては、さっきから批判の多いバグ収束曲線も、客にとっては判断材料になると思います。バグ収束曲線を代表とする、(誤っているとしても)品質を向上をしめす判断材料をいちいち批判していたら、客にどうやって品質が上がりましたと説明するのでしょうか?
作っている側の方には、誰のために自分たちはソフトを作っているのか考えてもらえるとうれしいですね。自分(たち)の給料のためだけとおっしゃる正直な方はぼったくりと呼ばれるべき種族なので、ぜひ永遠にパッケージソフトだけを作っていてほしいです。
>顧客満足度の話が混じっているように思われますが、客の立場から>言えば、極端な話、仕事に使えるかどうかだけが問題です。
仕事に使えるモノという定義が難しいんだよね。実際、自分がやっている仕事の「実際やっていること」しか知らないで仕事している場合が多い。そして、そういったお方は目の前でやっていることを、自分の言葉で言ってしまう。そうなると、「ある全体の流れの一部の支流についての個人的見解」レベルになる。
どういった石を置くか?ではなくて、なんでその石を置いて、どう流れを制御するか?流れているモノは何か?そもそもそれがなんで流れる必要があるのか?といったことではなくなってしまう。
なので、その流れがあるべきか?とかいった以前に、その流れに「似たような石を置いたら流れなくなった」みたいなことが多いんだよな。
>仕事に使えるモノという定義が難しいんだよね。
ここがキモだと私は思ってます。なので、仕事を知っている、あるいは責任をもって回答できる、お客さん側の最終仕様決定者を決めるとか、言いたくないことを引き出すスキルとか、そういった、「客のしたい仕事」ができるシステムを構築できる人をSEと呼びたいし、育ててほしいと思ってます。
そんな人の1/3くらいは、さっさと独立しちゃうんですけどね。そりゃ、私みたいなバカな部下がいたら、とてもやってられないだろうし。
ワンオフ的案件で複数社に発注出すときにバグとか仕様っていうレベルの以前に実戦経験の差みたいなものがありありと出てくるんすよね。出来る業者さんとそうでない業者さんみたいな。
目的の機能満たしたモノを作ってくださいよっていうのをお願いする際に生じる周辺要件をあらかじめちゃんと押さえている業者さんと当たり前のエラー処理さえもこっちで指定しないと動けないレベルの業者さんがいて、その辺を知らない担当が仕様決めしなきゃいかんという状態だと重要度と選択肢と矛盾点に対する決定事項が雪だるま式に増えて最終的に納期と品質が全然変わって来ますね。当然バグの量も。
その辺って技術っていうよりノウハウ的なものなんだと思うので、仕様上なんかしっくり来ないよっていうのに対してどういう補完条件を出したら顧客の決定が早くなるかとか、他社さんはどうやってんの?っていうことに嗅覚を持つといいかもしれないですね。パッケージと違うワンオフみたいな発注側の発注頻度が低い分野の案件だと官民問わずそういうのをやった経験のない人間が発注担当になる割合多いのも見過ごせないところです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
品質が安定していてうらやましい (スコア:3, 興味深い)
俺が師匠に言われたのは、
・BUGが無くなったっと評価したら、その評価がBUGである。
・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
・キチンとした「仕様書」が入手出来ていない仕事の場合、「おまえのセンスで何とかしろ。」
・・・そんなオチかよ!!
Re:品質が安定していてうらやましい (スコア:0)
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、
という前提が必須です。
社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ
仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。
まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる
人を育てないと、どうにもならないと思いますよ。
こう書くと、顧客満足度の話が混じっているように思われますが、客の立場から
言えば、極端な話、仕事に使えるかどうかだけが問題です。その情報としては、
さっきから批判の多いバグ収束曲線も、客にとっては判断材料になると思います。
バグ収束曲線を代表とする、(誤っているとしても)品質を向上をしめす判断材料を
いちいち批判していたら、客にどうやって品質が上がりましたと説明するのでしょうか?
作っている側の方には、誰のために自分たちはソフトを作っているのか考えてもらえ
るとうれしいですね。
自分(たち)の給料のためだけとおっしゃる正直な方はぼったくりと呼ばれるべき種族
なので、ぜひ永遠にパッケージソフトだけを作っていてほしいです。
Re:品質が安定していてうらやましい (スコア:1)
>顧客満足度の話が混じっているように思われますが、客の立場から
>言えば、極端な話、仕事に使えるかどうかだけが問題です。
仕事に使えるモノという定義が難しいんだよね。
実際、自分がやっている仕事の「実際やっていること」しか知らないで仕事している場合が多い。
そして、そういったお方は目の前でやっていることを、自分の言葉で言ってしまう。
そうなると、「ある全体の流れの一部の支流についての個人的見解」レベルになる。
どういった石を置くか?ではなくて、なんでその石を置いて、どう流れを制御するか?
流れているモノは何か?そもそもそれがなんで流れる必要があるのか?といったことでは
なくなってしまう。
なので、その流れがあるべきか?とかいった以前に、その流れに「似たような石を置いたら
流れなくなった」みたいなことが多いんだよな。
Re:品質が安定していてうらやましい (スコア:1)
流れなくなったり、流れ方がよくわからなくなったりしますね。
一方で小さな石だとたいした値段をつけられなかったりして。
# yes, fly. no, fry.
Re: (スコア:0)
>仕事に使えるモノという定義が難しいんだよね。
ここがキモだと私は思ってます。
なので、仕事を知っている、あるいは責任をもって回答できる、お客さん側の
最終仕様決定者を決めるとか、言いたくないことを引き出すスキルとか、そう
いった、「客のしたい仕事」ができるシステムを構築できる人をSEと呼びたい
し、育ててほしいと思ってます。
そんな人の1/3くらいは、さっさと独立しちゃうんですけどね。そりゃ、私みた
いなバカな部下がいたら、とてもやってられないだろうし。
Re: (スコア:0)
今時、言われたことだけいい加減な仕事してたら、次から仕事回してもらえなくなるもの。
Re: (スコア:0)
ワンオフ的案件で複数社に発注出すときにバグとか仕様っていうレベルの以前に実戦経験の差みたいなものがありありと出てくるんすよね。出来る業者さんとそうでない業者さんみたいな。
目的の機能満たしたモノを作ってくださいよっていうのをお願いする際に生じる周辺要件をあらかじめちゃんと押さえている業者さんと当たり前のエラー処理さえもこっちで指定しないと動けないレベルの業者さんがいて、その辺を知らない担当が仕様決めしなきゃいかんという状態だと重要度と選択肢と矛盾点に対する決定事項が雪だるま式に増えて最終的に納期と品質が全然変わって来ますね。当然バグの量も。
その辺って技術っていうよりノウハウ的なものなんだと思うので、仕様上なんかしっくり来ないよっていうのに対してどういう補完条件を出したら顧客の決定が早くなるかとか、他社さんはどうやってんの?っていうことに嗅覚を持つといいかもしれないですね。
パッケージと違うワンオフみたいな発注側の発注頻度が低い分野の案件だと官民問わずそういうのをやった経験のない人間が発注担当になる割合多いのも見過ごせないところです。