BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
- Java,
News
品質に交渉の余地はあるか？
作者 Amr Elssamadisy, 翻訳者 沼田 暁子 投稿日 2007年12月18日 午前12時46分
ソフトウェアの品質はどうでもよい、特定の期日までに仕上げなければならない予定された要求（スコープ）がある - 顧客にそう言われたら、あなたはどうするだろうか？顧客の言うことを聞き、品質を犠牲にするだろうか？（そもそも、品質とは何だろうか？）
Simon Baker氏は、顧客の要求(source)には必ず答えるべきなのだろうか？と問いかけている。
もしも顧客が、「完璧なコード」は求めておらず、要求したことを行ってくれる限り品質の低いコードで満足だ、と言ったら、あなたはどうしますか？顧客の要求に応えることが我々の役目ですよね？では、品質については手抜きをしますか？私はそうはしないでしょう。私は顧客が考えていることを理解したいと思うでしょうし、もしそれが、短期的な思惑（「最も費用のかからないソリューションにしたいから品質は気にしない」）あるいは無知や単なる愚かさによるものだということがわかったら、私はほうっておくでしょう。私の良心は、自分の仕事の品質を妥協することを許しません。
また、Yahoo! Groupにあるスクラム（SCRUM）で開発をしている人たちのグループ(source)では、これに関連する議論(source)が行われており、「品質」は交渉の余地があってはならないかどうかが論じられている。この議論は、Pierre Mengal氏の質問に端を発した。
私は、顧客が品質を気にかけないという状況に直面しています。なぜなら、彼にとっては時間の無駄だからです。彼らは納期をずらすことはできず、リソースは増やせず、そしてスコープを縮小することはできません。彼らは、必要があれば、リリースのわずか数ヵ月後にアプリケーションを完全に書き直してもかまわないと思っています。間違いなくこれは、開発コストの問題では全くないのです（彼らは、納期にリリースできないことで、何百万ドルも失う可能性があるのです）。
Esther Derby氏が応えた。
私は、「品質には交渉の余地が無い」という発言に興味があります。
品質は確固とした言葉ではなく、話し合って、共有された明確な定義をしなければならないのです。私にとっては、「交渉して決めた品質のレベルはあきらめない」と言うほうが役に立ちます。
Jerry Weinberg氏は、「品質とはある人にとっての価値である」と言いました。するべき事は、その価値がどこにあるのかを見つけることです。
Jerry氏のQuality Software Managementのシリーズを見てみるのもよいかもしれません。
Kathy Iberle氏も「They Don’t Care about Quality」という素晴らしい論文で、異なるビジネスコンテキストにおける「品質」を論じました。http://www.kiberle.com/2003/STAREast2003.pdf (英語・PDF)
Lance Walton氏は、品質というものの確固とした定義が無いと述べた。
ここで一見して明らかに問題なのは、「品質」がきちんと定義されていない用語だということです。例えば、「品質が悪くてもリリースする」というのが、実際に作業内容を保存しようとするたびにクラッシュするものをリリースすることを意味していたらどうでしょう（クラッシュする前に、実際に作業内容が保存されるのであれば話は違うと思いますが）。あるいは、キーを叩くたびに処理に10秒かかることを意味していたらどうでしょう。「品質が悪くてもリリースする」といった場合、これらは受け入れられるのでしょうか？
Alistair Cockburn氏はこれを説明する例を挙げた。
私は、少し前にA社を訪ねたのですが、A社のソフトウェアは競合のB社のものよりもよく売れていて、B社を倒産に追い込むことができるくらいです。私が話した人はこういっていました。B社の製品は多機能で速く、そしてA社のものよりバグが少ないのですが、B社は、A社のような現場の専門家がサポートする組織を作らなかったのです。
彼らの顧客から見たら、A社の製品はB社のものに比べ、「より高い品質」を備えていたのです。
単にバグを減らし保守性の高いコードを書くだけでは「品質」は実現できません。それでも誰かが買わなければなりません。それを買うと決めることは、「何を品質とみなすか」という尺度です。
「品質」には数えきれない側面があり、それをどの順で評価するのかを十分に話し合わなければなりませんし、そのほぼ全てが必要なのです。倒産したら、「バグがなくて保守性が高い」ことには価値がないのです。
品質に関する別の見方が、Ken Schwaber氏の「Agile Quality : A Canary in a Coal Mine」(source)と題するプレゼンテーションで論じられた。このプレゼンでは、コードの品質は、企業の資産として扱うべきであると提案している。
では、顧客が品質はどうでもよいと言った場合、我々は耳を傾けるべきだろうか？彼らに言われたことをやみくもにやるべきだろうか？それとも、我々はよくわかっているのだから彼らの言うことを無視するべきだろうか？あるいは、他のやり方があるだろうか？最も良いソフトウェアを構築するためには、顧客とどのような会話をするべきなのだろうか？
原文はこちらです：http://www.infoq.com/news/2007/12/4
No comments
返信