プロダクトUIデザイン定例（クーポン構造化＋プロジェクトプロセス見直し）

サマリ

• クーポン機能の設計を構造的に再構築する方針で合意。モーダルを「要素 × 場合分け」の単純な組み合わせに（モーダル1 必ず出す / モーダル2 宿泊時のみ）
• ドキュメント管理を Google ドライブの md ファイルに集約。Claude Code との対話時に必ず読み込む運用へ
• プロジェクトプロセス見直し: 概要設計を握ってから実装ペア化。フィグマフィックスまで最低 1 週間バッファ。横浜市要件変更による 6 月リリース範囲再検討

決定事項

• モーダル設計: 共通テンプレ + 場合分けの組み合わせ方式に統一
• 各ブロック約 9 個について全場合分けを明記（例: 1 泊 2 日でクーポン 2 枚消費 = 1 日 6,100 円）
• 「自費で予約に進む」ボタンテキストに修正
• ドキュメント管理: クーポン機能仕様を Google ドライブ md に集約、対話前に必ず読み込み
• プロジェクトプロセス: 概要設計を細かく握る → 優先順位で決定 → 設計と実装をペアに
• 6 月リリース範囲: 横浜市要件変更により再検討（インポート機能はマスト、集合契約・国の減免・請求書は別タイミング）
• フィグマフィックスまで最低 1 週間のバッファをスケジュール上に確保
• 来週日曜に園田 → 信田で 6 月リリース範囲を最終擦り合わせ

議論メモ

クーポン機能設計の構造化

• 園田: 既存モーダル設計は要素を全網羅できないと実装で問題発生
• 園田: モーダル1・2 を共通化し、単に場合分けすればエンジニアが楽
• 園田: Notion レビュー時には気付けなかった発想が UI を見て初めて可能に（手戻りは避けられない）
• 園田: 基本「施設種類（日帰り/宿泊）× 日付選択」でモーダル1、宿泊なら泊数選択でモーダル2
• 園田: クーポンを使う自治体ではモーダル1 必ず出す、単位は事業区分ごと
• 園田: 出す/出さないのロジック分岐をしない、前例としてモーダル出す方が良い
• 園田: タイムライン表示が分かりにくい → ゆこびんに新表示作成依頼
• 園田: 未来予約は「自費か否か」で該当クーポン割当、共通クーポンの場合は事業区分補足
• 園田: オプション代金がクーポン対象外の注記は国の減免/無料クーポン使用時だけ
• 園田: 「自費で予約に進む」ボタンテキストに修正

ドキュメント管理とエンジニア連携

• 園田: クーポン機能の全情報を Google ドライブ md に集約、対話時に必ず読み込み運用
• 園田: Claude Code との対話が「賢い状態」になる、これが資産
• 園田: テーブル設計・カラム名も Claude Code 上で対話して新カラム提案も可能に
• 園田: 非エンジニア側がエンジニア側に踏み込むのが楽。全員プロダクト/ビジネス/ドメイン理解必須
• 園田: 分からなければ Claude に聞けば良い

スケジュール調整と実装計画

• 伊原: UI 設計を 5/15 完了予定だったが、機能概要設計が長引き UI 提出が 5/22 に
• 伊原: 5/13 依頼、5/14 まで 2 日期限だったと認識
• 園田: 実際は 5/12 投げて 5/14 までの依頼
• 園田: 5/20 確認依頼 → 5/22 返信の期限
• 園田: 修正があれば 2-3 回ラリーが必要、最終フィックス予定の確認
• 2049 INOKUBO: 機能概要設計の代理予約モーダルで長引いた、5/22 までに収めたかった
• 園田: 利用者側 UI は 3 月にフィックス済み、実装はゼロ
• 園田: 事業者側 UI は「利用者の転用」で軽いと思っていたが、構造化されておらず実装危険

利用者側と事業者側の設計プロセス相違

• 2049: 利用者側は既リリース認識
• 2049: ゆこびんが場合分けを用意していなかった
• 伊原: ゆこびんの小さいクーポンパターンをそのまま使用
• 園田: ゆこびんが多パターン作ってくれるとは想定外

6 月リリース範囲と優先順位

• 2049: 6 月リリース範囲を来週日曜に話したい
• 2049: 設計レベル細部より、概要設計を細かく握って優先順位で決め、設計と実装ペアにする方式提案
• 園田: 賛成。細かく詰めると詳細設計書になり、フィグマがマークダウンになっただけ
• 2049: 要件・何をしたいかまで握るレベル感が適切
• 伊原: 最後はフィグマレビューが入ってから
• 園田: フィグマフィックスまで最低 1 週間欲しい
• 2049: 2 日でレビュー依頼来て「全部もう 1 回」となるリスクを避けたい、リスケしかなくなる
• 2049: 実装が詰まる部分の設計に集中性が来ている

横浜市要件変更と実装への影響

• 2049 INOKUBO: 7 月集合契約・国の減免、8 月請求書の話が出てくる
• 2049: 6 月リリースをなくして集合契約一式・6/1 リリース提案
• 2049 INOKUBO: 6 月マストは無いが、インポートはマスト
• 園田: 履歴インポート、横浜市は 7/1 に間に合わない
• 園田: 今日も横浜市側が「市民も事業者もどうでもいい、横浜市のやりたいようにやる」と発言
• 園田: 来週横浜市に行く。担当変更で前提が変わった
• 園田: 課長補佐は頭は良いが歩み寄り姿勢なし
• 2049: 横浜は日本一の市だから難しい
• 園田: 横浜市民だけ格差が生まれる、他市町村より不公平と伝えるしかない
• 園田: 自費の場合は実績報告書を提出不可にする、インポート機能、自費アラート出し、承認前予約禁止 — 4 つは仕様確定方向

議事録時点のフォロー事項

• 伊原: モーダル再設計（共通テンプレ + 場合分け）
• ゆこびん: 新タイムライン表示作成
• 2049 INOKUBO: 機能概要設計の Notion ドキュメント化
• 園田: 来週日曜に信田と 6 月リリース範囲擦り合わせ
• 園田: クーポン機能 md ドキュメントを Google ドライブに集約
• 園田: 来週横浜市訪問（担当変更後の擦り合わせ）

持ち越し・次回までの宿題

• フィグマレビュー期間 1 週間の運用ルール化
• 概要設計レベルでの握り方の標準化
• 横浜市要件変更による 6 月リリース範囲の最終決定
• インポート機能の優先実装

次回

• 日時: 翌週日曜（園田×信田）+ 通常定例
• アジェンダ案: 6 月リリース範囲最終確定、モーダル再設計レビュー、横浜市訪問結果共有

補足

• ASR 補正: 「ノブタ／野太」→「信田直人」、「ユコビン」→「ゆこびん」、「いはらさん／井原氏」→「みき いはら」、「2049／二零四九」→ デザイン会社「2049」、「INOKUBO／いのくぼ」→「2049 Inokubo」、「山道氏／山見氏」→「Masaaki YAMAMICHI」、「フォーマント」→ フォーマット/テンプレートの意、「ニチ／ハク」→「日／泊」、「慈悲」→「自費」、「集合性」→ 文脈上「集中／集約」の意、「海外の県」→「カーゴカルト／プロジェクト」の ASR ノイズ想定
• 「フォーカー市」→「福岡市」、「ニーゼル案件」→ 不明（要確認）、「ミラブル／ミラボ」→「ミラボ」（競合）
• 内部 MTG のため文字起こし生データセクションは含めない（[[feedback-government-meetings]] ルール準拠）