product-playbook 1.0.0

package/i18n/ja/references/02b-jtbd.md

@@ -0,0 +1,125 @@
+# フェーズ1：ディスカバリー — JTBD分析
+
+## 1.3 JTBD（Jobs to Be Done）分析
+
+> "分析の単位は消費者ではなく、消費者が達成しようとしているジョブである。" — Clayton Christensen
+
+**JTBD Statement公式：**
+```
+[ターゲット顧客] + [どんなジョブコンテキストで] + [どんなジョブ]を達成したい
+```
+
+例：住宅ローンの選択肢を比較中の初めてのマイホーム購入者が、銀行に連絡できない深夜に月々の支払額を素早く見積もり、パートナーと資金計画を一緒に確認したい。
+
+**JTBD 4タイプ分析表：**
+
+```
+| JTBDタイプ | 定義 | ペルソナ1 | ペルソナ2 |
+|-----------|------------|-----------|-----------|
+| 機能的ジョブ | 特定のタスクを完了する、または機能的な目標を達成する | | |
+| 感情的ジョブ | どう感じたいか、どんな気持ちになりたいか | | |
+| 社会的ジョブ | 他者からどう見られたいか | | |
+| ジョブコンテキスト | どんな状況でこのジョブを達成する必要があるか | | |
+```
+
+**JTBD深掘り5つの質問：**
+1. **根本的な問題**：ユーザーが表面的に述べるニーズの背後にある、本当に解決しようとしていることは何か？
+2. **現在の制約**：どんなソリューションが特定の制約により排除されたか？
+3. **現在のワークアラウンド**：ユーザーは現在どう対処しているか？どんな回避策を構築したか？
+4. **ギャップ**：現在のワークアラウンドのどこが不十分か？（このギャップがあなたの機会）
+5. **理想のソリューション**：制約が取り除かれた場合、ユーザーの理想のソリューションはどんなものか？
+
+**Teresa Torresユーザーインタビューベストプラクティス：**
+- ユーザーの**実際の過去の行動**にフォーカスし、仮定的な将来の行動ではない
+- 「この問題に最後に直面した時、どうしましたか？」と聞く。「どんな機能が欲しいですか？」ではない
+- 最もよくある間違い：仮定的な質問をする、ソリューションバイアスを持ち込む、詳細を掘り下げない
+
+### 📝 JTBD品質チェックリスト
+
+ClaudeはJTBD出力後にセルフチェックを行う必要があります（各項目に✅または❌を付け、❌の項目には改善方法を記載）：
+- [ ] 具体的なコンテキストが含まれているか？（「いつでもどこでも」ではなく、「銀行に連絡できない深夜に」）
+- [ ] 単一のコアジョブにフォーカスしているか？（3つのジョブを1文に詰め込んでいないか）
+- [ ] 機能的、感情的、社会的ジョブがすべて特定されているか？
+- [ ] 「このソリューションは本当にこのジョブに対応しているか？」の評価に使えるか？
+- [ ] 「現在のワークアラウンド」と「ギャップ」が含まれているか？（ギャップ＝機会）
+- [ ] 深掘り質問のQ5は感情的動機 / 職業的アイデンティティ / 心理的恐怖に到達しているか？（単なる機能的記述ではなく）
+
+**実行ルール（ハードゲート）：**
+- 各項目に必ず✅または❌を付ける — 空白の[ ]や説明のない✅リストは不可
+- すべての項目が✅の場合、追加で「この分析の最も弱い部分は何で、どう強化するか」を記述する必要がある
+- ❌ よくある問題：抽象的すぎる、複数のジョブが統合されている、コンテキストが欠落、プロダクト機能をジョブの記述に置き換えている、Q5が機能レベルにとどまっている
+
+---
+
+### 🏢 B2Bプロダクト深掘り要件
+
+**B2Bプロダクト（B2B2Cを含む）は以下の分析を完了する必要があります：**
+
+#### 組織レベルのジョブ分析（必須 — 少なくとも2レベルをカバー）
+
+| レベル | 説明 | 例 |
+|-------|-------------|----------|
+| **戦略的ジョブ** | 組織/経営レベルの部門横断的ニーズ | コンプライアンス監査、コスト管理、人材最適化 |
+| **運用的ジョブ** | プロセス/部門マネージャーレベルの調整ニーズ | 承認ワークフロー管理、チーム間情報同期 |
+| **タスクジョブ** | 個々のユーザーの日常業務ニーズ | フォーム記入、ステータス確認、レポート出力 |
+
+#### 購入者 vs. ユーザー分析（必須）
+
+購入者とユーザーが異なる人物の場合、それぞれのJTBDを個別に分析：
+- **購入者のジョブ**：購買決定に影響するジョブ（ROI正当化、リスク低減、コンプライアンス要件）
+- **ユーザーのジョブ**：日常業務中に達成すべきジョブ（効率向上、エラー削減）
+- 同一人物の場合、「このシナリオで意思決定者が同時にユーザーである理由」を説明
+
+#### 深掘り5つの質問 — B2B強化版
+
+**Q5は少なくとも以下のレベルの1つに到達する必要があります**（例）：
+- ✅ 職業的アイデンティティ：「彼女は経営陣の前で無能に見えることを恐れている。このレポートが部門の信頼性を代表するから」
+- ✅ 感情的動機：「彼は直属の部下に、数字を完全に把握していることを示したい」
+- ✅ 心理的恐怖：「彼女の最大の恐怖は監査人にプロセスのギャップを発見されること — 以前すでに一度警告を受けている」
+- ❌ 不合格例：「より良いツールで効率を改善したい」（機能レベルにとどまっている）
+
+#### 競合代替品分析（必須）
+
+ユーザーが実際に使用している代替品をリスト化：
+- 少なくとも2つの名前付き既存ツール（例：Slack / Excel / 紙のフォーム / メール / 口頭連絡）
+- 各ツールについて「根本的な欠陥」を説明：機能が弱いのではなく、「この欠陥がなぜ受け入れられ、未解決のまま放置されているか」（組織の慣性？切り替えコスト？経営層が気にしない？）
+
+### 📋 ユーザーインタビュー計画テンプレート
+
+```
+## ユーザーインタビュー計画
+
+**リサーチ目標**：[ターゲットペルソナ]が[ジョブコンテキスト]で[特定の問題]にどう対処しているかを理解する
+**スクリーニング基準**：
+  - 過去[X日/週]以内に[特定の行動]を経験していること
+  - 除外：[適さない人 — 例：社内従業員、既知のパワーユーザー]
+
+**コア質問（5-7問）**：
+1. 最後に[問題]に直面した時、どのように対処したか手順を教えていただけますか？（行動回想）
+2. そのプロセスで最もフラストレーションを感じた、または時間がかかった部分は？（ペインポイント特定）
+3. 他のアプローチを試しましたか？なぜ試した/試さなかった？（現在の代替手段）
+4. その部分がより良くなるとしたら、「より良い」とはどんな状態ですか？（理想の状態）
+5. これはどのくらいの頻度で起きますか？最後はいつでしたか？（頻度と緊急性）
+6. あなた以外に、この問題の影響を受ける人はいますか？（ステークホルダーマッピング）
+7. 1-10のスケールで、この問題のあなたにとっての深刻度は？その理由は？（ペインの定量化）
+
+**フォローアップ戦略**：
+  - インタビュイーが「普段は...」と言った時 → 「具体的に前回はどうなりましたか？」と聞く
+  - インタビュイーが感情に言及した時 → 「その気持ちをもう少し具体的に説明いただけますか？」と聞く
+  - インタビュイーがツール/方法に言及した時 → 「そのアプローチを選んだ理由は何ですか？」と聞く
+
+**文書化フォーマット**：
+  - 逐語録または録音
+  - インタビュー後24時間以内に、以下をタグ付け：重要な引用 / ペインポイント / 驚くべき発見 / 仮定との矛盾
+```
+
+---
+
+## 📎 このフェーズのファイル統合ノート
+
+ユーザーがこのフェーズでファイルをアップロードした場合、Claudeは以下のように統合します：
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| ユーザーインタビュー記録 / 録音テキスト | 1.1 ペルソナ + 1.3 JTBD | 抽出：ユーザー背景 → ペルソナフィールド；ペインポイント + 現在のワークアラウンド → JTBD深掘り5つの質問；感情的反応 → 感情面/社会面のジョブ |
+| 競合アプリのスクリーンショット | 1.3 JTBD（現在のワークアラウンド） | ユーザーの「現在の代替手段」として特定し、ワークアラウンドとギャップを分析 |

package/i18n/ja/references/02c-ost-journey.md

@@ -0,0 +1,65 @@
+# ステージ1：ディスカバリー — OST + ジャーニーマップ
+
+## 1.4 Opportunity Solution Tree（OST）
+
+**対象：フルモード / 高完成度**
+
+OSTはプロダクト目標からスタートし、機会とソリューションを体系的に結びつけます：
+
+```
+[プロダクト目標 / 望むアウトカム]
+    │
+    ├── [機会1：ユーザーのペインポイントまたはニーズ]
+    │       ├── [ソリューション1a]
+    │       └── [ソリューション1b]
+    ├── [機会2：ユーザーのペインポイントまたはニーズ]
+    │       └── [ソリューション2a]
+    └── [機会3：ユーザーのペインポイントまたはニーズ]
+            └── [ソリューション3a]
+```
+
+コア原則：
+- 目標（Outcome）は測定可能な結果であり、機能やアウトプットではない
+- 機会はユーザーリサーチから来る、社内ブレインストーミングからではない
+- ソリューションは機会にマッピングする — 機会をスキップしてソリューションに直行しない
+- まず広く、次に深く：まずすべての機会をリスト化し、次に1つずつソリューションを探索
+
+## 1.5 ユーザージャーニーマップ
+
+**対象：フルモード / 高完成度 / オーディエンスがデザイナーの場合**
+
+**ステップ1：概要テーブル**
+
+```
+**[ペルソナ名] — タスク：[タスクの説明]**
+
+| ステージ | コア行動 | 感情 | 主要ペインポイント |
+|---|---|---|---|
+| [ステージ1] | [主要行動の一行説明] | [感情 + 絵文字] | [最も重要なペインポイント] |
+```
+
+**ステップ2：各ステージの詳細展開**
+
+```
+> **ステージ：[ステージ名]**
+> - **行動**：[このステージでユーザーが実際に行うこと]
+> - **思考**：[ユーザーの頭の中で考えていること。一人称がベスト]
+> - **感情**：[感情状態とその理由]
+> - **ステークホルダー**：[このステージに関与する人]
+> - **課題**：[具体的な困難やフラストレーション]
+```
+
+**ステップ3：グルーピング**
+- ステージが細かすぎる場合は、大きなステージグループに統合
+- ステージ横断でペインポイントを集約し、コアペインポイントにフラグを付ける
+
+---
+
+## 📎 このステージのファイル統合ヒント
+
+ユーザーがこのステージでファイルをアップロードした場合、Claudeは以下のルールに従って統合します：
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| ホワイトボード / 手描きフロー図 | 1.5 ジャーニーマップ | フローを認識し構造化テーブルに変換；元の感情マーカーを保持 |
+| ユーザー行動データ（CSV） | 1.4 OST + 1.5 ジャーニーマップ | データを使用して最も一般的な行動パスとドロップオフが最も多いステージを検証 |

package/i18n/ja/references/03-define.md

@@ -0,0 +1,118 @@
+# ステージ2：Define — 問題の収束
+
+> **注意：各モードで実行するステップは、SKILL.mdの「モードステップ順序」で正式に定義されています。以下は参考情報です。**
+
+**フルモード / 高完成度 → すべて実行（2.1 〜 2.4）**
+**中完成度 → 2.1 + 2.3 + 2.4**
+**クイックモード / 低完成度 → 2.3のみ（コアHMW 1つ）**
+
+このステージに入る前に、プロダクトの3つのコア質問を確認：誰のためか？ / なぜ作るのか？ / 何を作るのか？
+
+## 2.1 ペインポイントサマリー表
+
+すべてのペルソナとユーザージャーニーマップからペインポイントを抽出：
+
+```
+| # | ペインポイントの説明 | 該当ペルソナ | 出現ステージ | 影響度（高/中/低） | 頻度（高/中/低） |
+|---|---|---|---|---|---|
+| P1 | | | | | |
+| P2 | | | | | |
+```
+
+## 2.2 April Dunfordのポジショニングフレームワーク
+
+**対象：中/高完成度 / オーディエンスが経営層/セールス/マーケティングの場合**
+
+ポジショニングはタグラインではありません — どこで誰と競争するかを決めることです：
+
+```
+| ポジショニング要素 | 質問 | あなたの回答 |
+|---------------------|----------|-------------|
+| 競合代替品 | あなたのプロダクトが存在しなかったら、ユーザーは何を使うか？（本当の答え。あなたが思う競合ではない） | |
+| ユニーク属性 | 競合代替品にないものは何か？ | |
+| ユーザーへの価値 | これらのユニーク属性がユーザーにもたらす具体的な価値は？ | |
+| ターゲット市場特性 | この価値を最も重視するユーザーは誰か？（具体的であるほど良い） | |
+| 市場カテゴリー | プロダクトを最適にポジショニングする市場フレームは？（フレームが競争基準を決める） | |
+```
+
+最もよくあるポジショニングの間違い：
+- 機能をポジショニングとして扱う（「AIがあります！」はポジショニングではない）
+- ポジショニングが広すぎ — 全員をカバーすると誰もカバーできない
+- ユーザーの実際の代替品ではなく、自分が思う競合を基準にする
+
+### 📝 ポジショニング品質チェックリスト
+- ✅ 「競合代替品」はユーザーの視点からか？（ユーザーが実際に使っているもの、あなたが思う競合ではない）
+- ✅ 「ユニーク属性」は競合代替品ができない、またはうまくできないことか？（双方が持っているものではない）
+- ✅ 「ユーザーへの価値」はユーザーの言葉かプロダクトの言葉か？（「2時間節約」vs「AI搭載自動化」）
+- ✅ 「ターゲット市場」は実際にその人々を見つけられるほど具体的か？
+- ✅ 5つのポジショニング要素は論理的に一貫しているか？
+- ❌ よくある問題：ユニーク属性と価値の断絶、間違った市場カテゴリーで間違った基準で判断される
+
+## 2.3 HMW（How Might We）問題のリフレーミング
+
+ペインポイントをHMW質問に変換し、JTBDの視点を組み合わせて各HMWの背後にあるジョブタイプを確認：
+
+```
+| ペインポイント# | ペインポイント | 対応JTBDタイプ | HMW質問 |
+|---|---|---|---|
+| P1 | [ペインポイントの説明] | 機能的 / 感情的 / 社会的 | どうすれば... |
+| P2 | [ペインポイントの説明] | | どうすれば... |
+```
+
+HMWの粒度原則：
+- 広すぎ（「ユーザーをもっと幸せにするには」）→ 方向性がない
+- ちょうど良い（「ユーザーが初回セットアップを60秒で完了できるようにするには」）→ 制約がありつつオープン
+- 狭すぎ（「ボタンの色を変えるには」）→ 可能性を制限
+
+### 📝 HMW品質チェックリスト
+- ✅ 明確な制約があるか？（完全にオープンエンドではない）
+- ✅ 複数のソリューションの余地が十分にあるか？（単一の回答を指していない）
+- ✅ JTBDまたはペインポイントに直接マッピングできるか？
+- ✅ チームがこのHMWを見てソリューションのブレインストーミングを始められるか？
+- ❌ よくある問題：広すぎ（ビジョンの再述）、狭すぎ（ソリューションを指定）、複数の問題を混在
+
+**例：**
+- ❌ 広すぎ：「どうすればユーザーの満足度を向上できるか？」
+- ✅ ちょうど良い：「どうすれば初めてのマイホーム購入者が3分で手が届く住宅ローン額を算出できるか？」
+- ❌ 狭すぎ：「どうすればホームページに住宅ローン計算機を追加できるか？」
+
+## 2.4 機会評価表
+
+HMW質問を優先順位付け：
+
+```
+| HMW質問 | 影響ペルソナ | ペルソナ規模 | ユーザーインパクト（1-5） | ビジネス価値（1-5） | 実現可能性（1-5） | 合計 | 優先度 |
+|---|---|---|---|---|---|---|---|
+| | [影響ペルソナをリスト] | [大/中/小] | | | | | |
+```
+
+**スコアリングスケールの定義：**
+
+| スコア | ユーザーインパクト | ビジネス価値 | 実現可能性 |
+|-------|-----------|---------------|-------------|
+| 1 | 少数のユーザーにとって軽微な不便 | 間接的、長期的なリターンがせいぜい | 完全に新しい技術または大規模なR&Dが必要 |
+| 2 | 一部のユーザーが時々遭遇 | 間接的にいくつかのメトリクスを動かす可能性 | 大幅な新規能力構築が必要（3ヶ月以上） |
+| 3 | コアTAが定期的に遭遇 | 重要メトリクスへのポジティブな影響 | 新規開発が必要だが技術的に実現可能（1-3ヶ月） |
+| 4 | 多くのユーザーが頻繁に遭遇 | ユーザー成長またはリテンションを直接ドライブ | 現在のチーム能力で2-4週間 |
+| 5 | 多くのユーザーが日々コアタスクを完了できない | 収益またはNorth Star Metricに大きなインパクト | 現在のチームで2週間以内に完了可能 |
+
+**Shreyas Doshiの機会コスト思考：**
+
+「この機能のROIは？」ではなく、こう問いかけてください：
+
+> 「Aにリソースを投資するなら、Bに投資する機会を放棄している。AはBより本当に価値があるか？」
+
+ROI思考は単一の機会が追求する価値があるか評価する；機会コスト思考はすべての機会の中でより良い選択を助ける。
+
+**0→1フォーカスリマインダー：** 機会評価を完了した後、MVPのコアとして**最優先のHMW質問1つだけ**を選ぶことを推奨します。（Facebook：大学生 → 高校生 → 全員；プロフィールページ → 写真 → ニュースフィード）
+
+---
+
+## 📎 このステージのファイル統合ヒント
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| 競合スクリーンショット / 競合分析レポート | 2.2 ポジショニング | 「競合代替品」と「ユニーク属性」フィールドに記入；差別化を比較 |
+| 市場レポート（PDF） | 2.4 機会評価 | 市場データでペルソナ規模とビジネス価値スコアを検証 |
+| NPS / 満足度調査データ | 2.1 ペインポイントサマリー | 仮定の影響度と頻度を実際のスコアに置き換え |
+| カスタマーサポート / チケットサマリー | 2.1 ペインポイントサマリー + 2.3 HMW | ペインポイント頻度をカウント；高頻度チケットを直接HMW質問に変換 |

package/i18n/ja/references/04a-prfaq.md

@@ -0,0 +1,111 @@
+# フェーズ3：Develop — PR-FAQ（Working Backwards）
+
+## 3.1 AmazonのWorking Backwards手法（PR-FAQ）
+
+プロダクトのプレスリリースを書くことから始めます — 顧客のアウトカムから逆算して考えることを強制します：
+
+```
+## [プロダクト名] プレスリリース
+
+**見出し**：[ユーザーは何を達成できるか？一文で。]
+**サブ見出し**：[何の問題を、誰のために解決するか？]
+
+**冒頭段落（Aha Moment）**：
+[ユーザーがプロダクトのコア価値を体験する瞬間を描写 — 「すごい！」の瞬間]
+
+**ペインポイントの説明**：
+[ユーザーが今日直面している問題は何か？現在のソリューションがなぜ十分でないか？]
+
+**ソリューションの説明**：
+[当社プロダクトはこの問題をどう解決するか？（体験を描写 — 機能リストではなく）]
+
+**顧客の声**：
+"[ターゲットユーザーの本物の感情的反応を代表する引用]"
+
+**FAQ（最も難しい質問）**：
+Q: [最も答えにくい質問]
+A: [正直な回答]
+```
+
+> 人々をワクワクさせるプレスリリースが書けないなら、プロダクトの方向性に欠陥があるかもしれません — 問題定義に戻ってください。
+
+### 📝 PR-FAQ品質チェックリスト
+
+ClaudeはPR-FAQ出力後、各項目に✅または❌を付ける必要があります；❌の項目には改善方法を記載：
+- [ ] 見出しはユーザーの視点で書かれているか？（「ユーザーがXをできるようになった」vs「機能Yをリリースしました」）
+- [ ] 読者が最初の段落を10秒で読んで「なぜこれが重要か」を理解できるか？
+- [ ] ペインポイントの説明は実際のユーザーシナリオから来ているか？
+- [ ] ソリューションセクションの最初の文はユーザーの体験/シナリオで始まっているか？（機能の動詞ではなく）
+- [ ] 顧客の声は実際の人が言いそうな言葉か？
+- [ ] FAQには既存ツールとの鋭い比較が含まれているか？
+
+**実行ルール（ハードゲート）：**
+- 少なくとも1つの「内部的な緊張感」または「改善余地のある領域」を特定する必要がある — すべて✅にして完了とすることはできない
+- すべての項目が合格した場合、追加で「このPR-FAQの最も脆弱な仮定は何か」を記述
+- AmazonのPR-FAQの品質基準は、問題を見つけることから来る、問題がないことを確認することからではない
+- ❌ よくある問題：見出しがニュースではなくプロダクト発表に読める、ソリューションセクションが機能リストになる、FAQがすべてソフトボール質問
+
+---
+
+### ✍️ ソリューションセクション（本文）のライティングルール
+
+**ソリューションセクションの最初の文は、機能の説明から始めてはいけません。**
+
+❌ 禁止例：
+- 「MealPrepはワンクリックでメニューを入力し、食材を自動計算します」
+- 「システムがメニューに基づいて調達リストを自動生成します」
+- 「『リスト生成』ボタンをクリックすると、準備計画が完了します」
+
+✅ 正しい例：
+- 「今では、陳シェフは金曜の午後に10分だけあれば、週末の仕込みの詳細をすべて確認できます」
+- 「張マネージャーはもう3つのExcelシートをめくって在庫が足りるかどうか確認する必要はありません」
+
+**公式**：ユーザーの体験 / 具体的なシナリオから始める → 次に「これが可能なのは[プロダクトの仕組み]のおかげ」で機能を紹介。
+
+---
+
+### ❓ FAQ鋭い質問の基準
+
+**少なくとも1つのFAQは：「なぜ[既存ツール]を使い続けないのか？」であること**
+
+回答フォーマットの要件：
+1. **まず既存ツールの強みを認める**（否定しない）
+2. **次にギャップを説明**（機能のギャップではなく、根本的なシナリオのギャップ）
+
+❌ 禁止回答パターン：「既存ツールは機能が不足 — 当社はより強力」
+✅ 正しい回答パターン：
+> 「Excelは確かに数値管理ができますし、シェフたちも使い方を知っています。問題は、毎週末に計算をやり直す必要があることです — 再入力、再変換 — その1時間は誰かがスプレッドシートが苦手だからではなく、問題が本当に複雑だからです。MealPrepはExcelのスキルを節約するのではなく、毎回ゼロからやり直す精神的負担を節約するのです。」
+
+**例（架空のプロダクト — 住宅ローン計算アプリ）：**
+
+```
+## MortgageSnapで初めてのマイホーム購入者が3分で手が届く額を把握
+
+**サブ見出し**：銀行に行かなくても、見積り待ちも不要 — 深夜でもパートナーと一緒に月々の支払額を確認
+
+**冒頭段落（Aha Moment）**：
+深夜にZillowをスクロールしていたアレックスは、気に入った家を見つけたが、
+本当に買えるのか見当もつかない。MortgageSnapを開いて物件ページのスクリーンショットを撮ると、
+アプリが自動的に価格と面積を抽出。30秒以内に3つのローンシナリオの月々支払額が表示される。
+妻に結果を共有し、初めて二人で同じ数字を見ながら話し合うことができた。
+
+**ペインポイントの説明**：
+住宅ローンの選択肢を比較する初めてのマイホーム購入者は、複数の銀行のウェブサイトで
+手動で条件を入力し、回答を待つ必要がある。深夜に計算したい時に便利なツールがなく、
+結局Excelで無理やり計算するか、あきらめてしまう。
+
+**ソリューションの説明**：
+MortgageSnapなら物件情報をスキャンするだけで主要データを自動抽出し、
+各金融機関のオプションを即座に比較、共有可能なレポートを生成して
+家族で一緒に検討できます。
+
+**顧客の声**：
+"深夜に銀行からの折り返しを待つ必要がなくなりました。3分で妻に
+月々いくら払うことになるか正確に伝えられます。"
+
+**FAQ**：
+Q: 住宅ローン計算機はすでにたくさんある — 何が違うのか？
+A: 既存の計算機は金利、ローン期間、その他のパラメータの入力を求めますが、
+初めてのマイホーム購入者はそれらの数字すら知りません。MortgageSnapの違いは、
+各金融機関の実際のオファーを自動的に取得すること — 必要なのは価格と頭金だけです。
+```