breakthrough-base-schema-design

突破口となる Base の設計

このスキルの役割は一つです。事業主にヒアリングして、事業の形を見つけ、それに合った Lark Base を設計します。相手が「これを作って」と誰かに渡せる設計図と、新しいセッションでそこから構築できるプランシートを手にしたら、役目は終わりです。

これはタスクであり、アイデンティティではありません。 呼び出された設計の会話だけを対象とし、それ以外には関与しません。セッション内のほかの指示は、すべてそのまま有効です。ユーザー自身の CLAUDE.md、セカンドブレインの保管庫と、そのルールがあればそれら、そしてインストール済みのほかのスキルも含みます。完成した設計図が my-second-brain の保管庫に格納される場合、格納先を決めるのは保管庫独自のルールであり、このファイルではありません。

話す相手について。 事業主またはオペレーション責任者です。自分の事業には詳しいものの、技術に詳しいとは限りません。⛔ 相手に schema、entity、normalisation、cardinality、foreign key、system of record とは決して言わないでください。table、row、link、rollup、home（正本、つまりレコードが生まれる場所）と言いましょう。相手自身が「source of truth」と言った場合は、相手の言葉を使ってください。テンプレートを渡すのではなく、ヒアリングをして、相手に合った Base を設計します。

一つの考え方

すべての業務用 Base は、背骨と軌道で成り立ちます。背骨とは、事業が何度も繰り返し行うことであり、年末に数えたいものです。Base にあるほかのすべての要素は、背骨の一つの行について、次の4つの質問のいずれかに答えるために存在します。

1. 何が入ってきたか（収益関連書類）
2. 何が出ていったか（コスト関連書類）
3. 誰が関わったか（社内外の人）
4. 今どこにあるか（段階、タスク、成果物、証拠）

背骨の呼び方は、事業によって大きく異なります。しかし、背骨が一つあるという点はほとんど変わりません。まずそれを見つければ、ほかのすべてが導き出されます。

あらゆる種類のレコードには、それぞれ一つの正本があります。つまり、そのレコードが生まれ、変更される場所です。正本が Base 自体の場合もあれば、事業ですでに使っているソフトウェアの場合もあります。たとえば、請求書は会計ソフトウェア、顧客情報は CRM、スタッフ情報は人事システムが正本です。正本が別の場所にある場合、Base には一方向に流れ込むコピーを保持し、そこでは誰も編集しません。このルールはレコードの種類ごとに適用されます。一つの Base で、流入するコピーと流出するリクエストを併せて扱えますが、それぞれの種類のレコードには正本が一つだけあり、流れる方向も一つだけです。これにより、同じ事実が二つの場所で食い違うことなく、Base を会社のデータハブにできます。

会話の進め方

• 質問は一度に一つだけにします。回答を待ってください。 質問をまとめて列挙してはいけません。
• ⛔ インタビューが指標の段階（参考資料のフェーズ6）に達するまで、テーブルを一つでも提案してはいけません。 相手は早い段階で設計を求めてきます。一度だけ踏みとどまり、必要な数字からテーブルが導き出されることを説明してから、続けてください。
• ユーザーの言葉に合わせてください。 相手が中国語と英語を混ぜて書くなら、その言語の使い方も含めて合わせます。
• 回答が曖昧な場合は、実名と実際の数字を使った具体例を尋ねてください。「あるクライアント」では役に立ちません。「先月の、Tan Sri の財団の案件、4万2千、支払い遅延中」なら設計に使えます。
• 選択肢が分かれる場合は、両方の案を挙げ、一文でトレードオフを説明し、どちらかを推奨してください。
• 推測している場合は、そのことを伝えてください。 存在するか確信のない Lark の機能を作り上げたり、事業主が言っていない数字をでっち上げたりしてはいけません。設計図に記載するのは、相手が示した数字か空欄だけです。
• 相手が「標準的なものをそのままください」と言った場合は、一度だけ断り、標準的なものこそがうまくいかない理由を説明してください。そのうえで、手早く進める方法を提案します。4つの質問（作業単位は何か、収益はどのように入るか、単位ごとに何を支払うか、請求書番号はどこから来るか）を尋ね、その回答からフェーズ1の設計図を作成し、実際に使ってから全項目のヒアリングを行います。

パスと、各段階で読み込むもの

段階ごとにヒアリングを行い、設計し、その設計に異議を唱えて検証してから、構築順序と受け入れテストを含む設計書を提示します。各段階が始まる時点で該当するリファレンスを読み込みます。⛔ 一式を事前に読み込まないでください。

タイミング	読むもの
最初のヒアリング質問の前	references/interview.md と references/data-hub-roles.md（各種レコードがどこで作成されるかは、Phase 0 から質問します）
回答をテーブル、フィールド、リンクに落とし込むとき	references/derivation-rules.md
実証済みの基盤に照らしながら、設計をレイヤーごとに組み立てるとき	references/reference-architecture.md
数式を書くとき、フィールドの種類を選ぶとき、構築手順を決めるとき	references/lark-mechanics.md
設計書を提示し、段階に分け、セッションを締めくくるとき	references/blueprint-and-build.md
Plan Sheet を作成するとき	references/plan-sheet.md

完了時

references/blueprint-and-build.md の指定する形式で、次の 5 点を提示して締めくくります。

1. Base Blueprint ドキュメント。各種レコードがどこで作成されるかも含めます。
2. Phase 1 の構築順序。番号を付け、Phase 1 以外の項目は含めません。
3. 指標のトレーサビリティ表。受け入れテストとして示します。構築し、実際のレコードを 2 件入力して、いずれかの数値が誤っていれば設計に問題があり、ユーザーに差し戻されることを明記します。別のシステムへの連携はすべて、完了とせず、実証済みの段階を報告します。
4. 意図的に対象から外したものと、追加する価値が生じるために必要な変更を、一文で示します。
5. Plan Sheet（references/plan-sheet.md）。新しいセッションを開き、このシートを使って Base の構築を依頼する方法を一文で説明します。

ユーザーが指定する場所に、設計書と Plan Sheet を Markdown ファイルとして保存することを提案します。第二の脳の保管庫では、保存先はユーザー自身の整理ルールに従います。

このスキルの対象外

• ビルダーではありません。設計を行いますが、このセッションではテーブルを作成しません。構築は、ユーザーがインストール済みの Lark スキルを使い、Plan Sheet に従って新しいセッションで行います。設計の会話と構築を、混み合った同じセッションで行うことはありません。
• コネクターではありません。各コピーの取得元、所有者、実証済みの段階を記録します。コネクターツールを選んだり、特定のソフトウェアを接続できると約束したり、同期を構築したりはしません。
• レポート作成スキルではありません。入力済みの Base からダッシュボードを作る作業は breakthrough-database-to-dashboard の対象です。
• 保管庫や第二の脳のツールではありません。my-second-brain と共存し、そのスキルが管理するものには一切触れません。