Slide 1

Slide 1 text

デザイナーとPdMが自分でデプロイする ― Amplify Hosting の PR プレビューで回す仮説検証 2026/08/25 Nokogiri@株式会社カケハシ AWS Amplify 事例紹介 - Amplify Boost Up #11 ©KAKEHASHI inc.

Slide 2

Slide 2 text

自己紹介 Nokogiri(@nkgrnkgr) X | Bluesky | Github 株式会社カケハシ ソフトウェアエンジニア(主にフロントエンド) React / TypeScript / フロントエンド大好き! 二児の父👶 ポケモン対戦大好き! ©KAKEHASHI inc. 2

Slide 3

Slide 3 text

会社紹介 株式会社カケハシとは ● ヘルステックスタートアップ ● 主に調剤薬局向けの業務システムを提供 ● クラウド型電子薬歴「Musubi」のほか、複数プ ロダクトを開発・提供し、グループ全体で国内の 薬局の14,000店舗超をカバー ©KAKEHASHI inc. 3

Slide 4

Slide 4 text

1 今日話すこと ©KAKEHASHI inc. 4

Slide 5

Slide 5 text

今日話すこと カケハシでの AWS Amplify 活用事例を一つ紹介 新しいプロダクトの開発チームの働き方が大きく変わった話 ● デザイナーとPdMが自分でブランチを切り、PRを出し、Basic認証つきのプレビューURLをステー クホルダーに配っている ● 要件検討フェーズでFigmaを使っていない ● これを支えているのが生成AIとデザインシステムと運用ルール、そして Amplify Hosting ©KAKEHASHI inc. 5

Slide 6

Slide 6 text

2 プロダクトの高速な仮説検証目指して ©KAKEHASHI inc. 6

Slide 7

Slide 7 text

プロダクトの高速な仮説検証目指して 今回紹介する事例の開発背景 ● 新規案件 ● 要件が複雑 ● ステークホルダーが多い 不確実性が高い開発 ©KAKEHASHI inc. 7

Slide 8

Slide 8 text

プロダクトの高速な仮説検証目指して 従来の開発手法 ● PdMとデザイナーで議論し、Figmaを使って画面やUIのサンプルを作る ● 仕様に関してはドキュメントで整理 ● エンジニアは上記をインプットとして画面を開発していた 途中まで従来通りのやり方で進めていた時 ● Figmaやドキュメントを元に仕様を議論していたが空中戦になりがちだった ● コンセプトレベルのスライドしかなく、ステークホルダーからしっかりとしたフィードバックももらいづ らい ©KAKEHASHI inc. 8

Slide 9

Slide 9 text

プロダクトの高速な仮説検証目指して 立てた2つの仮説 ● 素早く動くものを見ながら議論すれば、意思決定を早くできるのではないか ● 生成AIの登場によって、従来のやり方より高速にプロトタイプを作れるのではないか ©KAKEHASHI inc. 9

Slide 10

Slide 10 text

プロダクトの高速な仮説検証目指して 整えた環境 ● 非エンジニア向けセットアップ ○ ● AIを使うためのイネーブルメント ○ ● PC セットアップ、ローカル環境構築、GitHub アカウント、AI コーディングツール(Cursor) 勉強会とハンズオン、段階的な指示の出し方、ターミナルのエラーへの対処 コードベース側の準備 ○ デザインシステム、プロトタイプ専用ディレクトリ、Agent Skill + AWS Amplify によるPRごとのプレビュー環境 ©KAKEHASHI inc. 10

Slide 11

Slide 11 text

3 PRを出すとURLができる仕組み ©KAKEHASHI inc. 11

Slide 12

Slide 12 text

PRを出すとURLができる仕組み ©KAKEHASHI inc. 12

Slide 13

Slide 13 text

PRを出すとURLができる仕組み amplify.yml の内容 ©KAKEHASHI inc. 13

Slide 14

Slide 14 text

PRを出すとURLができる仕組み StorybookもPRごとに環境作成 ©KAKEHASHI inc. 14

Slide 15

Slide 15 text

4 プレビューがどう使われているか ©KAKEHASHI inc. 15

Slide 16

Slide 16 text

プレビューがどう使われているか ケース1:仕様の決定 ● PdMが自分でプロトタイプを作成し、思考を具体化 ● デザイナーは実コードベースでプロトタイプを作成しブラッシュアップ ● エンジニアが一緒にモブで入って技術的なアドバイスをしたり、受け取ってプロダクトコードに生かし たり ケース2:社内でのステークホルダーとの合意 ● PdMが自分で作ったプロトタイプを会議で見せて仕様を合意 ● ステークホルダーからフィードバックを受けて開発側に共有する ©KAKEHASHI inc. 16

Slide 17

Slide 17 text

プレビューがどう使われているか ケース3:ユーザーヒアリング ● PMM、事業責任者などが、実際に既存のプロダクトを使っていただいているお客様へヒアリング ● コンセプトの資料よりも、動くデモがあることで社外からのフィードバックももらいやすい ケース4:Pharmacy Leaders Day 2026 ● Pharmacy Leaders Day はカケハシ主催の薬局業 界向けのカンファレンス ● 実際の現場の薬剤師の方などから製品に関するリアル な声をいただきました ©KAKEHASHI inc. 17

Slide 18

Slide 18 text

5 半年運用してみて ©KAKEHASHI inc. 18

Slide 19

Slide 19 text

半年運用してみて 高速な仮説検証はできたのか? ● ● ● 従来のFigmaより早く、多くの画面の検証ができるようになった ○ 特に複数パターンのプレビュー環境同士で比較が可能になった ○ ステークホルダーからのフィードバックを素早く複数箇所に反映することができる エンジニア以外の職種がプロトタイプを作る敷居が下がった ○ PdMが自らの思考をそのまま具現化できる ○ デザイナーが動くモノを使って仮説を検証できるため、実現可能性があがった ○ エンジニアは実コードに近いインプットをベースに開発ができるようになる 意思決定の進め方にはまだ改善の余地がある ○ ©KAKEHASHI inc. 早く試作を作って試せるため選択肢が増えた、複数の選択肢から決めるきる重要性が増した 19

Slide 20

Slide 20 text

半年運用してみて 新たに見つかった課題 デザイナー目線 ● 今まではFigmaで蓄積していたデザイン資産がプロトタイプになったことで残しづらくなった ● 一つを作り込むことで、複数の選択肢から選択するという意識が弱まることがある ● 試作品を早く作れるという意識が大事で、完成品が早くできるわけではない。それをチームで理解 する必要がある 運用上の課題 ● 複数プレビュー環境ができると最新の環境がどれかわかりづらい ● プロトタイプ同士のPRのコンフリクト解消が必要なことも ©KAKEHASHI inc. 20

Slide 21

Slide 21 text

6 まとめ ©KAKEHASHI inc. 21

Slide 22

Slide 22 text

まとめ AWS Amplify は偉大で、開発を次のステップへ進めてくれた! ● PRプレビューと Basic 認証を有効にするだけで、非エンジニアが自分の環境を持てた ● 生成AIを使ったプロトタイピング x Amplify プレビュー環境の組み合わせによって開発メンバー の働き方が大きく変わった ● プロトタイピングは早くなり、作れる人が増えた。その分「なぜこれを選んだのか」を説明できる重要 さが増した。また合意形成の取り方という次の課題も見えてきた 関連するブログも読んでいただけると幸いです PdM もデザイナーも AI でプロトタイプを作る — フロントエンドエンジニアが整えた3つの準備 生成AIフレンドリーなフロントエンド基盤をつくる ©KAKEHASHI inc. 22

Slide 23

Slide 23 text

We Are Hiring!!! PM EM エンジニア積極採用中 © KAKEHASHI Inc. All Rights Reserved.