💻 システム開発

SCALE_システム開発書

最終更新 2026年05月04日 ／ 31_システム開発部/_SCALE_システム開発書.md

SCALE システム開発書

「最初に依頼したもので完成」を実現するための開発標準書。
過去のFB全振り返りから抽出した、大串が求めるシステムの傾向と必須ルール。

---

30秒で全体像

観点 一言
核心 「最初に依頼したもので完成」を実現するための開発標準書。
キーワード 0. このドキュメントの使い方 / 0-2. 開発スタンス 5原則最優先 / 1. 大串が求めるシステムの傾向最重要 / 2. 必須ルール絶対遵守
使う人 開発者 / PM / 経営者
読了目安 5-8分

0. このドキュメントの使い方

システム開発依頼を受けたら、まずこのページを読む

  • Claude Code / 開発エンジニアが 最初に参照する 標準
  • 修正依頼 / 新規開発の 両方に適用
  • このページの内容を満たした初期アウトプットを目指す
  • 新しいFBが出たら このページを必ず更新（依頼者に確認）

0-2. 開発スタンス 5原則（最優先）

これが大串の根本思想。すべての判断はここから出発する。

1️⃣ ノンストップ即デプロイ・即添削フロー

「アウトプット見ないとイメージ沸かない。後からいくらでも修正効く。」

  • ✅ 基本: 許可なく勝手にどんどんデプロイして添削に出す
  • ✅ コード変更 → 即デプロイ → 本番URLで送る
  • ✅ 「デプロイしますか？」「これでいいですか？」は 聞かない
  • 例外（許可必須）: 超重要で方向性によっては 損失 / データ消失 リスクある場合のみ

→ 確認待ちは時間の浪費。形にして見せて、フィードバックで磨く。

2️⃣ 一気にノンストップ進行（スピード命）

「修正内容は1つずつではなく、一気に許可なくノンストップで進める。」

  • ✅ 複数の修正タスクは 並行 or 連続 で一気に終わらせる
  • ✅ Phase ごとに区切らない、確認を挟まない
  • ✅ TodoWriteで全タスクを書き出し、上から消していく
  • 1個ずつ「次これでいいですか？」と聞かない

→ スピードが品質を上回る場面が多い。動くアウトプットを最速で出す。

3️⃣ 細部まで超高品質（No1を目指す）

「全部を細部までこだわり超高品質に。うちのシステムがNo1というところまで。」

観点 妥協しない
デザイン 配色・余白・整列・フォントサイズ
パフォーマンス カクツキゼロ・初回ロード3秒以内
📐 一貫性 全画面で同じデザインルール
細部 エラーメッセージ・空状態・ローディング表示
📱 レスポンシブ モバイル・タブレット・PC全て美しい
アクセシビリティ コントラスト比・キーボード操作

「とりあえず動く」では足りない。
競合に勝つレベルの完成度を初期アウトプットで出す。

4️⃣ UI/UX に拘る（使われないシステムは無価値）

「使い勝手悪いシステムは内容よくても使われない。」

守るべきこと 具体策
即動作 クリック → 反応 < 100ms
意図伝達 アイコン + ラベルで誰でも分かる
🛤 動線設計 主要操作は2クリック以内
視覚階層 重要度を色・サイズ・位置で表現
状態表示 選択中・進行中・完了が一目で分かる
⌨️ キーボード 主要操作にショートカット
コピー導線 コピーすべき情報には必ずコピーボタン

→ 「使う人が 3秒で何ができるか分かる」が合格ライン。

5️⃣ 更新履歴・バックアップ徹底（やり直し撲滅）

「やり直しが一番だるい。」

必須 内容
更新履歴 1行修正でも changelog / updates.js に追記必須
💾 バックアップ 編集前後 (pre-deploy / post-deploy) に tar.gz
タグ付け バックアップファイル名に変更内容のタグ
復元可能性 いつでも過去状態に戻せる体制
関数保護 大型ファイル編集時は関数チェック必須

→ 詳細は 2-2. バックアップ 2-3. changelog 2-4. 関数保護 参照

6️⃣ 「業務に組み込まれて初めて完成」

作っただけ ≠ 完成。日々の業務で使われて初めて完成。

  • ✅ 開発時に 「誰がいつ何のために使うか」 を明確化
  • ✅ Slack通知 / 既存ツール連携 / カレンダー埋込 等で 業務フローに組み込む
  • ✅ 使われていない機能は 削除候補（追加より削除を恐れない）
  • 「機能だけ作って後は使う人が頑張る」は失敗パターン

7️⃣ 数値主義（全機能にKPIを紐付ける）

「数字で語れない機能は、無価値。」

  • ✅ 全機能に KPI を設計（CTR / CV率 / 滞在時間 / 離脱率 等）
  • ✅ ダッシュボードに数値が 常時可視化
  • ✅ 異常値（前週比 ±20% 等）で 自動アラート
  • ✅ レポートは PDF出力 + コピー対応

8️⃣ 統合前提（22プロダクト連動）

単独システムは作らない。SCALE全体の中の1ピース。

  • ✅ 既存システム（Lead / Base / PM Dash / FS Dash）との データ共有 を前提
  • ✅ ログイン認証は 共通基盤（DEFAULT_MEMBERS）
  • ✅ 部署横断の通知は Slack ハブ
  • ✅ ナレッジは SCALE-Brain Vault に蓄積

9️⃣ モバイル/PC 両対応（必須）

「移動中・出先でも操作できる」が当たり前の時代。

  • ✅ レスポンシブ設計（ブレークポイント: 768 / 1024px）
  • ✅ タッチエリア最小 44x44px
  • ✅ ハンバーガーメニュー / タブ切替
  • ✅ オフライン対応（重要データはローカルキャッシュ）
  • 「PCでしか使えません」は時代遅れ

🔟 AI共創を前提とする

AIが提案 → 人が判断 → 実行。これがSCALEの開発思想。

  • ✅ 入力フォームに AI自動補完
  • ✅ レポート / 議事録は AI自動生成 → 人レビュー
  • ✅ AIに 3案出させて選ばせる UI
  • ✅ Claude API / MCP 連携

1️⃣1️⃣ SCALEらしさ統一（ブランディング）

どのシステムを開いても "SCALEだ" と分かる一貫性。

  • ✅ ロゴ・カラー・フォント・余白の 共通基準
  • ✅ ヘッダー / フッターの 共通テンプレ
  • ✅ ボタンスタイル・通知トースト・モーダルの 共通コンポーネント
  • ✅ メッセージトーン（敬語・温かみ）の統一

1️⃣2️⃣ ドキュメントは即書く（知識を残す）

「動くけどドキュメントない」は資産にならない。

  • ✅ 実装した機能は 使い方ガイド を即作成
  • ✅ システム別の CLAUDE.md に開発ルール明記
  • ✅ Vault（SCALE-Brain）に ナレッジを蓄積
  • ✅ 過去FBは 本ドキュメントに反映（このページ）

1️⃣3️⃣ 競合を超える初期完成度

「とりあえず動く MVP」では、業界No.1にはなれない。

  • ✅ 同カテゴリの競合を 3社以上調査 してから実装
  • ✅ 競合の弱点を 意図的に潰す 機能を入れる
  • ✅ 初期から マネタイズできる品質 を目指す
  • ✅ デモで他社経営者に見せて 「これいいね」 と言わせる完成度

1️⃣4️⃣ 失敗したら即修正・即デプロイ

バグ放置は信頼を失う最短ルート。

  • ✅ ユーザーから不具合報告が来たら その場で修正 → 即デプロイ
  • ✅ 「次回のリリースで」は禁句
  • ✅ デプロイ後に新たなバグ発覚 → 3分以内に切り戻し or 修正再デプロイ

1️⃣5️⃣ 「自分が使いたくなる」基準

大串自身が使ってテンションが上がるか？が最終判断軸。

  • ✅ 自分で触って楽しいか
  • ✅ 朝開いて「お、進んでる」と感じるか
  • ✅ 数字を見て次のアクションが浮かぶか
  • 義務感で開く画面は失敗

これらの原則が SCALE システム開発の DNA
迷ったら原則に立ち返る。気付きがあれば原則を増やしていく（このページに追記）。

1. 大串が求めるシステムの傾向（最重要）

1-1. 全体傾向

「使う人が即理解できて、即動ける」システム

傾向 具体
即効性 クリック・ロード・反映が遅いと使われない
自動化 手動の二重入力・KPI自動計算は標準
視認性 色・ステータス・件数が一目で分かる
数値主義 全機能にKPIが紐づく、レポート自動化
AI共創 AIが全部やる ≠ AIと人で共創（後述）
📱 柔軟性 タブ・カンバン・モーダル等の複数ビュー切替

1-2. UI/UX の傾向

観点 大串の好み
配色 カラフル過ぎない。強調色は1〜2点まで
📐 余白 詰め込み過ぎない。情報密度より読みやすさ
タグ・色 フィルタ選択中・状態は 明確に色付け
アイコン 意味のあるemoji・symbolで階層を直感化
コントラスト ダークモード対応、視認性最優先
動作 カクツキ・ガタつき 絶対NG（致命傷扱い）

1-3. 機能の傾向

必ず搭載されるべき "標準機能"

  • レポート完全自動化（全体 / 月別 / 担当者別 / 日別 / 週別）
  • 議事録自動生成（FMT選択：内部用 / クライアント用）
  • AI共創モード（AIが提案 → 人が意思決定）
  • Slack自動通知（成果・異常・期限）
  • データ連動（一度入れたら全画面で反映）
  • NGリスト連動（重複アプローチ防止）
  • PDF出力 / コピーボタン（社外共有想定）
  • 個人ダッシュボード（メンバー別の自分専用ビュー）
  • 権限管理（PM限定機能 / メンバー限定 等）

2. 必須ルール（絶対遵守）

2-1. デプロイ

コード変更後は必ずデプロイ。確認不要・即実行。

システム デプロイ先 / コマンド
SCALE CRM cd hp && npx wrangler pages deploy . --project-name="scale-hp" --commit-dirty=true → https://crm.scale-group.co.jp/base/
SCALE Base cd scale-base && npx wrangler pages deploy . --project-name=scale-base --commit-dirty=true → https://scale-base.pages.dev/home/
scale-morning cd scale-morning && npx wrangler pages deploy . --project-name=scale-morning --commit-dirty=true

ハッシュ付きデプロイURLは送らない
NG: https://787eb488.scale-base.pages.dev
OK: https://scale-base.pages.dev/home/（ブックマーク可能な本番エイリアス）

2-2. バックアップ（SCALE CRM 特化）

hp/base/ を1行でも触ったら必ず pre/post 両方バックアップ

# pre-deploy
cd "株式会社SCALE/hp"
TS=$(date +%Y-%m-%d_%H%M%S)
tar czf "../../scale-lead-backups/scale-lead_${TS}_pre-deploy.tar.gz" base/

# (コード変更)

# post-deploy（タグ付き）
TS=$(date +%Y-%m-%d_%H%M%S)
tar czf "../../scale-lead-backups/scale-lead_${TS}_post-deploy__<タグ>.tar.gz" base/

タグは変更内容を表す短い単語（例: eye-toggle, update-log, fix-login）

2-3. changelog 更新（必須・漏れ厳禁）

typo修正・CSSちょい直しでも追記対象。省略判断はしない。

システム 更新先
SCALE CRM hp/base/lib/updates.js の SYSTEM_UPDATES 最上段に unshift
SCALE Base lib/changelog.ts の CHANGELOG 最上段にエントリ追加

SCALE CRM 必須フィールド:
- date: 'YYYY-MM-DD HH:MM'
- category: feature / ui / bugfix / improve / security
- title: 短い見出し（20-30字）
- detail: 2-3文で何を・どう・なぜ
- jumpTo: ジャンプ先（page / logout / highlight / null）
- backup: 対応するpost-deployバックアップファイル名

SCALE Base 必須フィールド:
- id / date / time / title / category / scope / summary / details / files / snapshotTs / href / hrefLabel

複数修正をまとめてデプロイ時も、変更単位で1エントリずつ分ける

2-4. 関数保護（SCALE CRM 重大事故防止）

関数を消すと致命的なバグになる。デプロイ前必ずチェック。

過去事故: 8つの関数が消えてタブ切替が完全に壊れた → 2時間以上の損失

チェックスクリプト:

node -e "
const code=require('fs').readFileSync('/tmp/sc.js','utf8');
const fns=['_rerenderKeepScroll','koAutoH','koInitAutoH','autoCalcDailySilent','renderPartnerOnboard','renderManualPage','renderKnowledgeHub','renderService','renderDashboard','navigateTo','renderSidebar','doLogin','showApp','getSectionPerm','_checkSlackOnStatusChange','slackNotifyApo','slackNotifyLoss','slackPost','saveCallField','clInlineSave','renderCallList','filterCL','renderKickoff','renderContracts','renderOnboarding','khSaveSvcField','koSuriDragStart','koSuriDrop'];
var missing=[];
fns.forEach(fn=>{if(!code.includes('function '+fn))missing.push(fn)});
if(missing.length){console.log('MISSING:',missing.join(', '));process.exit(1)}
else console.log('ALL OK');
"

MISSINGが1つでもあればデプロイ禁止。復旧してから再チェック。

Edit時の鉄則:
1. 置換対象を 最小限 に（前後の関数を巻き込まない）
2. 大量修正は 1つずつ確認 しながら進める
3. lib/ 追加JSの関数を core.js から参照する時は typeof ガード必須:
- NG: updates: renderUpdates
- OK: updates: (typeof renderUpdates==='function' ? renderUpdates : null)

2-5. ファイル管理ポリシー

AI生成システム系は触らない

触らない 触っていい
scale-base/, scale-finance/, scale-hp-showcase/, scale-recruit/, scale-seo/, scale-lead/, hp/, x-auto-app/, gemini-image-tool/, linkedin-auto-tool/ 等のプロジェクトディレクトリ 手動編集の xlsx, pdf, docx, pptx, md, tsv 等

整理時のルール:
1. 削除前に 「削除候補」リスト提示 → 承認待ち
2. rm -rf 禁止 → mv ~/.Trash に置く（復元可能）
3. ~/株式会社SCALE 配下のscale-leadやhpも本番稼働なので触らない

3. UI/UX 設計原則

3-1. 視覚デザイン

「カラフル過ぎない × 余白しっかり」が大串の好み

観点 NG OK
配色 全要素に派手な色 強調1〜2点・残りは落ち着いた色
📐 余白 詰め込み セクション間に明確な区切り
トーン 蛍光色多用 ダークモード親和の落ち着いたトーン
グラフ 全色塗り データの主役だけ強調

参考: 📐 Vault_デザイン規則 のカラーパレット

3-2. 操作性

カクツキ・ガタつきは "致命傷"

  • タブ切替の遅延
  • チェック操作の再描画ガタつき
  • フォーム入力中のフォーカス飛び
  • プルダウンが意図せず閉じる

→ Realtime同期・差分レンダリング・スクロール位置保持 で対応

3-3. 情報設計

設計 内容
🪟 複数ビュー切替 テーブル / カンバン / モーダル / カレンダー
詳細モーダル 企業名クリック → 4タブ（概要/議事録/録画/AI分析）
セグメント詳細 業種 × 売上 × 従業員 等の組み合わせ表示
フィルタ選択中の色付け 状態が一目で分かる
5️⃣ 5段階評価 D / C / B / A / S（数値テーブルと連動）

4. 機能設計の標準

4-1. 必須レポート機能

graph TB
    DATA[元データ] --> AGG[自動集計]
    AGG --> R1[全体]
    AGG --> R2[月別]
    AGG --> R3[担当者別]
    AGG --> R4[日別]
    AGG --> R5[週別]

    R1 --> PDF[ PDF出力]
    R5 --> COPY[ コピー]

    style PDF fill:#fce4ec
  • グラフ + 表 で視覚的に
  • PDF出力 + コピーボタン 必須
  • 担当者フィルタ は他画面と連動

4-2. AI共創モード（大串の重要思想）

AIが全部作る ≠ AIと人で1時間共創して埋める

graph TB
    USER[ 人] -->|意思決定| DECIDE[判断]
    AI[ AI] -->|提案| DECIDE
    DECIDE --> OUTPUT[ 共創成果]

    style OUTPUT fill:#fce4ec

実装ポイント:
- AIが選択肢を 3案提示
- 人が選ぶ・修正する
- 案件の商材に応じて項目が 動的に追加 される
- 履歴を残し、次回の提案精度を上げる

4-3. Slack 自動連携

必須通知タイプ

トリガー 通知
✅ 成果（アポ獲得 / 受注） 即時通知
失注 即時通知
資料送付 送付報告 + 再架電前日リマインド
日次バッチ 全案件の稼働日報
異常検知 アポ率低下・リスト枯渇等のアラート

実装ルール:
- Bot Token 経由（MCP直接使用禁止）
- 各エージェント専用の アイコン・表示名
- タイトルに 種別・対象・日付 明記
- スレッド末尾にメンション

4-4. データ連動・自動反映

  • 二重入力ゼロ（一度入れたら全画面で反映）
  • KPI自動計算（架電→接続→アポ→受注のファネル）
  • NGリスト連動 — 該当企業を 赤色表示
  • アポ済企業の色分け — 二重アプローチ防止
  • テンプレート変数自動置換 — {{企業名}} → 実値

5. 業務プロセス標準フロー

5-1. 受注前 → 受注後 → 運用 のバトン

graph TB
    LEAD[ リード] --> APPO[✅ アポ]
    APPO --> FS[ FS商談]
    FS --> CONTRACT[ 契約]
    CONTRACT --> PM[ PM運用]
    PM --> RENEW[ 継続更新]

    style RENEW fill:#c8e6c9
フェーズ システム
リード〜アポ SCALE CRM
商談〜契約 FSダッシュボード
受注後品質管理 PMダッシュボード
全業務統合 SCALE Base

6. 改修時の標準フロー（5ステップ）

1. pre-deploy バックアップ（SCALE CRM）
   ↓
2. コード変更（関数保護に注意）
   ↓
3. changelog 追記（updates.js / changelog.ts）
   ↓
4. デプロイ（本番URL確認）
   ↓
5. post-deploy バックアップ（タグ付き）

確認後にユーザーに送るもの:
- ✅ 本番URL（ハッシュなし）
- ✅ 変更内容のサマリ
- ブラウザを勝手に開かない（スクショ自動取得禁止）
- file:// リンクで送らない（システム系は本番URL）

7. 文章・通知・対人標準

7-1. 文章添削の基準（Writing 添削プロンプト）

5つの基準

  1. ✅ 綺麗な日本語
  2. ✅ 敬語の徹底（二重敬語などなし）
  3. ✅ ビジネスマンとして優秀さが出る文面
  4. ✅ 長ったらしくなく、簡潔に
  5. ✅ 人として信頼関係を損なわない

→ 3案を毎回出す（その中に必ず温かみ・関係構築型を入れる）

7-2. メール文面の姿勢

HackCamp 等 BtoB の対人ルール

  • 相手の 過去接点情報にこちらが触れない
  • 「待ってほしい」と言われたら完全に待つ（攻めない）
  • 既存顧客には 営業禁止・サポート型のみ
  • 署名ブロックは書かない（自動付与）
  • 件名はコードブロック外に別出し

7-3. Slack 投稿フォーマット

タイトル: 【提出】<種別> <対象> <件数>（YYYY-MM-DD）
本文:
- 報告内容（具体的に・曖昧表現NG）
- 確認URL（本番）
- 改修内容のサマリ

スレッド末尾:
- 大串 <@U08N2PK3YCQ>
- 細川 <@U091VN5GBRP>（マーケ部の場合）
- ※デザイン秘書室の場合は @大串 のみ（はる退職に伴う暫定対応）

司令名義で送る（社長メンション必須）

8. システム別 固有ルール

8-1. SCALE CRM（hp/base/）

項目 値
URL https://crm.scale-group.co.jp/base/
PW ●●●●●●（全員共通固定）
認証 core.js 883行付近の DEFAULT_MEMBERS
💾 バックアップ scale-lead-backups/ (tar.gz、pre/post 両方)
changelog lib/updates.js の SYSTEM_UPDATES

ファイル分割:
- index.html（87行）
- style.css（251行）
- core.js（567行）— Supabase / 認証 / ナビ / ルーター / ダッシュ
- service.js（809行）— サービス概要
- kickoff.js（863行）— キックオフ / OB / ナレッジ / マニュアル
- calllist.js（491行）— 架電リスト
- pages.js（2063行）— その他全ページ
- ai.js（759行）— AIエンジン

8-2. SCALE Base（scale-base）

項目 値
URL https://scale-base.pages.dev/home/
場所 ~/.../scale-base/
☁️ インフラ Cloudflare Pages + KV + D1
changelog lib/changelog.ts の CHANGELOG
デバイス 1アカウント = 1デバイス前提（KV同期不要）

主要セクション:
- Tasks（KV API、ナビ確定済）
- CRM / SEO / Marketing / X / Calendar
- Writing（Claude API予定）
- Finance（15ページ、Supabase準備済）
- Recruit（11セクション、Supabase準備済）
- Docs（Notion管轄）

9. NGリスト（過去のミス・繰り返さない）

絶対繰り返してはいけない事故

過去ミス 教訓
関数8つ消失 → タブ全壊 デプロイ前 関数チェック必須
旧版と最新版入れ替わり バックアップ必須・タグ付け
ハッシュ付きデプロイURL送付 本番エイリアスのみ送る
ブラウザ自動オープン 完成リンクのみ送る
MCP Slack 直送信 → アイコン社長 Bot Token経由必須
AI生成システム系を整理 触らない・確認必須
changelog 更新漏れ typoでも追記必須

9-2. 完了時のVault反映確認（必須）

システム改修・実装が完了したら、必ずユーザーに確認

✅ <システム名> の改修が完了しました。

このシステムの概要・変更内容をVaultにまとめますか？

保存先候補:
- /Users/oogushiyuuki/Obsidian/SCALE-Brain/31_システム開発部/<システム>/_README.md
- /Users/oogushiyuuki/Obsidian/SCALE-Brain/31_システム開発部/_SCALE_システム開発書.md
- /Users/oogushiyuuki/Obsidian/SCALE-Brain/10_Daily/<今日>.md

→ 「保存して」or「ここに保存」or「いらない」で指示ください。

確認すべきタイミング:
- 大規模改修が完了した時
- 新機能を実装した時
- 過去FBが新しく出た時（→ システム開発書に追記）
- 仕様変更があった時

詳細: Vault更新確認フロー

✅ 10. 開発依頼チェックリスト

依頼を受けたら必ず上から確認

  • [ ] このページを読んだ
  • [ ] 該当システムの _README を読んだ（SCALE CRM / Base / PM / FS）
  • [ ] 該当システムのCLAUDE.mdがあれば読んだ
  • [ ] 過去FBに該当案件のメモリーがあるか確認した
  • [ ] 必要バックアップを取得した（特にSCALE CRM）
  • [ ] 大串の傾向（カラフル過ぎない・余白しっかり）を意識した
  • [ ] AI共創モード（必要なら）を組み込んだ
  • [ ] レポート機能（自動化）を含めた
  • [ ] Slack連携（必要なら）を含めた
  • [ ] PDF出力 / コピー（必要なら）を含めた
  • [ ] フィルタ選択中の色付けを設計した
  • [ ] カクツキが発生しないように差分レンダリングを設計した
  • [ ] 関数保護のチェックを通した（SCALE CRM）
  • [ ] changelog に追記した
  • [ ] 本番URL（ハッシュなし）で確認 → ユーザーに送る

関連ドキュメント

必読

システム別

全プロダクト

11. このドキュメントの更新ルール

新しいFBが出るたびに必ず更新

更新タイミング:
- 大串から新しい指摘・要望が出た
- 過去事故の再発防止策が決まった
- 新システムの固有ルールが確定した
- 共通パターンが見えてきた

更新者: Claude Code + 大串確認

更新方法:
1. 該当セクションに追記 / 修正
2. updated: を当日に変更
3. git commit & rsync で同期

このドキュメントが育てば育つほど、初期アウトプットが完成形に近づく。
SCALEシステム開発の 集合知 がここに集約される。