プロジェクト導入戦略¶

ツールを「入れる」ことと「定着させる」ことは別物です。ここでは、Salesforce 開発チームに余白フォース Suite を小さく始めて確実に広げるための段階的ステップと勘所をまとめます。

基本方針

一気に全部入れない。 価値が出る最小単位（core 単独）から始め、痛みが顕在化したら次の層を足す。各段階で「誰が・何を・どう使うか」を 1 つに絞る。

導入の 4 ステージ¶

flowchart LR
    S1[Stage 1<br/>core 単独] --> S2[Stage 2<br/>共有 context-hub]
    S2 --> S3[Stage 3<br/>ai-pm で進行管理]
    S3 --> S4[Stage 4<br/>チーム標準化]

最初の価値は core だけで出ます。サーバ不要・他製品に依存しません。

やること: 既存の Salesforce プロジェクトで yohaku init → graph build → render --format md,html。
得られる価値: 属人化していた仕様が、メタデータから決定的に設計書になる。レビューが速くなる。
共有: 生成した docs/generated/ を Git にコミットして PR でレビュー（戦略参照）。
撤退コスト: ほぼゼロ（CLI を消すだけ）。だから最初に試すのに最適。

成功の目安

「設計書を手で書く時間が減った」「レビューで仕様の認識ズレが減った」を 1〜2 案件で実感できたら次へ。

「あの案件の Slack のやり取り / Backlog のチケット、どこだっけ？」が増えてきたら context-hub。

やること: 社内の共有マシン 1 台（業務時間中起動で可・専用サーバ不要）に context-hub（production プロファイル）を立て、 Slack/Backlog/Redmine/Gmail を取り込む。チームは Tailscale/VPN で接続。
連結: core の .yohaku/config.json の contextProvider を共有 context-hub に向け、 設計を「共有された文脈」を踏まえて行えるようにする。
得られる価値: 顧客文脈が 1 か所に集約され、AI（Claude Code 等）が即座に参照できる。
データ境界: 顧客データはこのホストに留まる（戦略の層 B）。

朝会・日報・催促・総括などの定型的な進行管理の手間が見えてきたら ai-pm。

やること: 同じ共有ホストに ai-pm（Docker）を立て、context-hub に接続（CONTEXT_HUB_API_KEY = DEV_API_KEY）。まず LLM_PROVIDER=mock で疎通 → 実 LLM（サブスク/ローカル）へ。
進め方: いきなり全 7 能力を回さず、まず 1〜2 能力（例: 朝会と日報）から。通知は local_file で安全に開始。
得られる価値: 定型連絡が自動化され、人は判断と例外対応に集中できる。
ガバナンス: リーダー確認ゲート（final_analysis は人の確認で発火）で「AI が勝手に進めない」設計。

役割	主な担当
開発者	core で設計書生成、共有 context-hub を参照して実装、PR レビュー
テックリード	リポ構成・`.gitignore`・`contextProvider` の標準化、設計差分レビュー
PM / 進行管理	ai-pm の設定（時刻・通知先）、リーダー確認ゲートの運用
インフラ / 情シス	共有ホスト・VPN・バックアップ・鍵配布（共有金庫）

やりがちな失敗

Stage 1（core）Stage 2（context-hub）Stage 3（ai-pm）