リーンキャンバスは、ブロックの順番どおりに書く必要がありますか。

必要ありません。リーンキャンバスを考案した Ash Maurya は、書くことをジグソーパズルにたとえ、決まった正しい順序はないと説明しています。最も理解しているブロックから始めてください。ただし、多くのアイデアは顧客セグメントと課題から始めるのがよいでしょう。よく使われる順序は、課題、顧客セグメント、独自の価値提案、ソリューション、チャネル、収益の流れ、コスト構造、主要指標で、圧倒的な優位性は最後のブロックです。

圧倒的な優位性（Unfair Advantage）とは何ですか。まだ持っていない場合は、どう書けばよいですか。

圧倒的な優位性とは、競合が簡単には真似したり買ったりできないものです。たとえば、長年かけて蓄積したデータやネットワーク、特定の顧客層との関係、希少な専門知識などです。初期のスタートアップの多くは、まだ持っていません。このブロックは空欄のままで構いません。「他社より先に始めた」のような真似しやすいことを書くよりよいでしょう。商標や特許などの法的な権利は一部を助けますが、それだけで優位性のすべてになるわけではありません。

リーンキャンバスとビジネスモデルキャンバスのどちらを使うべきですか。

新しいアイデアで、顧客が本当に課題を抱えているか、お金を払うかどうかまだ分からず、素早く検証したい場合は、リーンキャンバスを使います。すでに実際の顧客がいて、パートナー、リソース、チームを管理する必要がある場合は、ビジネスモデルキャンバスを使います。多くのチームは、リーンキャンバスから始め、事業の形がはっきりしてきたらビジネスモデルキャンバスに切り替えます。

会社をまだ設立していなくても、テスト販売や予約注文の受付はできますか。

個人としてなら可能です。ただし、創業者は顧客や取引先に対して個人として責任を負い、収入には個人所得税がかかります。前払いを受ける場合は、告知したとおりに商品を引き渡すか、返金しなければなりません。継続的に販売する場合は、商業登記が必要になることがあります。創業者が複数人いる場合、出資を受ける場合、従業員を雇う場合は、先に会社を設立し、創業者間の合意を結ぶべきです。

会社設立前に作ったコードやブランドは、誰のものですか。

原則として、コード、デザイン、コンテンツの著作権は創作者のものです。その時点では、使用者や委託者となる会社がまだないためです。会社を設立したら、著作権譲渡契約を書面で作成し、譲渡人と譲受人の双方が署名してください（著作権法 B.E. 2537 第17条）。商標、ドメイン、SNSアカウントも、会社名義に移すか、会社名義で出願します。その後に従業員や請負人が作った成果物は、第9条と第10条を契約とあわせて確認する必要があります。

リーンキャンバスとは：書き方とビジネスモデルキャンバスとの違い（スタートアップ向け）

スタートアップの創業者の多くは、アイデアが足りないのではありません。数か月をかけてシステムを作ったり商品を製造したりする前に、そのアイデアを本当に必要としている人がいるかを確かめる方法が足りないのです。リーンキャンバスは、この段階のために設計された1枚のツールです。解決策を書く前に顧客の課題を書かせ、本当に分かっていることと、まだ推測にすぎないことを切り分けます。

本ガイドでは、9つのブロック、実際に使える書く順序、ビジネスモデルキャンバスとの違いを説明し、コンケンの美容室向け予約アプリを例に取り上げます。そのうえで、アイデア検証の段階で見落とされがちな法務を順に見ていきます。創業者間の合意、コードとブランドの帰属、ユーザーデータ、市場テストでの顧客からの入金です。これらはチームが小さいうちなら簡単に直せますが、投資家が入ったあと、あるいは創業者の1人が抜けたあとでは、直すのが非常に難しくなります。

結論

リーンキャンバスは、Ash Maurya がビジネスモデルキャンバスを新しいアイデア向けに改変した9ブロックのシートです。主なパートナー、主な活動、主なリソース、顧客との関係の4ブロックを、課題、ソリューション、主要指標、圧倒的な優位性に置き換えています。決まった正しい書く順序はありませんが、多くは顧客セグメントと課題から始め、優位性は最後に書きます。初期段階では、すべてのブロックが、実際の顧客で検証すべき仮説です。

ルール（タイ法）。 アイデアを検証する段階にも、法律は適用されます。まだ会社を設立していなくても同じです。ウェブページやフォームで関心のある人の氏名、メールアドレス、電話番号を集める場合は、収集の前または収集の際に、目的、保存期間、情報の受領者、データ主体の権利を通知しなければなりません（個人情報保護法 B.E. 2562 第23条）。システムが、加盟店や他のサービス提供者に代わって電子的に支払いを受ける場合、その業務は、支払システム法 B.E. 2560 に基づきタイ中央銀行の許可または登録が必要な決済サービスにあたります。また、従業員が従業員として創作した著作物の著作権は、別段の書面の合意がない限り、創作した従業員に帰属します（著作権法 B.E. 2537 第9条）。

当事務所の実務的な見解。 チームがリーンキャンバスでアイデアを検証している間に、次の3つを並行して整えてください。創業者間の合意を書面にすること。コード、ブランド、データを会社のものにすること。最初の顧客の時点から、ユーザーデータの収集と入金の方法を適正にしておくこと。3つとも必要な書類は多くありませんが、投資家が最初に確認する事項です。

1. リーンキャンバスとは何か、どこから来たのか

リーンキャンバスは、『Running Lean』の著者 Ash Maurya が、Alexander Osterwalder のビジネスモデルキャンバスを改変して開発しました。Maurya は、新しいアイデアの最大のリスクは、パートナーやリソースよりも、顧客が本当に課題を抱えているか、それを解決するためにお金を払うか、という問いにあると考えました。そこで、ビジネスモデルキャンバスの4つのブロックを、この問いに答えるためのブロックに置き換えました。残りの5つのブロックは、元の位置のままです。

リーンキャンバスは、次のような場合に向いています。

お金を払う顧客がまだいないアイデア。 続けるか、修正するか、やめるかを早く知りたい場合。
複数のアイデアを持つチーム。 1つのアイデアにつき1枚書くと、わずかな時間で比較できます。
投資家やアドバイザーとの会話。 1枚で、どんな課題を、誰のために解決し、どう測るのかを説明できます。
既存事業が新商品を出す場合。 新しい顧客グループがそれを必要とするかどうか、まだ分かっていないとき。

2. リーンキャンバスの9ブロック

ブロック	中心となる問い	書く内容
1. 課題 (Problem)	顧客が抱える最も重要な課題は何か	主な課題を1〜3つと、顧客が今その課題を解決するために使っている代替手段
2. 顧客セグメント (Customer Segments)	誰がその課題を抱えていて、誰が最初に試してくれるか	対象グループと、その課題に最も困っている最初のユーザー（アーリーアダプター）
3. 独自の価値提案 (Unique Value Proposition)	なぜ顧客は自社に関心を持つべきか	既存の代替手段との違いを示す、明確な1つのメッセージ
4. ソリューション (Solution)	各課題をどう解決するか	ブロック1の課題に答える、少数の主要な機能
5. チャネル (Channels)	最初の顧客にどうやって届くか	成長を待たずに、今日から使えるチャネル
6. 収益の流れ (Revenue Streams)	顧客は何に対して、どのように支払うか	課金の方法。たとえば月額、1回ごと、売り切りなど
7. コスト構造 (Cost Structure)	商品を顧客に届けるのに、どんなコストが必要か	開発コスト、顧客獲得コスト、主な運営コスト
8. 主要指標 (Key Metrics)	どの数字が、正しい方向に進んでいることを示すか	測定できる、顧客の重要な行動
9. 圧倒的な優位性 (Unfair Advantage)	競合が簡単には真似したり買ったりできないものは何か	自チームだけが築き、蓄積できるもの。または、いったん空欄にする

Ash Maurya の解説（ashmaurya.com）による。Maurya は、Strategyzer AG のビジネスモデルキャンバス（strategyzer.com、CC BY-SA 3.0 ライセンス）からリーンキャンバスを開発した。

3. 実際に使える書く順序

決まった正しい順序はない

Maurya は、リーンキャンバスを書くことをジグソーパズルにたとえ、決まった出発点や正しい順序はないと説明しています。最も理解しているブロックから始めてください。ただし、多くのアイデアでは、顧客セグメントと課題から始めるのがよい出発点です。ほかのブロックはすべて、この2つへの答えに左右されるためです。

よく使われる順序

課題。 主な課題を1〜3つ書きます。思いつく課題をすべて書く必要はありません。そのうえで、顧客が今日その課題をどう解決しているかも書いてください。メモ帳や電話での問い合わせにすぎなくても、既存の代替手段こそが本当の競合だからです。
顧客セグメント。 新しいものを試すほど課題に困っている最初のユーザーは誰かを、はっきりさせます。買い手と売り手のような、2つの側がある事業では、同じシートに両方の側を書き、Maurya の勧めに従って、それぞれの視点を色か記号で分けます。
独自の価値提案。 最初のユーザーが読めばすぐに、既存の代替手段とどう違うかが分かる、1つのメッセージにします。
ソリューション。 課題が明確になってから書きます。課題を解決できる最小限にとどめてください。開発者である創業者は、このブロックから始めたがります。そうすると、アイデアが、顧客が必要とするものより、自分が作りたいものに傾いてしまいます。
チャネル。 今すぐ最初のユーザーに届くチャネルを選びます。たとえば、自分で会いに行く、オンラインコミュニティ、顧客が信頼する仲介者などです。
収益の流れ。 誰が、何に対して、どのように支払うかを書きます。最初から課金するつもりで進めることは、「もしあれば使いますか」と尋ねるより、よい検証になります。
コスト構造。 アイデアが成り立つかどうかが分かるまでに必要なコストを書きます。創業者の時間も含めます。
主要指標。 実際に誰かの役に立ったことを示す顧客の行動を選びます。ウェブページの閲覧数のような、見栄えはよいが何も語らない数字は避けます。
圧倒的な優位性。 最後のブロックとして書くか、空欄にします（第11項を参照）。

リスクの高い順に検証する

書き終えたら、すべてのブロックを同時に検証しないでください。一般的な順序は次のとおりです。

顧客が求めているか（desirability）。 課題は本当にあり、顧客は解決策を求めているか。インタビュー、テスト用のウェブページ、事前登録の受付で検証します。
収益を生めるか（viability）。 顧客は、コストをまかなえる形で支払うか。実際の販売や予約注文で検証します。
実現できるか（feasibility）。 チームは、必要な規模で作り、提供できるか。

多くのチームは最後の項目から始めます。つまり、先にシステムを完成させ、そのあとで、顧客がそれを求めていなかったと知るのです。

書くときのコツ

最初の1枚は、短い時間で書き終えます。まだ答えられないブロックには「まだ分からない」と書きます。それも有益な情報です。
今日の状況から書き、何年も先にこうなってほしいという姿からは書きません。
最もリスクの高い仮説に印を付け、まずそれを検証します。
日付を入れて、すべての版を残します。変わった版は、チームが顧客から何を学んだかの記録になります。
主要指標には、スタートアップ業界でよく使われる枠組みを使えます。たとえば、新規ユーザーの獲得、実際の利用開始、再利用、支払い、紹介などです。そのうえで、この段階で重要なものを、ごく少数だけ選びます。

4. リーンキャンバスとビジネスモデルキャンバスの比較

変わったブロック

シート上の位置	ビジネスモデルキャンバス	リーンキャンバス	変更の理由
左端	主なパートナー	課題	新しいアイデアは、誰に頼る必要があるかはまだ分からないが、何の課題を解決するかは先に知る必要がある
左中央・上	主な活動	ソリューション	ソリューションは、書いた課題に結びついている必要がある
左中央・下	主なリソース	主要指標	初期段階では、どんなリソースがあるかより、前進しているかどうかを知る必要がある
右中央・上	顧客との関係	圧倒的な優位性	何が競合を遠ざけるのかを、最初から考える必要がある
残りのブロック	顧客セグメント、価値提案、チャネル、収益の流れ、コスト構造	元の位置を使う。価値提案は独自の価値提案に調整

どちらのシートをいつ使うか

状況	向いているシート
新しいアイデアで、お金を払う顧客がまだいない	リーンキャンバス
まだ知らない新しい顧客グループに、新商品を出す	リーンキャンバス
すでに顧客と収益があり、仕組み全体を見たい	ビジネスモデルキャンバス
支店、フランチャイズ、パートナー探しを計画している	ビジネスモデルキャンバス
融資申込み用の事業計画書を準備する	ビジネスモデルキャンバスを書き、事業計画書に展開する

ビジネスモデルキャンバスをブロックごとに書く方法、カフェの記入例、ブロックごとの法務確認は、ビジネスモデルキャンバスとは：9つのブロックの書き方をご覧ください。

5. 記入例：コンケンの美容室向け予約アプリ

創業者が2人いると仮定します（これは仮想の例です）。1人はプログラムを書き、もう1人は美容院向けの機器を営業していた経験があります。2人は、コンケンの小規模な理容室・美容室向けに予約システムを作りたいと考えています。会社はまだ設立しておらず、お金を払う顧客もまだいません。

ブロック	チームが書いた内容
課題	店は、施術中にチャットや電話での予約対応に時間を取られる。予約したのに来ない客のせいで、売れるはずの時間帯が無駄になる。客は、どのくらい待つのか分からない。既存の代替手段：電話予約、LINEのチャット、ノートへの記入、来店して待つ
顧客セグメント	複数のスタッフがいる小規模な理容室・美容室（支払う側）。店の客（利用する側）。最初のユーザー：夕方と休日に予約が詰まる店、すでにLINEで客とやり取りしている店のオーナー
独自の価値提案	「お客様が自分で予約できます。店は手を止めてチャットに返信する必要がありません」
ソリューション	LINEから開ける予約リンク。予約時間前のリマインドメッセージ。人気の時間帯の予約には、決済サービス提供者を通じて予約金を受け付ける
チャネル	1店ずつ直接訪問する。SNS上の店舗オーナーのグループ。美容院向け機器の販売業者による紹介。店のページで客が予約リンクを見る
収益の流れ	店からの月額サービス料（検証すべき主な仮説）。予約金システムを使う店には、追加料金を課す可能性がある
コスト構造	サーバーとクラウドサービスの費用。メッセージ送信費。決済サービス提供者の手数料。販売と、店のシステム設定を手伝う創業者の時間
主要指標	毎週システム経由で予約が入る店の数。1店あたりの予約数。システム利用前と比べた、来店しなかった予約の数。1か月目のあとも利用料を払い続ける店の数
圧倒的な優位性	まだない。2人目の創業者が知っている県内の店舗ネットワークから築けるかもしれない

この例は仮想のケースです。

このキャンバスで見えてくること

この事業には顧客が2つの側にいます。支払うのは店ですが、予約ページを使うのは店の客です。店の客がリンクから予約してくれなければ、店はそれ以上お金を払いません。
最もリスクの高い仮説は、システムを作ることではなく、店が月額で支払うかどうかです。したがって、システム全体を作る前に、まず実際の店のグループに販売して検証すべきです。
予約金システムは来店しない客の問題を解決しますが、チームは直ちに他人のお金に関わることになり、それには法律の規制があります（第9項を参照）。
システムは、店の客の氏名、電話番号、予約履歴を保存します。チームは、このデータが誰のもので、チームが何に使えるのかを答えられなければなりません（第6項と第10項を参照）。

6. スタートアップ段階でのブロックごとの法務確認

ブロック	法務の問い	予約アプリの例では
課題	解決する課題は、金融、医療、教育、運送など、規制される事業にあたるか	一般的な予約事業に特別な許可は要らないが、予約金を受け取る部分は支払システム法に関わる
顧客セグメント	事業者向けか消費者向けか、あるいは両方か。それぞれの側に専用の利用規約が必要	店とはサービス契約を、予約する客とは利用規約を結ぶ
独自の価値提案	広告の主張は立証できるか。「ドタキャンがなくなる」や「売上が増える」は、裏付けがあって初めて使える	裏付けのないデータの結果を約束する表現は避ける
ソリューション	システムは、他人のソフトウェア、フォント、画像、サービスを、どんな条件で使っているか	オープンソースライブラリのライセンスと、メッセージプラットフォームの規約を確認する
チャネル	プラットフォームや代理店を通じて販売する場合、どんな条件を受け入れる必要があるか。紹介者はどんな報酬を得るか	機器の販売業者とは、紹介に関する合意を書面で結ぶ
収益の流れ	どんな契約が必要か。税務はどうなるか。自動更新はあるか	月額料金、解約、返金の条件
コスト構造	手伝ってくれる人は、創業者、従業員、フリーランスのどれか。その対価は何か	画面デザインを手伝うフリーランスとは、成果物を誰が所有するかを明記した契約が必要
主要指標	測定に使うデータは個人情報か。通知した目的の範囲で使えるか	集計データで測定し、個人ごとのデータは見る必要がない
圧倒的な優位性	優位性だと主張するものに、法的な権利の裏付けはあるか	店との合意で、店の顧客データについて、合意した範囲を超える権利をチームが主張してはならない

誰がデータ管理者か。 この例では、予約管理のために顧客データを収集するかどうかを決めるのは店です。したがって、店が個人情報の管理者にあたる可能性が高いと考えられます。店の指示で処理を行うアプリは、個人情報の処理者にあたる可能性が高く、両者の間でデータ処理の合意を結ぶべきです。ただし、チームが顧客データを自分の目的に使う場合は、たとえば他の店の広告を送る、客が店を選べる一覧ページを作る、などです。その部分ではチームもデータ管理者となり、客に通知し、自分自身の法的根拠を持たなければなりません。この立場は、誰が目的と方法を決めるかという事実によって決まります。したがって、システムを設計する段階で決めておくべきです。

7. 創業者間の合意

友人同士の創業者は、口頭で取り決めることが多く、1人の働きが減る、会社勤めに戻る、方向性で意見が合わなくなる、といったことが起きるまでは、それで通用します。創業者間の合意には、次の事項を含めるべきです。

役割と時間。 誰が何に責任を持つか。フルタイムで働くか。どの事項を単独で決められるか。
株式の配分。 株式の割合と、その理由。それぞれが持ち込む資金、労力、知識、ネットワークを考慮します（資金を出すパートナーと労力を出すパートナーを参照）。
株式の権利確定（vesting）。 創業者の株式が、働いた期間に応じて徐々に確定的な権利になる仕組み。早く辞めた人が全株を持ち続けないようにするためです。
創業者が抜けるとき。 誰が株式を買い戻す権利または義務を持つか。価格をどう計算するか。通常の理由で辞める場合と、合意違反で辞める場合の違い。
知的財産。 全員が、プロジェクトのために行った成果物を会社に譲渡することに同意する（第8項を参照）。
意思決定とデッドロック。 どの事項に全員の同意が必要か。同数になった場合はどうするか（株主が50対50の場合のデッドロックと解決策を参照）。
外部への株式売却。 先買権、大株主が売却する際の共同売却請求権（タグアロング）、会社全体の買い手が現れたときの強制売却請求権（ドラッグアロング）。
秘密保持。 全員がアクセスできる、顧客情報、事業計画、コード。

株主間契約は、一般に署名した者だけを拘束します。株式譲渡の制限を、会社と新しい株主にも及ぼしたい場合は、重要な事項を登記の時点から会社の定款に書くことを検討してください。詳細は外国人パートナーがいる場合の株主間契約をご覧ください。将来、従業員に株式を与える計画がある場合は、従業員持株制度（ESOPとRSU）をご覧ください。

8. コード、ブランド、アイデアは誰のものか

アイデアは著作権で保護されない

著作権が保護するのは、コード、デザイン、文章、画像などの表現です。考え方、手順、方法は保護しません。したがって、「理容室の予約アプリ」というアイデアは、誰のものでもありません。他の人が、自分でコードを書いて同じようなアプリを作ることができます。保護できるのは、チームが作ったコードとデザイン、商標登録したブランド名、秘密として管理する情報、そして場合によっては、特許を出願できる発明です。

会社設立前の成果物

創業者が自分でコードを書いた、またはデザインした場合。 会社ができる前は、創業者は誰の従業員でも請負人でもありません。したがって、著作権は創作者のものです。会社を設立したら、著作権譲渡契約を書面で結び、譲渡人と譲受人の双方が署名しなければなりません（著作権法第17条）。
会社の従業員。 第9条により、従業員として創作した著作物の著作権は、別段の書面の合意がない限り、従業員のものです。使用者は、雇用の目的の範囲で、その著作物を公表できます。したがって、開発者との雇用契約には、帰属を明記すべきです。
フリーランスまたは開発の請負会社。 第10条により、請負で創作した著作物の著作権は、別段の合意がない限り、委託者のものです。しかし、多くの開発請負契約は、請負人が権利を保持するように書かれています。そのため、契約をよく読み、ソースコードの引渡しも確認する必要があります（ソフトウェア開発契約とソースコードを参照）。

創業者が以前ほかの会社で働いていて、一部のコードを勤務時間中、または以前の使用者の機器で書いた場合は、使う前に以前の雇用契約を確認すべきです。以前の使用者が権利を主張する可能性があるためです。

ブランド、ドメイン、アカウント

商標は会社名義で出願し、ドメイン、SNSアカウント、LINE公式アカウント、アプリストアのアカウント、クラウドのアカウントは会社名義に移します。創業者の1人の名義のままにしておくと、その人が意図せず会社を支配する力を持ってしまいます（会社設立時のブランド・商標の帰属と商標登録の手続きを参照）。

特許と営業秘密

チームが特許を取得できる可能性のある技術的な方法を考案した場合は、出願前に公開しないよう注意してください。たとえば、コンテストでの発表や、詳細のオンライン投稿などです。発明の新規性に影響する可能性があるためです。特許を出願しない情報、たとえば内部の計算方法、顧客リスト、価格設定のデータは、管理者がアクセス権の制限や秘密保持契約などの適切な方法で秘密を守っている場合に、営業秘密法 B.E. 2545 に基づき、営業秘密として保護されます。取引先や共同出資者にアイデアを説明する前に、事業交渉の前にNDAを結ぶと特許、実用新案、営業秘密をご覧ください。

9. ウェブページ、試作品、予約注文による市場テスト

リーンキャンバスが役に立つのは、チームが実際の顧客でテストするときです。よく使われる方法には、それぞれ確認すべき法務があります。

登録受付のウェブページ。 メールアドレスや電話番号を集める場合は、送信ボタンの前に短いプライバシー通知を表示し、データを何に使うか、どのくらい保存するか、削除の依頼はどこにすればよいかを伝えます（PDPA 第23条）。マーケティングのお知らせを今後も送る場合は、ユーザーが自分で選べるよう分けてください。必要なデータだけを集め、まだ使わないのであれば、誕生日や住所は尋ねないでください。

クッキーと分析ツール。 測定ツールや広告ツールは、ユーザーを追跡することがあります。ウェブの動作に必須でないクッキーについては、ユーザーに知らせ、選べるようにしてください（PDPAチェックリストを参照）。

まだ存在しない商品の販売ページ。 まだ存在しない商品の「注文する」ボタンで関心を測る方法はよく使われますが、お金を受け取ったり、ユーザーに購入が完了したと思わせたりしてはいけません。ユーザーがボタンを押したら、商品はまだ販売の準備ができていないことをはっきり伝え、待機リストへの登録を案内します。

予約注文。 前払いを受ける場合は、支払い前に、いつ引き渡すか、期限までに引き渡せないときはどう、いつまでに返金するかを知らせ、知らせた証拠を保存します。お金を払ったのに商品を受け取れなかった顧客は、民事法に基づいて返金を求める権利があり、消費者保護法に基づいて苦情を申し立てることもできます（オンラインショッピングでの消費者の権利を参照）。

入金。 許可を受けた決済サービス提供者を使ってください。顧客のお金を創業者の個人口座に通してから店に送金することは避けてください。チームのシステムが、加盟店や他のサービス提供者に代わって自ら入金を受ける場合、その業務は、支払システム法 B.E. 2560 に基づきタイ中央銀行の許可または登録が必要な電子決済サービスにあたります。予約アプリの例では、より安全な方法は、許可を受けた提供者を通じて、予約金を店の口座に直接支払わせることです。

ベータ期間。 短い利用規約を用意し、試験版であること、誤りがありうること、ユーザーが入力したデータをどう保存するか、ユーザーの意見や提案をチームが改善に使えることを伝えます。ただし、消費者に不公正な責任制限は、強制できないことがあります。

実際に切り替える前に、法人顧客でパイロット運用する方法と、試験期間中の合意の書き方は、ビジネスモデル変更のパイロット運用をご覧ください。

10. 主要指標とユーザーデータ

主要指標のブロックがあると、チームはあらゆるデータを集めたくなります。しかし、必要以上に集めたデータは、意思決定の役に立たないリスクにしかなりません。

必要な分だけ集める。 大半の指標は、集計データで足ります。たとえば、1店舗あたりの週ごとの予約数などです。どの客が何を予約したかを見る必要はありません。
個人を特定できるデータを分離する。 分析するときは、できる限り、氏名や電話番号ではなくIDを使います。
アクセスできる人を制限する。 創業者全員が本番のデータベースにアクセスする必要はありません。フリーランスには、必要な分だけの権限を与えます。
保存期間を決める。 不要になったら、削除するか、特定できない状態にします。
クラウドサービスと海外のツール。 個人情報を海外で保存または送信する場合は、PDPAに基づく基準があります。提供者が適切な保護措置を講じているかを確認し、プライバシー通知に記載してください。
AIツール。 チームがAIで顧客データを分析したり、文章を起案したりする場合は、入力してはならないデータを決めたルールを設けるべきです（顧客データに関する社内AIポリシーを参照）。

11. 圧倒的な優位性と法律

本当の優位性とは、簡単には真似したり買ったりできないものです。リーンキャンバスがこのブロックを空欄にできるのは、そのためです。初期段階では、ほとんどのチームがまだ持っていません。また、「他社より先に始めた」「チームの熱意」「システムが使いやすい」といった、よく書かれる内容は、まもなく真似されることが多いのです。

法律は、優位性の一部を築いたり守ったりするのに役立ちますが、それだけで優位性のすべてになるわけではありません。

商標。 混同するほど似た名前やロゴを他人が使うことは防ぎますが、別の名前で同じ事業を行うことは防ぎません。
特許。 要件を満たす発明を保護しますが、多くのソフトウェアやビジネス手法は、特許を取得できないか、出願する価値がありません。
営業秘密。 実際に秘密を守る措置を講じている場合にだけ保護され、独自に思いついた人を防ぐことはできません。
蓄積したデータ。 適法に取得し、ユーザーに通知した範囲で使う権利のあるデータは、実際に優位性になりえます。しかし、通知した範囲を超えて収集または使用すると、かえってリスクになります。
パートナーとの排他契約。 競合を遠ざけることはできますが、事業が大きな市場支配力を持つ場合は、取引競争法に注意が必要です。パートナーも、実際に同意していなければなりません。
取得が難しい許可。 規制される事業では、先に許可を得ていることが、本当の優位性になりえます。

12. ビジネスモデルキャンバスに移り、会社を登記するタイミング

リーンキャンバスからビジネスモデルキャンバスに切り替え、法的な構造を整えるべきタイミングを示す兆候は、次のとおりです。

継続的にお金を払う顧客がいて、主要指標が、顧客が本当に役立てていることを示している。
創業者が複数いる、または出資を受ける予定である。 会社を登記し、合意に従って株式を発行し、創業者間の合意を定款と株主間契約に反映させるべきです（タイ人オーナーのための会社設立を参照）。
最初の従業員を雇う予定である。 労働法と社会保険に基づく使用者の義務が生じます（初めての従業員：使用者の義務を参照）。
法人顧客が契約書と税務書類（インボイス）を求めてくる。 価格モデルとソフトウェアのサービス契約については、SaaSの価格モデルと月額サービス契約をご覧ください。
投資奨励の恩典を受けたい。 一部の種類のソフトウェア・デジタル事業は、BOIの奨励を申請できる場合があります（ソフトウェア・デジタル事業のBOIを参照）。
外国人の創業者または投資家がいる。 サービス業における外国人の持株は、外国人事業法の対象になる可能性があります。株式を発行する前に構造を設計してください（サービス会社の外国人事業許可を参照）。