クラス予約モバイルアプリを作る方法：ステップバイステップガイド

予約アプリのコンセプトと対象を明確にする

画面や機能を考える前に、ユーザーが何を予約するのか、誰向けなのかを具体化してください。「クラス」には多様な意味があります：フィットネスセッション、家庭教師、音楽レッスン、語学スクール、ワークショップ、小グループのコーチングなど。それぞれ価格設定、スケジュール、キャンセル対応に対する期待が異なります。

明確な対象ユーザーから始める

主要ユーザーを一文で書き出してください。例：「忙しい親が子どもの週1回の家庭教師を予約する」や「ジム会員が定員制のグループクラスを予約する」。この明確さがリマインダーやチェックアウトフローなど全てを導きます。

単一事業向けアプリ vs. 複数講師のマーケットプレイス

対象が一つの事業（1つのスタジオ／スクール）か、多数の講師を扱うマーケットプレイスかを決めます。

• 単一事業向けアプリ： 運用が簡単でルールが一貫し、品質管理がしやすい。成長は通常単一ブランドに依存します。
• マーケットプレイス： 顧客にとって選択肢が増えるが、オンボーディング、支払い、サポート、信頼（評価、本人確認、紛争処理）の管理が難しくなる。

迷う場合は、現時点で運用可能なモデルを選んでください。後で拡張できますが、開発途中でモデルを切り替えるとコストがかかります。

単発の予約か、継続的な関係か？

多くのレッスンビジネスはリピート（週次クラス、数週間のコース、回数券、パッケージ）を前提としています。単発予約は単純ですが、継続プランは定着率と収益の予測性を高めます。選択はリスケ（再予約）、クレジット、出席管理など予約ロジック全体に影響します。

「成功」を定義する

初日から追うべき指標を3〜4個決めましょう：

• 週あたりの予約数（需要）
• リテンション（30〜60日でどれだけ戻ってくるか）
• キャンセル率（ポリシーの適合性とスケジュール品質）
• 任意：クラスや講師ごとの埋まり率

これらの目標がアプリの設計を絞り、意味のない機能追加を防ぎます。

簡単なリサーチで需要を検証する

画面設計やツール選定の前に、本当に人々があなたのアプリに乗り換えるかを確認してください。大規模な調査は不要で、問題が頻繁で辛いか、支払う価値があるかを示す証拠があれば十分です。

学生側と講師側の両方に話を聞く

合計8〜15回の短いインタビュー（各15分でも可）を行いましょう。新規・常連の参加者と、講師やフロントデスクの担当者を混ぜてください。

現在の予約フローとどこで壊れているかを尋ねます：

• 予約、再スケジュール、キャンセルで最も煩わしい点は？
• 欠席の原因は何か（忘れ、案内不足、ウェイトリスト、支払い問題）？
• 今何を使っているか（Instagram DM、スプレッドシート、Calendly、Mindbody、WhatsApp）とその理由は？
• 何があれば乗り換えるか？

正確なフレーズを書き留めてください—これらは後でアプリのマーケティング文言になります。

現状のジャーニーを一枚にまとめる

発見 → スケジュール → 支払い → 参加 → レビュー、の流れを一枚にマップします。

各ステップでメモすること：

• ユーザーが詰まる／離脱する場所
• 所要時間（手作業の担当者は誰か）
• よく起きるエラー（ダブルブッキング、場所の間違い、返金の不明確さ）

このジャーニーマップで摩擦を取り除く機能の優先度を決めます。

まずは一つのニッチに絞り、それを約束に変える

「何でも予約できるアプリ」は避けてください。複雑さを減らし、導入を早めるために最初は一つの垂直市場（例：ヨガスタジオ、音楽レッスン、家庭教師）から始めます。

その後、調査結果を問題定義とアプリの約束（プロミス）に落とし込みます：

• 問題： 誰が、どのような問題に、どれくらい頻繁に直面しているか
• 約束： 測定可能な成果（例：「30秒で予約」「欠席減少」「自動ウェイトリスト登録」）

これが明確でないとMVPは焦点が定まらず、売りにくくなります。

ユーザーロールとコアユースケースを定義する

機能を列挙する前に、誰がアプリを使い、何を達成する必要があるかを明確にします。ほとんどの予約アプリは学生、講師、管理者／オーナーの3つの役割がありますが、最初から全部出す必要はありません。

学生（購入者）

学生の体験は摩擦がないことが重要：クラスを見つけ、内容を理解し、混乱なく予約を完了できること。

典型的な学生ユースケース：今後のクラスを閲覧、スポット予約、支払い、ポリシー内での再スケジュールやキャンセル、リマインダーの受信。

講師（運用担当）

講師は「何を、いつ、誰に教えるか」が重要です。

講師向けユースケース：可用性の設定／管理、クラス名簿の閲覧、場所や持ち物、急な変更を学生にメッセージ送信。承認が必要なモデルなら承認／却下フローを追加しますが、運用上必要な場合のみに留めてください。

管理者／オーナー（事業側）

オーナー／管理者は事業の設定と日々の混乱の抑制が役割です。

典型的な管理者ユースケース：クラスとスケジュールの管理、価格と割引ルールの設定、キャンセル／ノーショーのポリシー定義、スタッフ権限の管理（誰がクラスを編集できるか、返金を発行できるか、顧客にメッセージを送れるか）。

v1で何を出すか、後回しにするか決める

実用的なMVPパス例：

• v1： 学生の予約＋決済＋基本的な管理（クラス、スケジュール、ポリシー）
• v1.5： 講師ツール（可用性、名簿、メッセージ）
• 後期： 詳細な権限管理、複数拠点管理、より高度なメッセージ／CRM

単一スタジオであれば「学生＋オーナー」から始め、運用が安定したら講師アカウントを追加することが多いです。マーケットプレイスを作るなら、講師のオンボーディングと可用性管理はv1に含める必要があります。

スコープを狭く保つために、「必ず動く」シナリオを5〜10個書き出してください（例：「学生が予約して支払う」「学生がポリシー内で再スケジュールする」「オーナーがクラスをキャンセルし学生に通知される」）。これらがプロダクトチェックリスト兼テストプランになります。

MVPに必要な機能を選ぶ

クラス予約アプリのMVPは「小さくした全部」ではありません。実際の顧客がクラスを見つけ、スポットを確保し、支払えるための最小限の機能セットです—その間にチームが裏で手作業をする必要がないこと。

コアな予約ループから始める

モバイル予約アプリは下記のエンドツーエンドフローをサポートするべきです：

1. クラスを閲覧
2. セッションを選択
3. 空き確認
4. 支払い（または仮押さえ）
5. 確認とリマインダーを受け取る

どれか一つでも欠けるとユーザーを逃すか運用上の面倒が増えます。

MVPに入れるべき機能（とその理由）

クラス一覧とフィルター。 ロケーション、レベル、価格、時間、講師などで絞り込めるシンプルなカタログを提供します。単一スタジオでもフィルターはスクロール疲れを減らします。マーケットプレイスならロケーションや講師フィルターが必須になります。

スケジューリングの基本。 時間枠、定員、定期セッションをサポートします。人気クラスが満席になる場合に備えてウェイトリストは早めに導入しましょう。失われた収益を防ぎ、フロントデスクの業務を減らします。

決済とサブスクリプション（最小限だが完結）。 カード決済と地域で人気のウォレットを一つから始めます。デポジット、返金、プロモコードを含めます。メンバーシップが事業の主要収入源なら、複雑な階層ではなくシンプルなサブスク（例：月額プラン＋クラスクレジット）から始めましょう。

欠席を防ぐ通知。 予約確認、リマインダー、スケジュール変更／キャンセル、ウェイトリストの更新をプッシュで送ります。メッセージは短くアクション指向に。

信頼を築くアカウント周り。 プロフィール、保存された支払い方法、予約履歴は基本です。履歴は「本当に予約したか？」というサポート問合せを減らし、再予約を促します。

後回しにするもの

高度な分析ダッシュボード、紹介機能、アプリ内チャット、深いカレンダー同期は、予約フローが安定して需要が検証されるまでスキップします。内部の「アプリMVPチェックリスト」を一つ持ち、すべての機能を実際のユーザーニーズに結びつけてください。

スケジューリングと価格ルールをモデリングする

画面設計やコードを書く前に、スケジューリングと価格ルールをドキュメント化してください。多くの予約アプリはカレンダーUIではなく、UIの裏にあるルールが不明確なために失敗します。

サービスカタログ：何が予約可能か？

提供する「予約可能なもの」を一覧にします。後でデータ化できるよう構造化してください：

• クラスの種類（例：Yoga Flow、Beginner Guitar、SAT Prep）
• 所要時間（45/60/90分など、またはクラスごとに固定）
• レベル（初心者／中級／上級）
• 場所／ルーム（スタジオAとスタジオB、オンライン／対面）

早い段階で1:多クラス（1人の講師に対して複数の受講者）か1:1レッスン（講師と受講者1対1）かを決めてください。ルールや価格はしばしば異なります。

可用性ルール：いつ予約可能か？

可用性は単なるカレンダーではなくポリシーとして定義します。

• 営業時間（場所や講師ごと）
• 休憩時間（昼休み、準備／片付け時間）
• 祝日と休業日（単発と繰り返しルール）
• バッファ（準備のための前後10分など）

また、突発的な混乱を防ぐ境界を設定します：「予約は開始2時間前まで」「当日予約は午後5時まで」など。これらの制限はサポート負荷を減らします。

キャパシティと在庫：座席数は？

グループクラスでは定員が在庫に相当します。明確にします：

• クラスあたりの座席数（部屋ごとに変わるか）
• 締め切り時間（例：開始15分前で予約締切）
• オーバーブッキングルール（通常は避ける。許可する場合はいつどのように）

ウェイトリストをサポートするなら、席が空いたときの動作を定義します：次の人が自動で登録されて支払われるのか、それとも時間限定のオファーを出すのか。

価格モデル：何に対して支払うか？

事業に合う最も単純なモデルを選びます：

• 1回ごと（単発購入）
• パック／回数券（例：5回パック、60日有効）
• メンバーシップ／サブスクリプション（月額、制限や特典付き）

エッジケースも今のうちに書き出してください：パックは全てのクラスで使えるのか、カテゴリ限定か。メンバーシップは無制限なのか月ごとの上限があるか。ここが明確でないとチェックアウトと機能範囲に影響します。

ポリシー：キャンセル、ノーショー、返金

ポリシーは1画面に収まるくらい短く簡潔にします：

• キャンセル期限（例：開始12時間前まで無料でキャンセル可能）
• ノーショールール（手数料徴収、クレジット没収、ストライク制など）
• 返金方針（いつ許可されるか、処理にかかる時間、手数料の扱い）

ルールがシンプルならアプリの印象もシンプルになります。ユーザーは「予約」前に結果が分かるため信頼性が高まります。

ユーザー体験と主要画面を設計する

クラス予約アプリの成否は、ユーザーがどれだけ速くクラスを見つけ、価格を理解し、自信を持ってスポットを確保できるかにかかっています。目標は「3分で予約」：入力を最小限にし、驚きがなく、次のアクションが明確であること。

必要になりそうなコア画面

オンボーディングは価値を1〜2画面で伝え、その後は邪魔をしないこと。ユーザーが予約するまではブラウズを許可し、予約時にサインアップを求める流れが良いです。

検索／閲覧はほとんどのセッションが始まる場所です。シンプルなフィルター（日付、時間、場所、レベル、価格）を使い、結果は見やすく：クラス名、講師、所要時間、次回開催時間。

クラス詳細は決定ページです。表示すべきは：

• リアルタイムの空き（残り席）
• 総額（税／手数料を含む場合は明示）
• 持ち物、キャンセル期限、場所

カレンダー／スケジュールはユーザーが予約管理をする場所。ポリシー内での再スケジュールやキャンセルを簡単にし、任意でカレンダー同期を提供します。

チェックアウトは良い意味で退屈に。可能な限り1ページで収め、合計額を繰り返し表示し、日時を明確に確認させます。

プロフィールはメンバーシップ、支払い方法、クレジット残高、領収書、ポリシーリンクをまとめる場所。

予約UXの基本（離脱を避ける）

予約可能なオプションのみ表示してください。満席なら明確に「満席」と表示し、「ウェイトリストに参加」または「次の空き時間を表示」を提案します。成功時にはすぐに予約確認を表示し、「カレンダーに追加」アクションをわかりやすく提示します。

アクセシビリティと信頼性

読みやすいフォントサイズ、強いコントラスト、大きなタップ領域を使ってください。信頼を得る要素も重要です：講師の略歴、レビュー、明確なキャンセル／返金ポリシー、安全な決済を示すアイコンや簡潔な説明。

チェックアウトや設定にポリシーページへのリンクを置く（例：/terms、/privacy）ことでユーザーに安心感を与えます。

予算とスケジュールに合う技術選定をする

技術選定はMVPのスコープに従うべきです。目的は迅速に信頼できる予約フローをリリースし、その後改善することです。

モバイル：ネイティブ vs クロスプラットフォーム

**ネイティブ（iOSはSwift、AndroidはKotlin）**はパフォーマンスやデバイス機能へのアクセスで有利ですが、コストは高くなります（実質2つ作ることに）。

**クロスプラットフォーム（React Native、Flutter）**はiOSとAndroidでコードを共有でき、ローンチが速く保守も単純化されることが多いです。高度なUI操作や統合が必要な場合は追加の手間がかかることがあります。

実用ルール：予算が限られて早く進めたいならクロスプラットフォームから始める。ブランド体験が非常に重要で既にiOS／Androidのチームがいるならネイティブを検討してください。

プロトタイプやフルカスタムビルドにすぐ移りたくない場合、Koder.aiのようなvibe-codingプラットフォームでチャットベースの仕様から動くWebアプリ、バックエンド、Flutterモバイルアプリを素早く作ることもできます。スケジューリングルールやMVPスコープを試行錯誤する段階で有用で、プランニングモードやソースコードのエクスポートもサポートしているため、検証しつつコードベースを所有する道筋も残せます。

バックエンドの基本（MVPでも必要）

ほとんどの予約アプリに必要な基盤は同じです：

• ユーザー、クラス、講師、スケジュール、予約を保存するデータベース
• データを安全に読み書きするAPI
• 非エンジニアが運用できる管理ダッシュボード（クラス作成、時間編集、講師管理、返金発行）
• リマインダーや「クラス開始1時間前」など時間ベースのタスク用のジョブスケジューラ

リアルタイムの空き管理：ダブルブッキングを避ける

ここで予約アプリはよく失敗します。二人がほぼ同時に「予約」を押したとき、在庫超過を防がなくてはいけません。

通常はデータベースのトランザクションかロック／予約方式（支払い完了を待つ間、短時間席を仮押さえ）を使います。「空きチェック」だけに頼らず、予約アクションを原子的に処理してください。

検討すべきサードパーティサービス

すべてを自前で作る必要はありません。よく使われるアドオン：

• 分析ツール（予約フローでの離脱箇所を可視化）
• メール／SMSプロバイダ（確認やリマインダー）
• 地図サービス（スタジオや講師の位置、道順）

適切なスタック選びが初回リリースをスケジュール通りに進めつつ後で拡張可能にします。

決済、返金、サブスクリプションの設定

決済はアプリの印象を左右します。支払モデル（1回払い、デポジット、サブスクリプション、パック）を早めに定義してください。これがデータモデル、領収書、キャンセルルールに影響します。

決済プロバイダ：何を扱ってもらい、何を自分で持つか

一般的にはStripe、Adyen、Square、Braintreeなどを使います。これらはカード保存、3Dセキュア／SCA、詐欺チェック、顧客向け領収書、異議申し立て／チャージバック処理を扱います。

しかし、いつ資金を確定（予約時か参加後か）、どのタイミングで「成功した支払い」を予約作成に結びつけるか、失敗した支払いをどう扱うかはあなたが決める必要があります。

返金とキャンセルフロー

現実は複雑です：直前キャンセル、講師の病欠、スケジュール変更があります。

一般的な対応をサポートしてください：

• 全額返金（運営側がクラスをキャンセルした場合）
• 一部返金（例：キャンセル料が差し引かれる）
• クレジット払い戻し（ストアクレジット）
• デポジット（返金不可、または一定期間内のみ返金）

ルールはチェックアウト画面と予約詳細メールに明示してください。

サブスクリプションとクラスパック

「10回パック」や月額メンバーシップは残高システムとして扱うと良いです：

• ユーザーごとの残りクレジットを追跡
• 予約時にクレジットを確保し、返金時に戻す
• 更新、期限切れ、更新失敗を扱う

オプションを比較させるならプランページ（例：/pricing）へリンクします。

税金と請求書

アプリ内で表示すべき項目（価格内訳、税/VAT、事業情報）とメールで送る項目（請求書PDF、法的文書）を決めます。多くのプロバイダが領収書を発行しますが、請求書要件は地域で異なるため事前に確認してください。

アカウント、プライバシー、セキュリティの基本

予約アプリは個人のスケジュール、メッセージ、金銭を扱うため、基本的なアカウントとセキュリティの選択が信頼に直結します。エンタープライズ並みの複雑さは不要ですが、明確なルール、妥当なデフォルト、障害時の対応計画は必要です。

アカウントとサインイン（シンプルに）

オーディエンスに合った認証方法を提供し、サポート負担を減らします：

• メール＋パスワード（一般的）
• 電話番号＋ワンタイムコード（モバイルファースト向け）
• ソーシャルサインイン（Apple／Google）でオンボーディングを速くする

後でメールや電話番号を変更しやすくし、スタッフアカウント向けに任意の二段階認証を検討します。

保存すべきデータ（と避けるもの）

予約とサポートに必要な最小限のデータに留めます：

• 保存する：名前、連絡先、予約履歴、出席状況、メンバーシップ／クレジット残高
• 避ける：カード番号、CVV、銀行口座の生データ

支払いの機微データは決済プロバイダに任せ、アプリ側にはトークンやIDのみ保持してください。コンプライアンスとリスクが低くなります。

ユーザーが期待するプライバシーの基本

プライバシーは法的手続きだけでなく、ユーザーのコントロール感に関わります：

• 通知とマーケティングへの明確な同意
• メール／SMSの受信設定（取引連絡とプロモーションの分離）
• データ削除とアカウント閉鎖の分かりやすい手順

プライバシーポリシーへのリンクを設定（例：設定画面やサインアップ時）し、削除要求に対応するサポート準備をしておきます。

スタッフ向けの運用上のセキュリティ

現場の問題の多くは内部のミスから発生します。以下を用意してください：

• 役割ベースのアクセス制御（講師、フロントデスク、管理者）
• 予定や価格、返金、キャンセルの変更履歴を残す監査ログ

これにより「そんなキャンセルはしていない」という紛争の解決が容易になります。

信頼性：地味な失敗への備え

セキュリティは迅速な復旧体制も含みます：

• 自動バックアップと復元テスト
• 基本的な監視（エラー、決済失敗、予約フローの離脱）
• 軽量なインシデントチェックリスト：誰が調査し、誰が連絡し、どの機能を止めるか（例：新規予約）

こうした基本が収益を守り、ダウンタイムを減らし、ブランドを保護します。

予約フローのテストとよくある失敗の予防

予約アプリのテストは「クラッシュしない」ことだけではありません。お金が動き、スケジュールが確定される瞬間を守ることが目的です。小さなバグでダブルブッキングや返金の対応が必要になり、利用者が怒ることがあります。

適切なテストで信頼を作る

まずスケジューリングルール（定員制限、キャンセルウィンドウ、クレジットパック、価格ロジック）に対するユニットテストを用意します。その後、予約→決済完了→席割当→通知というフルチェーンをカバーする統合テストを追加します。

決済プロバイダを使う場合はWebhook／コールバックの取り扱いを徹底的にテストしてください。「支払い成功」「支払い失敗」「支払い遅延」「チャージバック／返金」それぞれの挙動を明確にします。冪等性（同じコールバックが二度届いても二重に予約が作成されないこと）も確認しましょう。

実際のアプリを壊すエッジケースを探す

以下の失敗しやすいシナリオに注力します：

• 最後の1席レース条件： 二人が同時に「予約」を押す
• ウェイトリスト昇格： 席が空いた時に次の人が昇格されるときの支払い／保持ロジック
• タイムゾーン＋DST： 講師と学生が別のタイムゾーン、夏時間の切り替え
• カレンダー同期の競合： 変更後も正しいローカル時間でイベントが入るか

実機と低品質ネットワークでテストする

小さなデバイスマトリクス（古い機種、小画面、OSの異なるバージョン）でテストし、低接続や機内モード遷移をシミュレートします。

プッシュ通知については配信、ディープリンク、通知オフ時の挙動を確認してください。

ベータ展開と簡易QAチェックリスト

公開前に少数の講師と学生でベータを回します。各リリースではシンプルなQAチェックリスト（予約、キャンセル、再スケジュール、返金、ウェイトリスト、通知）を用意し、更新前に必須項目として実行します。

リリース計画の補助が必要なら、/blog/app-mvp-checklist に共有ドキュメントを置いておくと便利です。

ローンチ計画：App Store、運用、最初のユーザー

スムーズなローンチは派手さより「レビュワーと最初の顧客双方の摩擦を取り除くこと」が重要です。ユーザーを招待する前にアプリが「機能的に完成」しているだけでなく「運用的にも完成」していることを確認してください。

ストア提出準備（Apple + Google）

提出のためのチェックリストを用意してください。遅延は全体を止めます。

準備するもの：

• ストアアセット：アプリアイコン、一般的なデバイスサイズ向けのスクリーンショット、実際の機能に即した説明文
• プライバシー表示／ラベル：収集するデータ（メール、位置情報、決済状況、分析）と理由を明示
• レビューガイドライン準拠：曖昧な表現を避け、アカウント削除が必要なら動作すること、ログインで主要画面が壊れていないこと

運用準備

最初のユーザーはUIだけでなくビジネス運用を試します。

整備するもの：

• モニタリングされるサポート用メール（応答時間目標を設定）
• よくある問題をまとめた短いFAQ（再スケジュール、返金、講師キャンセルの扱い）
• 明確なキャンセルポリシーページ（アプリ内とストア説明にリンク）、例：/cancellation-policy

ローカルで始め、正しい指標を測る

最初は1都市や1つのスタジオネットワークで始めてください。供給、サポート、スケジュールのエッジケースを管理しやすくなります。

毎日追うべき指標を2つ：

• オンボーディングの離脱箇所（どこで離脱するか：電話認証、アカウント作成、クラス選択）
• 初回予約完了率（検索→詳細→支払い→確認）

重大なバグのロールバック計画

何かが壊れる前提で進めてください。単純なロールバック計画を用意します：最後の安定ビルドを再提出する準備、サーバー側のフラグでリスクのある機能を無効化、ユーザー向けのステータスメッセージテンプレート。

自己ホスティングの場合はスナップショット／バックアップと復元テストを優先し、デプロイが失敗したときに迅速に復旧できるようにします。

ローンチ後の成長：マーケティングと反復

アプリをリリースすることは始まりであって終わりではありません。成長は新規獲得ループとリピートさせるループの並行運用から生まれます。

リテンションを高める施策

リテンションは獲得よりコストが低いことが多いので、週次計画に組み込みます：

• スマートなリマインダー： 確認、前日の通知、直前のアラート（スパムにならないよう注意）
• 再予約促進： クラス後に次の候補を提示（「来週同じ時間は？」）や短期パスの提案
• ロイヤルティ特典： 「5回で1回無料」や会員専用枠などシンプルな報酬
• 紹介施策： 完了予約に紐づく「紹介で$10獲得」などわかりやすいオファー

公開で開発するなら、Koder.aiのようなプログラム（コンテンツ公開や紹介でクレジット付与）をモデルにして、コアフローが安定してからアプリ内に取り入れることもできます。

講師（スタッフ）を支援して成長を促す

講師がバックエンドを気に入り推奨してくれると広がりが早くなります。

提供すべき機能：

• スケジュール編集の高速化（一括変更、簡単なキャンセル、ウェイトリスト処理）
• 支払いレポート（何を稼ぎ、保留中、返金されたか）
• パフォーマンス統計（埋まり率、リピート学生、ピーク時間）

本当に重要な分析指標

少数の指標に絞って毎週確認します：

• CAC（顧客獲得コスト）： 1人のアクティブ顧客を獲得するコスト
• コンバージョン率： インストール→サインアップ→初回予約の遷移
• チャーン： いつ誰が予約を止めるか
• LTV（顧客生涯価値）： 時間あたりの収益
• ノーショー率： クラス種別、時間帯、講師、リマインダー設定別

測定結果に基づくロードマップ作り

「次に欲しい機能」リストは持ちながらも、重要なのは指標を動かすものだけ優先すること。ローンチ後に典型的に追加される機能はメッセージング、動画レッスン、複数拠点サポート、ギフトカードなどです。

良いペース感は：1〜2週に1つ小さな改善を出し、アプリ内で告知し、その改善が予約数、リテンション、運用負荷にどう影響したかを測ることです。