想像してみてください。UI/UXデザイナーとして1か月かけてステークホルダーの意見を集め、問題領域を整理し、完璧だと思える要件一式をまとめ上げた矢先に、要件が変わったと告げられる。次もまた変わるのかわからないまま、一からやり直しです。その間、何も作られません。ユーザーは何も目にせず、誰も何も学びません。
これが要件駆動開発の実態であり、根本的に破綻しています。チームは実験し、学び、改善を重ねることよりも、仕様を完璧にすることに不釣り合いなほどの時間を費やしています。Jeff GothelfとJosh SeidenがLean UXで論じているように、厳格な要件へのこだわりは市場機会の逸失やリリースの遅れにつながります。しかし、問題はもっと根深いところにあります。実装された要件であっても、ユーザーテストの対象であることに変わりはなく、ユーザーが難色を示せば、結局は要件が変わります。つまり、要件ははじめから事実ではなかったのです。形式ばった言葉をまとった仮説にすぎませんでした。違いは、要件が網羅性と「確実である」という錯覚を優先するのに対し、仮説は学びを優先するという点にあります。
仮説を立て、学び、改善する
このことに正直に向き合う組織は、競争上の優位を得ます。その最もわかりやすい例がAmazonです。Amazonのチームは、要件定義書ではなく架空のプレスリリースから出発する「ワーキング・バックワーズ」で仕事を進めます。何を作るべきかを理解する最善の方法は、事前に仕様を固めることではなく、それがリリースされた姿を思い描くことだと知っているからです。本番環境へのデプロイは毎秒行われており、学習のループは非常に短く、あらゆる実験が現実のシグナルを生み出しています。
プロセスのレベルでは、BasecampのShape Upという方法論が、同じ主張をより具体的に示しています。スコープが既知であることを前提とした「これにはどれくらい時間がかかるか?」という問いの代わりに、チームは「このアイデアにはどれだけの価値があるか?」と問います。Shape Upで「アペタイト」と呼ばれるこの時間予算が、何を作るかを形づくるのであって、その逆ではありません。スコープは意図的に可変のままにされるため、チームは決められた仕様をただ実行するのではなく、トレードオフを判断しながら本当に重要なことを見つけていきます。その結果、仮説は、チームが守り続ける文書に前もって詰め込まれるのではなく、開発サイクルそのものの中で継続的に検証されることになります。
この転換を進めるのに、いまほどの好機はありません。かつては、要件を重視することにもコスト面である程度の合理性がありました。プロトタイピングには時間がかかり、開発は高くつき、間違いを取り消すのは大変でした。だからチームは、開発に着手する前に、考えるべきことを仕様に前倒しで詰め込んでいたのです。その計算はもう成り立ちません。AIによってプロトタイピングは速くなり、実験は安価になりました。ボトルネックはもはや実行ではなく、思考の質です。いまだに要件定義書に何週間も費やしているチームは、もう存在しない制約に向けて最適化しているのです。
緊張が最も表れる場所:日本の中小企業
チームがこの転換をどれだけ容易に行えるかは、組織文化によって左右されます。そして、その緊張関係を日本の中小企業ほど鮮明に示す例は多くありません。
合意形成を重んじる意思決定は、日本の職場文化に深く根づいています。実際には、どんなアイデアも前に進む前に、何層もの議論と承認を経る必要があるのが一般的です。プロダクト開発への影響は予想どおりです。網羅的な要件は、一種の組織的な防御策になります。詳細な仕様書は単なる計画のためのツールではなく、十分な検討がなされ、リスクが考慮され、誰も独断で動かなかったことの証拠なのです。このプロセスから外れることは、非効率であるだけでなく、文化的にふさわしくないことのように感じられます。
私は日本の中小企業で働く中で、これを直接経験しました。デザインの依頼は、ユーザーリサーチからではなく営業チームや経営層から届くことが多く、デザイナーの手元に届くまでに何層もの解釈を経ていました。「要件」が私の机に届く頃には、すでに議論され、調整され、合意の判が押されていることが多く、それに疑問を呈するのは、閉じた扉をもう一度開けるようなものでした。その結果、プロセスはユーザーから学ぶことではなく、社内の足並みをそろえることに最適化されていたのです。
だからこそ、仮説ファーストのアプローチは、魅力的であるだけでなく必要なものになります。要件がリサーチではなく営業チームから生まれるのであれば、それはすでに仮説です。ただ、そう認められていないだけです。その事実を正直に明示すると、会話が変わります。「要件は正しかったか?」と問う代わりに、チームは「何を学び、次に何をするか?」を問い始めます。これは、デザインへの理解度にかかわらず、どのステークホルダーも参加できる問いです。
日本の中小企業におけるもう一つの構造的な現実は、専任のUX部門がめったにないことです。リサーチャーもストラテジストもおらず、アイデアが仕様になる前にそれを検証することを仕事とする人がいない、ということがよくあります。その空白の中では、仮説ファーストのモデルは方法論の選択ではなく、生き残るためのスキルです。小さく安価な実験が、大きな組織であれば正式なリサーチが担う役割を果たし、しかもそれをより速くこなします。
AIツールのおかげで実験のコストが劇的に下がったいま、要件を前倒しで固めることを正当化していた実務上の障壁は、ほぼ消えました。文化的な障壁は残っていますが、乗り越えられないものではありません。転換は、自分たちの要件が常に仮説だったとチームが認識したときに始まります。残る問いは、その仮説を何かを作る前に検証するのか、作った後に検証するのか、だけです。
価値のある転換
要件と仮説は、私たちが教わってきたほど違うものではありません。どちらも、何を作るべきかについてのチームの現時点での最善の理解を表しています。違いは、正直さとスピードです。 最善の考えを要件ではなく仮説として扱っても、プロセスが弱まるわけではありません。むしろ、仕様が間違っていたと認める心理的な重荷を背負うことなく、チームはより早く検証し、より速く学び、方向を変えられるようになります。仕様を修正しているのではなく、理解を更新しているのです。合意を重んじる文化では特に、この捉え直しが重要です。失敗のように感じられかねないものを、その本当の姿、つまり前進へと変えてくれるからです。 実験を速く安価に行うためのツールは、すでにそろっています。残っているのは文化と認知の課題です。ユーザーが正しいかどうかを教えてくれる余地を残せるくらい、自分の最善のアイデアを軽やかに持つことを学ぶことです。 それは厳密さを妥協することではありません。それこそが、本当の意味での厳密さなのです。
参考資料
- Gothelf, J. & Seiden, J. - Lean UX (3rd ed., O'Reilly, 2021)
- Singer, R. - Shape Up: Stop Running in Circles and Ship Work that Matters (Basecamp, 2019) - basecamp.com/shapeup で無料公開