【スタートアップに学ぶ新規事業創出】後編：開発プロセス「アジャイル開発」講座

お客様に届く！商品・サービス開発ワー クショップ 継続的企画/開発で事業を加速！

自己紹介 宮田 大督 / プロダクトマネージャー NTTコミュニケーションズのような大きな企業から メルカリや楽天のようなメガベンチャー、またエク サウィザーズのようなAIもしくはGaudiyのような Web3スタートアップと幅広く業界を経験。UXリサ ーチ、デザインなどを軸足に、現在は令和トラベル にて10XのグロースPdMとML/LLMチームのリーダー として奮闘中。

ガイダンス セミナータイトル お客様に届く！商品・サービス開発ワークショップ どんな講座？ 商品・サービス開発のセミナー・ワークショップです。 お客様の課題を解決でき、利益を創出できる商品・サービス を生み出し、継続的に成長させるための自信と能力が身に付 きます

開催期間は？ 01 前編：MVPで新規事業を創出！ 02 後編：継続的企画/開発で事業を加速！ 11月4日（土） 12月9日（月） 初期検討から最初のリリースまで 最初のリリースから継続的開発、 成長戦略まで

セミナー終了後には、こうなってるはず お客様に届く商品・サービスを生み出すプロジェクトのリーダ ーの役割をやれる 良い商品・サービスとは何かについての理解が深まる エンジニアなどさまざまなチームのメンバーの仕事が理解でき 、よりよいコラボレーションができるようになる

今日の学習目標 継続的企画/開発で事業を加速！ 本格開発から成長戦略まで 開発ディレクションができるようになる 成長戦略が描けるようになる

セミナーで学ぶこと 企画・開発の全体プロセス 顧客調査 MVP開発 継続的開発 継続的企画 問題はあらゆるところに 。解決すべき問題はどれ か？特定する 解決するためのアイデア は本当に顧客のニーズを 満たすか？ 何を、いつ、どの順番で 商品・サービスを作って いくべきか計画を立て、 開発を行う 商品・サービスの価値を 最大化するため、市場の 反応を見ながら柔軟に戦 略を見直し、継続的な改 善を行う

今回の範囲 3. 継続的開発 4.継続的企画 本格的に開発をするとなったら、何を、い 商品・サービスの成長の計画（ロードマッ つ、どの順番で商品・サービスを作ってい プ）を立てて、MVP開発や継続的開発をつ くべきかを決定する。 づけていく

継続的開発について 講義１：どんなパターンがあるか？

企画から開発へ 前回の企画プロセスで仮説とMVPが決定 CHECK ! いよいよ本格的な開発フェーズへ 目標：リリースを目指す

基本はシンプル 計画を立てて実行するだけ 仕様書を作って開発を 進める 決まったものを粛々と 実装

継続的な開発のプロセスの種類 ウォーターフォール 最初に全体計画を立てる アジャイル 小さな単位で開発と改善を繰り返す 計画通りに一気に開発を進める 途中での変更は原則なし フィードバックを受けながら柔軟に 方向修正

ウォーターフォール: 確実性が高いプロダクトの開発段階のプロセス 順次的な開発フロー: 戦略 STEP1 ビジネス要件 計画 STEP2 開発計画 開発 STEP3 コーディング、テスト チェック STEP4 承認とローンチ

戦略フェーズ（ビジネス要件） ここは「何を作るか」をざっくり決める段階です。 イメージストーリー あなたは新しいスイーツショップを開きたい。 まず、「どんなお菓子を売るか？」を考えます。 -ターゲットは？（子供向け、健康志向、高級志向？） 店舗で売る？通販で売る？アプリで注文？ ここで定まるのは「ビジネスの方向性」です。

計画フェーズ（開発計画） 「何を作るか」が決まったら、 それを実現するための詳細な計画を立てます 。 イメージストーリー 目標は「健康志向の焼き菓子」を通販で売ることに決定！ 材料調達はどれくらいかかるか？ 焼き上がりまで何日必要？ 包装や発送はどう整える？ など具体的な工程表を作ります。 ここで定まるのは「いつ何をするか」のスケジュールや設計図のようなもの。

開発フェーズ（コーディング・テスト） 計画ができたら、 実際に手を動かしてモノを作る段階に入ります。 イメージストーリー 用意した計画に沿って実際のお菓子を焼いたり、 特製パッケージをデザイン・製造したり、 オンライン注文サイトを作成したりします。 ここでは、「予定どおり材料を準備し、 製品(お菓子)を形にする」作業が進みます。 この段階で不具合(焼き加減が悪い、サイトがうまく動かない)が見つかれば修正します。

チェックフェーズ（承認とローンチ） 最後は完成品を最終確認する段階です。 イメージストーリー お菓子はちゃんと美味しいか？ パッケージは想定どおりのデザインか？ サイトはスムーズに注文できるか？ ここでOKが出れば、いよいよ世に出します！ 承認が取れたら、 お客様に商品が届き、食べてもらえる状態になります。

ウォーターフォール：以下の場合に最適 01 適用条件 要件が最初から明確で変更の可能性が低い場合 品質や安全性が特に重要な場合 法規制や基準への厳格な準拠が必要な場合 プロジェクトの規模が大きく複雑な場合 01 適用分野の例 金融システムの開発 医療機器のソフトウェア開発 大規模な基幹システムの構築

開発プロセスの種類 ウォーターフォール 最初に全体計画を立てる アジャイル 小さな単位で開発と改善を繰り返す 計画通りに一気に開発を進める 途中での変更は原則なし フィードバックを受けながら柔軟に 方向修正

アジャイル開発の考え方 前回の講義で紹介した リーン思考を開発に適用 開発の不確実性を段階的に解消

リーン:不確実性が高い企画段階のプロセス 仮説検証サイクルを繰り返し企画する -> このサイクルを繰り返しながら段階的に企画をまとめる Learn：仮説を立てる Build：MVPを構築 Measure：検証

アジャイル: 確実性がそこまで高くないプロダクトの開発段階のプロセス 小さい開発サイクルを繰り返し開発する: → 同じサイクルを繰り返しながら段階的に開発を進める Plan：計画 Do：開発 Check：チェック

アジャイルプロセスの基本の流れ 特徴：動くものを早期に作り、使用しながら改善を重ねる ステップ ディスカッション アクション 1 計画 2週間の短期間で 達成範囲を決定 具体的な 開発タスクに分割 2 開発 毎日の進捗確認で その日やるタスクを決定 チームで分担し 開発タスクを実行 3 チェック その期間で作ったものを共有 関係者でレビューと 次の計画への反映

アジャイル：以下の場合に最適 01 適用条件 要件が流動的な場合 顧客と密接なコミュニケーションが可能な場合 柔軟な変更対応が必要な場合 迅速な開発が求められる場合 01 適用分野の例 Webアプリ開発（ECサイト、SNSなど） デジタルマーケティング施策

アジャイル vs ウォーター フォール 本当にアジャイルが最適か？

アジャイル開発の必要性 アジャイルのアプローチ POINT 01 小さな単位での計画と実行 POINT 02 継続的な確認と方向修正 POINT 03 柔軟な対応が可能

本開発はお金がかかる MVPと本開発の違い MVPは少人数で進め られる 本開発は大規模なコ ストが発生

アジャイル開発の現実的な課題 開発費用が大規模になるため頻繁な稟議が必要 01 多忙な意思決定者と の時間調整の難しさ 02 柔軟な変更に対する 理解獲得の困難さ

ウォーターフォール型開発への誘惑 お互いにとって効率的な進め方？ ステークホルダーの視点 投資に対する確実 性を求める 明確な計画と実行 を望む 開発中の頻繁な変 更を避けたい 現場の視点 企画をきちんと作 り込んで意思決定 開発期間中は計画 通りに進行 途中での確認・調 整が最小限

エンジニアから見たアジャイル開発の課題 エンジニアの抱える不満 開発を阻害する要因 頻繁な仕様変更要求 実装途中での価値検証の要請 技術的な集中力の分散

開発における不確実性 不確実性の種類 価値の不確実性 方法の不確実性 カスタマーの課題が不明確 実現可能性が不明確 ソリューションの方向性が不 明確 コストの見積もりが不確実 さまざまな不確実性が開発にはあります

現実的なアジャイルの進め方 MVP段階で方向性を固めて 企画を確定 開発段階での焦点 ステークホルダーの承認を得る 実装方法の不確実性に集中 価値の不確実性は一旦棚上げ 技術的な検証を重視 大きな方向転換を避ける ステークホルダーとの調整を最小 限に

問題ないのか？ 価値検証の考え方 次のステップ MVPで十分な初期検証済み 本格的な開発に集中 この段階で慎重に検討し承認を得 る 大規模なユーザー検証を実施 細かな不安は一旦保留 スケールでの価値検証を行う

2段階の価値検証アプローチ アジャイル開発もプロセス全体で ひとつの価値の仮説検証 01 MVP段階での繰り返し行う検証 02 本開発による「スケール」での検証

MVPと本開発の違い MVP開発（企画段階） 本開発 少数ユーザーでの検証 多数ユーザーでの検証 低コストで繰り返し実験 本格的な投資 基本的な価値確認 ソリューションの完成度向上

開発段階での不確実性への対応 方法の不確実性が主な焦点に 多くのユーザーに向けた精度の高い実装が必要 実装方法の不確実性が増大 検証の中心が実装方法にシフト 本質を忘れずに 最終目的は顧客価値の検証 方法論は手段であって目的ではない 価値検証と実装のバランスを保つ

開発手法の使い分け 状況に応じた選択 確実性が高い → ウォーターフォ ール 不確実性が高い → アジャイル/リ ーン

ステークホルダー（承認者）との コミュニケーションのポイント 講義２：継続的開発を始める前に

本開発はお金がかかる MVPと継続的開発の違い MVPは少人数で進め られる 継続的開発は大規模 なコストが発生

ステークホルダーとの承認プロセス 開発フェーズによる承認プロセスの違い MVP開発段階(企画フェーズ)の特徴 継続的開発段階の特徴 少人数での実施が可能 大規模な投資判断が必要 上司との最小限のコミュニケーション 正式な承認プロセスが必須 大きな予算調達は不要 ステークホルダーとの密な連携

アジャイル開発と権限移譲 権限移譲の必要性 現場への権限移譲が必要な理由 頻繁な意思決定の発生 経営陣への確認による遅延防止 開発速度の維持 状況変化への柔軟な対応 ステークホルダー（承認者）の理解が得られれ ば、不可逆ではない可逆な範囲においてなど限 定的でも、素早いプロジェクト進行が可能とな る

効果的なコミュニケーション戦略 承認獲得のためのアプローチ 意思決定者の 時間的制約への配慮 簡潔で明確なメッセージ 現場にしかない情報が 存在する MVPの結果や データに基づく根拠の提示 コンパクトに まとめる ファクトを 伝える

プレゼンテーションの構造 聞き手の特性を理解する 最初と最後以外は記憶に残りにくい 冒頭：結論と主張を明確に伝える 中盤：補足情報や参考データなど 効果的な情報配置の3ステップ 終盤：聞き手にとって価値の高い提案

コンセンサスとコミットメント DisAgreement and Commitment コンセンサスの位置づけ コミットメントの重要性 完全な合意は不要 実行責任の明確化 意見の相違を記録 目標達成への約束 コミットメントはするけど、コンセンサスはしていないことは明確に伝える。 そうしなければ、次につながらない

アジャイル開発の代替案 ウォーターフォール開発での代替 アジャイル開発の承認が困難な場合はウォーターフォール開発も可能 スコープは可能な限り小規模に設定 アジャイル開発の最初のスプリントをイメージした規模感で実施

チームメンバーとの コミュニケーションのポイント 講義３：継続的開発のスタート

チームメンバー承認とコミュニケーション アジャイル開発の第一歩、スプリントゼロとは Point 1 アジャイル開発の最初の期 間（スプリント） 通常スプリントは2週間ほどだが、スプリントゼロは1カ月ほど 期間をとる Point 2 開発がスムーズにスタート できるための準備期間 解決すべき不安（不確実性）を整理し、チームメンバーの認識 をそろえるのが一番の目的

不確実性の整理 ビジネス担当 スコープ・優先順位 受け入れ基準 エンジニア担当 見積もり

スプリントゼロでやることの全体像 スプリントゼロの主要タスク ドキュメント整備 キックオフミーティング 不確実な部分を整理し、仮説 がある部分は明記、残課題は 議論ポイントとして共有 準備したドキュメントを、口 頭でもチームメンバーに共有 し、認識をなるべくそろえる PRD（Product Requirements Document）の作成 チーム全体への計画共有 質疑応答・合意形成 見積もりと計画、スプリント ロードマップの策定 解決すべき不安（不確実性）を整理し、チームメンバーの認識をそろえるのが一番の目的

PRDの作成 PRD（Product Requirements Document）は、製品や機能 の仕様を明確に定義する文書で、開発チームや関係者 が共通の理解を持つためのガイドライン Whyの言語化 ビジネスとしての目標はもちろん大事 顧客にどんな価値をもたらすかMVP開発のシェア Whatの言語化 何をどのスコープでやろうとしてるのか リスクの特定と対策（FAQ） 分析仕様

Whyの言語化

MVPでの検証結果 調査を行ってアップデートされた仮説 POINT 現金決済が主流で、ATMで現金を頻繁に引き 出す必要がある状況で POINT お客様は 現金を持ち歩くことを面倒に感じ、 より手軽な支払い方法を求めているはず。 -> 本当に現金決済がそんなに多いのか？クレジットカ ード決済も多いのでは？ 検証結果 クレジットカード決済も多いので、そこ まで現金決済が多く発生はしていなさそ う。 -> 面倒に本当に感じているのか？ 検証結果 現金支払いの時は、レジ前にもたつくとほか の人に迷惑をかけてる気分がして焦る。 また、クレカなど便利な決済方法は使いすぎ ることを心配している。

MVPでの検証結果 調査を行ってアップデートされた仮説 POINT スマートフォンで簡単に支払いができるQRコ ード決済を提供することで POINT より多くのお客様が財布を持ち歩かずに、ど こでも手軽に買い物ができるようになるはず 。 検証結果 検証結果 スマートフォンなどで暗証番号の入力な ど手間をかけずにできる支払い方法であ るＱＲコード決済やＮＦＣ決済を提供す ることで お客様はよりスムーズな支払いをすることが でき、買い物においていやな体験をしなくな るはず。また、プリペイド式の支払いになる ことで使い過ぎ防止になるのがうれしいはず 。

Whyの言語化:OKRの活用 OKR (Objectives and Key Results) 01 目標 (Objectives) 組織が達成を目指す意欲的 な方向性 02 成果指標 (Key Results) 目標の達成度を評価できる 具体的な数値指標

OKRの効果 目標 (Objectives): 組織全体の方向性統一 成果指標 (Key Results): 進捗の可視化と管理 チーム内外の関係者が同じビジョン（Why）を共有 し、一丸となって目標達成を目指すための指針と なります。 プロジェクトの進捗状況や成果を数値化し、外部 関係者と共有することで、透明性の高いプロジェ クト運営を実現します。

目標（Objectives）の活用 目標と成果指標の例 支払い体験をストレスフリーにする 決済完了までの平均所要時間を現金決済比で 50%削減する 日常的な利用を定着させる 週1回以上の利用者を全体の40%まで増やす 安心・安全な決済手段として認知さ れる セキュリティインシデントの発生を0件に保 つ

成果指標（Key Results）の活用 目標と成果指標の例 支払い体験をストレスフリーにする 決済完了までの平均所要時間を現 金決済比で50%削減する 日常的な利用を定着させる 週1回以上の利用者を全体の40%ま で増やす 安心・安全な決済手段として認知さ れる セキュリティインシデントの発生 を0件に保つ

ワーク1 OKRをかんがえてみる

ワーク: OKRを改善する 下記のOKRを見直しましょう。これまで話してきたOKRガイドラインによりよ く適合するように修正しましょう。 新規ECサイトを立ち上げ、3月末までに月間売上100万円を達成し、サイトの有効 性を検証する。 ユーザー登録を増やす。 メールマガジン読者を集める。 リピート率を上げる。 初年度に事業を黒字化する。 売上を伸ばす。 クーポンを配布して新規顧客を獲得する。 下期の売上を増やす。

ワーク: OKRを改善する （解答例） 新規ECサイトを立ち上げ、3月末までに月 間売上100万円を達成し、サイトの有効性 を検証する。 新規ECサイトを、顧客に支持される価値あ るサービスとして確立する。 ユーザー登録を増やす。 3月末までに月間アクティブユーザー1,000人を達成 する。 メールマガジン読者を集める。 メールマガジン登録者数を5,000人獲得する。 リピート率を上げる。 月間リピート率を30%以上にする。

ワーク: OKRを改善する （解答例） 初年度に事業を黒字化する。 初年度に事業を黒字化し、持続可能なビジ ネスモデルを構築する。 売上を伸ばす。 下期までに月商500万円を達成する。 クーポンを配布して新規顧客を獲得する。 新規顧客獲得単価を3,000円以下に抑える。 下期の売上を増やす。 12月の月間営業利益を100万円以上にする。

Whatの言語化

Whatの言語化:スコープ（やること、やらないこと）の決定 目標と成果指標を達成するために スコープ（やる範囲）として「機能グループ」と「機能」を考えます。 支払い体験の改善 利用定着の促進 決済フローの 最適化 ユーザー体験 の向上 セキュリティ強化 不正利用対策 高速なQRコードスキャン機能 日替わりのクーポン配布 不正検知システム わかりやすいエラーメッセージ処 理 家計簿機能との連携 取引限度額の設定機能

電子決済サービスのソリューションマップ

ビジネス戦略の重要性 選択と集中 全ての機能を網羅的に開発するのではなく、重要な機能グループに注力 リソースの効率的な配分 市場インパクトの大きい機能の見極め 競争優位性を生む機能への集中投資

Whatの言語化:機能リスト（バックログ）の作成 プロダクトバックログを作る 特徴 大小問わずすべての実装したい機能をリスト形 式で網羅、どのグループに属するかなどの情報 も明記 実際にプロジェクトが進むと、アサインやステ ータスなども書いて管理していく 開発計画と管理がシンプルにでき、チームの次 のアクションが明確

なぜガントチャートではなくバックログ（リスト形式）か？ ガントチャートについて ガントチャートは、いつまでに何を作るかを詳しく計画する開発管理の方法で す。 要件が最初から明確で、大きな変更が予定されていないプロジェクトに適して います。 バックログ形式を選ぶ理由 アジャイル開発のように、状況を見ながら計画が変わる可能性がある場合は、 たんなるリスト形式のバックログの方が適しています。 バックログは優先順位の変更が簡単で、新しい要件の追加や既存の要件の削除 も容易にできます。

バックログの作り方 これまで検討してきたソリューションマップなどから アイテムを取り出し、リスト形式にならべる 一旦この段階では、企画者目線で 重要と思われる順に並べるでOK

機能別の優先順位のつけかた：MoSCoWメソッド 各機能の相対的な優先順位を判断し、 それぞれに重要度のレベルを設定することができます。 01 03 M: Must 絶対必要 C: Could あってもいい 02 04 S: Should 入れるべき W: Won't いらない

例

続いて工数感の見積もりをしましょう どうやって見積もる？ ウォーターフォールなど、後戻りができないやり方での計画で あれば、この段階で仕様も完全に作りきり詳細な見積もりがで きるようにするのがよい アジャイルでは・・・？

機能概要の作成 なにをもってその機能開発が完了したのかだけ、決める POINT 01 「機能」を補完する、概要的な文章。 POINT 02 この要素があれば、この機能が作られたと言える説明を２－５個の文 章で示す。 POINT 03 説明自体はおおまかでもいいが「機能」が完成したものとみなす基準 となるので重要。 POINT 04 これがないと、エンジニアが機能の見積もりができない

例）機能と機能概要の例 機能「QRコードで支払いができる」 機能概要 No.01 「店舗側がQRコードを生成し 、レジ横のディスプレイに表 示できる」 No.02 「顧客がスマートフォンのカ メラでQRコードを読み取ると 、支払い金額と店舗情報が表 示される」 No.03 No.05 「顧客が支払いを確定すると 、店舗側のレジ画面に支払い 完了通知が表示される」 No.04 「取引完了後、顧客と店舗の 双方に取引履歴が記録される 」

機能概要を作成する上での注意点 書きながら、イメージを膨らませる 抜け漏れなどはないか？ ひとつの「機能」としては大 きすぎないか？ 言語化したりすると、この要素も必要だったと 機能概要を書きながら、要素が大きすぎる場合 気づく。 は、開発対象としても大きい可能性。二つ以上 の機能に分割できないか検討

工数感を見積もる：Tシャツサイズメソッド 各機能の工数を相対的に見積もるための簡易的な手法です。 01 XS: 02 S: 03 M: 1-2日程度の小規模な作業 3-5日程度の作業 2週間程度の作業 04 L: 1ヶ月程度の作業 05 XL: 2ヶ月以上の大規模な作業

例

バックログの優先順位付け 価値と工数のバランスを考慮した優先順位付けを行い、優先順位を並び替える 各機能の工数見積もり 各機能の価値の評価 XS: 1 Must: 5 S: 2 Should: 3 M: 3 Could: 1 L: 4 Won't: 0 XL: 5 最終評価計算：価値 ＋ 簡単さ（＝５－工数）

Wht + What = PRD

PRDの作成 PRD（Product Requirements Document）は、製品や機能 の仕様を明確に定義する文書で、開発チームや関係者 が共通の理解を持つためのガイドライン Whyの言語化 ビジネスとしての目標はもちろん大事 顧客にどんな価値をもたらすかMVP開発のシェア Whatの言語化 何をどのスコープでやろうとしてるのか リスクの特定と対策（FAQ） 分析仕様

PRDの作成 Whyの言語化 カスタマー仮説 状況 課題 ソリューション仮説 ソリューションの概要 期待される効果 OKR 目標 成果指標

PRDの作成 Whatの言語化 機能リスト（バックログ） 機能グループ・機能・機能概要 工数 優先順位のリスト 参考情報 スコープ外のこと（やらないこと） リスクの特定と対策（FAQ） 分析に関する相談など、機能に直接関わらないが相談しておきたいこと

実際の開発要件やデザイン（HOW）はどうするの？ エンジニアやデザイナー中心に議論してまとめてもらう CHECK POINT チーム全体としては、WhyとWhatを中心 に議論する程度にしておくのがアジャイ ルではベスト 実際にどう実装するかは、開発を進めていく中で 、着手するときなどにエンジニアやデザイナーが 検討をすると、柔軟性が高い （そしてあとからPRDなどにかいてもらう）

PRDによって解決されること 開発がスムーズにスタートできるための準備 不確実性の解決 なにをやるか、優先順位がきまっ ていない 機能開発の完了基準がなく、どう したら終わるかわからない どれくらいの工数がかかるかわか らない そして、キックオフミーティングを開き、口頭でもしっ かり皆さんにお伝えしましょう

コンセンサスとコミットメント DisAgreement and Commitment コンセンサスの位置づけ コミットメントの重要性 完全な合意は不要 実行責任の明確化 意見の相違を記録 目標達成への約束 コミットメントはするけど、コンセンサスはしていないことは明確に伝える。 そうしなければ、次につながらない

ワーク2 実際に、バックログをつくってみましょう

シナリオ：パン屋のホームページ制作 地域でパン屋を営むA社が自社ホームページを作ることになりました。 目的はお店の基本情報や商品紹介 を掲載し、来店や問い合わせを促 すことです。 開発機能の優先順位付けが必要で す。たくさんの機能要望がありま すが、まだ整理できていません。 作業シートで優先順位を決めてい きましょう！

評価シート

スライド例1：トップページ（HP-1） 機能概要： トップページ上部に、店舗ロゴとキャッチコピ ーが表示されること 簡易的なナビゲーションメニューがあり、「会 社概要」「商品紹介」「アクセス」「お問い合 わせ」ページへのリンクが機能すること PC・スマホいずれの画面幅でも、メインメッセ ージ（キャッチコピー）が途切れず表示される こと（レスポンシブ対応）

スライド例2：会社概要ページ（HP-2） 機能概要： 「会社概要」ページに、会社名、所在地、代表 者名、設立年など基本情報がテキストで掲載さ れていること 写真（店舗外観・オーナー写真）が指定箇所に 表示されること 他ページ（トップページや商品紹介ページなど ）に戻れるメニューリンクが機能すること

スライド例3：商品紹介ページ（HP-3） 機能概要： 商品一覧がグリッドまたはリスト形式で表示さ れること（商品写真、名称、価格、簡易説明） 10点以上の商品を想定し、一覧表示・スクロー ルがスムーズであること 将来的な商品追加に対応できるよう、テンプレ ート化された商品表示エリアが用意されている こと（CMS連携または手動更新を想定）

スライド例4：レシピ・食べ方提案ページ 機能概要： レシピ一覧がカード形式で表示され、写真とタ イトルが見やすく配置されること 各レシピページに材料リスト、手順、完成写真 が掲載されること レシピの検索・カテゴリ分類機能があること

スライド例5：おすすめパン診断機能 機能概要： 好みや用途に関する3-5個の質問に回答する形 式であること 質問への回答に基づき、適切なパンを推薦する ロジックが実装されていること 診断結果画面に推薦パンの写真、特徴、価格が 表示されること

スライド例6：店内混雑状況表示 機能概要： 店内の混雑度が「空いている」「やや混雑」「 混雑中」の3段階で表示されること 混雑状況が5分ごとに自動更新されること 過去の統計データに基づく時間帯別の混雑予測 が表示されること

スライド例7：アクセス/地図ページ（HP-4） 機能概要： 店舗所在地住所が明記されていること Google Maps等の地図埋め込みウィジェットが 正常に表示され、地図上に店舗位置が示されて いること 営業時間や定休日等の基本情報が表示されてい ること

スライド例8：お問い合わせフォーム（HP-5） 機能概要： 氏名、メールアドレス、お問い合わせ内容の入 力欄があること 必須項目が未入力の場合は送信できず、エラー 表示がされること 送信成功時に「送信完了」メッセージが表示さ れること

スライド例9：ニュース/お知らせ機能（HP-6） 機能概要： 管理画面からお知らせを投稿・編集できる場合 は、その仕組みが機能すること（もしくは静的 ファイル更新で対応） 最新のお知らせがトップページまたは専用枠に 数件表示されること

スライド例10：SNSリンク（HP-7） 機能概要： フッターなど指定箇所に、InstagramやFacebook への外部リンクアイコンが並ぶこと クリックで該当SNSの店アカウントページへ遷 移すること アイコンは透過PNGやSVGで鮮明に表示されて いること

スライド例11：多言語対応（HP-8） 機能概要： サイト上部または下部に言語切替用メニューま たはボタンがあること 英語対応を選ぶと、全ページの主要テキストが 英語表記に切り替わること レイアウト崩れが発生せず、英語文言が長くな っても全体が整然と表示されること

シナリオ：パン屋のホームページ制作 パート1：バックログの機能価値を見積もる タスク No.01 No.01 各メンバーで個別にバックログの各アイ テムの機能価値をMOSCOW法で評価 No.02 No.02 お互いに見せ合い、話し合って最終的な 数値を決定

シナリオ：パン屋のホームページ制作 パート2：機能価値の評価 タスク No.01 バックログの各アイテムのTシ ャツサイズ法で見積もる No.02 メンバー全員で個別にスコア を入力 No.03 No.05 話し合って最終スコアを決定

最終的なスコア付け 価値と工数のバランスを考慮した優先順位付けを行い、優先順位を並び替える 各機能の工数見積もり 各機能の価値の評価 XS: 1 Must: 5 S: 2 Should: 3 M: 3 Could: 1 L: 4 Won't: 0 XL: 5 最終評価計算：価値 ＋ 簡単さ（＝５－工数）

開発サイクル(スプリント)のはじまり 講義３：アジャイル開発の流れ

開発サイクル（スプリント）の開始 準備から実践へ CHECK CHECK スプリントゼロで基本計画と 優先順位付けを完了 実践のポイント 実際の開発サイクル（スプリント） 教科書的な理想形があるが完璧を目 へ移行 指す必要はない 開発サイクルを何度も繰り返し完成 チームの状況に応じて段階的に導入 を目指す

アジャイルな進め方のイメージ アジャイル開発は、最初から一部を完璧に仕上げるのではなく、 全体を少しずつ「薄く」仕 上げていくイメージです。

全体を薄く描いてから段階的に精密化する たとえば、絵を描く場合を想像してみてください。 レンガを積むように： 最初から完璧な一部だけを完全仕上げし、それを積み上げて最終的 な完成に至る方法。 これは、完成形が見えづらく、途中で方向転換しにくい。

全体を薄く描いてから段階的に精密化する スケッチを広く描いてから色付けを薄く重ねるように： 全体の下描きをして、大まかな形を把握し、その上に段階的に 色やディテールを足していく。 → 最初から全体像が見えるので、修正や軌道修正が容易。 アジャイルはこのイメージに近い手法です。最初の段階で全体像をざっくり作 り、その後、少しずつ改良を重ね、メンバーと相談しながら完成度を高めてい きます

全体像：ミニ開発サイクル (スプリント) 2週間を1例とすると： 1日目 2～13日目 短期計画会議 (スプリントプラン ニング) → 目標＆やること決定 → 目標＆やること決定 14日目 Goal ! 毎日の進捗共有 (デイリースタンド アップ)＋作業 完成物共有会議 (スプリントレビュ ー) → 小さな問題もすぐ共有 → 出来たものを確認＆次 回改善点 → 小さな問題もすぐ共有 → 出来たものを確認＆次回改善点 このサイクルで少しずつ価値ある成果物を積み上げます。

チーム構成例 製品計画責任者 (PM) 顧客ニーズ・目標を把握、 開発優先付け 開発担当者 (エンジニア) 実装や製品づくり担当 デザイン担当者 (デザイナー) 品質確認担当 (QA) 使いやすさ・見た目を整え る 問題点発見・品質確保支援

計画会議 (スプリントプランニング) 短期開発期間(スプリント)の開 始時には、「これからの期間内 で何を完成させるか」を決める 計画会議を行います。

計画会議(スプリントプランニング)：理想的な進め方 目的： この短い期間内(例：2週間)でどの機能やアイデ アを「完成」まで持っていくかを決定 手順の一例： 開発候補リスト(バックログ)を見る 優先度が高い項目から、実現可能な範囲をピッ クアップ 「ここまでできたら完成」とみなす条件(受け入 れ基準)を明確にする、必要であれば精緻な見積 もりも行う 結果： 「この期間中にA機能を完成」「B機能は途中ま で」など具体的なゴールが固まる

計画会議(スプリントプランニング)： 実際はゆるくてOK 01 慣れないうちは、ざっくりとした合意で十分 「この2週間で新機能Xをだいたい完成させたいね」程度から始める 02 続けるうちに、精度アップ 「この機能は3日で終わる」「ここは複雑だから1週間かかる」

計画会議で大切なのは「合意」と「見通し」 チーム全員が「これをこの期間でやり切る」と 腹落ちできることが重要 完璧な計画は不要： あくまで短期間後に再調整可能な「仮の計画」 開発対象を小さく区切ることで、 ・ステークホルダーに早めに見せられる ・不確実性を減らせる ・実際使ってみて不要な機能を省ける

ストーリー例：お店の宣伝ページ開発 01 02 計画会議で決めること： 「この2週間で新しい宣伝ページを完成させ、 顧客に見せる」 03 最初は大まかでOK： 「まずは基本デザインを固め、公開テストでき る状態にする」程度の合意 経験を積むと正確な見積もりも可 能に： 「ビジュアルデザインに3日」「コンテンツ作 成に4日」「最終仕上げに残り」

毎日の進捗共有 (デイリースタンドアップ) 短期開発期間(スプリント)中は 、 日々の進捗を共有し合うこ とで、全員が状況を把握しやす くなります。

全員が3つの質問に答える このシンプルな質問で、作業を振り返り、 次の行動を明確にし、問題解消をスムーズに POINT 01 昨日何をした？ POINT 02 今日何をする？ POINT 03 問題(ブロッカー)はある？

理想的な進め方 朝15分ほどで、「昨日何した？」「今日何する？」「問題点は？」を共有 タスクに集中しやすく、問題 発生時はすぐ対応可能 「遅れてる人がいないか」「 手助けが必要な人がいないか 」を見える化 Point ポイントは「進捗をチームで素早く共有できる仕組み」があること

実際はゆるくてOK 全員が毎日顔を合わせられないなら、 チャットツールに短い報告でもOK 毎朝無理なら隔日でもいい ポイントは「進捗をチームで素早 く共有できる仕組み」があること

具体的な例 「昨日はページの基本的なところをつくった。 今日はもう少し装飾を調整する予定。特に問題なし」 CHECK POINT 他の人のコメント 「そういえば、たまたまテキスト内容を 確認したが、もともと掲載する予定でな いものになってたよ」 → これでチームが「コンテンツ変更必要だね」と すぐ気づく

進捗確認を少しずつ PO INT 進捗が毎日見えるから 「予定通り完成しそうか」「後何が必要か」 といった判断がしやすい

まとめ：毎日の進捗共有(デイリースタンドアップ) 短時間で状況確認→問題発見→即対処を促す フォーマルな形にこだわらず、チャットでも柔軟に対応可 進捗がクリアになることで、スプリント最後にリリース判断がスムーズに 次は、完成物レビュー会議(スプリントレビュー)で、出来上がった成果物を関係者に見せ て意見をもらうステップへ進みます

完成物レビュー会 議 スプリントレビュー スプリント最後に、「この期間 で何ができたか」を関係者へ見 せ、直接フィードバックをもら う場。

理想的な進め方 チームが完成した成果物を実際にお披露目 次の方向性（来週何を ステークホルダーから 開発したらいいか、何 直接意見を受け取り、 が足りてないか）を決 める手がかりにする

実際はゆるくてもOK 日常的に共有していれば、当日は簡単な最終 確認程度でも問題なし 小規模なチームなら、 計画会議(スプリントプランニング)と一緒にしてしまうことも可能

リリース条件 「この状態ならお客様へ見せられる！」と合意したらリリ ース可能 必要ならさらに改善して、次回以降にリリース判断する

具体例 新しい宣伝ページをお披露目 「デザインは良いけど、使っている写真をもっと工夫した 方が良い」 → 次の短期開発期間(スプリント)で画像の選定の改善を計 画

価値の不確実性を見直すチャンス 基本はアジャイル期間ではあまり疑わないほうがいいが、 実際に動いているのを見て 「この機能、本当に必要？」と思う場合もあります 「意外と顧客が求めていない？」と気づいたら、 → 企画段階やMVP検証（最低限の試作品でニーズ確認）に立ち戻り、方 向修正も勇気をもってやる こうした微調整が早期に行えるため、 無駄な作業を減らし、本当に価値あるものに集中できる

まとめ：完成物レビュー会議(スプリントレビュー) 完成物をお披露目してフィードバックを得ることで、 次の一手が明確に POINT 01 必要に応じて「そもそも要らない？」と再考し、企 画やMVP段階に戻る柔軟性も POINT 02 理想形にとらわれず、日々の共有と組み合わせて気 軽に実施

アジャイル開発の本質 開発サイクルのポイント 01 03 段階的な開発： 一度にすべて完成させようとせず 、部分ごとに少しずつ進める 進捗管理ツールの活用： シンプルなリストや図表などで状 況を見える化し、判断しやすく 02 04 継続的な共有： 計画会議や毎日の進捗共有、レビ ューなどで常に状況をオープンに リリース時期の見極め： 「もうお客様に見せられる」段階 で、即リリースして価値提供

気軽さが大事 完璧な計画や理想的な形式にとらわれず、 「とりあえずやってみる」精神でOK やりながら学び、改善し続ける 小さな前進を積み重ねるうちに、 気づけば大きな価値を生み出せるようになる 「重く考えすぎず、繰り返し前進する」ことが、 アジャイルな開発の本質です。

継続的企画プロセス 講義４：アジャイルでリリースしてどうするの？

アジャイルでリリースしたけど、これからどうする？ MVP開発ですでに価値検証がすんでいるものがまだまだあるなら、開発計画を 立てて進めていこう

プロダクトロードマップ

プロダクトロードマップ 中長期的なプロダクトの成長を反映した戦略的ドキュメント バックログの限界 バックログだけでは、中長期のスケ ジュールを立てるのは難しい しかしガントチャートのように細か いものを作るのはやはりアジャイル になじまない OKRの限界 一つのOKR（目標と成果指標）だけ では、数年後の成功への道のりまで は一気に辿り着くことはできない 段階的アプローチ 現実的には、中長期的に段階的にビ ジネス的成功にたどりつく その段階を示したものがロードマッ プ 各段階（例えば1クオーターごと） にOKRが設定されるのが現実的

(引用）ロードマップに機能を書くべからず 小城久美子 / ozyozyo https://note.com/ozyozyo/n/nfb370fadd70c

ロードマップの大事な役割 コミュニケーションツールであるということ このプロジェクトに関わるメンバーの一番の不安＝ これからどうなっていくのか？ ステークホルダー（承認者）に対 しては、成功の道筋、勝ち筋を提 示し、継続的な協力をお願いしま しょう チームメンバーに対しては、現在 まだまだ不確実性が完全に解消さ れていなくても、中長期的には成 功に向かっていることを示し、チ ームの士気を高めましょう

成長ジャーニー

次のステップ 継続的な改善プロセス 具体的なアクション 01. 成果の評価・分析 データに基づく改善点の特定 02. フィードバックの収集 ユーザーの声の収集・分析 03. 次期開発計画の策定 新機能の企画・開発 / 既存機能の最 適化

あとはがむしゃらに改善するだけ それもあり。でも 成長のフレームワークも参考にしよう

さらに成功に向か って計画を立てよ う MVP開発＋アジャイル開発を 繰り返す サービスをどんどん成長させよ う

成長ジャーニー 顧客課題(CPF)→解決策の有効性(PSF)→製品化(SPF)→市場受容(PMF)と段階を踏み、成長へと つなげます。 (引用） スタートアップ・フィット・ジャーニー 今どの段階にいて、何に取り組むべきかのガイド 馬田隆明 https://review.foundx.jp/entry/startup-fit-journey

• https://review.foundx.jp/entry/startup-fit-journey

成長のステージ 1. 初期検証フェーズ MVPによる検証：CPF/PSF スケールでの検証：SPF 顧客課題の特定 最低限の機能実装 ソリューションの妥当性確認 実用性の確認 サンプルテキストサンプルテキストサンプ バケツの穴を特定し修正

成長のステージ 2. 初期PMFチャレンジフェーズ 初期PMFの達成を目指す 一転突破の戦略で進める 集中的な体験の磨き込み イノベーターをとる 勝負をかける

初期PMFの実践戦略 スケールしないことをやる イノベーター層への 直接アプローチ ユーザー離脱の監視 と対策 口コミによる自然な 成長促進

具体的な例 直筆のお礼メッセージ 自動メールではなく手書きで感謝を伝え る 顧客に特別感を与える 直接訪問・電話サポート 顧客の課題に真摯に向き合う 深い信頼関係を構築

なぜ「スケールしないこと」をやるのか？ 顧客一人ひとりへの丁寧な対応が、強い信頼関係を構築 効率化を急がず、顧客 との距離を縮める 口コミを誘発し、自然 な成長を促進

「非効率」がもたらす効果 顧客ニーズの深い理解 CHECK ! 強固な信頼関係の構築 将来の効率化への知見蓄積

3. Growthフェーズ : 2次PMF,3次PMF マジョリティ市場への展開 1次PMFは狭い顧客層(イノベーター/アーリーアダプター)での成功 より大きな市場規模を 持つマジョリティ層へ のチャレンジ 課題の深刻度は低いが、 市場規模で勝負

問題発生時の対応 機能・安定性の問 題 SPFレベルとして、完成度を上げる UX/UIの問題 SPFレベルとして、デザインクオリティの改善 価値の問題 MVPから再検証することも考える

リーン:不確実性が高い企画段階のプロセス 仮説検証サイクルを繰り返し企画する -> このサイクルを繰り返しながら段階的に企画をまとめる Learn：仮説を立てる Build：MVPを構築 Measure：検証

何より大事なのは プロダクトの成功に役に立つこと ビジョンを元に俯瞰すること ＋ ファクトを元に泥臭くやること ビジネス戦略＋リーン/アジャイル開発

ワーク3 ロードマップをつくってみましょう

eコマースのロードマップ 背景 ロードマップの作成手順 あなたは地域密着型パン屋のデリ バリーサイトの企画者です。チー ムですでに特定されているOKRと バックログに基づいてプロダクト ロードマップを作成します。 デリバリーサイトを改善するために必要な 主要な目標と機能グループを決める。 各機能グループにどの機能が該当するかを 定義する。 各機能の機能価値、工数感を特定する。 タイムラインに照らしてロードマップの図 を描く。

課題仮説eコマースのロードマップ（続き） 戦略フレームワーク 1 課題仮説 朝食用のパンを前日夜に買いに行く時間がない人が多い 人気商品が売り切れで、わざわざ店舗に行っても買えないことがある 待ち時間のストレスを感じる顧客が存在する 2 ソリューション仮説 前日夜までの予約注文と朝一配達で、新鮮なパンを届ける 在庫状況をリアルタイムで反映し、確実に商品を確保できる仕組みを提供 人気商品の在庫状況を可視化する

機能グループ 1. 支払い方法の拡充 2. 購入操作の改善 3. 商品選択のサポー ト 4. マーケティング施 策 5. 配送システム 決済代行業者連携： 複数決済方法への対 応 カート機能改善：日 をまたいでも情報維 持 関連商品表示：相性 の良い商品推薦 メールマガジン：新 商品・セール情報配 信 配達パートナー連携 ：配達状況の管理 PayPay導入：スマホ 決済対応 ワンクリック購入： 決済情報保存で簡単 注文 複数商品画像：断面 や食べ方提案 ライブ通知：焼き立 て情報の提供 ポイントカード連携 ：実店舗ポイントの オンライン利用 予約注文：前日まで の注文受付 レビュー機能：購入 者の評価表示 定期購入：定期的な 自動配達 在庫管理：リアルタ イム在庫表示

Whyの言語化:OKRの活用 OKR (Objectives and Key Results) 01 目標 (Objectives) 組織が達成を目指す意欲的 な方向性 02 成果指標 (Key Results) 目標の達成度を評価できる 具体的な数値指標

eコマースのロードマップ（続き） 戦略フレームワーク 目標 (Objective) 主要な成果 (Key Result) デリバリー注文の売上を伸ばす デリバリー注文の比率を全売上の30%まで 引き上げる リピート率を50%以上に向上させる

ワークショップ3：デリバリーサイトのロードマップ作成 ワークショップの進め方例（進め方はどれから先にやってもいいです） Step 1：期間ごとのOKR設定 6ヶ月間を2ヶ月ごとの3期に分割 各期で達成したい具体的な指標を設定 KRは任意です 例）第1期（1-2ヶ月目） O：デリバリーの基盤構築 KR：デリバリー注文比率10%達成 サンプルサンプルテキストサンプルテキサンプルテキスト

ワークショップ3：デリバリーサイトのロードマップ作成 ワークショップの進め方例（進め方はどれから先にやってもいいです） Step 2：成長ジャーニーの設定（20分） 各期で達成しておきたいフェーズを定義 段階的に仮説を検証していく どれくらいでPMFを目指すか？ 例） 第1期：PSF: 基本的な注文機能の実現 第2期：SPF : 利便性の向上 第3期：PMF: 顧客エンゲージメントの強化

ワークショップ3：デリバリーサイトのロードマップ作成 ワークショップの進め方例（進め方はどれから先にやってもいいです） Step 3：機能の優先順位付け 提供されているバックログを確認し、おおまかなスケジュー ルを決める 基本的には優先順位が高い方から先に 機能グループもみて、先に実装した方がいい機能があればそ れも重視

ワークショップ3：デリバリーサイトのロードマップ作成 ワークショップの進め方例（進め方はどれから先にやってもいいです） Step 4：ロードマップの完成 実際にロードマップ上に配置 OKRや成長ジャーニーと見比べながら調整する 機能グループごとに、色分けなどする ポイント OKRと実装機能の整合性 技術的な依存関係の考慮 リソース配分の現実性

まとめ 最終講

振り返り どんな講座？ 商品・サービス開発のセミナー・ワーク ショップです。 どんな講座？ 商品・サービス開発のセミナー・ワ ークショップです。 お客様の課題を解決でき、利益を創 出できる商品・サービスを生み出し 、継続的に成長させるための自信と 能力が身に付きます

振り返り 01 前編：MVPで新規事業を創出！ 02 後編：継続的企画/開発で事業を加速！ 11月4日（土） 12月9日（月） 初期検討から最初のリリースまで 最初のリリースから継続的開発、 成長戦略まで

こうなりましたか お客様に届く商品・サービスを生み出すプロジェクトのリーダ ーの役割をやれる 良い商品・サービスとは何かについての理解が深まる エンジニアなどさまざまなチームのメンバーの仕事が理解でき 、よりよいコラボレーションができるようになる

セミナーで学ぶこと 企画・開発の全体プロセス 顧客調査 MVP開発 継続的開発 継続的企画 問題はあらゆるところに 。解決すべき問題はどれ か？特定する 解決するためのアイデア は本当に顧客のニーズを 満たすか？ 何を、いつ、どの順番で 商品・サービスを作って いくべきか計画を立て、 開発を行う 商品・サービスの価値を 最大化するため、市場の 反応を見ながら柔軟に戦 略を見直し、継続的な改 善を行う

1.顧客調査 問題はあらゆるところに。解決すべき問題はどれか？特定する CHECK ! 問題の発見生活の中でみながふと口にしてしまっ ているような苦情、顧客の問題を探す。 問題の理解顧客とともに仮説を検証し、顧客ニー ズをよりよく理解するための調査計画を立てる。

2.MVP開発 解決するためのアイデアは本当に顧客のニーズを満たすか？ CHECK ! 解決策の検討顧客のニーズを満たすためのアイデアを検討する。 解決策を生み出す検証をするための最小限のプロダクトを作る アイディアの仮説を検証顧客をよりよく理解するために、効果的な調査・ 検証を行う。本格的に開発を行うかのジャッジをする。

今回の範囲 3. 継続的開発 4.継続的企画 本格的に開発をするとなったら、何を、い 商品・サービスの成長の計画（ロードマッ つ、どの順番で商品・サービスを作ってい プ）を立てて、MVP開発や継続的開発をつ くべきかを決定する。 づけていく

企画から開発まで 一気に駆け抜けてきましたが いかがでしたでしょうか

みなさんの日々のビジネスに 少しでもなんらかお役に立てる部分あれば 幸いです ありがとうございました