クライアントアップセール提案

コードベースのエビデンスに基づいたアップセール提案は、意見に基づいたものより早くクローズします。Sun Agent Kitを使えば、既存プロジェクトに対して体系的な監査を実行し、調査結果をビジネス成果にマッピングし、業界ベンチマークで主張を検証し、洗練されたクライアント向けドキュメントを作成することができます — コードを1行も書かずに。かつてはシニアエンジニアとアカウントマネージャーが週の大半を費やしていた作業が、水曜日の午後には完了します。

概要

目標: 意見ではなくコードベースのエビデンスに基づいた体系的なアップセール提案を生成する
所要時間: 1〜2時間（手動での分析・執筆では4〜6時間）
使用エージェント: scout、researcher、doc-writer
コマンド: /sk:scout、/sk:brainstorm、/sk:research、/sk:plan、/sk:docs

注意: このワークフローではコードは一切書きません。すべてのコマンドは分析、調査、またはドキュメント作成を行います — コードベースは全体を通して読み取り専用です。

前提条件

Sun Agent Kitがインストール済みであること（インストールガイド）
クライアントのコードベースへのアクセス（ローカルクローンまたは読み取りアクセスで十分）
アップセールのトリガーが明確であること — 新しいクライアントリクエスト、サポートインシデント、更新期日の近づき
アカウントマネージャーのコンテキスト：クライアントが最も重視する成果は何か（パフォーマンス、モバイル、スケール）

ステップバイステップのワークフロー

ステップ1：エビデンスのためにコードベースを監査する

/sk:scout "audit this Laravel codebase for technical debt, missing test coverage, architectural bottlenecks, security gaps, and scalability risks — generate a structured findings report for a client proposal"

実行内容: エージェントが以下を実行します：

リポジトリを走査し、ソースファイル、設定、依存関係マニフェストをインデックス化します
テストカバレッジを計測し、欠落しているテストスイートを特定し、テストされていないクリティカルパスにフラグを立てます
アーキテクチャパターン — またはその欠如 — を検出します（サービスレイヤーの欠如、密結合、コントローラーからの直接データベース呼び出しなど）
既知のセキュリティ問題をスキャンします：露出した認証情報、古いパッケージ、入力バリデーションの欠如
重大度評価とエビデンス参照を含む体系的な調査結果レポートを plans/reports/scout-report.md に保存します

ステップ2：調査結果をビジネス価値にマッピングする

/sk:brainstorm "based on the scout findings: no tests, monolithic architecture, no API layer, and the client wants a mobile app — what are the 3-5 most compelling upsell scopes? Map each to both technical risk reduction and business value"

実行内容: エージェントが以下を実行します：

スカウトレポートを読み取り、最も重大度の高い調査結果を抽出します
各技術的調査結果をビジネスリスクの説明に変換します（例：「テストカバレッジなし → モバイルAPI抽出時に高いリグレッションリスク」）
調査結果を明確な価値提案を持つ一貫したエンゲージメントスコープにグループ化します
クライアントへの影響と納品実現可能性でスコープをランク付けします
技術的な根拠とビジネスフレーミングの両方を含む、優先度付きのアップセール観点リストを作成します

ステップ3：業界データで主張を検証する

/sk:research "ROI benchmarks: cost of adding test coverage to a 50k LOC Laravel project, typical timeline for API extraction from a PHP monolith, mobile app backend requirements for REST vs GraphQL"

実行内容: エージェントが以下を実行します：

提案されたスコープに関連する業界ベンチマーク、ケーススタディ、コミュニティデータを検索します
同等のエンゲージメントの工数見積もりとタイムライン範囲を検索します
PHP/Laravelプロジェクトにおけるテストインフラ投資のROIデータを探します
提案の主張を裏付けるソース参照付きの調査サマリーをまとめます
ベンチマークが少ない、または見積もりの分散が大きい領域にフラグを立てます

ステップ4：提案書の構成を設計する

/sk:plan "structure a 3-month upsell proposal: Section 1 current state findings with evidence, Section 2 three engagement scopes with effort estimates, Section 3 risk-if-no-action analysis, Section 4 pricing tiers (essential/recommended/comprehensive)"

実行内容: エージェントが以下を実行します：

スカウトレポート、ブレインストームの出力、調査サマリーをインプットとして読み取ります
エビデンスから始まり提案へと積み上がる提案構成を設計します
各セクションに含める内容を定義します — どの調査結果、どのスコープ、どのベンチマークか
価格帯モデルを指定します：各ティアに何が含まれ、どのように差別化するか
ドキュメント計画を plans/proposal-structure.md に保存し、doc-writerが実行できるようにします

ステップ5：クライアント向け提案書を執筆する

/sk:docs "write the upsell proposal document per the plan — formal client-facing tone, reference scout findings as supporting evidence, include executive summary at the top"

実行内容: エージェントが以下を実行します：

提案構成計画とすべての以前のエージェント出力をソース素材として読み取ります
非技術系の経営幹部を対象として、各セクションを正式なクライアント向け言語で記述します
抽象的な主張ではなくコードベース統計として、スカウトの調査結果を裏付けのエビデンスとして埋め込みます
スコープ、タイムライン、相対的な価格ガイダンスを含む3段階のエンゲージメントオプションを構築します
最終提案書を生成し、docs/client-proposal.md に保存します

完全な例：モバイルアプリのリクエストを3ヶ月エンゲージメントへ転換

シナリオ: クライアントのために2年前のLaravelモノリスをメンテナンスしています。コードベースはテストスイートなし、サービスレイヤーなし、Bladeコントローラーにすべてのビジネスロジックが存在する状態で約5万行まで成長しています。月曜日の電話で、クライアントがQ3までにモバイルアプリを欲しいと言及しました。アカウントマネージャーから週末までに提案書を作るよう依頼されています。

実行するコマンド:

# 1. コードベースを監査する — エビデンスは実際に何を示しているか？
/sk:scout "audit this Laravel codebase for technical debt, missing test coverage, architectural bottlenecks, security gaps, and scalability risks — generate a structured findings report for a client proposal"

# 2. アカウントマネージャーが売り込めるアップセール観点に調査結果をマッピングする
/sk:brainstorm "based on the scout findings: no tests, monolithic architecture, no API layer, and the client wants a mobile app — what are the 3-5 most compelling upsell scopes? Map each to both technical risk reduction and business value"

# 3. クライアントの前に出す前に工数見積もりとROIの主張を検証する
/sk:research "ROI benchmarks: cost of adding test coverage to a 50k LOC Laravel project, typical timeline for API extraction from a PHP monolith, mobile app backend requirements for REST vs GraphQL"

# 4. 文章を1語も書く前に提案構成を設計する
/sk:plan "structure a 3-month upsell proposal: Section 1 current state findings with evidence, Section 2 three engagement scopes with effort estimates, Section 3 risk-if-no-action analysis, Section 4 pricing tiers (essential/recommended/comprehensive)"

# 5. 最終的なクライアント向けドキュメントを執筆する
/sk:docs "write the upsell proposal document per the plan — formal client-facing tone, reference scout findings as supporting evidence, include executive summary at the top"

結果: 水曜日の午後には、コードベースのエビデンスと3段階のエンゲージメントオプション（テストインフラ、APIレイヤー抽出、モバイルアプリ開発）、調査に裏付けられたROI予測を含む10ページの提案書が完成します。アカウントマネージャーは金曜日のクライアントミーティングに、勘に頼った見積もりではなく、信頼性のあるものを持って臨めます。

時間比較

タスク	手動	Sun Agent Kit使用
コードベース監査 + 調査結果	2〜3時間	数分
アップセール観点の特定	1〜2時間	数分
市場調査 + ベンチマーク	1〜2時間	数分
提案構成 + 執筆	2〜3時間	数分
合計	4〜6時間	1〜2時間

ベストプラクティス

1. すべての提案の主張をスカウトの調査結果に基づかせる ✅

クライアントは意見よりエビデンスを信頼します。提案書に「コントローラークラス47個にわたってテストカバレッジがゼロです」と記載されている場合、「テストが必要だと思います」とは異なる印象を与えます。スカウトの調査結果があなたの信頼性の源です。

2. 段階的なスコープを提示する ✅

「必要最低限 / 推奨 / 包括的」という選択肢を提示することで、クライアントに二択を迫らずに済みます。単一の大きなスコープを拒否するクライアントも、範囲が示されると中間ティアを選ぶことがよくあります。

3. docsプロンプトに対象者とトーンを明示する ✅

"formal client-facing tone"（正式なクライアント向けトーン） は暗黙的に理解されません — すべての /sk:docs 呼び出しで明記してください。明記しない場合、doc-writerはデフォルトで技術的なレジスターを使用します。

4. 「何もしない場合のリスク」セクションを含める ✅

何もしないコストを数値化することは、行動することの利点を説明するよりも説得力があります。「今APIレイヤーを抽出するとXのコストがかかりますが、モバイルアプリ公開後に行うと3Xのコストがかかり、書き直しが必要になります」は、意思決定の具体的な理由となります。

5. スカウトの調査結果に根拠のない作業を提案する ❌

提案書がKubernetesへの移行を推奨しているのに、スカウトレポートにインフラのスケーリング問題が何も記載されていない場合、そのスコープには何のエビデンスもありません。クライアントとその技術アドバイザーは気づき、ドキュメント全体の信頼性を損ないます。

6. 調査をスキップする ❌

検証されていないROIの主張は主張がないよりも悪いです。工数見積もりをベンチマークや同等のケーススタディで裏付けられない場合は、削除するか、内部見積もりであることを明示的に示してください。

トラブルシューティング

問題：スカウトが多すぎる問題を発見し、提案がバグレポートのようになる

解決方法: 執筆前にブレインストームを使って優先順位をつけてください。ブレインストームプロンプトに制約を追加してください: "pick the 3 most business-critical findings — ignore anything that is cosmetic or low risk"。すべてを修正しようとする提案は何も承認されません。

問題：ドキュメントの出力が非技術系CTOには技術的すぎる

解決方法: 明示的な対象者の指示を付けて /sk:docs を再実行してください: "write for a non-technical CTO who understands business risk but not PHP internals — no code snippets, no framework-specific terminology"。

問題：計画が多すぎる提案セクションを生成する

解決方法: 構成を事前に制約してください: "maximum 4 sections, executive summary under 200 words, no appendices"。セクションが多くても提案が強くなるわけではありません — 承認が難しくなるだけです。

問題：調査でスタックに関連するベンチマークが見つからない

解決方法: 検索範囲を絞り込んでください: "Laravel-specific test coverage ROI case studies from teams between 5 and 20 engineers"。一般的なソフトウェアベンチマークよりもスタック固有のデータの方が信頼性が高く、存在しない場合は調査エージェントが明確にそう伝えます。

次のステップ

高速プロトタイピング — 提案が承認された場合、本格的な構築にコミットする前に新機能をプロトタイプ化する
プロジェクトマイグレーション — 提案にテクスタック移行が含まれる場合、このワークフローを使って計画・実行する
ドキュメント生成 — エンゲージメント開始後の引き継ぎドキュメントを生成する
セキュリティ監査とスキャン — 提案にセキュリティ修正のスコープが含まれる場合、最初の成果物として専用のセキュリティスキャンを実行する

要点: コードベース監査に基づいたアップセール提案は、意見に基づいたものより早くクローズします — /sk:scout がエビデンスを提供し、/sk:brainstorm がそれをビジネス価値にマッピングし、/sk:docs がクライアント向けの成果物に変換します。コードは書かれず、成立しないかもしれない提案にエンジニアリングの時間は無駄になりません。