先日、AWS Japanを訪問し、ソフトウェア開発におけるAI活用について話を聞く機会があった。そこで興味を引かれたのが、「Discovery」と「Delivery」という二つのサイクルでソフトウェア開発を捉える考え方だった。
説明は明快だった。Discoveryの目的は「正しいプロダクトを作ること」、Deliveryの目的は「プロダクトを正しく作ること」だという。この話を聞いて、これまで考えてきた「成果から始めるマネジメント」という考え方とのつながりを感じた。ソフトウェア開発の話に見えるが、実は企業経営そのものにも通じる構造がある。

1．「何を作るか」と「どう作るか」は、本来別の問題だ

ソフトウェア開発では、長い間、「何を作るか」と「どう作るか」が混同されがちだった。顧客や事業部門から要求が出る。それを要件に落とし、仕様を決め、開発計画を立て、プログラムを書き、テストを行い、リリースする。この一連の仕事をいかに効率的、確実に進めるかについて、企業は多くの方法論を発達させてきた。
これはDeliveryの世界だ。そこでは、品質、コスト、納期、リスク、進捗、テストなどが重要になる。

しかし、ここには一つ大きな問題がある。

そもそも、そのプロダクトを作ることが正しかったのか。いくら品質の高いシステムを完成させても、顧客が使わなければ意味がない。いくら予定通りに機能を実装しても、顧客の問題を解決していなければ成果にはつながらない。
だから、Discoveryサイクルで、正しいプロダクトなのかどうかを検証するのだ。

2．Discoveryとは、「要件定義」ではない

Discoveryという言葉を、日本企業の従来の仕事に置き換えて理解してはいけない。Discoveryは、単に要件を細かく決めることではない。
例えば、「営業担当者向けの生成AIシステムを作ろう」という企画があったとする。ここで日本企業でありがちな「Discovery」を考えてみよう。
営業部門にヒアリングをする。「どんな機能が欲しいですか」と聞く。営業担当者から「顧客情報をすぐ検索したい」「提案書を自動で作ってほしい」「過去の商談記録を要約してほしい」という要望が出る。それを整理して、「生成AIによる営業支援システム」の要件にまとめる。
一見、顧客の声を聞き、要求を整理している。だから、Discoveryをしているように見える。しかし、これは本当の意味でのDiscoveryではない。

本来のDiscoveryなら、もう一段前に戻る。
営業担当者は、本当に何に困っているのか。時間を使っている仕事は何か。その仕事のどこが顧客への価値提供を妨げているのか。営業担当者の作業時間を削減することが、本当に会社の成果につながるのか。そもそも問題は情報検索なのか、提案書作成なのか。それとも、顧客との対話そのものに別の問題があるのか。生成AIを使う必要があるのか。システムを作らず、業務プロセスを変えるだけで解決できないのか。
こうした問いを立て、顧客や現場を理解し、仮説をつくり、プロトタイプや実験によって検証していく。

ここに、両者の違いがある。
「何が欲しいですか」と聞いて要求を集めるのは、要求定義に近い。「そもそも何が問題なのか」「何を変えれば成果が生まれるのか」を探索するのがDiscoveryだ。

3．Discoveryは「方法論」になっている

欧米のProduct Managementの世界では、このDiscoveryを行うためのさまざまな方法論が発達している。
Customer Interview、User Research、Design Thinking、Design Sprint、Lean UX、Jobs to Be Done、Opportunity Solution Tree、Prototype、A/Bテストなど、名前はさまざまだ。しかし、基本にある考え方は共通している。
いきなり作らない。まず顧客や市場を理解する。何が問題なのかを発見する。何を成果とするのかを明確にする。解決策について仮説を立てる。小さく検証する。その結果をもとに、何を作るべきかを決める。
つまりDiscoveryとは、一つの手法ではない。
「何を作るかを、思いつきや要求だけで決めず、探索と検証を通じて決める」という仕事の思想なのだ。

４．なぜ欧米では、Discoveryが発達したのか

では、なぜ欧米では、これほどまでにDiscoveryに力を入れてきたのだろうか。
「欧米では失敗が許されるから、どんどん作って失敗すればよい」という説明では、この現象を十分に説明できない。むしろ、欧米企業も大きな失敗は避けたい。そのために発達したのが、失敗を早く、小さく、安く発見するための仕組みだったと考えたほうがよい。
仮説を立てる。顧客に聞く。プロトタイプを作る。実験する。反応を見る。駄目なら捨てる。もう一度仮説を立てる。このプロセスなら、間違ったものを何年もかけて作ってから失敗することを避けられる。つまり、失敗を許容するというより、大きな失敗を避けるために、小さな失敗を早い段階で経験するのだ。

一方、日本企業は違う方向に進んだ。
日本企業も、当然、失敗を避けたい。そこで発達したのは、事前に十分に検討し、関係者の合意を取り、承認を得て、計画通りに実行する仕組みだった。調査する。企画書を作る。関係者と調整する。稟議する。予算を確保する。計画を立てる。そして、決めたことを確実に実行する。
つまり、欧米は、失敗を早く、小さく、安く発見するためにDiscoveryを仕組み化した。それに対して、日本は、失敗しないために、事前に計画し、合意し、承認し、実行を管理する仕組みを発達させた。両者とも目的は「大きな失敗を避けること」だった。しかし、そのために選んだ仕事の構造が違ったのである。

ここには、さらに重要な違いがある。
Discoveryでは、最初に立てた仮説が間違っていることを前提にしている。だから、「この企画は間違っているかもしれない」と言うことに価値がある。顧客に聞いてみた結果、作ろうとしていたものをやめることも成功だ。
しかし、事前の合意と承認を重視する組織では、一度決めた企画を途中で「そもそも間違っていた」と言うことが難しくなる。なぜ最初に分からなかったのか、誰が承認したのか、既に使った予算はどうするのか、という問題になるからだ。すると、顧客や市場を調べる目的も変わってくる。「何を作るべきかを発見するための調査」ではなく、「決めた企画が正しいことを確認するための調査」になってしまう。
ここに、日本企業が「市場調査もしている、顧客の声も聞いている、PoCもやっている。だからDiscoveryをしている」と考えてしまう理由がある。問題は、調査をしたかどうかではない。調査や実験の結果によって、最初に考えていた解決策そのものを捨てたり、変えたりすることができるか。
そこに、Discoveryと従来の企画活動との決定的な違いがある。

５．AI時代に問われるのは、正解を探索し続ける経営への転換

AWSは、Discoveryを行うことで、多くのアイデアを捨ててきたそうだ。私たちは、Discovery云々よりも、もっと根本的な、仕事の構造そのものが問われているように思う。
日本企業は、これまで「失敗しないために、事前に計画し、合意し、承認し、決めたことを正しく実行する」という仕組みを発達させてきた。それは、変化が比較的予測でき、正解を事前に定義できる時代には、大きな強みだった。しかし、正解が最初から分からない時代には、この仕組みだけでは対応できない。
これから必要なのは、「正解を決めてから実行する組織」から、「成果を定め、仮説を置き、探索し、検証しながら正解をつくっていく組織」への転換ではないだろうか。そのためには、失敗をなくすことだけを目指すのではなく、間違いを早く発見し、学び、方向を変えることを仕事として認める必要がある。Discoveryとは、そのための一つの方法論にすぎない。

本当に変えなければならないのは、企業の「仕事の進め方」なのだ。
AIは、Deliveryを劇的に高速化する。だからこそ、これからの企業競争では、「正しく作る力」よりも前に、「何を成果とするのかを定め、何をすべきかを探索し、必要なら自分たちの前提そのものを変える力」が問われる。
AI時代の経営とは、正解を早く実行する経営から、正解を探索し続ける経営への転換なのではないだろうか。