未来から逆算するプロダクト開発
こんにちはバーニング近澤です。皆さんも日々感じていらっしゃるように、昨今生成AIの進化が大変目覚ましいです。その生成AIの進化により、プロダクト開発にも大きな影響が出ていると感じています。Burning needsを特定することは恒久的に重要ですが、生成AIを前提とした次の10年を作るサービスを生み出すには、少し違った考え方が必要だと考えます。
以前Burning castで話したNotionやAirtableの例のように、Burning needsの特定をすっ飛ばして成功しているスタートアップはこれまでも多くありました。ただ、これらの多くは生存者バイアスであり、彼らの成功の影に多くの屍があることは間違いありません。ですので私はこの方法には再現性がないと考えており、まずBurning needsを特定することが重要であると説いてきました。
しかし、生成AIの登場により状況は変化してきています。現在席巻している生成AI系のサービスの多くが、Burning needsを特定して開発してきたかというと、そうではないでしょう。人間のようにチャットできるサービスが解決するBurning needsが、最初からあったとは思えません。
生成AIという巨大な技術革新の波
いま我々は大きな転換点にいます。弊社Autifyでも生成AIを用いたサービス開発を行っていますが、その進化が目覚ましく、あらゆるものを変えてしまうポテンシャルに興奮と恐怖が混ざった感覚を感じています。これからあらゆるものが再定義されるでしょう。
このような巨大な変革の波のある中では、製品開発においても考え方を変える必要があります。生成AIにより、あらゆるものが今より圧倒的に改善される可能性があります。しかしそれが解決する課題は、現在日常業務として当たり前にこなされているので、Burning needsとして顕在化していません。顧客はそれを課題として認識すらしていないでしょうし、それがもっと良くなると思ったこともなかったでしょう。
例えばGitHub Copilotを活用すると、55%も早くタスクが完結でき、さらにタスクの完結度が使わないよりも8ポイント高くなるという調査結果が出ています。ソフトウェア開発をもっと効率化したいと誰もが思っているでしょうが、Burning needsであると明言できた人はほとんどいなかったでしょうし、ましてやAIによって解決しようと思っていた人はいなかったでしょう。
GitHub blogより
未来から逆算するプロダクト開発
ではChatGPTやGitHub Copilotのような製品を生み出すにはどうすればいいのでしょうか。Case studyとしてAI software engineerのDevinを取り上げたいと思います。最初に断っておきますが、Devinが素晴らしいサービスだとも爆発的にうまくいくサービスだとも思っていません。単純に生成AI時代におけるプロダクト開発の考え方として参考になるので取り上げます。
Devinは「世界初のAI software developer」という謳い文句で2024年4月にリリースされました。デモ動画の完成度から、人間のように自律的にタスクをこなせるという期待が非常に高まりました。さらに「いずれ自分の仕事が奪われるかもしれない」と感じたエンジニア達の中で、大きな議論を巻き起こしました。Devinは大きな注目を集め、リリースから6ヶ月で一気に$2Bの評価額がつき$175Mの資金を調達しました。
AIエンジニアがチームで一緒にタスクをこなしてくれたら、確かに今までより圧倒的に効率的になります。しかし、そのような声が顧客から上がってくることはなかったでしょう。生成AIを前提としたサービスを考える場合、AIが今後さらに進化していく中でどのような未来になるのかを定義し、そこから逆算してプロダクトを考える必要があります。
Devinの場合は、AIが自律的にエンジニアリングタスクを解き、人と同様にチームメイトのように協業する未来が来ると仮定し、そこから逆算してAI software developerというコンセプトの着想に至り、製品開発を進めたと言えます。
AIが変革するソフトウェア開発
我々Autifyも生成AIでテストケースとテストコードを作り出す、Autify Genesis(USではZenesという名称で展開。以下Genesis）という製品をベータローンチしました。現在非常に多くの引き合いを頂いていますが、Burning needsから逆算したのではなく、AIの進化の中でソフトウェアの品質保証がどのようになるか考えて、そこから逆算する形で製品のコンセプトを構築しました。
AIがソフトウェア開発に対してどのような変化をもたらすかについては、翻訳業界が参考になると考えました。翻訳業界は機械翻訳の爆発的な精度向上により、人が0から翻訳を行うよりも、機械翻訳の結果を修正するpost editという手法が確立されてきました。
ソフトウェア開発においても、AIが下地を作りエンジニアが修正を行うpost editが恐らく主流となってくるでしょう。そうなった時にQAはどうなるか。人が与えた指示からAIが下地を生成する形になる、つまり仕様書を起点としてテストケースを生成し、人がレビューを行い修正を加え、そこからさらにテストコードを作り出す、そうすることによってこれまでの業務フローを大きく変更することなく、AIによる生産性向上の恩恵を受けられるのではないか。そう考えて着想したのがGenesisです。
Autify Genesisのコンセプト図
Burning needs特定の重要性は変わらない
ここまで読み進めていただくと、これまで僕が発信してきたBurning needs特定のプロセスを否定しているように聞こえるかもしれません。しかしこれまで解説してきたプロセスの重要性は全く変わりません。ソリューションファーストで進めていって、ニーズがありませんでしたとなる状況に違いがあるわけではありません。Devinの成功に僕が若干懐疑的なのは、Burning needsの検証がどこまでなされているのか不明だからです。
こちらで解説したように、仮説フェーズでは顧客セグメント、課題、解決策の三つの仮説を立てる必要があります。この前提は変わりませんが、この考え方の場合は、解決策から仮説を立案する形になります。つまりこれまで顧客セグメントと課題に重点を置いて仮説構築を行なってものを、解決策の方に重心を寄せるということです。その先の検証フェーズの進め方に違いはありません。検証フェーズにおける製品の検証については、MVPが作りやすい生成AIにおいてはむしろ進めやすいのではないでしょうか。
Genesisを着想した際も解決策から仮説を作り簡単なモックアップまで作りましたが、この製品が多くの企業において言及されている「ソフトウェアQAにおけるリソース不足」のBurning needsを解決することに、全く疑いの余地はありませんでした。ですので、解決策 → 課題 → 顧客セグメントの順番で仮説を立案し、顧客ヒアリングを進めていく中で確信を得たため、正式な事業展開に至りました。
我々の新サービスがどのような形になるかは全く分かりませんが、製品の進捗を見るたびに未来はこうなるはずであるという確信が強まってきています。これまで課題から入る「ボトムアップ」な製品開発手法であったものに対し、あるべき未来から製品を逆算する「トップダウン」な手法へと少し重心を移していく時期なのではないかと考えています。
すでに登録済みの方は こちら
読者限定の内容も逃しません。