アカウント名:
パスワード:
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、という前提が必須です。社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる人を育てないと、どうにもならないと思いますよ。
こう書
>顧客満足度の話が混じっているように思われますが、客の立場から>言えば、極端な話、仕事に使えるかどうかだけが問題です。
仕事に使えるモノという定義が難しいんだよね。実際、自分がやっている仕事の「実際やっていること」しか知らないで仕事している場合が多い。そして、そういったお方は目の前でやっていることを、自分の言葉で言ってしまう。そうなると、「ある全体の流れの一部の支流についての個人的見解」レベルになる。
どういった石を置くか?ではなくて、なんでその石を置いて、どう流れを制御するか?流れているモノは何か?そもそもそれがなんで流れる必要があるのか?といったことではなくなってしまう。
なので、その流れがあるべきか?とかいった以前に、その流れに「似たような石を置いたら流れなくなった」みたいなことが多いんだよな。
>仕事に使えるモノという定義が難しいんだよね。
ここがキモだと私は思ってます。なので、仕事を知っている、あるいは責任をもって回答できる、お客さん側の最終仕様決定者を決めるとか、言いたくないことを引き出すスキルとか、そういった、「客のしたい仕事」ができるシステムを構築できる人をSEと呼びたいし、育ててほしいと思ってます。
そんな人の1/3くらいは、さっさと独立しちゃうんですけどね。そりゃ、私みたいなバカな部下がいたら、とてもやってられないだろうし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
品質が安定していてうらやましい (スコア:3, 興味深い)
俺が師匠に言われたのは、
・BUGが無くなったっと評価したら、その評価がBUGである。
・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
・キチンとした「仕様書」が入手出来ていない仕事の場合、「おまえのセンスで何とかしろ。」
・・・そんなオチかよ!!
Re: (スコア:0)
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、
という前提が必須です。
社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ
仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。
まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる
人を育てないと、どうにもならないと思いますよ。
こう書
Re:品質が安定していてうらやましい (スコア:1)
>顧客満足度の話が混じっているように思われますが、客の立場から
>言えば、極端な話、仕事に使えるかどうかだけが問題です。
仕事に使えるモノという定義が難しいんだよね。
実際、自分がやっている仕事の「実際やっていること」しか知らないで仕事している場合が多い。
そして、そういったお方は目の前でやっていることを、自分の言葉で言ってしまう。
そうなると、「ある全体の流れの一部の支流についての個人的見解」レベルになる。
どういった石を置くか?ではなくて、なんでその石を置いて、どう流れを制御するか?
流れているモノは何か?そもそもそれがなんで流れる必要があるのか?といったことでは
なくなってしまう。
なので、その流れがあるべきか?とかいった以前に、その流れに「似たような石を置いたら
流れなくなった」みたいなことが多いんだよな。
Re:品質が安定していてうらやましい (スコア:1)
流れなくなったり、流れ方がよくわからなくなったりしますね。
一方で小さな石だとたいした値段をつけられなかったりして。
# yes, fly. no, fry.
Re: (スコア:0)
>仕事に使えるモノという定義が難しいんだよね。
ここがキモだと私は思ってます。
なので、仕事を知っている、あるいは責任をもって回答できる、お客さん側の
最終仕様決定者を決めるとか、言いたくないことを引き出すスキルとか、そう
いった、「客のしたい仕事」ができるシステムを構築できる人をSEと呼びたい
し、育ててほしいと思ってます。
そんな人の1/3くらいは、さっさと独立しちゃうんですけどね。そりゃ、私みた
いなバカな部下がいたら、とてもやってられないだろうし。