KAWARU CLOUD / REQUIREMENTS BREAKDOWN
開発要件 14件 — 詳細と 8/7 展開の可否
2026-08-04 のヒアリングで挙がった開発要件を、実コードで裏を取って整理したもの。優先度は依頼者の指定。8/7 午前に全営業メンバーが本番で使い始める前提で、実作業 2.5 日に何が入るかを仕分けている。
整理日 2026-08-04
展開日 2026-08-07 午前
実装締切 8/6 夕方
対象 CRM入力画面（GAS WebApp ＋ BigQuery）
最高 ＋ 高
10件
8/7 午前までに使える状態がマスト
実作業に使える時間
2.5日
8/4 残り・8/5・8/6
SECTION 01
時間の現実 — 積み上げると入らない
「最高」＋「高」の10件を積み上げると、使える 2.5 日を大きく超える。どれを落とすかを決めないと、全部が中途半端に終わる。
SECTION 02
14件の一覧 — 優先度と 8/7 判定
判定は「8/7 午前に本番で使える状態にできるか」。○＝確実、△＝縮小案なら可、✕＝不可能。
| No | 要件 | 優先度 |
8/7 | レイヤ | 所要 | 判定の理由 |
| 1 | 更新・読み込みの高速化 | 最高 | △ | 画面＋GAS＋BQ | 2日 | 実測0.5秒は物理的に不可。体感を上げる方式なら可 |
| 2 | カード削除＋権限（高橋のみ） | 高 | ✕ | BQ | 3日 | BQ作業が2種類（権限＋VIEW）。高倉さん枠が2回必要 |
| 3 | 取り込み済みデータを既定で全表示 | 中 | ○ | 画面 | 0.5日 | チェックの初期値のみ。ただし件数5.8倍で①と衝突 |
| 4a | ポップアップの横長化 | 高 | ○ | 画面 | 0.5日 | CSSと配置のみ |
| 4b | 商談議事録の反映 | 高 | ✕ | BQ新規 | 15日〜 | 実装ゼロ。データ取得元も未定。単独プロジェクト規模 |
| 5 | デジマ取込の即時反映 | 高 | ✕ | BQ＋基盤 | 13日 | 遅いのではなく7/23から停止中。復旧が4段階 |
| 6 | NA内容・期日の表示、超過で色 | 高 | ○ | 画面 | 0.5日 | ほぼ実装済み。色の割り当て変更のみ |
| 7 | 無効化フェーズを別タブに移動 | 低 | ○ | 画面＋GAS | 1日 | ⑧⑬と同根。まとめれば追加コストは小さい |
| 8 | フェーズ選択肢をマスタと連動 | 高 | ○ | 画面 | 1日 | 原因特定済み。除外処理を足すだけ |
| 9 | Slackリマインド連携 | 中 | ✕ | manifest＋外部 | 10日 | 時間トリガー導入は安全設計の変更。要合意 |
| 10 | 特定フェーズ移動時に背景を必須化 | 高 | △ | 画面＋BQ | 0.5日 | 入力欄は既存。正攻法はBQマスタ、直書きなら即日だが規約違反 |
| 11 | 提案商材の複数選択 | 高 | △ | 画面＋BQ | 0.5日 | 複数化はデータ構造変更で不可。単一のまま更新画面に出すなら可 |
| 12 | 最終決定サービス＋料金を必須化 | 高 | ✕ | 画面＋GAS＋BQ | 5日 | BQに列が無い＝保存先が存在しない。列追加が先 |
| 13 | ボードの大分類をフェーズと連動 | 中 | ○ | 画面 | 0.3日 | ⑧と同根。同時に直せば追加コストほぼゼロ |
| 14 | 確度をパーセンテージ3分類に | 高 | △ | 画面＋BQ | 0.5日 | 既存データの移行は不可。UIだけ3択にするなら可 |
優先度の分布から見えること
「高」が9件で全体の64%。優先度がついていない状態に近い。しかも同じ「高」の中に、0.3日で終わる⑬と、15日以上かかる④bが同居している。このままだと、すぐ終わるものが大物に埋もれて後回しになる。
SECTION 03
要件の詳細
各要件の現状を実コードで確認した結果。「現状」はすべて実測・実ファイルの記述に基づく。
最高
1更新・読み込みの高速化8/7 △
要望
情報の読み込み、フェーズ・ステータスの移動を 0.5秒程度にしたい。
現状
v1.4.0 で 11秒 → 3秒前後まで改善済み（マスタキャッシュ TTL1800 ／ 往復統合 ／ ボード遅延描画）。
| 内訳 | 時間 | 削れるか |
|---|
| GASの往復 google.script.run | 0.3〜0.8秒 | ほぼ不可（仕様） |
| BigQuery のクエリ | 0.5〜2秒 | 限界あり |
| 画面の再描画 | 0.2〜0.5秒 | 可 |
実測0.5秒は現構成では到達できない。固定費の合計が既に0.5秒前後あるため。
体感0.5秒なら作れる。サーバーの返事を待たず画面を先に動かし、失敗したら戻す方式。ただし「画面では移動したのに保存されていない」を絶対に起こせないので、失敗時の見せ方の設計に時間がかかる。
この要件が抱える構造的な問題
③（既定で全件表示）と正面衝突する。
| 表示 | 件数 |
|---|
| 現在の既定 | 80件 |
| ③を実施した場合 | 461件（Notion 148 ＋ 旧CRM 233 が加わる） |
描画対象が 5.8倍になる。速くしたい要望と、表示を増やす要望を同時に叶えるには、仮想スクロールかページングが必要になり、③は「チェックの初期値を変えるだけ」では済まなくなる。
判断が必要：速度と全件表示、どちらを優先するか。
高（9件）
8フェーズ選択肢をフェーズ管理と連動8/7 ○
原因は特定済み
JavaScript.html:639 で STATE.statuses を無条件に全件ループしている。マスタとは繋がっているが、無効化されたフェーズを除外する処理が無い。
サーバー側は既に正しい
Api.gs:691-698「いま既にその値である場合だけは無効化済みでも通す」。廃止フェーズの案件で担当やメモだけ直す操作をブロックしないための判定。UIをこれと鏡合わせにすればよい。
直し方：選択肢から is_active=FALSE を除外。ただし現在値だけは残す。画面のみで完結、BQ不要。
6NA内容・期日の表示、超過で色8/7 ○
ほぼ実装済み
JavaScript.html:121 naCellHtml_ が一覧・ボードカードの両方で使われ、既に3段階で表示している。
| 状態 | 表示 | 現在の色 |
|---|
| 超過 | 「N日超過」 | 赤 |
| 当日 | 「本日」 | 黄 |
| 未来 | 「あとN日」 | 通常 |
NA内容も18文字まで表示済み。
要確認：ご要望の「黄色」は現在当日を表している。実画面で見えていれば色変更のみ。見えていなければ別の不具合（データ側に期日が入っていない等）。
4aポップアップの横長化8/7 ○
更新ダイアログ dlgUpdate の幅を広げ、項目配置を見直す。画面のみで完結。
注意：Style.html に display を書き足すときは [hidden]{display:none !important} を殺していないか必ず確認。過去にこれでモーダルが閉じなくなり、画面が使用不能になる本番障害が発生している。
4b商談議事録の反映8/7 ✕
商談ごとの議事録をカードの中に直接反映したい。
現状
議事録関連の実装は Api.gs に 0件。完全に新規。議事録の取得元（Zoom／手入力／他システム）も未確定。
新しいデータソースの追加にあたるため、4箇所への波及ルールがまるごと当たる。過去にこの波及を1箇所忘れて163件が「unknown」に落ちた事故がある。単独で1プロジェクト規模。
分割を推奨：④a（横長化・0.5日）とは切り離す。横長化だけなら 8/7 に入る。
5デジマ取込の即時反映8/7 ✕
「遅い」のではなく止まっている。docs/DATA_MODEL.md:270：stg_intake_event が 2026-07-23 から更新停止（119行）。
復旧は4段階
| # | 内容 |
|---|
| 1 | Notion取込の倍増バグ修正（2回loadすると倍になる） |
| 2 | 取りこぼし監視の復旧（現在0行＝1件も評価していない） |
| 3 | 取込の復旧・日次自動化 |
| 4 | 即時化 |
順序を飛ばすとデータが倍になる。1 を飛ばして 3 をやると実害が出る。
10特定フェーズ移動時に背景を必須化8/7 △
入力欄は既にある
Index.html:208 に「変更理由・メモ」欄が存在し、raw_ui_event.change_note に入る。設計書に「口頭/メールでのキャンセル等、唯一の受け皿」とある。新しいダイアログは不要。
必要なのは必須化のロジック
対象フェーズ（開約・失注・対応不可）で、空のまま保存できなくする。
正攻法はBQマスタ。「どのフェーズが対象か」をコードに書くと、区分値をコードに書かないという設計の柱に違反する。フェーズが増減するたびにコード改修が必要になる。
抜け道：直書きなら 0.5日で 8/7 に入る。ただし明示的な技術的負債として記録し、来週マスタ化し直す前提が必要。
11提案商材の複数選択8/7 △
現状と要望の差は3つ
| 現状 | 要望 |
|---|
| 場所 | 新規登録のみ（更新画面に無い） | 更新画面にも |
| 個数 | 単一値 | 複数選択 |
| 入力 | 自由入力（datalist） | 選択肢固定 |
複数値化はデータ構造の変更。1案件1商材の前提で列が作られているため、4箇所への波及が当たる。8/7 には入らない。
縮小案：単一選択のまま更新画面にも商材欄を出す（0.5日）。複数化は来週。
⑫と対の概念。提案商材 → 最終決定サービス。商材マスタは共通なので同時に設計すべき。
12最終決定サービス＋料金を必須化8/7 ✕
ルール
| 移動元 | 移動先 |
|---|
| 商談実施 ／ 担当者合意 ／ 決済者合意 | 契約書締結 ／ デリバリー中 ／ デリバリー完了 |
必須：最終決定サービス ＋ 初期費用・月額費用・一括請求費用のいずれか1つ以上。解約は対象外。目的は請求書管理の徹底。
BQに列が無い＝保存先が存在しない。列追加（ALTER TABLE）が先。列が無い状態でコードを書いても保存できない。
「必須」はDBでは守れない。BigQuery の ADD COLUMN は NOT NULL を付けられない（既存行を埋められないため）。担保はサーバー側の検証でしか実現できず、過去データは全てNULLのまま残る。請求管理では「いつ以降のデータが信頼できるか」の明示が要る。
列追加には前例がある。Phase3 で8列以上を冪等に追加した実績があり、同じ形を踏襲できる。
14確度をパーセンテージ3分類に8/7 △
現状：確度はマスタではない
JavaScript.html:650 で 実データのDISTINCT を拾っているだけ。入力欄も自由入力。フェーズ（マスタ駆動）とは作りが違う。
必要な作業は4段階
| 1 | 確度マスタを新設 | BQ |
| 2 | 既存データを3分類へマッピング | BQ |
| 3 | 自由入力 → 固定選択に変更 | 画面 |
| 4 | フィルタの供給元を実データ→マスタへ | 画面 |
2が論点。現在どんな値が入っているか（「A」「高」「80%」等の混在の可能性）を見ないと移行ルールが決められない。フィルタのプルダウンを開けば実在する値がそのまま出る。
縮小案：UIだけ3択に固定（0.5日）。既存データはそのまま残るので不整合は出る。
2カード削除＋権限（高橋さんのみ）8/7 ✕
物理削除は実装しない。append-only の設計の柱を壊すため。根拠3箇所：IAMで人間のDELETE/UPDATEを与えない方針、禁止事項5、そして「基本、削除はないはず」という依頼者ご自身の発言が実装コメントに引用されている。
方式
論理削除イベントを追記し、画面が読むVIEW側で除外する。
BQ作業が2種類必要：権限マスタの変更（admin 3名 → 1名）＋ VIEWの変更。高倉さんの枠が2回要る。
目的が「テスト用データの除去」なら別解がある。テストモードで入れたデータを弾く仕組みが既に実装済み。VIEW 1本で除外できる可能性があり、その場合コード変更は不要。
中（3件）・低（1件）
3取り込み済みデータを既定で全表示8/7 ○
チェックボックス「取り込み済みデータ（Notion・CRM）も表示」は既定OFF。既定表示 80件 ／ 全件 461件。
①（速度）と正面衝突する。描画対象が5.8倍になる。両立には仮想スクロールかページングが必要。
13ボードの大分類をフェーズと連動8/7 ○
JavaScript.html:586-587 で STATE.stages を無条件に全件ループ。⑧と全く同じ原因。
⑧と同時に直せば追加コストはほぼゼロ。優先度は「中」だが、⑧が「高」なので実質同時に片付く。
9Slackリマインド連携8/7 ✕
NA期日の当日・3日前・1週間前に、担当者へメンション付きで通知。
明文化された安全装置を壊す。運用手順書に「このプロジェクトには時間トリガーが1本もないので、pushによる本番への副作用はありません。トリガーを追加する場合はこの前提が崩れる。必ず高倉さんに相談」と明記されている。時間トリガーを1本入れた瞬間、pushしただけで本番が動く世界に変わる。
manifest変更も必要。現在は外部HTTP通信の権限が無い。追加すると、剥がれると404になり修復が難しい設定ファイルを触ることになる。
7無効化フェーズを別タブに移動8/7 ○
マスタ管理の「一覧・編集」タブから無効化フェーズを外し、専用タブへ移す。
⑧⑬と同根。優先度は「低」だが、まとめて直すのが正しい。片方だけ直すと必ず兄弟が残る（このプロジェクトで4日間に9回起きた事故の型）。
SECTION 04
同じ根っこでまとまるもの
14件はバラバラではない。3つのグループに束ねられる。束ねて直すと安く済み、バラして直すと必ず取りこぼす。
SECTION 05
8/7 に向けた3つの選択肢
実作業 2.5 日をどう配分するか。①（最高）に2日使うと、他は2件しか入らない。ここが最大の判断ポイント。
A. 速度優先
3件
①の体感高速化に2日を使う。残り0.5日で⑥⑧のみ。
最優先の要望に正面から応えるが、誤入力を防ぐ修正がほとんど入らないまま全員が使い始めることになる。
入るもの：① ⑥ ⑧
C. 中間（推奨）
4件＋α
①の高速化をフェーズ移動だけに絞る（1日）。残り1.5日で小粒を回す。
遅さが最も刺さるのはボードでカードを動かす操作。そこだけ体感を上げれば「使えない」という第一印象は避けられる。一覧の初回読み込みは1回だけなので3秒でも致命傷にならない。
入るもの：①（部分） ⑥ ⑧ ④a ＋ ⑬⑦（同根なのでほぼ無料）
B. 件数優先
6件
①は実測のみ（0.5日）にして、小粒を最大化する。
件数は稼げるが、最優先とされた速度が展開日に改善されない。9月の本作業の前提は固まる。
入るもの：⑥ ⑧ ④a ⑪縮小 ⑭縮小 ⑩縮小
NEXT
今日中に決めること
この3つが今日動かないと、8/7 は成立しない
01 deploy 枠の確保
開発担当は本番反映（clasp deploy）を実行できない。8/6 夕方に高倉さんが動けないと、コードが完成していても 8/7 に本番は何も変わらない。テスト用URLで見えているだけの状態になる。
02 担当者マスタの確認
担当者マスタは 3人分 5行しか登録が確認できていない。補完用のファイルは7/29から「高倉さん確認待ち」で止まったまま。未登録のメンバーは自分の名前を選択肢から選べないため、展開初日に手が止まる。これはコードでは直せない。
03 A / B / C の選択
実作業2.5日の配分。①に2日使うか、1日に絞るか、実測だけにするか。これが決まらないと 8/5 の朝から手が止まる。