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か月で準備できます。それから先へ進みましょう。」 すると、どうなるでしょう。クライアントはあなたのことを、これまでできたものを壊して時間をムダにしている、と思うでしょう。その結果、あなたは彼らを失望させるだけでなく、彼らに要件を変更する時間も与えることになります。最終的にあなたが「製品ソフトウェア」を見せたときには、彼らは別のものを求めているでしょう。