実験駆動開発 - ポストアジャイルの手法

原文(投稿日：2010/02/25)へのリンク

TDDとBDDは今や、広く使われているソフトウエア開発技術だ。しかし、単にBDDやTDDに従っているだけではビジネス機会を逸したり、もっと悪いときにはビジネスに悪影響を及ぼしてしまう。TDDとBDDには解決できないふたつの問題がある。すなわち、どのようにして開発したアプリケーションの使用を評価するのか。そして、どうやって顧客からフィードバックを得るか。

ユーザを調査する従来の方法は決して正確な結果にはならない。アプリケーションの提供者も顧客も多大な時間を必要とし、先入観にとらわれてしまう。Nathaniel Talbott氏はRubyConf 2009でのプレゼンテーションで次のような考えを発表した。すなわち、開発時におけるTDDと同じような方法でビジネスもフィードバックを得るべきだ、という考えだ。

(画像はLabnotesから)

ソフトウエア開発の主要な課題は、"無駄を生み出す機械"を開発しないように解決すべき正しい問題を見つけ出すことだ。このためには意見(そしてエゴ)ではなく事実を評価しなくてはならない。そうすれば、開発中のアプリケーションの使用感をより正確に測定できる。

TDDは設計及びコードの検証についての手法だ。一方、EDDは開発の進行方向がビジネスに対して正しく働きかけるかどうかを検証する。

EDDのフレームワークはA/Bテストに基づいている。A/Bテストはもとはマーケティングに用いられる手法で、基準となるサンプルとそこに単一の変更を加えたサンプルを複数用意して両者を比較することで、どちらがより反応を得ることができるのかを調査する方法だ。

Vanity (EDDのフレームワーク)の作者であるAssaf Arkin氏はEDDについて自身の考えを述べている。

EDDは事実に基づいたソフトウエア開発を実現します。EDDが提供するのは、CEOが義理のいとこに語ったおとぎ話に基づいた考えを材料に使うソフトウエア開発手法とは正反対の方法です。EDDはまずアイディアから出発して、そのアイディアを実際の人々に試してもらって評価します。つまり、顧客やウェブサイトにやってきた人、あるいはアイディアを思いついた本人が使うことで、そのアイディアの裏付けや実際の操作感を探るのです。
TDDとBDDはコードの品質を上げ、コードの振る舞いを仕様に確実に適合することを支援するツールを提供してくれますが、EDDはどんな機能をどこに実装すればいいのか見つけるのを支援します。つまり、仕様を発見するのを手助けしてくれるのです。

RailsのプラグインであるVanityを使うと、A/Bテストは次の5つのステップで実行できる。

1. A/Bテストを定義する:

   # experiments/price_options.rb
   ab_test "Price options" do
     description "Mirror, mirror on the wall, who's the better price of all?"
     alternatives 19, 25, 29
     metrics :signup
   end
   

2. ユーザに異なる選択肢を提示する:

   <h2>Get started for only $<%= ab_test :price_options %> a month!</h2>

3. track!メソッドを使ってコンバージョンを測定する:

   class SignupController < ApplicationController
     def signup
       @account = Account.new(params[:account])
       if @account.save
         track! :signup
         redirect_to @acccount
       else
         render action: :offer
       end
     end
   end

4. レポートを生成する:
   (画像はLabnotesから)
5. 収集したデータを検討して各選択肢の性能を評価する:
   (画像はLabnotesから)

InfoQはEDDについて詳細を学ぶためAssaf Arkin氏に話を聞いた。

InfoQ:どのようにしてEDDを思いついたのですか。あなたの新しいプロジェクトApartlyのために、A/Bingoで遊んでいたときに思いついたのですか。それともNathaniel Talbott氏のプレゼンテーションを通してですか。

EDDを考案したのはNathanielで、私はただコーヒーを飲み過ぎていただけです。

RubyConfの数週間前、Nathanielはサンフランシスコに滞在していて、私たちは昼食を共にしました。その前に私はApartlyの実験の準備に取り組んでいたのですが、そのときはA/Bingoをスプリットテストに、Google Analyticsをメトリクスの評価に、データベースをその他の作業にそれぞれ使っていました。

この実験の結果のレポートにはそれぞれ3つの別の場所で生成される画像をつなぎ合わせる必要がありましたが、この作業は簡単ではありません。Google AnalyticsはA/Bテストをサポートしていませんし、A/Bテストの結果をGoogle Analyticsに解析させることもできないからです。また、動作検証のためのコードパスについても同様の問題があります。一体どうやって実験や測定結果を検証すればいいのでしょう。

コーヒーを飲みながら、Nathanielは近々におこなう予定のプレゼンテーションの概要を説明してくれました。その話は私がやったことと似ているようでした。明白な違いは、彼は方法論を持っていて、私はただ悪戦苦闘し閉口していたということです。

彼は本題に入りました。彼の話ではEDDは概念的なフレームワーク、すなわち、実験を通じでコードを構築し測定し精錬することを考える方法だ、ということでした。もし、実際にこういう実験のための大変な作業を肩代わりしてくれるフレームワークがあって、数行で実験用のコードがかけたらどうする?。そう聞かれるとすぐに私の頭の中で“欲しい!”という声が鳴り響きました。

その声が頭の中で鳴り響き続けた結果、私はRubyConf開催までの短い時間の中であるフレームワークを書き上げました。このフレームワークは実用できる最小限の機能を持ち、ある程度のドキュメントもありました。また、実際に数日間使ってみました。それでも、まだ私自身がしっかり使い込んでいないうちから他の人が私のコードを利用し始めるとは思ってもみませんでした。

これがVanity誕生の物語です。

 InfoQ:最近、あなたはどのように開発を進めていますか。テスト駆動ですか。それとも、振る舞い駆動ですか。または、実験駆動ですか。これらの開発方法を利用する割合はプロジェクトの成熟とともに進化していますか。

EDDとTDDを一緒に使っています。どちらか一方だけ利用することは考えられません。

私たち、小さなスタートアップ企業はやりたいことやアイディアはたくさんあります。しかし、これらのアイディアを改善してや完璧な製品や活発な市場を生み出すにはある程度時間がかかります。初期の思いつきの中には正しいことが証明されるものもあるでしょう。また、微調整が必要なアイディアや間違っていたアイディアもあると思います。これはスタートアップの宿命です。資金が尽きる前に完全な製品/市場フィットを見つけられるくらい素早く試行錯誤を繰り返すこと。これが成功の鍵です。

なので、忍者のように素早くコーディングします。最小限の努力で開発することで自分の思いつきやアイディアを検証することができます。

また、“念のため”のシナリオを作り込む時間的余裕はありません。というのも、6ヶ月も経てば間違いなく何らかの方針を変えているはずだからです。それは市場の要請に答えての方針転換であり、不要な機能を急に破棄することもあります。そんなときには作り込まなかったことをありがたく感じます。

また、余計な部分を除去するのも最小限の開発を実現するひとつの側面です。なので、重荷になるようなくずコードや死んでいる機能を支えることはできません。機能追加と同じくらいの素早さで機能の除去も行います。

常に足下を照らしておくことで異なるアイディアを自由に実験できます。悪影響が起こるような結果になりにくいからです。最初からたくさんの機能を作り込んで、それらの機能を長年にわたってメンテナンスするはめになっていなければ、様々な試行錯誤ができます。ある実験の結果がよくなかったら、それはやめて他のことを試せばいいのです。

こうすることでコードの変更が簡単になり、トラブルシュートも楽になり、継続的にデプロイするのに十分な信頼性を確保できます。もちろん、実際には優れたテストスイートの力が必要です。私たちのcode-to-test ratioの値は現在、1:3.4になっています。私たちはユニットテスト、機能テスト、統合テストを継続的に実行していますが、これができるのもAutotestのおかげです。Autotestは“僕のマシンでは動いたよ”バグを取り除くためのビルドサーバであり、配置に関する問題に取り組むためのステージングサーバとしても機能する素晴らしいテストツールです。

このように予防線を張り巡らせておくことで制御できないようなコードが生まれることが防げます。このような予防措置がコードの品質を管理するTDDの役割であり、新しいアイディアを試したり、変更を素早く反映することを支援してくれます。しかし、どのように変更するかについてはどうやって決めればいいのでしょう。こだわる価値のあるアイディアとはどんなものなのでしょうか。

最初は皆思いつきに頼ります。しかし、思いつきだけでは不十分です。ニューヨークタイムズのスタートアップについての記事を読むと、起業家がひとつの優れたアイディア持っていてすぐに大金を手にするというような素敵な話が書いてあります。しかし実際は、起業家たちが数えきれないほどのアイディアを持っていても、そのほとんどは価値がなく、及第なのは数えるほどしかありません。そして、人の記憶に残るのはほんの一握りの優れたアイディアだけです。成功しているスタートアップは市場の声を聞き、数少ない儲かるアイディアを追いかけています。

私たちは反復開発を行っています。しかし、それは新しい機能の実装を完了するためでも実装予定の機能一覧を下へ進めていくためでもありません。そうではなくて、反復開発をすることで何らかのトライアルをして顧客から学習し、その学習結果を次のイテレーションで何をするか決定するために使っています。私たちの前進はEric Ries氏が言う“検証型学習”によって計測されているのです。

顧客はどんな機能に関心があるのか。どんな変更を加えれば満足してもらえるのか。どんな機能が不要で安全に取り除けるのか。同じ事を実現する方法がふたつあるとして、どちらを選択すればいいのか。

EDDはこれらの疑問に答えます。EDDではあるアイディアを実際に製品に反映してみて反応を検証することで、そのアイディアを評価します。EDDとTDDは相互補完的な関係にあります。TDDなしではジャストインタイムの開発や素早いイテレーション、様々な実験を実現できません。一方でEDDなしでは、高品質で堅牢なコードをかけるかもしれませんがだれも相手にしてくれない製品になってしまうかもしれません。EDDが支援してくれるのは素晴らしいソフトウエアに欠かせない隠された要素を発見することです。

InfoQ:EDDはどんな種類のソフトウエア開発にも適用できると思いますか。機能を盛り込みすぎたJavaソリューションやあなたが以前に開発していたIntalionoのようなアプリケーションにも適用できますか。それともアクセスが多いウェブサイトにしか適用できないのでしょうか。

A/Bテストはファンネルサイトやコンバージョン、ランディングページのためのものという印象があります。マーケティング担当は今まで分析やマーケットの分割に静的な手法を用いてきました。そして彼らはウェブの世界にも同じ手法を持ち込みました。しかし、この世界ではA/Bテストやランディングページ最適化について学ぶことは避けられません。

A/Bテストは単なる登録画面以上に意味があります。実際、私たちがウェブサイトから受ける印象はランディングページやマーケティングとは関係がありません。

ソフトウエア開発者としての私たちの仕事は、機能を実装しそれがしっかり動作すること確認する以上のことをしなければなりません。使った人が利益を得られる機能を実装する必要があります。ソフトウエア開発者として、単にビルドするために実装するのか、それとも顧客のために実装するのか。誰もが悩まず使えるコードを欠くのか、それとも多くの人にとって問題になるコードを書いてしまうのか。

私たちの多くは複数のプロジェクトに関わっています。というのもそのようなプロジェクトでは一部のソフトウエアに関する意思決定に対して、完全な責任と権限を持つことができるからです。

Apartlyの開発プロセスについては次の問いで要約できると私は考えています。すなわち、“針が動くか?”

これはどういうことか。私たちには関心のある指標がいくつかあります。例えば、登録 (取得), 招待 (紹介), 購読 (収益)等です。これらが針です。限りあるリソースをやりくりしながら、私たちはこれらの指標を改善しなければならないのです。それはひょっとしたら、登録を増やすことかもしれませんし、再訪問者数を増やしたりすることかもしれません。あるいは、Twitter上で多くの人と交流すれば改善するかもしれません。

この指標はすべての人が見るのではありませんが、開発プロセスには組み込まれています。この指標や実験はコードベースの一部であり、コードと同じようにリポジトリで扱われ、テストと検証が行われます。

実験はテストファースト開発と同じようにまずテストに失敗するコードを書きます。そしてそのコードをテストに成功するようにするため、指標の基準となる値を考慮しながら、その指標を好ましい方向へ動かしてくれるコードを書きます(多くの場合は上がればいいのですが、WTFs/mのように下がったほうがいい指標もあります)。

トラフィックの多いウェブサイト以外にこのEDDを適用できるのでしょうか。差異がわかる指標はどこにもあります。例えば、同期処理の通信をメッセージキューに置き換えたら応答時間は改善するでしょうか。負荷が高いときにサーバが動かなくなる回数が減りますか。新しいサービスは簡単に配置できるようになるでしょうか。要するに、置き換える前と後で何らかの計測できる効果があるのか、それとも理論上良さそうに見える無駄な努力なのか。

結果を計測する方法を持っていないときに何が起きるのか。さまざまな問題が関心の対象になりたくさんの開発が始まります。そして、これらの開発が無駄であるという証明をする手段がないので開発は継続します。結果、サンクコストを背負うことになります。何らかの指標を導入すれば、何を関心の対象にするのかが変わります。差異がわかるので関心の対象がはっきりします。

NathanielのEDDフレームワークに対する要求リストの2番目にあったのは、“すべてのレベルにアクセスできること”というものです。これは、ユーザインターフェイスだけではなく、対象のソフトウエアスタックのすべてのレイヤを計測できるようにしたい、ということです。この場合、すべてのコンポーネントに自身の価値を表明することに責任を持たせる必要があります。

InfoQ: TDDやBDDはROIを測定するのが難しいです。測定できたとしてもすぐに結果はわかりません(まちがいなくリアルタイムでは不可能です)。このため、結局マネージャや意思決定者い対してTDDやBDDの利点を理解させるのは大変です。開発の方向性と定量化可能なデータを提供するEDDはマネージャのお気に入りになれるでしょうか。

残念ですが、EDDで開発しても尖った髪のボスの尖り具合は和らぎませんし、髪の量も少なくなりませんし、ボス特有の不快さも変わりません。

IT部門、ひいてはビジネスソフトの開発会社はユーザのIT環境に対して独占的な影響力を持っています。ユーザのいうことに耳を傾ける必要がないとき、顧客との間にある種の関係が生まれます。つまり、お金をくれる人が現れます。こうなると顧客はいつも正しく、自分たちが認めていない変更が行われることを許しません。なので顧客は開発ロードマップを見たがり、0%から100%までの進捗を確認したがります。古典的なウォーターフォール開発になってしまいます。

反対に自分のソフトウエアをユーザに強制するような贅沢にありつけない会社やプロジェクトで仕事をする場合は、ユーザの機嫌を伺い、楽しませ、ある意味ではその人生をより良くしなければなりません。この場合成功は、単年度でどのくらいの機能を実装したのかではなく、何人のユーザを納得させ味方にしたのかで計測されます。

実装した機能で成功したかどうかを測定するなら注意深くひいたガントチャートが案内役になるでしょう。これを拡大コピーしてオフィスの一番大きい壁に貼付ければいいのです。では、顧客の喜びで成功を計測しようとしたらどうすればいいのか。マーケティング担当が経営陣向けに配布する四半期報告書を全社向けに公開する絵馬で待てばいいのでしょうか。しかし、それでは実装し公開してからフィードバックを得るまでに3ヶ月もかかります。

ロールプレイをすることで利用するユーザの典型を作り出し、この典型を想定してソフトウエアを設計する企業もあります。また、いわゆる“eat your own dog food”を実践して、自分たちが内部で使っているソフトウエアを開発する会社もあります。しかし、売りたいソフトウエアがソフトウエア開発者を対象にしたものではない場合はどうでしょう。

もし、ソフトウエアがどのように評価されるのか知りたければ、コード行数でそのソフトウエアの生産性を計ることが無駄であるということを理解しなければなりません。機能やストーリーポイントで生産性を計るのも得策ではありません。どちらの場合も二次的な効果を測定しているにすぎないからです。生産性を測定してもなにもわかりません。

その代わりに最も関心の対象になるビジネス上の指標を取り上げるのです。Dave McClure氏が“海賊のメトリクス”と呼ぶ指標には、訪問、活性化、再訪問、他者への紹介、収益化の5つがあります。会社の中で一番頭のいい連中にこれらの指標を改善する方策を考えさせるのです。この中には開発者も含まれます。

そして、単にビジネスから定量化可能なデータを取得するだけではなく、そのデータがマーケティング担当から開発マネージャへ、そしてチームリーダへ落ちてきたときには、前線に開発者を配置して各種指標を考慮しながら、ビジネス上のゴールがどこにあるのか測定します。

私はEDDを“ポストアジャイル”と呼んでいます。EDDはアジャイルの素晴らしい基盤の上に構築されていますが、“ソフトウエアが動くかどうかで成功を計測する”という考えから“検証型学習と鍵となる指標で成功を計る”という考えに移行しています。TDDがアジャイルであるようにEDDはポストアジャイルなのです。

数年内にEDDは主流になるだろうか。明らかな利点を生み出すだろうか。それとも単なるもうひとつの*DDで終わってしまうだろうか。あなたはどうお考えだろうか。