スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜

2025年7月3日に開催された「開発生産性Conference 2025」で、セカンダリー事業エンジニア 田中, 佐野が発表した資料です。

Transcript

1. スタートアップに 選択肢を 生成AIを活用した セカンダリー事業への挑戦 開発生産性カンファレンス 2025 Nstock株式会社
2. 本日お伝えしたいこと 厳しい制約下での開発プロセス改善と生成AI活用の実践 セカンダリー事業（非上場株式取引） という前例の少ない領域で、厳格な金融基準 とタイトなスケジュール（約1 年でのローンチ） という制約下での挑戦 スクラムから効率重視の開発体制への転換 を経て、Devin・Claude を中心とした生成AI戦略的活用 で 開発速度 向上 を実現 さらに 全社展開 で組織全体の生産性向上を目指す実践知見を共有
3. 本日のアジェンダ 前半：プロジェクト概要と課題認識 セカンダリー事業の制約・特殊性 スクラム採用から方針転換までの経緯 後半：生成AI活用と組織展開 Devin・Claudeを中心とした開発効率化の具体事例 全社展開の戦略と実践 今後の展望と学び
4. 発表者 田中 清 - 前半担当 Nstock株式会社 セカンダリー事業部 エンジニア 2024年8月入社 佐野 智章 - 後半担当 Nstock株式会社 セカンダリー事業部 エンジニア 2022年4月入社
5. プロジェクトの概要 セカンダリー事業とは 非上場株式のセカンダリー市場 スタートアップなどの株式を、非上場時に売買できる取引所を立ち上げる事業です。 ※通常の株式市場と違い、非上場時での売買が可能となります。 何ができるようになるか？ 役員・従業員が 上場前にストックオプションを換金 できる 期待できる効果は？ 行使期限に左右されず IPO時期を柔軟に選択 優秀な人材がスタートアップにチャレンジしやすい環境 を実現
6. なぜ今必要か？ 日本のスタートアップエコシステムをブーストするために 役員・従業員の 報酬の選択肢を広げる 優秀な人材のスタートアップ参画 を促進 スモールIPOを避け、事業を「じっくり大きく」成長 → より多くの人が チャレンジできる環境 を創る スタートアップエコシステムの活性化には、優秀な人材がリスクを取りやすい環境が不可欠
7. プロジェクトの制約と特徴 3つの主要制約 金融規制の厳格さ 金商法対応、システム監査、コンプライアンス体制の構築が必要 前例のないドメイン設計 非上場株式セカンダリー取引所の要件・仕様をゼロから構築 タイトなスケジュール 2025年夏〜秋頃のローンチを目指し、約1年での開発・業登録・体制構築 開発開始期 2024年6-7⽉ プロセス変更期 2024年8-11⽉ スクラム導⼊ 透明性重視 オフサイト実施 開発体制転換 活⽤期 年 ⽉以降 AI 2025 1 ・ 導⼊ 全社展開 Devin Claude
8. 前半パートでお伝えしたいこと 制約下での開発手法の柔軟な選択 2024/6〜2024/12末頃までの、生成AI本格導入前のお話がメインです 私たちが直面した現実 理想とした開発手法（スクラム） から 実効性重視 への転換 透明性とスピードのトレードオフ を理解した判断 数値と事実に基づく意思決定 の実践 これから詳しくお伝えする内容 スクラム採用の理由と期待した効果 徐々に浮上する課題と決定的な瞬間 「教科書通りじゃなくていい」 という決断の背景
9. 不確実性が高い中でも確実な選択を 開発プロセスの戦略的判断
10. プロジェクト特性の分析とスクラム採用の判断 プロジェクト特性の整理と開発プロジェクト準備（6-7月） プロジェクトの特性 お手本のない非上場株式セカンダリー取引所構築 金融規制を理解した上での複雑なドメイン知識（金商法対応） 市場投入の時間的制約：市場機会の獲得が急務 プロジェクトが抱える課題 要件定義の確定が難しく、オペレーション設計、システム開発も並行で進める必要がある 事業的にも市場投入までをスピード感を持って進める必要がある
11. スクラム採用の理由と実践への期待 各専門領域の知識統合によるアジャイル開発（7-8月） プロジェクト特有の課題とスクラムの価値 金融規制の複雑性：金商法対応の要件が頻繁に変更される中での透明性確保 複数部署の連携：エンジニア・PdM・法務・運用の専門知識を統合する必要性 市場投入のスピード：要件変更に迅速に対応しながら開発を加速する要求 スクラムを選んだ理由 透明性 リファインメントで全員が状況を把握し、規制変更への対応を迅速化 適応性：スプリントごとに方向修正し、市場ニーズの変化に対応 リスク軽減：早期の課題発見と迅速な対応により、プロジェクト失敗リスクを最小化
12. スクラム実践の確かな成果 透明性がもたらした価値（8-10月） リファインメントの威力 バックログアイテムの詳細化 → 見積もり精度向上 → 優先順位の明確化 2時間の枠内で認識のズレを その場で解消、スプリントプランニングを効率化 仕様の曖昧さを大幅に削減：後工程での仕様変更が約30%減少 レトロスペクティブの文化 プロセス改善の継続的な取り組み：月次で改善アイデアを収集・実装 チーム全体での振り返りと改善提案の検討 心理的安全性の確立：失敗を隠さず、改善の糧として共有する文化 「みんなで作っている感」が醸成された
13. 「みんなで作っている感」 チーム一体感の醸成だけでは足りなかった
14. 徐々に浮上する課題の兆候 会議時間の増加が開発のボトルネックに（10月頃） 週あたり約5時間のスクラムイベント リファインメント：2時間〜 スプリントプランニング：1時間 デイリースクラム：1.5時間 レトロスペクティブ：1時間 段階的に深刻化する影響 開発時間の圧迫：週の15%を会議が占め、特にリファインメントの時間が増加 チームからの懸念：「会議ばかりで開発が進まないが、これって大丈夫なのか？」という疑問が増加 透明性とスピードのトレードオフ：情報共有の質は向上したが、開発速度が低下
15. 決定的な瞬間：オフサイトミーティング 2024年11月、衝撃の見積もり結果 残り工数の詳細見積もり 後半エピックの全体見積もり：残りの開発項目をストーリーポイントで詳細に算出 現在のベロシティで計算：実際の開発速度を基準にした現実的な予測 結果：目標スコープに2〜3倍の工数が必要（6ヶ月→18ヶ月） チーム全員が直面した現実 衝撃の数値：予想を大幅に上回る工数に全員が絶句 共通の認識： 「このままでは絶対に間に合わない」
16. 理想を捨てる勇気 スクラム文化 vs 確実な成果
17. 開発プロセスを変える決断 理想と現実の狭間での選択（11月） 2つの選択肢とその重み A案：現状維持で突き進む 情報の透明性は維持されるが、確実にスケジュール遅延（6ヶ月→18ヶ月） B案：開発プロセスを根本から変える スピードアップの可能性はあるが、これまで構築したスクラム文化を捨てる覚悟が必要 属人化リスク：知識が個人に集中し、チーム全体での共有が後回しになる チーム全員での議論と合意 現実を直視し率直に意見を出し合った結果、理想的なプロセスよりも確実に成果を出すことを優先する事で 合意
18. プロセス変更の本質：アジリティの継続 スクラム廃止でも失わなかった価値 重要な気づき：手段と価値の分離 スクラムプロセスは廃止したが、アジリティ（変化への対応力）は継続 「教科書通りのスクラム」ではなく、状況に応じた柔軟な方針転換こそが本質 継続した3つの価値 継続的改善の姿勢：月次振り返りでプロセスを見直し、さらなる最適化を追求 迅速な意思決定：デイリー後の即時集まりで方向修正し、機会損失を最小化 チーム間連携：並列開発でも概要レベルの情報共有は継続し、全体最適を維持
19. 具体的な実践：3チーム並列開発体制 スピード重視の組織設計（11月〜） チーム編成の戦略 Epic単位でのチーム分割：関連機能をまとめて各チーム（1〜2名）が担当 柔軟な再編成：1〜2ヶ月ごとに優先度に応じて調整 リーダー制：各チームに意思決定権限を集中 属人性を許容した戦略と効果 知識共有の戦略的延期：「今はスピード、知識共有は後で」という明確な優先順位 専門性の深化：各チームが担当領域に特化し、深い知識を蓄積 意思決定の迅速化：チーム内での合意形成により、即座に判断可能
20. エンジニアの役割拡大：技術×業務の融合 要件定義から実装まで一貫した責任（11月〜） エンジニアの新たな役割と成果 要件定義への積極参加：PdMと協働し、技術的実現可能性を早期に検証 技術的観点からの提案：実装可能な仕様設計と業務設計の同時最適化 要件の実現可能性向上：技術的制約を早期に発見し、設計段階で解決 開発工数の削減：後工程での仕様変更を大幅に減少 迅速な意思決定とリスク管理 デイリーミーティング後の即時判断：必要メンバーのみで迅速な意思決定 仕様ズレの早期発見：各チームの進捗を毎日共有し、問題を事前に回避 リスクの共有と対策：課題を隠さず、全員で解決策を検討
21. 不安から自信へ 笑いが起きる余裕
22. プロセス改善の確かな成果 チームの変化：不安から自信へ（12月） スケジュール棚卸し会議での変化 3-4ヶ月前：不安だらけの議論 年末：笑いが起きる余裕。各メンバーが自信を持ってリスクも楽しめる雰囲気に 数値が示す改善効果 開発速度：約2倍以上に向上 意思決定スピード：即日〜翌日 チーム満足度：大幅に改善 プロセス改善により、数値と雰囲気の両面で確実な成果を実現
23. 前半のまとめ 学んだ3つの教訓 1. 手段にとらわれず、目的に立ち返る スクラムはあくまで手段。状況やフェーズに応じて、最適なプロセスを選び直す柔軟さが重要 2. データに基づく迅速な意思決定 理想や慣習に流されず、見積もり結果や数値データを重視し、大きな方針転換を恐れず実行した 3. 組織全体の連携による相乗効果 部署や役割を超えた連携と迅速な意思決定により、開発速度を約2倍向上させることができた
24. 次のステップ：生成AIによるさらなる加速 2024年末時点での成果と新たな壁 プロセス改善による確かな成果 開発速度約2倍向上により、プロダクトは着実に前進 組織全体の連携強化で、チームの士気も大幅に改善 しかし、新たな課題が浮上 機能開発以外のタスク：システム監査・テスト・要件変更対応 人的リソースの限界：現在の体制ではさらなる加速が困難 リリースに向けたリスク：不透明な部分が依然として残存 生成AIという突破口 従来の開発手法では到達できない次元の生産性向上を目指し、生成AIを戦略的に導入します。（後半パートへ続く）
25. 本日のアジェンダ 前半：プロジェクト概要と課題認識 セカンダリー事業の制約・特殊性 スクラム採用から方針転換までの経緯 後半：生成AI活用と組織展開 => Devin・Claudeを中心とした開発効率化の具体事例 全社展開の戦略と実践 今後の展望と学び
26. Devin・Claudeを中心とした開発効率化の具体事例 目次 年末時点での生成AI利用状況 現在までの生成AI導入例と意思決定 開発への生成AI導入で得られた学び
27. 年末時点での生成AIの導入状況 一部の生成AIツールの利用を開始済 LLM ChatGPT：ベストプラクティス相談 Claude：コード生成 コード補完系 GitHub Copilot：IDE上でコード補完
28. 当時の生成AI利用の課題感 人が駆動し続ける必要性 コード補完でもタブを押し続ける必要はある ChatGPTの結果を受け、改修は人が担当するなど 文脈を都度渡す必要がある ChatGPT：文脈情報を都度与える必要があった コード補完：タブで開いた範囲の情報のみ利用していた
29. Devin・Claudeを中心とした開発効率化の具体事例 目次 年末時点での生成AI利用状況 現在までの生成AI導入例と意思決定 開発への生成AI導入で得られた学び
30. 現在までの生成AI導入例と意思決定 何をいつ導入したか 1月: Devin導入 3月: Claude全社展開 5月: Claude Code導入 意思決定 従量課金の生成AIツールの予算方針
31. 1月: Devin導入 Devin 自律型AIプログラマ 新たな開発スタイルに注目 指示を出したらGitHubでPRを出す Slackから指示を出せる 懸念は従量課金 Devinは従量課金で天井知らずになる懸念 既存の生成AIツールはシート数固定課金
32. 従量課金の開発向けAIツールに対する方針策定 エンジニアを採用するようなものと考える 生産性を1.5~2倍に高め自律して動く 並列してスケールする(工夫はいるが) 今後類似サービスが出現・効率化が進むと予想 詳しくはPodcastで Nstockのテックラジオ#14 Welcome, Devin!
33. Devin導入で達成できたこと テストカバレッジ向上：35% => 60%へ オペレータ用管理サービスの開発を高速化 デザイナー・PdMが微調整や仕様確認に利用するように
34. テストカバレッジ向上: 35% => 60%へ 背景 外部システム監査の観点で、テストカバレッジを高める必要あり domain層はあるがusecase層は薄いなどカバレッジにムラ
35. テストカバレッジ向上: 35% => 60%へ 工夫 Devin searchでテスト不足の箇所を洗い出し その箇所に゙ 対応するテスト作成の参考となるコードをナレッジ化 Devinを並列実行して、テストのカバレッジを上げた => 見積もりでは1ヶ月かかる予定が1週間で実現
36. オペレータ向け社内管理サービス開発を効率化 背景 オペレータ: 社内で業に係る業務を行う方 業務例: 本人確認の承認・取引情報の登録など この業務を支援する社内管理サービスが必要 一部は開発済みで開発方針・規約は定まっていた リソースのCRUD処理を担う画面など比較的単純な実装が多い
37. オペレータ向け社内管理サービス開発の工夫 工夫 タスクを、理解する文脈が少なくて済むように分割 難しいとタスク当たりの最大使用リソースを使い切り、PRを出せない 1機能をbackend / frontendで依頼タスクを分割 類似のAPIや画面のファイル名を参考にするように指示 外部サービス連携の場合、サービス名を入れると良い出力に 今年のコミット数：生成AIが30.5%
38. 副次的な効果: デザイナー・PdMがUI修正・仕様確認
39. 3月: Claude全社展開 一部エンジニアがトライアルし効果を確認 利用枠が増えるので全社で契約
40. Claude活用事例: 規程の作成支援 背景 金融事業用の規程の作成が必要 システムリスク管理規程（7ページ約7,000文字）はじめ、同規模が5件 ネット上のテンプレートは内容が古い・網羅性が低い場合あり 工夫 ステップに分ける: 素案作成 => 詳細確認・修正 => 整形 素案作成と詳細確認で、人手と比べ体感8割以上の時間削減 2〜3ヶ月かかる想定 => 2週間程で終了
41. 素案作成プロンプトの一部抜粋 Nstock というシリーズAの Fintech 系スタートアップにおいて 株式報酬やストックオプションを管理する SaaS、 スタートアップのための非上場株式の取引所の開発を行っています。 今回、「システムリスク管理規程」を策定しようとしているので、その内容を提案してください。 特に、CISコントロールや金融庁の監督指針、FISC の安全対策などのプラクティスを考慮することを期待しています。 ただし具体的な記述は不要で、 全体感を把握できる目次や箇条書きのようなものであれば十分です。
42. 5月: Claude Codeの導入 Claude Code Devinと同様の自律型プログラマ 即座にマージ可能なレベルのアウトプット 使用量に応じてMaxプランに
43. Claude Code活用事例: レビューコストの圧縮 背景 自律プログラマ利用でPR量が増え、レビューが大変 特徴 GitHub Appを設定すると、コメント欄でメンション可能
45. Claude Code導入の工夫 整理した知識ベースをそのまま活用可能 Claude導入時に、設計の壁打ち用に整備した抽象度の高い知識が活きた Devinは併用 Slackからの修正依頼ができるのでPdM,デザイナーが利用
46. Devin・Claudeを中心とした開発効率化の具体事例 目次 年末時点での生成AI利用状況 現在までの生成AI導入例と意思決定 開発への生成AI導入で得られた学び
47. 学び: 進化が速いので切り替えやすくする 生成AI予算を人件費と捉える 人件費と捉えると考え方が変わる、ツール切替しやすく 知識は自前で管理する 知識はツール側でなく、できるだけ自前で管理 試せる体制を用意する 新しいパラダイムは試して価値がわかる その感覚は人によって違うため、試せる体制は用意
48. 本日のアジェンダ 前半：プロジェクト概要と課題認識 セカンダリー事業の制約・特殊性 スクラム採用から方針転換までの経緯 後半：生成AI活用と組織展開 Devin・Claudeを中心とした開発効率化の具体事例 =>全社展開の戦略と実践 今後の展望と学び
49. 全社展開の背景 エンジニアの生産性は上がったが... エンジニアが先行して生成AIを取り入れ、生産性は向上 同時期に他職種の希望者にChatGPT/Claudeはアカウントを付与 実務への応用例が少なかった
50. 全社展開の背景2 開発以外の面で、アウトカムへ貢献 価値を提供するのは開発だけではない セカンダリー事業：法務・オペレーションチームと連携 全職種の生産性を高めることで、よりスピーディに価値提供できるはず 「でもどうしたら？」 全社へ生成AIを浸透させるために、取り組んだこと
51. これから話すこと 社内でいろいろ試した結果を、今振り返ってまとめたもの 最初から筋道立てて分かってはいない 一人がリードしたのではなく、様々なメンバーが貢献した内容
52. 全社に生成AIをenablingする上のポイント 事例情報の流れを整える 対応する組織 文化・経営層のコミット
53. 事例情報の流れを整える 社内を観察すると... どんどん試す人は一部いる その人の現実の仕事を解いてる様子を知ると伝播する => 解き方が伝わる場・流れを整えると広まる
54. 伝播の具体例 ライティング業務へのClaudeの利用 マーケティングチームはオウンドメディアの記事を担当 試しにClaudeで文字起こし結果からインタビュー記事の初稿を依頼 チームの定例で共有したところ、社長がプレスリリース初稿にClaudeを利用
55. 流れを整える1: All Handsでのワークショップ 背景 ツールは配った & 説明会もしたが、仕事への応用はまだ 時間を取って考える・利用シーンを伝える場を用意したほうがよい
56. 流れを整える1: All Handsでのワークショップ ワークショップの内容 現実の問題: 各職種が現実の問題を出す 問題の解き方: LLM試してる人がその場でプロトタイプ・やり方を示す => アイデアをもとに実運用へ 詳しくはPodcastで Nstockのラジオ #99 生成AIをテーマにすごいAll Handsしてみた！
57. 例: 社内ドメインエキスパートへのQ&Aの自動化 背景 複雑なドメイン知識が、開発・運用に必要 ドメインエキスパートに質問できるが、社員増に伴い似た質問が増加 ドメインエキスパートが打ち合わせ同席するので即応が難しい 解決策 既出質問の検索・返答をNotebookLMでプロトタイプ その後、質問を継続的に貯める + ユーザー評価を追加するためにSlack botの実装中
58. NotebookLMでのプロトタイプ Slack bot
59. 流れを整える2: 全社向け生成AIチャンネルの設置 背景 生成AIに関する情報キャッチアップが大変 流量が多い / 選別が必要 / 毎日状況が変わる 結局見ない、となるのは避けたい 投稿に縛りを設けたSlackチャンネルを設置 試してみてよかったtipsを投稿 これはマジでタメになる、の情報シェア(tips溢れすぎへの対策) 困ってる内容の投稿 + そこへのサポート
60. 流れを整える3: 生成AIオフィスアワーの実施 背景 利用状況のヒアリングを実施 「やりたいことはあるんだけど、家庭教師のように相談したい」 現実の問題 => 問題の解き方のブリッジが足りない 週１時間、相談を受け付けるオフィスアワーを設置 仕事の相談を受け、その場でやり方を見せる 解決に時間がかかるものは、一時受けをして追って対応
61. 全社に生成AIをenablingする上のポイント 事例情報の流れを整える 対応する組織 文化・経営層のコミット
62. 対応する組織: 専任チームがあった方が良い 当初有志の会で実施し、専任チームを設置予定 手を動かす時間が必要で、業務時間とかち合う ヒアリング, オフィスアワー 新しいツールの検証 既存ツールの性能改善の試行 浸透が進むと他のニーズも集まる 生成AIは、全社の採用・事業戦略にも影響 プロダクト化のためのR&D
63. 全社に生成AIをenablingする上のポイント 事例情報の流れを整える 対応する組織 文化・経営層のコミット
64. 文化・経営層のコミット 文化 新しいものを取り入れる・試す人がいる 得た知見を共有してくれる 経営層のコミット Devin導入前には、他社事例を社長が共有 ClaudeやDeep Researchを進んで試す ツールと考えず人件費と考える予算 これ自体は弊社固有かもしれないが、そういう場所を用意した方が進む
65. まとめ 私たちの軌跡 事業の制約・特殊性を踏まえ、開発プロセスを方針転換 生成AIも取り入れ加速 全社展開で組織全体の生産性向上を目指した 事業・全社の組織の変化のお話 問題の観察・分析・対応を愚直に行った わからない恐れはあれど「一旦試す」姿勢が役立った 今後も状況は変化しそう、この姿勢を保ちたい
66. スタートアップに選択肢を創る挑戦 ご清聴ありがとうございました
67. 告知 本日 開発生産性カンファレンス Drink UP！!
68. 告知 CHUO_Tech Vibe Coding について語ろう！