株式会社Relic_TECH Street登壇資料「インサイト起点のプロダクト開発へ ― Claude Codeを軸にツール連携で回すPMの検証・開発サイクル」

インサイト起点のプロダクト開発へ Claude Codeを軸にツール連携で回す PMの検証・開発サイクル Copyright © 2026 Relic Inc. All Rights Reserved. 1

自己紹介 株式会社Relic イノベーションマネジメント事業部 和歌山イノベーションラボ マネージャー 拠点長 高橋 洋地 大学卒業後、フロントエンドエンジニアとして様々な業界・業種のクライアントに対して、開発からカスタマーサポート まで一貫した支援を行う。自社プロダクトのSaaS型クラウドファンディングプラットフォーム「ENjiNE」や、クライアン トと共創するSaaSプロダクトのフロントエンド開発を担当するなど、様々な新規事業の開発を経験。エンジニアとしてプ ロダクト開発を行う傍ら、自身が関わったプロダクトのバイアウトを経験。2023年2月に和歌山イノベーションラボ所長に 就任。 その後、プロダクト開発をする上で事業価値を探索・検証を重視するプロダクトディスカバリー事業部に所属しマネー ジャーとして、仮説検証・ユーザー理解・事業成長に直結する開発プロセスの設計およびチームマネジメントを担当。 2025年7月より株式会社Relicホールディングスのグループ会社である株式会社DocTokの取締役を務め、2026年1月からは Relic自社プロダクトのSaaS型イノベーションマネジメントプラットフォーム「Throttle」の事業責任者を兼任し、その後 2月からイノベーションマネジメント事業部に部署移動し現職。 2

Saa S型イノベーションマネ ジメント・プラットフォーム「Throttl e」 新規事業を統合的に支援する イノベーションマネジメント プラットフォーム 大企業を中心に2,000社・ 5万人以上が導入／利用する 国内シェアNo.1のSaaS Copyright © 2026 Relic Inc. All Rights Reserved. 「インキュベーションの民主化」を実現するべく、蓄積したナレッジやデータ等を クラウドで提供し、事業構想から仮説検証・事業化までのサポートをSaaS化。 3

Saa S型イノベーションマネ ジメント・プラットフォーム「Throttl e」 自律的なイノベーター人材育成と新規事業創出の仕組みの構築が可能 ・新規事業の基礎知識を習得し、その後事業案の作成、ブラッシュアップ、審査を実施することが可能 ・単なる知識習得にとどまらず、学びを事業案作成に活かす実践型の育成プログラムを設計・運用することが可能 ナレッジの蓄積 新規事業の基礎知識を学習 各社個別の新規事業のナレッジを蓄積 eラーニングを通じて学ぶ 評価やフィードバックを確認 AI壁打ち 不通過の原因や理由を理解 起案者へのサポート ステージゲート設計 AIフィードバック 事業案の審査を実施 事業案をブラッシュアップ 事業検証 Copyright © 2026 Relic Inc. All Rights Reserved. 事業案が完成 事業案提出へ向けた準備完了 4

本日の流れ 1 会社概要 Relicの会社概要についてご説明 2 私が想う理想のプロダクト開発 Throttleのプロダクト開発から生まれた課題と課題から思う理想のプロダクト開発 3 全体設計 Claude Codeを軸にした検証と開発の全体像 4 各mdファイルの内容 私が使っているCLAUDE.mdやskillで必要なmdファイルについて 5 まとめ 今回の発表のまとめ Copyright © 2026 Relic Inc. All Rights Reserved. 5

基本情報 株式会社Relic（Relic Inc.） 2015年 イノベーションの民主化をミッションに 350名 5,400万円(資本準備金含む) 大企業〜スタートアップまで5,000社以上の 北嶋 貴朗（代表取締役CEO／Founder） 新規事業を支援/共創した実績を持つ 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー19F 国内シェアNo.1の事業共創カンパニー 大庭 亮 （代表取締役CTO／Co-Founder） 北海道：Sapporo Incubation Studio / Hakodate Innovation Port 宮城：Innovation Hub Sendai 埼玉：Kawagoe Innovation Terrace 千葉：Innovation Hub Kashiwanoha 富山：Toyama Development Base 静岡：Innovation Cross HAMAMATSU 愛知：Nagoya Incubation St udio 滋賀：SHIGA NE XUS LAB Vision Mission Value 京都：Kyoto Incubation Studio 大阪：Osaka Incubation Studio 兵庫：HYOGO VE NT URE FORGE 和歌山：Wakayama Innovation Lab / Growth Studio Shirahama 大志ある挑戦を創造し、 日本発の新規事業や 挑戦する人と企業の共創 島根：Matsue Innovation Square 広島：Hiroshima Incubation Studio 日本から世界へ イノベーションを共創する パートナーとして 愛媛：EHIME Incubation Field 想いを持った挑戦者と プラットフォームとなり日 最高のプロフェッショナル 共に走り、共に創る 本経済と地域を活性化する ×テクノロジーを提供する 福岡：Fukuoka Incubation Studio 沖縄：Naha Development Base / Nago Innovation Link ・JIS Q 27001:2025 (ISO/IEC 27001:2022+Amd 1:2024) ・労働者派遣事業 許可番号(派13-314462) ・有料職業紹介事業 許可番号(13-ユ-313432) ・全省庁統一資格 東 京本 社の み適 用 ・古物商許可 第303312515508号 https://relic. co.jp/ 6

事業内容 プロダクト/テクノロジー インキュ ベーションテック 新規事業開発に特化した プロフェッショナル、 プロダクト/テクノロジー、 投資/共同事業の三位一体で、 唯一無二のイノベーション マネジメントを提供 新規事業が生まれる仕組みや技術を 実装する新規事業支援に特化した SaaS型プラットフォーム。 オープン イノベー ション 事業プロ デュース プロフェッショナルサービス VC/CVCとしての投資/共同事業 新規事業の課題に一気通貫で伴走し、 解決／支援するトータルソリュー ション。 Relicが投資や協業を通じて当事者となり 事業を共創するオープンイノベーション。 7

Relic の強み・組織の特徴 インキュベーション戦略、組織 /制度設計、イノベーター人材育成 MA/C VC支援、出島共創スキームDUA Lii、Th rottle 開発/運営 オーダーメイド型新規事業開発プロジェクト /伴走支援 新規事業立ち上げから 現在私が所属している事業部 成長/拡大に特化した 日本最大級のBTC組織 領域特化型支援、レベニューシェア型事業開発、 出向起業 /カーブアウト支援、 ID EA TION Clou dの開発/運営 地方創生、地域イノベーション、中堅/中小企業 /自治体支援 事業承継やネクストプレナー支援 R elic としての新規事業開発/運営 ディープテックを軸にしたR &D戦略や新規事業開発、 大学発スタートアップ支援 クラウド、AI /L LM、ハードウェアを融合した 技術ソリューションの提供 事業価値探索を軸にしたプロトタイプ開発 ビジネス(B) ×テクノロジー(T) 技術/セキュリティ要件が高い開発案件において プロフェッショナルサービスを提供 デザイン思考、UI /UXデザイン、ブランディング 技術統括、生産性向上、エンジニア研修、エンジニア採用 /広報 パートナーアライアンス/渉外 ×クリエイティブ(C) が一体となったチーム により新規事業を共創 マーケティング/セールス、広報、採用 ブランドマネジメント、コーポレートブランディング 経営企画、アセット /ナレッジのマネジメント/利活用、 人材育成、シンクタンク DX /AX、システム開発プロジェクトのソリューション営業 コーポレートエンジニアリング /情報システム統括 コーポレート/バックオフィス 8

Relic が提唱する新規事業開 発プロセスの全体像 「3つのフェーズ・7つの検証項目・10のプロセス」に体系化 すべてのフェーズ/検証活動/プロセスに伴走して事業共創 Concept Creation 現状のThrottleの事業フェーズ （事業構想フェーズ：0→1） （事業創出／事業化フェーズ：1→10） フェーズ 検証項目 （成長／拡大〜完成フェーズ：10→100） Customer & Problem Value & Solution Product & Market Feasibility Scalability Sustainability Unifiability （顧客と課題） （提供価値と解決策） （製品と市場） (事業性／収益性) (成長・拡大可能性) (持続可能性) (戦略との親和性) Monet ize Grow th E xit Core プロセス Ins ight Define Ideat ion Protot yping Development Launc h 概要 深い洞察で顧客 や市場の課題を 課題の蓋然性を 検証し、定義す 課題を解決する アイデアを検討 アイデアを試作 品を活用して検 検証結果を踏ま えてプロダクト プロダクトを提 供し初期顧客を 発見する る する 証する を開発する 獲得する 課題の仮説が検 証によって蓋然 課題を解決する ための提供価値 商用プロダクト として提供でき プロダクトに満 足し継続利用す 性の高い事実に や機能の仮説を る品質や運営体 る顧客や市場が なっている 構築できている 制ができている 見つかっている 目指す状態 Complete 質の高い課題の 仮説を構築でき ている 顧客の受容性が あり課題を解決 できるプロダク ト要件が明確に なっている プロダクトを販 売し収益化する ユニットエコノ ミクスが成立し ている =LTV>CACの状 態になっている 投資によって事 業を成長・拡大 させる 持続的に成長可 能な構造を作る 市場／顧客を拡 大しても事業性 中長期的に成長 率を維持・拡大 や収益性が担保 できる算段が できている 立っている 中核領域の事業 として貢献性を 高める ビジョンや戦略 との親和性を高 めてシナジー創 出や全社KGI／ KPIに貢献できて いる 投資するリソース 不確実性 9

インサイト起点のプロダクト開発へ Claude Codeを軸に、ツール連携で回すPMの検証・開発サイクル Copyright © 2026 Relic Inc. All Rights Reserved. 10

新規事業への取り組み 状況 新規事業の取り組みは総じて拡大傾向（1,032社回答） 新規事業開発の取り組みに関する実態調査2025年, PwC Japanグループ 新規事業の主力事業化に成功している企業は1割程度（1,030社回答） 新規事業開発の取り組みに関する実態調査2025年, PwC Japanグループ 新規事業への取り組みは拡大する一方、成功確度は約2割に留まる ⇓ 生成AIの発展によりPMに求められる役割や期待値も変わりつつある 新規事業を成功させるためにもPMがプロジェクトマネジメントだけでなく、 より事業成果への貢献が求められるようになる Copyright © 2026 Relic Inc. All Rights Reserved. 11

新規事業への取り組み 状況 事業成果に踏み込んだPMの初めの一歩になれば幸いです。 Copyright © 2026 Relic Inc. All Rights Reserved. 12

前提となるプロダクト 開発 PM/PO目線で見たThrottleのプロダクト開発の全体像 5 リリースする エンジニア/デザイナー 4 1 仕様書をDevへ 連携する Biz/PM/PO 3 Copyright © 2026 Relic Inc. All Rights Reserved. 2 プロダクトを触る インサイトが 返ってくる クライアント インサイトを深掘る 13

新規プロダクト開発で の課題 商談やヒアリング結果を元にインサイトを整理したい 1 2 過去の商談やヒアリング結果を1つ1つ見直し出てきた課題を整理するのは時間がかかりすぎる。 ①の内容をもとに事業検証で設定した仮説が正しいか検証したい 事業検証を実施する上で設定した仮説と実際にクライアントから出てきた課題が合致しているかを検証したい。 ①②の内容と元に具体機能に落とし込みたい 3 検証結果を元にプロダクトのアップデートを進めたいが、検証結果とプロダクト開発がシームレスに繋がっていない 。 Copyright © 2026 Relic Inc. All Rights Reserved. ※新規事業のフェーズやターゲットによって新規プロダクト開発の課題は異なります。 14

私が想う理想のプロダ クト開発 クライアントから返ってきた「インサイト」を 最速で探索しプロダクトに反映できる状態 ▼解決策 Claude codeを活用して自動でインサイトを分析しインサイト をもとに検証設計や要件定義書を作成する Copyright © 2026 Relic Inc. All Rights Reserved. 15

インサイトとは？ 「インサイト」の定義 インサイトとは、消費者の行動や思惑、その背景にある意識構造を見抜くことによって得られる 「購買意欲の核心やツボ」のこと 表面的な課題ではなく、課題が発生する要因や原因を理解し構造を見抜くことが重要 表面的な課題で見ると各社から上がる課題は共通していないように思えるが、インサイトで見ると、 共通した構造的な課題が見えてくる インサイトを探索するには、「ターゲットの課題」と「仮説」が必要 【例】 ターゲットの課題 新規事業をなかなか事業化できない 仮説 顧客起点やマーケット起点で課題を発見したり、アイデアを発想できる人材がいない ことでそもそも事業性が低いアイデアが多い結果、事業化ができていないのでは？ Copyright © 2026 Relic Inc. All Rights Reserved. 引用元：https://www.synergy-marketing.co.jp/glossary/insight/ 16

• https://www.synergy-marketing.co.jp/glossary/insight/

インサイト起点のプロ ダクト開発をする前に... • 大前提となる事業検証の設計(仮説設計)がしっかり定義できていない上でAIを使って分析をし ても意図するアウトプットは出てこない • まずは「何を検証するのか」「何を分析するのか」を定義し設計する • その上でスキルの設計と作成に進んでいく ①事業検証設計 ・どんな課題を持ったターゲットに対し、何を検証するのか？ ②事業分析設計 ・事業検証設計をベースに、Claude codeで何を情報元とし何を分析させるのか？ ③ディレクトリ/スキル設計 ・Claude codeで分析するスキル設計と出力先の設計 ④スキル作成 ・設計したスキルの作成 Copyright © 2026 Relic Inc. All Rights Reserved. 17

全体設計 Copyright © 2026 Relic Inc. All Rights Reserved. 18

全体構成図 データ ソース Circleback Slack/Gmail/Hubspot Google Drive • 商談やヒアリングの録画 • 議事録生成 • 商談のサマリーの把握 • ネクストアクションの把握 • 検証設計の読み込み • サービス紹介資料の読み込み MCP で接続（読み取り） Claude Code 実行環境 定義ファイル 実行する処理 • CLAUDE.md ／ SKILL.md ／ references/ • 読み込み → 仕分け → 判定 → 書き出し 書き出し 出力先 outputs 仕様書作成 • 週次と月次で個別サマリを生成 • Q単位等の横断レポートを生成 • outputsで出力された内容をもとに新 機能または機能アップデートの仕様書 を作成 Copyright © 2026 Relic Inc. All Rights Reserved. 検証設計アップデート 検証ログへの記載 • インサイトをもとに検証設計アップ デート • 検証ログシートへの記載 19

(再掲載)ステップ ①事業検証設計 ・どんな課題を持ったターゲットに対し、何を検証するのか？ ②事業分析設計 ・事業検証設計をベースに、Claude codeで何を情報元とし何を分析させるのか？ ③ディレクトリ/スキル設計 ・Claude codeで分析するスキル設計と出力先の設計 ④スキル作成 ・設計したスキルの作成 Copyright © 2026 Relic Inc. All Rights Reserved. 20

事業検証設計 • 理想の状態(ゴール)から逆算して事業検証設計を実施 • プロダクトのフェーズに合わせて、検証目的を設計 決めること 答えを出しておくべき問い 1 理想の状態 この事業が成り立ったとき、顧客はどうなっているか 何のための検証か、途中で見失う 2 ターゲットの条件 どんな業界・部署・規模なら当たると考えるか 当たり外れの理由を説明できない 3 検証目的 今回の検証で、何が言えるようになりたいか 検証結果の判断がつかない 4 課題と解決策の検証 どの課題に、どの機能を当てるつもりか Copyright © 2026 Relic Inc. All Rights Reserved. 決まっていないと、こうなる 要望が全部「新機能」に見える 21

事業分析設計 • 判断できる評価軸をもとに、分析を実施 • 証拠を定義することでハルシネーションを対策した上で結論まで提示 定義するもの 定義しないと、こうブレる 1 評価軸 何と突き合わせて判定するか 毎回ちがう物差しで判定され、前回と比較できない 2 証拠 何を根拠と認めるか 相槌が、課題が実在する根拠になってしまう 3 結論 どこまで言い切るか 「データ不足」と言えず、無理に結論が出る Copyright © 2026 Relic Inc. All Rights Reserved. 22

検証設計と事業分析設 計の内容をもとにディレクトリとスキルの設 計 役割 パス CLAUDE.md • 前提知識（プロジェクトの目的・プロダクト仕様・データソース） .claude/skills/ • 分析手順を定義するスキル • 商談分析・仮説検証スキル SKILL.md • 手順・判定方法・出力形式 references/hypotheses.md • 検証仮説の詳細 └ sdd-requirements • 要件定義書作成スキル SKILL.md • reportsの内容をもとに要件定義書の作成 • 分析結果の出力先 • 個別商談サマリ／週次リスト／横断分析レポート └ throttle-deal-analysis/ outputs/ └ reports/ Copyright © 2026 Relic Inc. All Rights Reserved. 23

各mdファイルの内容 Copyright © 2026 Relic Inc. All Rights Reserved. 24

references/*.md ― 判定の基準 事業検証の基礎情報を定義することで、検証結果をブレさせない 1 対象顧客の全体像 • 「顧客が置かれている状態」を複数パターンに分け、自社で解く/解 かないを明示するテーブル • 表面上は同じように見えても、実は対象外パターンを含めるのが要点 • 上位の目的・ビジョンとの接続を参考情報として添える 3 課題 × 解決策マップ • 大分類→小分類→当てる機能／打ち手→顧客の既存の代替手段の4列 構成 • 「既存の代替手段」列が痛みの強さを測る補助情報として機能する 2 セグメント軸ごとの仮説（業界／部署・役割／企業規模 等） • 各軸について「なぜこの軸を仮説として置いたか」と「そこで想定さ れる課題」をペアで記述 • 軸をまたいで共通して現れうる兆候があれば、横断的な注記として別 立てする 4 セグメント別の訴求ポイント • 「顧客の状態」「課題仮説」「訴求ポイント」 • 訴求ポイントを疑問形（〜が刺さるか？）で書くのが要点 • 断定文にすると「もう正しいこと」として読まれ、検証マイン ドが失われる .claude/skills/throttle-deal-analysis/references/*.md ## 1. 適用範囲の明示 ## 2. 対象顧客の全体像 ## 3. セグメント軸ごとの仮説 ## 4. 課題 × 解決策マップ ## 5. セグメント別の訴求ポイント Copyright © 2026 Relic Inc. All Rights Reserved. 25

deal-analys is ― 判断の手順 分析手順を固定することから、「課題の根拠」にすり替わらない 1 モード分岐 • 対象指定あり（企業名等） 2 セグメント仕分け • セグメント仕分け • 対象指定なし（期間・条件のみ） • セグメントA：検証対象 • 軸の指定あり（「◯◯業界は刺さってる ？」） • セグメントB ：既知の勝ちパターン 3 データ収集の優先順位 • 一次情報 → 補完情報(前後のやり取り) の 順で、「要約で代用しない」ことを明記 した収集フロー • 各セグメントに対し件数付きで明示 • Bで刺さったことをAの支持根拠に混ぜない 4 判定ロジック • 証拠強度ラベルを全ての証拠に付与 • 自発/誘発＋具体/相槌/不在 • 判定ラベル • 支持/部分支持/反証/データ不足 • 母数が少ない段階では「データ不 足」を積極的に使う 5 要望の分類 • 顧客発の要望を即座に「新機能要望」と しない • 4分類（既存機能で充足/既存機能の拡張 / 真の新機能 / 対象範囲外）に振り分ける テンプレートを固定フォーマット化 .claude/skills/throttle-deal-analysis/SKILL.md ## 1. モード分岐 ## 2. セグメント仕分け：判定に入る前の除外 ## 3. データ収集の優先順位 ## 4. 判定ロジック：証拠強度・出典・ラベル ## 5. 要望・シグナルの分類 ## 6. 出力テンプレート • 反証探しを必須ステップ化（仮説が間違 っている場合の証拠は何か） Copyright © 2026 Relic Inc. All Rights Reserved. 26

出力フォーマットを確 定 出力フォーマット(例) 1. ヘッダー — 作成日／対象範囲（母数・除外条件）／参照情報源／逐語まで降りた商談の明示 2. サマリ — 3〜5行の結論先出し 3. 利用文脈の内訳 — ①事業部利用／②プログラム運営／③ターゲット外に分類（母数はここで確定） 4. Q1判定表 — 業界／部署／企業規模ごとに「①該当社数・判定・根拠」 5. Q2判定 — 課題大分類ごとの自発言及の有無 6. Q3判定 — 機能ごとの訴求社数・反応・機能反応マトリクス 7. ①が成立する条件 — 前進企業の共通条件／進まなかった企業の要因分類 8. 主要検証項目状況 9. 商談の進め方への示唆 10. 新機能開発への示唆 — 優先度順、(a)既存機能で充足〜(d)プロダクト範囲外 の4分類＋証拠・強度・引用 11. 反証・仮説外の発見 12. 次に検証すべきこと Copyright © 2026 Relic Inc. All Rights Reserved. 27

sdd-require ments ― 要件定義書作成の手順 インサイトをもとに開発可能な要件定義書を作成 1 概要 • 誰のため/何を実現するかを記載 • 利用シーンも添える 4 ユーザーロール・権限 • 権限マトリクスで操作を明示、排他/併用 関係も記載 7 画面一覧 • 対象ロールと目的、新規か改修かを明記 2 目的・背景 • 現在の課題と解決策の方向性、設計時の 判断基準を整理 5 機能要件/非機能要件 • 本要件定義書で開発する機能の要件を 記載 • パフォーマンス/セキュリティ/可用性を 検証可能な数値 8 制約事項 • スコープ境界を明確化 • 初期リリース以降に開発する可能 性がある要件がある場合は記載 3 用語定義 • ビジネスドメインの用語を対象に定義 • 設計書ではないため、技術用語は記載し ない 6 ユーザーストーリー • 役割・目的・機能の3要素、「開発者とし て」は不可 .claude/skills/sdd-requirements/SKILL.md ## 1. 概要 ## 2. 目的・背景 ## 3. 用語定義 ## 4. ユーザーロール・権限 ## 5. 機能要件 ## 6. ユーザーストーリー ## 7. 画面一覧 ## 8. 非機能要件 ## 9. 制約事項 Copyright © 2026 Relic Inc. All Rights Reserved. 28

まとめ ― インサイトを回し続け る仕組みへ インサイト整理・検証設計・開発を1つのサイクルに繋ぐと、プロダクトが強くなる 1 商談・ヒアリング 検証の精度 顧客の生の声が返ってくる • インサイト整理のたびにレポートを生成し分析 • レポートをもとに検証設計をアップデート Circleback / Slack / HubSpot デプロイして、また触ってもらう 開発の速度 4 開発 Claude Code 要件定義書から実装へ MCPで各ツールと接続 sdd-requirements 2 インサイト整理 証拠強度で判定する throttle-deal-analysis • インサイトが要件定義書の起点になる • 検証目的を設計した上で開発を実施すること でリリース後のトラッキングすべき指標も 明確になる 事業判断 3 検証設計の更新 • 投資と撤退の判断材料が揃う 検証設計のアップデート references/hypotheses.md Copyright © 2026 Relic Inc. All Rights Reserved. 29