# 濱風 × 澤田 — 構築の進め方を決める（2026-08）

> **加藤さんへ。このファイルは、そのまま Claude Code に読ませてください。**
> ターミナルで濱風のリポジトリを開いて、こう打つだけです:
>
> ```
> このファイルを読んで、書かれているとおりに進めてください: 19-build-decisions-kit.md
> ```
>
> **決めていただきたいのは4つ**です。所要 10〜15分。
> 迷うものは「保留」で構いません。**保留の理由だけ記録します。**
>
> 人が読む資料は共有ページの「**構築の進め方**」にあります。先にそちらを見ていただくと決めやすいですが、
> **このファイルだけでも判断できるよう、要点は下に再掲**しています。

---

## AI への指示（ここから下は AI が読みます）

あなたは濱風商事の業務支援として、加藤さんに**構築方針の決定**をお願いします。
これは意見を聞くのではなく、**決めたことを記録する**作業です。

### 進め方

1. **1問ずつ聞く。** まとめて4問出さない
2. 各問の前に、下記の「**判断の材料**」を**そのまま読み上げる**（要約しない。判断に必要な情報です）
3. 選択肢を提示し、選んでもらう。**「保留」も正式な選択肢**です
4. 保留の場合は「**いつ・何が分かれば決められるか**」を聞いて記録する
5. 専門用語を使わない。使うときは括弧で言い換える
6. 全問終わったら、下記の書式で**既存ファイルへ追記**する

### 保存先 — 既存ファイルへの追記

`wiki_system/wiki/operations/kickoff-hearing-2026-08.md`

> ⚠ **既存の内容は消さないでください。** ファイル末尾に `## 構築方針の決定（2026-08-05）` の節を足します。
> frontmatter の `last_synced` を更新してください。**新しいファイルは作らないでください。**

追記する書式:

```markdown
## 構築方針の決定（2026-08-05）

| # | 決めること | 決定 | 保留の場合：いつ・何が分かれば決められるか |
|---|---|---|---|
| D1 | 進め方の案 | ... | — |
| D2 | アカウントの名義 | ... | — |
| D3 | 記録・安全・検収を誰が見るか | ... | — |
| D4 | 平日日中の一次対応 | ... | — |

### この決定が設計に与える影響
（AI が記入。「この決定により、次に何ができるようになったか／何が止まるか」を1行ずつ）
```

---

## 決めていただきたいこと

### D1. 進め方は3案のどれにしますか

**判断の材料（そのまま読み上げてください）**

> 需要エンジンを「作る」といっても、①要件定義 ②設計 ③画面の実装 ④記録・計測の実装 ⑤安全まわり ⑥テストと引き継ぎ ⑦保守、の7段階があります。
> 澤田は非エンジニアで、AIを使えば動くものは作れますが、**障害のときに原因を切り分けられる保証はありません**。
> 特に危ないのは ④⑤⑥ です。**画面が壊れたらすぐ分かりますが、記録が壊れても画面は正常に見えます**。送ったのに届いていないものを「反応なし」と数えたり、ボタンは押されたのに保存に失敗していたり——**気づかないまま、その数字で判断してしまう**のが一番怖い形です。

| 案 | 外に払うお金 | 速さ | 危なさ |
|---|---|---|---|
| **A：全部内製** | **0円**（澤田の稼働のみ） | 最も速い | **高い**（間違いを止める人がいない） |
| **B：安全まわりだけ外に出す** | **50〜200万円** | 中 | 中（事故になる部分は第三者が見る） |
| **C：実装ごと外に出す** | **164〜672万円** | 最も遅い | 低い |

> **金額は日本の受託開発の相場からの推定**で、実際の見積もりではありません。発注前に複数社からお取りください。
> なお C は、御社の現金（約300万円）に対して最安でも55%、完全版なら89%になります。**買取が主軸なら、システムより先に仕入れの運転資金が要ります**。

**さらに、段階を分ければ費用は下がります。**

> ①薄いパイロット（外に出すのは秘密情報の管理だけ・10〜30万円）→ **適格な対話3件が出たら** → ②記録を足す（記録の検証を外に・20〜50万円）→ **1件が商談まで通ったら** → ③案件管理まで
> **反応が出なければ①で止められる**ので、損失は最小です。

**選択肢**：`A 全部内製` / `B 安全まわりだけ外に` / `C 実装ごと外に` / `まず薄いパイロットだけ（段階分け）` / `保留`

---

### D2. GitHub・Vercel・Supabase のアカウントは、誰の名義にしますか

**判断の材料（そのまま読み上げてください）**

> 現在、濱風さんは**会社用の GitHub の入れ物（Organization）をお持ちではありません**。既存のリポジトリは共同代表の個人アカウントの下にあります。
> 「テスト版のうちは個人名義で、本番になったら移す」という進め方は、**実は高くつきます**。移すときに、やりとりの履歴・Vercel と Supabase の連携・パスワードやAPIキーの設定・自動デプロイの設定が失われ、入れ直しになるためです。
> そして一番の理由は、**「テスト版」と「本番」の境目が曖昧になること**です。動き始めると止められず、気づいたら個人名義のまま本番で使っている、が普通に起きます。
> **会社用の入れ物を作るのは無料**です。澤田は招待ユーザーとして入り、契約が終われば招待を外すだけで引き継ぎが済みます。

**選択肢**：`会社名義の入れ物を作る（新しいものから）` / `既存の個人アカウントのまま` / `保留`

> ※ **既存の `Hamakaze_admin` は今すぐ移す必要はありません。** 動いているものを触るリスクの方が大きいので、**新しく作るものから**で十分だと澤田は考えています。

---

### D3. 記録まわり・安全まわり・検収を、誰が見ますか

**判断の材料（そのまま読み上げてください）**

> 澤田が要件を決め、コードを書き、自分で「できた」と判断すると、**間違いを止める人がいません**。
> 特に「記録が正しく取れているか」は、**画面を見るだけでは確認できません**。
> また、パスワードやAPIキーの扱い、誰がどのデータを見られるかの設定は、**事故が起きてから気づく**種類のものです。

| 誰が見るか | 費用の目安 | 備考 |
|---|---|---|
| **外部の技術者に見てもらう** | 20〜80万円 | 記録の検証＋安全まわり＋検収 |
| **加藤さんが見る** | 0円 | ただし専門外の判断が要る場面があります |
| **AIに反対意見を言わせて、澤田が判断** | 0円 | 澤田が実際に使っている方法。**ただし最終判断は澤田1人**になります |
| **見ない** | 0円 | 間違いに気づけません |

> 澤田からのお願いがもう1つあります。**本番で使い始める前に、エンジニアでない方2名で「壊れたときに戻せるか」を1回試させてください**。これが通らないなら、まだ渡せる状態ではないという意味です。

**選択肢**：`外部の技術者に依頼` / `加藤さんが見る` / `AIレビュー＋澤田の判断でよい` / `保留`

---

### D4. 平日の日中に止まったとき、誰が最初に対応しますか

**判断の材料（そのまま読み上げてください）**

> 澤田は平日の日中に即応できません（本業があるため）。
> 資料にも「平日日中の障害対応は澤田に割り当てない」と書かれていますが、**実際には作った本人が最初に呼ばれます**。
> 一番避けたいのは「**止まったまま、誰も気づかない**」状態です。お客さまがカタログを開けない状態が半日続くと、その分の反応が丸ごと失われます。

**決めたいこと**：①**誰が最初に気づくか**（監視するか、気づいた人が言うか） ②**誰が一次対応するか**（澤田に連絡する役） ③**どこまで澤田が対応するか**（不具合だけか、使い方の質問も含むか）

**選択肢**：`加藤さんが一次対応` / `佐瀬さんが一次対応` / `松岡さんが一次対応` / `止まっても急がない（半日〜1日は許容）` / `保留`

---

## 全問終わったあとに、AI がやること

1. 上の書式で **既存ファイルの末尾へ追記**する（新規ファイルを作らない・既存を消さない）
2. frontmatter の `last_synced` を更新する
3. **この決定が設計に与える影響**を1行ずつ書く（「D2 が会社名義 → 新しいリポジトリを会社の入れ物に作れる」のように）
4. **保留になったものについては、「いつ・何が分かれば決められるか」を必ず記録**する
5. 加藤さんに「保存しました。澤田さんへは Discord でこのファイルのパスを伝えてください」と案内する

---

## この文書について（引き渡しの約束）

| 項目 | 内容 |
|---|---|
| **どこから読むか** | 冒頭（加藤さん向けの3行）から |
| **変えてよいもの** | 選択肢の粒度、聞く順番 |
| **変えてはいけないもの** | ①**1問ずつ聞く** ②**「判断の材料」を要約せずそのまま読み上げる**（判断に必要な情報です） ③**「保留」を正式な選択肢として扱う** ④**既存ファイルへ追記し、新規ファイルを作らない** |
| **どこまで通れば完了か** | D1〜D4 に「決定」または「保留＋再検討の条件」が入ること。**全部決めることは完了条件ではありません** |
| **失敗したとき何を残すか** | 途中で止まっても、そこまでを追記してから終わること |
| **責任範囲外** | 費用の実際の見積もり取得、契約の締結、法的な判断 |

---

## 澤田側の記録（加藤さんは読まなくて大丈夫です）

- 出所: `18-構築の進め方-先に決めること.md`（人が読む版・共有ページに掲載）の §5「先に決めておきたい3つ」＋ §3「3つの案」
- **人が読む版とAI実行版を分けた理由**: 加藤さんはページを直接見るが、**回答は Claude Code 経由で repo に保存される**運用になっている。回答が repo に残れば `gh api` で取りに行ける（09・13 で実証済み）
- **金額はすべて外注相場からの推定**。澤田の報酬とは無関係の文脈で置いている
- D3 の選択肢に「AIレビュー＋澤田の判断」を残したのは、**現実的にそれで進む可能性が高い**ため。ただし「最終判断は澤田1人になる」というリスクを明記した
- **未確認**: 「構築」がどこまでを指すか（自分でコードを書くのか、外注を管理するのか）は先方と未合意。D1 の回答で実質的に決まる