BT

プロトタイプを捨てよう

| 作者: Michael Stal フォローする 0 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2012年9月18日. 推定読書時間: 2 分 |

原文(投稿日:2012/09/17)へのリンク

 

Udi Dahan氏は最近のブログ記事「捨てるものを作る」でソフトウェア開発者がよく直面する「ニワトリとタマゴ」の問題について議論している。顧客は必ずしも自分が求めているものを望んでおらず、ソフトウェアエンジニアと密にやりとりする必要がある一方で、このやりとりのために製品レベルのソリューションを構築するのはコストがかかる。Dahan氏はこう語る。

本番環境の上に実際の機能を構築することで、その際に生じる課題やプロセス上の問題について学ぶ、プラットフォームのAPIを改善する、その上にさらなる機能を構築する、これらにはそれぞれ価値はあるのですが、問題は、どんなシステムを作る必要があるかという重要な学びをスローダウンさせてしまうことです。

そこでDahan氏は「捨てるものを作る」ことを勧めている。エンジニアはこうしたプロトタイプのために、TDD、DDD、CQRS、Event Sourcing、SOAなどを使うべきではない。そしてプロトタイプを作るときには、アーキテクトは少なくともアーキテクチャ上、最も重要なユースケースを知り、「辛うじて足りるだけの事前のアーキテクチャ」を構築しなくてはならない。ここで生じる課題のひとつは、組織はプロトタイプと製品レベルのコードとの違いを理解するのが困難だということだ。

Dahan氏はこう結ぶ。

効率性は有効性の次です。ペダルを踏み込む前に、あなたは向かっている方向が正しいか確認する必要があります。改訂することは許容されるべきですし、むしろ快諾されるべきです。

このブログ記事に対して、読者から次のようなコメントが寄せられている。

たとえば、Jonathan Oliver氏は彼の意見に賛同して、こう述べている。

全体的に私も同意見です。特に、効率性よりも有効性だというところは。実際 「7つの習慣」(7 Habits of Highly *Effective* People)の著者、Stephen Covey氏も述べています。本当に必要なのは有効性であるのに、私たちはいかに効率の名のもとに物事を進め、ありとあらゆる問題を引き起こしているのかと。

Jonathan Atting氏はこう語る。

すばらしい記事です。最初のうち、すぐれたプロトタイプはモックアップ言語で作られたものが多いと思います。これだと、このプロトタイプは捨てられるものだ、とみんなわかっているので、もっとすぐれた、もっと根本的な改善提案が得られます。プロトタイプが本物みたいに見えてしまうと、フィードバックはボタンの大きさや位置といったGUIに終始してしまいます。でも結局のところ、ユーザが実環境で使い始めるまで、本当に妥当なフィードバックは得られないでしょう。

Nightwatch氏はプロトタイプにもリスクがあると考えている。

私に言わせると、このアドバイスはかなり危険です。クライアントがワクワクして先に進めようとすると、あなたはすぐにブレークをかけて、こう言うのです。「そう焦らないでください。スクラッチからプログラムを書かなくちゃいけません。4か月で準備できます。それから先へ進みましょう。」 すると、どうなるでしょう。クライアントはあなたのことを、これまでできたものを壊して時間をムダにしている、と思うでしょう。その結果、あなたは彼らを失望させるだけでなく、彼らに要件を変更する時間も与えることになります。最終的にあなたが「製品ソフトウェア」を見せたときには、彼らは別のものを求めているでしょう。

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

作り捨てのソフトウェア? ありえない by j celebpoker

Nightwatch の考えに賛成です。作り捨てのソフトウェアを書くなどバカです。常にリファクタリングされた最善のコードを書いてください。正しく書かれたコードであるなら、さほどの手間がかからず機能、仕様の変更に対応できるはずです。それがたとえ、大幅な方向転換だとしても、同じことです。

そもそも、プロトタイプ、モックアップの段階というのが、私には想像できません。誰が不完全な仕様、不完全なものと分かっててコードを書きたがるのですか? それが完成したら確実に素晴らしい製品になるという確信がなければ、コードを書いてはいけません。モックアップの段階は、グラフィックソフトで完成形を描くところで終わってます。

考えられうる最良の形が決まったところでコードを書きますが、しかし、フィードバックのよって求められるものも変わり、コードも変わるでしょう。それは、受け入れなければいけません。とはいえそれは、最良を追求したから得られるのであって、はじめから作り捨てありきで書かれたソフトウェアでは、良いフィードバックが得らないものと私は考えます。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

1 ディスカッション

特集コンテンツ一覧

.NETの派生を理解する

Wayne Citrin 2018年7月18日 午前3時44分

ASP.NET Core - シンプルの力

Chris Klug 2018年6月4日 午前3時26分

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT