読者です 読者をやめる 読者になる 読者になる

デザインダイアローグコペンハーゲン

デンマークのコペンハーゲンでのデザイン留学の日々について書いています

Test Early and Fail Fastとは言うものの

デザインの世界に限らず、エンジニアリングの世界だとか、ビジネスの世界でもそうですが「Test Early and Fail Fast」という考え方があります。これは、早い段階でテストを行って、早い段階で失敗しましょうという意味です。Test Early, Fail Oftenだとか、Test Early, Fail Fast, Learn Cheaplyのような派生系もあるようですが、基本的には同じような意味だと考えて良いのかなと思います。

多くのプロジェクトにおいて、失敗はつきものです。しかしながら失敗を修正するコストというのは、プロジェクトが進むにつれて大きくなります。例えば、私の元々の専門はコンピュータサイエンスですので、ソフトウェア・エンジニアリングの世界から例を持って来ます。

www.atmarkit.co.jp

上記のサイトに有るように、設計段階で早期にバグを見つける事ができれば、修正コストは小さくなるが、運用後にバグが発覚してしまうと、多大な修正コストが必要になリます。このような修正コストを最低限に抑えるためには、早い段階でバグを見つけて修正する事が必要になるわけですが、そのために必要なのが、テスト、というわけです。

デザインの領域では、ソフトウェア開発プロセス(特にウォーターフォール)のように、設計や実装のように明確にフェーズが別れておらず、Low Fidelityなプロトタイプを作ってテストして、Mid Fidelityなプロトタイプを作ってはテストして仮説を検証していくというプロセスを取る事が多いですが、結局これもプロジェクトの軌道修正コストを最小限に抑え、結果としてプロジェクトを早く前に進める為です。

これをグラフにしてみると下記のような感じなのかなと思います。

f:id:mikio-k:20160508073217p:plain

これはプロジェクトの進行具合によって、忠実度と、確実性がどのように変化させていくべきかを示したものです。最初は、何もアイディアがないわけですから、忠実度も確実性もゼロですが、プロジェクトが進むにつれて、忠実度や確実性が増していき、右上に到達するとプロジェクト完了です。

そしてもちろん自分たちの仮説が間違って居る場合というのが当然あるわけですから、そういった際には手戻りが発生します。そこで大きな手戻りが発生しないように、適切なタイミングでテストを行っていく必要があります。

しかし、ここで注意しなければならないことがあります。テストを行うのはタダではないと言うこと。確かにソフトウェア開発であればCIと呼ばれる仕組みを使う事によって、テストを行うコストが非常に小さくなっているのは事実ですが、デザイン分野で言うテストを行うためにはプロトタイプを作って、ユーザーにインタビューを行ったりするわけですが、これらにはそれなりのコストがかかるわけですね。

つまり、確実に一歩一歩テストして確実性を高めていくのが手戻りコストを最小化するためには効いてくるけれども、それではテストのコストが増大してしまうので現実的ではありません。プロジェクト全体で、手戻りのコストと、仮説検証のコストを最小化する事が、プロジェクトのスピードを早め、コストを下げるために必要です。そのため、それぞれのコストを最小化出来るような最適なバッチサイズを見極めてプロジェクトの計画を進めていく必要があります。

では、それにはどうすれば良いのか。それは忠実度を上げる前に、自分たちが検証したいポイントは何で、それを確認するために必要な忠実度はどの程度必要なのかを明確にする必要があるのかな、と思います。

例えば、スマホアプリであればペーパープロトタイプなどを用いて仮説検証を行う場合がありますが、そのペーパープロトタイプを作る前に、自分たちのアイディアの確実性が足らない場所はどこで、どういったものがあればそれを検証出来るのかを検討するわけです。こうすることで、闇雲にテストを行うのではなく、最小の手数でクオリティを上げていくことが出来るのだろうと思います。とはいえ、頭ではわかって居ても実際には中々難しいのですが。