プロダクト哲学を伝える創業者サイトの作り方

サイトの目的から始める

創業者サイトはパンフレットではなく、明確な意図表明です。1行も書く前に、このサイトが何のためにあるのかを決めてください：ボタンが何個あるかではなく、製品の背後にある「なぜ」を伝えて、読者がどんな信念で作られたかを理解できるようにするためです。

目標を明確に：哲学が先、機能は後

あなたのプロダクト哲学は次のような問いに答えるべきです：

• どの問題が間違ったやり方で解決されていると思うか？
• どんなトレードオフを受け入れるか？
• たとえ利益が出ても決してやらないことは何か？

これが明確なら、各ページは同じ物語を支えることができます。

主な対象を定める（と1つの行動）

最初のバージョンで一つの主要対象を選んでください：

• 買い手（Buyers） は確信が必要です：「これは私たちの優先事項に合っている」
• ユーザー（Users） は明快さが必要です：「これで私の仕事／生活が具体的に良くなる」
• パートナー（Partners） は適合性が必要です：「価値観とアプローチが一致している」
• 報道（Press） ははっきりした切り口が必要です：「これが主張だ」

次に、その対象に結びついた単一の成功アウトカム（メール登録、デモ申込、事前注文、採用の関心 など）を選び、サイトをそこへ誘導するよう設計します。

測定可能な成功基準を設定する

「機能している」とは何かを数値で書き出してください：コンバージョン率の目標、週間デモ申込の目標、または最低限の質の高いメール数など。

カバーしないことを決める

サイトを長い自伝にしないでください。哲学を直接説明しない限り、だらだらした起源話は避けましょう。また「AI駆動のシナジー」などのジャーゴン多用はやめ、弁護できる具体的な約束に集中してください。

平易な言葉でプロダクト哲学を定義する

プロダクト哲学は、なぜそのプロダクトを作ったのか、そして今後どう意思決定を行うかを説明する短い信念のセットです。宣言文ではなく、賢い友人に説明するように書いてください。

まずは一文から始める

サイト全体（ホーム、/about、プロダクトページ）で使える一行を下書きしてください：

「[誰のために]、私たちは[痛み／問題]を[アプローチ]で解決します。なぜなら[生みたい変化]を信じているからです。」

例：「小さな代理店オーナー向けに、私たちは意見を持ったワークフローでプロジェクトの混乱を減らします。なぜなら、カスタマイズの常時調整よりも明快さが勝ると信じているからです。」

3–5のコア信念を名付ける

意思決定を導くのに十分具体的なものにしてください：

• 「プロダクトは一度で学べるべきだ」
• 「デフォルトが多くの人に機能すべきだ」
• 「短期的なトリックより長期的な信頼を最適化する」

信念をユーザー向けの約束に変える

信念は内部向け、約束はユーザーが期待できることです。

• 信念: 「一度で学べる」
  約束: 「トレーニングなしで初日から生産的になれます」
• 信念: 「デフォルトが機能する」
  約束: 「すべてを設定し直さなくても価値が得られます」

トレードオフを明示する

トレードオフは誠実さのサインで、適切な顧客の自己選別を助けます。

例：

• 「無限のオプションよりシンプルさ」
• 「統合は少ないが、サポートするものは維持する」
• 「何でも作れるより意見を持ったワークフロー」

読者が将来の意思決定を予測できるなら、哲学は機能しています。

ユーザーが使う言葉をリサーチする

創業者サイトが機能するのは、ターゲットの人たちが普段使う言葉のように聞こえるときです。哲学を書く前に、顧客が問題をどう表現するか、いつそれが痛みになるか、そして「より良い」とは何かを聞いてください。

実際のフレーズを集める（要約ではなく原文）

まずは5–10の実際のフレーズを、ユーザーが自分の声で話している場所から集めます：

• セールス通話やデモのメモ
• サポートチケットやライブチャットの記録
• レビュー（自社と競合）
• コミュニティ（Reddit、Slackグループ）、求人票、RFP

特に「疲れた…」「ただ〜したい」といった短く感情的な一言は、見出しやサブヘッド、哲学の導入に使える素材になります。

言葉の中に隠れた反論を見つける

繰り返し聞く一般的な反論や恐れをリスト化してください。大抵はいくつかのカテゴリに分かれます：

• 価格: 「投資効果があるか不安だ」
• 切り替えコスト: 「移行に何週間もかかる」
• 信頼: 「1年後も存在するだろうか？」
• 複雑さ: 「うちのチームは別のツールを受け入れないだろう」

これらと議論するのではなく、読者が安心するために何が必要かを示すヒントと受け取ってください。

哲学のポイントをリスク低減に結びつける

「シンプルが強い」という信念なら、採用リスクをどう下げるかを示してください。「データは自分のものにする」という信念ならベンダーロックインのリスクをどう低減するかを示します。価値観と購買判断の橋渡しが重要です。

読みやすさのレベルを意図的に決める

デフォルトの文体を決めてください：短い文、具体例、最小限の略語。どうしても専門用語を使うなら1回だけ平易に定義してください。こうすると哲学が速くスキャンでき、信頼性を失いません。

物語を支えるシンプルなサイト構成を選ぶ

創業者主導のサイトは、信念→作ったもの→対象→次にすべき行動、という案内の会話のように読めると効果的です。構成はその物語を迷わず辿れるようにします。

多くの創業者プロダクトに合うシンプルなサイトマップ

各ページが一つの役割を果たすように小さなセットにまとめます：

• Home — 「これは何か、誰のためか、どんな成果を届けるのか」
• Philosophy — 「問題について何を信じ、どんな原則がプロダクトを導くか」
• Product — 「どう動くか、機能が哲学をどう表現しているか」
• Use Cases — 「あなたのアプローチが勝つ実例（対象別やワークフロー別に）」
• Proof — 「なぜ信頼できるか（顧客、結果、信用性、セキュリティの基本）」
• Pricing — 「価格、含まれるもの、プランの選び方」
• FAQ — 「反論に答え、コアメッセージを崩さずに境界を明確にする」
• Contact — 「問い合わせ方、デモ申込、サポートの方法」

ナビゲーションは短く、残りはフッターへ

トップレベル項目は5〜7個に抑え（例：Home、Philosophy、Product、Use Cases、Pricing、FAQ、Contact）、Careers、Press、Legal、Security、Changelog はフッターへ移して主要な道筋をクリアにします。

すべてのページに明確な次の一手を置く

各ページは一つの主要アクションで締めます：トライアル開始、ウエイトリスト参加、通話予約、問い合わせ。サイト全体でアクションを統一して、訪問者が何度も再判断しなくて済むようにします。

信念と成果を前面に出すホームページを書く

ホームページは1分以内に二つの仕事を果たすべきです：訪問者にどんな成果を生むかを伝え、なぜあなたのアプローチが違うのかを示すこと。スクロールしないと何をするか分からないなら既に負けています。

ヒーロー：成果を先に、哲学はその次に

まず単一の具体的な成果を見出しで示し、次にその成果を達成する「正しい方法」についての一文を添えます（ジャーゴンは避ける）。

例となる構成：

• 見出し: 提供する成果（明瞭で具体的）
• 補助文: その成果を達成するための信念（平易な言葉）

「私たちの考え方（How we think）」の短いティーザーを置き、/philosophy に誘導できるようにすると、興味ある読者に深掘りの道を示せます。

スキャンしやすい物語：問題 → アプローチ → プロダクト → 証拠 → CTA

ページの残りは短い論証として整理します：

問題: ユーザーが直面することを彼らの言葉で示す。焦点は一つの主要な緊張に絞る。

アプローチ: あなたの視点を説明する。ここで哲学が登場する—優先すること、やらないこと、受け入れるトレードオフ。

プロダクト: 製品が何か、誰向けかを1段落で。機能の詳細は /product に、対象別の詳細は /use-cases に置く。

証拠: ロゴ、短いテストモニアル、文脈付きの指標など、主張をサポートする控えめな信用シグナルを載せる。

CTA: 明確な一つの行動で締める（例：「仕組みを見る」「哲学を読む」「トライアル開始」）。ページ内でアクションは一貫させます。

人が斜め読みできるPhilosophyページを作る

良いPhilosophyページはバイオではなく信念で始まります。

信念表明例: ソフトウェアは決定を増やすのではなく、決定を減らすべきだ。

その信念がプロダクトにどう影響しているかをすぐに示し、1分以内に適合するか判断できるようにします。

人が慣れた繰り返しパターンを使う

スキミングしやすいページは予測可能です。各原則ごとに次の4つの要素を繰り返してください：

原則 → 意味すること → 私たちがすること → 私たちがしないこと

太字ラベルを追うだけでも立場が分かるようにします。

原則はスローガンではなく「設計上の判断」として書く

原則: デフォルトはシンプルにする

意味すること: 初回体験がエッジケースより重要である。

私たちがすること: 妥当なデフォルトを提供し、設定は最小限にし、選択肢を平易な言葉で説明する。

私たちがしないこと: 競合が持っているからといってオプションを追加しない。

ミニストーリー: 顧客から「カスタムダッシュボード」を求められた際、ダッシュボードビルダーを追加する代わりに、役割別に3つのビュー（Founder、Ops、Finance）を用意し、オンボーディング時間を数日から半日へ短縮した。

原則: 注意を尊重する

意味すること: 真に行動が必要なとき以外はプロダクトは静かであるべきだ。

私たちがすること: 通知はまとめて要約する。

私たちがしないこと: エンゲージメントを促すために緊急性を煽るアラートは使わない。

ミニストーリー: ベータユーザーが通知で圧倒されていたため、週12件の通知を金曜のまとめ1件に変えたところ、翌月にサポートチケットが減った。

スキミングしやすく、信頼しやすくする

原則は3–6個に絞り、最後に「誰向け／誰向けでないか」の短い注を付けて自己選別を助けます。

もしこのアプローチに賛同するなら、価格設定や作り方も気に入るはずです—/pricing や /contact を案内してください。

プロダクトページで哲学と機能を結びつける

プロダクトページはチェックリストの羅列ではなく、なぜその作りになっているかを説明する場であるべきです。すべての機能が原則の結果として感じられるようにしてください。

原則で始め、次に機能を示す

主要な機能ブロックごとに短い信念表明を置き、それをどう機能で実現しているかを示します。

例の構成：

• 原則: 「明快さは複雑さに勝る」
• だから作った: 何が変わったか、何が重要か、次に何をするかを答える単一のダッシュボード

このフレーミングは、訪問者が意図を理解し、自己選別が早く進むのに役立ちます。

重要なワークフローを3–5ステップで説明する

オンボーディング、プロジェクト作成、結果レビューなど、哲学を最も表すワークフローを選んで短い手順で説明します。

ワークフロー: アイデアから公開ページまで

1. 既存コンテンツを接続（移行不要）
2. 目的に沿ったテンプレートを選ぶ
3. 見出し・証拠・CTA を一箇所で編集
4. クリーンなURLへ公開
5. 効果を確認して改善

ステップは人間味と成果に焦点を当て、社内用語は避けてください。

信頼を築くための制約を明記する

「万人向けではない」ことを小さなコールアウトで示すと、哲学の信憑性が増します。

例：「オプションを絞って速い意思決定を重視するチーム向け。大規模なカスタマイズや50クライアントを管理する代理店向けではありません。」

正直な比較：なぜこのアプローチを選んだか

競合名は出さずにアプローチの対比を短く示します：

• 「オールインワン」対「フォーカスされたツール」
• 「無限のカスタマイズ」対「意見を持ったデフォルト」
• 「自動化優先」対「人間の確認を織り込む」

得られるものとトレードオフを説明すると、適切な顧客は興味を持ち、不適切な顧客は不満なく去ります。

ユースケースで哲学を具体化する

信念は同意しやすいが想像しにくい。ユースケースは「これを使うとこうなる」という具体例にして、哲学を現実の成果に変換します。短く、具体的で成果中心のストーリーにしてください。

ここから始める（経路を選ばせる）

異なる読み手が自己識別しやすいようにページ上部に簡単なチューザーを置きます：

• ツールを評価している → 「散らかったセットアップからの移行」を見る → /pricing
• アプローチを比較している → 「過度な自動化を避ける」を見る → /faq
• 話したい → 「少人数チームでの導入」へ → /contact

ユースケース1: 散らかったセットアップからの移行

対象: 創業者とオプスリード

状況: ツールが多すぎ、所有権が不明、決定がDMに埋もれている

望む結果: 重いプロセスなしに一つの信頼できる情報源を作る

アプローチの効果: 手順を減らし、デフォルトを明確にし、作業量を減らして速度を維持する

次の一手: /pricing

ユースケース2: 過度な自動化を避ける

対象: 「設定して放置」型で痛い目に遭ったプロダクトチーム

状況: 自動化が静かな失敗と驚きを生む

望む結果: 人のコントロールを残した予測可能な成果

アプローチの効果: 何を自動化し、何を手動に残すかの境界を示し、信念に整合させる

次の一手: /faq

ユースケース3: 初めての買い手と信頼構築

対象: 内部承認が必要な顧客

状況: セキュリティや信頼性、ベンダーロックの懸念

望む結果: 小さく始める自信

アプローチの効果: 哲学を明確な保証と限界に結び付け、何を約束し何をしないかを示す

次の一手: /faq

ユースケース4: 少人数チームでの導入

対象: リーンスタートアップ

状況: 管理者が不在でオンボーディングは速くあるべき

望む結果: 数日で価値を得る

アプローチの効果: 妥当なデフォルト、ガイド付きセットアップ、教えるサポートで迅速に価値を提供

次の一手: /contact

過大な約束を避けて証拠を示す

証拠は信頼を築きますが、提供できる範囲と一致しているときにのみ有効です。目的は読み手に「このチームは正直で、自分に合うかが分かる」と思わせることです。

信頼しやすい軽めの証拠を使う

誰を助け、何が変わるかを明らかにする証拠を選んでください：

• テストモニアル: 誇張より具体性。「オンボーディングを2週間から3日に短縮した」の方が「素晴らしい」より強い
• ロゴ（許可がある場合のみ）: 許可が無ければ掲載を避ける
• 文脈付きの数値: 期間、チームサイズ、出発点を添えて信憑性を保つ（例：「8人チーム、60日でトライアル→有料が12%から18%へ」）

トレードオフの扱いを示す

過大な約束は現実の“汚い部分”を隠すと生じます。フィードバック処理について短く説明しましょう：

「私たちは毎週リクエストを収集し、役割間でパターンを探して信頼性を高める変更を優先します。リクエストが哲学に反する場合は、理由を説明します。」

創業者の一言で人間味を出す

短く人間味のあるノートはスローガンより効きます。ビデオがあれば短いトランスクリプト抜粋を載せてください：

「こんにちは、私はマヤです。クリック数より明快さを最適化するツールに疲れてこのプロダクトを作りました。約束は単純です：機能を減らし、デフォルトを良くし、限界を透明にします。」

信頼の基本を網羅する

データに関わるなら、平易なセキュリティ／プライバシーの要約を載せ、詳細は /security に置く（法的な埋め草ではなく約束の一部として扱う）。

価値観を補強するFAQを作る

FAQはオブジェクションの保存庫ではなく、どのように考えているかを示す場所です。もしあなたの哲学が「明快さ優先」や「コントロールを残す自動化」なら、回答もそのトーンを反映させてください。

選ぶ質問は適合性（と非適合性）を示すものにする

購入直前に人々が尋ねる質問から始めます：

• 価格（含まれるもの）
• セットアップ時間とオンボーディング
• 既存ツールからの移行
• サポートと応答時間
• 誰向け／誰向けでないか

原則で答え、弁明ではなく説明する

一貫したパターン：「私たちはXをする。なぜならYを信じているから」。これにより機能決定が価値判断として伝わります。

価格

私たちは人数単位ではなくチーム単位で価格設定します。協働を成長の罰にしたくないと考えているからです。

セットアップ時間

ほとんどのチームは1日で稼働します。プロダクトは新しいワークフローを要求するのではなく、既存の流れに合うべきだと信じているからです。

移行

ガイド付き移行を提供します。ツール切替で組織知が失われるべきではないと考えているからです。

サポート

サポートはプロダクトを作る人が担当します。正確さが重視され、マニュアル化された台本よりも価値があると信じているからです。

誰向け／誰向けでないか

私たちは繰り返し使えるシステムを重視するチーム向けです。あらゆるコストで無制限のカスタマイズを求める人向けではありません。

短く、人間味があり具体的に

回答は2–4文を目標にしてください。法的に必要な場合（返金条件、プライバシー、コンプライアンス）は丁寧な表現にしますが、それ以外は平易な言葉で。

「まだ迷う？」のCTAを付ける

FAQの最後に /contact への明確な次の一手を置き、問い合わせしやすくします。

まだ迷っている？ /contact 宛てに短いメッセージを送ってください。以下は使えるテンプレート：

Subject: Not sure if it’s a fit

Hi — I’m evaluating [product] for [team/company].
We care most about [top priority].
We’re currently using [current tool/process].
Can you tell me if we’re a good fit, and what setup would look like?

（テンプレート部分は編集してそのまま使えます）

創業者主導サイトのためのデザインと声のガイドライン

デザインと言葉は同じ人が作ったように感じさせるべきです。哲学を説明するなら、すべてのビジュアルと文がそれを補強していなければなりません。

タイポグラフィと余白で哲学を表現する

もし哲学が「明快さと静けさ」なら、余白を多く、短い行長、読みやすい書体を使ってください。精密さが哲学ならグリッドや整った整列を重視し、遊び心なら色や個性を加えても構いませんが、ナビゲーションと主要ページは予測可能に保ちます。

実用的なルール：まずはスキャンしやすく、読み進めると報われる構成にする。

声は一つに決めて守る

早い段階で一人称（I/we）か三人称（the team/company）かを決めます。創業者主導のサイトは責任感と人間味が出るので一人称が有利なことが多いです。

決めたら以下を定義しておくとよいです：

• 声のカード（例：自信がある、直接的、ジャーゴンは使わない）
• 再利用できる例文

哲学が常に見えるように再利用可能なコンポーネントを作る

どのページにも置ける小さなブロックを作ります：

• 原則のコールアウト（1文＋なぜ重要か）
• 引用（創業者、顧客、パートナー）
• 決定メモ（「私たちはXをYより選んだ。なぜなら…」）

サイトが成長しても一貫性が保てます。

信頼を示すアクセシビリティの基本

アクセシビリティは信頼の一部です。必須事項を守ってください：十分なコントラスト、見出しの正しい順序（H2,H3…）、必要箇所の代替テキスト、読みやすいフォントサイズ（一般に16px以上）。哲学に「ケア」や「包摂」が含まれるなら、ここでそれを示せます。

公開して測定し、反復する

創業者サイトは公開で終わりではなく、視点を公開して人の行動を観察し、物語を磨くフィードバックループです。

検索意図を考えて公開する

哲学を見つけてもらいたければ、人々が検索する言葉で名前を付ける必要があります。狙うクエリ例：「プロダクト哲学 + カテゴリ」（例：「プロダクト哲学 プロジェクト管理」）や 「なぜ作ったか」（例：「この請求書ツールをなぜ作ったか」）など。

見出しは人にも検索エンジンにもスキャンしやすくしてください：

• 各ページに明確なH1を1つ
• 説明的なH2（例：「なぜ作ったか」「私たちが信じること」「製品での表れ方」）

公開前に測るべきことを設定する

分析は早めに入れ、イベントを公開前に定義しておきます。そうしないとトラフィックしか分かりません。

追跡する高信号アクションの例：

• 主要CTAクリック（例：「無料トライアル開始」「通話予約」）
• フォーム送信（問い合わせ、デモ、ニュースレター）
• /philosophy のスクロール深度（事例まで読まれたか）

価格ページがあるなら、Home/Product/Philosophy から /pricing へのクリックも追って、物語がモメンタムを生んでいるかを見ると良いです。

公開チェックリストを使う

公開前に短い“信頼パス”を実行してください：

• スペルとリンクチェック
• モバイルのレイアウト（特に最初の画面）
• ページ速度（重いメディアを圧縮、余計なものは削除）
• フォームのエンドツーエンド動作確認（確認メッセージ＋メール送信）
• 必要ならフッターにプライバシーポリシーのリンク

スケジュールを決めて反復する

大きな書き直しより小さな更新を計画してください。セールス、サポート、投資家の質問からフィードバックを集め、小さく更新します。

シンプルなリズム例：

• 四半期ごと：哲学の例を更新し、1つ新しいユースケースを追加
• 継続的：新しい証拠（引用、指標、事例）を追加

目標は一貫性です：哲学は安定させつつ、証拠を時間と共に強化していくこと。

実用的なビルドノート：声を失わずに速く公開する

多くの創業者は、数週間かけて手作業で作るか、あるいはテンプレートで速く出すかの板挟みになります。速く動きながらも文章に意図を保ちたいなら、チャット駆動のビルドワークフローが有効です。

例えば Koder.ai のようなツールなら、サイト構成を平易な英語で説明して（Home, /philosophy, /product, /use-cases, /pricing, /faq, /contact）、会話でレイアウトやコンポーネントを調整しつつ実際にエクスポートできるウェブアプリが得られます。プラットフォームの特徴で特に役立つもの：

• プランニングモード: 生成前にサイトマップとページ目標を設計して、哲学がぶれないようにする
• スナップショットとロールバック: メッセージや構造を試し、明快さが損なわれたら戻す

ポジショニングを検証するなら、このようなワークフローはサイトをプロダクト作業のように扱い、小さく公開して測り、改善することを可能にします。

Subject: Not sure if it’s a fit

Hi — I’m evaluating [product] for [team/company].
We care most about [top priority].
We’re currently using [current tool/process].
Can you tell me if we’re a good fit, and what setup would look like?