アジャイル開発はもう古い？次世代の開発手法トレンドと今後の最適解を徹底解説

アジャイル開発がソフトウェア開発の主流となって久しい現代において、「アジャイルは古い」という声が一部の技術者や経営層から聞かれるようになっています。特に、最新のアメリカのプロダクトマネジメント界の潮流では、「単なるアジャイルは、市場価値を産み出すのには役に立たない」という大きな批判の声すら、そこにはあるのです。

本記事では、アジャイル開発が古いと言われる背景や理由を紐解き、現在のソフトウェア開発における正確な立ち位置、次に来ると予測される新しい開発手法のトレンドを解説します。自社の開発体制に課題を感じている方や、最適な開発手法を模索しているプロダクトオーナーの方にとって、今後の戦略立案の羅針盤となる情報を提供します。

アジャイル開発は本当に古いのか？現状とトレンドを解説

日本国内におけるアジャイル開発の普及状況

日本国内のソフトウェア開発市場において、現在もなお普及と進化の途上にあります。独立行政法人情報処理推進機構（IPA）が発表しているソフトウェア開発の各種調査においても、アジャイル開発を採用する企業の割合は年々増加傾向を示しています。

しかしながら、日本特有のシステムインテグレーターを中心とした多重下請け構造や、要件を事前に確定させることを好む商習慣が壁となり、欧米と比較するとアジャイル開発の全面的な導入は遅れをとっているのが実情です。

そのため、日本市場においては「アジャイルが古い」というよりも、むしろ「本格的なアジャイルの導入がこれから始まる」と表現するのが正確な状況と言えるかもしれません。

グローバル市場から見たアジャイルの立ち位置

一方、グローバル市場、特にソフトウェア産業を牽引する米国や欧州の先進企業に目を向けると、アジャイル開発はすでに特別な手法ではなく、開発の「当たり前の基盤」として定着しています。2001年にアジャイル憲章が採択されてから二十年以上が経過しており、アジャイルは世界に広く浸透した感があります。そのため、海外の最前線では「アジャイルを導入すること」自体はもはやイノベーションとは見なされず、アジャイルを土台とした上で、さらにビジネス価値を最大化するための新たなアプローチへと関心が移行しています。

そんな「当たり前化」した地域の最たるものであるアメリカでは、実は、アジャイルやアジャイルコーチなどのアジャイル産業が、手厳しい批判にさらされています。たとえば、プロダクトマネジメントの第一人者、マーティ・ケイガン氏は、

が諸悪の根源である、とずいぶん前から酷評しています。

例えば、YouTube動画 The nature of product | Marty Cagan, Silicon Valley Product Group (Lenny’s Podcast) の中で、ケイガン氏は手厳しく、様々な角度からその「悪しき状態」を批判しています。以下はほんの数例です。これからアジャイルを導入したいと考える企業にとって、彼の警告は、無視できないもののはずです。

• 「その（作業パッケージの）一式がスプリント計画に持ち込まれ、エンジニアは次に何を作るかを、ほぼ指示されるだけになる」
• 「多くのチームでは、プロダクトマネージャーが主に要求仕様やPRD、ユーザーストーリーを書く人として扱われている。……中略……（スクラムにおける）プロダクトオーナーの仕事は、プロダクトマネージャーの仕事のほんの一部。しかも後回しにしてよい事務作業だ。POに、価値発見のスキルや責任がないことがあまりにも多い」
• 「プロダクト開発の経験や知識のないアジャイルコーチに習ってPOの資格が取れる現状はナンセンスだ。まるで、道端で出会った他人にエンジニアリングを教わるようなものだ」

これこそが「アジャイルはもう古い」という認識の根本理由であり、それはアジャイルがすでに機能不全に陥ってきているという証拠なのです。

アジャイルが古いと言われる理由

手法が目的化し形骸化している現状

アジャイル開発が古いと指摘される理由の一つは、開発現場においてスクラムなどの手法を導入すること自体が目的化し、本来のアジャイルの精神が形骸化しているケースが多発している点にあります。多くの企業において、デイリースクラムやスプリントレビューといったイベントの実施、あるいはストーリーポイントの見積もりといった形式的なプロセスを守ることが第一義であるとされ、実質的なプロダクトの改善やチームの自律性が伴っていない「名前だけのアジャイル」が蔓延しています。このような形骸化した状態では、アジャイル本来のスピード感や柔軟性が失われ、単なるオーバーヘッドの大きい開発プロセスへと成り下がってしまいます。

アジャイルの、事実上の「ウォーターフォール化」

もっと根本的な問題として、上記のケイガン氏のいう「価値創造」のコンテキストでは、事実上、アジャイルは単に見せかけだけで、それは事実上「顧客を無視した、解決策の、上流（？）から下流（開発チーム）への受け渡しシステム」という意味で、寸分ウォーターフォールと変わらない、という、否定しようのない事実があります。

これについては以下「スクラム（アジャイル）の3つの欠点」で詳述します。

スクラム（アジャイル）は、それ単体では市場価値を生むとは限らない

アジャイルで開発したはずのソフトウェアなりハードウェアなりが、最終的に出荷され、値段をつけられて売られる段階になってさっぱり売れないのであれば、開発手法がアジャイルであろうが、ウォーターフォールであろうが、

と、考えるしかありません。なぜこうなるのか？も、以下「スクラム（アジャイル）の3つの欠点」で詳述します。

まとめ

短期間に予算以内で売れないプロダクトが「アジャイルに開発」された事例は、脚光を浴びることがないだけで、世の中には山のようにあるのです。

スクラムで開発したにもかかわらず、サービスとして成功しなかった３つのプロジェクト

スクラムで開発したにもかかわらず、事業自体は成功しなかった実例を３つあげます。これらの事例がアジャイルが時代遅れといわれる評価の傍証になっています。

1．IMVUの最初のバージョン

エリック・リース氏がCTOとしてかかわった、アバターつきのメッセンジャーアドオンを提供するサービスIMVUの最初のバージョンこそ、スクラムで開発し、大失敗を喫したプロジェクトの最たる例です。創業当時の2000年代初頭、IM/インスタントメッセンジャーはSNSライクな機能を果たしており、周囲の人間がはまったら自分も参加せざるをえず、さらに知り合いを誘って顧客に加えることで雪だるま式にユーザベースが膨れていくネットワーク効果を備えていました。そこでIMVUは、たくさんのユーザをほこるAOLのようなIMにこのアドオンをくっつけて使わせることで、コバンザメ式にそのネットワーク効果に乗ろうとしました。

リース氏はスクラムチームを率いて、半年間で必死で製品版のコードを書き上げます。CTOであるリース氏はリリースの前の晩、クラッシュだらけの製品を上市していいものか悩みましたが、思い切って正式リリースします。まだたくさんの人が使用しないうちに、アジャイルで片っ端からバグをつぶそうと思ったのです。しかし、何か月間も、誰もクラッシュバグを引くことがない状態が続きました。

それもそのはず、アジャイルで造ったはずのサービス、IMVUを誰も使わなかったからでした。

この後もリース氏の率いるスクラムチームは長い間サービスの性能を向上させようとあがきますが、いまある製品の形を捨てるピボットを決断するまで、ついに売上が向上することはなかったのです。

【関連記事】リーンスタートアップとは？メリットや事業成功へ導く手順を詳しく解説！

2. 筆者自身が技術部長を務めた、あるSaaSのアジャイル開発

恥ずかしい話ですが、ほかならぬ私自身が、スクラムを自分のプロジェクトに導入し、必死でサービスは短期間に起ち上げたが、結局自分の在職期間3年の間には、赤字が出るばかりで損益分岐点にはるかにとどかなかった、とても苦い経験をしています。いままでやったことのなかったスクラム開発体制を、隣の部門のアジャイルコーチに教わりながら、スクラムマスターを教育し、アジャイル経験者の外国人エンジニアをハイアリングして、DevOpsの環境まで一から構築、社内では「この短期間でサービスローンチしたのは見事」と絶賛されたのですが、一つ一つのリリースがどれだけの市場価値をもたらしたか、はなはだ心もとない結果となりました。

3. スクラムで有名なスタートアップと協業、PoCに大成功➡事業化に失敗

以下の記事に、ある企業がスクラムで有名なスタートアップと組んでアプリを造り、官公庁に表彰されるような非常に見事なPoCを行ったが、結局ついに事業化できなかった事例を挙げています。この事例でも、素早く、素晴らしい製品を世に送り出し、官公庁に絶賛されるような成果を上げて――事業化に失敗しました。

【関連記事】PoCのやり方とは？計画から評価まで5ステップで進め方を解説

スクラム（アジャイル）の3つの欠点

私はかつて、大企業にスクラムを導入し、数ヶ月の短期間でいくつもの製品を世の中に出したという、あるスクラムマスターの方の zoom セミナーに出席したことがあります。その方が、いかに効率的に複数のサービスを少ないチームで事業化なさったか？ということを自慢げに とうとうと 語るので、私はこのような質問をQ＆Aに入れました。

私はこの、素朴だが本質的きわまる質問を、3度入力し、3度ともスルーされました……。本質的だと私が信じる理由はとてもシンプルで、短期間に数少ないメンバーで売れない製品を次々造ったところで、赤字がかさむだけだからです。

欠点1. スクラムガイドの限界①　「プロダクト価値」発見の手順が書かれていない

スクラム・ガイドでは、プロダクトオーナーは「プロダクト価値の最大化に責任を持つ」とされていますが、実は以下の２点がどこにも書かれていません。

1. 「プロダクト価値」の、実務で役に立つ定義
2. 具体的にどのようにすればその「プロダクト価値」とやらが最大化されるのか？

驚くなかれ、スクラム・ガイドには「顧客 customer」という言葉は、以下の一か所にしか登場しないのです！

つまり、プロダクトオーナーに対し、スクラムガイドは、「ミッションインポッシブル」ふうに言えば、このように宣言しているのです。

欠点2. バックログに積み上げられたものが市場価値を生み出す保証は何もない

欠点1. の「放置プレイ」がもたらす弊害は、深刻です。

開発チームは、バックログに積みあがっているユーザーストーリーを実装しようとするとき、どれをどの順番で開発していくか、または最悪どのユーザーストーリーを没にするか、までは考えますが、自分の足で顧客のところまで出かけていって、その要件（≠デザイン）を大幅に変更したり、新たな要件を聞き出してきたりしようとはしません。私も自分のサービス開発にスクラムを導入したことが２度、ありますが、二度とも、開発チームのエンジニアたちもスクラムマスターも、一緒に客先に行くことをかたくなに拒否しました。理由は、「スクラムガイドに、それは開発チームの責任だとは書かれていない、我々は開発だけで手いっぱい」だからです。

これでは、ケイガン氏らの指摘する通り、要件の順番を並べ替えたり実装の〇✖を付けたりしているだけで、やっていることは、上（川上＝プロダクトオーナー）から下（滝つぼ）へ作業パッケージを受け渡しているだけで、文字通りのウォーターフォール（滝）です。

また、このとき、プロダクトオーナーがどのようなやり方でユーザーストーリーを書いていくのか、その方法が、厳密なやり方で規定されている場合は稀です。ましてや、ユーザーストーリーなどに細かく顧客の行動が聞き込み調査に基づきファクトベースでジョブマップ的に書かれているケースなど、少なくても私はみたことがないです。

そして、厄介なことに、ほとんどの場合、顧客の意思を少なくても直接は確認せずに、事業側の何らかの意思を受けただけで、ユーザーストーリーがいつの間にか積みあがっていきます。例えば、「競合がこの機能を持っている」という、実はその時点では「社内の都合」でしかない事情が、「この機能があったら使いますか？」という顧客への確認をすっとばして、本当は競合のユーザーがそもそも存在に気づいていない機能かもしれないのに、当たり前のようにバックログに追加されるのです。

つまり、アジャイル憲章に「変化を抱きしめる」とありますが、その抱きしめた変化が、果たして、多くの顧客の要望を科学的にヒアリングして生み出された変化なのか、それとも、社内の誰か声の大きなステークホルダーの気まぐれにしか過ぎないのか、スプリントプランニングで厳密には精査されないまま、実装へ回されていくのです。あるいは、ある程度 吟味されることはあっても、「空気を読んで」鵜呑みにされる傾向が強い実態があるのです。

そして、「そんなのプロダクトオーナーが悪いだけ」と責めるのは酷です。なぜなら、スクラムガイドは、価値を生み出す方法についてどころか価値が何なのかも、何も教えていないからです。

欠点３. スクラムガイドの限界②　ピボット／撤退の判断基準、やり方が書かれていない

あなたは、月面探査プロジェクトを遂行する宇宙船「アルテミス」の船長（プロダクトオーナー）です。最近まで、アルテミスは、強力で一度噴射すれば長距離を一気に進めるが、エネルギー充電に長時間要する大型ロケットブースター「ウォーターフォール」しか搭載していませんでした。この「ウォーターフォール」には厄介なところがもう一つあり、下手すると目的地をそれて行き過ぎてしまうのです。最近になって、敏捷な動きを可能にするスラスター「スクラム」を搭載し、さまざまな方向へ小刻みに素早く動くことが可能になりました。目的地さえはっきりしていれば、そこに素早く確実に、しかも最低限の燃料でたどり着けるようになったのです。

ところが、あるときあなたは大変なことに気づきました。自由自在に小回りが利くようになったのはうれしいのですが、あなた自身の描いた航路図「バックログ」に基づいてちょこまか噴射（スプリント）を繰り返しても、「ウォーターフォール」を使用していたときと同様、一向に月（サービスの大ヒット）が見えてこないのです。「スクラム」のマニュアル「スクラムガイド」を必死でめくるのですが、どうやってバックログを消化するか、あるいはどうやって一回の噴射（スプリント）を行うべきかは詳細に書かれていても、

のです。

実際のスクラムガイドには、こうあっさり書いてあります。

つまり、スクラムガイドが教えてくれるのは、「今回の噴射目標（Sprint Goal）が、何らかの理由で目指すに値しない古い目標となったら、その噴射は止めてもよい（逆に言うと止めなくてもよい）」というところまでなのです。

別のたとえでいうなら、スクラムガイドは、軍をどのように進軍させるか、は教えても、どのような条件になったらきっぱり進軍を止めるべきか、あるいは、どんな戦況になったらそれを逆転不可能と判断していまの戦争をやめ、新しい戦さを起こすべきについては口を緘して語らないのです。

アジャイルの次に来る開発手法のトレンド

ここまで、なぜ「造るだけのアジャイル」が、アメリカで「時代遅れのイケてない手法」として認識されてきたのかを語ってきました。ここから、その先にあるプロダクト開発の考え方を説明します。

開発と運用を統合するDevOps

アジャイル開発の先いある次の開発手法として、すでに多くの先進企業で標準となりつつあるのがDevOpsという概念です。アジャイル開発が主にソフトウェアを迅速に開発することに焦点を当てているのに対し、DevOpsは開発チームと運用チームの壁を取り払い、ソフトウェアの開発からテスト、リリース、そして運用までのライフサイクル全体を自動化し、継続的に価値を届けることを目的としています。

DevOpsを導入することで、CI/CDパイプラインが開発から運用まで一気通貫で構築され、一日に複数回のリリースを行うことも可能になります。

ただし、DevOpsが「開発から運用までスムーズに、ごみの山を構築する」ことになるリスクは、そのスキームの範囲内では原理的に防ぎようがないのは一緒です。

デュアルトラックアジャイルの登場

これは、まったく新しい流行語というより、スティーブ・ブランク氏の顧客開発ランチパッドにある「顧客開発チーム」と「プロダクト開発チーム」の考え方を、現代のプロダクト開発組織に合わせて言い直したものです。

顧客開発チームは、顧客、市場、支払い意思、導入条件を確かめる。プロダクト開発チームは、確かめられたものを実際のプロダクトとして造る。この二つを切り離さず、並行して動かす。これがデュアルトラックアジャイルの基本です。

この方法は、マーティ・ケイガン氏の「３つの問題」（下表）の、②と③を、①と並行で解決しようとするやり方です。

ここで大事なのは、

では、デュアルトラックにはならないということです。当たり前ですが、どのようにそれをやるかを規定しないといけません。

実際には、プロダクト責任者、デザイナー、リードエンジニアが小さな探索チームを造り、毎週のように顧客と接点を持ちます。そこで、顧客が何を選び、何を避け、どの代替手段で我慢しているのかを観察します（上表の問題③）。そして、そこで見えた前提を小さく確かめ、本当に造る価値があるものだけをプロダクトバックログに渡します。一方、開発チームは、渡されたものをただ実装する下請けではありません。探索段階から一緒に入り、「それは本当に造るべきか」「もっと安く確かめる方法はないか」「技術的にどの前提が危ないか」（上表の問題②）を一緒に考えます。

つまり、デュアルトラックアジャイルとは、上流で決まった要件を下流に流すのではなく、何を造るべきかを見極める探索と、造ると決めたものを届ける開発を、同じチームが一丸となって並行して進めていくスキームです。

ただし、マーティ・ケイガン氏は後に、この「デュアルトラックアジャイル」という言葉を使うのをやめました。理由は、この言葉自体が、またしても、アジャイルという言葉が先行することで、開発プロセスの話だと誤解されたからです。そのため、ケイガン氏は現在、より本質に近い表現として「CD／Continuous Discovery 継続的市場探索」×「CD／Continuous Delivery 継続的デリバリー」という表現を用いています。

つまり、古いのはアジャイルそのものではなく、古いのは、アジャイルは問題の３分の１、しかも最も容易な問題しか解決できないのに、すべてを解決する魔法の杖だと誤解することです。

Continuous Discovery／継続的市場探索の台頭

アジャイルの次に来る開発手法トレンドとして、近年アメリカのプロダクトマネジメント界隈で最も注目を集めているのが、Continuous Discovery（継続的市場探索）です。これは、単に開発を素早く回すための手法ではありません。プロダクトチームが、顧客と継続的に対話しながら、市場機会を発見し、どの打ち手が本当に価値につながるのかを、小さく検証し続けるための方法です。

テレサ・トーレス氏は、Continuous Discoveryを「少なくとも週に一回、プロダクトを作るチーム自身が顧客と接点を持ち、望ましいプロダクトアウトカムに向けて小さなリサーチ活動を行うこと」と定義しています。ここで重要なのは、営業部門や調査会社に顧客理解を丸投げするのではなく、実際にプロダクトを作る側が、自分たちで顧客の行動や困りごとに、直接触れ続けることです。

顧客の問題を十分に探索せず、最初から選ばれた解決策を作業パッケージとして右から左へ流していくだけでは、どれだけ開発の回転が速くても、お金にならない機能を量産しかねません。Continuous Discoveryは、この欠陥を根本的に補います。顧客インタビュー、アサンプションテストを日常的に繰り返しながら、「どの市場機会に取り組むべきか」「どの解決策のどの前提条件を試すべきか」を更新し続けるのです。つまり、アジャイルが得意としてきた“製造する工程の改善”を土台にしつつ、その手前にある“何を作るべきかの探索”＝スクラム・ガイドの言う「プロダクト価値」自体の開発を、開発プロセスの外ではなく、内側に有機的に組み込むのが Continuous Discovery の本質です。

デュアルトラックアジャイルとの最大の違いは、上表問題の、主に③を、オポチュニティー・ソリューション・ツリーというフレームワークを用いて体系化したことです。

【関連記事】Continuous Discovery Habitsとは？実践方法・OST・インタビューの基本を解説

まとめ

アジャイル開発を導入するメリット

仕様変更に対する柔軟な対応力

アジャイル開発の大きなメリットは、途中で見えてきた事実に合わせて、開発内容を変えやすいことです。

新規事業やプロダクト開発では、最初の計画がそのまま正しいことはほとんどありません。顧客と話す。実際の利用状況を見る。代替手段を知る。すると、最初に考えていた機能や優先順位が、的外れだったと分かることがあります。

そのとき、半年後まで計画を変えられない開発体制では、学び続けることができなくなります。

アジャイル開発であれば、次の短い開発サイクルで優先順位を変えたり、不要になった機能を止めたり、より重要な検証に集中したりできます。

ただし、ここでいう「仕様変更への柔軟性」は、社内の思いつきに振り回されることではありません。顧客の行動、導入条件、支払い意思、利用継続の見込みといった事実を見て、造るものを変えられる、ということです。

小分けに造るので、Continuous Discovery と相性がよい

もう一つのメリットは、開発を小さく区切れることです。

大きな製品を一気に造ると、間違いに気づくのが遅れます。完成してから「誰も使わない」と分かっても、そこまでの開発費と時間は戻りません。

アジャイル開発では、機能を小さく切り出し、短い間隔で届けることができます。これにより、「この機能は本当に使われるのか」「顧客の行動は変わるのか」「次に進むだけの根拠があるのか」を早い段階で確認しやすくなります。

アジャイル開発は、継続的市場探索と組み合わせて初めて、収益化にすぐにむすびつく開発を進められる仕組みになります。

アジャイル開発を成功に導くためのポイント

ここまで詳しく述べてきたとおり、「アジャイル開発を成功に導くためのポイント」というこの問いかけそのものが、そもそもボタンをかけ間違った問いです。なぜなら、アジャイル導入➡開発に成功して多くの機能を短期間にデリバリし、結果、赤字がコツコツ積みあがって結局 事業に失敗したのでは、有害無益だからです。

（危険極まる）間違った問い：アジャイルでいかにたくさんの機能を短期間に世に出していくか？

正しい問い：（アジャイルを使うまい使うまいが）あなたの事業を黒字化するにはどうしたらいいのか？

後者の問いに答えるなら、アジャイルという片輪走行で事故るのを防ぐために、もう片輪である Continuous Discovery 継続的市場探索を導入するのが最も確実です。

であるがゆえに、この節では、

を解説します。

組織全体でのアジャイルマインドの醸成

アジャイル開発を単なる手法の導入で終わらせず、真の成果に結びつけるためには、開発チームだけでなく組織全体でアジャイルマインドを醸成することが不可欠です。アジャイルの成功を阻む最大の障壁は、既存の組織文化や評価制度との衝突です。

この文化の醸成は、Continuous Discovery／継続的市場探索を導入したときも、というよりは、導入したときこそ、非常に大切になってきます。

例えば、失敗を許容しない企業文化や、個人の成果のみを評価する人事制度は、チームの協力と実験を重んじるアジャイルの精神と真っ向から対立します。経営層やビジネス部門を含めた組織全体が、不確実性を受け入れ、継続的な学習と改善を尊ぶマインドセットを共有する必要があります。

トヨタ自動車が実践するリーン生産方式の精神が全社に根付いているように、アジャイルを単なるIT部門のツールとしてではなく、企業全体の競争力を高めるための経営哲学として位置づけ、トップダウンでの意識改革を推進することが成功の鍵を握ります。組織の壁を越えた協力体制の構築が急務です。

プロジェクト特性に合わせた手法の選択

アジャイル開発は万能の銀の弾丸ではなく、プロジェクトの特性に合わせて最適な手法を選択する見極めが極めて重要です。すべてのプロジェクトを無理にアジャイルで進めようとすることは、かえって効率を低下させ、失敗のリスクを高めます。

例えば、ユーザーの反応を見ながら仕様を固めていく新規Webサービスの開発や、継続的な改善が求められるスマートフォンアプリの開発には、CD／Continuous Discovery × CD／Continuous Delivery が適している、というより、ほぼ必須です。一方で、要件が明確で変更の可能性が低く、人命に関わるような高い安全性が求められるインフラシステム、セキュリティシステムの構築、航空機のソフトウェア開発などには、ウォーターフォール開発の方が適しています。

また、両者のメリットを組み合わせたハイブリッド型アプローチを採用することも有効な選択肢です。プロジェクトの規模、不確実性の高さ、求められる品質基準、チームの習熟度などを総合的に評価し、固定観念にとらわれず柔軟に開発手法をテーラリングする姿勢が求められます。状況に応じた最適な手法の選択がプロジェクトの明暗を分けます。

アジャイル開発のまとめ

アジャイル開発は、オワコンではありません。ただし、アジャイルを「短期間でたくさん機能を出す方法」と考えている限り、その認識は時代遅れです。スクラムを回し、スプリントを切り、バックログを消化しても、顧客が選ばなければ、市場価値は生まれません。

つまり、「何を造るべきか」を探索しないまま造るスピードだけを上げようとする「片輪走行」の発想は、明確にオワコンです。

これから必要なのは、CD/CDすなわち継続的市場探索（ディスカバリー）と継続的デリバリーを組み合わせることです。顧客と対話し、どの市場機会に取り組むべきかを見極め、危ない前提を小さく確かめる。そのうえで、造る価値があるものだけを、短いサイクルで毎回のデリバリーで届けていく。

弊社では、スクラム導入だけでは価値創造に届かなかった実体験を踏まえ、継続的市場探索を事業開発・SI・プロダクト開発に応用しています。

【関連記事】大手SIerが未経験分野での事業立案に成功した秘訣とは？Continuous Discovery 継続的市場探索 導入事例公開中！

富岡功

イントラプレナーとして、合計８つの新規事業開発を経験。1,300回に及ぶ顧客インタビューの実施経験を持つ。生成AIによるアイディエーションの世界初のサービスである、「AIディアソン」を、2023年の1月に上梓。それ以降も次々とAIサービスをローンチしている。
翻訳書の発行される前の版の、The Four Steps to the Epiphany （邦訳「アントラプレナーの教科書」、リーンスタートアップの下敷きになった本）を所持するほど、古くから事業開発の方法論を考究。最近はアメリカで最新とされるプロダクト開発のメソッドである、継続的発見(Continous Discovery)手法を取り入れ、エフェクチュエーションと組み合わせて事業開発に応用。