「いかに作らないか」が考え抜かれた機能開発を。

機能要件を網羅しようとする機能開発は効率が良くないなあと、つくづく感じています。

ソフトウェアプロダクトの機能開発では、作り上げた機能がリリースされてユーザーに使われ始めるまでは、そのユーザー価値を正しく評価することができません。つまり、開発中は正しいゴールの場所がわからない。おおよそゴールだと信じる場所に向い、リリースするその日まで、ただひたすらに真っ直ぐ突き進んでいるようなものです。

はじめに目星を付けた方角に正しいゴールがあれば良いのですが、そうでなかった場合、その角度の僅かな誤差は、走った距離が長くなるほど大きなギャップとなって現れます。

私はここに、機能要件を網羅しようとする機能開発の非効率さを感じるのです。なぜなら、機能要件を網羅すると、必然的に開発規模が大きくなる。規模が大きくなる分、リリース後に大きなギャップを生じさせやすいからです。

ならばむしろ、機能要件を網羅しない方が良い。最小限の機能要件セットを満たす小さくシンプルな機能を短期間でリリースする。これを何度も繰り返すやり方の方が効率的です。リリースするたびにユーザーのフィードバックを受け、小刻みに軌道修正しながら、正しいゴールに向かえば良いからです。

「なんだ、単にアジャイルの話じゃないか」という声がきこえてきそうですが、いやその通り。目新しい話は何もしていない。

ではなぜ、機能要件を網羅しようとするのでしょうか。それは、「優れたユーザー体験をカタチにしなければならない」という、作り手の想いにあると考えています。リリースした機能に、ユーザー体験上の考慮漏れや、使いづらい箇所があってはならない、という具合に。

この強い想いは強迫観念となって、作り手に多大なプレッシャーを背負わせることとなります。

かくして、「優れたユーザー体験」を導き出そうと、徹底的な分析が進められます。時間をかけて綿密に分析するほどに、あれもこれもと機能要件が洗い出され、継ぎ足されていく。こうして、網羅的な機能要件ができあがります。

さて、この機能網羅型アプローチは、「優れたユーザー体験をカタチにしなければならない」という信念を行動原理としています。機能要件を網羅することで、作り上げようとする機能のユーザー価値を、リリースに先だって「保証」しようとしているのです。

しかし、冒頭で話した理由により、リリース前にユーザー価値を保証することはできません。ユーザーに触れられるまでは、機能の価値を正しく評価できないからです。

このように、機能網羅型アプローチは矛盾を抱えています。

機能のユーザー価値をリリース前に保証できないのなら、素直にその前提に立ったアプローチとする方が自然です。リリース前にユーザー価値を保証するために機能要件を網羅するのではなく、リリースしてユーザー価値を検証するために機能要件を厳選して開発する。

ここで作り上げられる機能は、仮説となるユーザー価値を検証するための最小限の機能要件のセットです。これにより機能開発は、短期間でのリリースを繰り返すプロセスに生まれ変わります。リリースするたびに細かく軌道修正しながら、正しいゴールに向かうことが可能になるということです。

重要なポイントは、仮説となるユーザー価値の検証に必要ない機能要件を思い切って排除すること。それが、「いかに作らないか」を考え抜いた機能開発です。