正しい技術選定がPMFを加速する〜なぜ、エンジニアが顧客と話すべきか︖〜

or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 正しい技術選定がPMFを加速する〜なぜ、エンジニアが顧客と話すべきか︖〜 Yuta Okoshi 1 1 : 3 0 A M ~ 1 1 : 5 5 A M Startup Solutions Architect

or its affiliates. All rights reserved. Who are you? ⼤越雄太 Startup Solutions Architect / AWS スタートアップ事業本部シード/アーリーステージのスタートアップのPMF実現を⽀援し、CxO やエンジニアへの技術的・⾮技術的なアドバイザリーや情報発信を⾏いながら、⽇本のスタートアップエコシステムの発展に貢献している。 @cossy70461807

or its affiliates. All rights reserved. • 起業家を技術⾯で補完する重要性が増⼤ • 仮説検証と計画的技術負債のバランス感覚 • 技術とビジネス両⽅を理解した意思決定 • エンジニアリング知識がないまま⽣成AIを使う時間が増加 • 最も重要な仮説検証の時間が不⾜ • ⻑期的な技術選定や拡張性を考慮した設計ができない⽣成AI時代に求められるエンジニアの役割 4 起業家が直⾯する課題エンジニアが果たすべき役割「エンジニアは仮説検証に最適な技術を選定する」

or its affiliates. All rights reserved. 7 架空のスタートアップ︓「NeighborLink」 CEO⽥中さんの原体験「ある⽇、下の⼦が急に40度の熱を出したんです。主⼈は出張中で、薬も切れていて…でも近所に頼れる⼈がいなくて本当に困りました」アイデア「近隣住⺠同⼠マッチングプラットフォーム」皆さんもNeighborLinkのエンジニアになったつもりで⼀緒に考えていきましょう ※「NeighborLink」は架空のスタートアップです。

or its affiliates. All rights reserved. 15 架空事例「NeighborLink」①︓顧客課題のギャップ当初の仮説世代間マッチング・共働き→⾼齢者の⼀⽅的な依頼・⾦銭による対価・公式な依頼プロセス実際のニーズコミュニティ型相互⽀援・同世代含む多⽅向の助け合い・⼼理的ハードルの低減が鍵・気軽なきっかけづくりヒアリング⾼度なマッチングアルゴリズムではなく、「顔を合わせるきっかけ作り」と「気軽に頼める仕組み」を軸に

or its affiliates. All rights reserved. 18 なぜ⾔語化とチームで合意が重要なのか︖ → それは実際のスタートアップで起こる典型的な失敗パターンを防ぐため § 例えば – 顧客体験の⾔語化がないと⼀貫性のない顧客体験に – 創業初期のリソース不⾜時に認識のズレがあると取り返しがつかない – 無意識の前提による開発⽅向のバラつきを防⽌できる理想の顧客体験を⾔語化しチームで合意ができているか︖

or its affiliates. All rights reserved. 19 なぜ⾔語化とチームで合意が重要なのか︖ それは実際のスタートアップで起こる典型的な失敗パターンを防ぐため § 例えば – 顧客体験の⾔語化がないと⼀貫性のない顧客体験に – 創業初期のリソース不⾜時に認識のズレがあると取り返しがつかない – 無意識の前提による開発⽅向のバラつきを防⽌できる理想の顧客体験を⾔語化しチームで合意ができているか︖ この認識のズレを創業初期の資⾦も⼈員も⾜りないときに犯すと取り返しのつかないことに

or its affiliates. All rights reserved. Working Backwards︓未来から逆算するプロダクト開発 20 Working Backwardsとは︖ – 「未来から逆算して考える」アプローチで、理想の顧客体験を⽰す – コードを書く前にPR/FAQを実際に書くことを推奨 PR/FAQの構成 § プレスリリース • 顧客の⼼に思いを馳せ、新製品・サービスの体験をイメージする § FAQ • 顧客に焦点を当てた質問（価格、故障時など） • 社内ステークホルダーに焦点を当てた質問（⽬標、ビジネス成果、差別化理由など） § ビジュアル • ⾔葉では伝えにくい顧客体験のイメージを伝える PR FAQ 顧客向け新製品・サービスの体験架空の顧客からのコメント社内向け Visual

or its affiliates. All rights reserved. AWS LambdaのPR/FAQ実例 21 引⽤元︓AWS Lambda turns 10: A rare look at the doc that started it https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at- the-doc-that-started-it.html

or its affiliates. All rights reserved. AWS LambdaのPR/FAQ実例 22 AWSサービスチームが発⾒した顧客課題 § ⼩さなコードを動かすためにも、EC2インスタンスを⽴ち上げて管理する必要がある § トラフィックがない時でも24時間サーバー代を払い続けなければならない § 突発的なアクセス増加に対応するため、常に余分なインスタンスを準備しておく必要がある § Auto Scalingの設定が複雑で、エンジニアがインフラ管理に多くの時間を取られる引⽤元︓AWS Lambda turns 10: A rare look at the doc that started it https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at- the-doc-that-started-it.html

or its affiliates. All rights reserved. AWS LambdaのPR/FAQ実例 23 PRの⼀部抜粋（意訳） – 「AWS Lambda により、開発者はサーバーの管理を⼀切せずに、コードの実⾏だけに集中できるようになりました。従来は数時間かかっていたインフラ準備が、今では数秒で完了します。また、実際にコードが実⾏された時間分だけの課⾦となるため、コストを⼤幅に削減できるケースも多数確認されています。」引⽤元︓AWS Lambda turns 10: A rare look at the doc that started it https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at- the-doc-that-started-it.html

or its affiliates. All rights reserved. AWS LambdaのPR/FAQ実例 24 FAQの⼀部抜粋（意訳） § 顧客向けFAQ – Q: 「従来のEC2インスタンスと何が違うのか︖」 – Q: 「技術的制約はあるのか︖」 – Q: 「従来のアーキテクチャからの移⾏は⼤変か︖」 § 社内向けFAQ︓ – Q: 「どんな顧客が最も喜ぶのか︖」 – Q: 「どのような場合に顧客に Lambda を使⽤しないよう指⽰すればよいですか?」 – Q: 「 Lambda の信条は何ですか?」引⽤元︓AWS Lambda turns 10: A rare look at the doc that started it https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at- the-doc-that-started-it.html

or its affiliates. All rights reserved. AWS LambdaのPR/FAQ実例 25 引⽤元︓AWS Lambda turns 10: A rare look at the doc that started it https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at- the-doc-that-started-it.html

or its affiliates. All rights reserved. 26 § 「今すぐこれを欲しがるのは誰だ︖」 § 「誰も聞いたことのない⼆⼈だけのスタートアップが作ったクソみたいなバージョン1でさえ使うほどにこれを欲しているのは誰だ︖」理想の顧客体験を⾔語化しチームで合意ができているか︖ 引⽤元︓Masa Kakinokiさん訳「スタートアップのアイデアを得る⽅法（原著者︓Paul Graham）」 https://medium.com/kakinoki-masato-no-blog/how-to-get-startup-ideas-by-paul-graham-4f8cdf1217b8 翻訳元︓Paul Gragan「How to Get Startup Ideas」 https://paulgraham.com/startupideas.html もしこれらが曖昧なら、コードを書く前に顧客課題と顧客体験の解像度を⾼めましょう

or its affiliates. All rights reserved. 27 プレスリリース概要 • 「NeighborLinkは、同じ地域に住む⼈同⼠が気軽にお⼿伝いを依頼・提供できるプラットフォームです。『荷物の受け取り』『ペットの散歩』『DIYの⼿伝い』など、⽇常の⼩さなお⼿伝いから始まり、段階的に信頼関係を築いていきます。」顧客向けFAQ • Q:「知らない⼈に家の中に⼊られるのは不安です」 • A:「まずは『⽞関先での荷物受け取り』など、プライベート空間に⼊らないお⼿伝いから始められます」社内向けFAQ: • Q:「なぜ広域のマッチングアプリではダメなのか︖」 • A:「地理的近接性（徒歩5分圏内）と継続的関係が信頼を⽣む。⼀回限りのサービスではなく『いつものあの⼈』になることで安⼼感を実現」架空事例「NeighborLink」②︓PR/FAQ

or its affiliates. All rights reserved. 30 PR/FAQ（仮説）論理的に構築された顧客体験の仮説 • 完璧な論理構成 • 内部チーム合意 • 理想的な顧客像なぜ仮説検証をする必要があるのか︖ PR/FAQをどんなに論理的に組み⽴てても、それはあくまでも仮説実際のユーザーフィードバック現実の顧客体験から得られる貴重なインサイト「このボタン何︖」「他のアプリの⽅が使いやすい」「使い⽅がわからん」仮説検証が必要

or its affiliates. All rights reserved. 架空事例「NeighborLink」③︓仮説検証 32 検証仮説 • 「近隣住⺠は『荷物受け取り』のような⼩さなお⼿伝いから始めれば、段階的に信頼関係を築いて継続利⽤してくれる」検証結果 • 「⼩さなお⼿伝いから始める」という前提⾃体が、ユーザーにとって「⼩さく」なかった。 • ⼼理的ハードルの⾼さを過⼩評価していた学んだ重要な洞察創業者たちが考えた「荷物受け取りは簡単なお⼿伝い」と、ユーザーが感じる「知らない⼈との初回接触は⼤きなハードル」に⼤きなギャップがあった。依頼の気軽さではなく、⼼理的安全性の確保が最優先課題だった。

or its affiliates. All rights reserved. なぜ技術選定が関係あるの︖ 34 • エンジニアリングの知識を活⽤し、短期間で多くの仮説を検証 • 最適な技術選定で柔軟かつ迅速にフィードバックを反映 • 顧客価値の早期発⾒と、PMF達成への近道を実現スタートアップに所属するエンジニアは技術的知⾒を活かし、学習サイクルを⼤幅に加速することができる重要なパートナー起業家の課題 • エンジニアリング知識を持った⼈が少ない • 技術的な壁により、仮説検証サイクルの速度が制限されるエンジニアの貢献

or its affiliates. All rights reserved. 学習サイクルの加速させる技術選定とは︖ 35 「コードを書く必要があるのか︖」を常に問い、マネージドサービスで代替できないか積極的に検討しましょう。 • 最も重要な3つの指標︓ § デプロイまでの時間（アイデア→本番︓数時間〜1⽇） § 機能追加・修正の速度（翌⽇改善リリース可能か） § 失敗の許容性（不要機能を簡単に削除・変更可能か）

or its affiliates. All rights reserved. 架空事例「NeighborLink」④︓スピード重視の技術選定 39 新しい仮説︓ • 「信頼情報(顔写真と過去評価)の可視化機能」を最短で検証する Next.js on Vercel （⾼速プロトタイピング、簡単デプロイ） Supabase （ユーザープロフィール管理 + 認証 + 画像ストレージ） CTO「今週は『プロフィールを⾒て安⼼できるか』だけに集中。1週間後に再度ユーザーヒアリングして、⼼理的ハードルが下がったかを確認します」

or its affiliates. All rights reserved. PMFしている状態とは︖ 41 ⾃発的な活動ユーザーが⾃主的にイベントを企画⾼い継続率週3回以上のアクティブユーザーが急増⼝コミ拡散「うちでも使いたい」という問い合わせエンジニア視点だと？ • リクエスト数が1,000倍に跳ね上がる • 「◦◦の機能はないの？」という機能要望が殺到 • 障害が発⽣すると数分で問い合わせが殺到

or its affiliates. All rights reserved. PMF発⾒後の課題に対応できる、ビルディングブロックとは 44 持続可能な成⻑スケールに対応最⼩構成 PMF発⾒に集中段階的拡張成⻑に合わせて追加必要最⼩限から始めて段階的に拡張する設計で、成⻑に柔軟に対応コスト効率性 • 初期投資を最⼩化 • 段階的に投資を増やす開発速度 • 既存ブロックの再利⽤により、素早い実装が可能メンテナンス性 • 部分的な修正・変更が容易 • システム全体の安定性が向上ビルディングブロックアプローチの3つのメリット

or its affiliates. All rights reserved. 架空事例「NeighborLink」⑤︓PMF達成後の課題とOpportunity 45 開発課題 • 既存構成維持しながら機能追加 § IoT連携（荷物到着通知、在宅センサー） § パーソナライズ機能と地域イベント管理⾃治体連携 • ⾃治体からの公式アプリ化検討依頼 § 専⽤AWS環境とセキュリティ強化 § ⾏政システム連携⽤インターフェース

or its affiliates. All rights reserved. 架空事例「NeighborLink」⑤︓PMF達成後の課題とOpportunity 46 PMF前︓学習速度重視「動けばいい」段階 PMF後︓持続可能性重視「⽌まってはいけない」段階シンプルなコアシステム Next.js Vercel Supabase • 迅速な開発・デプロイ • 低コストでスピーディーな実験 • ユーザー基本機能のみ実装 • 個⼈ユーザー向けサービスシンプルなコアシステム Next.js Vercel Supabase 拡張モジュール（追加） AWS IoT Core スマートデバイス連携 Amazon Personalize レコメンド機能 Lambda + DynamoDB 拡張データ処理⾃治体向け環境（別テナント） AWS Organizations SecurityHub セキュリティ強化・完全分離環境世⽥⾕区役所向け公式アプリ

or its affiliates. All rights reserved. ビルディングブロックを考慮する上で⼤切なこと 47 1. ビルディングブロックアプローチ § 既製品の「仕様上できません」という制約を、ビルディングブロック型なら必要なコンポーネント組み合わせで解決。 § 技術的制約なしで競合差別化とスタートアップ成⻑を実現 2. ただし、技術投資タイミングの⾒極めも必要 § 早すぎると無駄なコスト、遅すぎると事業成⻑の⾜枷に。このバランス感覚がスタートアップエンジニアの腕の⾒せ所

or its affiliates. All rights reserved. まとめ︓PMFを⾒つけるまで 49 顧客課題を事実ベースで特定仮説ではなく事実に基づく顧客理解顧客インタビュー・⾏動観察顧客体験の⾔語化と合意チーム全体の共通認識形成 PR/FAQ・Working Backwards PoCを利⽤した仮説検証質の⾼いフィードバックの重要性ドッグフーディング・ユーザー検証１２３スピード重視の技術選定上記サイクルを加速させる PMF達成への近道︓顧客理解の深化と検証サイクルの⾼速化

or its affiliates. All rights reserved. 50 「PMF前に⾒つけた成⻑の種」を、「持続的に成⻑する強固なビジネスの幹」へ技術選定の視点転換 • 「動けばいい」→「⽌まってはいけない」 • 可⽤性と信頼性を重視した設計への移⾏ビルディングブロック導⼊ • 拡張性と再利⽤性の⾼い設計への転換 • コンポーネントの分離と再利⽤性向上まとめ︓PMFを持続させるためにビジネスの持続可能性 • 経済的持続性 • 運⽤持続性 • 開発持続性

正しい技術選定がPMFを加速する 〜なぜ、エンジニアが顧客と話すべきか︖〜

正しい技術選定がPMFを加速する 〜なぜ、エンジニアが顧客と話すべきか︖〜

More Decks by YutaOkoshi

Other Decks in Technology

Featured

Transcript

正しい技術選定がPMFを加速する〜なぜ、エンジニアが顧客と話すべきか︖〜

正しい技術選定がPMFを加速する〜なぜ、エンジニアが顧客と話すべきか︖〜