アイデアから出荷まで: 技術創設者がクロード コードと完全なコンテキストを使用して構築する方法

オペレーター

4 つのクライアント プロジェクトと契約しながら 2 つの SaaS 製品を構築している技術的な創業者は、ソフトウェア操作と同じくらいコンテキスト切り替え操作を実行しています。各製品には独自のロードマップ、バックログ、および関係者との一連の会話があります。各クライアント プロジェクトには独自のリポジトリ、Slack または電子メールでの独自のコミュニケーション スレッド、および何がいつ構築されるかについての独自の期待があります。創設者はエンジニアリング チームであり、アカウント マネージャーでもあります。つまり、コンテキストを切り替えるたびに実際のオーバーヘッドが発生します。つまり、コードを 1 行書く前に適切なメンタル モデルに引き戻さなければなりません。

ソフトウェアを適切に構築するためのツールはすでに存在しています。Claude Code は、数年前であれば小規模なチームが必要だったレベルで実装、テスト、反復を処理します。ギャップは仕事をしている脳にあるのではありません。それは脳が開始時に知っていることの中にあります。すべての作業セッションは同じ質問から始まります。何を構築していたのか、どこで中断したのか、前回のセッション以降に関係者との会話で何が変わったのか、いつリリースされるのかを誰が知る必要があるのか​​などです。

限界点

オーバーヘッドは小さな形で蓄積されますが、合計されるまでは構造的な問題とは感じられません。創設者は、ほとんどのセッションの最初の 30 分を、Slack スレッドと電子メールを読み返して、2 日前に最後に明確に保持されていた仕様コンテキストを再構築します。彼らが先週出荷した機能により、利害関係者の質問が生じましたが、まだ答えられていません。これは、見逃したからではなく、間違ったタブに到着したためです。電子メールで合意されたクライアント プロジェクトのマイルストーンは、立ち止まって記録する時間がなかったため、どのタスクにもタイムラインにも反映されていません。

さらに深刻な問題は、クロード コードが強力であるにもかかわらず、各セッションが何も知らずに開始されることです。創設者がコンテキスト (仕様、関連スレッド、コードベースの問題の現在の状態) を貼り付けると、セッションが生産的になります。ただし、貼り付けの手順は手動で行われ、損失が発生し、完全に完了することはありません。モデルは、受信したどのようなコンテキストでも見事に推論します。制約は、そのコンテキストを組み立てるには、実際の作業が始まる前に人間の時間と人間の判断が必要であるということです。

何かが出荷されると、通信ステップは優先順位スタックの一番下に落ちます。この機能は完了しました。適切な人に伝えることは摩擦を生みます。成果物を待っていた関係者が数日後にそのことに気づくのは、創設者が成果物を忘れたからではなく、完了したタスクを送信通知に変えるシステムがなかったからです。

セットアップ

技術的な創設者は、クライアントの通信スレッドとして Gmail を接続し、仕様、設計ドキュメント、プロジェクトの概要のために Google ドライブを接続します。各製品と各クライアント エンゲージメントは、Lodestar 内に独自の組織とプロジェクトを持ちます。つまり、2 つの製品組織が独自のロードマップ プロジェクトを持ち、4 つのクライアント組織がそれぞれ配信プロジェクトを持ちます。 MCP サーバーは Claude Code に接続されているため、すべてのターミナル セッションでは、ブラウザ タブに切り替えることなく完全な操作画面に到達できます。

Lodestar は既存の電子メール スレッドとドライブ ドキュメントを取り込み、証拠を含むアクション アイテムの抽出を開始します。各アイテムは、引用元の正確な引用またはファイルにリンクされています。 1 日以内に、6 つのコンテキストすべてにわたる未解決のアイテムが 1 か所に表示され、プロジェクトごとに整理され、ソース資料に表示されている日付が推定されます。創設者はこれらを手動で入力していません。すでに存在する通信履歴から浮かび上がってきました。

ワークフロー

典型的な作業セッションは、クロード コードに対する自然言語のプロンプトから始まります。「その日の現在の状態は何ですか」というものです。その時点から、セッションは完全にエディター内で実行されます。タブの切り替え、手動によるコンテキストの組み立て、最後に個別の通信ステップは必要ありません。

• ·Sense — Claude Code は MCP 経由で「dashboard_today」を呼び出し、ランク付けされた毎日の画像を取得します。応答には、6 つのコンテキストにわたって 3 つの期限付きアクション項目が示されています。1 つは製品リリースのブロック、1 つはクライアントの成果物、1 つは待機中の利害関係者の応答です。
• ·センス — 創設者はこう言います: ブロッキングアイテムを実装してください。 Claude Code は、そのアイテムの ID に対して「action_items_retrieve」を呼び出して、完全な構造化レコード (アイテムの抽出元の仕様フラグメント、リンクされたドライブ ドキュメント、関係者が最後に意見を交わした電子メール スレッド、および関連するコードベース コンテキスト) を取得します。
• ·Sense — Claude Code は「knowledge_search」と「files_content」を呼び出して、現在の仕様とドライブに記録されている以前の設計上の決定を取得します。 `context_resume` を呼び出して、ステークホルダーのスレッドで最後に決定された内容を明らかにします。これらすべては、創設者がブラウザーのタブを 1 つも開くことなく、セッションに到達します。
• ·決定 — 完全なコンテキストが組み立てられた状態で、Claude Code は実装を計画します。つまり、何を、どの順序で構築し、どのようにテストするかです。創設者は計画をレビューし、アプローチを確認または調整し、実装セッションが始まります。
• ·Act — Claude Code はコードを作成し、テストを実行し、反復します。実装の準備ができたら、創設者は「出荷してループを終了」と言います。 Claude Code は `action_items_partial_update` を呼び出して項目が完了したことをマークし、次に `timeline_events_create` を呼び出してプロジェクトのタイムラインに対して完了を記録します。
• ·閉じる — クロード コードは `emails_reply_link` を呼び出して、スレッドからの元のリクエストを参照し、完了した正確な項目に基づいて利害関係者通知を草案します。ドラフトは創設者の作成ウィンドウで開きます。彼らはそれを確認し、送信をクリックします。 Claude Code は、完了によってプロジェクトのマイルストーンがトリガーされた場合、`milestones_partial_update` を呼び出してプロジェクトのマイルストーンを進めます。
• ·クライアントの成果物に対しても、コンテキストの取得、実装、クローズ、通知という同じパターンが繰り返されます。セッション全体 (コンテキストのアセンブリ、実装、ステータスの更新、関係者への通知) はエディター内に留まります。

何が変わるのか

貼り付けステップが消えます。クロード コードは、仕様、スレッド履歴、以前の決定、およびすでに範囲内にあるオープン コミットメントとともに各セッションに到着します。これは、Lodestar がそれらを構造化された形式で保持し、MCP がそれらをオンデマンドで表示するためです。実際の作業が始まる前の摩擦は、30 分の再構成作業から、数秒間のモデル検索まで続きます。

ステークホルダーとのコミュニケーションは、別個のタスクではなく、配送の副産物となります。アイテムが閉じると、通知ドラフトはメモリからではなく、実際の完了コンテキストから生成されます。創設者は最初から作成するのではなく、レビューして送信します。何かを出荷することと、それを知る適切な人との間のギャップは崩れます。

6 つのコンテキストにわたる運用状況は、手動メンテナンスなしで最新の状態に保たれます。アクション アイテムは通信スレッドから自動的に表示されます。証拠が到着するとマイルストーンが進みます。タイムラインは実際に起こったことを反映しており、ソフトウェアの構築に使用したクロード コードと同じソース資料から構築されています。