「デッドエンド」を回避するプロダクト開発：市谷聡啓『作る、試す、正す。』

「MVPの反応は良かった。でもビジネスとして伸びていかない」——この状況は珍しくない。検証を回しているのに、どこかで詰まっている感覚がある。

市谷聡啓の『作る、試す、正す。アジャイルなモノづくりのための全体戦略』は、この「成功しているように見えて実は死に向かっている」パターンを「デッドエンド」と呼び、なぜ起きるのかを構造的に説明する。

1. 「デッドエンド」の正体

MVPで限られた顧客の要望に応え続けると、その顧客層に最適化されたプロダクトが出来上がる。一方で、本来目指すべき広い市場への道を知らず知らずに閉ざしてしまう。これがデッドエンドだ。

デッドエンドが起きる要因として、本書は三つを挙げる。

• ターゲットが極小化されている: 課題がニッチ過ぎて、解決しても市場規模が小さいままになる
• 届けるチャネルがない: 良いものを作っても、それを見つけてもらえる経路が設計されていない
• 課題が切実でない: 「あったら嬉しい」程度の問題に対しては、対価を払ってもらえない

flowchart LR
    A["作る\n（MVP・仮説）"] --> B["試す\n（ユーザー検証）"]
    B --> C["正す\n（学びを反映）"]
    C --> A
    B -.->|"デッドエンドに注意\nターゲット極小化？\nチャネルがない？\n課題が切実でない？"| DE["⚠ デッドエンド"]
    style A fill:#e8f4fd,stroke:#4a9eda
    style B fill:#e8f8e8,stroke:#4caf50
    style C fill:#fff8e1,stroke:#f5a623
    style DE fill:#fce8e8,stroke:#e53935

検証の結果が良くても、これらを見落としているとデッドエンドに入る。機能の出来ではなく、外側の構造が問題だ。

2. 四次元で考えるモノづくり

本書が提示するのは、プロダクト開発を「ソフトウェア」「プロダクト」「チーム」という三要素に、時間軸（トキ）を加えた四次元で捉えるフレームだ。

今の「正解」が半年後には「負債」になる。この変化を前提にすると、設計の問い方が変わる。「どう作るか」ではなく「今の判断が未来の選択肢をどれだけ残すか」が重要な判断軸になる。

3. 「Be Agile」への転換

スクラムを導入した。スプリントを回している。でも組織全体のスピードは変わらない——この状態は「Do Agile（アジャイルをやっている）」にとどまっている。

本書が目指すのは「Be Agile（アジャイルになっている）」だ。具体的には、作って試した結果から学びを得て、次の行動を変える——という反復が組織に当たり前として定着している状態を指す。

「正解を探すのではなく、正しくなる状況をつくる」という言葉が、この転換の本質を表している。仮説は間違えてもいい。ただし、間違えたことから学べる仕組みがあるかどうかが、組織の適応能力を決める。

4. 「機運もリソースである」という考え方

リソースは予算と人員だけではない、と本書は主張する。チームの関心や社内の機運も、活用できるリソースだ。

変革を起こそうとして抵抗にあったとき、正面突破ではなく「今、動ける場所から動く」という選択がある。機運が高まっている部分でまず成果を出し、それを周囲に見せることで状況を変える。小さな実績が次の機運をつくる。

本書を通じて著者が問い続けているのは、「どう動けば変化を起こせるか」という実践的な問いだ。

この本が解決できる具体的な状況

冒頭で触れた「検証は回っているのに、どこかで詰まっている」という感覚は、機能改善やA/Bテストの追加では解消できないことが多い。原因がプロダクトの中ではなく、プロダクトを取り巻く外側の構造にあるからだ。

本書が示す「デッドエンド」という捉え方は、この詰まりに名前を与える。ターゲットが極小化していないか、届けるチャネルがあるか、課題が本当に切実か——検証結果の良し悪しではなく、この三つの問いに答えられるかどうかで、同じ「反応が良い」状態でも事業として伸びるか行き止まるかが分かれる。読後にまず変わるのは、次の検証の設計ではなく、この三つの問いを立てる習慣だ。

こんな人に向いている

「スクラムを導入したが、組織の変化を感じられない」「開発速度は上がったが、ビジネス成果につながっていない」と感じているエンジニアリングマネージャーやプロダクトマネージャーに向いている。純粋に技術書ではなく、ソフトウェア開発の「上位レイヤ」——プロダクト戦略・組織設計・アジャイルの本質——を扱う一冊だ。

コードを書くことが本業のエンジニアよりも、チームをリードする立場にある人間に刺さる内容が多い。「なぜうちのアジャイルはうまくいかないのか」を問い直したいとき、システムレベルの診断ツールとして機能する。

逆に向いていないケース

一方で、この本が今すぐ効きにくい読者もいる。

• リソースの限られたスタートアップで、今すぐ答えを出したい人: 本書が描くのは、ある程度の規模と余力を持つ組織での変革だ。スピードが生命線の小さなチームにどこまでそのまま持ち込めるかは、自分の状況で見極める必要がある。
• 具体的な手順やチェックリストだけを探している人: 本書は「なぜその問いを立てるか」に紙幅を割く思考の書で、真似できる作業リストの本ではない。手を動かす前に考え方を掴みたい人に向く。

どちらも本書の価値を否定するものではなく、読むタイミングと併読すべき素材が変わるという話だ。

知っておきたい限界

本書への批判として押さえておきたい点が二つある。

一つは抽象度の高さだ。長年の実践が概念へ洗練されている分、個別企業の成功事例や泥臭い実践記録は薄い。フレームワークの意図は掴めても、自社への落とし込みは読者に委ねられる。詳細な事例が欲しければ、実践研究の書を併読するとよい。

もう一つは、AI時代における前提への問いだ。生成AIが開発のあり方を大きく塗り替えつつある今、アジャイル開発を前提に据える発想が同じ普遍性を保つのか、という批評的な視点がある。本書は仮説を生成AIと磨く手法を示すが、土台そのものの射程は読み手が検証を続ける領域だ。

この二点を承知した上で、本書を「問いの立て方」を手に入れる道具として使うのが現実的だ。

同じテーマの本との比較

アジャイル・プロダクト開発の文脈では、スクラムの実践的な手順を解説する本は数多くある。本書の差別化は「やり方」ではなく「なぜその問いを立てるか」という思考の枠組みにある。実装の詳細より「問いの立て方」「構造の見方」を学びたいときに向いている。

デッドエンドを避けるための問い

本書を読んで「自分のプロダクトはデッドエンドに向かっていないか」を問い直すことが、最初の実践になる。「ターゲットは十分に広いか」「課題は本当に切実か」「届けるチャネルがあるか」という三つの問いを、現在のプロダクトに当てはめてみる。答えに詰まるなら、それが問い直すべき箇所だ。アジャイルを「やっている」から「なっている」への転換は、フレームワークの変更ではなく、こうした問いを日常的に立てる習慣から始まる。

まとめ

「作って試す」は手段であり、「正す」ことができる組織になることが目的だ。本書はその区別を言葉にするための一冊だ。

筆者の体験から

前職の受託開発では検収が通れば案件は終わりで、納品したシステムが現場でどう使われているかを追う仕組みがなかった。自社サービスに関わってからも、MVPの反応は悪くないのに事業として伸びている感覚が薄い時期があり、この本を読んだ。

チームの振り返りに「ターゲットが狭すぎないか」「届けるチャネルはあるか」「課題は切実か」の三点を加えたところ、機能の完成度だけを見ていたレビューの視点が変わった。新しいテスト戦略への抵抗にあったときは、正面から説得せず乗り気なメンバーの領域から小さく始め、実績を見せてから広げる進め方に切り替えた。

うまくいかないこともあった。フレームの意図はつかめても自分のチームに当てはめる段になると、具体的な手順は結局自分で考えることになった。以前関わっていたtoBの業務システムで、ある部門の要望に応え続け、感謝されながらも他部門には展開できない機能ばかりが積み上がっていたことがある。後になってあれがターゲットの極小化そのものだったと気づいた。

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。