diff --git a/MEMO.md b/MEMO.md
index 747c49a..e9ca1fe 100644
--- a/MEMO.md
+++ b/MEMO.md
@@ -170,4 +170,129 @@ Google スプレッドシートにエクスポート
 3. バグ修正
    1. 計画フェーズ
    2. 開発フェーズ
-   3. レビュー＆テスト・マージ
\ No newline at end of file
+   3. レビュー＆テスト・マージ
+
+
+# 新規開発ワークフロー 詳細設計書（再検討版）
+
+## 1. 計画フェーズ：思考を外部化し、道筋を立てる
+
+### 概要
+このフェーズの目的は、頭の中にある漠然としたアイデアを、誰が見ても理解できる具体的なタスク群に変換し、外部システム（GitHub）に完全に記録することです。これにより、「何をすべきか」を記憶しておく必要がなくなります。
+
+### 流れ
+
+1. **リポジトリの作成**: GitHub上で、この新規プロジェクトのためのリポジトリを1つ作成します。
+
+2. **ブランチ戦略の決定**:
+   - `main` ブランチ：常にリリース可能な、安定したコードを置く場所とします
+   - `develop` ブランチ：これから開発する機能や修正を統合していくための、中心的な開発用ブランチとします。mainブランチからこのdevelopブランチを作成します。
+
+3. **仕様書の作成**:
+   - リポジトリの README.md ファイルに、このプロジェクトが「何を」「なぜ」「誰のために」作るのか、という核心的な目的を書き出します。これがプロジェクトの憲法となり、モチベーションの源泉になります。
+
+4. **タスクの洗い出しと分解**:
+   - 仕様書を基に、プロジェクト完成に必要なタスクをすべて洗い出します。
+   - 「ユーザー認証機能」のような大きなタスクは、「ログイン画面UI作成」「APIエンドポイント設計」「DBテーブル作成」のように、数時間〜1日で完了できるレベルまで細かく分解します。これは着手のハードルを劇的に下げます。
+
+5. **全タスクのIssue化**:
+   - 分解したタスクを一つ残らず、GitHubのIssueとして作成します。
+   - 各Issueには、`feature`（機能追加）、`bug`（バグ）、`chore`（雑務）などのラベルを付け、整理します。
+   - 作成したIssueはすべてGitHub Projectsのカンバンボードに追加し、「Todo」カラムに配置します。
+
+## 2. 開発フェーズ：集中と柔軟性を両立させる
+
+### 概要
+計画フェーズで作成したIssue（指示書）に基づき、一つずつタスクをこなしていきます。ここではgit worktreeを最大限に活用し、集中を妨げることなく、興味の波に合わせた柔軟なタスク切り替えを実現します。
+
+### 流れ
+
+1. **Issueの選択**: GitHub Projectsのカンバンボードから、今日取り組むIssueを1つ選び、「進行中」カラムに移動させます。
+
+2. **作業場の準備 (git worktree)**:
+   - ターミナルでメインの作業フォルダ（developブランチがチェックアウトされている場所）にいることを確認します。
+   - 取り組むIssue（例: #11）のために、以下のコマンドで新しい作業場（フォルダ）とブランチを瞬時に作成します。
+   ```bash
+   # developブランチを基に、feature/11-login-ui という新しいブランチを作り、
+   # ../login-ui-work という新しいフォルダに展開する
+   git worktree add -b feature/11-login-ui ../login-ui-work develop
+   ```
+
+3. **開発に着手**:
+   - `cd ../login-ui-work` で新しい作業場に移動し、コーディングに集中します。元の作業フォルダのことは完全に忘れて大丈夫です。
+
+4. **コミットとプッシュ**:
+   - キリの良いところで、こまめにコミットします。コミットメッセージにIssue番号（#11）を入れると、自動でIssueと関連付けられます。
+   ```bash
+   git commit -m "feat: ログインフォームのUIコンポーネントを作成 #11"
+   ```
+   - 作業が完了したら、ブランチをリモートリポジトリにプッシュします。
+   ```bash
+   git push origin feature/11-login-ui
+   ```
+
+5. **プルリクエストの作成**（開発完了後の具体的なアクション）:
+   - GitHub上で、今プッシュしたfeature/11-login-uiブランチからdevelopブランチへの**プルリクエスト（PR）**を作成します。
+   - PRは「この変更を開発用ブランチに加えても良いですか？」というレビュー依頼です。
+   - PRの説明欄に `Closes #11` と書くことで、このPRがマージされた時にIssue #11 が自動でクローズされるように設定します。
+
+## 3. レビュー＆統合フェーズ（テストフェーズ）
+
+### 概要
+作成したプルリクエスト（PR）を通じて、変更内容が安全であることを確認し、開発の中心であるdevelopブランチに統合します。ここでの主役は自動化とコミュニケーションです。
+
+### 流れ（テストフェーズの具体的な流れ）
+
+1. **自動テストの実行 (GitHub Actions)**:
+   - PRが作成されると、それをきっかけ（トリガー）にGitHub Actionsが自動的に起動します。
+   - あらかじめ設定しておいたテスト（単体テスト、結合テストなど）が実行され、この変更によって既存の機能が壊れていないかがチェックされます。
+   - 結果はPRページに「✔︎ All checks have passed」のように表示され、品質を客観的に保証します。
+
+2. **コードレビュー**:
+   - 他の開発者（あるいは未来の自分）がPRの「Files changed」タブを見て、コードの変更内容を確認します。
+   - 「この変数名はもっと分かりやすい方が良い」「ここのロジックはもっとシンプルに書ける」といったフィードバックを、コードの特定の行に対してコメントします。
+
+3. **フィードバック対応と修正**:
+   - レビューコメントを受けたら、自分の作業場（../login-ui-workフォルダ）でコードを修正します。
+   - 修正内容をコミットし、再度プッシュします。PRは自動的に最新の状態に更新され、GitHub Actionsによるテストも再実行されます。
+
+4. **マージ**:
+   - すべての自動テストが成功し、レビューで承認（Approve）されたら、PRページの「Merge pull request」ボタンを押します。
+   - これで、あなたの変更が安全にdevelopブランチに統合されます。
+
+5. **後片付け**:
+   - developブランチに統合されたので、作業用のブランチと作業場は不要になります。メインの作業フォルダに戻り、以下のコマンドでクリーンアップします。
+   ```bash
+   # メインの作業場に戻る
+   cd ../my-project
+   
+   # 不要になった作業場を削除
+   git worktree remove ../login-ui-work
+   
+   # 不要になったブランチをローカルとリモートから削除
+   git branch -d feature/11-login-ui
+   git push origin --delete feature/11-login-ui
+   ```
+
+この一連の流れを繰り返すことで、一つ一つのタスクを確実にこなしながら、プロジェクト全体を着実に完成へと導くことができます。
+
+## worktreeを使った並行作業の管理
+
+複数のIssueを同時に進める場合の具体例：
+- Issue #11: ログイン機能を作っている途中
+- Issue #12: 急にバグ修正が必要になった  
+- Issue #13: UIの改善アイデアが浮かんだ
+
+```bash
+# 現在の作業状況
+../my-project/        # developブランチ（メイン作業場）
+../login-work/        # Issue #11用（feature/11-login）
+../bugfix-work/       # Issue #12用（hotfix/12-auth-error）
+../ui-improve-work/   # Issue #13用（feature/13-ui-improvement）
+
+# 作業場間の移動は単純にcdするだけ
+cd ../bugfix-work     # バグ修正に切り替え
+cd ../login-work      # ログイン機能に戻る
+```
+
+それぞれの作業場は完全に独立しているので、コミットしていない変更があっても問題なく切り替えられます。
\ No newline at end of file