プロダクトに備わる機能の64%がほとんど使われないと言う。あるいは、80%という数字が用いられることもある。これが本当だとすれば、ソフトウェア開発に費やしたコストの多くが無駄だったことになる。ソフトウェア開発は常にスピードが求められるものだが、そもそもこのような無駄がなければ、ユーザーや顧客への価値の提供をもっと速くできたはずだ。
ソフトウェプロダクトをローンチし、それから次々とリリースを繰り返しながら追加されていった変更は、いったいどれだけのものが実際に価値があったのだろうか。本稿では、Standish Groupやマイクロソフトの文献を中心に、ヒントとなる数字をいくつか紹介し、その理解を深める。
64%はめったに、あるいはまったく使われない
まずは「64%」という数字の出典であるが、2002年5月に地中海のサルデーニャ島で開催された "The XP 2002 Conference" にまでさかのぼることになる。Standish Groupの創設者であり会長のジム・ジョンソン（Jim Johnson）による基調講演 "ROI, It's Your Job" の中で紹介されたものだ。この時の様子は、マーティン・ファウラー（Martin Fowler）がレポートしている。
原典となる公演資料が手元にないのだが、ジム・ジョンソンが提示したデータはStandish Groupによる調査で得られた結果であり、次の円グラフにある通りだ。ソフトウェアプロダクトが備える機能それぞれの使用頻度を調査している。ここで、「まったく使わない（Never）」とされた45%の機能と、「めったに使わない（Rarely）」の19%を足し合わせたものが、例の「64%」である。
「いつも使う（Always）」と「よく使う（Often）」を合わせてもたった20%であり、さらに「時々使う（Sometimes）」を合わせても36%だ。ジム・ジョンソンが同講演において合わせて引用したDuPontによる「機能の25%だけが実際に必要」という研究結果をみても、惨憺たるものだ。
マーティン・ファウラーは、提示されたこれらのデータがソフトウェアエンジニアとしての経験と合致すると感じたようだ。それについては、次のように述べられていることから分かる。
This certainly fits the anecdotal evidence of many agilists who feel that traditional approaches to requirements gathering end up gathering way more requirements than are really needed to a usable version of a release.
確かにこれは、要件収集に対する従来のアプローチにおいて、リリースするバージョンに本来必要な要件より多くの要件を集めてしまうと感じている多くのアジリストの事例証拠と一致する。
おそらく、ジム・ジョンソンが公開したStandish Groupの調査結果を知った多くのソフトウェアエンジニアが、マーティン・ファウラーと同様に感じたのではないだろうか。そうであるからこそ、この調査結果は数多くの文書で引用されることとなったのだろう。
しかしながら、Standish Groupによる調査結果を信頼する上で、その調査の詳細がどのようなものであったかが気になるところだ。その答えとなる情報は、私の知る範囲で2つある。
1つめは、書籍『アジャイルな見積りと計画づくり』などの著者であるマイク・コーン（Mike Cohn）による2015年のブログ記事 "Are 64% of Features Really Rarely or Never Used?" だ。彼は、Standish Groupに連絡を取り、この調査が4つの企業の4つの社内アプリケーションを対象にした調査であることを聞き出した。たった4つの、しかも社内での開発プロジェクトのみを扱ったデータであることから、この調査結果は一般化できないというのが、彼の主張だ。
2つめは、Standish Group自身によって2010年頃に公開された "MODERNIZATION - CLEARING A PATHWAY TO SUCCESS" というレポートだ。そこでは、100のカスタム開発アプリケーションを対象とした調査に基づいていると説明されている。1996年に行われたユーザーワークショップによって得られた結果のようだ。
たった4つのアプリケーションなのか、100のアプリケーションなのか。どう解釈すれば良いのか分からないが、後者について書かれたレポート "MODERNIZATION ~" には続きがある。それが「80%」に関する説明だ。
80%は価値が低い、あるいはまったくない
「80%」の出典もまたStandish Groupのレポートであり、最近の同社のレポートでは、「64%」ではなく、「80%」が使われるようになっている（私が知る限り、少なくとも2014年のレポートまでは）。
Standish Group research shows that 80% of features and functions have low to no value.
Standish Groupの調査によると、機能やフィーチャの80％は、価値が低い、あるいはまったくないことを示している。
先述した2010年のレポート "MODERNIZATION ~" によると、これは、1996年の調査で64%という結果を得て以降、数年ごとに繰り返し実施された調査で得た結論のようだ。その数年にわたる調査では、ほとんどのメソドロジー（methodology, おそらくソフトウェア開発方法論のこと）において、調査のたびに結果が大きく変動するようなことがなかったと言う。
Using some automated tools and spot checks every couple of years, we found, to no surprise, that the numbers are relatively unchanged for most methodologies.
いくつかの自動ツールを使い、数年ごとにスポットでチェックしたところ、やはり、ほとんどのメソドロジーにおいて、数値が比較的に変化しないことがわかった。
そして、下の円グラフで表される結論に至ったのだ。それが、「めったにない（Hardly Ever）」「まれ（Infrequently）」を合わせて80%という数字だ。
これらのことから、「80%」という数字は、Standish Groupによる「64%」という調査結果を経た上でのより新しい、アップデートされた結論であることが分かる。
それでは「機能やフィーチャの80％は、価値が低い、あるいはまったくない」と言い切ってしまえるかと問われると、少々ためらうところもある。単純に、調査内容について詳細が分からないことが原因だ。それは主に3つある。
1つめは、この調査で扱われたソフトウェアに、商用などの社外向けアプリケーションが含まれていたのかどうかだ。マイク・コーンが言うような、社内アプリケーション向けの社内プロジェクトだけを対象とした調査であるなら、社外向けアプリケーションでの状況は異なるかもしれない。
2つめは、どんな機能を対象とした調査だったかだ。めったに使わない機能であっても、必要なものはある。例えば、ユーザーが自身の登録情報を変更する機能がそれにあたるだろう。こういった機能は、調査でどう扱われたのだろうか。
3つめは、現在も継続して調査が行われているのかどうかだ。ソフトウェアを取り巻く環境は大きく変化し続けている。Standish Groupの結論は、2010年以前に出されたものだ。その後も状況に変化がないのだろうか。
もちろん、Standish Groupの調査についてもう少し調べていけば、これらに関する解答が得られるのかもしれない。しかし、いまのところ、これ以上の情報を見つけられていない。それでも有用なデータだとは思うが、自戒を込めて言えば、共感できる数字だけに、このままでは確証バイアス的に利用してしまいやすい。
そもそも、先ほど2つめの原因として挙げた通り、機能の価値と使用頻度が一致するとは思えない。あるタスクを処理するために、ユーザーが毎日使わなければならない機能と、ほとんど何もしなくても処理してくれる機能では、ユーザーにとってどちらがより価値が高いだろうか。使用頻度は、ソフトウェアに加えた新機能や改善を評価する上であまり意味がないのかもしれない。
そのような理由から、Standish Groupの調査結果は有用なデータのひとつとして参考にしながらも、より「価値」というものに焦点をあてた情報の必要性を私は感じていた。
3分の2は価値がない、あるいは逆に価値を損なわせる
最近、マイクロソフトのオンライン実験に関する論文を2つ読んだ。きっかけは、デイビッド・ファーリー（David Farley）の著書『継続的デリバリのソフトウェア工学』の7章にある次の一文だった。
機能は開発チームが役に立つと考えたから作られているのだが、多くのドメインでほとんどのアイデアが重要指標を改善できていない。Microsoftでテストされたアイデアのうち、改善されたのは1/3だけだった。
ここで注目すべきは、リリースされた機能を「重要指標」で評価しているという点だ。それがビジネス価値を計測する指標であるか、ユーザー価値を計測しようとする指標であるかは場合によるだろうが、「1/3」という数字は、そういった「価値」として定義した指標をもとにアイデアを評価したものである点が良い。
私自身が関わるソフトウェアプロダクト開発でも、リリースされた機能や改善は、すべてではないが、A/Bテストなどを通し、KGI（Key Goal Indicator, 重要目標評価指標）やOEC(Overall Evaluation Criterion, 総合評価基準）を構成するKPI（Key Performance Indicator, 重要業績評価指標）に関連付けて評価されている。それらのデータを過去に遡って集計すれば、上述のような統計データも得られるだろう。しかし、こういった手持ちのデータだけを見ていても、自分たちが上手くやれているのかどうなのか分からない。たった1人しか受験しない大学入試模擬試験が役に立たないことと同じだ。自分たち以外のデータもあってこそ、相対的なものさしを手に入れ、改善の要否なども見えてくる。そういった点において、上述のようなマイクロソフトの調査結果があるのはありがたい。
本題に戻るが、『継続的デリバリのソフトウェア工学』での先の引用もととなった参考文献は、マイクロソフトの "Online Controlled Experiments at Large Scale" という2013年の論文だ。内容としては、A/Bテストのような「対照実験（controlled experiment, control experiment）」における実験回数のスケーリングに焦点があてられている。これはこれで興味深い内容だったのだが、本稿とはテーマが異なる。
同論文内で参考文献に挙げられていたマイクロソフトの2009年の論文 "Online Experimentation at Microsoft" に、興味深い統計データがいくつか書かれていた。マイクロソフト社内でのBingなどのプロダクトに関する対照実験のデータだ。先述の「1/3」もここからの引用らしく、この論文内では次のように書かれている。
Evaluating well-designed and executed experiments that were designed to improve a key metric, only about one-third were successful at improving the key metric!
主要な指標を改善するよう適切に設計され、実施された実験を評価すると、それに成功したのはわずか1/3程度だった！
~ ~
Stopping the launch saves the company money and avoids hurting the user experience. As humbling as it may be, this represents about one third of experiments.
ローンチを中止することで経費を節約し、ユーザー体験を損わずに済む。控えめに言っても、これは実験のおよそ1/3に相当する。
~ ~
While it is expensive to experiment, it is more expensive to continue developing and supporting features that are not improving the metrics they were supposed to improve, or hurting them, and at Microsoft, these two cases account for 66% of experiments.
実験にはコストがかかる。しかし、指標を改善しない機能や指標を悪化させる機能を、開発したりサポートしたりし続けるのは、もっとコストがかかる。そしてマイクロソフトでは、これら2つのケースが実験の66％を占めている。
つまり、マイクロソフトの実験では、アイデアの1/3は価値があるが、2/3は価値がないか、逆に価値を損なわせると言うのだ。アイデアの良し悪しに対する人間の感覚がどれだけ信用できないものであるかが、この結果からよくわかる。
もちろんこの数字も、同社のプロダクトに対する数多くの変更を母集団と考えた場合に、実験対象となった変更の集合に標本として偏りがあるかもしれない。実施された対照実験の多くが、実験しやすい変更に対するものだったかもしれないからだ。それに、これはマイクロソフトに閉じた結果でもある。発表されたのも2009年であり、同社の2013年の論文でも引用されているとは言え、やはり少々古い。
しかし、アイデアの価値を対照実験を通して評価するという点で言えば、私が関わるプロダクト開発でも条件は同じだ。その点で、このマイクロソフトの数字は、自分たちの現状と比較するデータとして参考にできそうだ。
「勝利宣言」からの脱却
先のマイクロソフトの論文では、同社以外の数字についても紹介されている。例えば、Netflixでは、自分たちのアイデアの90%が間違っていると考えているようだ。Amazonでは、すべての新機能を評価することが当たり前であり、その成功率は50％を下回っているとされている。また、ソフトウェア産業におけるアイデアの成功率は、対照実験によって科学的に評価した場合、50％以下であるという報告で溢れていると言う。
これらのことから、人間は基本的に、成功するアイデアと失敗するアイデアを見分けることが得意ではないということがよくわかる。長年、ソフトウェアプロダクト開発に携わっていれば、これに頷ける。プロダクトのアップデートを何度繰り返しても重要指標が一向に改善されないことや、自信を持ってローンチした新機能がほとんど使われないといった経験を重ねてきただろう。だからこそ、Standish Groupのデータにも共感するのだ。
優れていると信じるアイデアをローンチできただけで、ユーザーやビジネスに価値を付加できたと確信してしまっていないだろうか。ジョナサン・ラスムッソンの著書『ユニコーン企業のひみつ』では、これを否定的に「勝利宣言」と呼んだ。そのアイデアが成功を導くと信じ込んでしまい、実際に価値を提供できたのかどうかを検証せず、フィードバックによる学習を放棄しているからだ。
勝利宣言するタイプの開発組織では、成功を信じるあまり、ひとつのアイデアに対する開発規模が大きくなる傾向があるのではないだろうか。確実に勝利を手にするために、時間をかけて分析し、必要な機能を網羅しようとするからだ。無駄になるかもしれないという考えがそこにはない。
スティーブ・マコネル（Steve McConnell）によれば、要求の間違いをリリース後に修正するコストは、要求段階で修正することに比べ10倍から100倍かかると言う。そうであるなら、成功するか失敗するかを見分けられないはずのアイデアの開発規模を、はじめから大きくしてしまうことは無駄だとわかる。
ソフトウェアプロダクト開発は、クネビンフレームワークで言うところの「複雑（Complex）」な領域にマッピングされるものだ。予測可能性が低く、 分析だけで正しい答えを得ることはできない。探索が必要なのだ。だからこそ実験する。すなわち、仮説と検証を繰り返す。解決すべきは不確実性であり、それが、フィードバックループを形成するインクリメンタルな開発の意義なのだろう - Experiment or Die！
