プロダクトのキックオフ支援サービス

プロダクトを作ると決めたチームが、成功の定義・決める人・計画に合意するまでを、質問への回答から導くウェブサービスです。今は試作を SAGUS チームの中で確かめています。

掲載日

2026-10-07

状態

試運転中

開発期間

2026-09-05 に要求を決め、09-07 に操作できる試作を作成、09-08 に関係者向けに公開。本番の機能は作成中

体制

SAGUS チームが判断し、要求の整理・設計・実装・レビューは AI (Claude Code) が担当

主な技術

Next.js、Cloudflare Workers、TypeScript、Base UI、Claude Code

主な仕事

プロダクトを作ると決めたプロダクトオーナーや PM は、関係者の目標・責任・期限がそろわないまま走り出しがちです。 Day Zero は、確かめるべきことを洗い出して片付け、全員が同じ計画に合意した状態で、次の準備に進めるようにします。

• 始まり: 作ることは、Day Zero の外ですでに決まっています。
• 終わり: 関係者が最終版を確かめ、最終判断者が承認した「成功の定義」があります。
• 「この事業に市場があるか」「そもそも何を作るべきか」を調べて決めることは、対象にしていません。

使う人

キックオフを進める人 (プロダクトオーナーや PM) です。 最初は、SAGUS のプロダクトマネージャーが顧客のプロダクト作りに伴走する時に、案件ごとに開いて使います。顧客自身が登録して使う形は、最初の版に含めません。

期待する成果

• キックオフを進める人: 準備の抜け漏れと手直しが減ること
• 最終判断者: 責任・根拠・計画を確かめたうえで合意できること
• 関係者: 自分が何を、いつまでに確かめ、実行するかが分かること

確かめる目安として、案件を作ってから最終承認までを 21 日以内にすること、必ず確かめてほしい関係者の全員が最終版を確かめることを置いています。

解きたい問題

問題	よくある状態	解けた状態
成功の定義があいまい	「売上を伸ばす」だけで、今の値・目標・期限がない	指標・今の値・目標・期限・見直す日・止める条件がそろう
誰が決めるか分からない	決める人が複数いる、決まっていない、引き受けていない	引き受けた最終判断者が 1 人いる
体制が確かめられていない	作る人や稼働が決まらないまま、計画だけが進む	担当・責任・稼働がはっきりする
確認が人の経験頼み	PM が経験と記憶で、確かめることを思い出す	足りない項目と矛盾から、確かめることが毎回同じように出る
配ったことと合意が混ざる	資料を送っただけで、合意した扱いになる	最終版を本人が確かめたことと、最終承認を記録できる
次の工程で前提が消える	次の担当が、目標・やらないこと・制約を聞き直す	承認した版を、根拠と履歴ごと次の工程へ渡せる

解き方

質問への回答 → 確かめること → 関係者の回答 → 成功の定義の確定 → 版に結びついた合意、という 1 本の流れを目指しています。今の試作は仮のデータで動き、AI の提案も見本の出力で代用しています。

1. 「このプロジェクトの成功は何か」を決めるための 7 つの問いに、1 問ずつ会話の形で答えます。「まだ分からない」と答えて先へ進むこともできます。
2. 決まった規則が、足りない項目と矛盾 (たとえば、期限より後に取り組む期間が終わる) を見つけ、確かめることを出します。本番では、AI がその案件ならではの見落としを提案する予定です。
3. 確かめることごとに、誰にいつまでにお願いするかを決め、回答をもらって片付けます。
4. 成功の定義を関係者が読める版として確定し、関係者がその版を確かめ、異議があれば記録します。
5. 最終判断者が、その版に対して承認します。承認した版は変えず、直す時は新しい版を作って承認し直します。

AI は下書きと問いを出すだけです。引き受け・確認・承認は AI が代わりに行わず、人が記録します。 名前・日付・数値は直接入力でもらい、AI に推測させません。 決まっていない大事な項目は、架空の値で埋めずに「確かめること」にします。

届けるもの

• 招待した人だけが使えるウェブアプリ
• 7 つの問いで成功を定義する画面
• 確かめることの一覧 (担当・期限・回答・確認)
• 成功の定義の版と、その版への合意の記録
• 次の工程へ渡す出力 (Markdown と JSON)

主な使い方

やりたいこと	要点
大事なことに答えて、計画を整理したい	分からない問いは分からないまま進める。名前・日付・数値を推測で確定しない
始める前に、足りないことと矛盾を知りたい	理由つきの「確かめること」が重複なく出る
確かめることを、適切な人にお願いしたい	担当と期限を決め、回答をもらう
正しい版を確かめ、異議を伝えたい	版が新しくなったら、古い版への確認を流用しない
合意した版を承認したい	条件がそろった版だけを承認できる
合意した内容を次の工程に引き継ぎたい	承認した版と、決めた人を特定できる形で出力する

調べたこと

• 2026-09-05 に、画面を作る前に、SAGUS の社内の案件 1 件で、質問と確認の流れを文書だけで 1 周しました。質問に答えるのに約 12 分、確かめること 13 件の片付けに約 10 分、確認と承認に約 3 分で、合わせて約 25 分でキックオフの資料が承認まで進みました (関係者への確認の時間は含みません)。
• 足りない項目を見つける規則は、用意した 18 件のうち 5 件が働き、どれも「確かに決めていなかった」と埋められる指摘でした。働かなかった規則と、足りなかった規則 (稼働と目標の釣り合いなど) も記録し、作り直しに使いました。
• 社外の利用者による検証は、まだです。

似たサービスとの違い

プロジェクト管理ツール、ワークショップのテンプレート、AI による要求文書の作成サービスは、計画書や資料を作るところを助けます。 Day Zero は「AI が計画書を作ること」を売りにしません。キックオフに要る、決まっていないことを片付け、関係者の合意まで閉じることを中心に置きます。この違いが効くかは、これから確かめる仮説です。

最初の版でやらないこと

• 需要や事業性の検証、インセプションデッキ、詳しい要求、技術の選定や見積り (次の工程の範囲です)
• Slack や GitHub などとの連携、会議そのものの開催・進行・議事録
• 顧客自身の登録や課金
• 複数の承認者
• 社外の案件のデータは、認証・組織の分離・監査・削除・復旧などの条件をすべて満たすまで扱いません

これから

• 本番の機能 (ログイン・保存・AI による提案・承認) を、試作で確かめた流れから順に作ります。
• 社内の実際の案件で使い、その後、社外の案件でも確かめる計画です。
• 確かめることや承認の通知、合意の後の振り返りは、使ってみて繰り返し困ったものから選びます。

作り方

• SAGUS チームが判断し、要求の整理・設計・実装・レビューは AI (Claude Code) が担当しています。要求と設計の文書は、書いた AI とは別の AI のレビューも受けています。
• AI の成果は、SAGUS チームが受け入れの条件で確かめてから公開しています。
• 本番の仕組みを作る前に、仮のデータで動く試作を作り、画面の流れを確かめてから本番に進む順にしました。要求を決めた 2 日後に、操作できる試作ができました。
• 試作を触って、作り直したことがあります。最初は 14 の質問と 4 つの段階でしたが、多すぎて手順が重かったため、「成功を定義する」7 問と 3 つの段階 (成功の定義・確かめること・合意) に絞りました。画面も、1 問ずつ答えると上に積み上がる会話の形に作り直しました。
• 今は、仮のデータで動く試作を、SAGUS チームの中だけで開ける形で公開して確かめています。