アジャイル開発者の責任

作者 Amr Elssamadisy , 翻訳者 編集部 投稿日 2008年1月25日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Delivering Quality ,

Agile ,

Delivering Value

タグ

品質

顧客が間に合わせのソリューションを求める場合、開発者の責任は何か? 結局は顧客が支払いをするのだから、顧客の言うことを聞いて近道をすべきか? それとも、開発者は自分の考えで技術的に「最適な」選択肢であることを常に行うべきか? それとも、中間の妥協点があるだろうか?

James Shore氏は、「Our Professional Responsibility(source)」で、顧客/開発者のバランスに関する簡単な歴史を紹介している。

^{*ウォーターフォール開発の古き悪しき時代には、プログラマは、要件を理解し、デザインを作成し、技術的に最も便利な方法でデザインを実装していました。プログラマは王でした。プランは完全にプログラマによって作成されていました。または、プログラマの上司が締め切りを設定し (おそらく、政治的圧力、またはJoltを伴う週末にプログラムできたことについての美化された思い出がその動機となっている)、プログラマはその締め切りに間に合わせるように急いでいました。*}

 *はい、私は複雑な状況を単純化しすぎています。私は許可されています。

アジャイル開発はこれに対して、「おい、ちょっと待って! これはうまくいかないだろう! 顧客に価値を提供していないではないか」と反応しました。プランニングゲームはバランスを均衡に戻します。顧客は価値を任され、プログラマはコストを任されます。

一部のアジャイルチームは、極端に振り子を振りすぎています。彼らは責任を放棄して、「顧客が仕切っている! 我々は顧客が言うことなら何でもやらなければならない」と言っています。

それは行き過ぎです。

彼の意見では、開発者は仕切るべきではないが、それと同時に、品質コードの開発に責任がある。常に。

そして、「近道してこれをもっと速く終わらせることができませんか?」と言われたとき、相手の目をまっすぐ見つめて「ノー」と言います。「いいえ、スケジュールに影響を与えずにそうすることはできません。しかし、もっと速く終わらせることができるように機能を単純化する方法を見つけるお手伝いはできます。」

Reg Braithwaite氏は、「What I admire about professions like Engineering and Medicine(source)」で、時には、顧客が間に合わせのソリューションを望む場合にその顧客の言うことを聞くのは悪い考えではないかもしれないと示唆している。

今、私は、保守が困難になる間に合わせのコードを適当に作り上げることを命じられたときにそれを拒否すべきだということに同意しません。それが良い考えかどうかは各自の判断です。私は、クライアントや雇用主との関係の制約の中で方法を知っているように手際よくソフトウェアを記述することを選びます。私は、その件について強く私の判断を奨励することを選びます。

しかし私は、雇用主やクライアントに強く求められたときに、そうすることを徹底して拒否する権利があるとは思いません。彼らが保守困難なソフトウェアという結果に苦しむため、彼らだけにその件についての最終決定権があります。

彼が境界線を引く場所は、品質ではなく、倫理である。

ソフトウェア開発の場合では、安全性が低くてプライベートユーザーデータを危険にさらすソフトウェアを開発するように頼まれた場合、私はノーと言うことを個人的に選ぶでしょう。

もちろん、私は法の保護を受けていません。そうすることで首になるなら、頼れるものはありません。私は失業手当を受け取ることすらできず、正当な理由によって解雇されたと見なされるでしょう。プログラマは思いのままに仕事をしています。つまり、そのために自分の生活を危険にさらすならば、あなたは倫理を非常に高く評価している(source)ということです。

Robert Martin氏 (Uncle Bob) は、「Business software is Messy and Ugly(source)」で、間に合わせのソリューションは誤った結果であると示唆している。彼のクライアントのマネージャの1人による「Business software is messy and ugly (ビジネスソフトウェアは繁雑で厄介だ)」という言葉を引用し、次のように応えている。

いいえ、それはそうではありません! ルールは複雑で、独断的で、特別なものにできますが、コードは繁雑で厄介なものにする必要はありません。実際には、ビジネスルールがより独断的で、複雑で、特別になるほど、コードをクリーンにする必要があります。別の繁雑さに抑制されている場合、ルールの繁雑さを管理することはできません! 繁雑なルールを管理する唯一の方法は、それらを最もクリーンでクリアなコードで表現することです。by another mess! The only way to get a handle on the messy rules is to express them in the cleanest and clearest code you can.

最後に、以前のInfoQの記事「Refactoring is a Necessary Waste(source)」では、ユーザーコメントの多くが、コードのリファクタリングに時間をつぎ込む時期とそうすべきでない時期についての意見だった。

開発者の真の責任についてあなたはどのように考えるか? 近道の話になったら、ノーとはっきり言うべきか? 顧客の要求を聞くべきか? それとも、柔軟ながらも顧客に影響を与えることに突き進み、価値と倫理を固守するべきか?

原文はこちらです：http://www.infoq.com/news/2008/01/developer-responsibility

• 次へ >