2026-08-04 のヒアリングで挙がった開発要件を、実コードで裏を取って整理したもの。8/9 に状況を再取得し、計画と実績の差分を反映した。下の SECTION 00 が最新の状況、SECTION 01 以降は 8/4 時点の計画（記録として残している）。
8/4 の計画時点と、いま（8/9）では前提が変わっている。計画の良し悪しの前に、まず何が変わったかを共有する。
8/4 に 案A（Cloud Run + IAP）が追加され、以降の実装はすべて新基盤の中で進んでいる。Node.js のサーバー実装一式、テスト、設計判断記録（D-1〜D-19）まで揃っている。
この14件が REQ-0001〜0017 として整理され、運用の仕組みまで作られている。
| 追加されたもの | 役割 |
|---|---|
| requirements/REQ-*.md | status / priority / needs / target / deployed_at を持つ |
| requirements/validate.js | 要件ファイルの検査 |
| .github/workflows/ | CI で自動検査 |
| .claude/skills/req/ | 起票用スキル |
| ID | 要件 | status | 優先 | target | 本番反映 | 8/9 時点のメモ |
|---|---|---|---|---|---|---|
| REQ-0001 | 案件ボードの表示速度改善 | in_progress | P0 | 08-08 | 未 | 唯一の着手中。owner 高倉さん。Cloud Run 移行そのものが対策 |
| REQ-0002 | カード削除＋権限 | reviewing | P1 | 08-07 | 未 | 旧GAS側に未検証の実装1440行が手元に残存 |
| REQ-0003 | 取り込み済みデータを既定で全表示 | reviewing | P2 | 08-07 | 未 | 新基盤で実装済み（8/7 コミット） |
| REQ-0004 | ポップアップの横長化 | reviewing | P1 | 08-07 | 未 | 新基盤で実装済み（8/7 コミット） |
| REQ-0005 | 商談議事録の反映 | reviewing | P1 | 08-07 | 未 | 新基盤で実装済み。8/4 に「15日以上・単独プロジェクト規模」と見積もった要件が入っている |
| REQ-0006 | NA内容・期日の表示、超過で色 | reviewing | P1 | 08-07 | 未 | 旧画面では既に実装済み。新基盤側の移植状況は要確認 |
| REQ-0007 | デリバリー・請求管理 | draft | P3 | 08-31 | 未 | 新規に切り出された要件。⑫の事業目的が独立した形 |
| REQ-0008 | 日次取込の自動化 | draft | P1 | — | 未 | 設計判断は 8/6 に記録済み（D-19〜）。target 未設定 |
| REQ-0009 | 新規登録・一括分類を新画面へ | draft | P2 | — | 未 | 新規要件（移行に伴って発生） |
| REQ-0010 | 無効化フェーズを別タブに移動 | reviewing | P3 | 08-07 | 未 | 8/5「フェーズ管理を新画面へ」で関連実装が入った |
| REQ-0011 | フェーズ選択肢をフェーズ管理と連動 | reviewing | P1 | 08-07 | 未 | 同上。8/4 に「確実に入る」と判定した要件 |
| REQ-0012 | Slackリマインド連携 | reviewing | P2 | 08-07 | 未 | 時間トリガーの論点は Cloud Run 移行で前提が変わる |
| REQ-0013 | 特定フェーズ移動時に背景を必須化 | reviewing | P1 | 08-07 | 未 | — |
| REQ-0014 | 提案商材の複数選択 | reviewing | P1 | 08-07 | 未 | — |
| REQ-0015 | 最終決定サービス＋料金を必須化 | reviewing | P1 | 08-07 | 未 | 請求管理の本体。REQ-0007 と対 |
| REQ-0016 | ボードの大分類をフェーズと連動 | reviewing | P2 | 08-07 | 未 | 新基盤で実装済み（8/7 コミット） |
| REQ-0017 | 確度をパーセンテージ3分類に | reviewing | P1 | 08-07 | 未 | — |
status は reviewing 13 ／ draft 3 ／ in_progress 1。dev_done と closed はいずれも0件。コードが入っている要件も status は reviewing のままなので、ファイルの状態と実装の実態がずれている。ここを合わせないと、この仕組みは進捗を映さなくなる。
レイヤ判定が律速になるという読み。実際、要件ファイルの needs: に同じ考え方が採用された。
①（速度）は小手先では届かないという判断。基盤の載せ替えという回答になった。
2.5日で10件は入らないという見立て。実際、旧画面への反映は0件。
④b 商談議事録を「15日以上・8/7 には不可能」と見積もったが、新基盤の上で 8/7 に実装が入っている。基盤を替えるという選択肢を計算に入れていなかったのが原因。
既存資産の制約を前提に見積もると、作り直す判断の方が速い場合を見落とす。
新基盤の実装が営業の業務で実際に使えるかは、切り替えるまで分からない。テストは厚いが、テストが通ることと現場で回ることは別。
旧画面とのデータの地続き性も未検証。
「最高」＋「高」の10件を積み上げると、使える 2.5 日を大きく超える。どれを落とすかを決めないと、全部が中途半端に終わる。
判定は「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が同居している。このままだと、すぐ終わるものが大物に埋もれて後回しになる。
各要件の現状を実コードで確認した結果。「現状」はすべて実測・実ファイルの記述に基づく。
情報の読み込み、フェーズ・ステータスの移動を 0.5秒程度にしたい。
現状v1.4.0 で 11秒 → 3秒前後まで改善済み（マスタキャッシュ TTL1800 ／ 往復統合 ／ ボード遅延描画）。
| 内訳 | 時間 | 削れるか |
|---|---|---|
| GASの往復 google.script.run | 0.3〜0.8秒 | ほぼ不可（仕様） |
| BigQuery のクエリ | 0.5〜2秒 | 限界あり |
| 画面の再描画 | 0.2〜0.5秒 | 可 |
③（既定で全件表示）と正面衝突する。
| 表示 | 件数 |
|---|---|
| 現在の既定 | 80件 |
| ③を実施した場合 | 461件（Notion 148 ＋ 旧CRM 233 が加わる） |
描画対象が 5.8倍になる。速くしたい要望と、表示を増やす要望を同時に叶えるには、仮想スクロールかページングが必要になり、③は「チェックの初期値を変えるだけ」では済まなくなる。
JavaScript.html:639 で STATE.statuses を無条件に全件ループしている。マスタとは繋がっているが、無効化されたフェーズを除外する処理が無い。
サーバー側は既に正しいApi.gs:691-698「いま既にその値である場合だけは無効化済みでも通す」。廃止フェーズの案件で担当やメモだけ直す操作をブロックしないための判定。UIをこれと鏡合わせにすればよい。
JavaScript.html:121 naCellHtml_ が一覧・ボードカードの両方で使われ、既に3段階で表示している。
| 状態 | 表示 | 現在の色 |
|---|---|---|
| 超過 | 「N日超過」 | 赤 |
| 当日 | 「本日」 | 黄 |
| 未来 | 「あとN日」 | 通常 |
NA内容も18文字まで表示済み。
更新ダイアログ dlgUpdate の幅を広げ、項目配置を見直す。画面のみで完結。
商談ごとの議事録をカードの中に直接反映したい。
現状議事録関連の実装は Api.gs に 0件。完全に新規。議事録の取得元（Zoom／手入力／他システム）も未確定。
| # | 内容 |
|---|---|
| 1 | Notion取込の倍増バグ修正（2回loadすると倍になる） |
| 2 | 取りこぼし監視の復旧（現在0行＝1件も評価していない） |
| 3 | 取込の復旧・日次自動化 |
| 4 | 即時化 |
Index.html:208 に「変更理由・メモ」欄が存在し、raw_ui_event.change_note に入る。設計書に「口頭/メールでのキャンセル等、唯一の受け皿」とある。新しいダイアログは不要。
必要なのは必須化のロジック対象フェーズ（開約・失注・対応不可）で、空のまま保存できなくする。
| 現状 | 要望 | |
|---|---|---|
| 場所 | 新規登録のみ（更新画面に無い） | 更新画面にも |
| 個数 | 単一値 | 複数選択 |
| 入力 | 自由入力（datalist） | 選択肢固定 |
| 移動元 | 移動先 |
|---|---|
| 商談実施 ／ 担当者合意 ／ 決済者合意 | 契約書締結 ／ デリバリー中 ／ デリバリー完了 |
必須：最終決定サービス ＋ 初期費用・月額費用・一括請求費用のいずれか1つ以上。解約は対象外。目的は請求書管理の徹底。
JavaScript.html:650 で 実データのDISTINCT を拾っているだけ。入力欄も自由入力。フェーズ（マスタ駆動）とは作りが違う。
必要な作業は4段階| 1 | 確度マスタを新設 | BQ |
| 2 | 既存データを3分類へマッピング | BQ |
| 3 | 自由入力 → 固定選択に変更 | 画面 |
| 4 | フィルタの供給元を実データ→マスタへ | 画面 |
論理削除イベントを追記し、画面が読むVIEW側で除外する。
チェックボックス「取り込み済みデータ（Notion・CRM）も表示」は既定OFF。既定表示 80件 ／ 全件 461件。
JavaScript.html:586-587 で STATE.stages を無条件に全件ループ。⑧と全く同じ原因。
NA期日の当日・3日前・1週間前に、担当者へメンション付きで通知。
マスタ管理の「一覧・編集」タブから無効化フェーズを外し、専用タブへ移す。
14件はバラバラではない。3つのグループに束ねられる。束ねて直すと安く済み、バラして直すと必ず取りこぼす。
実作業 2.5 日をどう配分するか。①（最高）に2日使うと、他は2件しか入らない。ここが最大の判断ポイントだった。実際にはこの3案のいずれも採られず、基盤を Cloud Run へ移すという第4の道が選ばれた。以下は当時の検討として残す。
①の体感高速化に2日を使う。残り0.5日で⑥⑧のみ。
最優先の要望に正面から応えるが、誤入力を防ぐ修正がほとんど入らないまま全員が使い始めることになる。
入るもの：① ⑥ ⑧
①の高速化をフェーズ移動だけに絞る（1日）。残り1.5日で小粒を回す。
遅さが最も刺さるのはボードでカードを動かす操作。そこだけ体感を上げれば「使えない」という第一印象は避けられる。一覧の初回読み込みは1回だけなので3秒でも致命傷にならない。
入るもの：①（部分） ⑥ ⑧ ④a ＋ ⑬⑦（同根なのでほぼ無料）
①は実測のみ（0.5日）にして、小粒を最大化する。
件数は稼げるが、最優先とされた速度が展開日に改善されない。9月の本作業の前提は固まる。
入るもの：⑥ ⑧ ④a ⑪縮小 ⑭縮小 ⑩縮小
8/4 の論点（deploy枠の確保・担当者マスタ・A/B/Cの配分）は、基盤移行という判断によって役目を終えた。いまの論点は3つに変わっている。